13
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.

BGP as a Service (BGPaaS) Feature in Contrail Cloud 3 as a Service (BGPaaS) Feature in Contrail Cloud 3.0 ... Juniper has provided a new feature to use BGP as a service in Contrail

Embed Size (px)

Citation preview

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