Odom's ICND2 Standard Access List Example 6-5

I may be going crazy as I keep looking at this example in the Cisco Press ICND2 book and don't understand the reasoning.

Basically for standard access lists, you want to put it as close as you can to the destination address right? For this example (if I could put it into words or get the diagram on here, I would), it appears he is using the router closest to the source IP address for both the access lists.

This, in turn, makes it so that an IP address can't even get outside it's own network. This will probably only make sense to owners of the book, but if you anyone can enlighten me I would very much appreciate it. Thanks!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

hiddenknight821

descender421 wrote: »

I may be going crazy as I keep looking at this example in the Cisco Press ICND2 book and don't understand the reasoning.

Basically for standard access lists, you want to put it as close as you can to the destination address right? For this example (if I could put it into words or get the diagram on here, I would), it appears he is using the router closest to the source IP address for both the access lists.

This, in turn, makes it so that an IP address can't even get outside it's own network. This will probably only make sense to owners of the book, but if you anyone can enlighten me I would very much appreciate it. Thanks!

I know this sounds confusing, but if you kept reading to the part where they talked about extended access list, then you will see that they also made a generic rule on where to put the ACL on, which is the opposite of the standard ACL rule. For the extended list, you would have to place the list closest to the source.

Let's say you have a triangular topology with three routers like this:

Remember, Standard Access List will only filter incoming source address. You will not be able to explicitly apply a statement that will filter packets using the destination address since that is only available on the extended access-list.

I want to make sure that the a host with ip address (10.0.1.1) on R3's Fa0/0 subnet (10.0.1.0 /24) do not communicate with hosts on R1's Fa0/0 subnet (10.0.2.0/24).

Would it be wise to place the following statement on R3's S0/0/0 interface?

R1(config)#access-list 1 deny 10.0.1.1 0.0.0.0
R1(config)#access-list 1 permit any
R1(config)#interface s0/0/0
R1(config-if)#ip access-group 1 out

If you think about it, let's say the serial link between R1 and R3 is down, will the above statement works? No. R3 still have a route to R1 through its s0/0/1 interface. It logically make sense if you implement the above statement on R1's Fa0/0 interface, which is the closest router interface to the destination. The statement will be able to filter the packets regardless if one of the adjacent serial links on R1 is down.

By the way, you can also use access-list 1 deny host 10.0.1.1 instead of the first statement. Either way will work.

descender421

I totally understand that, but that's why I think I'm going crazy on his example. By the way, I had the number wrong. The one I'm looking at is his Standard IP ACL: Example 2.

The way I understand standard access lists is the way you put it there. The correct way is to put it as close as you can to the destination. In his example, he is making the access list applicable to the closest router instead of the one closest to the destination.

Or am I still way off here? Thanks for the example by the way.

hiddenknight821

descender421 wrote: »

In his example, he is making the access list applicable to the closest router instead of the one closest to the destination.

Or am I still way off here? Thanks for the example by the way.

It should be the latter. You apply the ACL rule closest to the destination. How would you know which router is closer to you if you are not standing near any of them?

It has nothing to do with whether you are physically close to the router or not. Remember, packets operate on layer 3. Thus they use IP addresses. So, you should only be concern with source/destination IP address when making ACL rules. I should also include sockets for extended ACL.

descender421

hiddenknight821 wrote: »

It should be the latter. You apply the ACL rule closest to the destination. How would you know which router is closer to you if you are not standing near any of them? It has nothing to do with whether you are physically close to the router or not. Remember, packets operate on layer 3. Thus they use IP addresses. So, you should only be concern with source/destination IP address when making ACL rules. I should also include sockets for extended ACL.

Sorry, by closer I should have said default gateway. So would this still be correct? I'm looking for an entry on the errata but there isn't one, so I'm guessing he's correct. But still doesn't make much sense.

hiddenknight821

descender421 wrote: »

Sorry, by closer I should have said default gateway. So would this still be correct? I'm looking for an entry on the errata but there isn't one, so I'm guessing he's correct. But still doesn't make much sense.

ip access-group 1 out

See the command line above? You really need to keep reading until you read the entire chapter. Once you're done, you can come back and we will clear up the cloudy thoughts you had.

When using the statement above, it should be apply on an interface. There is a rule. You can only have one ACL per interface, per ROUTABLE PROTOCOL per direction. What this means is that you can have many standard and extended ACLs saved on a router, but not all of them will be in used. You may create another ACL as a back-up in case the new ACL you recently implemented doesn't work.

So, from long list of ACL rules (assuming you created a bunch of them), you will see them in your running-config. Like I said, not all of them will be in used. To clarify the ACL implementation rules underlined above, you can only apply one ACL rules composed of multiple deny/permit statements for one direction (in/out). When I said ROUTABLE protocol (or you can say routed), I meant IP, IPX, AppleTalk, and so on. Very often, you will only see IP. You may not see the IP in the following command line: access-list 1 deny 10.0.1.1 0.0.0.0 but it's implied. The 1 in the command line is within the range, 1-99 and 1300-1999 for IP. That's why I encourage you to keep on reading even though it's confusing.

