Description

The customer has configured a strict BGP hold time of 20 seconds between the route reflector (RR) and its clients. Both the RR and client devices are non-Juniper, and they connect via a transit Juniper PTX10K16 router.

 

RR_SRV (XXXX:506:100:XXXX::X) --- Transit_Juniper_1 <AE10/AE11/AE1.20/AE2.20/AE3.20> Transit_Juniper_2 --- RR_Client 

 

In this setup, there are five ECMP paths between Transit_Juniper_1 and Transit_Juniper_2: The customer reported that BGP IPv6 RR sessions flap when interfaces AE10/AE11 recover after a failure. 

 

Primary Path: AE10 and AE11

Fallback Path: AE1.20, AE2.20, and AE3.20 (used when AE10/AE11 are down)

 

 

A static supernet route (XXXX:506:100:XXXX::/64) is configured on Transit_Juniper_2, pointing to a discard route. This ensures that if a more specific route is temporarily unavailable—such as during link recovery—Transit_Juniper_2 drops packets via the supernet route until a valid route is reinstalled in the routing table. This setup helps prevent unintended traffic forwarding during route convergence. However, it may contribute to BGP session flaps if the valid route is delayed beyond the configured hold time.

 

Symptoms

In one instance where the issue was observed, the adjacency over AE10 came up first, but the interface was marked with the "Tentative" flag and remained in that state for about 12 seconds after the adjacency was established. Meanwhile, the AE11 interface was up and did not have the Tentative flag, yet the ISIS adjacency took longer to come up on it.

 

At 11:12:18 IST, ISIS adjacency was successfully established on interface AE10.0.

---(refreshed at 2025-09-20 11:12:18 IST)---

   ae10.0        Transit_Juniper_1 1 Up          2

   ae11.0        Transit_Juniper_2 1 New          2

 

After the ISIS adjacency on AE10.0 came up at 11:12:18 IST, the route to RR_SRV (XXXX:506:100:XXXX::X) began pointing to a discard route. Prior to this, the route was correctly forwarding traffic via AE1.20, AE2.20, and AE3.20.

 ---(refreshed at 2025-09-20 11:12:18 IST)---

   inet6.0: 555097 destinations, 555100 routes (552586 active, 2503 holddown, 8 hidden)

   + = Active Route, - = Last Active, * = Both

   XXXX:506:100:XXXX::/64

                 *[Static/254] 1d 22:59:23

                    Discard

 

The output of show interface extensive for AE10.0 indicates the IPv6 address is in a Tentative state due to Duplicate Address Detection (DAD). The DAD flag remains set for approximately 10 seconds during this process, which is expected behavior while the system verifies address uniqueness.

---(refreshed at 2025-09-20 11:12:28 IST)---

    Device flags  : Present Running

    Interface flags: SNMP-Traps Internal: 0x4000

      Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2

       Flags: Sendbcast-pkt-to-re

       Addresses, Flags: Is-Preferred Is-Primary

       Flags: Is-Primary

      Protocol inet6, MTU: 9178

       Addresses, Flags: Is-Preferred Is-Primary

         INET6 Address Flags: Tentative

       Addresses, Flags: Is-Preferred

         INET6 Address Flags: Tentative                     <<< Tentative flag set on AE10. 

       Flags: Is-Primary

       Flags: Is-Primary

 

The specific route to RR_SRV (XXXX:506:100:XXXX::X) is now installed via AE10.0. This occurred after IPv6 Duplicate Address Detection (DAD) completed and the ISIS Shortest Path First (SPF) algorithm identified AE10.0 as the optimal path to reach RR_SRV.

 

 ---(refreshed at 2025-09-20 11:12:30 IST)---

   inet6.0: 555098 destinations, 555101 routes (555090 active, 0 holddown, 8 hidden)

   + = Active Route, - = Last Active, * = Both

   XXXX:506:100:XXXX::X/128

                 +[IS-IS/15] 00:00:01, metric 110

                  > to fe80::e59:9cff:fe23:16bd via ae10.0            

 

Solution

When the link becomes operational after a failure, the ISIS adjacency over it comes up. Based on the SPF calculation, IPv4 prefers the new path. However, in rare instances, IPv6 Neighbor Discovery (ND) may not have completed due to the Duplicate Address Detection (DAD) hold time interval. Since this is an ISIS single-topology configuration, the ISIS SPF process does not wait for IPv6 ND to complete and selects the new path as the best route for IPv6 as well. As ND is still pending on the new path, IPv6 routes cannot be installed via ISIS. Consequently, alternate protocol (static/BGP/...) routes may be preferred for IPv6 until ND completes

 

Based on IS-IS best practice guidelines, the following configuration knobs are suggested to help mitigate the issue.

Enable "toplogy ipv6-unicast” knob under isis

or 

Enable “strict-dual-isis” knob under isis

Modification History

2025-10-06 : Article Created