Network layer protocols move packets between IP networks and report conditions that affect delivery. IPv4 and IPv6 carry the packets. ICMPv4 and ICMPv6 carry control and error messages. OSPF and BGP exchange routing information that can influence which route a router installs; they do not forward an application's packets in place of IP. This distinction is more useful than treating every protocol associated with a router as the same kind of Layer 3 protocol.
| Protocol | Main job | Where it fits |
|---|---|---|
| IPv4 / IPv6 | Address and carry packets toward a destination | IP data plane: hosts send packets; routers forward them |
| ICMPv4 / ICMPv6 | Report errors and convey control information, including echo tests | IP control messages; not an application transport |
| OSPF | Exchange routes within a routing domain | Routing control plane; OSPFv2 runs directly over IPv4 as IP protocol 89 |
| BGP | Exchange reachability and path information between routing peers | Routing control plane; BGP messages travel over TCP, normally port 179 |
The table groups protocols by their job, not by a claim that all four occupy one strict OSI-model box. In particular, OSPFv2's specification identifies IP protocol 89, while the BGP-4 specification says BGP uses TCP. Both can help a router learn routes, but ordinary packets are still forwarded according to IP addresses and a forwarding decision.
What IPv4 and IPv6 do
An IP packet has a source address and a destination address. A host uses its local routing information to decide whether the destination is on a directly reachable network or whether it must send the packet toward a gateway. A router then chooses a next hop for the destination and forwards the packet. The next router may make a different decision using its own table. IP's job is best-effort packet delivery, not an end-to-end promise that data arrives once, in order, or at all. The original IPv4 specification, RFC 791, distinguishes IP addressing and routing from host-to-host reliability.
IPv4 uses 32-bit addresses; IPv6 uses 128-bit addresses and a different header format. They solve the same basic packet-delivery problem but are separate address families. A dual-stack host may have a usable IPv4 route and no usable IPv6 route, or the reverse. Test the family the application actually selected rather than assuming that one successful path proves the other works. RFC 791 specifies the IPv4 address field, and RFC 8200 specifies the IPv6 header and its 128-bit addresses.
IPv4's Time to Live (TTL) and IPv6's Hop Limit prevent packets from circulating forever. Routers reduce these values as packets pass through; a router discards a packet whose limit expires. Despite the IPv4 field's name, modern troubleshooting generally interprets it as a hop-limiting mechanism, not a stopwatch. The corresponding ICMP Time Exceeded response, when sent, lets a traceroute-style tool identify a responding hop. RFC 8200 explains why IPv6 calls its field Hop Limit.
What ICMP tells you—and what it does not
ICMP belongs beside IP because it reports delivery problems and carries control information. For IPv4, RFC 792 defines messages such as Destination Unreachable, Time Exceeded, Echo Request, and Echo Reply. The IPv6 counterpart, RFC 4443, defines ICMPv6 errors including Destination Unreachable, Packet Too Big, and Time Exceeded, plus echo messages. ICMPv4 and ICMPv6 are related but not interchangeable protocols or message formats.
ping sends echo requests and reports replies. A reply shows that the target responded to that probe over that path at that moment. It does not prove a web server accepts TCP connections, that a firewall allows a different protocol, or that every client takes the same path. No reply is also inconclusive: a host or intermediate device may filter or limit ICMP even while the application works. Compare ICMP results with the actual service request before declaring a destination up or down.
ICMPv6 deserves particular care. Packet Too Big conveys path-MTU information needed when a packet cannot pass through a link at its present size; indiscriminately blocking ICMPv6 can therefore break otherwise valid IPv6 traffic. IPv6 Neighbor Discovery also uses ICMPv6 messages, though its details are specified separately from RFC 4443. The point is not that every ICMP message must be allowed everywhere: permit the types required by your network design and apply appropriate filtering, rather than treating ICMPv6 as disposable diagnostic noise.
How OSPF and BGP affect the route
A router needs a route before it can choose the next hop. Routes can be connected, configured statically, or learned through routing protocols. OSPF and BGP are examples of the last category. They belong to the control plane—the information exchange and decisions that populate routing state. Forwarding a particular application packet using an installed route belongs to the data plane. A routing-protocol session being healthy does not by itself prove that the selected data path works.
OSPF is an interior gateway protocol: routers within an autonomous system share link-state information and calculate routes. RFC 2328 defines OSPFv2 for IPv4. It sends its own protocol packets directly over IP, identified as protocol number 89; it does not run on TCP port 89. OSPFv3, specified in RFC 5340, adapts OSPF for IPv6. In a network using OSPF, an adjacency or route problem can change which destination prefixes appear in a router's table. But the cause of a failed request still needs checking at the affected source and destination; not every timeout is an OSPF fault.
BGP exchanges reachable IP prefixes and path attributes between peers. External BGP peers are in different autonomous systems; internal BGP peers are in the same one. BGP also has policy: a peer may advertise, accept, prefer, or reject different routes. Unlike OSPF, BGP messages ride a TCP connection, normally on port 179, as RFC 4271 specifies. Saying that BGP is about IP reachability is accurate; saying that user packets are encapsulated in BGP is not.
Think of the difference as a sequence: OSPF or BGP may provide candidate routes, router policy selects a route, and IP forwarding uses the resulting next hop for packets. A host's local route lookup is only one part of that sequence. It cannot expose every remote router's routing table, policy, or forwarding decision.
Check the route from a Linux host
On Linux with iproute2, ip route get asks the kernel which route it would use for one destination. These examples use Cloudflare's documented public resolver addresses as concrete destinations; substitute the affected destination when diagnosing your own path:
ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
The Cloudflare resolver address list identifies those addresses. The ip-route(8) manual says get resolves one route as the kernel sees it; it does not send a packet to the destination or reconfigure the route. Output depends on the host's interfaces, source addresses, policy rules, network namespace, and current routes. An IPv6 lookup can fail on a host without a suitable IPv6 route. If an application runs in a container or another network namespace, run the lookup there; the host's answer may differ.
Inspect the selected source address, outgoing interface, and next hop if one is shown. A route through a gateway is not evidence that the gateway—or anything beyond it—will deliver the packet. A local lookup also cannot establish that the reverse path back to this host exists. Conversely, if the kernel reports no route, fix local addressing, policy, or routing before investigating the remote service.
If the local route exists, an optional next check is ping -4 -c 3 1.1.1.1 or ping -6 -c 3 2606:4700:4700::1111. Unlike ip route get, these commands send ICMP probes. The Linux ping(8) manual documents -4, -6, and -c. If installed, traceroute -4 1.1.1.1 or traceroute -6 2606:4700:4700::1111 also sends probes with increasing TTL or Hop Limit and listens for replies; a silent hop may simply not answer. The traceroute(8) manual documents its probe behavior. Neither tool replaces a test of the application's actual protocol and port.
For a named service, first resolve its A and AAAA records, then test the address family and port the client uses. A missing or wrong DNS answer is different from a missing IP route; this DNS troubleshooting guide covers that earlier step. When comparing results from two machines, keep the source network and time in view. Different source addresses or routing policies can produce different next hops to the same destination.
Read network evidence alongside application failures
An application request can fail because there is no local route, a remote path fails, filtering blocks the traffic, a TCP connection is refused, or the service never responds. These can produce different errors; a refusal or missing local route is not necessarily a timeout. The route lookup narrows the first question; ICMP probes may add path clues; the actual application request determines whether the service works. If you operate OSPF or BGP, inspect the relevant router's neighbor state, selected route, and change history using that router's own tools. Do not infer a BGP or OSPF failure solely from a host ping result.
Where router, firewall, and application logs are already collected, compare their timestamps and destination addresses. Fluxtail can store and search those logs when they are sent through a supported ingest path, but it does not discover packet paths or routing adjacencies on its own. Log management helps preserve the surrounding evidence; direct route and service checks still establish what the network is doing now.