route-map and access-list

kpjunglekpjungle Member Posts: 426
Hi,

Im seeing some funky behavior with my route-maps and access-list.

I have a route-map which i use to distribute EIGRP routes into IS-IS, I was playing around with the deny/permit options, and came across this issue. My route-map is very simple, and looks like this:

route-map MYMAP permit 10
match ip address 20

when used with this access-list(20):
10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
20 deny 192.168.70.0, wildcard bits 0.0.0.255 (1 match)
30 permit 192.168.70.0 (1 match)

the route im testing with (192.168.70.0) will get passed (permitted), even though the first deny tells it not to.

However, if i use this access-list:
10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
20 deny 192.168.70.0, wildcard bits 0.0.0.255 (2 matches)
30 permit 192.168.70.0, wildcard bits 0.0.0.255

It wont go through, even though the only difference is the wildcard mask, what gives?

I also know that when not putting in a wildcard mask, 0.0.0.0 is assumed, but I was under the impression that when a match was found, nothing else was checked, but that doesnt seem to be the case with the first access-list.

Question 2:
The way i read access-lists with route-maps, is that only stuff thats permitted in the ACL gets the route-map action applied (permit/deny), example:

I have an ACL that says deny 1.1.1.1, and my route map says DENY, then this route wont get denied, because it doesnt match in the ACL, is that correctly understood?

Please save my brain :)
Studying for CCNP (All done)

