Configuring Zebra for Routing

Before the services can be started at least minimal configuration files must created for the routing manager and the protocol engines that are intended to be used. We will look at this next.

Configuring Zebra for Routing

The default location for Zebra’s configuration files is /usr/local/etc.The installer creates a sample file for each of the daemons as

daemon_name.conf.sample (zebra.conf.sample for the routing manager, for instance).To create a basic configuration for each daemon, simply create copies of the appropriate files (minimally, for Zebra itself ) in /usr/local/etc without the .sample suffix.The included files contain enough information for the services to start and to permit access via Telnet.

Once the configuration files are in place, the daemons can be started with SystemStarter as normal (sudo SystemStarter start zebra).The first steps upon starting the daemons should be basic configuration.This includes pro-viding hostnames, passwords, IP addresses, and any needed static routes to the system.

N

It is also possible to fully configure the daemons before starting them via the configuration files. In either case (Telnet or direct file modifica-tion) the individual commands are the same, as long as location within the file is properly maintained. The intent here is to demonstrate basic configuration the way it would be completed on a production device, and it is easier to write the configuration from the vty session.

Connect to the vty interface of the main routing manager by connecting with Telnet to port 2601. When prompted for a password, use the default of zebra.This should set the session to a Router> prompt.This initial mode is read-only with very limited access.To enter privileged mode, type enable at the prompt and enter the default password,zebra.This mode is largely read-only, with the exception of the ability to the system configuration and some session parameters, so we need to enter configuration mode to make further modifications.This is done by typing config term at the Router# prompt.

N

Astute and experienced users will note that the commands and con-figuration files used by Zebra are very similar to Cisco’s own IOS. This is very true, but only to a point. Zebra resembles something like an IOS that was forked at about IOS version 10. While it shares a

number of basic syntactical features, the Zebra syntax is also very dif-ferent from what Cisco administrators would see today (and in many ways, happily less complicated, but also less feature-rich). Zebra for instance, does not use wildcard masks like IOS, but tends to use CIDR (Classless Inter-Domain Routing) notation instead. It also has a dif-ferent method of dealing with named access lists; they are created with the access-list …command rather than IOS’s ip access-list extended…command, and are the more limited standard access lists rather than the extended variety. Rather than as in IOS (in most cases anyway), whose configuration is monolithic with all available func-tionality being available in one place, Zebra splits the dynamic proto-cols off into additional processes with their own configuration files.

Though the differences are many, most administrators familiar with IOS will be able to find their way around Zebra with ease.

This mode (evidenced by the prompt changing to Router(config)#) is read/write and changes are instantaneous, though not automatically saved.To set the hostname for the routing engine (informational only, but useful when multiple devices are under one’s domain), type hostname Zeblah(where

It is a good idea to set the logon and enable mode passwords away from the default as well.This is done with two commands:

password somep@Sw0rdthatsrea77yl0ngandg00d

enable password some()therp@ZwerdthatsalsoreallEElo|\|gandg00d!

It is also a good idea to encrypt passwords in the configuration, so if a configuration is leaked it will still be difficult for someone to obtain adminis-trative access:

service password-encryption

If an administrator wishes to add additional IP addresses to interfaces beyond those set at the OS level (via the ifconfig command, or GUI, as shown earlier) it is possible to do this within Zebra as well.

T

It is probably better to add the extra addresses through the zebra process if the reason for the additional addresses and interfaces is for routing. It is cleaner and easier to manage in the long run.

To add IP addresses to an interface, enter configuration mode (if not already there), then enter interface configuration mode for the interface you wish to configure.The general command for this is interface <INTER-FACE_NAME>.The prompt will change accordingly and allow you to enter subcommands for the interface (of which IP addressing is just one).The fol-lowing example enters interface configuration mode, then adds an IP address of 10.10.10.10 (with a subnet mask of 255.255.255.0) to interface en0:

Router(config)#

Router(config)# interface en0

Router(config-if)# ip address 10.10.10.10/24

Notice that the prompt changes accordingly. Additional addresses can easily be added with additional instances of the ip address subcommand.

Once added, these IP addresses show up in ifconfig output as seen in the fol-lowing snippet:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::214:51ff:fe0a:d238%en0 prefixlen 64 scopeid 0x4 inet 192.168.0.104 netmask 0xffffff00 broadcast 192.168.0.255 inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:14:51:0a:d2:38

media: autoselect (10baseT/UTP <half-duplex>) status: active supported media: none autoselect 10baseT/UTP <half-duplex>

10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX

<half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback>

The other major piece of functionality the Zebra routing manager pro-vides is static routing, the configuration of which is performed in general configuration mode (to exit interface configuration mode, type exitat the prompt).The general form of a route statement is ip route followed on the same line by a destination network in one of two forms:

■ A.B.C.D/M The network address in CIDR notation

■ A.B.C.D W.X.Y.Z The network address and subnet mask in dotted-quad notation

This is continued with a next hop location in one of three forms:

■ M.N.O.P The IP address of the next hop

■ INTERFACE(en0, or en1, or ppp0, for example) The interface out of which packets should be pushed, usually used for point-to-point links

■ Null0 A special interface of sorts that makes packets go poof, into a black hole rather than being processed further

For example, the following would add the network 172.16.16.0/25 with a next hop of 10.10.10.254 and route packets destined for 10.100.100.0/24 into the floor:

ip route 172.16.16.0/25 10.10.10.254 ip route 10.100.100.0 255.255.255.0 null0

While all of the above changes take effect immediately, if the machine is rebooted (or gods forbid, the daemon crashes), any configuration will be lost.

exit command) and enter write memory.This will write the configuration out to the configuration file.

