bgp as a service (bgpaas) feature in contrail cloud 3 as a service (bgpaas) feature in contrail...
TRANSCRIPT
BGP as a Service (BGPaaS) Feature in Contrail Cloud 3.0
BGPaaS Overview:
Juniper has provided a new feature to use BGP as a service in Contrail Cloud 3.0 as referred on Juniper-
Techpubs-BGPaaS:
https://www.juniper.net/techpubs/en_US/contrail3.0/topics/concept/bgp-as-a-service-overview.html
With this feature if a VNF VM have a capability to support BGP then it can do BGP peering with vRouter-
agent/controller and can advertise routes into the VRF instance.
When BGPaaS is configured in contrail, the vRouter-agent listens for the TCP/179 onto the virtual network
default-gateway and virtual DNS addresses. These are configured as eBGP sessions. The vRouter-agent
then proxy the TCP connection to the control node on behalf of the tenant VM. The BGP peers will be
established and can exchange routes with each other. All routes advertised from contrail to VNF will have
next-hop set to default-gateway IP address.
Our Lab Topology for Deploying BGPaaS:
The following snapshot describes our lab-environment topology for contrail cloud 3.0 as well as the BGP
peering when BGPaaS will configured:
We will see how to configure the BGPaaS service in contrail and deploy BGP sessions in VNF (here we will
use JunOS router) and see how the advertised routes will be reflected into the contrail controller routing
instance table.
First we will configure BGPaaS with virtual machine’s VMI-address. Whereas on tenant’s VM, BGP will be
configured with default-gateway address and see the BGP sessions and flows on both tenant and
compute. We will advertise the loopback addresses both IPv4 & IPv6 from VM into the BGP and see these
routes will be available in control nodes VRF table. Secondly we will configure BGP with vDNS address and
see the flow sessions. Finally we will configure the BGPaaS with the loopback address of tenant VM rather
than its VMI-address and see the behavior of BGP sessions. In the end we will provide some
cautions/recommendations to configure BGPaaS for it to work properly.
Tenant Network Creation:
For our analysis we have created a virtual network and launched a VM to test BGPaaS as shown below:
Virtual Network “VN_TEST”
o CIDR: 192.168.100.0/24
o Default-Gateway: 192.168.100.1
o vDNS IP address: 192.168.100.2
Virtual Machine “VM_BGPaaS”
o VMI-IP-address: 192.168.100.51/32
o Lo0 IP-address: 10.10.100.100/32
o Lo0 IPv6-address: 2001::10:10:100:100/128
The VM is created and is up & running.
Configuring BGPaaS:
To configure the BGPaaS, in ‘Configure’ tab, go to the ‘Services’ and select ‘BGP as a Service’ and hit the
‘+’ sign to create a new service as shown below:
Enter the name for this service object, the AS number for VNF, select address families that need to be
transported and the VMI, here it will be as shown in below snapshot:
As the service is created, the vRouter-agent started listening TCP 179 on both default-gateway & vDNS
addresses. To complete the BGP peering process, create BGP configurations in VM. Here in our
environment we are using JunOS so following minimal configs are made in the VM:
interfaces {
lo0 {
unit 0 {
family inet {
address 10.10.100.100/32;
}
family inet6 {
address 2001::10:10:100:100/128;
}
}
}
}
routing-options {
router-id 10.10.100.100;
autonomous-system 65000;
}
policy-options {
policy-statement export-to-bgp {
term allow_local {
from protocol [ direct local ];
then {
next-hop 192.168.100.51;
accept;
}
}
term deny_all {
then reject;
}
}
}
protocols {
bgp {
group BGPaaS-VN_TEST {
type external;
multihop;
local-address 192.168.100.51;
family inet {
unicast;
}
family inet6 {
unicast;
}
export export-to-bgp;
peer-as 64512;
multipath;
neighbor 192.168.100.1;
}
}
}
This will create BGP session between the VM and the vRouter-agent and advertise routes.
Verification of configured BGPaaS:
To verify the service, we can see the BGPaaS is configured successfully in introspect as:
In control node, the BGP neighbor list report also shows the peering session with VM instance:
We can find the flow for this peering session with virtual network default-gateway in compute node as:
root@cs4:~# flow --match 192.168.100.51
Flow table(size 80609280, entries 629760)
Entries: Created 252573 Added 252599 Processed 252573 Used Overflow entries 0
(Created Flows/CPU: 18466 19884 20185 19866 19525 19816 19625 19504 19505 18907 18781 19266 945 861 860
934 976 960 944 868 916 934 914 761 513 472 676 563 746 680 766 573 728 511 652 1347 10 13 8 29 4 6 4 3 14 3
9 40)(oflows 0)
Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)
Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop
Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked
TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead
Listing flows matching ([192.168.100.51]:*)
Index Source:Port/Destination:Port Proto(V)
-----------------------------------------------------------------------------------
147344<=>492980 192.168.100.51:55143 6 (1->0)
192.168.100.1:179
(Gen: 26, K(nh):31, Action:N(SPsDL), Flags:, TCP:SSrEEr, S(nh):31, Stats:20/1558, SPort 62035)
root@cs4:~#
As vrtouer-agent proxy this peering session to the controller, so we can see the flow as shown below:
root@cs4:~# flow --match 10.0.0.4
Flow table(size 80609280, entries 629760)
Entries: Created 252573 Added 252599 Processed 252573 Used Overflow entries 0
(Created Flows/CPU: 18466 19884 20185 19866 19525 19816 19625 19504 19505 18907 18781 19266 945 861 860
934 976 960 944 868 916 934 914 761 513 472 676 563 746 680 766 573 728 511 652 1347 10 13 8 29 4 6 4 3 14 3
9 40)(oflows 0)
Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)
Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop
Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked
TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead
Listing flows matching ([10.0.0.4]:*)
Index Source:Port/Destination:Port Proto(V)
-----------------------------------------------------------------------------------
492980<=>147344 10.0.0.1:179 6 (0->1)
10.0.0.4:50000
(Gen: 19, K(nh):5, Action:N(SDPdL), Flags:, TCP:SSrEEr, S(nh):12, Stats:42/2263, SPort 54056)
root@cs4:~#
In VM, we can also verify the BGP session as:
sdn-e@JunOS-VM> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
inet6.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.100.1 64512 5 8 0 0 1:38 Establ
inet.0: 0/0/0/0
inet6.0: 0/0/0/0
sdn-e@JunOS-VM>
Advertised routes in VRF instance:
As we can see in VM configuration we configured loopback0 for inet and inet6. These prefixes are
advertised in BGP as shown below:
sdn-e@JunOS-VM> show route advertising-protocol bgp 192.168.100.1
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.100.100/32 192.168.100.51 I
* 192.168.100.0/24 192.168.100.51 I
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
2001::10:10:100:100/128
* 192.168.100.51 I
sdn-e@JunOS-VM>
These prefixes are shown in the VRF table of the control node as shown in below snapshot:
vDNS BGP session:
For high availability, a second BGP session can be configured with vDNS IP address for that particular
virtual network as vRouter-agent listens for port 179 onto both default-gateway and vDNS IP addresses.
So we only need to create session in the VM:
[edit]
sdn-e@JunOS-VM# set protocols bgp group BGPaaS-VN_TEST neighbor 192.168.100.2
[edit]
sdn-e@JunOS-VM# commit and-quit
commit complete
Exiting configuration mode
sdn-e@JunOS-VM> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
inet6.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.100.1 64512 46 54 0 0 22:20 Establ
inet.0: 0/0/0/0
inet6.0: 0/0/0/0
192.168.100.2 64512 2 4 0 0 14 Establ
inet.0: 0/0/0/0
inet6.0: 0/0/0/0
sdn-e@JunOS-VM>
We can see the flow session in compute node as follows:
root@cs4:~# flow --match 192.168.100.51
Flow table(size 80609280, entries 629760)
Entries: Created 252592 Added 252618 Processed 252592 Used Overflow entries 0
(Created Flows/CPU: 18466 19884 20185 19866 19525 19816 19625 19504 19505 18907 18781 19266 945 861 860
934 977 960 944 868 916 934 914 761 513 472 676 563 746 680 766 573 728 511 669 1347 10 13 8 29 4 6 4 3 14 3
9 41)(oflows 0)
Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)
Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop
Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked
TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead
Listing flows matching ([192.168.100.51]:*)
Index Source:Port/Destination:Port Proto(V)
-----------------------------------------------------------------------------------
147344<=>492980 192.168.100.51:55143 6 (1->0)
192.168.100.1:179
(Gen: 26, K(nh):31, Action:N(SPsDL), Flags:, TCP:SSrEEr, S(nh):31, Stats:105/7003, SPort 62035)
466736<=>85472 192.168.100.51:55010 6 (1->0)
192.168.100.2:179
(Gen: 11, K(nh):31, Action:N(SPsDL), Flags:, TCP:SSrEEr, S(nh):31, Stats:9/909, SPort 58383)
root@cs4:~#
BGP peering with loopback address:
Contrail cloud 3.0.2 has enhanced the BGPaaS feature by adding the facility for BGP peering with loopback
address of the VM instance. To do this, edit the BGPaaS object and in ‘Advanced Options’ enter the
loopback IP of the VM:
Here in this case it is 10.10.100.100.
In addition to this we need to add a static route in network route table of vRouter for the VM instance’s
loopback address. To do so, go to ‘Networking’ and select ‘Routing’; then select ‘+’ to create a static route
table as shown below:
Now go the Networks and edit the virtual network ‘VN_TEST’. In ‘Advanced Options’ select the created
network table under ‘Static Routes’ option.
This will add this route to the network table of this virtual network.
Now we need to change the BGP configs on VM instance also as follow:
[edit]
sdn-e@JunOS-VM# set protocols bgp group BGPaaS-VN_TEST local-address 10.10.100.100
[edit]
sdn-e@JunOS-VM# commit and-quit
commit complete
Exiting configuration mode
sdn-e@JunOS-VM> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
inet6.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.100.1 64512 2 5 0 0 6 Establ
inet.0: 0/0/0/0
inet6.0: 0/0/0/0
192.168.100.2 64512 2 4 0 0 5 Establ
inet.0: 0/0/0/0
inet6.0: 0/0/0/0
sdn-e@JunOS-VM>
As now the BGP session is created with the loopback IP address so we can see the flow session for this
BGP peering onto compute node as follows:
root@cs4:~# flow --match 10.10.100.100
Flow table(size 80609280, entries 629760)
Entries: Created 252689 Added 252715 Processed 252689 Used Overflow entries 0
(Created Flows/CPU: 18468 19888 20187 19876 19528 19817 19632 19504 19507 18909 18783 19272 945 862 860
940 978 962 949 869 916 936 916 762 513 472 676 563 746 680 766 573 728 511 678 1373 10 13 8 29 4 6 4 3 14 3
9 41)(oflows 0)
Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)
Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop
Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked
TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead
Listing flows matching ([10.10.100.100]:*)
Index Source:Port/Destination:Port Proto(V)
-----------------------------------------------------------------------------------
89808<=>492980 10.10.100.100:54501 6 (1->0)
192.168.100.1:179
(Gen: 12, K(nh):31, Action:N(SPsDL), Flags:, TCP:SSrEEr, S(nh):31, Stats:21/1834, SPort 50140)
264832<=>85472 10.10.100.100:54899 6 (1->0)
192.168.100.2:179
(Gen: 15, K(nh):31, Action:N(SPsDL), Flags:, TCP:SSrEEr, S(nh):31, Stats:21/1815, SPort 61715)
root@cs4:~#
This is worth to note that this BGPaaS object on vRouter-agent is same as it was configured for VMI
address previously. Only the peer-ip is changed. This can be verified from the below introspect snapshot:
Caution Notes:
i. EBGP-Multihop must be enabled on tenant VM
ii. Static route must be configured and associated with virtual network if BGP peering is
configured through non-VMI address (loopback address)
iii. Its recommended to configure both peering sessions each with default-gateway as well as
vDNS IP address
iv. For routes to be advertised in tenant VM, protocol next-hop should be set to VIF address of
the VM assigned by vRouter