Bering-uClibc 7.x - User Guide - Advanced Topics - Setting Up a Routing Daemon

From bering-uClibc
Revision as of 19:55, 11 July 2024 by Davidmbrooke (Talk | contribs) (→‎BIRD: - Added some section headings and a very brief summary of Concepts - plus some References)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Advanced Topics - Setting Up a Routing Daemon
Prev Bering-uClibc 7.x - User Guide Next

Introduction

Simple installations of Bering-uClibc generally operate with simple routing tables - they automatically know how to route traffic between all locally-connected networks and everything else gets sent via a single default route - typically to an Internet Service Provider (ISP). Slightly more complexity can be managed using manually-maintained 'static routes' or other mechanisms - for example choosing between multiple Internet connections - but where there are lots of routes to administer (and especially where these routes change as network links go up and down) a more automated solution is required.

Large-scale network installations typically rely on Routing Protocols such as Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF) as a means to automatically communicate routing information between routers.

In order to send or receive routing information using one or more of these standard routing protocols, some sort of Routing Daemon is required. Note the actual routing is still done by the Linux kernel; the role of the Routing Daemon is to populate the kernel's routing table with information about non-local networks.

Bering-uClibc 7.x offers two Routing Daemon options: Zebra (actually the Quagga codebase) and BIRD, which are described further below.


Zebra

This material copied directly from http://leaf.sourceforge.net/doc/bucu-zebra.html - needs to be checked/updated for Bering-uClibc 7.x!

Overview

Zebra is a routing daemon. That means, it will send routing requests and receive similar requests from neighbor routers, and eventually update your routing tables accordingly. Zebra provides TCP/IP based routing services with routing protocols support such as RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4, and BGP-4+.

In Bering-uClibc 7.x [and some earlier versions too - do we know which?] the Zebra packages actually implements the Quagga software codebase, which replaced the earlier GNU Zebra codebase.

RIP and OSPF are "internal" routing protocols, whereas BGP is an "external" routing protocol. Internal protocols are designed for use in LANs, within a global administrative scope. External protocols are designed for use in WAN, and BGP is specifically designed for Internet use. Zebra also supports special BGP Route Reflector and Route Server behavior. In addition to traditional IPv4 routing protocols, Zebra also supports IPv6 routing protocols.

There are five routing daemons in use, and there is one manager daemon. These daemons may be located on separate machines from the manager daemon.

The routing daemons are:

  • ripd, ripngd, ospfd, ospf6d, bgpd

The manager daemon is:

  • zebra

Configuring Zebra

Zebra's architecture includes an O/S dependant application, whose role is to deal with network interface configuration, routing table updates, and other kernel stuff ; and O/S independant routing processes, communicating thru sockets with the Zebra core. You will have to choose which daemons you want to run by loading and configuring the appropiate Packages.

If you want to activate the processes zebra and bgpd, edit bgpd.conf (note that lines beginning with ! are comments). No configuration is necessary in zebra.conf, but you should edit bgpd.conf to include the following lines : 

router bgp ASN
 bgp router-id ROUTERID
 network 192.168.A.B/M
 network 192.168.C.D/N
 neighbor 192.168.P.Q
 remote-as REMOTEASN

Where ASN is your Autonomous System Number (it will look like a number above 65000, and will be given when you ask for it to the tunnel's maintener), ROUTERID is a dummy IP address (it can be 5.4.3.2 if you like, it's just an identifier). You should specify your network entries with respect to your allocated IP addresses ranges. For instance, if you told the maintener that you would use 192.168.93.1 thru 192.168.93.127, specify 192.168.93.0/25 . You can specify multiple network routes. If you are part of the backbone (you will be told if that is the case), you should export a host route (192.168.0.X/32). The neighbor IP address and ASN will be given to you by your maintener.

After editing configuration files, do a backup and start zebra and bgpd (svi zebra start and svi bgpd start or reboot the router). The routes should appear within your kernel routing table (ip route).

