Traditional routing software is made as a one process program which provides all of the routing protocol functionalities. Zebra takes a different approach. It is made from a collection of several daemons that work together to build the routing table. There may be several protocol-specific routing daemons and zebra the kernel routing manager.
The ripd daemon handles the RIP protocol, while
ospfd is a daemon which supports OSPF version 2.
bgpd supports the BGP-4 protocol. For changing the kernel
routing table and for redistribution of routes between different routing
protocols, there is a kernel routing table manager zebra
daemon. It is easy to add a new routing protocol daemons to the entire
routing system without affecting any other software. You need to run only
the protocol daemon associated with routing protocols in use. Thus,
user may run a specific daemon and send routing reports to a central
routing console.
There is no need for these daemons to be running on the same machine. You can even run several same protocol daemons on the same machine. This architecture creates new possibilities for the routing system.
+----+ +----+ +-----+ +-----+
|bgpd| |ripd| |ospfd| |zebra|
+----+ +----+ +-----+ +-----+
|
+---------------------------|--+
| v |
| UNIX Kernel routing table |
| |
+------------------------------+
Zebra System Architecture
Multi-process architecture brings extensibility, modularity and
maintainability. At the same time it also brings many configuration
files and terminal interfaces. Each daemon has it's own configuration
file and terminal interface. When you configure a static route, it must
be done in zebra configuration file. When you configure BGP
network it must be done in bgpd configuration file. This can be a
very annoying thing. To resolve the problem, Zebra provides integrated
user interface shell called vtysh. vtysh connects to
each daemon with UNIX domain socket and then works as a proxy for user input.
Zebra was planned to use multi-threaded mechanism when it runs with a
kernel that supports multi-threads. But at the moment, the thread
library which comes with GNU/Linux or FreeBSD has some problems with
running reliable services such as routing software, so we don't use
threads at all. Instead we use the select(2) system call for
multiplexing the events.
When zebra runs under a GNU Hurd kernel it will act as a
kernel routing table itself. Under GNU Hurd, all TCP/IP services are
provided by user processes called pfinet. Zebra will provide
all the routing selection mechanisms for the process. This feature will
be implemented when GNU Hurd becomes stable.