When a router or switch is configured as either a routereflector (RR) or an AS boundary router (an external BGP peer) anda VPN family (for example, the family inet-vpn unicast statement)is configured, a flap of either the RR IBGP session or the EBGP sessioncauses flaps of all other BGP sessions that are configured with the family inet-vpn unicast statement. This example shows how toprevent these unnecessary session flaps.
The reason for the flapping behavior is related to BGP operationin Junos OS when originating VPN routes.
BGP has the following two modes of operation with respectto originating VPN routes:
If BGP does not need to propagate VPN routes because thesession has no EBGP peer and no RR clients, BGP exports VPN routesdirectly from the instance.inet.0 routing tableto other PE routers. This behavior is efficient in that it avoidsthe creation of two copies of many routes (one in the instance.inet.0 table and one in the bgp.l3vpn.0 table).
If BGP does need to propagate VPN routes because the sessionhas an EBGP peer or RR clients, BGP first exports the VPN routes fromthe instance.inet.0 table to the bgp.l3vpn.0table. Then BGP exports the routes to other PE routers. In this scenario,two copies of the route are needed to enable best-route selection.A PE router might receive the same VPN route from a CE device andalso from an RR client or EBGP peer.
Note:
The route export is not performed if theroute in instance.inet.0 is a secondary route.In Junos OS, a route is only exported one time from one routing tableas a primary route to another routing table as a secondary route.Because the route in instance.inet.0 is alreadya secondary route, it is not allowed to be moved again to the bgp.l3vpn.0table, as needed to be advertised. The route does not reach the bgp.l3vpn.0table and thus is not advertised. One workaround is to send the routesthat should be advertised to inet.0 so that they are advertised.
When, because of a configuration change, BGP transitions fromneeding two copies of a route to not needing two copies of a route(or the reverse), all sessions over which VPN routes are exchangedgo down and then come back up. Although this example focuses on the family inet-vpn unicast statement, the concept applies to allVPN network layer reachability information (NLRI) families. This issueimpacts logical systems as well. All BGP sessions in the master instancerelated to the VPN NLRI family are brought down to implement the tableadvertisem*nt change for the VPN NLRI family. Changing an RR to anon-RR or the reverse (by adding or removing the cluster statement) causes the table advertisem*nt change. Also, configuringthe first EBGP session or removing the EBGP session from the configurationin the master instance for a VPN NLRI family causes the table advertisem*ntchange.
The way to prevent these unnecessary session flaps is to configurean extra RR client or EBGP session as a passive session with a neighboraddress that does not exist. This example focuses on the EBGP case,but the same workaround works for the RR case.
When a session is passive, the routing device does not sendOpen requests to a peer. Once you configure the routing device tobe passive, the routing device does not originate the TCP connection.However, when the routing device receives a connection from the peerand an Open message, it replies with another BGP Open message. Eachrouting device declares its own capabilities.
Topology
Figure 1 shows the topologyfor the EBGP case. Router R1 has an IBGP session with Routers R2 andR3 and an EBGP session with Router R4. All sessions have the family inet-vpn unicast statement configured. If the R1-R4EBGP session flaps, the R1-R2 and R1-R3 BGP sessions flap also.
Figure 1: Topology for the EBGP Case
Figure 2 shows the topology for the RRcase. Router R1 is the RR, and RouterR3 is the client. RouterR1 has IBGP sessions with Routers R2 and R3. All sessions have the familyinet-vpn unicast statement configured. If the R1-R3session flaps, the R1-R2 and R1-R4 sessions flap also.
Figure 2: Topology for the RR Case
