Quantcast
Channel: 200-105 Chapters – Wendell's CCNA Skills Blog
Viewing all 48 articles
Browse latest View live

Extended IPv4 ACL Drill 1

0
0

Extended Access Control Lists (ACLs) can be a challenge for many reasons. In the first few posts in this series, these ACL exercises will focus on just a few of those issues. In particular:

  • The concept and syntax to match TCP and UDP port numbers
  • When you need to make the ACL match and permit some kinds of overhead traffic

Today’s post gives you a set of requirements, and then a few variations on that set of requirements. Your job: Create an ACL that meets those requirements. Simple enough!

Ground Rules

First off, a quick note about some rules for this exercise. First:

These exercises are NOT intended to be about tricky wording. The requirements are intended to be plain.

Instead, the goal of these exercises is to give you repetition in thinking about:

  • The location and direction of the ACL
  • The matching of different applications
  • The matching of some overhead protocols

So, read the requirements, think of them as being plain, create ACL statements to match each requirement, and practice choosing the correct config while thinking about the location of the ACL!

 

The Requirements

Configure an ACL to meet the following requirements.

First, the exercise uses the topology in Figure 1:

Figure 1: Topology Used in the ACL Drill

 

Use the following requirements to decide how to configure a named IPv4 ACL to permit and deny specific applications:

  1. Use the ACL location shown with the circled 1, that is, outbound on router R2’s G0/2 interface.
  2. Deny any TCP and UDP traffic that is not otherwise noted to be permitted per these requirements, while allowing all other IP packets.
  3. For any ACL statements that could use either a number or a keyword (for instance, for a TCP port number), use the number, not the keyword.
  4. Permit the following applications to work correctly between hosts in the subnet where host A resides and hosts in the subnet where server S resides:
    • Telnet
    • World Wide Web
    • SMTP

Additionally, make sure that your ACL meets the following requirements for overhead protocols. Configure ACL statements only if necessary to meet these requirements:

  1. To allow IPv4 ARP to work correctly
  2. To allow IPv4 OSPF to work correctly

You should be able to extrapolate the necessary IPv4 addressing details from the following router address/mask reference table:

Device Interface Address/Mask
R1 G0/1 172.16.1.1/25
R1 S0/0/0 172.16.12.1/30
R2 G0/1 172.16.2.2/26
R2 S0/0/1 172.16.12.2/30
R2 G0/2 172.16.23.2/29
R3 G0/1 172.16.3.3/27
R3 G0/2 172.16.23.3/29

Router Interfaces and Their Address/Mask Settings

 

Answers: Next Post!

I’ll post in the answers within the next few days. Once posted, the answer post should be linked at the bottom of this post, as the next post in chronological order. Thanks for playing!


Extended IPv4 ACL Drill 1 – Answers

0
0

The previous post listed a set of ACL requirements that require an IPv4 Extended ACL. Your job: using those requirements, configure an extended named ACL. Of course, this post makes no sense without the post that states the requirements, so check out that post first. Answers and comments are below the fold.

Ground Rules

Often times, the words that describe the requirements for an ACL can be interpreted in several ways. So, before reading these answers, consider:

  • Your answer may be correct per your interpretation of the requirements…
  • …while being different from the answer listed here.

For the answer shown here, I tried to work through the requirements one by one, with a line in the ACL for each requirement. Feel free to comment about alternate answers, but FYI, that’s how I came up with these.

On to the answers!

 

Subnets in Use

All the answers will use the subnets of host A and Server S, so a few words about those first.

To match the subnet of host A, you need to find the subnet ID and the matching wildcard mask. First, calculate the subnet ID:

  1. R1’s G0/1 interface address/mask is 172.16.1.1/25
  2. Calculate the subnet ID as 172.16.1.0.

Then, to find the correct wildcard (not subnet) mask to use:

  1. Convert prefix mask /25 to dotted decimal mask 255.255.255.128
  2. Subtract it from 255.255.255.255 to get 0.0.0.127
  3. Use 0.0.0.127 as the wildcard mask in the ACL statement.

For subnet 3, using the same logic:

  1. R3’s G0/1 interface address/mask is 172.16.3.3/27
  2. To match the subnet, use the subnet ID of 172.16.3.0.
  3. Convert prefix mask /25 to dotted decimal mask 255.255.255.224
  4. Subtract it from 255.255.255.255 to get 0.0.0.31
  5. Use 0.0.0.31 as the wildcard mask.

 

Answers

