route-map and access-list

kpjungle

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

Plazma

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

kpjungle

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..

tech-airman

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?

kpjungle

tech-airman 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.

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.

Plazma

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.

tech-airman

kpjungle,

kpjungle wrote:

tech-airman 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?

gojericho0

have you tried to lab it at all?

You wouldn't (or shouldn't) see this in a live environment though

kpjungle

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"...

tech-airman

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"...

kpjungle

tech-airman 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.

tech-airman

kpjungle wrote:

tech-airman 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

kpjungle

tech-airman wrote:

kpjungle wrote:

tech-airman 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.