Example: Preventing BGP Session Resets - Technical Documentation - ...

https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/bgp-se...

Example: Preventing BGP Session Resets

Understanding BGP Session Resets Example: Preventing BGP Session Flaps When VPN Families Are Configured

Understanding BGP Session Resets

Certain configuration actions and events cause BGP sessions to be reset (dropped and then reestablished). If you configure both route reflection and VPNs on the same routing device, the following modifications to the route reflection configuration cause current BGP sessions to be reset: Adding a cluster IDIf a BGP session shares the same autonomous system (AS) number with the group where you add the cluster ID, all BGP sessions are reset regardless of whether the BGP sessions are contained in the same group. Creating a new route reflectorIf you have an internal BGP (IBGP) group with an AS number and create a new route reflector group with the same AS number, all BGP sessions in the IBGP group and the new route reflector group are reset. Changing configuration statements that affect BGP peers, such as renaming a BGP group, resets the BGP sessions. If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished.

Example: Preventing BGP Session Flaps When VPN Families Are Configured
This example shows a workaround for a known issue in which BGP sessions sometimes go down and then come back up (in other words, flap) when virtual private network (VPN) families are configured. If any VPN family (for example, inet-vpn, inet6-vpn, inet-mpvn, inet-mdt, inet6-mpvn, l2vpn, iso-vpn, and so on) is configured on a BGP master instance, a flap of either a route reflector (RR) internal BGP (IBGP) session or an external BGP (EBGP) session causes flaps of other BGP sessions configured with the same VPN family. Requirements Overview Configuration Verification

Requirements
Before you begin: Configure router interfaces. Configure an interior gateway protocol (IGP). Configure BGP. Configure VPNs.

Overview
When a router or switch is configured as either a route reflector (RR) or an AS boundary router (an external BGP peer) and a VPN family (for example, the family inet-vpn unicast statement) is configured, a flap of either the RR IBGP session or the EBGP session causes flaps of all other BGP sessions that are configured with the family inet-vpn unicast statement. This example shows how to prevent these unnecessary session flaps. The reason for the flapping behavior is related to BGP operation in Junos OS when originating VPN routes. BGP has the following two modes of operation with respect to originating VPN routes: If BGP does not need to propagate VPN routes because the session has no EBGP peer and no RR clients, BGP exports VPN routes directly from the instance.inet.0 routing table to other PE routers. This behavior is efficient in that it avoids the 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 session has an EBGP peer or RR clients, BGP first exports the VPN routes from the instance.inet.0 table to the bgp.l3vpn.0 table. 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 and also from an RR client or EBGP peer. When, because of a configuration change, BGP transitions from needing two copies of a route to not needing two copies of a route (or the reverse), all sessions over which VPN routes are exchanged go down and then come back up. Although this example focuses on the family inet-vpn unicast statement, the concept applies to all VPN network layer reachability information (NLRI) families. This issue impacts logical systems as well. All BGP sessions in the master instance related to the VPN NLRI family are brought down to implement the table advertisement change for the VPN NLRI family. Changing an RR to a non-RR or the reverse (by adding or removing the cluster statement) causes the table advertisement change. Also, configuring the first EBGP session or removing the EBGP session from the configuration in the master instance for a VPN NLRI family causes the table advertisement change. The way to prevent these unnecessary session flaps is to configure an extra RR client or EBGP session as a passive session with a neighbor address 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 send Open requests to a peer. Once you configure the routing device to be passive, the routing device does not originate the TCP connection. However, when the routing device receives a connection from the peer and an Open message, it replies with another BGP Open message. Each routing device declares its own capabilities. Figure 1 shows the topology for the EBGP case. Router R1 has an IBGP session with Routers R2 and R3 and an EBGP session with Router R4. All sessions have the family inet-vpn unicast statement configured. If the R1-R4 EBGP session flaps, the R1-R2 and R1-R3 BGP sessions flap also. Figure 1: Topology for the EBGP Case

1 of 4

30/10/2013 17:40

Example: Preventing BGP Session Resets - Technical Documentation - ...

https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/bgp-se...

Figure 2 shows the topology for the RR case. Router R1 is the RR, and Router R3 is the client. Router R1 has IBGP sessions with Routers R2 and R3. All sessions have the family inet-vpn unicast statement configured. If the R1-R3 session flaps, the R1-R2 and R1-R4 sessions flap also. Figure 2: Topology for the RR Case

Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. set set set set set set set set set set set set set protocols protocols protocols protocols protocols protocols protocols protocols protocols protocols protocols protocols protocols bgp bgp bgp bgp bgp bgp bgp bgp bgp bgp bgp bgp bgp family inet-vpn unicast family l2vpn signaling group R1-R4 type external group R1-R4 local-address 4.4.4.2 group R1-R4 neighbor 4.4.4.1 peer-as 200 group R1-R2-R3 type internal group R1-R2-R3 log-updown group R1-R2-R3 local-address 15.15.15.15 group R1-R2-R3 neighbor 12.12.12.12 group R1-R2-R3 neighbor 13.13.13.13 group Fake type external group Fake passive group Fake neighbor 100.100.100.100 peer-as 500

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. To configure the EBGP scenario: 1. Configure one or more VPN families. [edit protocols bgp] user@R1# set family inet-vpn unicast user@R1# set family l2vpn signaling 2. Configure the EBGP session. [edit protocols bgp] user@R1# set group R1-R4 type external user@R1# set group R1-R4 local-address 4.4.4.2 user@R1# set group R1-R4 neighbor 4.4.4.1 peer-as 200 3. Configure the IBGP sessions. [edit protocols bgp] user@R1# set group R1-R2-R3 user@R1# set group R1-R2-R3 user@R1# set group R1-R2-R3 user@R1# set group R1-R2-R3

