Routing on the Host user guide


Show first post

33 replies

how does this integrate with KVM using openvswitch, would like to find out how to inject the routes when using bridges on vlans.
Userlevel 5
Mr Roger wrote:

how does this integrate with KVM using openvswitch, would like to find out how to inject the rout...

I have not looked at that particular integration however it should be possible. If you can add a hook to openvswitch to add the route via a CLI command that would work; the other option that comes to mind is to write a little daemon that looks at configured bridges for some predefined interval and adds/removes them from the routing fabric.
This is a good guide but can you possibly point me to one for the containerisation side of things? As a network guy getting a packet to the host is easy and running Quagga in a container to make the announcements makes perfect sense. The bit I'm struggling to articulate to the DevOps guys is how that packet gets to a container once it lands on the host without the host having the IP address configured on it beforehand! Should we for example, be running Quagga in every container, the next hop being a loopback address configured in the container? The DevOps-y way of solving all this seems to be bridges and ridiculously complicated (to me!) sequences of commands which just feels wrong. We're using RancherOS so anything Docker-like we should be able to adapt and hopefully find a common language!! Thanks!
Userlevel 1
Simon Woodhead wrote:

This is a good guide but can you possibly point me to one for the containerisation side of things...

The container networks on the host would be advertised to it's neighbors via OSPF or BGP. Your host has L3 connectivity, instead of L2, to your Cumulus switch.
Userlevel 5
Simon Woodhead wrote:

This is a good guide but can you possibly point me to one for the containerisation side of things...

What I see is that the server's management IP address is typically already applied which is how the Quagga installation is initially deployed/configured, (if the server image is not deployed with a base Quagga config on initial turn-up). Most people run a single instance of Quagga in a privileged container giving it access to the kernel/server interfaces to setup routing adjacencies and install routes into the kernel. This container will advertise-out all the other bridges/l3 subnets/host-routes running for the containers on that server as the case may be. Using tech like BGP unnumbered gets you away from having to worry about the IP addresses on interfaces etc. Allows the server to be picked-up and moved across the DC arbitrarily as the BGP relationship will re-establish anywhere it happens to get plugged-in. Complicated bridge configs are not needed here unless you prefer that method or have some other constraint. The important thing to remember (which I always forget to mention) is that we're not using Quagga as a Vrouter with namespaces or anything like that; all external traffic leaving/entering the containers is not passing through the Quagga container first.
Simon Woodhead wrote:

This is a good guide but can you possibly point me to one for the containerisation side of things...

Thanks Eric. This is about where we've ended up with a slight difference. Because we want a single prefix to span multiple hosts, we need to ensure that any container seeking to reach addresses in that prefix are routed away from the host rather than flooded out the relevant interface given there is no layer2 adjacency between them. The primary application for this is anycast but also the kind of mobility you describe without any specific host configuration.

We found this plugin (https://github.com/medallia/cnm-routed-plugin04377) which together with a priveleged container looks like it'll do the job. As you say, we'll use the host ip as the next hop rather than routing through Quagga.
Thanks again,
Simon

Userlevel 3
Simon Woodhead wrote:

This is a good guide but can you possibly point me to one for the containerisation side of things...

Hi Simon, one of our sales engineers wrote up an anycast design guide, that I published just the other day. Let me know if this helps you at all.

https://docs.cumulusnetworks.com/display/DOCS/Anycast+Design+Guide
Simon Woodhead wrote:

This is a good guide but can you possibly point me to one for the containerisation side of things...

I'll check it out. Thanks!

Reply