tcpdump OSPF and BGP Routing: Capture Protocol Traffic (2026)

OSPF and BGP are the workhorses of inter-domain routing, and sometimes, you just need to see what they’re saying to each other. tcpdump is your ear to the ground for this.

Here’s a BGP session in progress, captured by tcpdump, showing an OPEN message being exchanged between two routers. Notice the AS numbers (65500 and 65501) and the BGP version (4).

10:01:01.123456 IP 192.168.1.1.179 > 192.168.1.2.179: Flags [P.], seq 12345:12346, ack 67890, win 65535, options [nop,nop,TS val 12345678 ecr 87654321], length 50
BGP: OPEN version 4, my AS 65500, holdtime 180, router-id 192.168.1.1, opt len 28
  Capabilities:
    MP_REACH_NLRI (1): 10
    AS4_PATH (2): 12
    ROUTE_REFRESH (2): 2

And here’s an OSPF LS Update packet. You can see the Link State ID, Type, and Age, indicating it’s a router LSA (Type 2).

10:02:02.987654 IP 10.0.0.1.1186 > 224.0.0.5.5: OSPFv2, Hello, length 44, ABR, DR, BDR
  RTR 10.0.0.1, mask 255.255.255.0, hello 10, dead 40, neighbor 10.0.0.2

The fundamental problem OSPF and BGP solve is how to dynamically discover and maintain paths to destinations across a network, especially when that network is made up of many independent administrative domains (like different ISPs). They do this by exchanging messages that describe network reachability and preferences. BGP is designed for the internet, focusing on policy and path attributes, while OSPF is designed for within an autonomous system, focusing on link cost and shortest paths.

When you capture OSPF and BGP traffic with tcpdump, you’re essentially eavesdropping on the conversation between routers. This conversation isn’t just about announcing which networks they can reach; it’s also about establishing and maintaining the relationship between the routers themselves.

BGP’s Three-Way Handshake and State Machine

BGP uses a TCP connection (port 179) to reliably exchange messages. This means you’ll see standard TCP SYN, SYN-ACK, and ACK packets as the session establishes, followed by BGP-specific messages like OPEN, UPDATE, KEEPALIVE, and NOTIFICATION.

• Idle: The initial state where the router is waiting to establish a connection.
• Connect: TCP connection establishment is in progress.
• Active: TCP connection establishment is in progress, and the router is actively trying to connect.
• OpenSent: The local router has sent an OPEN message and is waiting for a response.
• OpenConfirm: The local router has received a valid OPEN message and is waiting for a KEEPALIVE message.
• Established: The BGP session is fully established, and UPDATE messages (routes) can be exchanged.

You can tcpdump BGP traffic like this:

sudo tcpdump -i eth0 -nnv 'tcp port 179'

The -i eth0 specifies the network interface. -nnv tells tcpdump to not resolve hostnames or port names (showing IP addresses and port numbers), and to be verbose. The filter 'tcp port 179' ensures you only see traffic on the BGP port.

OSPF’s Multicast Messaging

OSPF, on the other hand, uses IP multicast for its control traffic. It sends Hello packets to 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all OSPF designated routers) and Link State Advertisements (LSAs) to these same multicast addresses. This means you won’t see a TCP handshake. Instead, you’ll see IP packets destined for these multicast groups.

Capturing OSPF traffic:

sudo tcpdump -i eth1 -nnv 'udp port 179 or igmp'

Here, -i eth1 is the interface. udp port 179 is used because although OSPF is an IP protocol, many implementations historically used UDP port 179 or a similar UDP port for OSPF. A more precise filter would target the IP protocol directly if your tcpdump version supports it for OSPF. The igmp part captures Internet Group Management Protocol, which is essential for multicast group membership. A more direct OSPF filter might look like:

sudo tcpdump -i eth1 -nnv 'ip multicast'

Or, if you know the specific OSPF IP protocol number (89):

sudo tcpdump -i eth1 -nnv 'proto ospf'

What to Look For in the Output

• BGP:

  • TCP Handshake: SYN, SYN-ACK, ACK packets between the IP addresses of your BGP peers.
  • OPEN Messages: The first BGP message after the TCP handshake. Look for the AS numbers and router IDs.
  • UPDATE Messages: These contain the actual route advertisements. You’ll see NLRI (Network Layer Reachability Information) and Path Attributes.
  • KEEPALIVE Messages: Sent periodically to ensure the session is still active. If you stop seeing these, the session might be down.
  • NOTIFICATION Messages: Indicate an error and the reason for the session tear-down.

• OSPF:

  • Hello Packets: Sent frequently to neighbors. Look for the multicast destination 224.0.0.5 or 224.0.0.6. These packets establish adjacency.
  • Database Description (DBD) Packets: Routers exchange summaries of their Link State Databases (LSDBs).
  • Link State Request (LSR) Packets: A router requests specific LSAs from a neighbor.
  • Link State Update (LSU) Packets: Contain the actual LSAs being flooded.
  • Link State Acknowledgment (LSAck) Packets: Confirm receipt of LSUs.

A crucial detail often missed is that BGP uses TCP, making it reliable but also susceptible to TCP-level issues like packet loss, retransmissions, and windowing problems that can indirectly impact BGP session stability. OSPF, by contrast, relies on IP multicast and its own internal mechanisms for reliability. If you’re seeing OSPF Hellos but no other OSPF traffic, it usually means there’s a multicast routing issue or a firewall blocking the multicast traffic, not a problem with the OSPF protocol itself.

The next step after capturing and understanding BGP and OSPF traffic is often to analyze route propagation and policy enforcement, or to troubleshoot complex OSPF area adjacencies.