BGP Unnumbered and Router Advertisements: Disabling RA Is Not Silence, It Is Withdrawal

Following on from the BGP unnumbered underlay, what the documentation adds up to is this: in a BGP unnumbered scenario that relies on dynamic peer discovery, the Router Advertisement in IPv6 Neighbor Discovery is the mechanism that discovers the far end and triggers creation of the BGP neighbour. And during the lab it turned out that disabling RA does considerably more than block discovery of new neighbours.

Neither Cisco’s nor Arista’s documentation says this outright. Only Juniper’s states plainly that it must be enabled:

BGP determines the address families to peer over based on the configuration. The peering sessions come up based on availability of the interface addresses for the determined families. The peer link-local address is discovered using IPv6 neighbor discovery (RFC4861) and creates a BGP session toward that neighbor. A link-local address is generated even when IPv6 interfaces have no addresses configured.

Note: You must enable IPv6 neighbor discovery for this feature to work.

In Wireshark, icmpv6.type == 134 filters these out. The message is defined by RFC 4861: a router periodically, or in response to a solicitation, advertises its own presence along with default gateway status, address prefixes, MTU and other parameters for hosts to autoconfigure from.

In this environment, Arista defaults to one every 200 seconds with a lifetime of 1800 seconds.

Arista#show ipv6 interface ethernet 1
  ND router advertisements are sent every 200 seconds
  ND router advertisements live for 1800 seconds

Cisco’s interval here is 200 to 600 seconds, also with a lifetime of 1800 seconds.

show ipv6 nd interface ethernet 1/1
  Router-Advertisement parameters:
      Periodic interval: 200 to 600 seconds
      Send "Router Lifetime" field: 1800 secs

Which raises the question: does lengthening the interval, shortening it, or turning it off affect existing neighbours — and new ones? Time to find out.

Note: the experiments in the sections below were run at different times and the environment was rebuilt in between, so the peer link-local addresses are not consistent across every output.

Current neighbour state#

Arista interface configuration:

Spine01(config-if-Et1)#show run int e 1
interface Ethernet1
   no switchport
   ipv6 enable

Cisco interface configuration:

interface Ethernet1/1
  no switchport
  ip forward
  ipv6 address use-link-local-only
  no shutdown

The BGP neighbour is healthy at this point:

Cisco(config-if)# show bgp sessions 
Total peers 1, established peers 1
ASN 65001
VRF default, local ASN 65001
peers 1, established peers 1, local router-id 10.100.0.2
State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown

Neighbor        ASN    Flaps LastUpDn|LastRead|LastWrit St Port(L/R)  Notif(S/R)
fe80::5264:47ff:fe5d:ab3%Ethernet1/1
                65000 0     00:09:28|00:00:26|00:00:27 E   25951/179        0/0

First, check whether changing the transmission interval has any effect.

Changing the RA interval#

Setting the RA interval to 1800 seconds on Cisco with ipv6 nd ra-interval 1800, the system automatically sets the minimum interval to 600 — after which the interval is a random value between 600 and 1800.

Cisco(config)# int e 1/1
Cisco(config-if)# ipv6 nd ra-interval 1800 
Warning: Setting value of ra-min-interval to 600

That automatic rewrite of the minimum is not arbitrary. RFC 4861 defines a default MaxRtrAdvInterval of 600 seconds and a default MinRtrAdvInterval of 0.33 × Max, i.e. 200 seconds — which matches the 200–600 default range Cisco showed above.

And as shown below, changing the RA interval does not affect the existing neighbour.

Cisco(config-if)# show bgp sessions 
Total peers 1, established peers 1
ASN 65001
VRF default, local ASN 65001
peers 1, established peers 1, local router-id 10.100.0.2
State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown

Neighbor        ASN    Flaps LastUpDn|LastRead|LastWrit St Port(L/R)  Notif(S/R)
fe80::5264:47ff:fe5d:ab3%Ethernet1/1
                65000 0     00:10:57|00:00:18|00:00:56 E   25951/179        0/0

Now to check new neighbours. Taking a shortcut and testing within the existing setup: running shutdown on interface 1 of both the Arista and the Cisco tears down the neighbour and clears the IPv6 neighbour table. I will not show that step.

Since the change was made on the Cisco side, the verification has to happen on Arista. As shown below, there are no BGP neighbours at all. Next, check on Cisco.

