OSPF and BGP are the workhorses of routing on the internet and within large networks. Debugging them often means diving into the packet captures generated by tools like Wireshark.
Let’s watch OSPF in action. Imagine two routers, R1 and R2, running OSPF. R1 has an interface with IP address 192.168.1.1/24 and R2 has 192.168.1.2/24 on the link between them. Both are configured for OSPF area 0.
// R1 config snippet
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip ospf 1 area 0
// R2 config snippet
interface GigabitEthernet0/0
ip address 192.168.1.2 255.255.255.0
ip ospf 1 area 0
When they come online, R1 will send an OSPF "Hello" packet out its Ethernet interface. You’ll see this in Wireshark as a UDP packet to multicast address 224.0.0.5 (AllSPFRouters) on port 89. The source IP will be 192.168.1.1. This hello packet contains crucial information: the OSPF Router ID of the sender, the network mask of the interface, the Hello interval (typically 10 seconds), the Dead interval (typically 40 seconds), and the Router Priority.
R2, upon receiving this hello, will also send one back. If the parameters match (specifically, Area ID, Hello/Dead intervals, subnet mask, and authentication if configured), they will transition to the "Two-Way" state. This means they’ve heard each other. The next step is forming an adjacency. They’ll exchange "Database Description" (DBD) packets. These are essentially summaries of their Link-State Databases (LSDBs). If the LSDBs are out of sync, they’ll then exchange "Link-State Request" (LSR) packets to ask for specific LSAs they’re missing, and then "Link-State Update" (LSU) packets to send those LSAs. Finally, they’ll send "Link-State Acknowledgment" (LSAck) packets. Once they’ve exchanged all necessary LSAs and the databases are synchronized, they reach the "Full" state, and routes are exchanged.
Now, let’s look at BGP. BGP is a path-vector routing protocol, meaning it exchanges entire network paths, not just link states. It operates typically over TCP port 179. Imagine R1 (an internal router, AS 65001) peering with R2 (an external router, AS 65002).
// R1 config snippet
router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 update-source GigabitEthernet0/1 // Assuming 10.0.0.1 is on Gi0/1
// R2 config snippet
router bgp 65002
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 update-source GigabitEthernet0/1 // Assuming 10.0.0.2 is on Gi0/1
The first packet you’ll see is a TCP SYN from R1 to R2 on port 179. This initiates the TCP connection. Once established, they exchange BGP "Open" messages. These messages contain the BGP version, the sender’s AS number, the Hold Time, and the BGP Identifier (similar to a Router ID). If these parameters are acceptable to both sides, they’ll send back their own Open messages. After exchanging Open messages and receiving acknowledgments, they transition to the "Established" state.
Once established, they send "Keepalive" messages periodically (default is 60 seconds) to ensure the neighbor is still up. If a Keepalive isn’t received within the Hold Time (default is 180 seconds), the neighbor is declared down. The most important messages are "Update" packets. These contain new routes (NLRI - Network Layer Reachability Information), path attributes (like AS_PATH, NEXT_HOP, LOCAL_PREF, MED), and withdrawn routes. Wireshark will show you the NLRI (e.g., 192.168.10.0/24), the AS_PATH (e.g., 65002), and all other attributes.
The mental model for BGP is that it’s a distributed policy engine. Every BGP speaker decides which routes to accept, which to advertise, and how to influence the path selection of others based on these attributes. It’s not about finding the shortest path (like OSPF), but about finding the best path according to a set of policies, which often relate to business relationships and traffic engineering.
The one thing that often trips people up is the NEXT_HOP attribute in BGP. When an internal BGP (iBGP) peer advertises a route learned from an external BGP (eBGP) peer, it does not change the NEXT_HOP to itself by default. Instead, it preserves the NEXT_HOP from the eBGP peer. This means that for an iBGP router to reach the NEXT_HOP, it must have a route to that NEXT_HOP already in its IGP (like OSPF or EIGRP). If it doesn’t, the route will be unusable, even though it’s in the BGP table.
After you’ve got OSPF and BGP neighbors up and routes flowing, the next thing you’ll want to debug is route flapping.