N

Like the Cisco IOS, Zebra has the concept of a difference between a startup configuration and a running configuration. Changes to the configuration of a running process are effective immediately, but will not survive a restart of the process. Only by writing the running con-figuration out to the startup concon-figuration will the changes survive a reboot.

The other daemons included with Zebra take the next step and provide dynamic routing services. Each of these processes is configured separately with separate configuration files (as discussed earlier in this section) and sepa-rate vty servers.Table 1 2 describes the default ports for each of the zebra ser-vices and a basic description of its functionality.

Table 1.2Zebra Processes, Ports, and Functions

Process Port Function

zebra tcp 2601 Zebra primary process ripd tcp 2602 RIPv1/v2 server

ripngd tcp 2603 RIP IPv6 server ospfd tcp 2604 OSPF server bgpd tcp 2605 BGP server ospf6d tcp 2606 OSPF IPv6 server

Each routing protocol’s daemon’s configuration is similar to that of the zebra process. For each protocol in use, it is still proper to set the hostname and the two passwords.The process is exactly as seen above, except that you Telnet to a different port and the default enable password for the other dae-mons is blank. Each daemon also has to be configured with the networks it will be announcing via the protocol it governs, which is enabled with the network command.The following are examples of how each protocol uses this command to announce 10.10.10.0/24 to neighbors:

■ RIP (ripd.conf )

! enable RIP (defaults to version 1 unless specifically set

! with the 'version' command router rip

network 10.10.10.0/24

■ RIPng (ripngd.conf )

! enable RIPng router ripng

network 10.10.10.0/24

■ OSPF (ospfd.conf )

! enable OSPF router ospf

! announce the network (here we will assume it is area zero) network 10.10.10.0/24 area 0

■ OSPF6 (ospf6d.conf )

! enable OSPF6 router ospf6

! announce the network (here we will assume it is area zero

! and there is no "network" command for v3 (IPv6) so we will use

! interface en0 as the interface for area 0 interface en0 area 0.0.0.0

■ BGP (bgpd.conf )

! enable BGP (here we will assume it is ASN 1) router BGP 1

network 10.10.10.0/24

W

Since each process’s password is blank by default, it is a very neces-sary part of configuration to set it to something more secure. And

Beyond the basics, the daemons typically need additional, protocol-specific configurations.These parameters depend quite a bit on which protocol is being used and how it has to be implemented to suit a particular network. In fact, the number of different ways an administrator can deploy these protocols is rather large (even when counting the subset of “correct” ways), so we will only touch on some basics here.The man pages and online documentation can assist greatly in tailoring the configuration to suite the needs of the net-work and its administrator(s).