So back to the point I'm trying to make here. You do not need to be concerned with the default gateway. You just need to be concerned with which router should you implement the ACL on, then once you pick the appropriate router, you would need to know which interface to apply the ACL on. That's the trick part. If we go back to the first command at the top, we need to break it down to better understand how the filtering works here. Back to my example in my previous post, we want to filter IP address 10.0.1.1, and we did that on R1. But the question here is why apply it on Fa0/0 interface? Well, with Standard ACL, you don't have that much choice, but Extended ACL will allow more options and flexibility. If we were to use the extended ACL, I can either use R3's Fa0/0 or s0/0/0 (assuming that there is no serial link between R2 and R3). I know I said R3, because the extended ACL implementation location rule is the opposite of the standard rule.

What you need to understand is how direction works.

A) If you are trying to filter traffic coming in R1 s0/0/1 interface:

incoming traffic --> |int s0/0/1 (R1) int f0/0| --> outgoing traffic -->

Otherwise, if you are trying to filter traffic coming in R1 Fa0/0 interface:

incoming traffic --> |int f0/0 (R1) int s0/0/1| --> outgoing traffic -->

I hope you will find this helpful. See the interfaces I labeled on the router? The interfaces with the ip access-group command are responsible to filter the packet. In our example we discussed earlier, we wanted to make sure that host with 10.0.1.1 will go nowhere nears R1's Fa0/0 subnet. So, we placed it on the Fa0/0 interface using the out command like I display on Line B above. It wouldn't make sense if we use the in command, because we would be attempting to filter incoming IP packet with 10.0.1.1, which is nonexistent on R1 subnet. We always have to be consistence with the implied direction in the ACL rule statements. That's why the implementation rule I underlined earlier is very important.

I hope this helps clear up everything, but if you are still unsure, you really need to keep pushing on your reading and try to understand it. That's why some find Odom's book not too difficult but intermediate reading unlike Lammle.

descender421

I understand the reasoning with what you're saying and agree with it. I also have read through the chapter 2 times. However, in the example from the book, Odom is saying something else. Basically, if he were using your diagram there, he would claim the best place to put the standard access list would be on R3's Fa0/0 subnet and to leave it as outbound.

With this, it would make it to where that host in that subnet couldn't even communicate with anyone outside of its own subnet. Which yes, it is successful in completing the objective, but to me that goes overboard.

I wish I could scan the example so I could put it on here so then it might help out more. Thanks for helping out btw.

hiddenknight821

descender421 wrote: »

I understand the reasoning with what you're saying and agree with it. I also have read through the chapter 2 times. However, in the example from the book, Odom is saying something else. Basically, if he were using your diagram there, he would claim the best place to put the standard access list would be on R3's Fa0/0 subnet and to leave it as outbound.

With this, it would make it to where that host in that subnet couldn't even communicate with anyone outside of its own subnet. Which yes, it is successful in completing the objective, but to me that goes overboard.

I wish I could scan the example so I could put it on here so then it might help out more. Thanks for helping out btw.

Okay, I got the Example 6-5 for Yosemite router from the book here.

interface serial 0
ip access-group 3 out
!
interface serial 1
ip access-group 3 out
!
interface ethernet 0
ip access-group 4 out
!
access-list 3 remark meets criteria 1
access-list 3 deny host 10.1.2.1
access-list 3 permit any
!
access-list 4 remark meets criteria 2
access-list 4 deny 10.1.3.0 0.0.0.255
access-list 4 permit any

And for your convenience, I used the topology in Figure 6-3 from book:

attachment.php?attachmentid=1232&stc=1&d=1315105837

So, let's "start over" again and tell me where you are confused with this?

Odom_ICND2_Figure_6_3.jpg

hiddenknight821

descender421 wrote: »

I may be going crazy as I keep looking at this example in the Cisco Press ICND2 book and don't understand the reasoning.

Basically for standard access lists, you want to put it as close as you can to the destination address right? For this example (if I could put it into words or get the diagram on here, I would), it appears he is using the router closest to the source IP address for both the access lists.

This, in turn, makes it so that an IP address can't even get outside it's own network. This will probably only make sense to owners of the book, but if you anyone can enlighten me I would very much appreciate it. Thanks!

After reviewing the example from the book again, I believe I finally understand where you got caught off guard. You were wondering why Odom's didn't follow his own "golden" implementation rule. Well, I can tell you the configuration he implemented would work, but he didn't follow his rule exactly as he would probably expect us to implement the access-list 3 ACL rule on Albuquerque's E0 interface using the ip access-group 3 out command. No need to implement this on the other interfaces. Damn this sneaky bastard.

You ought to send him an email and ask him why he dishonored his own rule. Most of us believe that most people would stand by their own principles.

pham0329

It's probably an error. If Seville loses it's link to Albuquerque, the routing protocol would reconverge and it would use its s1 interface to reach Albuquerque. With his implementation, this wouldn't be possible because his ACL would block everything. The same applies to Yosemite if it loses its connection to Seville

descender421

hiddenknight821 wrote: »

