Description

When there is an issue with a middle device (any L3, L2 or L1 devices) which causes BGP packet loss or a firewall filter is used to block live traffic to simulate the issue, the BGP session will be down but the interface is still up. The status of the received routes from this BGP neighbor might become 'Stale Accept' and the related stale prefixes still exist in the routing table for approximately 2 minutes. This  behavior is expected if the BGP neighbor device is configured with the graceful-restart feature.

Symptoms

The following excerpts are from the defined graceful restart rules of RFC 4724 :

4.1.  Procedures for the Restarting Speaker                                ## BGP neighbor

   When the Restarting Speaker restarts, it MUST retain, if possible,
   the forwarding state for the BGP routes in the Loc-RIB and MUST mark
   them as stale.  It MUST NOT differentiate between stale and other
   information during forwarding.

4.2.  Procedures for the Receiving Speaker                                  ## the DUT device
   [...]
   When the Receiving Speaker detects termination of the TCP session for
   a BGP session with a peer that has advertised the Graceful Restart
   Capability, it MUST retain the routes received from the peer for all
   the address families that were previously received in the Graceful
   Restart Capability and MUST mark them as stale routing information.

If the BGP neighbor device is configured with the graceful-restart feature, which is the default behavior for some 3rd party devices, and firewall filter is used to block live traffic to simulate packet loss, when the firewall filter is committed, and the Juniper router detects BFD and BGP sessions to be down (TCP session down, not interface down), the DUT router would still keep stale prefixes received from the BGP neighbor for 2 minutes as RFC complied.

Only BGP (TCP session) down, interface still up:

admin@router> show interfaces ae101.14 terse 
Interface               Admin Link Proto    Local                 Remote
ae101.14                up    up   inet     10.4.54.57/30   
                                   multiservice

The status of the routes from the BGP neighbor becomes 'Stale Accepted' and the prefixes will still be in the routing table for about 2 minutes:

admin@router> show route table test.inet.0 10.56.0.158 extensive       

test.inet.0: 26 destinations, 31 routes (26 active, 0 holddown, 0 hidden)
10.56.0.158/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.56.0.158/32 -> {10.4.54.58}
Page 0 idx 1, (group PROD_GROUP_iBGP type Internal) Type 1 val 0x4a25868 (adv_entry)
   Advertised metrics:
     Flags: Nexthop Change
     Nexthop: Self
     Localpref: 140
     AS path: [64790] 64696 I
     Communities: target:101:1
     VPN Label: 40
    Advertise: 00000007
Path 10.56.0.158
from 10.4.54.58
Vector len 4.  Val: 1
        *BGP    Preference: 170/-141
                Next hop type: Router, Next hop index: 762
                Address: 0x4e166dc
                Next-hop reference count: 11
                Source: 10.4.54.58
                Next hop: 10.4.54.58 via ae101.14, selected
                Session Id: 0x154
                State: <Active Ext>
                Peer AS: 64696
                Age: 2:13 
                Validation State: unverified 
                Task: BGP_64696.10.4.54.58
                Announcement bits (2): 0-KRT 2-BGP_RT_Background 
                AS path: 64696 I 
                Stale Accepted
                Localpref: 140
                Router ID: 10.56.0.151

Solution

To reduce the time period of stale routes existing in the route table, the workaround is to set stale-time to 1 second (minimum value) via following the hidden command:

set routing-instances <> protocols bgp family inet unicast graceful-restart long-lived restarter stale-time <1..16777215>

Note: The word ' long-lived ' is a hidden command, please type in directly.