Of note for this particular answer:

  • The ACL is located on R2, in the direction pointing towards the server, so any matching of well-known ports should be a match of the ACL’s destination port number
  • Any ACL statement that matches a port number should use either the tcp or udp keywords.
  • As an outbound ACL, the ACL will no filter any messages created by the router itself. So, the ACL would not consider filtering any ARP or OSPF messages it had generated anyway. (More on this topic in the answers for Option 3.)

Figure 1: Topology Used in the ACL Drill

 

The answers for requirement set 1, for the explicitly identified applications:

ip access-list extended option1
  permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 23  # uses 23 for Telnet
  permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 80  # uses 80 for WWW
  permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 25  # uses 25 for SMTP

Partial Answer

The requirement about denying all other TCP and UDP packets, while permitting all other IP packets besides those, might be a bit tricky. The logic intended by the combined requirements is this sequence:

  1. Permit packets for apps Telnet, World Wide Web, and SMTP
  2. Deny all other TCP and UDP traffic (that wasn’t already permitted)
  3. Permit all other IP traffic (that wasn’t already denied)

With that in mind, the following answer adds the matching for all other TCP, then UDP, and then IP. Without those final three commands, all other IP packets would have been denied because of the implied deny any any at the end of the ACL. (Also note that the configuration enables the ACL as suggested in the lab.)

ip access-list extended option1
 permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 23 # uses 23 for Telnet
 permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 80 # uses 80 for WWW
 permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 25 # uses 25 for SMTP
 deny tcp any any
 deny udp any any
 permit ip any any
!
interface gigabitethernet0/2
 ip access-group option1 out

Completed Answer

 

Extended IPv4 ACL Drill 2

0
0

This next Extended IPv4 ACL Drill continues to focus on some key ACL concepts. You have to think about where the ACL will reside, and for what direction of packet flow, before choosing the syntax of the commands. This next lab reverses the direction of flow versus the previous ACL drill.

As with all these ACL drills, today’s post gives you a set of requirements, and then a few variations on that set of requirements. The requirements may look familiar if you saw the previous exercise, but the answer is definitely different! Your job: Create an ACL that meets the requirements.

Ground Rules

First off, a quick note about some rules for this exercise. First:

These exercises are NOT intended to be about tricky wording. The requirements are intended to be plain.

That said, this exercise asks you to prevent ACLs in one subnet from communicating with a server in another subnet. You can filter packets going in either direction for the purpose of meeting that goal. In this exercise, you will need to filter packets flowing from the server to the client. That is not tricky wording – it’s just a chance to think about a different way to configure an ACL!

 

The Requirements

First, the exercise uses the topology in Figure 1:

Figure 1: Topology Used in the ACL Drill

 

Use the following requirements to decide how to configure a named IPv4 ACL to permit and deny specific applications:

  1. Use the ACL location shown with the circled 2, that is, inbound on router R1’s S0/0/0 interface.
  2. Deny any TCP and UDP traffic that is not otherwise noted to be permitted per these requirements, while allowing all other IP packets.
  3. For any ACL statements that could use either a number or a keyword (for instance, for a TCP port number), use the keyword, not the number.
  4. Permit the follow applications to work correctly between the subnet where host A resides and the subnet where server S resides.
    • Telnet
    • World Wide Web
    • SMTP

Additionally, make sure that your ACL meets the following requirements for overhead protocols. Configure ACL statements only if necessary to meet these requirements:

  1. To allow IPv4 ARP to work correctly
  2. To allow IPv4 OSPF to work correctly

You should be able to extrapolate the necessary IPv4 addressing details from the following router address/mask reference table:

Device Interface Address/Mask
R1 G0/1 172.16.1.1/25
R1 S0/0/0 172.16.12.1/30
R2 G0/1 172.16.2.2/26
R2 S0/0/1 172.16.12.2/30
R2 G0/2 172.16.23.2/29
R3 G0/1 172.16.3.3/27
R3 G0/2 172.16.23.3/29

Router Interfaces and Their Address/Mask Settings

 

Why ACL Drills Now?

FYI, I decided to create these latest exercises because I’m working on the final edit of the videos in a new product: The CCNA ICND2 Exam Prep LiveLesson. (Here’s a link to the similar product for CCENT/ICND1; the new CCNA/ICND2 product will be on the web in a week or two.) That new product has a few videos that show some of the common mistakes made when working with ACLs, in particular the kinds of issues that can happen with the direction of flow. Stay tuned on those – should be out in June 2017 – maybe that related ACL video will be one of the free ones to check out before having to buy!

 

