<p>When learning the Kubernetes CNI, I heard some plugins are using the BGP or VXLAN under the hood.</p>
<p>On the internet, border gateway protocol (BGP) manages how packets are routed between edge routers.</p>
<p><strong>Autonomous systems (AS)</strong> are network routers managed by a single enterprise or service provider. for example, <a href="https://db-ip.com/as32934-facebook-inc" rel="nofollow noreferrer">Facebook</a> and <a href="https://db-ip.com/as15169-google-llc" rel="nofollow noreferrer">Google</a>.</p>
<p>Autonomous systems (AS) communicate with peers and form a mesh.</p>
<p><a href="https://i.stack.imgur.com/vI6it.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/vI6it.png" alt="enter image description here" /></a></p>
<p>But I still can't figure out how does the CNI plugin take advantage of BGP.</p>
<p>Imagine there is a Kubernetes cluster, which is composed of 10 nodes. Calico is the chosen CNI plugin.</p>
<ul>
<li><p>Who plays the <strong>Autonomous System(AS)</strong> role? Is each node an AS?</p>
</li>
<li><p>How are packets forward from one node to another node? Is the iptable still required?</p>
</li>
</ul>

<p>The CNI plugin is responsible for allocating IP addresses (IPAM) and ensuring that packets get where they need to get.</p>
<p>For Calico specifically, you can get a lot of information from the <a href="https://projectcalico.docs.tigera.io/reference/architecture/overview#ipam-plugin" rel="nofollow noreferrer">architecture page</a> as well as the Calico <a href="https://projectcalico.docs.tigera.io/reference/architecture/design/l3-interconnect-fabric" rel="nofollow noreferrer">network design</a> memoirs.</p>
<p>Whenever a new Pod is created, the IPAM plugin allocates an IP address from the global pool and the Kubernetes scheduler assigns the Pod to a Node. The Calico CNI plugin (like any other) configures the networking stack to accept connections to the Pod IP and routes them to the processes inside. This happens with <code>iptables</code> and uses a helper process called Felix.</p>
<p>Each Node also runs a BIRD (BGP) daemon that watches for these configuration events: &quot;IP 10.x.y.z is hosted on node A&quot;. These configuration events are turned into BGP updates and sent to other nodes using the open BGP sessions.
When the other nodes receive these BGP updates, they program the node route table (with simple <code>ip route</code> commands) to ensure the node knows how to reach the Pod. In this model, yes, every node is an AS.</p>
<p>What I just described is the &quot;AS per compute server&quot; model: it is suitable for small deployments in environments where nodes are not necessarily on the same L2 network. The problem is that each node needs to maintain a BGP session with every other node, which scales as O(N^2).</p>
<p>For larger deployments therefore, a compromise is to run one AS per rack of compute servers (&quot;AS per rack&quot;). Each top of rack switch then runs BGP to communicate routes to other racks, while the switch internally knows how to route packets.</p>
