Route-maps & redistribution LAB -- one simple question for you

[anestis.iliadis]

Hello everyone,

I just wanted to ask for your help to undersstand the following route-map behaviour.

I'm doing some redistribution labs and I have the following scenario.

{ (EIGRP 100) R4 ----- [ R2 } ------ R1 (OSPF) ]

R2 sits between EIGRP and OSPF AS.

R4 has the following subnets (loopbacks) with the following requirements when redistributed into OSPF:

R4 LOOPBACKS

10.4.0.0/24 -- seed 100 - tag 10

10.4.2.0/24 -- seed 200 - tag 20

10.4.4.0/24 -- deny

All other subnets: seed metric 300 - tag 30

Where I'm having problems is with the requirement that 10.4.4.0 should be denied from crossing over to OSPF.

Here's my configuration for R2

I've configured the following ACLs:

access-list 1 permit 10.4.0.0 0.0.0.255

access-list 2 permit 10.4.2.0 0.0.0.255

access-list 3 deny 10.4.4.0 0.0.0.255 <---

put them in a route-map EIGRP-TO-OSPF:

route-map EIGRP-TO-OSPF permit 10

match ip address 1

set metric 100

set tag 10

route-map EIGRP-TO-OSPF permit 20

match ip address 2

set metric 200

set tag 20

route-map EIGRP-TO-OSPF permit 30 <-------- permitting because ACL has a DENY statement

match ip address 3                  <----

route-map EIGRP-TO-OSPF permit 40

set metric 300      <--- (no match statement to select all others)

set tag 30

and then under R2, router ospf 1:

redistribute eigrp 100 subnets route-map EIGRP-TO-OSPF

So far so good!

However, requirement for route 10.4.4.0 to be denied doesn't work! It passes through to R1 and I'm trying to figure out why since this is an exercise for me to understand route-maps and redistribution.

The way around to solve it was to change the ACL 3 and route-map to:

access-list 3 permit 10.4.4.0 0.0.0.255

route-map EIGRP-TO-OSPF deny 30

match ip address 3

essentially what I've noticed is that with the deny statement in the ACL, 10.4.4.0 passes through and has a tag of 30 so I guess it's caught by the match all of the route-map seq 40. I've tried to rearrange the statement and put it before last but it didn't change anything.

On the other hand when the deny is at the route map seq 30, then 10.4.4.0 isn't caught by the seq 40 and works as it should... very confusing!

so my question is why does it work when denied at the route map but not when denied at the ACL ?

thank you!

Anestis

[Giuseppe Larosa · Accepted solution]

Hello Anestis,

>> so my question is why does it work when denied at the route map but not when denied at the ACL ?

Because, this is the way it is implemented in IOS: the route-map logic provided by permit or deny at route-map clause (block) is the one that counts. The IP ACLs are invoked to provide a match condition and a deny in the ACL is simply a not match.

The deny in route-map clause provides a true filtering action so an IP prefix that matches an ACL in a route-,map clause with a deny action is actually filtered. A prefix that is denied in the IP ACL is simply a not match in the route-map clause.

Hope to help

Giuseppe

[anestis.iliadis]

Hi Guiseppe and thank you for your answer!

The reason I asked this question was because the lab comes from cbt nuggets and in the training video Jeremy Ciaora (the guy in the video) says that when we have similar scenarios one can either deny at the ACL level or at the route-map level and the best practice is to deny at the ACL so that we can be more consistent in using all permit statements at the route-maps.

So if I'm understanding this right, you are saying that the ACL is invoked to prove a match condition. So basically, whatever is matched by the ACL is "selected" meaning that in plain english I can think of the ip ACL inside the match clause of the route-map as a selector... meaning that it will NEVER deny a route, it will only deny something to be matched (am I right so far? BTW this is how I had the whole thing in my mind until I watched the aforementioned video saying that by using deny in the ACL and permit in the route-map essentially we can

"permit the route to be denied".

So then I guess the only reason to use an ACL which denies something inside a permit route-map would be for a case where we would need to select X Y Z but not whatever is in the deny ACL.

again, thanks so much for the reply

Anestis

[Giuseppe Larosa]

Hello Anestesis,

the suggestion in case of doubts is to use multiple documents and sources of information.

Search, compare and make a choice of the better version for each aspect that explains the results of tests.

Be prepared to change idea over time!

As an example of good ufficial documentation you can use  is the following

http://www.informit.com/library/content.aspx?b=CCIE_Practical_Studies_II&seqNum=19

>> If that's the case if the ACL acts simply as a "selection" and cannot deny anything, I can't think of a case where we would ever need a deny ip ACL inside a route-map like how I used it initially?

There may be cases where you want to treat a set of routes in a certain way with few exceptions, so the deny statement in the IP ACL ( or ip prefix-list) can still be used for these cases, where some specific routes have to be treated differently

Example:

access-list 11 deny 172.16.25.0 0.0.0.255

access-list 11 permit 172.16.0.0 0.0.255.255

the IP subnet 172.16.25.0/24 would not be a ,match, but any other subnet in 172.16./16 would be.

route-map TEST permit 10

match ip address 11

set tag 200

! other parts of the route-map

Hope to help

Giuseppe

[anestis.iliadis]

Thank you for your insightful answers and pointing me to the right direction. I get how it works now!

Also the ccnp route book from wendell odom nails it in the head

The match command can reference an ACL or prefix list, but doing so does introduce the
possibility of confusion. The confusing part is that the decision to filter a route or allow
the route through is based on the deny or permit in the route-map command, and not the
deny or permit in the ACL or prefix list. When referencing an ACL or prefix list from a
route map, the ACL or prefix list simply matches all routes permitted by the ACL or prefix
list. Routes that are denied by the ACL or prefix list simply do not match that match com-
mand’s logic, making IOS then consider the next route-map command.
The following list summarizes the key points about route map logic when used for redis-
[...]
And once a particular route has been
matched and determined to be either filtered (deny) or allowed to pass (permit), even if
more route-map commands exist later in the list, IOS stops processing the route-map for
that route.

thank you,

anestis