Article explains about the scenario where L3VPN prefixes advertised by RR is dropped by the PE. When device configured as PE peering with a RR as a client, when there are no external BGP Peers configured with static route target, Prefixes advertised by RR is being dropped by PE
On all Junos and Junos OS Evolved platforms configured as a Provider Edge (PE) in an L3VPN scenario peering with a route-reflector (RR) as a client, when there are no external BGP peers configured with a static route-target-filter as `local`, VPNv4 prefixes advertised by RR is being dropped which is as per design and expected behavior. However, when an external BGP session is established on the PE, because 'advertise-from-main-vpn-tables' is configured, the PE doesn't flap all existing BGP sessions, and the refresh of prefixes advertised by RR does not happen. As a result, prefixes advertised by RR continue to be dropped at PE.
The issue can be checked by verifying for the routes received for the particular router-target. We will see no or only part of routes received by PE.user@router_pe> show route receive-protocol bgp XX.XX.XX.XX table bgp.l3vpn.0 community target:ASN:NNNNAt the same time at the RR we could see that all needed prefixes are being advertised to the PE.user@router_rr> show route advertising-protocol bgp XX.XX.XX.XX table bgp.l3vpn.0 community target:ASN:NNNN
Example:========DUT: PE4_RE
Source routers: PE3_RE & PE7_RE Route Reflector: VRR_RE-1 PE4 configured with: set protocols bgp advertise-from-main-vpn-tables We need PE to receive VPNv4 prefixes 192.168.1.3:390:10.10.10.0/24 and 192.168.1.7:390:10.10.10.0/24, originated from PE3_RE and PE7_RE. No VPN and no static route-target-filter is configured yet with community target:16086:7888. <<<<<<<<< PR4 has bgp session with vRR (192.168.100.102) and family route-target already configured and the session is up. root@PE4_RE> show bgp summary 192.168.100.102 16086 13 14 0 10 9 Establ bgp.rtarget.0: 1/1/1/0 inet.0: 0/0/0/0 inet6.0: 0/0/0/0 bgp.l3vpn.0: 1/1/1/0 bgp.l3vpn-inet6.0: 0/0/0/0 bgp.l2vpn.0: 2/2/2/0 bgp.evpn.0: 0/0/0/0 bgp.mvpn.0: 0/0/0/0 BGP-VPLS.l2vpn.0: 1/1/1/0 L2_BNG_ETH_00238.l2vpn.0: 1/1/1/0 PolicyCheck_L3VPN.inet.0: 1/1/1/0 vRR is not sending routes with community target:16086:7888 to PE4 (192.168.1.4) lab@VRR_RE-1> show route advertising-protocol bgp 192.168.1.4 table bgp.l3vpn.0 community target:16086:7888 lab@VRR_RE-1> root@PE4_RE> show route receive-protocol bgp 192.168.100.102 table bgp.l3vpn.0 community target:16086:7888 bgp.l3vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden) 2. Configuring static route-target-filter with community target:16086:7888 on PE4 set groups Test policy-options policy-statement EBGP:VPN term VRF:7888 from community VRF:7888 set groups Test policy-options policy-statement EBGP:VPN term VRF:7888 then accept set groups Test policy-options policy-statement EBGP:VPN term VRF:7777 from community VRF:7777 set groups Test policy-options policy-statement EBGP:VPN term VRF:7777 then accept set groups Test policy-options policy-statement EBGP:VPN term all then default-action reject set groups Test policy-options community VRF:7888 members target:16086:7888 set groups Test policy-options community VRF:7777 members target:16086:7777 set groups Test routing-options rib bgp.rtarget.0 static route-target-filter 16086:7888/64 local set groups Test routing-options rib bgp.rtarget.0 static route-target-filter 16086:7777/64 local <<< set apply-groups Test root@PE4_RE# commit and-quit commit complete After this commit, RR starting to send 192.168.1.3:390:10.10.10.0/24 and 192.168.1.7:390:10.10.10.0/24 tagged with community target:16086:7888 - to PE4. lab@VRR_RE-1> show route advertising-protocol bgp 192.168.1.4 table bgp.l3vpn.0 community target:16086:7888 .. bgp.l3vpn.0: 5 destinations, 10 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.1.3:390:10.10.10.0/24 * 192.168.1.3 100 64529 I 192.168.1.7:390:10.10.10.0/24 * 192.168.1.7 200 100 64529 I This update is seen on links to PE4. But PE4 is still showing that it is not receiving anything with community target:16086:7888. And BGP session with RR is not flapped. root@PE4_RE> show bgp summary .. 192.168.100.102 16086 24 24 0 10 4:03 Establ root@PE4_RE> show route receive-protocol bgp 192.168.100.102 table bgp.l3vpn.0 community target:16086:7888 bgp.l3vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden) 3. Configuring external BGP neighbor on PE4 set groups TC2 routing-options rib bgp.rtarget.0 static route-target-filter 16086:7888/64 local <<<<<<<<<<<<<< set groups TC2 protocols bgp group EBGP type external set groups TC2 protocols bgp group EBGP drop-path-attributes 128 set groups TC2 protocols bgp group EBGP family inet-vpn unicast set groups TC2 protocols bgp group EBGP family inet6-vpn unicast set groups TC2 protocols bgp group EBGP export DEFREJECT set groups TC2 protocols bgp group EBGP export EBGP:VPN <<<<<<<<<<<< export policy attached set groups TC2 protocols bgp group EBGP neighbor 62.78.106.35 peer-as 64529 set groups TC2 protocols bgp group EBGP vpn-apply-export set apply-groups TC2 root@PE4_RE# commit and-quit commit complete Exiting configuration mode The expectation is that the routes advertised by RR should be seen in PE device. Since there is no BGP session flap in PE and needed prefixes are not received. root@PE4_RE> show bgp summary Jan 15 02:08:46 .. 192.168.100.102 16086 26 26 0 10 5:18 Establ root@PE4_RE> show route receive-protocol bgp 192.168.100.102 table bgp.l3vpn.0 community target:16086:7888 Jan 15 02:08:54 bgp.l3vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden) But they still advertised from RR: lab@VRR_RE-1> show route advertising-protocol bgp 192.168.1.4 table bgp.l3vpn.0 community target:16086:7888 Jan 15 02:09:00 .. junos-bgpshard1::bgp.l3vpn.0: 5 destinations, 10 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.1.3:390:10.10.10.0/24 * 192.168.1.3 100 64529 I 192.168.1.7:390:10.10.10.0/24 * 192.168.1.7 200 100 64529 I
1) Manually restart the BGP sessionor2) Clear bgp neighbor <RR-peer-ipaddr> Workaround:When configure static route target use group/neighbor instead of localAddressed by PR 1785231 fix in latest versions