JunOS: Preventing MP-BGP Session Dumping

When configuring the MP-BGP protocol, on Juniper equipment, there is a (not) obvious situation with the re-establishment of neighborhoods. The reason is described in detail in Junuper Knowledge base KB20870 , here is a brief retelling with my comments.

As you know, when working with VPNs, several routing tables are used. We will be interested in 2 main ones: vrf.inet.0 and bgp.l3vpn.0 (the situation with L3VPN is described later in the text, but the same is true for other services, where BGP is a signaling protocol).

All routes received from BGP neighbors are placed in the bgp.l3vpn.0 table .

The direct / static routes of a specific PE router are placed into the vrf.inet.0 table , and incoming routes from neighbors from the bgp.l3vpn.0 table are imported that satisfy the import policy (if one is configured).
At the same time, export from vrf.inet.0 to bgp.l3vpn.0 does not occur, and routes are directly announced to neighbors.

If the router acts as a reflector of the routes, or there are MP eBGP neighbors, the routes are placed both in the vrf.inet.0 table and in bgp.l3vpn . When this happens, a comparison with local routes occurs and (if necessary) the best path is chosen.

Thus, the router can operate in one of two specific modes:

• Router reflector is not configured on the router and there are no eBGP neighbors;
• The router is a route reflector and \ or it has eBGP neighbors.

Changing modes entails restarting MP-BGP sessions. Clearly, this can be seen in the following topology:

In the first variant (Fig. 1), the classic full-mesh iBGP scheme is presented. Now imagine that we need to add a router R4. For one reason or another, we decided to do this by setting up R1 with a route reflector for R4 (Fig. 2). Configuring the route-reflector to R1 will result in the re-establishment of all MP-BGP sessions (with R2 and R3 routers), which will result in downtime in the provision of services.

In order to avoid this, it is proposed to put the router firmly into the 2nd mode of operation. One way is to create a fictitious eBGP group. For example:

group fake-vpn {
   typeexternal;
   description "## Preventing mpbgp sessions flap ##";
   passive;
   familyinet {
       any;
   familyinet-vpn {
       any;
   family iso-vpn {
       unicast;
   family l2vpn {
       signaling;
   family evpn {
       signaling;
   familyinet-mvpn {
       signaling;
   familyinet-mdt {
       signaling;
   neighbor 192.0.2.1 {
       peer-as65536;
}

AS: 65536 and IP: 192.0.2.1 can be absolutely any, and passive mode allows you to avoid unnecessary attempts to establish a non-existent session from the side of the router.

When it can be useful:

• There are no dedicated route-reflectors on the network. RRs are network core routers. At the same time, there is a possibility of a change in their role (eg from the P-router to P / RR or vice versa);
• There is a possibility that an eBGP interface with the MP-BGP family will appear, for example, Inter-AS.