cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1604
Views
0
Helpful
2
Replies

Default announcement conditioned by route-map with 2 match entries

Mario Rosi
Level 1
Level 1

I’ve this scenario (see the attachment), where the BORDER routers are receiving the full routing table from external peers; I want to announce the default towards CORE routers (that are also router reflector) and some specific prefixes (if requested for load balancing). The default is conditioned by 4 prefixes; unfortunately, between BORDER02 and BORDER01 there is an old iBGP session that I don’t want to have to consider, but also on that session the external prefixes are announced between the BORDER routers. So the default is announced using a route-map that check the existence of four prefixes and also their next hop (I want to be sure that the next hop is an external peer and not the twin BORDER router). The same policy is followed on eventual specific prefixes I’m going to be announced to CORE routers (these ones are receiving the default and some prefixes in VRF and then announced in VPNv4 on the rest of the network). Here below is an extract of config concerning BGP on BORDER01 where also local preference is set… router bgp 12481 template peer-session IBGP-I-PE remote-as 12481 update-source Loopback0 timers 5 20 exit-peer-session ! template peer-session iBGP_2_VRF_INTERNET remote-as 12481 password CISCO timers 5 20 exit-peer-session ! bgp router-id 5.100.236.3 bgp log-neighbor-changes bgp maxas-limit 30 no bgp default ipv4-unicast neighbor 10.0.0.1 inherit peer-session iBGP_2_VRF_INTERNET neighbor 10.0.0.1 description iBGP to CORE01 neighbor 10.0.0.9 inherit peer-session iBGP_2_VRF_INTERNET neighbor 10.0.0.9 description iBGP to CORE02 neighbor 62.86.118.243 remote-as 3269 --> external peering neighbor 62.86.118.243 description AS3269 Telecom Italia neighbor 62.86.118.243 ebgp-multihop 5 neighbor 62.86.118.243 update-source Loopback0 neighbor 149.6.88.9 remote-as 174 --> external peering neighbor 149.6.88.9 description AS174 Cogent ! address-family ipv4 neighbor 10.0.0.1 activate neighbor 10.0.0.1 send-community both neighbor 10.0.0.1 next-hop-self neighbor 10.0.0.1 default-originate route-map DEFAULT_IPv4_ORIGINATE_to_CORE01 neighbor 10.0.0.1 route-map SPECIFIC_PREFIXES_to_CORE01 out neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.9 next-hop-self neighbor 10.0.0.9 default-originate route-map DEFAULT_IPv4_ORIGINATE_to_CORE02 neighbor 10.0.0.9 route-map SPECIFIC_PREFIXES_to_CORE02 out neighbor 62.86.118.243 activate neighbor 62.86.118.243 soft-reconfiguration inbound neighbor 149.6.88.9 activate neighbor 149.6.88.9 soft-reconfiguration inbound exit-address-family ! threat-visibility ! virtual-service csr_mgmt ! ip forward-protocol nd no ip http server ip http authentication local no ip http secure-server ip route 62.86.118.243 255.255.255.255 2.113.122.241 ! ! ! ip prefix-list PREFIX_LEVEL3_AT&T seq 5 permit 4.0.0.0/8 ip prefix-list PREFIX_LEVEL3_AT&T seq 10 permit 8.0.0.0/8 ip prefix-list PREFIX_LEVEL3_AT&T seq 15 permit 12.0.0.0/8 ip prefix-list PREFIX_LEVEL3_AT&T seq 20 permit 32.0.0.0/8 ! ip prefix-list SPECIFIC_PREFIXES_from_WWW seq 10 permit 1.0.0.0/8 ! ip prefix-list TI_COGENT_NH seq 5 permit 62.86.118.243/32 --> these are the Next Hop of external peer TI ip prefix-list TI_COGENT_NH seq 10 permit 149.6.88.9/32 --> these are the Next Hop of external peer COGENT ! route-map DEFAULT_IPv4_ORIGINATE_to_CORE01 permit 10 match ip address prefix-list PREFIX_LEVEL3_AT&T match ip next-hop prefix-list TI_COGENT_NH set local-preference 250 ! route-map DEFAULT_IPv4_ORIGINATE_to_CORE02 permit 10 match ip address prefix-list PREFIX_LEVEL3_AT&T match ip next-hop prefix-list TI_COGENT_NH set local-preference 200 ! route-map SPECIFIC_PREFIXES_to_CORE01 permit 10 match ip address prefix-list SPECIFIC_PREFIXES_from_WWW match ip next-hop prefix-list TI_COGENT_NH set local-preference 250 ! route-map SPECIFIC_PREFIXES_to_CORE02 permit 10 match ip address prefix-list SPECIFIC_PREFIXES_from_WWW match ip next-hop prefix-list TI_COGENT_NH set local-preference 200 ! Now, with this configuration, on CORE01 (similarly on CORE02) I receive correctly the specific prefixes 1.0.0.0/8 from BORDER01 but not the default… CORE_1#sh bgp vrf INTERNET BGP table version is 57, local router ID is 5.100.236.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 12481:200000 (default for vrf INTERNET) *>i 1.0.0.0 10.0.0.2 0 250 0 174 i * i 10.0.0.2 0 i … If I remove the condition of match on Next hop on route map and so: route-map DEFAULT_IPv4_ORIGINATE_to_CORE01 permit 10 match ip address prefix-list PREFIX_LEVEL3_AT&T no match ip next-hop prefix-list TI_COGENT_NH set local-preference 250 …I correctly receive also the default route from BORDER01: CORE_1#sh bgp vrf INTERNET BGP table version is 58, local router ID is 5.100.236.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 12481:200000 (default for vrf INTERNET) *>i 0.0.0.0 10.0.0.2 0 250 0 i * i 10.0.0.2 0 i *>i 1.0.0.0 10.0.0.2 0 250 0 174 i * i 10.0.0.2 0 i … Is this a normal behaviour or it is hiding a BUG in your opinion? Thanks, Mario