Answers: Next Post!

I’ll post in the answers within the next few days. Once posted, it should be linked at the bottom of this post, as the next post in chronological order. Thanks for playing!

Extended IPv4 ACL Drill 2 – Answers

0
0

Extended IPv4 ACLs? No problem. Matching packets going towards the client? A little more of a problem. Deciding whether you need to match ARP and OSPF in your ACL? Even more of a problem. This latest drill makes you think about ACL location + direction, syntax, plus those overhead protocols. As usual, check on the post about the requirements first so that this post makes sense.

Ground Rules

Often times, the words that describe the requirements for an ACL can be interpreted in several ways. So, before reading these answers, consider:

  • Your answer may be correct per your interpretation of the requirements…
  • …while being different from the answer listed here.

On to the answers!

 

Subnets in Use

All the answers will use the subnets of host A and Server S, so a few words about those first.

First, because the packets that drive this ACL will be flowing towards host A’s subnet, and from server S’s subnet, the source field in the ACL statements should refer to server S’s subnet, and the destination should refer to host A’s subnet.

Second, you just need to do a little math to take the router interface address/mask combo connected to those subnets to convert those numbers to the correct values to put in the ACL. First, to match the subnet of host A, to find the address and wildcard mask to use:

  1. R1’s G0/1 interface address/mask is 172.16.1.1/25.
  2. To match the subnet, use the subnet ID, calculated as 172.16.1.0.
  3. Convert prefix mask /25 to dotted decimal mask 255.255.255.128
  4. Subtract it from 255.255.255.255 to get 0.0.0.127
  5. Use 0.0.0.127 as the wildcard mask in the ACL statement.

For subnet 3, using the same logic:

  1. R3’s G0/1 interface address/mask is 172.16.3.3/27
  2. To match the subnet, use the subnet ID, calculated as 172.16.3.0.
  3. Convert prefix mask /25 to dotted decimal mask 255.255.255.224
  4. Subtract it from 255.255.255.255 to get 0.0.0.31
  5. Use 0.0.0.31 as the wildcard mask in the ACL statements.

For reference, the exercise uses the topology in Figure 1:

Figure 1: Topology Used in the ACL Drill

 

Answers

Of note for this particular answer:

  • The ACL is located on R1, in the direction pointing away from the server. As a result, any matching of well-known ports should be a match of the ACL’s source port number
  • Any ACL statement that matches a port number should use either the tcp or udp keywords.
  • As an inbound ACL, the ACL will attempt to filter all IPv4 messages. In this case, that means:
    • You need to add statements to permit OSPF packets, because those use IPv4
    • You do NOT need to add statements for ARP, because ARP does not actually use IPv4 (ARP is a separate protocol, and is not encapsulated in IP packets.)

The answers for requirement set 1, for the explicitly identified applications, before getting to the defaults and overhead messages:

ip access-list extended eacl02
  permit tcp 172.16.3.0 0.0.0.31 eq telnet 172.16.1.0 0.0.0.127
  permit tcp 172.16.3.0 0.0.0.31 eq 80 172.16.1.0 0.0.0.127 
  permit tcp 172.16.3.0 0.0.0.31 eq 25 172.16.1.0 0.0.0.127

Partial Answer

 

Next, for the defaults, the requirement about denying all other TCP and UDP packets, while permitting all other IP packets besides those, might be a bit tricky. The logic intended by the combined requirements is this sequence:

  1. Permit packets for apps Telnet, World Wide Web, and SMTP
  2. Deny all other TCP and UDP traffic (that wasn’t already permitted)
  3. Permit all other IP traffic (that wasn’t already denied)

With that in mind, the following answer adds the matching for all other TCP, then UDP, and then IP.

ip access-list extended eacl02
 permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 23 # uses 23 for Telnet
 permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 80 # uses 80 for WWW
 permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 25 # uses 25 for SMTP
 deny tcp any any
 deny udp any any
 permit ip any any
!
interface serial0/0/0
 ip access-group eacl02 in

Possibly Complete Answers; Adds Matching for TCP, UDP, IP

 

Finally, regarding OSPF and ARP, to restate, ARP does not use IP, so an IPv4 ACL will never filter an ARP message. However, OSPF uses IP; the OSPF messages are encapsulated directly into IP packets, using IPv4 protocol number 89. And when an OSPF message arrives in R1’s S0/0/0 interface, R1 would consider that packet based on the IPv4 ACL as configured, possibly denying (filtering) the OSPF message/