Comments

  • PlazmaPlazma Member Posts: 503
    route-map MYMAP permit 10
    match ip address 20

    when used with this access-list(20):
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (1 match)
    30 permit 192.168.70.0 (1 match)

    To me, it looks like your denying and then permitting 192.168.70.0 so naturally it will permit the route.
    I also know that when not putting in a wildcard mask, 0.0.0.0 is assumed, but I was under the impression that when a match was found, nothing else was checked, but that doesnt seem to be the case with the first access-list.

    Your thinking on the route map level.. route maps match 1 access list in your case.. and then the route map ends.. not the ACL
    Question 2:
    The way i read access-lists with route-maps, is that only stuff thats permitted in the ACL gets the route-map action applied (permit/deny), example:

    I have an ACL that says deny 1.1.1.1, and my route map says DENY, then this route wont get denied, because it doesnt match in the ACL, is that correctly understood?

    If you have a route map that is permitting , then it will permit every statement in the ACL, including all the deny statements (and don't forget the implicit deny)

    A route map denying an ACL deny will actually permit it.. because "it is acutally denying the fact you have the right to deny this route"

    Does that make any sense? If it helps, i think of them like truth tables.

    Route map permit + ACL Permit = permit
    Route map DENY + ACL Permit = Deny
    Route map Permit + ACL Deny = Deny
    Route map Deny + ACL Deny = Permit
    CCIE - COMPLETED!
  • kpjunglekpjungle Member Posts: 426
    Plazma wrote:

    Route map permit + ACL Permit = permit
    Route map DENY + ACL Permit = Deny
    Route map Permit + ACL Deny = Deny
    Route map Deny + ACL Deny = Permit

    Route-map permit + ACL permit = PERMIT
    Route-map deny + ACL permit = DENY
    Route-map permit + ACL deny = Wont get mached, goes onto any other route-map parts.
    Route-map deny + ACL deny = Wont get matched, goes onto any other route-map parts.

    Thats how i understand it..
    Studying for CCNP (All done)
  • tech-airmantech-airman Member Posts: 953
    kpjungle,
    kpjungle wrote:
    Hi,

    Im seeing some funky behavior with my route-maps and access-list.

    I have a route-map which i use to distribute EIGRP routes into IS-IS, I was playing around with the deny/permit options, and came across this issue. My route-map is very simple, and looks like this:

    route-map MYMAP permit 10
    match ip address 20


    when used with this access-list(20):
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (1 match)
    30 permit 192.168.70.0 (1 match)


    the route im testing with (192.168.70.0) will get passed (permitted), even though the first deny tells it not to.

    However, if i use this access-list:
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (2 matches)
    30 permit 192.168.70.0, wildcard bits 0.0.0.255

    It wont go through, even though the only difference is the wildcard mask, what gives?

    I also know that when not putting in a wildcard mask, 0.0.0.0 is assumed, but I was under the impression that when a match was found, nothing else was checked, but that doesnt seem to be the case with the first access-list.

    Using the above bolded access lists, which network and/or networks would be matched by access list 10?
    kpjungle wrote:
    Question 2:
    The way i read access-lists with route-maps, is that only stuff thats permitted in the ACL gets the route-map action applied (permit/deny), example:

    I have an ACL that says deny 1.1.1.1, and my route map says DENY, then this route wont get denied, because it doesnt match in the ACL, is that correctly understood?

    Please save my brain :)

    What is the exact access-list statement used to deny 1.1.1.1?
  • kpjunglekpjungle Member Posts: 426
    kpjungle,
    kpjungle wrote:
    Hi,

    Im seeing some funky behavior with my route-maps and access-list.

    I have a route-map which i use to distribute EIGRP routes into IS-IS, I was playing around with the deny/permit options, and came across this issue. My route-map is very simple, and looks like this:

    route-map MYMAP permit 10
    match ip address 20


    when used with this access-list(20):
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (1 match)
    30 permit 192.168.70.0 (1 match)


    the route im testing with (192.168.70.0) will get passed (permitted), even though the first deny tells it not to.

    However, if i use this access-list:
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (2 matches)
    30 permit 192.168.70.0, wildcard bits 0.0.0.255

    It wont go through, even though the only difference is the wildcard mask, what gives?

    I also know that when not putting in a wildcard mask, 0.0.0.0 is assumed, but I was under the impression that when a match was found, nothing else was checked, but that doesnt seem to be the case with the first access-list.

    Using the above bolded access lists, which network and/or networks would be matched by access list 10?
    kpjungle wrote:
    Question 2:
    The way i read access-lists with route-maps, is that only stuff thats permitted in the ACL gets the route-map action applied (permit/deny), example:

    I have an ACL that says deny 1.1.1.1, and my route map says DENY, then this route wont get denied, because it doesnt match in the ACL, is that correctly understood?

    Please save my brain :)

    What is the exact access-list statement used to deny 1.1.1.1?

    The first one, regarding the bolded access-list, its all one access-list, the numbers are just the sequence numbers given by the access-list.

    Number 2, lets say:

    route-map TEST deny 10
    match ip add 20

    access-list 20 deny 1.1.1.0 0.0.0.255

    My logic (as of right now anyways :)) is that only permits in the ACL will give a match in the route-map match statement.
    Studying for CCNP (All done)
  • PlazmaPlazma Member Posts: 503
    kpjungle wrote:
    Plazma wrote:

    Route map permit + ACL Permit = permit
    Route map DENY + ACL Permit = Deny
    Route map Permit + ACL Deny = Deny
    Route map Deny + ACL Deny = Permit

    Route-map permit + ACL permit = PERMIT
    Route-map deny + ACL permit = DENY
    Route-map permit + ACL deny = Wont get mached, goes onto any other route-map parts.
    Route-map deny + ACL deny = Wont get matched, goes onto any other route-map parts.

    Thats how i understand it..

    Correct me if im wrong (someone) but I don't think your thinking about it correctly. Route maps work just like an ACL until something is matched and then they "break" out of the route map and continue processing routing information. So if a route map matches on an ACL, it checks the ENTIRE ACL and then once the ACL is finished being 'checked' the route map breaks. You are working with 2 different levels here.
    CCIE - COMPLETED!
  • tech-airmantech-airman Member Posts: 953
    kpjungle,
    kpjungle wrote:
    kpjungle,
    kpjungle wrote:
    Hi,

    Im seeing some funky behavior with my route-maps and access-list.

    I have a route-map which i use to distribute EIGRP routes into IS-IS, I was playing around with the deny/permit options, and came across this issue. My route-map is very simple, and looks like this:

    route-map MYMAP permit 10
    match ip address 20


    when used with this access-list(20):
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (1 match)
    30 permit 192.168.70.0 (1 match)


    the route im testing with (192.168.70.0) will get passed (permitted), even though the first deny tells it not to.

    However, if i use this access-list:
    10 deny 172.16.1.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny 192.168.70.0, wildcard bits 0.0.0.255 (2 matches)
    30 permit 192.168.70.0, wildcard bits 0.0.0.255

    It wont go through, even though the only difference is the wildcard mask, what gives?

    I also know that when not putting in a wildcard mask, 0.0.0.0 is assumed, but I was under the impression that when a match was found, nothing else was checked, but that doesnt seem to be the case with the first access-list.

    Using the above bolded access lists, which network and/or networks would be matched by access list 10?
    kpjungle wrote:
    Question 2:
    The way i read access-lists with route-maps, is that only stuff thats permitted in the ACL gets the route-map action applied (permit/deny), example:

    I have an ACL that says deny 1.1.1.1, and my route map says DENY, then this route wont get denied, because it doesnt match in the ACL, is that correctly understood?

    Please save my brain :)

    What is the exact access-list statement used to deny 1.1.1.1?

    The first one, regarding the bolded access-list, its all one access-list, the numbers are just the sequence numbers given by the access-list.

    In that case, which network and/or networks would be matched by access list 20?
    kpjungle wrote:
    Number 2, lets say:

    route-map TEST deny 10
    match ip add 20

    access-list 20 deny 1.1.1.0 0.0.0.255

    My logic (as of right now anyways :)) is that only permits in the ACL will give a match in the route-map match statement.

    Unfortunately, that logic is incorrect. Remember that when you say...
    access-list 20 deny 1.1.1.0 0.0.0.255
    

    ...you are actually saying...
    access-list 20 deny 1.1.1.0 0.0.0.255
    [access-list 20 deny any]
    

    So since you're effectively using two deny statements without any permit statements, how is anything permitted by access-list 20?
  • gojericho0gojericho0 Member Posts: 1,059 ■■■□□□□□□□
    have you tried to lab it at all?

    You wouldn't (or shouldn't) see this in a live environment though :)
  • kpjunglekpjungle Member Posts: 426
    Let me try and clarify here, cause I think i might not have stated exactly what my thinking really was.

    Example:

    R1 <-- EIGRP --> R2 <-- OSPF --> R3

    R2 is redistributing EIGRP routes into OSPF.
    The EIGRP routes on R1 is:
    10.0.10.0
    10.0.20.0
    10.0.30.0

    Without a route-map i get all routes on R3:
    O E2    10.0.10.0 [110/20] via 192.168.23.2, 00:00:18, Serial0/0
    O E2    10.0.30.0 [110/20] via 192.168.23.2, 00:00:23, Serial0/0
    O E2    10.0.20.0 [110/20] via 192.168.23.2, 00:00:23, Serial0/0
    

    So now i enter in this ACL:
    R2#sh access-list
    Standard IP access list 20
        10 deny   10.0.10.0, wildcard bits 0.0.0.255 (3 matches)
    

    Along with this route-map:
    R2#sh route-map
    route-map TEST, deny, sequence 10
      Match clauses:
        ip address (access-lists): 20
      Set clauses:
      Policy routing matches: 0 packets, 0 bytes
    route-map TEST, permit, sequence 20
      Match clauses:
      Set clauses:
        metric 4000
      Policy routing matches: 0 packets, 0 bytes
    

    Result on R3:
    O E2    10.0.10.0 [110/4000] via 192.168.23.2, 00:00:03, Serial0/0
    O E2    10.0.30.0 [110/4000] via 192.168.23.2, 00:00:03, Serial0/0
    O E2    10.0.20.0 [110/4000] via 192.168.23.2, 00:00:03, Serial0/0
    

    As shown, no match is made in the first statement, so the route-map is not "breaked", and the route is passed onto statement 2, which sets the metric to 4000.

    So my logic states: I dont make a match because the ACL (which is stupid i know, but to prove concept) is DENY in the ACL.
    So, Route-Map DENY + ACL DENY = no match, go onto next route-map statement.

    To prove the Route-Map PERMIT + ACL DENY = no match, go onto next route-map statement, i modify the route-map:
    R2#sh route-map
    route-map TEST, deny, sequence 10
      Match clauses:
        ip address (access-lists): 20
      Set clauses:
      Policy routing matches: 0 packets, 0 bytes
    route-map TEST, permit, sequence 15
      Match clauses:
        ip address (access-lists): 20
      Set clauses:
        metric 10000
      Policy routing matches: 0 packets, 0 bytes
    route-map TEST, permit, sequence 20
      Match clauses:
      Set clauses:
        metric 4000
      Policy routing matches: 0 packets, 0 bytes
    

    The ACL is still:
    R2#sh access-list
    Standard IP access list 20
        10 deny   10.0.10.0, wildcard bits 0.0.0.255 (3 matches)
    

    The result is still:
    O E2    10.0.10.0 [110/4000] via 192.168.23.2, 00:00:18, Serial0/0
    O E2    10.0.30.0 [110/4000] via 192.168.23.2, 00:00:18, Serial0/0
    O E2    10.0.20.0 [110/4000] via 192.168.23.2, 00:00:18, Serial0/0
    

    So Route-map PERMIT + ACL DENY = no match, go onto next route-map statement.

    Concerning:
    Route-map permit + ACL permit = PERMIT
    Route-map deny + ACL permit = DENY

    We are in agreement since the ACL permits, and then makes a match condition true.

    Tech-airman,

    Yes, but in the example:
    route-map TEST deny 10
    match ip add 20
    
    access-list 20 deny 1.1.1.0 0.0.0.255 
    

    my point was that the MATCH statement in the route-map wont be TRUE unless a PERMIT is in the ACL.

    Sorry for my very long post :)

    Gojericho0, yeah, on my lab number 6 now on this :) and i probably would not see it live, im just brain-numbing myself again, probably putting too much thought into something i shouldnt be, just got a little puzzled by Jeremy in the CBT nuggets which said "a deny + a deny makes a true"...
    Studying for CCNP (All done)
  • tech-airmantech-airman Member Posts: 953
    kpjungle,
    kpjungle wrote:
    Let me try and clarify here, cause I think i might not have stated exactly what my thinking really was.

    Example:

    R1 <-- EIGRP --> R2 <-- OSPF --> R3

    R2 is redistributing EIGRP routes into OSPF.
    The EIGRP routes on R1 is:
    10.0.10.0
    10.0.20.0
    10.0.30.0

    Without a route-map i get all routes on R3:
    O E2    10.0.10.0 [110/20] via 192.168.23.2, 00:00:18, Serial0/0
    O E2    10.0.30.0 [110/20] via 192.168.23.2, 00:00:23, Serial0/0
    O E2    10.0.20.0 [110/20] via 192.168.23.2, 00:00:23, Serial0/0
    

    So now i enter in this ACL:
    R2#sh access-list
    Standard IP access list 20
        10 deny   10.0.10.0, wildcard bits 0.0.0.255 (3 matches)
    

    So when you apply access list 20 to an EIGRP update from the 10.0.10.0 network, what comes out? Think systematically which is...
            Input                                Process                  Output
    {EIGRP update from 10.0.10.0 network}---->[Access List 20]----->[What comes out?]
    
    kpjungle wrote:
    Along with this route-map:
    R2#sh route-map
    route-map TEST, deny, sequence 10
      Match clauses:
        ip address (access-lists): 20
      Set clauses:
      Policy routing matches: 0 packets, 0 bytes
    route-map TEST, permit, sequence 20
      Match clauses:
      Set clauses:
        metric 4000
      Policy routing matches: 0 packets, 0 bytes
    

    So, let's make this part 2 of the above question which was part 1. So now that you figured out what came OUT from the access list 20, would "Match clauses: ip address (access-lists): 20" match anything? If so, what would it match?
    kpjungle wrote:
    Result on R3:
    O E2    10.0.10.0 [110/4000] via 192.168.23.2, 00:00:03, Serial0/0
    O E2    10.0.30.0 [110/4000] via 192.168.23.2, 00:00:03, Serial0/0
    O E2    10.0.20.0 [110/4000] via 192.168.23.2, 00:00:03, Serial0/0
    

    Based on the above, which route-map statement was executed:
    1. route-map statement 10?
    2. route-map statement 20?
    3. route-map statement other?
    kpjungle wrote:
    As shown, no match is made in the first statement, so the route-map is not "breaked", and the route is passed onto statement 2, which sets the metric to 4000.

    So my logic states: I dont make a match because the ACL (which is stupid i know, but to prove concept) is DENY in the ACL.
    So, Route-Map DENY + ACL DENY = no match, go onto next route-map statement.

    To prove the Route-Map PERMIT + ACL DENY = no match, go onto next route-map statement, i modify the route-map:
    R2#sh route-map
    route-map TEST, deny, sequence 10
      Match clauses:
        ip address (access-lists): 20
      Set clauses:
      Policy routing matches: 0 packets, 0 bytes
    route-map TEST, permit, sequence 15
      Match clauses:
        ip address (access-lists): 20
      Set clauses:
        metric 10000
      Policy routing matches: 0 packets, 0 bytes
    route-map TEST, permit, sequence 20
      Match clauses:
      Set clauses:
        metric 4000
      Policy routing matches: 0 packets, 0 bytes
    

    The ACL is still:
    R2#sh access-list
    Standard IP access list 20
        10 deny   10.0.10.0, wildcard bits 0.0.0.255 (3 matches)
    

    The result is still:
    O E2    10.0.10.0 [110/4000] via 192.168.23.2, 00:00:18, Serial0/0
    O E2    10.0.30.0 [110/4000] via 192.168.23.2, 00:00:18, Serial0/0
    O E2    10.0.20.0 [110/4000] via 192.168.23.2, 00:00:18, Serial0/0
    

    So Route-map PERMIT + ACL DENY = no match, go onto next route-map statement.

    Concerning:
    Route-map permit + ACL permit = PERMIT
    Route-map deny + ACL permit = DENY

    We are in agreement since the ACL permits, and then makes a match condition true.

    Tech-airman,

    Yes, but in the example:
    route-map TEST deny 10
    match ip add 20
    
    access-list 20 deny 1.1.1.0 0.0.0.255 
    

    my point was that the MATCH statement in the route-map wont be TRUE unless a PERMIT is in the ACL.

    If that was your point, then why does your access-list 20 have deny instead of permit?
    kpjungle wrote:
    Sorry for my very long post :)

    Gojericho0, yeah, on my lab number 6 now on this :) and i probably would not see it live, im just brain-numbing myself again, probably putting too much thought into something i shouldnt be, just got a little puzzled by Jeremy in the CBT Nuggets which said "a deny + a deny makes a true"...
  • kpjunglekpjungle Member Posts: 426
    kpjungle,

    If that was your point, then why does your access-list 20 have deny instead of permit?

    Simply to test out what jeremy in CBT nuggets said "two negatives make a positive", which it doesnt.
    Studying for CCNP (All done)
  • tech-airmantech-airman Member Posts: 953
    kpjungle wrote:
    kpjungle,

    If that was your point, then why does your access-list 20 have deny instead of permit?

    Simply to test out what jeremy in CBT Nuggets said "two negatives make a positive", which it doesnt.

    kpjungle,

    When you mention "CBT Nuggets" are you talking about the Free Videos? If so, which video?

    Source:
    1. Free Videos at cbtnuggets.com - http://www.cbtnuggets.com/webapp/videos
  • kpjunglekpjungle Member Posts: 426
    kpjungle wrote:
    kpjungle,

    If that was your point, then why does your access-list 20 have deny instead of permit?

    Simply to test out what jeremy in <a href=http://www.cbtnuggets.com/techexams target=”_blank”>CBT Nuggets</a> said "two negatives make a positive", which it doesnt.

    kpjungle,

    When you mention "CBT Nuggets" are you talking about the Free Videos? If so, which video?

    Source:
    1. Free Videos at cbtnuggets.com - http://www.cbtnuggets.com/webapp/videos

    No, my work purchased the CCNP set a while back.
    Studying for CCNP (All done)
Sign In or Register to comment.