Page History

...

5. Modify volumes/gateway/zebra.conf and volumes/gateway/bgpd.conf as you want. Here are samples of the config files. Note that fpm connection ip in zebra.conf should be the eth0 interface IP address of onos-vrouter container, assigned by Docker. Run Quagga container with those config files. The IP address comes with the command would be equals to router-id in bgpd.conf. Note that the MAC address passed together must be unique if you have multiple gateway nodes. 

! -*- bgp -*-
!
! BGPd sample configuration file
!
!
hostname gateway-01
password zebra
!
router bgp 65101
  bgp router-id 172.18.0.254
  timers bgp 3 9
  neighbor 172.18.0.1 remote-as 65100
  neighbor 172.18.0.1 ebgp-multihop
  neighbor 172.18.0.1 timers connect 5
  neighbor 172.18.0.1 advertisement-interval 5
  network 172.27.0.0/24
!
log file /var/log/quagga/bgpd.log

!
hostname gateway-01
password zebra
!
fpm connection ip 172.17.0.2 port 2620

$ ./quagga.sh --name=gateway-01 --ip=172.18.0.254/30 --mac=fe:00:00:00:00:01

If you check the result of ovs-vsctl show, there should be a new port named quagga on br-router bridge. 

6. If you have more gateways, you should differentiate router-id and MAC address of the gateway from others. Here's an example configuration for 2 gateways,

! -*- bgp -*-
!
! BGPd sample configuration file
!
!
hostname gateway-02
password zebra
!
router bgp 65101
  bgp router-id 172.18.0.250
  timers bgp 3 9
  neighbor 172.18.0.1 remote-as 65100
  neighbor 172.18.0.1 ebgp-multihop
  neighbor 172.18.0.1 timers connect 5
  neighbor 172.18.0.1 advertisement-interval 5
  network 172.27.0.0/24
!
log file /var/log/quagga/bgpd.log

!
hostname gateway-02
password zebra
!
fpm connection ip 172.17.0.2 port 2620

$ ./quagga.sh --name=gateway-02 --ip=172.18.0.250/30 --mac=fe:00:00:00:00:03

#routed port connected to gateway-01
interface Ethernet43
   no switchport
   ip address 172.18.0.253/30
#routed port connected to gateway-02
interface Ethernet44
   no switchport
   ip address 172.18.0.249/30
 

router bgp 65100
   timers bgp 3 9
   distance bgp 20 200 200
   maximum-paths 2 ecmp 2
   neighbor 172.18.0.254 remote-as 65101
   neighbor 172.18.0.254 maximum-routes 12000
   neighbor 172.18.0.250 remote-as 65101
   neighbor $ ./quagga.sh --name=gateway-01 --ip=172.18.0.254/24250 --mac=fe:00:00:00:00:01

If you check the result of ovs-vsctl show, there should be a new port named quagga on br-router bridge. 

maximum-routes 12000
   ............

76. If there's no external router or emulation of it in your setup, add another Quagga container which acts as an external router. First, modify volumes/router/zebra.conf and volumes/router/bgpd.conf to make this Quagga an external router neighboring with the one created right before, and use the same command above but with additional argument --external-router option to bring up the router container. You can put any MAC address this time.

...

$ ./quagga.sh --name=router-01 --ip=172.18.0.1/2430 --mac=fa:00:00:00:00:01 --external-router

If you check the result of ovs-vsctl show, there should be a new port named quagga-router on br-router bridge. 

78. Once all the containers are up and running, check ports result from the ONOS-vRouter. If any port number does not match to the ones in vrouter.json, modify the config file with the correct port numbers, and just re-run the vrouter.sh. It actually happens often since you may re-create Quagga containers multiple times to fix the Quagga config files or for some other reasons, and OVS increases port number whenever a new port is added to a bridge. 

...

sona-setup$ vrouter.sh

89. If everything's right, check fpm-connections, hosts and routes. 172.18.0.1 is the external default gateway in this example. If you added interface and host for floating IP range, you should be able to see the host in the list.

onos> hosts
id=FA:00:00:00:00:01/None, mac=FA:00:00:00:00:01, location=of:00000000000000b1/25, vlan=None, ip(s)=[172.18.0.1]
id=FE:00:00:00:00:01/None, mac=FE:00:00:00:00:01, location=of:00000000000000b1/24, vlan=None, ip(s)=[172.18.0.254]
id=FE:00:00:00:00:02/None, mac=FE:00:00:00:00:02, location=of:00000000000000b1/1, vlan=None, ip(s)=[172.27.0.1], name=FE:00:00:00:00:02/None

onos> fpm-connections
172.17.0.2:52332 connected since 6m ago

onos> next-hops
ip=172.18.0.1, mac=FA:00:00:00:00:01, numRoutes=1

onos> routes
Table: ipv4
   Network            Next Hop
   0.0.0.0/0          172.18.0.1
   Total: 1

Table: ipv6
   Network            Next Hop
   Total: 0

910. Add route for floating IP range manually and check the route is added.

onos> route-add 172.27.0.0/24 172.27.0.1
onos> routes
Table: ipv4
   Network            Next Hop
   0.0.0.0/0          172.18.0.1
   172.27.0.0/24      172.27.0.1
   Total: 2

Table: ipv6
   Network            Next Hop
   Total: 0

onos> next-hops
ip=172.18.0.1, mac=FA:00:00:00:00:01, numRoutes=1
ip=172.27.0.1, mac=FE:00:00:00:00:02, numRoutes=1

1011. Now you should be able to see the gateway node is in COMPLETE state when you re-trigger node initialization. You can either run command openstack-node-init gateway-01 or push the network configuration file again.

...