Implementing Inter-AS MPLS L3VPN services with Option B
In the previous post we've seen how we can set up an inter-AS L3VPN with Option A. We continue this lab, but this time we'll set up the inter-AS L3VPN services with Option B.
Removing everything related to Option A:
As you can I've already removed the subinterfaces from the picture of the topology above. And that's what we're going to do first: we remove the subinterfaces and all of the VRFs from R1 and R7, we don't need these with Option B:
R1(config)# no int g0/0.10 R1(config)# no int g0/0.20R1(config)#no vrf definition RED% IPv4 and IPv6 addresses from all interfaces in VRF RED have been removedR1(config)#no vrf definition GREEN% IPv4 and IPv6 addresses from all interfaces in VRF GREEN have been removed
We do the same thing on R7. Because of this R1 and R7 don't have any BGP prefixes in their BGP table at this point:
R1(config)#do show bgp vpnv4 unicast allR1(config)#
This is because we have no import RTs on either router.
About Option B
Instead of the IPv4 unicast BGP neighborships, this time we'll have a single VPNv4 BGP neighborship between R1 and R7. Remember with Option A we had to establish a IPv4 unicast BGP session per VRF. If we had 1000 customers, that would be 1000 IPv4 unicast BGP sessions. So we can already see that Option B is going to be much more scalable: the VPNv4 neighborship is going to be end-to-end between the two ISPs. The ISPs don't treat each other as customers: so we don't need to define any VRFs on the ASBRs (this time we'll call R1 and R7 ASBRs). The RTs are going to be globally significant between the ISPs with Option B, not just within each IPS's infrastructure. What about the MPLS label stack? The VPN label (inner label) is not going to be same end-to-end: the ASBRs swap the VPN label, so the VPN label is only going to be same within each service provider's infrastructure.
Setting up inter-AS L3VPN with Option B
First we build the VPNv4 neighborship between R1 and R7:
R1(config)#router bgp 16R1(config-router)#neighbor 100.1.17.7 remote-as 712R1(config-router)#address-family vpnv4 unicast R1(config-router-af)#neighbor 100.1.17.7 activate
R7(config)#router bgp 712R7(config-router)#neighbor 100.1.17.1 remote-as 16R7(config-router)#address-family vpnv4 unicast R7(config-router-af)#neighbor 100.1.17.1 activate R7(config-router-af)#%BGP-5-ADJCHANGE: neighbor 100.1.17.1 Up R7(config-router-af)#%BGP_LMM-6-AUTOGEN1: The mpls bgp forwarding command has been configured on interface: GigabitEthernet0/0
Look at the message below: mpls bgp forwarding command has been configured on interface. This command is automatically applied on IOS-XE and regular IOS to the interface connected to the neighbor ISP (on IOS-XR we need to issue the command manually). This command basically enables to send labeled traffic between the two ASBR. We also have to do a next-hop-self for the routes advertised to the Route Reflectors:
R1(config-router-af)#neighbor 10.4.4.4 next-hop-self R7(config-router-af)#neighbor 10.10.10.10 next-hop-self
But at this point R1 and R7 are still unable to exchange VPNv4 prefixes because they don't have any. We removed the VRFs, so we don't have RTs. We have to disable the route-target filter on both ASBRs:
R1(config-router)#no bgp default route-target filter R7(config-router)#no bgp default route-target filter
This command allows the ASBRs to forward the VPNv4 prefixes even if the routers don't have any import RTs. And after issuing this above, R1 and R7 are now able to send and receive VPNv4 routes:
R1#show bgp vpnv4 unicast all | begin Net Network Next Hop Metric LocPrf Weight PathRoute Distinguisher: 16:1 *>i 14.14.14.14/32 10.5.5.5 0 100 0 65111 iRoute Distinguisher: 16:2 *>i 13.13.13.13/32 10.5.5.5 2 100 0 ? *>i 172.2.5.0/24 10.5.5.5 0 100 0 ? *>i 172.2.6.0/24 10.6.6.6 0 100 0 ?Route Distinguisher: 16:11 *> 15.15.15.15/32 100.1.17.7 0 712 65222 iRoute Distinguisher: 16:22 *> 16.16.16.16/32 100.1.17.7 0 712 ? *> 172.2.11.0/24 100.1.17.7 0 712 ? *> 172.2.12.0/24 100.1.17.7 0 712 ?
Now the PEs can learn the prefixes from the RRs, but they can't import them into the routing table of the respective VRF. Remember with Option B the RTs are globally significant, the import/export RTs have to match between the PEs of ISP1 and ISP2. In the previous post with Option A, I configured different RTs in each ISP's infrastructure, now on each PE we use the same import/export RTs for customer GREEN (16:20) and also the same import/export for customer RED (16:10). This is how I removed the old RTs on R11 and configured the new ones:
R11(config)#vrf definition REDR11(config-vrf)#no route-target both 16:100R11(config-vrf)#route-target both 16:10R11(config)#vrf definition GREENR11(config-vrf)#no route-target both 16:200R11(config-vrf)#route-target both 16:20
And now the PEs can import the VPNv4 routes into the routing tables of the corresponding VRFs, and the customers have connectivity to their remote site. Here is the RIB of R13 for example:
R13#show ip route | sec O IO IA 16.16.16.16 [110/2] via 172.2.6.6, 00:01:53, GigabitEthernet0/1 [110/2] via 172.2.5.5, 00:01:53, GigabitEthernet0/0 172.2.0.0/16 is variably subnetted, 6 subnets, 2 masksO IA 172.2.11.0/24 [110/2] via 172.2.6.6, 00:01:53, GigabitEthernet0/1 [110/2] via 172.2.5.5, 00:01:53, GigabitEthernet0/0O IA 172.2.12.0/24 [110/2] via 172.2.6.6, 00:00:10, GigabitEthernet0/1 [110/2] via 172.2.5.5, 00:00:10, GigabitEthernet0/0
Now the prefixes of the remote site are 'O IA' inter-area routes, that's because the OSPF domain-ids are the same on each PE. With Option A they were 'O E2' external routes, because we couldn't send the extended communities of the redistributed OSPF routes between the ISPs, now we could because we have a VPNv4 neighborship between the service providers. Let's look at the label stack:
R14#traceroute 15.15.15.15 source lo0 numeric Type escape sequence to abort.Tracing the route to 15.15.15.15VRF info: (vrf in name/id, vrf out name/id) 1 172.1.6.6 2 msec 2 msec 2 msec 2 10.0.36.3 [MPLS: Labels 3005/1017 Exp 0] 6 msec 6 msec 7 msec 3 10.0.13.1 [MPLS: Label 1017 Exp 0] 7 msec 6 msec 7 msec 4 100.1.17.7 [MPLS: Label 7013 Exp 0] 6 msec 7 msec 8 msec 5 10.7.8.8 [MPLS: Labels 8008/16 Exp 0] 7 msec 7 msec 6 msec 6 172.1.11.11 [MPLS: Label 16 Exp 0] 5 msec 6 msec 7 msec 7 172.1.11.15 5 msec * 4 msec
Now we send a labeled packet between R1 and R7. R1 sends a packet with a label of 7013 to R7. The (inner) VPN label is different within each service provider's infrastructure, the ASBRs insert a new VPN label. This is what we have between R1 and R7 when R14 sends ICMP Echoes to R15:
We can also verify with the show commands: R1 swaps the label 1017 to 7013 when he sends the prefix to R7:
R1#show bgp vpnv4 unicast all 15.15.15.15BGP routing table entry for 16:11:15.15.15.15/32, version 17Paths: (1 available, best #1, no table) Advertised to update-groups: 10 Refresh Epoch 2 712 65222 100.1.17.7 (via default) from 100.1.17.7 (10.7.7.7) Origin IGP, localpref 100, valid, external, best Extended Community: RT:16:10 mpls labels in/out 1017/7013 rx pathid: 0, tx pathid: 0x0
In the other direction, when R7 sends back the Echo Reply we have the label 1012:
R7#show bgp vpnv4 unicast all 14.14.14.14/32BGP routing table entry for 16:1:14.14.14.14/32, version 2Paths: (1 available, best #1, no table) Advertised to update-groups: 10 Refresh Epoch 1 16 65111 100.1.17.1 (via default) from 100.1.17.1 (10.1.1.1) Origin IGP, localpref 100, valid, external, best Extended Community: RT:16:10 mpls labels in/out 7016/1012 rx pathid: 0, tx pathid: 0x0
And here is the pcap, when R7 sends back the Echo Reply:
So as we can see we have a single label between the two ASBR, and we don't have a single VPN label end-to-end. The ASBRs insert a new VPN label at the edge of the service provider's infrastructure. You probably guessed it, with Option C we'll have a globally significant VPN label end-to-end between the PEs. That's going to be an improvement over Option B, but that requires even more coordination between the service providers, they have to share a lot of things between each other.