With the latest configuration, those OSPF packets would be permitted already, due to the ending permit ip any any command at the end of the ACL. However, you could have matched it explicitly in a couple of ways. You could have matched on the common destination IP addresses used by OSPF (224.0.0.5 and 224.0.0.6), or by matching the IPv4 OSPF protocol number by using protocol number 89, or by using the ospf keyword (permit ospf any any).

Figure 2: OSPF Encapsulation

Question: Interpreting show stp (1)

0
0

To analyze Spanning Tree for #CCNA, you need to think about the root switch, then the root ports on the non-root switches, and then designated ports. That analysis usually begins with the show spanning-tree command – a command that packs an incredible amount of meaning into its relatively short output. Mastering every tidbit of meaning from show spanning-tree is a great place to avoid mistakes and pick up points on the exam. Here’s a new practice question that gives you some exercise.

Question

Which answers show facts confirmed by the output from local switch SW4 about the root switch and the listed port G0/1?

SW4> show spanning-tree vlan 1

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    24577
             Address     fa16.3e9a.25be
             Cost        4
             Port        2 (GigabitEthernet0/1)
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  1. The local switch (SW4) is the root switch
  2. Some other switch is the root switch
  3. The output does not confirm whether the local switch (SW4) is the root switch or not
  4. Port G0/1 is a port on the root switch
  5. Port G0/1 is a port on the local switch (SW4)
  6. Port G0/1 is a port on some other switch that may or may not be the root switch

As usual, I’ll post the answer in just a few days. At that time, a link to the answer will appear towards the bottom of this page, just above where the comments begin.

Interpreting show stp (1) – Answers

0
0

Of all #CCNA topics in the ICND2 half of CCNA, Spanning Tree Protocol (STP) looms with more intimidation than most. As for Mastering STP verification, the process begins with mastering the show spanning-tree command. This latest sample question focuses on the first section of that command’s output, asking about two topics: is the local switch the root switch, and what does the port number in that first grouping of messages tell you about the network? Check out the original question, and then dive in here for the answer and some explanation.

Answer

B: Some other switch is the root

E: Port G0/1 is a port on the local switch

 

Explanation

First, note that the output shown with the question lists one section of the show spanning-tree command’s output, and does not include the 2nd and 3rd section. The first section describes facts related to the root switch, while the second section describes the local switch (that is, the switch that generated the output.) The third section shows a list of local interfaces with their STP port roles and states. So, to answer this question, you need to have mastered some of the facts found in that first section of output – you just can’t rely on the other sections (which would have been useful as well). The question requires you to trust the information in the first stanza of messages.

When issuing the show spanning-tree command on the root switch, the root switch claims to be the root, with a statement “This bridge is the root.” The output for the question does NOT list that line, so the absence of that line tells us, without question, that the local switch is not the root switch. That fact rules out two answers about which switches might be root and confirms that the local switch is not the root switch.

Figure 1: Absence of Note about the Local Switch Being Root

The second set of related answers ask about what the mention of “GigabitEthernet0/1” means. Again, from memory and earlier study, you should know that if the local switch is not the root switch, that:

  • As a non-root switch, the local switch has a root port, and a cost to reach the root
  • The show spanning-tree command lists those facts in the first stanza: facts about the local switch and its relationship to the root switch

As a result, you can know that the first message group’s mention of port GigabitEthernet0/1 is an interface on the local switch (SW4), namely the port used as its root port. That fact rules out two answers, and rules in the answer that restates that port G0/1 is on the local switch.

Figure 2: Location of Two Lines in First Stanza about Local Switch

 

Common Mistakes

As usual, let me give you a few more pointers about avoiding common mistakes on the exam. In this particular area of concern – that is, the narrow world of just the first section of output from show spanning-tree – keep an eye out for these items:

  • Looking for the absence of a line of output can be one of the most challenging kinds of details to notice when under pressure on the exam. When in lab, take the time to compare that first stanza of messages on the root switch versus a non-root, and help that difference sink in visually: the claim of being the root, versus the two lines about root cost and root port.
  • Another set of facts to memorize: on a non-root switch, as in this question, that first stanza lists the Bridge ID of the root, followed by the root cost and root port of the local switch. So, it’s not all about the root switch: it’s about the root switch plus the local switch’s facts related to the root switch.

 

 

Q: Matching Port Numbers with ACLs 1

0
0

