Openvpn – Routing with Quagga and OpenVPN

networkingopenvpnospfquaggarouting

We plan to connect servers in two racks with each other. Let's assume we have 5 servers in each rack, connected with a fast switch. Each server has a 1 GBit Internet uplink.

The following might be very stupid, but networking is not my area of expertise, that's why I need your help.

We are creating several OpenVPN connections (see the attached image, the 'blue clouds' are VPN networks), because we want to use the full 1 GBit connection between them. But if one server goes down, we still want a working connection between the two racks.

So, what we did:
1. Configure OpenVPN between each S[1-5] and C[1-5] server, creating a virtual network of 10.0.5x.0/24. (This is already working)
2. Install and configure Quagga with OSPF to announce routes. We did this for every node, so everyone can be a router for someone else (we don't want only one single gateway, because that would limit the connection between the racks to only 1 GBit, right?!)
3. Quagga now announces routes and everyone can ping everyone else (also working)

Now the play begins: We take C4 down and the routes get updated accordingly (speaking of OSPF and quagga). But what happens now if we try to ping from S4 to C5, it takes some route that C5 belives is not the best route (thats my understanding of the rp_filter linux networking setting to 1). The route we see in tcpdump is S4 -> S3 -> C3 -> C5. A better route would be S4 -> S5 -> C5.

If we set rp_filter to 2, the ping works, but it feels wrong to allow non-optimal routes? We thought OSPF is there to get the best (shortest route) possible? But we guess that we've configured Quagga / OSPFd wrong.

Here is the image of the topology we have in mind:
topology

The ospfd.conf looks like this

interface eth0
interface bond0
interface tun0

router ospf
  router-id 10.0.1.4
  network 10.0.1.0/24 area 0
  network 10.0.54.0/24 area 1
  redistribute static

zebra.conf:

interface bond0
  link-detect
interface tun0
  link-detect

Best Answer

In short, you should put all of your interfaces in the same area to get the behavior you desire. Inter-area routing is quite complicated internally and the whole concept of areas exist primarily for the sake of partitioning large routing networks into managed-size ones. This is not your case, if number of routers you give is correct.