Dec 30

IOS + Linux = Quagga

Posted by Alex Juncu

Cisco IOS’s shell is a popular interface for devices in the networking world. But also in the network world, there are a lot of Linux/Open Source fans. The Quagga open source project tries to bring together IOS and Linux, by providing an IOS-like interface for configuring Linux’s interfaces, routing table and firewall, along side its own implementations of RIP, OSPF and BGP daemons.

The Quagga Software Routing Suite comes as a set of daemos. The main one is the zerbra daemon (Zebra is the old name of the project). This core daemon does the interaction with the Linux kernel and, also, with other daemons like ripd (RIP daemon), ospfd (OSPF daemon), bgpd (BGP daoemon). Quagga is modular, so you can implement new protocols if needed via a standard API.

To configure Quagga, you first need to start the daemons (at least the core one), in the /etc/quagga/daemons file. Each daemon has its own configuration file (ex. /etc/quagga/zebra.conf, /etc/quagga/ripd.conf etc.). Accessing the IOS-like shell is done via the vtysh command. Once in this shell, most commands available in Cisco’s IOS are available.

Router / # cd
Router ~ # vtysh

Hello, this is Quagga (version 0.99.18).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

Router# conf t
Router(config)# hostname  LinuxRouter
LinuxRouter(config)# exit
LinuxRouter# show ?
bgp             BGP information
clns            clns network information
daemons         Show list of running daemons
debugging       State of each debugging option

[...]

Keep in mind that some things are not 100% identical to a Cisco router (ex. the interface names). Here’s an example of how to configure an interface.

LinuxRouter# conf t
LinuxRouter(config)# interface  eth0
LinuxRouter(config-if)# ip address  141.85.42.1 ?
A.B.C.D/M  IP address (e.g. 10.0.0.1/8)
LinuxRouter(config-if)# ip address  141.85.42.1/24
LinuxRouter(config-if)# link-detect

Monitor output (show commands) are similar aside some Linux specific details (ex. Kernel routes are available in Linux, but not in IOS).

Router# sh ip route
Codes: K – kernel route, C – connected, S – static, R – RIP, O – OSPF,
I – ISIS, B – BGP, > – selected route, * – FIB route

K * 0.0.0.0/0 via 192.0.2.1, venet0 inactive
O 10.10.12.0/24 [110/10] is directly connected, eth0, 00:03:41
C>* 10.10.12.0/24 is directly connected, eth0
O 10.10.14.0/24 [110/10] is directly connected, eth1, 00:03:36
C>* 10.10.14.0/24 is directly connected, eth1
O>* 10.10.23.0/24 [110/20] via 10.10.12.2, eth0, 00:02:46
O>* 10.10.24.0/24 [110/20] via 10.10.12.2, eth0, 00:02:14
*via 10.10.14.4, eth1, 00:02:14
O>* 10.10.25.0/24 [110/20] via 10.10.12.2, eth0, 00:02:41
O>* 10.10.35.0/24 [110/30] via 10.10.12.2, eth0, 00:01:21
* via 10.10.14.4, eth1, 00:01:21
O>* 10.10.45.0/24 [110/20] via 10.10.14.4, eth1, 00:02:08
C>* 127.0.0.0/8 is directly connected, lo
C>* 127.0.0.1/32 is directly connected, venet0
C>* 172.10.10.0/32 is directly connected, venet0
K>* 192.0.2.1/32 is directly connected, venet0

Configuring a routing protocol instance is also similar:

LinuxRouter# conf t
LinuxRouter(config)# router ospf
LinuxRouter(config-router)# network  192.168.123.0/0 area 0

As you can see, coming from an IOS background, this tool is very easy to use on your Linux box. It is far from perfect since it doesn’t have the years in production like IOS or iproute2, but it is cool to test out.

Jul 18

Scenario:
You have two routers running RIP, but the two routers aren’t directly connected because there is a third router between them. See topology below. How do you get routes across because RIP only communicates with routers that are directly connected?
riplab

The simple answer is to create a GRE tunnel between R1 and R3 so a tun interface simulates a direct connection of the two routers. But let’s take a more didactic approach to remember some things about RIP.

RIP v2 sends the updates to the address 224.0.0.9 that is a local multicast address (TTL=1).  But there is another, very important in some situations (like some Frame Relay networks), way to send routes, and that is via unicast to a statically configured neighbor. Configuration is done via the neighbor command in the router rip configuration.  The routes will be encapsulated in normal IP unicast packets and since RIP runs on top of UDP, they should be routed as any other packet.

R1:

interface Serial0/0/1
ip address 10.1.2.1 255.255.255.0
interface Loopback 0
ip address 192.168.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 192.168.0.0

neighbor 10.2.3.3
no auto-summary

R3:

interface Serial0/0/1
ip address 10.2.3.3 255.255.255.0
interface Loopback 0
ip address 172.16.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 172.16.0.0
neighbor 10.1.2.1
no auto-summary

You still need to have a network command for the interfaces when you send and receive the updates (in this case 10.0.0.0) otherwise the received updates will be ignored.

First thing you should be careful of is the fact that R1 and R3 need layer3 communication. So you do need static routes for the R1 and R3 routers through R2.

Having connectivity between each other, the router starts sending unicast packets with the routes. debug ip rip would show the following:

RIP: sending v2 update to 10.1.2.1 via Serial0/0/1 (10.2.3.3)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0

Notice the update is sent to an unicast address and not 224.0.0.9.

Routes are received but they still are not in the routing tables. debug ip rip shows why:

RIP: ignored v2 update from bad source 10.2.3.3 on Serial0/0/1

This reminds us of how RIP works: if a router receives an update it checks to see if the source of the packet is on the same subnet as the IP configured on the interface. If they don’t match, the update is ignored. In our case, the source of the updates are not on the same network because R2 does not modify the packet source/destination in any way.

The solution to this is to disable the default mechanism with the no validate-update-source command in the router rip configuration. This way any updates will be accepted.

Here is a wanted route in the routing table of R3:

R    192.168.0.0/24 [120/1] via 10.1.2.1, 00:00:27

Notice that the next hop is not directly connected so it need to do a recursive lookup and use the static route to send it to R2 first.

S       10.1.2.1/32 [1/0] via 10.2.3.2