CSC
Last updated
Last updated
Load csc.init.cfg
The IGPs of each AS are already preconfigured. Basic L3VPN is setup in AS100 for VPN_A and VPN_B, however R2 and XR2 have no connectivity yet.
Configure CSC between AS 17819 and AS 100. Use LDP where possible at the ASBR-ASBR links.
CSC (Carrier Supporting Carrier), also called Carrier’s Carrier, and also called Hierarchical L3VPN, allows an SP to use another SP for MPLS transit. Simply put, in our lab, the backbone carrier (AS 17819) carries the customer carrier’s (AS 100) global table in a VRF. This allows AS 100 to extend its MPLS transit across another MPLS provider, without the backbone carrier needing to be concerned with the final customer’s routing tables.
Another option could be to do one of the inter-AS options (A, B, or C), but in all of these cases, AS 17819 would have to partipate in VPN_A and VPN_B, which makes no sense, because the customer is not directly connecting to AS 17819. AS100 simply needs to use AS 17819 for MPLS transit.
CSC is usually seen when L2VPN p2p circuits are not an option. This may be the case if an Ethernet handoff is not viable in a particular PoP, so L3VPN using CSC might be more feasible than doing an EVC with protocol translation. (Protocol translation, as in translating Ethernet to ATM for example).
In CSC, the backbone carrier’s PEs are called CSC PEs. The customer carrier’s PEs are called CSC CEs, because from the backbone carrier’s perspective, they are CEs. In our lab, R1 and XR1 are CSC PEs. R3 and R4 are CSC CEs. R3 and R4 must advertise the internal prefixes to their CSC PE. The CSC PEs just treat this like a normal L3VPN, except they must enable MPLS on the CE-PE link.
We are limited to two options for using MPLS on the CE-PE link, because the CSC PE must put this link in a VRF. On IOS-XE, we can use LDP in a VRF, or we can do BGP IPv4-LU in a VRF. On IOS-XR, our only option is BGP IPv4-LU in a VRF. This lab asks us to use LDP where possible, so we use it on R1. Note that R1 will automatically use the interface address as the transport address for the LDP session in VRF CSC, because no actual loopback exists in that VRF.
From R3’s perspective, this is just another link in the internal IGP, which makes it easy. From R1’s perspective, this is using ISIS as a PE-CE protocol, so there is mutual redistribution between ISIS and BGP for the CSC VRF.
On R1, we can examine LDP output for the VRF by appending the vrf CSC keyword to all show commands.
On XR1, our only option is to use BGP IPv4-LU. We configure this under a VRF as you would expect. You must make sure to allocate-labels under the regular IPv4 unicast address-family. This allows routes injected from VPNv4 to be advertised to the CSC CE with a label. Remember to configure the static /32 route on IOS-XR when doing BGP IPv4-LU with an eBGP neighbor.
At this point, the backbone carrier will only have the customer carrier’s internal links in the VRF table. This is highly scalable, as no matter how many L3VPNs the customer carrier has, the backbone carrier’s VRF table stays the same size.
The customer carrier sees the ASBR link as a regular ISIS link at the R3 side, and as a BGP IPv4 LU link on the R4 side. Note that this negatively impacts TE, as there are two separate IGP islands. R1 is redistributing routes into ISIS, and R4 is redistributing BGP routes into ISIS.
Preform a traceroute between R9 and R10, and see if you can identify each label in the path.
At hops 2-4, the top label represents 20.20.20.20/32. R2 has a route to 30.10.10.10/32 via XR2. This is no different than basic L3VPN. The difference is just that the route to 20.20.20.20/32 has been redistributed into ISIS at R1.
At hop 5, the label 34, which represents 20.20.20.20/32, is swapped for the VPN label 24003 which comes from XR1. The transport label for XR1 within AS 17819 is pushed on top as well.
At hops 6-7, normal transport switching is preformed. R8 preforms PHP, exposing the service label for 20.20.20.20/32 in VRF CSC to XR1.
At hop 8, XR1 swaps label 24003 for label 18, which it learned from R4 via BGP IPv4-LU. The rest of the path does normal transport switching towards 20.20.20.20/32.
Notice that the service label that XR2 allocated, 24010, is carried end-to-end. This is possible because the CSC CE ↔ CSC PE links are MPLS enabled.
Let’s break LDP at the R1-R3 link.
The LDP session goes down at R3:
A traceroute from R9 to R10 is completely broken, because the traceroute functionality relies on a fully working LSP to the egress PE, which tunnels the ICMP error all the way back to the CE. Without this working, we can only get one hop.
IPv4 reachability between R2 and XR20 is still maintained, because R3 can send unlabeled traffic to R1.
If we traceroute from R2 to XR2, we can see that the packet becomes unlabeled at R3-R1:
We can also verify this in the LFIB of R3. Previously, R3 had an outgoing label for 20.20.20.20/32. Now the outgoing action is no label. Completely disposes the VPN label, which breaks the end-to-end L3VPN LSP.
One more way to troubleshoot this is an OAM traceroute. We enable mpls oam on XR2. The OAM traceroute cannot go beyond R3 because the packet becomes unlabeled.
We then bring the LDP session back up between R1-R3. The OAM traceroute will timeout within the backbone carrier’s core, because the traffic is L3VPN traffic. However, once it gets past the backbone carrier, we should see the OAM packet terminate at 20.20.20.20.
When it comes down to it, CSC is just about running L3VPN using labels at the CE-PE link. In CSC, the CE-PE link is called CSC CE - CSC PE. The prefixes that the CE advertises to the PE are the internal loopbacks in order to achieve end-to-end LSPs through the backbone carrier. That’s really all there is to it.
We have two options for enabling MPLS at the CSC CE - CSC PE link: LDP in a VRF (only on IOS-XE), and BGP IPv4-LU.
Interestingly, you could have multiple levels of heirarchy if you desired. In this lab, you could have CEs connecting to the customer carrier which are in fact a lower level of customer carrier. The customer carrier would carry the lower level customer carrier’s loopbacks in a VRF. The level of heirarchy is arbitrary. CSC is just the practice of extending an internal MPLS domain via L3VPN of another transit provider, which requires MPLS at the CE-PE links.
