gated and Zebra
gated and Zebra
This discussion of the methods of classification of routes into realms depends on the cooperation of the dynamic routing utility. In UNIX, all dynamic routing that was not simple RIP was traditionally done by the gated daemon. The gated daemon handles all types of routing. The protocol listing includes OSPF, BGP, RIP, HELLO, STATIC, ISIS, and methods of importing and exporting selected sets of information from one protocol to another.
Since the gated daemon was handed off to the MERIT consortium things have changed somewhat. The source code is no longer freely available and the license has changed to academic and non-commercial use only. Now gated has been spun off into a corporation, which will provide a commercial version for sale. The source code to the older versions is still available, however, and version 3.5.10 with patches by Alexey Kuznetsov is the one used with the Linux RPDB.
There is also a new source for routing daemons that has full GPL source code. This is the Zebra project based at http://www.zebra.org. Zebra pursues the concept of inde pendent routing daemons for each protocol. These are all tied into a core zebra daemon, which actually manipulates the FIB inside the kernel. This setup provides a good analogy for the split between the Routing Information such as is provided by a routing protocol and the FIB, which does the actual forwarding action.
You will want to consider both of these daemons. The gated daemon is stable and works quite well. The Zebra suite is rapidly evolving and represents the likely face of dynamic routing in the future.
The gated Utility
The gated source that you will use is an older one, 3.5.10. Under Linux you will need to patch it to run under glibc 2.1 and to run with the ip utility. The patched version is on the CD and available from the Web site. For now I will assume that you have obtained the patched source and compiled it.
The most difficult part of getting gated to work is setting up the configuration file. The are a few quirks that you should know about. First of all, the order in which the objects are specified in the configuration file are absolute. If you do not have them in the correct order and list only the ones that are compiled into the gated binary, you get a lot of complaints about parse errors and statements out of order. The second most common problem is forgetting a semicolon for terminating lines. Semicolons are also required for terminating braces. See the examples.
The best way to put together a config file is to get one that works from someone else and then carefully modify it. Otherwise go slowly and set up the sections one by one and test each time. Thankfully, the gated daemon itself can be called with a command-line option ( -C ) to check the config file and also one to specify the file ( -f conffilename ). So, you can at least verify that your syntax is correct.
You decide that you want to run OSPF on your corporate network. In order to see how to set up gated , you decide to test it first by running it on a single connected machine. You know that the routers are already running OSPF under area 0.0.0.0. This area is usually referred to as the backbone area. So you set up the following gated.conf file:
routerid 192.168.1.1; ospf yes { defaults { ospfarea backbone;} ; } ; This simply tells your system to run OSPF with all the standard defaults and join area backbone . Note that the routerid must correspond with an interface on the system and that that interface must be running when you start gated . Also note carefully where and how the semicolons are placed.
Now you simply run gated from the command line. To check on the operation you look at your main routing table with ip route list:
127.0.0.1 dev lo proto gated/conn scope host 192.168.1.0/24 dev eth0 proto gated/conn scope link src 192.168.1.1
Note that your default route, which you knew you had entered earlier, is gone. Also, the routes to loopback and the local ethernet are now protocol gated/conn . If you look in /etc/iproute2/rt_protos you will see that this is protocol 248. But you do not see anything from the OSPF yet. So you wait a few minutes and look again. Now you see the routes that are on some of the routers:
127.0.0.1 dev lo proto gated/conn scope host 192.168.1.0/24 dev eth0 proto gated/conn scope link src 192.168.1.1 128.1.1.0/24 via 192.168.1.2 dev eth0 proto gated/ospf 128.1.2.0/24 via 192.168.1.4 dev eth0 proto gated/ospfase
You note that one of the routers is reporting a directly learned route. It is the 192.168.1.2 router and it is telling your machine about a route it has to 128.1.1.0/24. You know it is directly connected to that network. You also see that router 192.168.1.4 is reporting a route that it has imported from some other protocol ( gated/ospfase ). You happen to know that is a static route on that router and that static route is all it is supposed to report via OSPF. So all is working well.
Now you know that you have several areas in your network. So you decide to quickly set up a multi-area configuration to see how it works. The machine you use has two ethernet interfaces, one of which is in the backbone and one of which is in area 172.16.1.0. The interfaces are 192.168.1.1/24 and 172.16.1.1/24. So you generate the following configuration:
routerid 192.168.1.1; ospf yes { area 172.16.1.0 { authtype none; networks { 172.16.1.0 mask 255.255.255.0; }; interface 172.16.1.1 cost 2 { priority 1; }; }; backbone { authtype none; interface 192.168.1.1 cost 1 { priority 1; }; }; }; When you fire it up and look at your routing tables you see the same routes with the addition of the local connection for 172.16.1.0/24. This is puzzling because you see no difference with the exception of the locally connected area. So you start looking for a utility that will give you the information on the OSPF areas and what is going on with the dynamic routing.
You find out that you can specify a log file for gated within the configuration file. Additionally for OSPF there is an ospf_monitor utility that enables you to talk with your OSPF routers all throughout your network. Since your gated seems to be running fine, you decide to try the ospf_monitor utility.
Upon reading the documentation you need to create a database file with the IP addresses and names of the various OSPF routers along with the authentication type if authentication is used. Since at the moment you are not using authentication, you decide to quickly create a simple file named ospf.db located in the same directory as ospf_monitor , which contains the following text:
192.168.1.1 mygated 192.168.1.254 core
This file lists both your local gated router as well as the core OSPF router. And since the names are only used to identify the device to you, you can use names that make sense.
Now that you have the file created you run the ospf_monitor utility. This utility takes the name of the database file on the command line. It has its own set of commands that can be seen by entering a ? once you are in the utility. The initial start and commands look like the following:
root# ospf_monitor ospf.db listening on 0.0.0.0.1026 [ 1 ] dest command params > ? Local commands: ?: help ?R: remote command information d: show configured destinations h: show history x: exit @ <remote command>: use last destination @<dest index> <remote command>: use configured destination F <filename>: write monitor information to filename S: write monitor information to stdout (default) [ 2 ] dest command params > ?R Remote-commands: a <area id> <type> <ls id> <adv rtr>: show link state advertisement c: show cumulative log e: show cumulative errors l: <retrans> dump lsdb (except for ASEs) A: <retrans> dump ASEs W: <retrans> dump ASEs with LSID's v: dump all verticies o: print ospf routing table I: show interfaces h: show next hops N <r>: show neighbors - if r is set will print retrans lst [ 3 ] dest command params >
You note that the commands are sequentially numbered and that issuing commands is divided into local and remote. Since you know the order in which you input lines into your database file, you know that the dest index is for issuing remote commands. So you decide to look at your local OSPF information:
[ 3 ] dest command params > @1 o remote-command <o> sent to 192.168.1.1 Source <<192.168.1.1 mygated>> AS Border Routes: Router Cost AdvRouter NextHop(s) ---------------------------------------------------- Area 0.0.0.0: 192.168.1.1 0 192.168.1.1 192.168.1.254 1 192.168.1.254 192.168.1.254 Area 172.16.1: 192.168.1.1 0 192.168.1.1 Total AS Border routes: 3 Area Border Routes: Router Cost AdvRouter NextHop(s) ---------------------------------------------------- Area 0.0.0.0: 192.168.1.1 0 192.168.1.1 Area 172.16.1: 192.168.1.1 0 192.168.1.1 Total Area Border Routes: 2 Summary AS Border Routes: Router Cost AdvRouter NextHop(s) --------------------------------------------------- Networks: Destination Area Cost Type NextHop AdvRouter ----------------------------------------------------------------------- 192.168.1 0.0.0.0 1 Net 192.168.1.1 192.168.1.1 ASEs: Destination Cost E Tag NextHop AdvRouter ----------------------------------------------------------------------- 0.0.0.0 2 2 3 192.168.3.254 192.168.1.254 Total nets: 1 Intra Area: 1 Inter Area: 0 ASE: 1 done [ 4 ] dest command params > Here you see the details of all of the areas that you have configured on your router. You can also look at any of the other OSPF routers running as long as you enter them into the ospf.db file. This is a good tool for troubleshooting an OSPF network, especially when you do not have physical access to the other routers.
Note that gated itself can participate in many types of dynamic protocols. All of these protocols may be entered into the configuration file along with the appropriate parameters. In this case you only bothered with your OSPF network. But you can have the same machine participate in BGP, RIP v1/v2, and also the newer IPv6 versions of these protocols.
Note
If you are familiar with other routers, such as Cisco or Bay or Proteon, and have run multiple dynamic routing protocols on them, such as OSPF and RIP and BGP, then you may be wondering how Linux deals with such multiple routing structures. Remember that you can think of Linux as having two modes of routing: the traditional style and Policy Routing. While Policy Routing does provide for backward compatibility, for much of traditional routing the use of multiple dynamic routing protocols is one area where you have choices.
Consider the concept that is employed by most modern routers when dealing with multiple routes to the same destination, as learned from different routing protocols. Under traditional routing, and indeed in IPv4 routing in general, you only want one route to any given destination to be used. If you learn of a route to the same destination from two different protocols, which one do you use? To solve this problem, there is the concept of "believability" or weighting that is applied to the inputs from the protocols. In a Cisco or Proteon router, this is referred to as the Administrative Distance assigned to the routes from the given protocol. This Administrative Distance number provides a method of selecting the most "believable" route from several presented. For example, a static route has a distance of 1 whereas an OSPF route to the same destination would have a distance of 50, thus the static route would be selected as "best." In most cases this distance number can be manually changed in the configuration. The important point is that this mechanism ensures that there is one used route to the destination with all the other routes either becoming backups or standbys or simply being dropped.
In Linux, when you use the one main routing table this mechanism of distance or weighting is enforced with specified defaults in the RPDB. See the source for details on the various weights. The really key part is that with the RPDB you do not have to use only one routing table! As illustrated later in this chapter, when you allow the specific dynamic protocol to use a routing table all its own, then you control the route selection through the rules. So in Linux you can have all of the routes from all of the protocols available and then use the rules to select which route you want to use. Combine this facility of multiple routing tables for multiple routing protocols with the fact that you may have multiple routes to the same des tination in the same table, as long as the TOS for the route is different, and you have a true multitude of ways to route a packet.
In summary, Linux defaults to using a configurable Administrative Distance concept when using one routing table. Multiple routing tables and the use of TOS tagged routes allow you to completely override the selection of only one "believable" route and use whatever routes you want from whatever protocols you want. This includes overriding static and local routes if you want.
The Zebra Routing Suite
For now you are interested in how the newer Zebra dynamic routing suite works. To start working with it, you obtain the newest source and compile it for your platform. The best way to get the latest code is to use the cvs repository. Check out http://www.zebra.org for details. In this case you instead go get the latest code as a tarball. The version you will use is 0.89a. This version is on the CD and in the PakSecured distribution.
Once the Zebra suite is compiled you find that there are several executables and related configuration files. Since Zebra consists of independent executables for each routing protocol, you can run any set of the protocols. Each protocol has its own configuration file that sets the parameters for the protocol.
The core daemon is zebra . It has the master configuration for all of the interfaces and system static routes. This configuration tells the other daemons which interfaces are available and performs the actual interfacing to the FIB. Each of the protocol daemons maintains a RIB unique to the protocol. This is a very nice implementation of the split between the Routing Information and the FIB as implemented in Linux itself.
One interesting part about Zebra is that the entire interface structure is modeled after the Cisco IOS command line. This makes it quite simple to manage for those who have been exposed to the Cisco-style interface. Each daemon will listen on a known port for telnet connections. There is a user -mode interface that allows viewing the routing tables and configurations, and an enable mode that allows setting parameters.
For now you want to explore how Zebra will work within your OSPF network. Returning to the setups worked through in testing gated , you start the same way with a single interface into the network. You want to set up OSPF for listening-only for now.
First, you need to configure the core zebra daemon to know about your interfaces. Remembering how your static route disappeared in the first gated test (you ran it earlier in the " gated " section of this chapter), you decide to make sure that the static route is entered into the system. Since the zebra daemon is responsible for interfaces and static routes, you create the following zebra.conf configuration file, by default located in /usr/local/etc:
! -*- zebra -*- ! ! zebra zebra.ospf.1.0 configuration file ! hostname myzebra password zebra enable password zebra ! interface eth0 ip address 192.168.1.1/24 ! ! Static default route ! ip route 0.0.0.0/0 192.168.1.254 ! log file /tmp/zebra.log
Then you can just run the zebra daemon. Once it is running you can check your routing table with ip route list to see if there are any differences:
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.13 default via 192.168.3.254 dev eth0 proto zebra
Note that the default route is coded as from proto zebra . As you recall from the gated output, the kernel knows who put the route into the FIB. Note, however, that the actual interface was not recoded into a Zebra interface. This is in contrast to the gated setup where the interfaces ended up coded as proto gated/conn .
Now that you are satisfied that the zebra daemon is working, you leave it running and turn to configuring OSPF. For this you use the Zebra OSPF daemon, ospfd . The configuration file, ospfd.conf located in /usr/local/etc , is similar to the zebra daemon file but with OSPF-specific options. To set up for running on OSPF only you can use a simple configuration file as follows :
! -*- ospf -*- ! ! OSPFd zebra.ospf.1.2 configuration file ! hostname myzebra password zebra enable password zebra ! router ospf network 192.168.1.0/24 area 0 !
And then you run the ospfd daemon. It will receive the configuration information about the interfaces from the zebra daemon. So once it is running you check your routing tables again:
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 128.1.1.0/24 via 192.168.1.2 dev eth0 proto zebra 128.1.2.0/24 via 192.168.1.4 dev eth0 proto zebra default via 192.168.1.254 dev eth0 proto zebra
Now you note one of the differences between Zebra and gated . In the same listing from gated you saw that there was a difference both in the name of the protocol and in whether it was a remote route or a remote static route. Here you only see that the protocol is zebra . You do not know if this route was added from a static, as the default route should be coded, or from OSPF, as 128.x.x.x/24 should be.
This is partially due to Alexey's gated patches allowing for different inputs from the gated daemon. Additionally, the gated daemon itself tracks internally which route is from which protocol. Remember that gated is monolithic; in other words, everything is in the same package. Since Zebra implements the split between the Routing Information and the FIB, the FIB only sees that the routes were updated from the zebra daemon.
This brings up the question of how to tell which routes came from which protocol within the Zebra suite. Recall that there is a telnet interface to the local daemons for the Zebra suite. To see what the various routes are from you need to connect to the various daemons and look at their individual internal routing tables. This is also where the additional information such as area for OSPF is located.
There are two ways to connect to the daemons for information. The first one is to telnet to the appropriate port for the local daemons individually. In this case zebra is on 2601 by default and ospfd is on 2604. This method requires that you connect to the ospfd for OSPF information and zebra for static and interface information. The alternative method is to use the integrated shell. This is vtysh . You can simply execute this command and have access to the various parts of the Zebra suite from one command line. Due to the integration and single point of information, you decide to just use the vtysh . It is simply executed from the command line. Note that there is the full Cisco IOS “style execution with a user-level prompt ( > ) and the enable or superuser prompt ( # ). See the Zebra documentation for details.
[root@paksecured /root]# /usr/local/bin/vtysh Hello, this is zebra (version 0.89a) Copyright 1996-2000 Kunihiro Ishiguro zebra> en zebra# sh ip ro Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, * - FIB route. S* 0.0.0.0/0 [1/0] eth0 (3) 192.168.3.254 O 0.0.0.0/0 [110/11] eth0 (3) 192.168.3.254 C* 127.0.0.0/8 lo (1) direct O* 128.1.1.0/24 [110/11] eth0 (3) 192.168.3.2 O* 128.1.2.0/24 [110/11] eth0 (3) 192.168.3.4 C* 192.168.3.0/24 eth0 (3) direct zebra#
This gives you the entire routing table as it is seen from the zebra daemon's point of view. Note that there is a difference between the protocols in this routing table. You want to see what the OSPF information is from the ospfd daemon.
zebra# sh ip ospf OSPF Routing Process, Router ID: 192.168.1.1 Supports only single TOS (TOS0) routes This implementation conforms to RFC2328 RFC1583Compatibility flag is disabled SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Refresh timer 10 secs Number of external LSA 3 Number of areas attached to this router: 1 Area ID: 0.0.0.0 (Backbone) Number of interfaces in this area: Total: 1, Active: 1 Number of fully adjacent neighbors in this area: 1 Area has no authentication SPF algorithm executed 5 times Number of LSA 3 zebra# zebra# sh ip os nei Neighbor ID Pri State Dead Time Address } Interface RXmtL RqstL DBsmL 192.168.1.254 2 Full/DR 00:00:32 192.168.1.254 } eth0 0 0 0 zebra#
Now you are also curious as to how the interfaces are functioning. So you look at the information for eth0:
zebra# sh int eth0 Interface eth0 index 3 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,MULTICAST> HWaddr: 00:50:56:8b:03:0d inet 192.168.1.1/24 broadcast 192.168.1.255 inet6 fe80::250:56ff:fe8b:30d/10 input packets 3297, bytes 1337231, dropped 0, multicast packets 0 input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0 output packets 1101, bytes 86436, dropped 0 output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0 collisions 0 zebra# This interface gives you all the information you would need to manage and troubleshoot the system.
Caution
The vtysh interface functions by using the terminal interfaces to the various daemons. These interfaces are standard telnet connections and all data is passed in the clear. You can disable the terminal interfaces by simply remarking out or not including the password and enable password lines in the configuration files. However, you then disable the ability of vtysh as well.
From a security standpoint, you would only want to run these daemons with the terminal interfaces if you have taken other precautions to disable access to those ports.
| Top |