1 Accepted Solution

Accepted Solutions

Harold Ritter
Cisco Employee
Cisco Employee

Hi Mario,

 

According to the IOS documentation, the only match that is allowed in the route-map is the "match ip address".

 

https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp3.html#wp1105838

 

I just verified and it works if you use a "match route-type external" instead of the "match ip next-hop prefix-list". This should achieve your objective of making sure the route is received from the eBGP peer rather than the iBGP peer.

 

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

2 Replies 2

Harold Ritter
Cisco Employee
Cisco Employee

Hi Mario,

 

According to the IOS documentation, the only match that is allowed in the route-map is the "match ip address".

 

https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp3.html#wp1105838

 

I just verified and it works if you use a "match route-type external" instead of the "match ip next-hop prefix-list". This should achieve your objective of making sure the route is received from the eBGP peer rather than the iBGP peer.

 

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Thanks Harold,

in fact i checked and changed the configuration using IP ACL and it works.

 

Thanks again,

Mario


@Harold Ritter wrote:

Hi Mario,

 

According to the IOS documentation, the only match that is allowed in the route-map is the "match ip address".

 

https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp3.html#wp1105838

 

I just verified and it works if you use a "match route-type external" instead of the "match ip next-hop prefix-list". This should achieve your objective of making sure the route is received from the eBGP peer rather than the iBGP peer.

 

Regards,



@Harold Ritter wrote:

Hi Mario,

 

According to the IOS documentation, the only match that is allowed in the route-map is the "match ip address".

 

https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp3.html#wp1105838

 

I just verified and it works if you use a "match route-type external" instead of the "match ip next-hop prefix-list". This should achieve your objective of making sure the route is received from the eBGP peer rather than the iBGP peer.

 

Regards,


 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: