Verifying and troubleshooting peering

Verify each layer separately. A BGP session can be Established while route policy rejects every announcement, and a valid route can still fail to forward.

Port and peering LAN

Confirm:

• interface, aggregate, and VLAN state;
• expected MTU;
• IPv4 ARP and IPv6 neighbour entries;
• sourced reachability to every route-server address; and
• no duplicate-address or MAC-move alarms.

BGP sessions

For every IPv4 and IPv6 session, check:

• local and remote ASN;
• local and remote address;
• session uptime and last reset reason;
• negotiated address families;
• received and advertised prefix counts;
• maximum-prefix state; and
• Add-Path capability and direction when enabled.

If no session establishes, verify that your router initiates the connection, that TCP/179 is permitted, and that first-AS enforcement is disabled where the platform requires it.

Exported routes

For each intended prefix, confirm:

• it exists in the local routing table;
• the outbound prefix policy permits it;
• the origin ASN matches the ROA and IRR object;
• the downstream origin is present in your AS-SET when applicable; and
• the route is advertised identically to every route server.

Use the CNX looking glass to determine whether a rejected route carries a reject-reason community.

Received routes and forwarding

Inspect a sample of routes for the original member AS_PATH, a reachable peering-LAN next hop, CNX validation communities, and the expected local preference. Confirm that the selected next hop is installed in the forwarding table.

Test traffic to an address operated by another member and verify the return path independently. Traceroute is useful evidence, but a missing response from an intermediate hop is not by itself a forwarding failure.

Change one policy at a time

After baseline peering works, enable Add-Path, ECMP, or steering in separate changes. Record the route and forwarding state before and after each change so the effect is attributable to one control.