Summary
Port 179 carries the Border Gateway Protocol (BGP), the routing protocol that determines how traffic flows between autonomous systems on the Internet. When you send a packet to a server on another continent, BGP decided the path it takes. When an entire country goes offline, BGP is usually involved. This is the protocol that turns 80,000 independently operated networks into a single, navigable Internet.
BGP was designed on two napkins at an IETF lunch in January 1989.1 It was supposed to be a temporary fix. Thirty-five years later, it routes over a million prefixes and handles every inter-domain routing decision on the Internet.2
What Port 179 Does
Port 179 is where BGP peers establish and maintain their relationships. Unlike internal routing protocols that discover neighbors automatically, BGP requires explicit configuration. Two routers must be told to connect to each other, and when they do, they open a TCP connection on port 179.
The protocol is elegant in its simplicity. Once connected, BGP speakers exchange their entire routing tables, then send incremental updates as things change. Each route carries an AS_PATH attribute listing every autonomous system the announcement has traversed. This path information serves two purposes: it prevents routing loops (if you see your own AS number in a path, reject it), and it enables policy decisions (you might prefer routes that don't pass through certain networks).3
BGP is a path vector protocol. It doesn't just tell you that a destination is reachable; it tells you exactly which networks you'd traverse to get there. This makes it fundamentally different from distance vector protocols that only share metrics, or link-state protocols that share topology. BGP shares policy-filtered paths.
The Key Insight
The genius of BGP is treating each autonomous system as a single hop. Interior routing protocols obsess over individual routers and links. BGP operates at a higher level of abstraction: autonomous systems are the atoms, and the Internet is molecules of ASes bonded through peering relationships.
This abstraction is what allowed the Internet to scale. You don't need to know the internal topology of every network on Earth. You just need to know which networks can reach which other networks, and which paths are available to you based on your business relationships.
When your router announces a prefix, it's making a promise: "I can deliver traffic to these addresses." Every AS that hears the announcement and accepts it is extending that promise: "I can reach a network that can reach those addresses." The AS_PATH is a chain of promises, traceable back to the source.
How BGP Works
A BGP session begins with a TCP three-way handshake on port 179. Once the TCP connection is established, the BGP speakers exchange OPEN messages containing their AS numbers and capabilities. If the OPEN is accepted, they enter the established state and begin exchanging routes.
The BGP state machine has six states:4
- Idle: Waiting to start
- Connect: TCP connection in progress
- Active: Attempting connection (confusingly named; this isn't the "good" state)
- OpenSent: TCP connected, OPEN message sent
- OpenConfirm: Waiting for KEEPALIVE
- Established: Full BGP adjacency, routes can be exchanged
Once established, BGP speakers send KEEPALIVE messages every 30 seconds by default. If a speaker misses three consecutive keepalives, the session is torn down and all routes learned from that peer are withdrawn.
Route selection follows a complex decision process, but the basics are:
- Prefer routes with the highest LOCAL_PREF (local policy wins)
- Prefer routes with the shortest AS_PATH (fewer hops through fewer networks)
- Prefer routes learned from external BGP over internal BGP
- Use various tiebreakers for everything else
History
In January 1989, the Internet had a routing problem. The Exterior Gateway Protocol (EGP), defined in RFC 827, was showing its age.5 EGP assumed a tree-shaped network topology with no cycles. As the Internet grew beyond its ARPANET roots, this assumption became increasingly false. Networks wanted to peer with multiple upstream providers. They wanted redundancy. They wanted policy control. EGP couldn't handle any of it.
At the 12th IETF meeting in Austin, Texas, three engineers sat down at a table during lunch: Yakov Rekhter from IBM, Kirk Lougheed from Cisco, and Len Bosack.1 They sketched out a new routing protocol on two napkins. The napkins themselves were thrown away, but photocopies of the three pages of notes they expanded from those napkins still hang on a wall at Cisco.6
The design was simple: use TCP for reliability, exchange complete paths instead of just distances, and let network operators define their own policies. They called it the Border Gateway Protocol and published it as RFC 1105 later that year.
"Security wasn't even on the table," Rekhter later recalled. "This was an era when hacks were rare and the toll modest." Kirk Lougheed put it more directly: "In the early days of the Internet, getting stuff to work was the primary goal. There was no concept that people would use this to do malicious things."7
BGP was explicitly designed as an interim solution, a stopgap until something better came along. The Internet had 80,000 hosts in 1989.7 Nobody imagined it would grow to billions.
Version 4 of BGP, published in RFC 1771 in 1995 and clarified in RFC 4271 in 2006, added support for Classless Inter-Domain Routing (CIDR) and became the version still running today.8 The interim solution became permanent infrastructure.
Security
BGP trusts everything it hears. If a network announces that it can reach a destination, other networks believe it. There is no built-in authentication, no cryptographic verification, no proof that the announcer actually controls those addresses. This design made sense in 1989, when the Internet was a community of researchers who knew and trusted each other. It makes less sense today.
The consequences of this trust have been dramatic:
The AS7007 Incident (1997): The first major BGP incident, when a small ISP accidentally announced routes for most of the Internet, causing widespread outages.9
The Pakistan YouTube Outage (2008): Pakistan Telecom attempted to censor YouTube by announcing a more specific route for YouTube's IP space. Due to BGP's preference for more specific routes, the announcement leaked to the global Internet, and YouTube went dark worldwide for hours.9
Cryptocurrency Heists (2014-2022): Attackers have repeatedly used BGP hijacks to steal cryptocurrency. In 2018, a hijack redirected traffic to Amazon's DNS service, allowing attackers to impersonate MyEtherWallet and steal cryptocurrency from users who logged in.9
The Cloudflare DNS Hijack (2024): A Brazilian ISP announced Cloudflare's 1.1.1.1 DNS resolver as its own, affecting over 300 networks in 70 countries.9
Resource Public Key Infrastructure (RPKI) was developed to address these vulnerabilities. RPKI allows address holders to cryptographically sign Route Origin Authorizations (ROAs) that prove they control specific prefixes. Networks can then validate incoming BGP announcements against these authorizations.10
Adoption has been slow. As of 2024, only about half of advertised IP prefixes are covered by ROAs, and only about 25% of networks actively filter invalid routes.11 The U.S. government released a roadmap in 2024 urging wider adoption, but deployment remains inconsistent.12
Related Ports
| Port | Protocol | Description |
|---|---|---|
| 179/TCP | BGP | Border Gateway Protocol |
| 646/TCP | LDP | Label Distribution Protocol for MPLS |
| 520/UDP | RIP | Routing Information Protocol (interior routing) |
| 89/IP | OSPF | Open Shortest Path First (interior routing, IP protocol 89) |
Frequently Asked Questions
The Weight of the Protocol
Port 179 carries the conversations that hold the Internet together. Every BGP session is a negotiation between autonomous systems, each one representing a network with its own infrastructure, its own policies, its own reasons for existing. When those sessions go down, the paths they maintained vanish from routing tables around the world.
The two-napkin protocol was never meant to last. It was a quick fix, designed by three engineers over lunch because the Internet needed something that worked right now. It didn't need to be perfect; it needed to be good enough to replace the tree-shaped routing of the 1980s with something that could handle the messy, cyclical, policy-laden reality of competing networks.
And it worked. It scaled from 80,000 hosts to over a billion. It grew from a few hundred autonomous systems to 80,000. It absorbed the explosive growth of the commercial Internet, the rise of content delivery networks, the shift to cloud computing, the demands of mobile traffic. Every time someone predicted BGP would collapse under its own weight, it didn't.
The protocol has no concept of trust. It believes what it's told. This has caused outages, enabled attacks, and frustrated security researchers for decades. But it has also allowed the Internet to operate without a central authority. No one has to approve your routing announcements. If your peers accept them, your traffic flows.
Every packet that crosses the boundary between networks exists because port 179 made it possible. BGP decided which paths exist and which do not. It transformed business relationships into routing policy, and routing policy into reachable destinations. The Internet you use today is built on handshakes negotiated through this port, trust established without cryptography, paths announced on faith.
The napkins are gone, but what they sketched still runs the world.
Was this page helpful?