Dual-Stack OSPF Routing with Quagga

In order to better learn about IPv6 I wanted to set up dual-stack routing on a virtual network. I chose to implement Quagga with OSPFv2 for IPv4 routing and OSPFv3 for IPv6 routing. I did this primarily because the price was right (free) and it could be implemented on a regular Ubuntu server that could also be used for other network support protocols (DHCP, DNS, multicast routing etc.). As usual everything here was implemented using VirutalBox on a Linux Mint host. What follows are examples of how to set up Quagga for dual-stack routing.

I chose OSPF because it was a robust, modern Internal Gateway Protocol (IGP) that was relatively easy to set up. I make no claim that the example presented here is perfect or even optimal, I only claim that I tried to keep it simple and that it works for me. I'm writing this for two reasons: to preserve what I have learned (my memory isn't what it used to be) and because a concrete example would have been helpful while I was learning this, so I thought I would supply one for those learning this stuff themselves.

In order to better follow this exercise, below is a diagram of the virtual network used. Note: the IPv6 prefixes are not my actual prefixes (I'd rather not share those publicly) but dummy addresses utilizing IPv6 "Unique Local IPv6 Unicast Addresses" (RFC 4193).  Such addresses can't actually be routed over the Internet. My real IPv6 addresses route just fine.

The three hosts that are the focus of this discussion:

• gator.jrl.home is a pfSense dual-stack router with BIND add-on
• route1.jrl.home is Ubuntu server v14.04.3 with Quagga and DHCP server
• route66.jrl.home is Ubuntu server v14.04.3 with Quagga and DHCP relay

It's important to know the static IP addresses for these hosts:

Router Addresses

All addressing and routing on "Net 0" on the diagram are statically assigned (no DHCP or OSPF routing). The pfSense router (gator) had static routes for Nets 1 - 3 added (for both protocols) and in addition new firewall rules added to allow hosts on the new networks to access gator and pass Internet traffic as well as local traffic on Net 0.

After installing "route1" and "route66" from ISO images files and updating them static addresses were assigned to all interfaces and packet forwarding was enabled through /etc/sysctl.conf, setting the following:

• net.ipv4.conf.all.forwarding=1
• net.ipv6.conf.all.forwarding=1

This turns your server from a multi-homed host into a router. After this step it's time to install Quagga from the repositories and edit some configuration files.

In the /etc/quagga directory on each router there are 5 text files. For the examples presented here only 4 of them need to be altered or created. You can leave debian.conf untouched it just tells the quagga processes where to run their terminal processes (more on this later).

The zebra.conf file is the one that requires the most information. Here is the sample zebra.conf file for route1

zebra.conf for route1.jrl.home

The IPv4 information should be familiar to anyone setting up Linux on a network. Some of the IPv6 addresses used here are all "Link-local" addresses for the interface in question, which can be discovered by using "ifconfig". IPv6 link-local addresses begin with "fe80". Routing information is passed from router to router using the link-local addresses in OSPFv3.

Near the bottom of each interface definition there are 4 IPv6-related directives that could use some explanation.

• no ipv6 nd suppress-ra - means do not suppress IPv6 router advertisements
• ipv6 nd managed-config-flag - means that DHCPv6 is in use for addressing
• ipv6 nd other-config-flag - means that DHCPv6 info other than addresses are in use
• ipv6 nd prefix fdf8:fade:deaf:5150::/64 - means advertise this prefix

Unlike DHCPv4, DHCPv6 does not "handle" routing information. That function is left to the router advertisement daemon that is part of an IPv6 router (in this case quagga). The IPv6 protocol has a powerful Stateless Autoconfiguration (SLAAC)  capability that does not rely on DHCP for addressing. Address assignment and routing information are configured automatically. What does not get assigned automatically are: addresses of the DNS servers, the host's domain name, and alternate search domains etc. As set up in these examples, each workstation will end up with one IPv4 address and four IPv6 addresses:

• Link-local address derived from the hardware address and assigned by the kernel
• SLAAC address also derived from the hardware address and the prefix from the router
• A privacy address that is dynamic, random and combined with the prefix from the router
• A managed address supplied by the DHCPv6 service

Depending on your operating system any of the three "global" (non link-local)  IPv6 addresses can be used by applications to contact remote systems. On my systems the default is to utilize the "privacy address" when contacting remote systems. Since that address is dynamic and random (on every reboot for instance) it makes it harder to track you on the Internet. Any of the 3 global addresses can be used by other systems to contact your workstation (i.e. ping6).

DHCPv6 is not required for automatic IPv6 address assignment, as long as the host being configured "knows" it's own domain and the addresses of it's DNS servers (usually by static assignment). It is also possible to distribute only that information (domain name and DNS server addresses) using DHCPv6 and leave the automatic addressing to SLAAC with information supplied by the router advertisements. The "ipv6 nd other-config-flag" directive is there for exactly this sort of setup.

To continue with the configuration of route1, let's look at the /etc/quagga/ospfd.conf file:

ospfd.conf for route1.jrl.home

This is pretty simple it just places the interfaces (represented by their IPv4 addresses) into the same OSPF routing area, then redistributes any learned routes and any statically configured routes into that area. This is all that is needed to configure the OSPFv2 daemon (IPv4 routing daemon) in quagga.

Now let's look at the OSPFv3 (OSPF for IPv6) routing configuration for route1 contained in the /etc/quagga/ospf6d.conf file:

ospf6d.conf for route1.jrl.home

This accomplishes the same thing for IPv6 as ospfd.conf did for IPv4. This time the interfaces are designated explicitly by their kernel names (instead of indirectly as in ospfd.conf). My guess is that the OSPFv3 was developed later and perhaps by another developer who "did it his way". I find this way "cleaner".

The same configuration files need to be created for route66 and they look very much the same as the OSPF configuration for route1:

ospfd.conf and ospf6d.conf for route66.jrl.home

The zebra.conf file is unique for route66, since it reflects the actual hardware in use, with unique hardware and IP addresses:

zebra.conf file for route66.conf

Finally there are two files that are the same on both route1 and route66 the /etc/quagga/daemons and /etc/quagga/debian.conf files:

daemons and debian.conf file for both route1 and route66

The "daemons" file determines which daemons within the quagga suite should actually run and the debian.conf file describes how and where the various  protocol daemons should  listen for terminal connections. Each of the protocols in use (ospfd and ospf6d  as well as zebra in our case) has a command-line interface accessible via telnet. It has some similarities to the command interface on cisco routers. Each of the three daemons runs on a different port on the localhost interface of each router:

• telnet localhost 2601 - will get you to the command interface of the zebra daemon
• telnet localhost 2604 - will get you to the command interface of the ospfv2 daemon
• telnet localhost 2606 - will get you to the command interface of the ospfv3 daemon

Those "enable password" statements at the top of the configuation files (zebra.conf, ospfd.conf and ospf6d.conf) set the passwords you will have to supply to actually get to those command interfaces.

Once logged in, typing a question mark will get some help with the commands. Once you have (re-)started the quagga daemons on both routers, you should be in business.

There are resources on the web for learning Quagga. One site is here: http://www.nongnu.org/quagga/docs.html