<div dir="ltr"><div><div><div><div><div><div><div><span style="font-family:monospace">Hi BIRD users!<br><br></span></div><span style="font-family:monospace">Attached are 3 patches that my team has been using for routing through IP-in-IP tunnels, rebased on 1.6.1.  I'd like to explain why we find them useful, and start a conversation about whether they or something like them could be upstreamed (or perhaps if there's some better way of achieving our aims).<br><br></span></div><span style="font-family:monospace">Calico [1] uses BIRD for BGP routing between the hosts in various cloud orchestration systems (Kubernetes, OpenStack etc.), to distribute routes to the pods/VMs/containers in those systems, each of which has its own IP.  If all the hosts are directly connected to each other, this is straightforward, but sometimes they are not.  For example GCE instances are not directly connected to each other: there is at least one router between them, that knows about routing GCE addresses, and to/from the Internet, and we cannot peer with it or otherwise tell it how to route pod/VM/container IPs.  So if we use GCE to create e.g. OpenStack compute hosts, with Calico networking, we need to do something extra to allow VM-addressed data to pass between the compute hosts.<br><br></span></div><span style="font-family:monospace">One of our solutions is to use IP-in-IP; it works as shown by this diagram:<br><br>       10.65.0.3 via 10.240.0.5 dev tunl0 onlink<br>       default via 10.240.0.1<br>               |<br>             +-|----------+                             +------------+<br>             | o          |                             |            |<br>             |   Host A   |         +--------+          |   Host B   |<br>             |            |---------| Router |----------|            |<br>             | 10.240.0.4 |         +--------+          | 10.240.0.5 |<br>             |            |---.                         |            |<br>             +------------+    |                        +------------+<br>               ^       ^   +---v---+                                |      <br> src 10.65.0.2 |       |   | tunl0 |                                |      <br> dst 10.65.0.3 |       |   +-------+                                |      <br>               |        \      |                                    v      <br>         +-----------+   '----'                               +-----------+<br>         |   Pod A   |      src 10.240.0.4                    |   Pod B   |<br>         | 10.65.0.2 |      dst 10.240.0.5                    | 10.65.0.3 |<br>         +-----------+          ------                        +-----------+<br>                             src 10.65.0.2<br>                             dst 10.65.0.3<br><br></span></div><span style="font-family:monospace">The diagram shows Pod A sending a packet to Pod B, using IP addresses that are unknown to the 'Router' between the two hosts.  Host A has an IP-in-IP device, tunl0, and a route that says to use that device for data to Pod B's address (10.65.0.3).  When the packet has passed through that device, it has a new outer IP header, with src 10.240.0.4 and dst 10.240.0.5, and is routed again according to the routing table - so now it can successfully reach Host B.<br><br></span></div><span style="font-family:monospace">So how is BIRD involved?  We statically program the local Pod route on each host:<br><br></span></div><span style="font-family:monospace">On Host A: 10.65.0.2 dev <interface to Pod A><br></span></div><span style="font-family:monospace">On Host B: <span style="font-family:monospace">10.65.0.3 dev <interface to Pod B></span></span><div><div><div><div><span style="font-family:monospace"><br></span><div><span style="font-family:monospace">then <span style="font-family:monospace">run a BIRD BGP session between Host A and Host B to propagate those routes to the other host - which would normally give us:<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">On Host A: 10.65.0.3 via 10.240.0.5<br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">On Host B: 10.65.0.2 via 10.240.0.4<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">But we don't want those normal routes, because then the data would get lost at 'Router'.  So we enhance and configure BIRD as follows.<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">- In the export filter for protocol kernel, for the relevant routes, we set an attribute 'krt_tunnel = tunl0'.<br><br>- We modify BIRD, as in the attached patches, to understand that that means that those routes should have 'dev tunl0'.<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">Then instead, we get:<br><br></span></span><div><span style="font-family:monospace"><span style="font-family:monospace">On Host A: 10.65.0.3 via 10.240.0.5 dev tunl0 onlink<br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">On Host B: 10.65.0.2 via 10.240.0.4 dev tunl0 onlink<br></span></span></div><span style="font-family:monospace"><span style="font-family:monospace"><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">which allows successful routing of data between the Pods.<br><br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">Thanks for reading this far!  I now have three questions:<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">1. Does the routing approach above make sense?  (Or is there some better or simpler or already supported way that we could achieve the same thing?)<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">2. If (1), would the BIRD team accept patches broadly on the lines of those that are attached?<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">3. If (2), please let me know if the attached patches are already acceptable, or otherwise what further work is needed for them.<br><br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">Many thanks,<br></span></span></div><div><span style="font-family:monospace"><span style="font-family:monospace">    Neil<br><br></span></span></div></div></div></div></div></div>