After reviewing the example from the book again, I believe I finally understand where you got caught off guard. You were wondering why Odom's didn't follow his own "golden" implementation rule. Well, I can tell you the configuration he implemented would work, but he didn't follow his rule exactly as he would probably expect us to implement the access-list 3 ACL rule on Albuquerque's E0 interface using the ip access-group 3 out command. No need to implement this on the other interfaces. Damn this sneaky bastard. You ought to send him an email and ask him why he dishonored his own rule. Most of us believe that most people would stand by their own principles.

Lol yes, this. I mean I do get that what he is doing there would work, but it just confused me as to why he didn't follow the rule of putting a standard ACL closest to the destination. Thanks for your time into this again.

hiddenknight821

pham0329 wrote: »

It's probably an error. If Seville loses it's link to Albuquerque, the routing protocol would reconverge and it would use its s1 interface to reach Albuquerque. With his implementation, this wouldn't be possible because his ACL would block everything. The same applies to Yosemite if it loses its connection to Seville

To be honest with you, I don't see how it's an error. Did you read the pages on this? To me it makes perfect sense. What I said was not exactly an indication of error. It's merely something the author overlooked. His configuration would work for sure 100%, but my suggestion would work just as good, which is what he "meant to use" in the first place.

pham0329

hiddenknight821 wrote: »

To be honest with you, I don't see how it's an error. Did you read the pages on this? To me it makes perfect sense. What I said was not exactly an indication of error. It's merely something the author overlooked. His configuration would work for sure 100%, but my suggestion would work just as good, which is what he "meant to use" in the first place.

I'm not really sure what you're trying to say. If your configuration is what he really "meant" to use, how is it not an error on his part? I didn't mean error as in he made a syntax error, I meant his configurations are wrong. Even though his config would work, the application of it is wrong. I didn't really reread the section on standard ACL, I just read the example and its requirements. The three requirements were

Sam is not allowed access to Bugs or Daffy
Hosts on Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet
All other combinations are allowed

The third objective is to allow any other combination, which is kind of dumb because even if you allow Sam to access Elmer, if Elmer is blocked from replying, you're essential blocking the communication between those two. But anyhow, any other combinations are allowed and if the WAN link between Yosemite and Seville goes down, Yosemite would have to use Albuquerque to get to Seville, and that's not possible with the ACL he configured. If Seville loses its WAN to Albuquerque, it needs to use Yosemite to get to Albuquerque, and that's also not possible with his configuration. The objective of those requirements are to block access to the LAN connected to the routers, not to the routers themselves.

hiddenknight821

pham0329 wrote: »

I'm not really sure what you're trying to say. If your configuration is what he really "meant" to use, how is it not an error on his part? I didn't mean error as in he made a syntax error, I meant his configurations are wrong. Even though his config would work, the application of it is wrong. I didn't really reread the section on standard ACL, I just read the example and its requirements. The three requirements were
Sam is not allowed access to Bugs or Daffy

Hosts on Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet

All other combinations are allowed

The third objective is to allow any other combination, which is kind of dumb because even if you allow Sam to access Elmer, if Elmer is blocked from replying, you're essential blocking the communication between those two. But anyhow, any other combinations are allowed and if the WAN link between Yosemite and Seville goes down, Yosemite would have to use Albuquerque to get to Seville, and that's not possible with the ACL he configured. If Seville loses its WAN to Albuquerque, it needs to use Yosemite to get to Albuquerque, and that's also not possible with his configuration. The objective of those requirements are to block access to the LAN connected to the routers, not to the routers themselves.

:facepalm: +1 goes to you. Why didn't I see this coming. You're absolutely right! I didn't bother checking if other possibilities work. I guess I need to practice troubleshooting more from objective observation. This isn't probably an error. THIS IS AN ERROR. Period.

Don't give anyone the benefit of doubt if you're so sure. Even if it's Wendell Odom!

wave

The part of this question (page 252) that caught me out was the rule that "Hosts on the Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet"

The rule was access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255

Which is applied to the E0 on Yosemite....It seemed kind of strange but then replicated it with my lab and the rule worked just as Odom said it would.

Standard ACL - placed close to the destination
Extended ACL - placed close to the source

descender421

wave wrote: »

The part of this question (page 252) that caught me out was the rule that "Hosts on the Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet"

The rule was access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255

Which is applied to the E0 on Yosemite....It seemed kind of strange but then replicated it with my lab and the rule worked just as Odom said it would.

Standard ACL - placed close to the destination
Extended ACL - placed close to the source

That one at least makes sense to me as it lets the third rule of "All other combinations allowed" to still work.

The standard example though, not so much.

hiddenknight821

wave wrote: »

The part of this question (page 252) that caught me out was the rule that "Hosts on the Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet"

It makes sense. Although, I have to tell you that rule is not phrase correctly, but it automatically implies that hosts on Yosemite Ethernet are not allowed access to hosts on Seville Ethernet. You may have to flip the sentence to make complete sense out of it. The one that we were working on didn't make more sense than this one.

wave

Yeah I figure it out, but initially I was thinking "what the?!"...there certainly are a few wording issues in that book, but I still like it. I'm feeling confident about acl's...I'm labbing OSPF now