Configuring Quagga BGP & Connecting to ONOS

Quagga comes with a rich (Cisco-like) CLI. However, it is not enough to simply configure Quagga BGP. We also need to configure Zebra, as well as the Linux-host on which Quagga runs. In addition, we need to hook up Quagga to ONOS in the control plane. This hookup happens on two different fronts: 1) where BGP communication from the data-plane hardware switch is delivered to ONOS, which in-turn delivers those packets to Quagga (and the reverse communication); and 2) where the ONOS lightweight BGP implementation peers with Quagga BGP using iBGP.

Sounds complicated! But part of Project Atrium's goal is to make life easier for the end user. And so, we have created a script that users can modify in a couple of places and launch with one command that would take care of all the pieces above. If interested in understanding the underlying plumbing, user should refer to the System Architecture.

The script resides at the top level of the directory structure in the distribution VM: router-deploy.py

Here is what it looks like:

Figure 1

The highlighted boxes in the script above show what user needs to change for the network:

1. The Atrium Router speaks BGP, so it must have an AS number. Set the AS number in the first box.
   
2. The second box is where user configures the same interface addresses (mac/vlan/ip) for the Atrium Router as was done when configuring ONOS. Note that there is no need to configure "port" information here. Also note that if user had configured the same mac address for all ports (eg. the RouterMAC case for Pica8 switches), the same would need to be done here.
3. The third box is where user configures the peer's (also called neighbor) IP address and AS number. Do not change the last line in this box: it refers to the ONOS iBGP peer.

User may have noticed that step#2 could be done using Linux commands, and steps 1 and 3 can be done using the Quagga CLI. User may also have noticed that we did not give the ability to advertise routes (also known as 'networks' in BGP terminology). This is a known issue with the Atrium router implementation, an issue which will be addressed in the next release. For this release, the Atrium router can only be used in transit, ie. it can receive and readvertise routes, but it cannot originate route advertisements itself.

Launching Quagga

Similar to what was shown in the "Launching ONOS" section, quagga can be launched simply by running the command in bash (over ssh) if it is just to be run for testing. For deployment, it is better to use tmux and launch quagga in a separate tmux window/pane.

In this example, a new "pane" to launch Quagga was created in the same tmux "window" where ONOS was launched.

In bash, listing the current tmux session should show what was created for launching ONOS.

$ tmux ls 

0: 1 windows (created Thu Jun 25 17:39:27 2015) [109x36]

Attach to the session:

$ tmux at -t 0

That should bring up the window where ONOS was launched.

Enter the keys Ctrl-b followed by " (double quotation mark). This command will split the window vertically into two panes.

In the lower pane, start the script user just edited in the background.

 $ sudo ./router-deploy.py &

 As a checkpoint, user should see the following responses when checking the following commands.

Figure 2

 Here, "bgp1" represents the linux-host (container) that runs Quagga. User can enter this host with:

$ ./mininet/util/m bgp1

Then, user can telnet into the Quagga BGP process with:

$ telnet localhost 2605

password: sdnip

Now user is in the Quagga CLI. To see the status of BGP peering, enter:

> show ip bgp summary

 Figure 3

The screenshot above shows that the iBGP peering session between ONOS (1.1.1.1) and Quagga is up. The screenshot also shows that the BGP peering session with the neighbors (peers) is not up. This display is due to the fact that the dataplane switch and controller have not been connected.

User is now ready to connect a switch of choice to the controller.