1.2 System Architecture

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.