BGP Session and Route Flaps
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 ID—If 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 reflector—If 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
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.
The route export is not performed if the route in instance.inet.0 is a secondary route. In Junos OS, a route is only exported one time from one routing table as a primary route to another routing table as a secondary route. Because the route in instance.inet.0 is already a secondary route, it is not allowed to be moved again to the bgp.l3vpn.0 table, as needed to be advertised. The route does not reach the bgp.l3vpn.0 table and thus is not advertised. One workaround is to send the routes that should be advertised to inet.0 so that they are advertised.
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 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.
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.
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:
- Configure one or more VPN families.[edit protocols bgp]user@R1# set family inet-vpn unicastuser@R1# set family l2vpn signaling
- Configure the EBGP session.[edit protocols bgp]user@R1# set group R1-R4 type externaluser@R1# set group R1-R4 local-address 4.4.4.2user@R1# set group R1-R4 neighbor 4.4.4.1 peer-as 200
- Configure the IBGP sessions.[edit protocols bgp]user@R1# set group R1-R2-R3 type internaluser@R1# set group R1-R2-R3 local-address 15.15.15.15user@R1# set group R1-R2-R3 neighbor 12.12.12.12user@R1# set group R1-R2-R3 neighbor 13.13.13.13
- (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
To verify that unnecessary session flaps are occurring:
- Run the show bgp summary command to verify
that the sessions have been established.
user@R1> show bgp summaryGroups: 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
- Deactivate the EBGP session.user@R1# deactivate group R1-R4user@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 Unconfigured), Reason: Peer Deletion 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 (Other Configuration Change), Reason: Configuration change - VPN table advertise 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 (Other Configuration Change), Reason: Configuration change - VPN table advertise
- Run the show bgp summary command to view the
session flaps.
user@R1> show bgp summaryGroups: 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 summaryGroups: 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:
- 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 externaluser@R1# set group Fake passiveuser@R1# set neighbor 100.100.100.100 peer-as 500
- 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 summaryGroups: 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
Purpose
Try to cause the flap issue after the workaround is configured.
Action
Verifying That the IBGP Sessions Remain Up
Purpose
Make sure that the IBGP sessions do not flap after the EBGP session is deactivated.
Action
user@R1> show bgp summaryGroups: 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 summaryGroups: 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
Understanding Damping Parameters
BGP route flapping describes the situation in which BGP systems send an excessive number of update messages to advertise network reachability information. BGP flap damping is a method of reducing the number of update messages sent between BGP peers, thereby reducing the load on these peers, without adversely affecting the route convergence time for stable routes.
Flap damping reduces the number of update messages by marking routes as ineligible for selection as the active or preferable route. Marking routes in this way leads to some delay, or suppression, in the propagation of route information, but the result is increased network stability. You typically apply flap damping to external BGP (EBGP) routes (routes in different ASs). You can also apply flap damping within a confederation, between confederation member ASs. Because routing consistency within an AS is important, do not apply flap damping to internal BGP (IBGP) routes. (If you do, it is ignored.)
There is an exception that rule. Starting in Junos OS Release 12.2, you can apply flap damping at the address family level. In a Junos OS Release 12.2 or later installation, when you apply flap damping at the address family level, it works for both IBGP and EBGP.
By default, route flap damping is not enabled. Damping is applied to external peers and to peers at confederation boundaries.
When you enable damping, default parameters are applied, as summarized in Table 1.
Table 1: Damping Parameters
Damping Parameter | Description | Default Value | Possible Values |
|---|---|---|---|
half-life minutes | Decay half-life—Number of minutes after which an arbitrary value is halved if a route stays stable. | 15 (minutes) | 1 through 45 |
max-suppress minutes | Maximum hold-down time for a route, in minutes. | 60 (minutes) | 1 through 720 |
reuse | Reuse threshold—Arbitrary value below which a suppressed route can be used again. | 750 | 1 through 20,000 |
suppress | Cutoff (suppression) threshold—Arbitrary value above which a route can no longer be used or included in advertisements. | 3000 | 1 through 20,000 |
To change the default BGP flap damping values, you define actions by creating a named set of damping parameters and including it in a routing policy with the damping action. For the damping routing policy to work, you also must enable BGP route flap damping.
See also
Example: Configuring BGP Route Flap Damping Parameters
This example shows how to configure damping parameters.
Requirements
Before you begin, configure router interfaces and configure routing protocols.
Overview
This example has three routing devices. Device R2 has external BGP (EBGP) connections with Device R1 and Device R3.
Device R1 and Device R3 have some static routes configured for testing purposes, and these static routes are advertised through BGP to Device R2.
Device R2 damps routes received from Device R1 and Device R3 according to these criteria:
Damp all prefixes with a mask length equal to or greater than 17 more aggressively than routes with a mask length between 9 and 16.
Damp routes with a mask length between 0 and 8, inclusive, less than routes with a mask length greater than 8.
Do not damp the 10.128.0.0/9 prefix at all.
The routing policy is evaluated when routes are being exported from the routing table into the forwarding table. Only the active routes are exported from the routing table.
Figure 3 shows the sample network.
CLI Quick Configuration shows the configuration for all of the devices in Figure 3.
The section Step-by-Step Procedure describes the steps on Device R2.
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.
Device R1
Device R2
Device R3
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 damping parameters:
Configure the interfaces.
[edit interfaces]user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30user@R2# set fe-1/2/1 unit 0 family inet address 10.1.0.1/30user@R2# set lo0 unit 0 family inet address 192.168.0.2/32- Configure the BGP neighbors.[edit protocols bgp group ext]user@R2# set type externaluser@R2# set neighbor 10.0.0.1 peer-as 100user@R2# set neighbor 10.1.0.2 peer-as 300
Create and configure the damping parameter groups.
[edit policy-options]user@R2# set damping aggressive half-life 30user@R2# set damping aggressive suppress 2500user@R2# set damping timid half-life 5user@R2# set damping dry disableConfigure the damping policy.
[edit policy-options policy-statement damp term 1]user@R2# set from route-filter 10.128.0.0/9 exact damping dryuser@R2# set from route-filter 0.0.0.0/0 prefix-length-range /0-/8 damping timiduser@R2# set from route-filter 0.0.0.0/0 prefix-length-range /17-/32 damping aggressiveEnable damping for BGP.
[edit protocols bgp]user@R2# set dampingApply the policy as an import policy for the BGP neighbor.
[edit protocols bgp group ext]user@R2# set import dampNote You can refer to the same routing policy one or more times in the same or different import statements.
- Configure an export policy.[edit policy-options policy-statement send-direct term 1]user@R2# set from protocol directuser@R2# set then accept
- Apply the export policy.[edit protocols bgp group ext]user@R2# set export send-direct
- Configure the autonomous system (AS) number.[edit routing-options]user@R2# set autonomous-system 200
Results
From configuration mode, confirm your configuration by issuing the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Causing Some Routes to Flap
Purpose
To verify your route flap damping policy, some routes must flap. Having a live Internet feed almost guarantees that a certain number of route flaps will be present. If you have control over a remote system that is advertising the routes, you can modify the advertising router's policy to effect the advertisement and withdrawal of all routes or of a given prefix. In a test environment, you can cause routes to flap by clearing the BGP neighbors or by restarting the routing process on the BGP neighbors, as shown here.
Action
From operational mode on Device R1 and Device R3, enter the restart routing command.
Use this command cautiously in a production network.
user@R1> restart routingR1 started, pid 10474
user@R3> restart routingR3 started, pid 10478
Meaning
On Device R2, all of the routes from the neighbors are withdrawn and re-advertised.
Checking the Route Flaps
Purpose
View the number of neighbor flaps.
Action
From operational mode, enter the show bgp summary command.
user@R2> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
12 1 11 0 11 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.0.1 100 10 10 0 4 2:50 0/9/0/9 0/0/0/0
10.1.0.2 300 10 10 0 4 2:53 1/3/1/2 0/0/0/0Meaning
This output was captured after the routing process was restarted on Device R2’s neighbors four times.
Verifying Route Flap Damping
Purpose
Verify that routes are being hidden due to damping.
Action
From operational mode, enter the show route damping suppressed command.
user@R2> show route damping suppressed
inet.0: 15 destinations, 17 routes (6 active, 0 holddown, 11 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.0.0.0/9 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.0.0.0/30 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.1.0.0/30 [BGP ] 00:00:15, localpref 100
AS path: 300 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
10.224.0.0/11 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.0.0/16 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.128.0/17 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.192.0/20 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
192.168.0.1/32 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
192.168.0.3/32 [BGP ] 00:00:15, localpref 100
AS path: 300 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
172.16.233.0/7 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
Meaning
The output shows some routing instability. Eleven routes are hidden due to damping.
Displaying the Details of a Damped Route
Purpose
Display the details of damped routes.
Action
From operational mode, enter the show route damping suppressed 172.16.192.0/20 detail command.
user@R2> show route damping suppressed 172.16.192.0/20
detail
inet.0: 15 destinations, 17 routes (6 active, 0 holddown, 11 hidden)
172.16.192.0/20 (1 entry, 0 announced)
BGP /-101
Next hop type: Router, Next hop index: 758
Address: 0x9414484
Next-hop reference count: 9
Source: 10.0.0.1
Next hop: 10.0.0.1 via fe-1/2/0.0, selected
Session Id: 0x100201
State: <Hidden Ext>
Local AS: 200 Peer AS: 100
Age: 52
Validation State: unverified
Task: BGP_100.10.0.0.1+55922
AS path: 100 I
Localpref: 100
Router ID: 192.168.0.1
Merit (last update/now): 4278/4196
damping-parameters: aggressive
Last update: 00:00:52 First update: 01:01:55
Flaps: 8
Suppressed. Reusable in: 01:14:40
Preference will be: 170
Meaning
This output indicates that the displayed route has a mask length that is equal to or greater than /17, and confirms that it has been correctly mapped to the aggressive damping profile. You can also see the route’s current (and last) figure of merit value, and when the route is expected to become active if it remains stable.
Verifying That Default Damping Parameters Are in Effect
Purpose
Locating a damped route with a /16 mask confirms that the default parameters are in effect.
Action
From operational mode, enter the show route damping suppressed detail | match 0/16 command.
user@R2> show route damping suppressed detail
| match 0/16172.16.0.0/16 (1 entry, 0 announced)
user@R2> show route damping suppressed 172.16.0.0/16
detail
inet.0: 15 destinations, 17 routes (6 active, 0 holddown, 11 hidden)
172.16.0.0/16 (1 entry, 0 announced)
BGP /-101
Next hop type: Router, Next hop index: 758
Address: 0x9414484
Next-hop reference count: 9
Source: 10.0.0.1
Next hop: 10.0.0.1 via fe-1/2/0.0, selected
Session Id: 0x100201
State: <Hidden Ext>
Local AS: 200 Peer AS: 100
Age: 1:58
Validation State: unverified
Task: BGP_100.10.0.0.1+55922
AS path: 100 I
Localpref: 100
Router ID: 192.168.0.1
Merit (last update/now): 3486/3202
Default damping parameters used
Last update: 00:01:58 First update: 01:03:01
Flaps: 8
Suppressed. Reusable in: 00:31:40
Preference will be: 170
Meaning
Routes with a /16 mask are not impacted by the custom damping rules. Therefore, the default damping rules are in effect.
To repeat, the custom rules are as follows:
Damp all prefixes with a mask length equal to or greater than 17 more aggressively than routes with a mask length between 9 and 16.
Damp routes with a mask length between 0 and 8, inclusive, less than routes with a mask length greater than 8.
Do not damp the 10.128.0.0/9 prefix at all.
Filtering the Damping Information
Purpose
Use OR groupings or cascaded piping to simplify the determination of what damping profile is being used for routes with a given mask length.
Action
From operational mode, enter the show route damping suppressed command.
user@R2> show route damping suppressed detail
| match "0 announced | damp"
0.0.0.0/0 (1 entry, 0 announced)
damping-parameters: timid
10.0.0.0/9 (1 entry, 0 announced)
Default damping parameters used
damping-parameters: aggressive
damping-parameters: aggressive
10.224.0.0/11 (1 entry, 0 announced)
Default damping parameters used
172.16.0.0/16 (1 entry, 0 announced)
Default damping parameters used
172.16.128.0/17 (1 entry, 0 announced)
damping-parameters: aggressive
172.16.192.0/20 (1 entry, 0 announced)
damping-parameters: aggressive
192.168.0.1/32 (1 entry, 0 announced)
damping-parameters: aggressive
192.168.0.3/32 (1 entry, 0 announced)
damping-parameters: aggressive
172.16.233.0/7 (1 entry, 0 announced)
damping-parameters: timid
Meaning
When you are satisfied that your EBGP routes are correctly associated with a damping profile, you can issue the clear bgp damping operational mode command to restore an active status to your damped routes, which will return your connectivity to normal operation.
Example: Configuring BGP Route Flap Damping Based on the MBGP MVPN Address Family
This example shows how to configure an multiprotocol BGP multicast VPN (also called Next-Generation MVPN) with BGP route flap damping.
Requirements
This example uses Junos OS Release 12.2. BGP route flap damping support for MBGP MVPN, specifically, and on an address family basis, in general, is introduced in Junos OS Release 12.2.
Overview
BGP route flap damping helps to diminish route instability caused by routes being repeatedly withdrawn and readvertised when a link is intermittently failing.
This example uses the default damping parameters and demonstrates an MBGP MVPN scenario with three provider edge (PE) routing devices, three customer edge (CE) routing devices, and one provider (P) routing device.
Figure 4 shows the topology used in this example.
On PE Device R4, BGP route flap damping is configured for address family inet-mvpn. A routing policy called dampPolicy uses the nlri-route-type match condition to damp only MVPN route types 3, 4, and 5. All other MVPN route types are not damped.
This example shows the full configuration on all devices in the CLI Quick Configuration section. The Configuring Device R4 section shows the step-by-step configuration for PE Device R4.
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.
Device R1
Device R2
Device R3
Device R4
Device R5
Device R6
Device R7
Configuring Device R4
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 Device R4:
Configure the interfaces.
[edit interfaces]user@R4# set ge-1/2/0 unit 10 family inet address 10.1.1.10/30user@R4# set ge-1/2/0 unit 10 family mplsuser@R4# set ge-1/2/1 unit 17 family inet address 10.1.1.17/30user@R4# set ge-1/2/1 unit 17 family mplsuser@R4# set vt-1/2/0 unit 4 family inetuser@R4# set lo0 unit 4 family inet address 172.16.1.4/32user@R4# set lo0 unit 104 family inet address 172.16.100.4/32Configure MPLS and the signaling protocols on the interfaces.
[edit protocols]user@R4# set mpls interface alluser@R4# set mpls interface ge-1/2/0.10user@R4# set rsvp interface all aggregateuser@R4# set ldp interface ge-1/2/0.10user@R4# set ldp p2mpConfigure BGP.
The BGP configuration enables BGP route flap damping for the inet-mvpn address family. The BGP configuration also imports into the routing table the routing policy called dampPolicy. This policy is applied to neighbor PE Device R2.
[edit protocols bgp group ibgp]user@R4# set type internaluser@R4# set local-address 172.16.1.4user@R4# set family inet-vpn unicastuser@R4# set family inet-vpn anyuser@R4# set family inet-mvpn signaling dampinguser@R4# set neighbor 172.16.1.2 import dampPolicyuser@R4# set neighbor 172.16.1.5Configure an interior gateway protocol.
[edit protocols ospf]user@R4# set traffic-engineering[edit protocols ospf area 0.0.0.0]user@R4# set interface alluser@R4# set interface lo0.4 passiveuser@R4# set interface ge-1/2/0.10Configure a damping policy that uses the nlri-route-type match condition to damp only MVPN route types 3, 4, and 5.
[edit policy-options policy-statement dampPolicy term term1]user@R4# set from family inet-mvpnuser@R4# set from nlri-route-type 3user@R4# set from nlri-route-type 4user@R4# set from nlri-route-type 5user@R4# set then acceptConfigure the damping policy to disable BGP route flap damping.
The no-damp policy (damping no-damp disable) causes any damping state that is present in the routing table to be deleted. The then damping no-damp statement applies the no-damp policy as an action and has no from match conditions. Therefore, all routes that are not matched by term1 are matched by this term, with the result that all other MVPN route types are not damped.
[edit policy-options policy-statement dampPolicy]user@R4# set then damping no-dampuser@R4# set then accept[edit policy-options]user@R4# set damping no-damp disableConfigure the parent_vpn_routes to accept all other BGP routes that are not from the inet-mvpn address family.
This policy is applied as an OSPF export policy in the routing instance.
[edit policy-options policy-statement parent_vpn_routes]user@R4# set from protocol bgpuser@R4# set then acceptConfigure the VPN routing and forwarding (VRF) instance.
[edit routing-instances vpn-1]user@R4# set instance-type vrfuser@R4# set interface vt-1/2/0.4user@R4# set interface ge-1/2/1.17user@R4# set interface lo0.104user@R4# set route-distinguisher 100:100user@R4# set vrf-target target:1:1user@R4# set protocols ospf export parent_vpn_routesuser@R4# set protocols ospf area 0.0.0.0 interface lo0.104 passiveuser@R4# set protocols ospf area 0.0.0.0 interface ge-1/2/1.17user@R4# set protocols pim rp static address 172.16.100.2user@R4# set protocols pim interface ge-1/2/1.17 mode sparseuser@R4# set protocols mvpnConfigure the router ID and the autonomous system (AS) number.
[edit routing-options]user@R4# set router-id 172.16.1.4user@R4# set autonomous-system 1001If you are done configuring the device, commit the configuration.
user@R4# commit
Results
From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
Verification
Confirm that the configuration is working properly.
Verifying That Route Flap Damping Is Disabled
Purpose
Verify the presence of the no-damp policy, which disables damping for MVPN route types other than 3, 4, and 5.
Action
From operational mode, enter the show policy damping command.
user@R4> show policy dampingDefault damping information:
Halflife: 15 minutes
Reuse merit: 750 Suppress/cutoff merit: 3000
Maximum suppress time: 60 minutes
Computed values:
Merit ceiling: 12110
Maximum decay: 6193
Damping information for "no-damp":
Damping disabledMeaning
The output shows that the default damping parameters are in effect and that the no-damp policy is also in effect for the specified route types.
Verifying Route Flap Damping
Purpose
Check whether BGP routes have been damped.
Action
From operational mode, enter the show bgp summary command.
user@R4> show bgp summaryGroups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l3vpn.0
6 6 0 0 0 0
bgp.l3vpn.2
0 0 0 0 0 0
bgp.mvpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.2 1001 3159 3155 0 0 23:43:47 Establ
bgp.l3vpn.0: 3/3/3/0
bgp.l3vpn.2: 0/0/0/0
bgp.mvpn.0: 1/1/1/0
vpn-1.inet.0: 3/3/3/0
vpn-1.mvpn.0: 1/1/1/0
172.16.1.5 1001 3157 3154 0 0 23:43:40 Establ
bgp.l3vpn.0: 3/3/3/0
bgp.l3vpn.2: 0/0/0/0
bgp.mvpn.0: 1/1/1/0
vpn-1.inet.0: 3/3/3/0
vpn-1.mvpn.0: 1/1/1/0Meaning
The Damp State field shows that zero routes in the bgp.mvpn.0 routing table have been damped. Further down, the last number in the State field shows that zero routes have been damped for BGP peer 172.16.1.2.
See also
Understanding BGP-Static Routes for Preventing Route Flaps
BGP-static routes can be configured to ensure that a prefix does not flap. BGP-static routes do not flap unless they are deleted manually. If the BGP-static routes are configured globally, then each neighbor, group, or all neighbors must be explicitly configured to receive them. Peer routers receive advertisements for these routes regardless of dynamic routing information learned by the advertising router for those prefixes. Despite being the active route, BGP-static routes are never advertised to a BGP neighbor for which they are not configured. You can specify any number of BGP-static routes in the configuration. You can also define a policy to specify which BGP-static routes need to be advertised and included in a BGP advertisement.
BGP-static routes are placed in the routing table. If the BGP-static routes are active routes (if there are no other routes for that prefix), they are placed in the forwarding table. These routes are advertised only to those BGP hosts that are configured to receive them. The configured BGP-static routes are not advertised by any other protocol besides BGP. Service providers who have one or more single-homed customers can configure BGP-static routes on a BGP network to advertise static paths for these customers.
Configuring the advertisement of BGP-static routes at the neighbor level causes an internal group split. Configure the advertisement of BGP-static routes only at the global and group levels to keep the configuration simple. The configured BGP-static routes do not affect the VPN routes that are advertised.
If a BGP-static route is advertised to a neighbor, it is the only route advertised for the prefix. BGP-static routes are not considered as candidate routes for BGP multipath or protocol-independent multipath. They do not cause an aggregate or generated route to be added to the routing table.
Configuring BGP-static routes on networks that are accessible by multiple paths and are not the only point of access to all of the paths might cause traffic to be silently dropped or discarded. In a multihomed network, BGP-static routes can be configured on devices that are the only point of access to other paths. By default, all BGP-static routes that are advertised to the internal peers include a local-pref value of 0 to mitigate the risk of a null route for multihomed networks. You can override this default value by setting an explicit preference2 value on the BGP-static routes.
Configuring BGP-Static Routes for Preventing Route Flaps
BGP-static routes are configured to ensure that routes to a customer network do not flap. The configured BGP-static routes are not advertised by any other protocol besides BGP. BGP-static routes are configured globally, but each neighbor, group, or all neighbors must be explicitly configured to receive them. Peer routers will receive advertisements for these routes regardless of dynamic routing information learned by the advertising router for those prefixes. You can specify any number of BGP-static routes in the configuration. You can also define a policy to specify which BGP-static routes need to be advertised.
Before you configure BGP-static routes:
- Ensure that the IGP and BGP protocols are configured and working.
- Ensure that BGP-static route that you configure is behind
a customer router.
Do not use BGP-static routes for prefixes that BGP uses to reach BGP neighbors.
To configure BGP-static routes:
- Configure a BGP-static route for a customer router on
a BGP network to advertise static paths for these customers.
You can also configure other configuration options such as as-path, color, community, tag, and preference as needed.
[edit routing-options]user@host# set bgp-static route destination-prefix - Configure the BGP groups or the BGP neighbors that are
to receive the BGP-static route advertisements.
You can also configure this statement at a global level if you want every host on the BGP network to receive the BGP-static advertisements.
[edit protocols bgp]user@host# set advertise-bgp-static - (Optional) Specify an additional export policy to control
whether or not a given BGP-static route needs to be advertised.
The policy is applied to the BGP-static route and not the active route.
[edit policy-options policy-statement policy name]user@host# set from prefix-list xyzuser@host# set then accept - Apply the defined policy to a BGP group or neighbor.[edit protocols bgp group group-name]user@host# set advertise-bgp-static export policy name
See also
Example: Configuring BGP-Static Routes to Prevent Route Flaps
This example shows how to configure BGP-static routes. BGP hosts advertise these BGP-static routes only to those neighbors who are configured to receive these routes. A BGP-static route is configured to ensure that a prefix does not flap. However, If the BGP-static routes are configured globally, then each neighbor, group, or all neighbors must be explicitly configured to receive them.
Requirements
This example uses the following hardware and software components:
Seven MX Series routers with BGP enabled on the connected interfaces
Junos OS Release 14.2 or later running on all devices
Overview
Beginning with Junos OS Release 14.2, you can configure and advertise BGP-static routes in a BGP network. You can advertise a BGP-static route in a BGP network even if it is not the active route for the prefix. BGP-static routes do not flap unless they are deleted manually. You can define a policy that determines which BGP-static routes need to be advertised and included in the advertisements. Peer routers receive advertisements for these BGP-static routes regardless of dynamic routing information learned by the advertising router.
In the sample BGP network, Devices CE1, CE2, and CE3 are directly connected to Routers PE1, PE2, and PE3. Both PE1 and PE2 are connected to Router P. Router P is directly connected to Router PE3. EBGP is configured on the provider edge and customer edge routers. IBGP is configured on directly connected provider edge routers. The IGP protocol IS-IS is configured on all provider routers. Configure a BGP-static route on Router PE1 to ensure that customer route 10.0.0.28 behind CE1 does not flap. Provider Router PE2 is configured to receive the BGP-static route. The objective is to advertise a BGP-static route only to CE2 and not to CE3, and to demonstrate that the configured BGP-static route does not flap.
Topology
Figure 5 shows the sample topology.
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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Router P
Router PE1
Router PE2
Router PE3
Router CE1
Router CE2
Router CE3
Step-by-Step Procedure
The following example requires that you 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 Router PE1:
- Configure the interfaces with IPv4 addresses.[edit interfaces]user@PE1# set ge-1/0/0 unit 1 description PE1->Puser@PE1# set ge-1/0/0 unit 1 family inet address 10.0.0.1/29user@PE1# set ge-1/1/0 unit 10 description PE1->CE1user@PE1# set ge-1/1/0 unit 10 family inet address 10.0.0.10/30
- Enable the IS-IS protocol on interfaces connected to provider
routers for learning and exchanging routes learned.[edit interfaces]user@PE1# set ge-1/0/0 unit 1 family iso
- Configure loopback addresses for inet and IS-IS.[edit interfaces lo0 unit 0]user@PE1# set family inet address 10.255.102.128/32user@PE1# set family iso address 49.0001.1720.1600.1010.00
- Configure the IS-IS interfaces.[edit protocols isis]user@PE1# set interface ge-1/0/0.1user@PE1# set interface lo0.0 passive
- Configure EBGP.[edit protocols bgp group ebgp]user@PE1# set type externaluser@PE1# set peer-as 64497user@PE1# set neighbor 10.0.0.9 description CE1user@PE1# set neighbor 10.0.0.9 local-address 10.0.0.10
- Configure an IBGP neighbor on internal routers connected
to the provider network.[edit protocols bgp group ibgp]user@PE1# set type internaluser@PE1# set local-address 10.255.102.128user@PE1# set export export-selfuser@PE1# set neighbor 10.255.102.146 description Puser@PE1# set neighbor 10.255.102.178 description PE2user@PE1# set neighbor 10.255.102.156 description PE3
- Configure the BGP static route.[edit routing-options]user@PE1# set bgp-static route 10.0.0.28/32 preference2 4294967195user@PE1# set bgp-static route 10.0.0.28/32 as-path path 64497
- Configure the BGP neighbor PE2 to receive BGP-static advertisements.[edit protocols bgp group ibgp neighbor 10.255.102.178]user@PE1# set advertise-bgp-static
- Define a policy to export routes to the BGP network.[edit policy-options policy-statement export-self]user@PE1# set then next-hop self
- Apply the policy to the IBGP group.[edit protocols bgp group ibgp]user@PE1# set export export-self
- Configure the router id and the autonomous system (AS)
number.[edit routing-options]user@PE1# set router-id 10.255.102.128user@PE1# set autonomous-system 64496
Results
From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying That the Configured Hosts Receive the BGP-Static Routes
Verifying That the Configured BGP-Static Route Does Not Flap
Verifying the BGP Neighbors
Purpose
Verify that BGP is running on the configured interfaces and that the BGP session is active for each neighbor address.
Action
From operational mode, run the show bgp neighbor command on Router PE1.
user@PE1> show bgp neighborPeer: 10.0.0.9+34260 AS 64497 Local: 10.0.0.10+45824 AS 64496
Description: CE1
Type: External State: Established Flags: <sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Cease
Options: <Preference LocalAddress PeerAS Refresh>
LocalAddress: 10.0.0.10 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 127.255.102.166 Local ID: 10.255.102.128 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0
BFD: disabled, down
Local Interface: ge-1/1/0.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 64497)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 14 Sent 13 Checked 4
Input messages: Total 249 Updates 2 Refreshes 0 Octets 4764
Output messages: Total 250 Updates 2 Refreshes 0 Octets 4883
Peer: 10.255.102.146+179 AS 64496 Local: 10.255.102.128+53460 AS 64496
Description: P
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ export-self ]
Options: <Preference LocalAddress Refresh>
Local Address: 10.255.102.128 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.255.102.146 Local ID: 10.255.102.128 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer does not support LLGR Restarter functionality
Peer supports 4 byte AS extension (peer-as 64496)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 12 Sent 1 Checked 63
Input messages: Total 246 Updates 1 Refreshes 0 Octets 4678
Output messages: Total 249 Updates 1 Refreshes 0 Octets 4834
Output Queue[0]: 0 (inet.0, inet-unicast)
Peer: 10.255.102.178+53463 AS 64496 Local: 10.255.102.128+179 AS 64496
Description: PE2 Type: Internal State: Established Flags: <Synch>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ export-self ]
Options: <Preference LocalAddress Refresh>
Options: <AdvertiseBGPStatic>
Local Address: 10.255.102.128 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.255.102.178 Local ID: 10.255.102.128 Active Holdtime: 90
Keepalive Interval: 30 Group index: 1 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer does not support LLGR Restarter functionality
Peer supports 4 byte AS extension (peer-as 64496)
Peer does not support Addpath
Table inet.0 Bit: 10002
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 9 Sent 10 Checked 22
Input messages: Total 247 Updates 2 Refreshes 0 Octets 4777
Output messages: Total 248 Updates 1 Refreshes 0 Octets 4815
Output Queue[0]: 0 (inet.0, inet-unicast)
Peer: 10.255.102.156+179 AS 64496 Local: 10.255.102.128+53462 AS 64496
Description: PE3
Type: Internal State: Established Flags: <Synch>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ export-self ]
Options: <Preference LocalAddress Refresh>
Local Address: 10.255.255.11 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.255.102.156 Local ID: 10.255.102.128 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer does not support LLGR Restarter functionality
Peer supports 4 byte AS extension (peer-as 64496)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 21 Sent 10 Checked 10
Input messages: Total 245 Updates 2 Refreshes 0 Octets 4695
Output messages: Total 247 Updates 1 Refreshes 0 Octets 4796
Output Queue[0]: 0 (inet.0, inet-unicast) Meaning
The output displays the BGP neighbors of Router PE1 and the configured BGP options such as whether the neighbor is configured to receive BGP-static routes. Router PE2 is configured to receive BGP-static route advertisements.
Verifying BGP Groups
Purpose
Verify that the intended BGP groups or neighbors are configured to receive the BGP-static routes.
Action
From operational mode, run the show bgp group command.
user@PE1> show bgp groupGroup Type: External Local AS: 64496 Name: ebgp Index: 3 Flags: <Export Eval> Holdtime: 0 Local AS: 64496 Local System AS: 64496 Total peers: 1 Established: 1 10.0.0.9+179 inet.0: 0/1/1/0 Group Type: Internal AS: 64496 Local AS: 64496 Name: ibgp Index: 0 Flags: <Export Eval> Export: [ export-self ] Options: <AdvertiseBGPStatic> Holdtime: 0 Total peers: 1 Established: 1 10.255.102.178+179 inet.0: 0/0/0/0 Group Type: Internal AS: 64496 Local AS: 64496 Name: ibgp Index: 0 Flags: <Export Eval> Export: [ export-self ] Holdtime: 0 Total peers: 2 Established: 2 10.255.102.156+179 10.255.102.146+179 inet.0: 0/3/2/0 Groups: 3 Peers: 4 External: 1 Internal: 3 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 3 3 0 0 0 0
Meaning
The output shows the BGP neighbor that is configured to receive BGP-static advertisements.
Verifying the Routes
Purpose
Verify that the configured BGP-static route is saved in the routing table of the configured BGP neighbors.
Action
From operational mode, run the show route protocol bgp-static command to display the routing table.
user@PE1> show route protocol bgp-staticinet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.28/32 *[BGP-Static/4294967292/-101] 00:43:15
Discard
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
inet6.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)User@PE1> show route 10.0.0.28/32
inet.0: 13 destinations, 14 routes (13 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.28/32 *[BGP/170] 00:00:15, localpref 100
AS path: 64497 I, validation-state: unverified
> to 10.0.0.9 via ge-2/1/8.0
[BGP-Static/4294967292/-101] 02:42:51
DiscardMeaning
The output shows the BGP-static route configured on the device. The active path is learned from CE1, and the BGP-static route is inactive.
Verifying That the Configured Hosts Receive the BGP-Static Routes
Purpose
Verify that the BGP-static route is being advertised to the host configured to receive it.
Action
On Devices CE2 and CE3, from operational mode, run the show route protocol bgp command to display the learned routes in the routing table.
user@CE2> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.28/32 *[BGP/170] 01:52:10, localpref 100
AS path: 64496 64497 I, validation-state: unverified
> to 10.0.0.14 via ge-2/0/0.13
1.0.0.29/32 *[BGP/170] 01:52:06, localpref 100
AS path: 64496 64499 I, validation-state: unverified
> to 10.0.0.14 via ge-2/0/0.13
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
user@CE3> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.28/32 *[BGP/170] 01:52:19, localpref 100
AS path: 64496 64497 I, validation-state: unverified
> to 10.0.0.18 via ge-2/0/5.17
1.0.0.29/32 *[BGP/170] 01:52:15, localpref 100
AS path: 64496 64498 I, validation-state: unverified
> to 10.0.0.18 via ge-2/0/5.17
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Meaning
Both Devices CE2 and CE3 have a route to 10.0.0.28/32. CE2 has received the BGP-static route and CE3 has received a dynamically-learned route, but you cannot tell the difference.
Verifying That the Configured BGP-Static Route Does Not Flap
Purpose
Verify that the BGP-static route does not flap even when the BGP peering session between Router PE1 and Device CE1 goes down.
Action
Deactivate the BGP peering session between Router PE1 and Device CE1. PE1 does not have a dynamically learned route to 10.0.0.28/32, but still has the configured BGP-static route.
user@PE1> show route 10.0.0.28/32 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.28/32 *[BGP-Static/4294967292/-101] 02:46:21
Discarduser@CE2> show route protocol bgpinet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.28/32 *[BGP/170] 01:52:48, localpref 100
AS path: 64496 64497 I, validation-state: unverified
> to 10.0.0.18 via ge-2/0/5.17
1.0.0.29/32 *[BGP/170] 01:52:44, localpref 100
AS path: 64496 64499 I, validation-state: unverified
> to 10.0.0.18 via ge-2/0/5.17
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)user@CE3> show route protocol bgpinet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.29/32 *[BGP/170] 01:52:47, localpref 100
AS path: 64496 64498 I, validation-state: unverified
> to 10.0.0.18 via ge-2/0/5.17
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Meaning
Router PE1 and Device CE2 still have the configured BGP-static route. However, Device CE3 does not have the route to 10.0.0.28/32 because this prefix has flapped. BGP-static routes do not flap unless deleted manually.