In this post, we will look into the Inter-AS MPLS VPN - Option C which is also known as "BGP + Label".
Option C uses eBGP IPv4 session between ASBRs to exchange reachability to PE loopbacks. There will be a VPNv4 neighbourship between service providers VPNv4 route-reflectors (RRs).
Option C takes away the heavy reliance on ASBRs. In this case, ASBRs are only used to exchange the loopback prefixes using eBGP IPv4 sessions.
To understand how it works, let's look at our topology below.
We have two service providers. Both are connected through ASBR routers. In this specific instance, we have local VPNv4 route-reflector for each SP. The customer site CE1 is connected to SP1 and CE2 is connected to SP2.
SP1-PE1 and SP1-ASBR are RR client of SP1-RR.
Similarly SP2-PE1 and SP2-ASBR are RR client of SP2-RR.
The SP1-ASBR learns the CE1 loopback prefix 1.1.1.1/32 from SP1-RR.
Similarly SP2-ASBR learns the CE2 loopback prefix 10.10.10.10/32 from SP2-RR.
Our aim to establish VPNv4 neighbourship between router reflectors of the both service provider RRs so they can exchange routing information.
To do this, first of all we have to exchange the loopback IPs of SP1-RR and SP2-RR through ASBRs.
For this we will configure standard IPv4 BGP neighbourship between ASBRs.
We also have to make sure that we send labels for the prefixes through the BGP neighbourship.
Remember we are using BGP to exchange the MPLS labels here and not LDP!
Now we will redistribute the loopback IP of route reflector from IGP to BGP. We will use route-maps and prefix-lists to do it in a controlled manner.
On SP1-ASBR,
On SP2-ASBR,
After this, both the ASBRs have started learning relevant prefixes through BGP.
As we are redistributing these prefixes into local IGP, the RRs should start learning them via IGP.
Now, let's configure the VPNv4 neighbourship between the RRs.
Once the neighbourship is up, we can see that the RR's have started learning the customer prefixes.
The RR's are passing this update to SP1-PE1 and SP2-PE1.
CE1 and CE2 are learning the prefixes from their EBGP session between the relevant PE routers.
The ping test suggests that we have full connectivity.
The traceroute confirms that there is an end to end LSP.
All good? not really. If we check the traceroute carefully we can see that the traffic actually traverse through SP1-RR (10.1.78.8) and then go the SP2-PE1. This is not an optimum path. The RR should not be in the data plane so how do we fix this?
The reason traffic goes through the RR is because when RRs exchange VPNv4 prefixes, they update the next-hop IP and set it to their local loopback.
As per the output above, the next-hop for the prefix 10.10.10.10 is set to 8.8.8.8 hence the traffic is forwarded to SP2-RR.
There is a way we can change this behaviour. This can be done by applying the "next-hop-unchanged" command under vpnv4 address-family.
The next-hop for the prefix 10.10.10.10/32 is now changed to 9.9.9.9 (SP2-PE1).
However this route cannot be used as the next-hop is unreachable!! This router doesn't learn 9.9.9.9 through IGP.
In this case we will have to advertise this prefix through ASBRs. Similarly we will also have to advertise 2.2.2.2 (SP1-PE1) prefix.
We will update the prefix lists on ASBRs to perform this change.
After this change, we can see that SP1-RR has considered it as the best path.
Now If we do the traceroute from CE1
We can see that route reflector is not in the traffic path.
If we analyse the traceroute, we can see that SP1-PE is using the VPN label assigned by SP2-PE. The transport label also points to the loopback (9.9.9.9) of SP2-PE.
As we can see this implementation is not very straight forward. Service providers have to share the information of their internal networks to set this up hence it's not very popular in real world.
More information on this can be found on
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ias_and_csc/configuration/xe-3s/asr1000/mp-ias-and-csc-xe-3s-asr1000-book/mp-vpn-connect-ipv4.html
Option C uses eBGP IPv4 session between ASBRs to exchange reachability to PE loopbacks. There will be a VPNv4 neighbourship between service providers VPNv4 route-reflectors (RRs).
Option C takes away the heavy reliance on ASBRs. In this case, ASBRs are only used to exchange the loopback prefixes using eBGP IPv4 sessions.
To understand how it works, let's look at our topology below.
We have two service providers. Both are connected through ASBR routers. In this specific instance, we have local VPNv4 route-reflector for each SP. The customer site CE1 is connected to SP1 and CE2 is connected to SP2.
SP1-PE1 and SP1-ASBR are RR client of SP1-RR.
Similarly SP2-PE1 and SP2-ASBR are RR client of SP2-RR.
The SP1-ASBR learns the CE1 loopback prefix 1.1.1.1/32 from SP1-RR.
Similarly SP2-ASBR learns the CE2 loopback prefix 10.10.10.10/32 from SP2-RR.
Our aim to establish VPNv4 neighbourship between router reflectors of the both service provider RRs so they can exchange routing information.
To do this, first of all we have to exchange the loopback IPs of SP1-RR and SP2-RR through ASBRs.
For this we will configure standard IPv4 BGP neighbourship between ASBRs.
We also have to make sure that we send labels for the prefixes through the BGP neighbourship.
Remember we are using BGP to exchange the MPLS labels here and not LDP!
Now we will redistribute the loopback IP of route reflector from IGP to BGP. We will use route-maps and prefix-lists to do it in a controlled manner.
On SP1-ASBR,
On SP2-ASBR,
After this, both the ASBRs have started learning relevant prefixes through BGP.
Now, let's configure the VPNv4 neighbourship between the RRs.
The RR's are passing this update to SP1-PE1 and SP2-PE1.
CE1 and CE2 are learning the prefixes from their EBGP session between the relevant PE routers.
The ping test suggests that we have full connectivity.
The traceroute confirms that there is an end to end LSP.
All good? not really. If we check the traceroute carefully we can see that the traffic actually traverse through SP1-RR (10.1.78.8) and then go the SP2-PE1. This is not an optimum path. The RR should not be in the data plane so how do we fix this?
The reason traffic goes through the RR is because when RRs exchange VPNv4 prefixes, they update the next-hop IP and set it to their local loopback.
As per the output above, the next-hop for the prefix 10.10.10.10 is set to 8.8.8.8 hence the traffic is forwarded to SP2-RR.
There is a way we can change this behaviour. This can be done by applying the "next-hop-unchanged" command under vpnv4 address-family.
The next-hop for the prefix 10.10.10.10/32 is now changed to 9.9.9.9 (SP2-PE1).
However this route cannot be used as the next-hop is unreachable!! This router doesn't learn 9.9.9.9 through IGP.
In this case we will have to advertise this prefix through ASBRs. Similarly we will also have to advertise 2.2.2.2 (SP1-PE1) prefix.
We will update the prefix lists on ASBRs to perform this change.
After this change, we can see that SP1-RR has considered it as the best path.
Now If we do the traceroute from CE1
We can see that route reflector is not in the traffic path.
If we analyse the traceroute, we can see that SP1-PE is using the VPN label assigned by SP2-PE. The transport label also points to the loopback (9.9.9.9) of SP2-PE.
As we can see this implementation is not very straight forward. Service providers have to share the information of their internal networks to set this up hence it's not very popular in real world.
More information on this can be found on
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ias_and_csc/configuration/xe-3s/asr1000/mp-ias-and-csc-xe-3s-asr1000-book/mp-vpn-connect-ipv4.html
No comments:
Post a Comment