Arista(config-if-Et1)#show bgp summary 
BGP summary information for VRF default
Router identifier 10.100.0.1, local AS number 65000
Neighbor          AS Session State AFI/SAFI                AFI/SAFI State   NLRI Rcd   NLRI Acc
-------- ----------- ------------- ----------------------- -------------- ---------- ----------
Arista(config-if-Et1)#

As shown below, Cisco has discovered a neighbour but no packets are being exchanged. What is going on? Time for Wireshark again, to see whether there are any clues in there.

Cisco(config-if)# show bgp sessions 
Total peers 1, established peers 0
ASN 65001
VRF default, local ASN 65001
peers 1, established peers 0, local router-id 10.100.0.2
State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown

Neighbor        ASN    Flaps LastUpDn|LastRead|LastWrit St Port(L/R)  Notif(S/R)
fe80::5264:47ff:fe5d:ab3%Ethernet1/1
                65000 0     00:00:25|never   |never    A   0/0          0/0

The packets did turn up some clues. When the Arista interface comes up it immediately emits an RA; Cisco receives it and triggers an NS to resolve Arista’s MAC address; and once it has the MAC, the BGP TCP handshake begins.

Note: this lab runs on an emulator. When the interconnecting cable is disconnected the interface still stays UP — it cannot negotiate UP/DOWN in real time the way a physical interface on real hardware does. Whichever side runs no shutdown first never receives an RA, and so never triggers the BGP TCP handshake. Manually flapping the interface forces an RA immediately.

Here I simply waited, to see whether Arista would enter BGP negotiation on receiving the next RA.

As shown below, at 17:49:23 Cisco sent an RA, and on receiving it Arista went straight into the BGP negotiation phase and through to an established neighbour. Why was there no NS this time, unlike before? Because Arista already has the ND cache entry and therefore already knows the peer’s MAC address. I will not expand on that here — it comes up again later.

What the experiment above establishes is that RA cannot be turned off: with it off, the far end cannot create the dynamic neighbour object, and so BGP negotiation cannot happen.

Separately, if you are enabling BGP unnumbered, lowering the RA interval can meaningfully speed up BGP convergence in certain situations. What value is appropriate? Let me see whether there is any published recommendation.

Cisco does document one (source):

BGP requires faster convergence time for route advertisements. To speed up detection of the Route Advertisement (RA) link-level protocol, enter the following commands on each IPv6-enabled interface that is using BGP Interface Peering via IPv6 Link-Local for IPv4 and IPv6 Address Families:

interface Ethernet port/slot
ipv6 nd ra-interval 4 min 3
ipv6 nd ra-lifetime 10

RFC 4861 requires AdvDefaultLifetime to be either 0 or not less than MaxRtrAdvInterval, so a lifetime of 10 paired with an interval of 4 satisfies that constraint.

One thing worth stating clearly: lowering the RA interval speeds up re-discovery, not fault detection. BFD is what detects failures quickly; the two act at different stages and are not substitutes for one another. Where BFD is used for fast failure detection, leaving RA at its default long interval means neighbour re-discovery can still become the thing you wait on during recovery — which is exactly why Cisco recommends lowering the RA interval for BGP interface peering. This article does not include a dedicated BFD experiment; the point here is only to mark the boundary between the two.

ND cache and BGP peer discovery: two different layers of state#

The previous section left a question open: on the second negotiation, why did Arista go straight into the BGP handshake after receiving the RA, instead of first sending an NS to resolve the MAC as it did the first time? The answer is that the ND cache already had the peer’s entry. Following that observation further leads to a conclusion that is easy to misread.

Forcing BGP back to a non-established state — Cisco stuck in Connect, continuously retransmitting SYN — and then checking the ND table on Arista:

Arista(config-if-Et1)#show ipv6 neighbors
IPv6 Address                                  Age Hardware Addr   Interface
fe80::52a8:5cff:fe9c:8f42                 0:00:12 50a8.5c9c.8f42  Et1

BGP plainly cannot come up, and yet the ND cache holds a perfectly stable entry pointing at Cisco’s link-local address, with the Age refreshing continuously. An entry for the peer in the ND cache does not mean BGP is in a position to establish — these are two independent mechanisms behind two separate things.

As shown below, in this capture the repeated creation and refreshing of that ND cache entry is driven mainly by NS/NA address resolution, not by periodic RA. Filtering on icmpv6.type==134 or icmpv6.type==135, Cisco sent no RA at all across the whole window, while both sides continuously exchanged NS (Neighbor Solicitation, type 135), each carrying the Source Link-Layer Address option. The address resolution and cache refresh observed in this experiment do not depend on periodic RA.

That said, when NS gets triggered and how often does depend on BGP’s current state:

You can verify this by hand: clear ipv6 neighbors to empty it, wait ten-odd seconds (long enough to cover one of Cisco’s SYN retransmission cycles), and the entry reappears. This is not leftover cache that failed to clear — it is Cisco continuing to attempt the TCP connection during BGP Connect, which re-triggers ND when the Neighbor Cache needs re-resolution or confirmation, causing the cleared entry to come back:

Arista(config-if-Et1)#clear ipv6 neighbors
Arista(config-if-Et1)#show ipv6 neighbors
IPv6 Address                                  Age Hardware Addr   Interface
Arista(config-if-Et1)#
(after about 15 seconds)
Arista(config-if-Et1)#show ipv6 neighbors
IPv6 Address                                  Age Hardware Addr    State Interface
fe80::5200:3ff:fe00:1b08                  0:04:59 5000.0300.1b08   REACH Et1

Disabling RA: not ceasing to transmit, but an explicit withdrawal#

Up to this point, the natural guess is: since an established session is maintained by keepalives, disabling RA should not affect it immediately — the problem should only surface once the interface flaps and the discovery process has to run again.

The actual result overturns that guess. Running ipv6 nd suppress-ra under the interface on the Cisco side, the BGP neighbour on Arista disappears instantly — no flap required, and no timeout to wait out:

Arista(config-if-Et1)#show bgp summary
BGP summary information for VRF default
Router identifier 10.100.0.1, local AS number 65000
Neighbor          AS Session State AFI/SAFI                AFI/SAFI State   NLRI Rcd   NLRI Acc
-------- ----------- ------------- ----------------------- -------------- ---------- ----------
Arista(config-if-Et1)#

This shows that disabling RA is not a matter of quietly ceasing to transmit and letting the far end age out — it triggers an explicit withdrawal. RFC 4861 §6.2.5 specifies this: when a router ceases to be a router, it should send a final RA with a Router Lifetime of 0, actively notifying every node on the link. On receiving an RA with Router Lifetime=0, the peer immediately removes that node from its Default Router List. In the Arista dynamic BGP neighbour implementation used in this lab, that in turn triggers withdrawal of the corresponding dynamic BGP neighbour object, so the BGP session disappears immediately. The packet below confirms this line of reasoning — Cisco sets the RA lifetime to 0:

Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x3e19 [correct]
    [Checksum Status: Good]
    Cur hop limit: 64
    Flags: 0x00, Prf (Default Router Preference): Medium
    Router lifetime (s): 0
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Source link-layer address : 50:00:03:00:1b:08)
    ICMPv6 Option (MTU : 1500)

Timeout and withdrawal are two completely different causal paths. That also explains why there is no need to wait out the 1800-second lifetime — this path never goes through ageing at all.

Conclusion#

From the experiments above, in the dynamic-peer-discovery BGP unnumbered scenario verified in this article:

• RA is responsible for discovery and withdrawal of dynamic peers. Disabling RA not only blocks discovery of new neighbours, it can also immediately trigger withdrawal of an established dynamic neighbour via Router Lifetime=0.
• NS/NA is responsible for layer 2 address resolution of IPv6 neighbours. An entry for the peer in the ND cache does not mean BGP is in a position to establish.
• Lowering the RA interval speeds up neighbour re-discovery but cannot replace BFD. RA and BFD act at two different stages — re-discovery and fault detection respectively. This article does not include dedicated BFD verification; the point is only to mark the boundary between the two.

Put simply: RA handles discovery and withdrawal, NS/NA handles address resolution, BFD handles fast fault detection.

The conclusions above are drawn from this lab environment together with the relevant RFCs and vendor documentation; specific implementations may differ across platforms and versions. Omissions, contradicting results, or implementation details not covered here — corrections and discussion are all welcome.

References

• RFC 4861 — Neighbor Discovery for IP version 6
• RFC 8950 — Advertising IPv4 NLRI with an IPv6 Next Hop
• Juniper — BGP auto-discovered neighbors
• Cisco Nexus 9000 — Configuring Advanced BGP