type internal local-address 15.15.15.15 neighbor 12.12.12.12 neighbor 13.13.13.13

4. (Optional) Configure BGP so that it generates a syslog message whenever a BGP peer makes a state transition. [edit protocols bgp] user@R1# set group R1-R2-R3 log-updown Enabling the log-updown statement causes BGP state transitions to be logged at warning level.

Step-by-Step Procedure

2 of 4

30/10/2013 17:40

Example: Preventing BGP Session Resets - Technical Documentation - ...

https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/bgp-se...

To verify that unnecessary session flaps are occurring: 1. Run the show bgp summary command to verify that the sessions have been established. user@R1> show bgp summary Groups: 2 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 4.4.4.1 200 6 5 0 0 1:08 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 12.12.12.12 100 3 7 0 0 1:18 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 13.13.13.13 100 3 6 0 0 1:14 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0

2. Deactivate the EBGP session. user@R1# deactivate group R1-R4 user@R1# commit Mar 10 18:27:40 R1: rpd[1464]: bgp_peer_delete:6589: NOTIFICATION sent to 4.4.4.1 (External AS 200): code 6 (Cease) subcode 3 (Peer Unc Mar 10 18:27:40 R1: rpd[1464]: bgp_adv_main_update:7253: NOTIFICATION sent to 12.12.12.12 (Internal AS 100): code 6 (Cease) subcode 6 ( Mar 10 18:27:40 R1: rpd[1464]: bgp_adv_main_update:7253: NOTIFICATION sent to 13.13.13.13 (Internal AS 100): code 6 (Cease) subcode 6 ( 3. Run the show bgp summary command to view the session flaps. user@R1> show bgp summary Groups: 1 Peers: 2 Down peers: 2 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 12.12.12.12 100 4 9 0 1 19 Active 13.13.13.13 100 4 8 0 1 19 Active user@R1> show bgp summary Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 12.12.12.12 100 2 3 0 1 0 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 13.13.13.13 100 2 3 0 1 0 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0

Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. To prevent unnecessary BGP session flaps: 1. Add a passive EBGP session with a neighbor address that does not exist in the peer autonomous system (AS). [edit protocols bgp] user@R1# set group Fake type external user@R1# set group Fake passive user@R1# set neighbor 100.100.100.100 peer-as 500 2. Run the show bgp summary command to verify that the real sessions have been established and the passive session is idle. user@R1> show bgp summary Groups: 3 Peers: 4 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 4.4.4.1 200 9500 9439 0 0 2d 23:14:23 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 12.12.12.12 100 10309 10239 0 0 3d 5:17:49 Establ bgp.l3vpn.0: 0/0/0/0 13.13.13.13 100 10306 10241 0 0 3d 5:18:25 Establ bgp.l3vpn.0: 0/0/0/0 100.100.100.100 500 0 0 0 0 2d 23:38:52 Idle

Verification
Confirm that the configuration is working properly. Bringing Down the EBGP Session Verifying That the IBGP Sessions Remain Up

Bringing Down the EBGP Session Purpose

Try to cause the flap issue after the workaround is configured.

Action
user@R1# deactivate group R1-R4 user@R1# commit

Verifying That the IBGP Sessions Remain Up Purpose

Make sure that the IBGP sessions do not flap after the EBGP session is deactivated.

3 of 4

30/10/2013 17:40

Example: Preventing BGP Session Resets - Technical Documentation - ...

https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/bgp-se...

Action
user@R1> show bgp summary Groups: 2 Peers: 3 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 12.12.12.12 100 10312 10242 0 0 3d 5:19:01 Establ bgp.l3vpn.0: 0/0/0/0 13.13.13.13 100 10309 10244 0 0 3d 5:19:37 Establ bgp.l3vpn.0: 0/0/0/0 100.100.100.100 500 0 0 0 0 2d 23:40:04 Idle user@R1> show bgp summary Groups: 3 Peers: 4 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 0 0 0 0 0 0 bgp.l2vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 4.4.4.1 200 5 4 0 0 28 Establ bgp.l3vpn.0: 0/0/0/0 bgp.l2vpn.0: 0/0/0/0 12.12.12.12 100 10314 10244 0 0 3d 5:19:55 Establ bgp.l3vpn.0: 0/0/0/0 13.13.13.13 100 10311 10246 0 0 3d 5:20:31 Establ bgp.l3vpn.0: 0/0/0/0 100.100.100.100 500 0 0 0 0 2d 23:40:58 Idle

Related Documentation
M Series Understanding External BGP Peering Sessions BGP Configuration Overview MX Series Understanding External BGP Peering Sessions BGP Configuration Overview

Published: 2013-09-24

Site Map / RSS Feeds / Careers / Accessibility / Feedback / Privacy & Policy / Legal Notices

Copyright 1999-2013 Juniper Networks, Inc. All rights reserved.

4 of 4

30/10/2013 17:40