You need to open the appropiate ports in shorewall (fw <-> loc for internal and fw <-> net for external routing protocols) to make the routing exchange possible.

Configuring Zebra with telnet

The individual daemons also provide a vty interface for Cisco like configuration. There are two ways of doing this: by telnetting to localhost (this method is not further described, because Bering-uClibc doesn't provide a telnet client due to securrity reasons) and by telnetting to the router with telnet from a client machine. Opening ports on the firewall is always a securitty risk, so only do this is you trust your localnet.

Open the zebra port and one of more of the daemon ports in shorewall (loc to net):

zebra 2601/tcp # zebra vty
ripd 2602/tcp # RIPd vty
ripngd 2603/tcp # RIPngd vty
ospfd 2604/tcp # OSPFd vty
bgpd 2605/tcp # BGPd vty
ospf6d 2606/tcp # OSPF6d vty

First configure the routing daemons as described in the previous section, additional you can set a password and a Hostname as described below:

Password: The password is like a standard user password, and think about the "enable password" like the "root password" of an UNIX box. If you don't put an "enable password", it won't be necessary (id est, empty password).

Hostname: You can also configure hostnames : If you use foo-zebra as hostname the router's name is "foo" for zebra process, and foo-bgpd for the bgpd process. The hostname only influences the command prompt when you connect to a router (with telnet firewall bgpd for instance).

After backup and starting of the different daemons, you can connect to them with: telnet <firewall> <port or name>

Check the BGP configuration: Connect to your BGP routing process : telnet firewall bgpd ; you will be prompted for a password. At the prompt, issue enable and give your enable password. Then, show ip bgp will show BGP routes ; show ip bgp summary will show neighbors state. The latter should look like this: 

firewall-bgpd# sh ip bg su Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/Pref 192.168.168.168 4  65168 14062 13971 0 0 0    1d23h59m 6 192.168.192.1 4 65301 6110 6250 0 0 0 2d00h01m 1 
firewall-bgpd#

Notice that you can abbreviate commands. If you see big variations between MsgRcvd and MsgSent, that may be a hint of network failures.

You have to backup the configuration with both "write" in the vty and a backup of the package on the Bering-uClibc firewall itself.

Links

http://www.zebra.org/

https://www.nongnu.org/quagga/

http://skaya.enix.org/vpn/zebra.html


BIRD

Introduction

BIRD Internet Routing Daemon (BIRD) does broadly the same thing as Zebra but it has a different software architecture from Zebra; there is a single daemon bird which can implement multiple routing protocols, based on the entries in a single configuration file /etc/bird/bird.conf This is installed using the bird.lrp Package.

Note that the configuration syntax changed significantly between BIRD 1.x and BIRD 2.x; it's the latter which is implemented in Bering-uClibc 7.x so be careful when using configuration examples from other websites that might use the older v1.x syntax. The official User's guide 2.0 is the best source for reliable 2.x configuration information.

The BIRD daemon is monitored and managed using the BIRD client. There are two variants of this available for Bering-uClibc 7.x:

  • birdc.lrp which provides the birdc (bird client) command
    • This is rather easier for new users and is recommended
  • birdcl.lrp which provides the birdcl (bird client - lightweight) command
    • This does not rely on the curses or readline libraries and so lacks command-line completion features but is otherwise fully functional; use if disk space or RAM is limited

Concepts

BIRD implements its own concept of Routing Tables, with the ability to control how Routes get copied between these 'BIRD' Routing Tables, the Kernel's Routing Tables and various Routing Protocols.

As standard, it uses a BIRD Routing Table called master4 for IPv4 routes and a corresponding one called master6 for IPv6 routes.

Then it understands several 'real' Routing Protocols such as BGP, OSPF and RIP.

Also, there are several 'pseudo' Routing Protocols such as Kernel, Direct and Static.

Most of the configuration required is to specify which sort of Routes should get Imported from each Protocol to the BIRD Routing Tables, and which should get Exported in the opposite direction.

References


Prev Up Next
Retrieved from "http://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_7.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_a_Routing_Daemon&oldid=5852"