Vaibhav Singh

Lately, I have been struggling to understand the logic behind route-map and its functioning when used along with a prefix-list in order to filter prefixes. Basically configurations where the permit/deny of prefix-list couples with permit/deny of route-map.

So I decided to lab it out in GNS3 – only allow 172.1.1.0/24 to pass through; filter everything else and prepend own ASN 3x.

R1#sh ip int brief | ex un   
Interface                  IP-Address      OK? Method Status                Protocol
Serial1/0                  10.1.1.1        YES manual up                    up      
Loopback1                  172.1.1.1       YES manual up                    up      
Loopback2                  172.1.2.1       YES manual up                    up      
Loopback3                  172.1.3.1       YES manual up                    up      
Loopback4                  172.1.4.1       YES manual up                    up    

R1#sh ip prefix-list 
ip prefix-list FILTER_OUT: 2 entries
   seq 5 deny 172.1.1.0/24
   seq 10 permit 0.0.0.0/0 le 32

R1#sh route-map 
route-map ROUTE_MAP_OUT, deny, sequence 10
  Match clauses:
    ip address prefix-lists: FILTER_OUT 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map ROUTE_MAP_OUT, permit, sequence 20
  Match clauses:
  Set clauses:
    as-path prepend 100 100 100
  Policy routing matches: 0 packets, 0 bytes
route-map ROUTE_MAP_OUT, permit, sequence 30
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

R1#sh run | s bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 10.1.1.0 mask 255.255.255.252
 network 172.1.1.0 mask 255.255.255.0
 network 172.1.2.0 mask 255.255.255.0
 network 172.1.3.0 mask 255.255.255.0
 network 172.1.4.0 mask 255.255.255.0
 neighbor 10.1.1.2 remote-as 200
 neighbor 10.1.1.2 route-map ROUTE_MAP_OUT out
 no auto-summary

Conclusion

It’s a logical OR operation that happens. For simplicity, I’d rather make prefix-lists with all permit statements and permit/deny as required in the route-maps.

Here is a [link] that has a good discussion which may clear many doubts.

Just to remove any ambiguity, I’ll reiterate a little here: multiple standalone match statements in a single route-map block are possible only if they refer to different kinds of tests, e.g. ACLs and interfaces (think NAT using route-maps for two different ISPs matching both ACL for internal IP addresses and the egress interface). However, when trying to add a couple of match ip address statements, even though each of them refers to a unique ACL number or name, the IOS will nevertheless collapse all these statements into a single match ip address statement. That is why they become logically OR-ed – because the IOS puts them into a single match ip address line even though each ACL was originally input as a separate and standalone match statement.

I remember trying to respond to a thread some two months ago from now where the poster tried to use the continue clause in route-map for PBR purposes. This is not supported, sadly. I suggested at that point using multiple match ip address commands in a single route-map block to achieve the same result. However, as it turned out – and somebody corrected me back then – this was not possible. I assumed I can make a logical AND between two ACLs by referring to them in different match statements. Sadly, IOS does not support this – it collapsed the configuration into a single match statement, spoiling my attempt at helping