#CCNA ACL questions can uncover your weaknesses even without a detailed and complicated list of requirements to place in a single ACL. In fact, my “Acing the CCNA Exam” live course on Safari features ACL Port Matching as one of its top 10 common mistakes for about 10 minutes of the course. In preparation for the upcoming Feb 8th edition of the course, I’ve added this new question. Enjoy.

Question:

Which answers lists an ACL command would permit all unencrypted web traffic from the web servers on the left of the figure to the subnet of the web clients on the right, assuming router R1 enables the ACL on its G0/1 interface in the input direction?

  1. access-list 101 permit ip   172.16.16.0  0.0.7.255   172.16.4.0 0.0.3.255  eq www
  2. access-list 101 permit tcp 172.16.16.0  0.0.7.255   172.16.4.0 0.0.3.255  eq www
  3. access-list 101 permit ip   172.16.16.0  0.0.7.255  eq www   172.16.4.0 0.0.3.255
  4. access-list 101 permit tcp 172.16.16.0  0.0.7.255  eq www   172.16.4.0 0.0.3.255  eq www
  5. access-list 101 permit tcp 172.16.16.0  0.0.7.255  eq www   172.16.4.0 0.0.3.255

The answer post should appear in a few days. As always, the answer link sits at the bottom of this page, just above where the comments begin.

 

A: Matching Port Numbers with ACLs 1

0
0

First, think of TCP headers, and the source port and destination port. Then think about the predictable port – the well-known port – and whether it will be the source or destination port. Then think about the syntax of the ACL command… and the location + direction of the ACL. Got all that? Well, you needed it to answer this latest question. Check this post for details, and the question post for the challenge!

Answer

E

 

Explanation

To answer this question, you have to piece together several facts, with no pre-set order:

First, determine the well-known port, and whether the sending host will use the well-known port as the source or destination port in the TCP header. In this case, the question stem tells us that the message to match flows from the servers (on the left) to the clients (on the right). Regardless of their location in the figure, because the server sends the message, the server uses its port number as the source port number. The sending server then uses the web clients’ (web browsers) port numbers as the destination port numbers, respectively.

Next, think about the predictable port number – the well-known port – used by the server application. The stem mentions unencrypted web traffic, which uses port 80. A reference to encrypted web traffic would mean that the connection uses SSL, which uses well-known port 443.

You also need to consider the location and direction of the ACL, but the wording of the question stem may have already told you what direction to use. The stem states that the ACL will be added to router R1, on its G0/1 port, for the input direction. Those details confirm that the ACL would match packets coming from the server going to the clients.

Because the ACL needs to match packets sent by the web servers, the ACL command must match the source port field, and not the destination port field. The destination port field will list a dynamic port number (49,152 and above) whose value is unpredictable. To match the source port, the command must include eq www or eq 80 (which IOS changes to eq www). Additionally, to match the source port field, the eq www keywords need to be before the destination address field(s) in the command, not after.

Finally, the command must use a tcp keyword, not an ip keyword. When using the ip keyword, IOS does not allow matching of any transport layer header fields – in fact, IOS would reject the two answers that use an ip keyword with syntax errors.

All those facts together give you enough information to choose the correct answer, but you might also care to think about the source and destination IP address fields for a moment. In this case, all answers used the same source address + mask combination and same destination address + mask combination. Each matches the source subnet of 172.16.16.0/21, with a destination subnet of 172.16.4.0/22.

In summary, the correct answer (E) uses the tcp keyword and includes the eq www parameters between the source and destination IP address parameters (matching the source port).

 

Sifting Through the Distractors and Common Mistakes

Questions that ask about matching messages based on TCP or UDP ports provide exam question authors plenty of opportunities to create effective distractors. This question used a few of the classic cases. To summarize some of those:

  • The command must use tcp or udp keywords, not ip, to allow the matching of port numbers.
  • You must think about the direction of the message in relation to the ACL location and direction, and ask:
    • If the ACL examines a message sent by the server, compare the source port
    • If the ACL examines a message sent to the server, compare the destination port
  • The command does not use a keyword to identify whether the port-matching parameters refer to the source or destination port. That is, you must memorize:
    • To match the source port in the message, put the port matching parameters between the source and destination address fields
    • To match the destination port in the message, put the port matching parameters after the destination address fields.

That’s it! For further exercise, if interested, change the packet direction, location/direction of the ACL, and the application, and try to determine what you would configure.


Viewing all 48 articles
Browse latest View live




Latest Images