In the previous post, we discussed how to deploy vSRX on Openstack. Since I’m using Contrail as my SDN for this setup, this one will be about setting up BGP as a Service (BGPaaS) between Contrail, vSRX, and Quagga.
The scenario I’m trying to demonstrate is the following:
- vSRX to advertise the pool 90.90.90.0/29
- Quagga to advertise the pool 80.80.80.0/29
- Both pools should exchanged between the nodes and Contrail using BGPaaS.
Contrail Configuration:
vSRX and Quagga VMs are attached to ports on ZoneA_MGMT Virtual Network (172.90.90.0/24), as follows
- Virtual Network Gateway: 172.90.90.1 [AS64512]
- vSRX: 172.90.90.10 [AS35500]
- Quagga: 172.90.90.20 [AS42750]
We will setup two BGP as a Service objects in Contrail under Configure > Services > BGP as a Service, like this:
vSRX:
Quagga:
vSRX Configuration:
What we are trying to achieve on vSRX is :
- Establish BGP Peering between vSRX and Contrail
- Advertise 90.90.90.0/29 from vSRX and Receive it on Contrail
For Establishing BGP Peering, set the following commands:
set protocols bgp group bgpaas type external set protocols bgp group bgpaas neighbor 172.90.90.1 peer-as 64512 set routing-options autonomous-system 35500
You can check your Contrail Global ASN under Configure > Infrastructure > Global Config > System (using release 5.1, other releases may slightly differ)
Let’s verify that BGP peering between Contrail and vSRX is established. On vSRX:
contrail@vSRX_ZoneA> show bgp neighbor 172.90.90.1 Peer: 172.90.90.1+179 AS 64512 Local: 172.90.90.10+51520 AS 35500 Group: bgpaas Routing-Instance: master Forwarding routing-instance: master Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ export-direct ] Options: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.0.51 Local ID: 172.90.90.10 Active Holdtime: 90
Peer, in the above output, represents the virtual network gateway IP which we are peering with. Peer ID is the IP address of the Contrail Controller the peering has been proxied to, which is Contrail-Controller-2 here.
In Contrail, I’ll be using the introspect module (Settings > Introspect > Control Nodes) with the following parameters to verify that peering is established:
Great. To start advertising the network pool: append the following lines to your vSRX Config:
set policy-options policy-statement export-direct from protocol static set policy-options policy-statement export-direct from route-filter 90.90.90.0/29 orlonger set policy-options policy-statement export-direct then accept set protocols bgp group bgpaas export export-direct set routing-options static route 90.90.90.0/29 next-hop 172.90.90.20
Confirm the route is advertised from vSRX:
contrail@vSRX_ZoneA> show route advertising-protocol bgp 172.90.90.1 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 90.90.90.0/29 172.90.90.20 I
We will verify route is received and propagated from the other vRouter Node under Contrail (Monitor > Infrastructure > Virtual Routers > Virtual Router 01 > Routes):
Quagga Configuration:
Quagga is is a Software Routing Suite that offers a range of routing protocols capabilities to Linux. What we are interested to do here is to see how Quagga configuration works with Contrail BGPaaS. I’ll leave the part of installing quagga up to you depending on your setup (if your VMs have internet access, or if you need to build a custom image, etc).
What we are trying to achieve on Quagga in this part is :
- Establish BGP Peering between Quagga and Contrail
- Advertise 80.80.80.0/29 from Quagga and Receive them on Contrail
Quagga consists of 2 configuration files, zebra.conf and bgpd.conf, the latter is holding our main configuration for BGP. Create these two files and restart both zebra and bgpd services.
/etc/quagga/zebra.conf:
! ! Zebra configuration saved from vty ! 2019/04/17 09:11:33 ! hostname BGP-VM ! interface eth0 ipv6 nd suppress-ra ! interface lo ! ! ! line vty ! ! ! Zerba Config File hostname Quagga-ZoneA interface eth0 ipv6 nd suppress-ra interface lo line vty
/etc/quagga/bgpd.conf:
! -*- bgp -*- ! ! BGPd configuratin file ! hostname Quagga-ZoneA password zebra ! !bgp mulitple-instance ! router bgp 42750 bgp router-id 172.90.90.20 network 80.80.80.0/29 neighbor 172.90.90.1 remote-as 64512 ! ! access-list all permit any ! ! !log file bgpd.log ! log stdout
Restart the services:
systemctl restart zebra systemctl restart bgpd
Check BGP Neighborship establishment
[root@quaggazonea quagga]# vtysh -c "show bgp neighbors" | head -n 3 BGP neighbor is 172.90.90.1, remote AS 64512, local AS 42750, external link BGP version 4, remote router ID 192.168.0.50 BGP state = Established, up for 00:08:30
Note in the above output the difference between BGP Neighbor IP and Remote Router ID. Again, BGP Neighbor IP resembles the gateway of the virtual network we used to peer with the Quagga. Remote ID is the IP address of the Contrail Controller the peering has been proxied to. Quagga is peering with Contrail-Controller-1, which is a different controller than the one vSRX has peered with. The reason is that Quagga and vSRX are hosted on two different compute nodes, and each compute nodes connects to two Contrail Controllers via XMPP at any given time, so in an HA setup with 3x Controllers, it is totally normal to see your BGPaaS objects peering with different controllers.
Since Contrail is proxying all routes it is receiving and reflecting them to its neighbors, this will automatically mean that routes received from both vSRX and Quagga will be also propagated back to them.
Confirm vSRX and Quagga are receiving each other’s routes:
contrail@vSRX_ZoneA> show route receive-protocol bgp 172.90.90.1 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 80.80.80.0/29 172.90.90.1 64512 42750 I 172.90.90.10/32 172.90.90.1 100 64512 ? * 172.90.90.20/32 172.90.90.1 100 64512 ? * 172.90.90.30/32 172.90.90.1 100 64512 ?
[root@quaggazonea ~]# vtysh -c "show ip bgp"
BGP table version is 0, local router ID is 172.90.90.20
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 80.80.80.0/29 0.0.0.0 0 32768 i
*> 90.90.90.0/29 172.90.90.1 0 64512 35500 i
*> 172.90.90.10/32 172.90.90.1 100 0 64512 ?
*> 172.90.90.20/32 172.90.90.1 100 0 64512 ?
*> 172.90.90.30/32 172.90.90.1 100 0 64512 ?
Total number of prefixes 5
As you can see, the AS Path shows both Contrail and Quagga/vSRX AS Numbers depending on the route and the node executing the command. Please note that the first output is displaying only the received bgp routes from Contrail on vSRX, hence why 90.90.90.0/29 is not visible.
BGPaaS is much more extensible than this, with more ISP grade features. Read more here.
