So far we have seen the Inter-AS MPLS VPN using "back to back VRF" method. Even though it's a relatively easy method to implement, it has few drawbacks.
This procedure doesn't require MPLS enabled on the link between ASBRs however it does not scale very well.
There is another method in which ASBR's establish VPNv4 neighbourship, exchange MPLS labels and can maintain end-to-end LSP. It is know as "Option B".
Let's see how it works. We are going to use the same topology as we used in last post.
The IP addressing and the core routing remains the same. The only difference is the configuration on ASBR where I have removed the EBGP neighbourship statement and removed the local VRF configuration.
Now the first step is to configure VPNv4 neighbourship between ASBRs.
We will now use BGP to forward MPLS label between ASBR. The way to achieve this is by configuring "mpls bgp forwarding" command under the interfaces.
If we check the prefix received on ASBR, we can see that we are not receiving anything either from CE1 or ASBR2 !!!
Why did we stop receiving the prefix 1.1.1.1/32 from CE1?
The reason is that we removed the local VRF configuration. This is the default behaviour where if you don't have the VRF configured with appropriate RT values locally on the router then the relevant VPNv4 routes will be dropped.
To overcome this issue, we will configure the command "no bgp default route-target filter" under the BGP process.
We can now see that we have received the prefixes from our own AS and also from ASBR.
Now let's check if these VPNv4 prefixes are advertised to the SP1-PE1 and SP2-PE2 or not.
So the PEs only shows the routes learned from connected CE routers! So what could be the problem?
Remember that the route-target value configured for both the VRFs are different.
We have to import/export the value on at least one PE routers. I will import/export RT 100:100 on SP2-PE1.
As a result of this, we can now see that both the PEs have started learning both the prefixes.
We can see that even though the prefixes have been learned by PEs, they don't appear as "best" routes.
The above output shows the reason behind it.
The ASBRs advertise the routes to PE routers, they do not change the next-hop-value hence the route learned by SP1-PE1 shows next-hop as 10.1.45.5 and the route learned by SP2-PE shows next-hop as 10.1.45.4.
The link between ASBRs (10.1.45.0/24) is not advertised into any IGP so PE router's mark the next=hop as inaccessible.
One way to resolve this issue is by advertising the subnet of this link (10.1.45.0/24) into IGP of both service provider networks.
The other way to do this is by setting next-hop-self on ASBR toward the PE router. We will use this method here.
Now we can see that the routes are marked as "best".
So let's check the routing table of CE1 and CE2.
A quick ping test confirms that the connectivity between loopbacks is working.
The traceroute shows that there is an end-to-end LSP between SP1-PE1 and SP2-PE2.
The thing to remember here is that the uses three different LSPs to reach at the destination.
The "LSP1" is between SP1-PE1 and SP1-ASBR. If we look at the output from SP1-PE1, it shows the VPN label assigned for VRF is "20".
The transport label to reach SP1-ASBR is "17"
This clarifies the first couple of hops of our traceroute output
The packet now hits SP1-P and it remove the transport lable "17" under the PHP process and ends up with a single label "20".
Packet is then forwarded to SP1-ASBR where the LSP 1 ends.
The "LSP2" is between SP1-ASBR and SP2-ASBR.
On SP1-ASBR the label "20" is swapped with "23" and the packet is passed onto SP2-ASBR.
Step 4 of the traceroute confirm this.
This is where "LSP2" ends and "LSP3" begins.
The "LSP3" is between SP2-ASBR and SP2-PE1.
As per the output from SP2-PE1, the VPN label assigned for VRF "RED" is "20" hence SP2-ASBR swaps the label "23" with "20" and uses transport label "16" to reach SP2-PE1.
When the packet hits SP2-P, it removes the transport label "16" under the PHP process and forward the packet to SP2-PE1. The PE router then removes the VPN label and pass IPv4 packet to CE2.
If we would have redistributed the link between ASBRs (10.1.45.0/24) in the IGPs then we would have ended up with 2 LSPs.
More information on this can be found here
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-asbr.html
This procedure doesn't require MPLS enabled on the link between ASBRs however it does not scale very well.
There is another method in which ASBR's establish VPNv4 neighbourship, exchange MPLS labels and can maintain end-to-end LSP. It is know as "Option B".
Let's see how it works. We are going to use the same topology as we used in last post.
The IP addressing and the core routing remains the same. The only difference is the configuration on ASBR where I have removed the EBGP neighbourship statement and removed the local VRF configuration.
Now the first step is to configure VPNv4 neighbourship between ASBRs.
We will now use BGP to forward MPLS label between ASBR. The way to achieve this is by configuring "mpls bgp forwarding" command under the interfaces.
If we check the prefix received on ASBR, we can see that we are not receiving anything either from CE1 or ASBR2 !!!
Why did we stop receiving the prefix 1.1.1.1/32 from CE1?
The reason is that we removed the local VRF configuration. This is the default behaviour where if you don't have the VRF configured with appropriate RT values locally on the router then the relevant VPNv4 routes will be dropped.
To overcome this issue, we will configure the command "no bgp default route-target filter" under the BGP process.
We can now see that we have received the prefixes from our own AS and also from ASBR.
Now let's check if these VPNv4 prefixes are advertised to the SP1-PE1 and SP2-PE2 or not.
So the PEs only shows the routes learned from connected CE routers! So what could be the problem?
Remember that the route-target value configured for both the VRFs are different.
We have to import/export the value on at least one PE routers. I will import/export RT 100:100 on SP2-PE1.
As a result of this, we can now see that both the PEs have started learning both the prefixes.
We can see that even though the prefixes have been learned by PEs, they don't appear as "best" routes.
The above output shows the reason behind it.
The ASBRs advertise the routes to PE routers, they do not change the next-hop-value hence the route learned by SP1-PE1 shows next-hop as 10.1.45.5 and the route learned by SP2-PE shows next-hop as 10.1.45.4.
The link between ASBRs (10.1.45.0/24) is not advertised into any IGP so PE router's mark the next=hop as inaccessible.
One way to resolve this issue is by advertising the subnet of this link (10.1.45.0/24) into IGP of both service provider networks.
The other way to do this is by setting next-hop-self on ASBR toward the PE router. We will use this method here.
Now we can see that the routes are marked as "best".
So let's check the routing table of CE1 and CE2.
A quick ping test confirms that the connectivity between loopbacks is working.
The traceroute shows that there is an end-to-end LSP between SP1-PE1 and SP2-PE2.
The thing to remember here is that the uses three different LSPs to reach at the destination.
The "LSP1" is between SP1-PE1 and SP1-ASBR. If we look at the output from SP1-PE1, it shows the VPN label assigned for VRF is "20".
The transport label to reach SP1-ASBR is "17"
This clarifies the first couple of hops of our traceroute output
The packet now hits SP1-P and it remove the transport lable "17" under the PHP process and ends up with a single label "20".
Packet is then forwarded to SP1-ASBR where the LSP 1 ends.
The "LSP2" is between SP1-ASBR and SP2-ASBR.
On SP1-ASBR the label "20" is swapped with "23" and the packet is passed onto SP2-ASBR.
Step 4 of the traceroute confirm this.
This is where "LSP2" ends and "LSP3" begins.
The "LSP3" is between SP2-ASBR and SP2-PE1.
As per the output from SP2-PE1, the VPN label assigned for VRF "RED" is "20" hence SP2-ASBR swaps the label "23" with "20" and uses transport label "16" to reach SP2-PE1.
If we would have redistributed the link between ASBRs (10.1.45.0/24) in the IGPs then we would have ended up with 2 LSPs.
More information on this can be found here
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-asbr.html
how can i make the CE routers to learn the addresses?
ReplyDeleteThanks for the post, How can simulate with GN3
ReplyDeleteRegards
Very good document. It clearly describes the specific configurations required for Inter-AS Option B and what we should expect to see at Data Plane level. Good job!
ReplyDeleteGood Job Buddy.. I read is enough to understand this..
ReplyDeleteThanks For sharing this Superb article.I use this Article to show my assignment in college.it is useful For me Great Work. torrenting without vpn
ReplyDeleteNice knowledge gaining article. This post is really the best on this valuable topic. anime torrents
ReplyDeleteTook me time to read all the comments, but I really enjoyed the article. It proved to be Very helpful to me and I am sure to all the commenters here! It’s always nice when you can not only be informed, but also entertained! setup vpn iphone
ReplyDeleteGood job, hats off for the 3 MPLS inter connect articles they are easy to follow. ^^
ReplyDelete
ReplyDeleteGood Post. I like your blog. Thanks for Sharing good information.
DevOps Training
DevOps Online Training
Inter-AS MPLS VPN - Option B (VPNv4 EBGP between ASBRs) enhances network flexibility and connectivity, much like the elvis on tour jacket represents iconic style and performance. Just as the jacket connects fans to Elvis's legacy, this networking option links different systems seamlessly, ensuring smooth communication and data flow across diverse networks.
ReplyDelete