How to troubleshoot common routing errors

Error 1. EBGP multihop sessions not appearing

BGP peers don't need to connect directly. Instead, BGP establishes neighborship over a TCP session. This requires multiple hops to pass data packets between routers. Network professionals might encounter an issue as they configure External BGP (eBGP) over multiple hops. Their setup might appear correct, but the BGP session doesn't appear.

No matter the number of routers between eBGP peers, the time-to-live (TTL) value in an IP packet remains critical to form neighborships. By default, eBGP's TTL value is set to 1; for Internal BGP peers, the TTL value is 255. This means the packet can't pass through a single router. To enable packet traversal through multiple routers, the TTL value must increase. Configuring eBGP multihop is the best way to fix this problem. It enables packets to pass through intermediate routers so peers can establish a session and exchange updates.

To enable eBGP multihop, use the ebgp-multihop command within the BGP configuration. This simple adjustment ensures eBGP peers can connect, even when separated by multiple hops.

#csr_01

router bgp 100
 bgp log-neighbor-changes
 neighbor 23.23.23.1 remote-as 200
 neighbor 23.23.23.1 ebgp-multihop 255

#csr_02

router bgp 200
 bgp log-neighbor-changes
 neighbor 12.12.12.1 remote-as 100
 neighbor 12.12.12.1 ebgp-multihop 255

Error 2. No matching BGP network command prefix

BGP must meet some conditions before network administrators can use the command to advertise a specific prefix. One critical condition is to ensure an exact match for the prefix exists. To do this, BGP references the routing table. After it finds a matching route, BGP includes the prefix in its BGP table and advertises it to other routers.

However, routing tables don't always provide a match. When this happens, BGP doesn't advertise the prefix or route the data packet. If the router doesn't advertise a configured network statement prefix as expected, network administrators should recheck the routing table. This should confirm that the exact route is there. If it's not there, network admins should perform further troubleshooting steps.

Error 3. Mismatched AS numbers

Another common eBGP issue occurs when mismatched autonomous system (AS) numbers are in the configuration. The AS numbers must match on both sides to establish an eBGP session. If the AS numbers don't align, the BGP session doesn't appear. Network administrators should always double-check the AS configurations of both peers to confirm the expected match.

For example, assume Router 2 must mirror Router 1 in their configurations. If Router 1 is in AS 64512 and has a neighbor statement configured with AS 64513, then Router 2 should be in AS 64513 and have a neighbor statement pointing back to Router 1.

Error 4. OSPF neighbor relationship requirements

OSPF router configurations enable routing on specific interfaces. It searches for neighbors by sending and receiving HELLO packets. However, neighbor detection is only the first step. OSPF must meet certain conditions to establish a neighbor adjacency.

While troubleshooting OSPF neighborship issues, network administrators should check the following settings to ensure both routers align:

• Interface IP addresses must be in the same subnet. The routers don't form an adjacency if the interface IP addresses don't match within the same subnet.
• OSPF authentication must pass if configured. The routers must have matching passwords if authentication is enabled.
• Hello and dead intervals must match. These timers control how often routers send HELLO packets and how long to wait before declaring a neighbor down. Mismatched values prevent adjacency.
• Interfaces must be in the same area. OSPF routers must be in the same area for adjacency to form.
• Maximum transmission unit (MTU) mismatch. The neighboring interfaces must match the MTU.

MTU mismatch example

The following example demonstrates an MTU mismatch. Router-01's MTU is listed as 1400. MTU's default is 1500, so it is incorrect.

router-01(config-if-Et1)#mtu 1400
router-01(config-if-Et1)#end

When checking the OSPF neighborship, notice the state is stuck at EXSTART/DR and the logs indicate an MTU issue.

Jan 28 23:01:01 router-01 Ospf: Instance 1: 
OSPF: invalid DD packet from 10.50.50.6: DD MTU is too large (29)

Changing the MTU back to 1500 forms the neighborship again.

router-01(config-if-Et1)#mtu 1500
router-01(config-if-Et1)#end
router-01#Jan 28 23:03:54 router-01 Ospf: Instance 1: 
%OSPF-4-OSPF_ADJACENCY_ESTABLISHED: NGB 10.50.50.6, 
interface 10.50.50.5 adjacency established

Error 5. OSPF passive interface

OSPF passive interface stops sending HELLO messages, so it doesn't form neighbor relationships over that interface. However, OSPF advertisements still include the connected network.

The passive-interface default command makes all interfaces passive. If this command is active, network administrators should manually enable OSPF on specific interfaces requiring neighbor relationships using the no passive-interface command. Check the interface in settings if OSPF neighborships don't form despite the correct configuration. If it's set to passive due to the global command, disable it on that interface using no passive-interface. This enables OSPF to form the neighborship.

The following example shows OSPF configurations on Interface Eth1 on router-01 and uses the passive-interface default command. Due to this, the neighborship did not form.

router-01#show run | sec ospf
interface Ethernet1
   ip ospf area 0.0.0.0
router ospf 1
   passive-interface default

router-01#show ip ospf neighbor
Neighbor ID     Instance VRF      Pri State                  Dead Time
Address         Interface

After disabling the passive interface on Eth1, the neighborship came up. This should happen immediately.

router-01(config)#router ospf 1
router-01(config-router-ospf)#no passive-interface eth1
router-01(config-router-ospf)#end

router-01#show ip ospf neighbor
Neighbor ID     Instance VRF      Pri State                  Dead Time
Address         Interface
10.50.50.6      1        default  1   FULL/DR                00:00:31
10.50.50.6      Ethernet1

Suresh Vina is a network engineer who has worked in the networking field for the past eight years. He has hands-on experience with technologies from Cisco, Juniper, Palo Alto Networks, Fortinet and more.