NOTE: These lines are an integration of this article read it before moving on.
When a route-map references an ACL (standard or extended, and this is true for a prefix-list too) its permit/deny rules don’t determine if the routes are accepted or not, the permit/deny rules of ACL will determine if routes are to be evaluated against the route-map statement in which are defined. If the route will be accepted or discarded will be always determined by the ACTION (permit or deny) defined in the ROUTE-MAP.
A route-map is a complex construct made of:
– a NAME
– one or more statements defining the action (permit/deny)
– matching conditions inside each statements
– set rules to apply changes to the matched traffic
route-map TEST [permit|deny] (seq-number-1)
match (condition type 1) [a OR b OR c…]
AND
match (condition type 2) [j OR k OR l…]
AND
match (condition type 3) [t OR u OR v…]
set (modify matched traffic)
route-map TEST [permit|deny] (seq-number-2)
match (condition type 1) [d OR e OR f…]
AND
match (condition type 2) [m OR n OR o…]
AND
match (condition type 3) [x OR y OR z…]
set (modify matched traffic)
route-map TEST deny (seq-number-3) ==> IMPLICT DENY STATEMENT
Let’s see how this fits in case we use a route-map to reference an ACL. To keep things simple I don’t want to modify routes’ attributes so don’t worry about set command, also I will reference only one ACL so route-map will be like:
route-map TEST [permit|deny] (seq-number-1)
match ip address [ACL-Name]
route-map TEST deny (seq-number-2) ==> IMPLICIT DENY STATEMENT
I define an ACL
Routes-Server#show run | s ip access
ip access-list extended INJECTOR
deny ip 10.0.0.0 0.255.255.255 any
permit ip 0.0.0.0 31.255.255.255 any
route-map TEST permit 10
match ip address INJECTOR
The logic is:
– deny –> not consider this set of routes –> bring them to the next statement
– permit –> the routes permitted match the statement –> action of route-map statement is permit so accept these routes
Then I don’t see another statement but there is the implicit deny, something I can see like:
route-map TEST deny 20 –> no match is defined so everything matches the statement, when routes 10.x.x.x are taken to this statement they match it, action of the route-map is DENY so routes will be discarded.
In other words is the IMPLICIT DENY STATEMENT of the Route-Map to discard the 10.x.x.x and not the deny of the ACL.
To see this in action I will remove the network statement from router rip, because this bring again some tricky effect. So I do:
Routes-Server(config)#router rip
Routes-Server(config-router)#no network 10.0.0.0
Routes-Server(config-router)#redistribute connected route-map TEST
Look at the rip database:
Routes-Server#show ip rip database
2.0.0.0/8 auto-summary
2.104.0.0/15 redistributed
[1] via 0.0.0.0,
4.0.0.0/8 auto-summary
4.127.26.0/24 redistributed
[1] via 0.0.0.0,
11.0.0.0/8 auto-summary
11.5.140.98/31 redistributed
[1] via 0.0.0.0,
11.137.168.0/24 redistributed
[1] via 0.0.0.0,
12.0.0.0/8 auto-summary
12.251.32.0/21 redistributed
[1] via 0.0.0.0,
13.0.0.0/8 auto-summary
13.5.232.64/26 redistributed
[1] via 0.0.0.0,
13.27.7.250/31 redistributed
[1] via 0.0.0.0,
14.0.0.0/8 auto-summary
14.14.14.14/32 redistributed
[1] via 0.0.0.0,
16.0.0.0/8 auto-summary
16.176.18.0/23 redistributed
[1] via 0.0.0.0,
17.0.0.0/8 auto-summary
17.0.0.0/10 redistributed
[1] via 0.0.0.0,
18.0.0.0/8 auto-summary
18.208.0.0/12 redistributed
[1] via 0.0.0.0,
19.0.0.0/8 auto-summary
19.128.0.0/11 redistributed
[1] via 0.0.0.0,
21.0.0.0/8 auto-summary
21.16.0.0/12 redistributed
[1] via 0.0.0.0,
29.0.0.0/8 auto-summary
29.144.0.0/12 redistributed
[1] via 0.0.0.0,
31.0.0.0/8 auto-summary
31.232.224.0/20 redistributed
[1] via 0.0.0.0,
I’m redistributing connected routes only from address-space [0.x.x.x – 31.x.x.x]/any-mask and excluding network 10.0.0.0/24 (fa0/0) and 10.0.6.0/24 (fa0/1)
So my route-map is working. For example
Routes-Server#show ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Redistributing via rip
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
Routes-Server#show ip route 104.54.143.0 255.255.255.0
Routing entry for 104.54.143.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Redistributing via rip
Routing Descriptor Blocks:
* directly connected, via Loopback10100
Route metric is 0, traffic share count is 1
are connected routes but I don’t see them in rip database because route-map filter them.
To verify that is the IMPLICIT DENY at the end of the route-map to filter routes 10.x.x.x I do:
Routes-Server(config)#ip access-list extended NET-TEN
Routes-Server(config-ext-nacl)#5 permit ip 10.0.0.0 0.255.255.255 any
Routes-Server(config)#route-map TEST permit 20
Routes-Server(config-route-map)#match ip address NET-TEN
route-map TEST permit 10
match ip address INJECTOR
route-map TEST permit 20
match ip address NET-TEN
Routes-Server#show run | s ip access
ip access-list extended INJECTOR
deny ip 10.0.0.0 0.255.255.255 any
permit ip 0.0.0.0 31.255.255.255 any
ip access-list extended NET-TEN
permit ip 10.0.0.0 0.255.255.255 any
Routes-Server#show ip rip database | b 10.0
10.0.0.0/8 auto-summary
10.0.0.0/24 redistributed
[1] via 0.0.0.0,
10.0.6.0/24 redistributed
[1] via 0.0.0.0,
I see again routes 10.x.x.x because first route-map statement brings them to the second statement where are permitted, so matching the permit action of the route-map they will be accepted and never reaches implicit deny. Now the mechanism should be clear. I’ll restore previous configuration for route-map TEST.
Routes-Server(config)#no ip access-list extended NET-TEN
Routes-Server(config)#no route-map TEST permit 20
Routes-Server#
route-map TEST permit 10
match ip address INJECTOR
Net 10.x.x.x are gone again. Now, let’s look what happens when I set network 10.0.0.0 statement under rip.
Route-Server#show ip rip database | b 10.0
10.0.0.0/8 auto-summary
10.0.0.0/24 directly connected, FastEthernet0/0
10.0.6.0/24 directly connected, FastEthernet0/1
I see again network 10.0.0.0/24 and 10.0.0.6/24 as connected routes, but route-map logic is the one that before was filtering these networks. Compare with rip database entry taken before when route-map was permitting in the set of connected routes also 10.0.[0,6].0/24
The tricky part here seems to be:
Connected interfaces that belong to the address space defined by a network command under a routing protocol are always taken by the protocol and “advertised” even if a routing filter should block them. Applying here this rules:
1] Route-Server has a set of connected interfaces – 100 Loopbacks and the two connected 10.0.0.0/24 (fa0/0) + 10.0.6.0/24 (fa0/1)
2] I’m telling rip to redistribute connected based on a route-map statement, two general things happen:
A] Router looks at the routing table searching for connected routes and among them lets the ones permitted by the route-filter to go into database
B] In any case, Router takes connected networks covered by its network commands and advertises them, even if the route-filter at previous step should block them.
I can see that in this case networks 10.0.[0,6].0/24 bypass the route-filter, looking at the routing table:
