CNX Documentation

Enabling Add-Path and ECMP

Enable Add-Path receive first, verify that multiple paths are retained, and then enable ECMP. This separates a capability problem from a route-selection problem.

The operational goal is non-disruptive route-server maintenance. All three route-server sessions keep CNX routes present when one server is maintained; Add-Path additionally keeps alternate participant paths live within each session. ECMP can install otherwise-equal alternatives before a withdrawal occurs. Together, these controls avoid waiting to discover a replacement path when CNX rotates one route server out of service.

1. Enable Add-Path receive

Configure receive capability for IPv4 and IPv6 on each route-server session. Do not enable Add-Path transmit toward CNX unless you have a separate reason to send several paths; the member-side requirement for this service is receive.

Restart or refresh the BGP session if your platform does not renegotiate the capability dynamically.

2. Verify path reception

Check the negotiated capability in the neighbor detail. For a prefix announced by more than one CNX member connection, inspect the BGP table and confirm that several path identifiers or path entries exist on the same route-server session.

If only one path appears:

  • confirm that the route server negotiated transmit and your router negotiated receive;
  • choose a prefix that actually has several eligible paths;
  • check whether import policy discards alternates; and
  • check the platform's received-path limit.

3. Enable BGP multipath

Set an explicit ECMP path limit. Where required, enable multipath comparison across different neighboring AS paths. Do not ignore more BGP attributes than needed to reach the intended equivalence.

Keep the same local preference on routes from all three CNX route servers if you want otherwise-equal paths to participate together.

4. Verify the forwarding table

For a test prefix, distinguish three states:

Several paths in received BGP data
Several eligible paths in the BGP RIB
Several next hops installed in the forwarding table

Only the last state provides ECMP forwarding. Confirm that every installed next hop resolves to a different member address and that the hardware supports the configured number of paths.

5. Test withdrawal behavior

During an agreed test, withdraw one eligible path or disable one session. Confirm that new flows use remaining next hops and that unrelated paths remain installed. Repeat the test by disabling one complete route-server session and confirm that the same prefixes remain usable through the other two sessions without a forwarding interruption. Do not use BFD to a route server as proof of member forwarding-path health: the route server is not the traffic next hop.

Platform snippets

Cisco IOS XE

address-family ipv4 unicast
 neighbor CNX-RS4 additional-paths receive
 maximum-paths eibgp 8
bgp bestpath as-path multipath-relax

Use the corresponding commands under the IPv6 address family. Some IOS XE trains use address-family-wide bgp additional-paths receive.

Junos OS

set protocols bgp group CNX-RS family inet unicast add-path receive
set protocols bgp group CNX-RS family inet6 unicast add-path receive
set protocols bgp group CNX-RS multipath multiple-as

Huawei VRP

peer CNX-RS4 capability-advertise add-path receive
maximum load-balancing ebgp 8
load-balancing as-path-relax

Apply the Huawei commands within each BGP address family. See the complete Cisco IOS XE, Junos OS, and Huawei VRP configurations.