Sunday, March 10, 2013

Cisco BGP route-map continue statement confusion


I was confused by the wording of Cisco regarding the route-map continue statement Route maps have a linear behavior, not a nested behavior. Once a route is matched in a route map permit entry with a continue command clause, it will not be processed by the implicit deny at the end of the route-map. Therefore I've designed the following lab to check the actual behaviour
 R1 configuration:
R1#show run
Building configuration...

!
hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip address 20.20.20.1 255.255.255.0
!
interface FastEthernet1/0
 ip address 10.10.10.1 255.255.255.252
 duplex auto
 speed auto
!
router bgp 65001
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 20.20.20.0 mask 255.255.255.0
 neighbor 10.10.10.2 remote-as 65002
 neighbor 10.10.10.2 send-community both
 neighbor 10.10.10.2 route-map TEST out
 no auto-summary
!
ip bgp-community new-format
!
route-map TEST permit 10
 set community 65001:65002
!
route-map TEST1 permit 10
!
end
Scenario 1: In this one we will match prefix list and community list on continue statement and advertise to R3 :
hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
 ip address 10.10.10.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/1
 ip address 10.10.10.5 255.255.255.252
 duplex auto
 speed auto
!
router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.10.1 remote-as 65001
 neighbor 10.10.10.6 remote-as 65003
 neighbor 10.10.10.6 send-community both
 neighbor 10.10.10.6 route-map BLOCK-IT out
 no auto-summary
!

ip bgp-community new-format
ip community-list 100 permit 65001:65002

!
ip prefix-list SEND-ME seq 5 permit 20.20.20.0/24
!
route-map BLOCK-IT permit 10
 match ip address prefix-list SEND-ME
 continue 100
!
route-map BLOCK-IT permit 100
 match community 100
 set community 65002:65003 additive
!
!
as we expected we see the output on R3:
R3#show ip bgp 20.20.20.20
BGP routing table entry for 20.20.20.0/24, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65002 65001
    10.10.10.5 from 10.10.10.5 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
      Community: 65001:65002 65002:65003
But if we change the community list 100 as follows, still we are observing the prefixes are advertised but no community values are added
R2#sho ip community-list 100
Community (expanded) access list 100
    permit 65001:10000
If you are expecting the prefixes that not matched the community list should be dropped that is not the case !!!
R3#show ip bgp 20.20.20.20
BGP routing table entry for 20.20.20.0/24, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65002 65001
    10.10.10.5 from 10.10.10.5 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
      Community: 65001:65002
So cisco says you need to define your explicit deny statement as follows if you want to drop that doesn't match. Therefore if you define the final drop statement it will drop that doesn't match.
route-map BLOCK-IT permit 10
 match ip address prefix-list SEND-ME
 continue 100
!
route-map BLOCK-IT permit 100
 match community 100
 set community 65002:65003 additive
!
route-map BLOCK-IT deny 110

R3#show ip bgp 20.20.20.20
% Network not in table

as defined in cisco if there is a match in the flow of route-map and then if it is transferred to continue statement you can't expect that it will be denied from the implicit deny statement. Tested in Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T

No comments: