BGP handling bug causes widespread internet routing instability

Original Article ↗ Hacker News Discussion ↗

BGP’s Role vs Multicast/Anycast

  • Several comments clarify that BGP is the inter-domain routing protocol of the Internet, not just for private networks. The “Internet” can be viewed as the global BGP table.
  • BGP itself is unicast over TCP/179; it does not use multicast. Confusion often comes from OSPF and other IGPs that do.
  • Multicast can technically work over the Internet (e.g., historical MBone, some IPTV deployments, tunnels), but is rarely enabled or interconnected by ISPs today; most large-scale streaming has gone to CDNs and unicast.
  • Anycast is highlighted as common and useful, but is essentially “special unicast” (same prefix from multiple locations), not a distinct traffic type like multicast.

Error Handling, Postel’s Law, and RFC 7606

  • Discussion revolves around how BGP speakers should handle malformed or unknown attributes:
    • Options: filter/bypass, drop message, propagate while ignoring parts, or reset session.
    • Arista dropped the whole session; Juniper propagated attributes it shouldn’t have.
  • RFC 7606’s “treat-as-withdraw” (drop the route, not the session) is cited as the modern consensus; tearing down sessions is seen as harmful because it causes repeated flaps.
  • There’s a long debate over Postel’s “be liberal in what you accept”:
    • Pro: enabled incremental deployment of new BGP attributes (e.g., 32-bit ASNs, large communities) and protocol evolution when equipment is heterogeneous and long-lived.
    • Con: encourages brittle systems, security issues, and protocol ossification when broken or undocumented behavior becomes relied upon.
  • Nuance: distinction between unknown-but-well-formed extensions (should usually be forwarded) vs clearly malformed data (should be rejected), and between per-message vs per-session failure.
  • Some argue strict spec conformance plus protocol versioning and explicit extensibility would have been a better long-term path.

BGP Complexity, Bugs, and Fuzzing

  • BGP is seen as very complex and continually accreting features (MPLS/VPNs, attributes), making deprecation unlikely and new bugs inevitable.
  • Operators mention recent CVEs in multiple BGP stacks and recall past large incidents; this class of error-handling bugs is expected to be painful and long-lived.
  • People are surprised there isn’t a strong, shared interoperability and fuzz-testing regime for BGP implementations, given the global impact. Fuzzing is technically straightforward but operationally risky; some research fuzzers exist but vendors don’t appear to leverage them aggressively.

Learning and Using BGP

  • Many developers never encounter BGP in school or work because it runs “behind the scenes” at ISPs and large networks.
  • Suggested ways to learn:
    • Simulators/emulators (GNS3, ns-3 variants, Cisco Packet Tracer/Modeling Labs, Eve-NG, containerlab, gini).
    • Open-source daemons (FRR, BIRD, OpenBGPD, OpenBSD bgpd) in VMs/containers.
    • Cheap routers (Mikrotik, VyOS) in a homelab, using private ASNs.
    • Joining “fake Internet” projects like dn42 or using looking-glass and RouteViews/RIPE data to observe real BGP.
  • Consensus: BGP in a homelab is mainly educational; its real value shows up in large, multi-ISP, policy-driven environments.