CSC (Carrier Supporting Carrier)
CSC (Carrier Supporting Carrier) is a design which allows one ISP to provide transit MPLS service for another ISP. This is sometimes called hierarchical L3VPN.
An example will help explain this. Imagine ISP1 wants to provide service in a new area but they cannot obtain their own connectivity in order to connect the new PoP to their existing IGP. In order to offer L3VPN service (or really any service for that matter) they need to connect the router to their internal MPLS network.
Usually ISP1 will order L2VPN service, but sometimes this is not possible. For example, if an ethernet handoff is not available at the new PoP, then Layer 3 might be the best option.
So ISP1 orders L3VPN service from ISP2, but ISP2 cannot treat ISP1 like a regular L3VPN customer. ISP2 needs to exchange labels with ISP1 so that ISP1 can send its own labeled traffic through ISP2. The two routers connecting ISP1 and ISP2 are actually both PEs. From ISP2’s perspective, ISP1 is a CE, but from ISP1’s perspective, that device is a PE which will connect to other CEs.
ISP2 is called the backbone carrier or core carrier, because it is offering backbone service to ISP1.
ISP1 is called the customer carrier because they connect directly to the customer. The backbone carrier provides MPLS L3VPN transit service to the customer carrier.
SP2’s (backbone carrier) PE is called the CSC_PE. ISP1’s (customer carrier) PE is called the CSC_CE, and connects to real CEs of the customers. The CSC_CE is named as such because it acts like the CE from the backbone carrier’s perspective.
There are two options for exchanging labels between the CSC_PE and CSC_CE: LDP/IGP or BGP-LU. In the following lab we will use both options. LDP is not available on VRFs in IOS-XR, so we will use LDP and OSPF on the XE CSC_PE and CSC_CE devices, and BGP-LU on the XR CSC_PE and CSC_CE devices.
The customer carrier needs to be able to send labeled traffic to the backbone carrier with the top label representing the loopback IP of another CSC_CE. So all the CSC_CEs advertise their loopbacks to the CSC_PEs with a label, and the CSC_PEs advertise other CSC_CE loopbacks to the connected CSC_CE with a label. The backbone carrier only needs to be concerned with the customer carrier CSC_CE loopback IPs, and does not care at all about the actual Customer L3VPNs behind the CSC_CEs.
As you go through the lab this will make much more sense. In a way, CSC is just regular L3VPN but enabling labeled traffic at the CSC_PE/CSC_CE peering point.
Lab
Notice in the diagram below how CSC creates a heirarchy. SP2 is the backbone carrier at the top of the heirarchy. It treats SP1 as a normal L3VPN customer except it also exchanges labels for the /32 loopback prefixes that SP1 advertises.
The Customer devices (CE1 and CE2) see SP1 as PE devices.
Here are the startup configs. I have configured everything as a “normal” L3VPN service.
Right now the CSC_CEs are learning routes from the CEs, but traffic is not working. The two CSC_CEs will need to peer with each other over vpnv4. Let’s first enable LDP between the two IOS-XE routers:
When you run LDP on an interface in a VRF, the transport address is automatically the interface. This is the case on CSC_PE1, because int Gi1 is part of the CUSTOMER_ISP1 VRF.
On the interface in the global VRF, which is Gi2 on CSC_CE1, we need to force the transport-address to be the interface address. Otherwise the transport address is Lo0 (the RID), which CSC_PE1 cannot reach right now. See the article “LDP Router-ID Issues” for more on this topic.
We’ll now run OSPF between CSC_CE1 and CSC_PE1 so that CSC_PE1 can learn CSC_CE1’s loopback and advertise this into the L3VPN, by redistributing OSPF into BGP. This configuration is regular OSPF as a PE-CE protocol.
IOS-XR does not have the ability to run LDP in a VRF. Instead we will use BGP labeled unicast to exchange label information for the ISP1 loopbacks at the CSC_PE2-CSC_CE2 peering point.
As we saw in Option C, we also need to create a static /32 route on the XR routers in order to send labeled traffic to a nexthop.
CSC_CE1 and CSC_CE2 now have reachability between their loopbacks. Not only that, but they have an LSP between them.
All we need to do in order to enable the L3VPN service for CE1 and CE2 is run vpnv4 between the ISP1 PEs.
The CEs now have reachability between themselves:
Test your knowledge:
How many labels deep is the stack at ISP2_P3 as it receives the ICMP request from CSC_PE1?
What is the AS path of the route 10.1.2.0/24 as seen on CE1?
Answers:
The label stack at ISP2_P3 is three labels deep:
The transport label representing CSC_PE2 (200.2.2.2/32)
The service label CSC_PE2 allocated for 100.2.2.2/32
The VPN label that CSC_CE2 allocated for 10.1.2.0/24
The AS path for 10.1.2.0/24 on CE1 is 100 65001 i. The route is advertised directly from CSC_CE2 to CSC_CE1. ISP2 plays no role in routing for the customer VRF. It only provides transit service to ISP1 for its own loopbacks.
Next, examine a traceroute from CE1 to CE2 and see if you can identify the labels:
Hop 2: 21 is the label assigned by CSC_PE1 for CSC_CE2’s loopback, and 24001 is the service label assigned by CSC_CE2 for 10.1.2.0/24. This label (24001) will be carried throughout the entire path.
Hop 3: 17 represents CSC_PE2 and 24006 is the service label assigned by CSC_PE2 for CSC_CE2’s loopback.
Conclusion
CSC sounds complex, but once you actually configure it I hope you find it easier than you thought it would be. The problem that CSC solves, is that in order for a backbone carrier to provide L3 MPLS service to a customer carrier, the CSC_PE and CSC_CE need to be able to send labeled traffic to each other. This allows the customer ISP to carry a service label end-to-end from one CSC_CE to another, all the way through the backbone ISP.
This means that CSC is essentially just heirarchical L3VPN service, but with some type of label exchange (BGP-LU or LDP) running between the backbone carrier and customer carrier.
The only information that the customer carrier needs to advertise to the backbone carrier is the loopback IPs which are used for BGP peering internally. This enables the CSC_CEs to form LSPs between each other through the backbone carrier.
Further Reading
RFC4364 Section 9 “Carrier’s Carriers” https://www.rfc-editor.org/rfc/rfc4364#section-9
https://orhanergun.net/carrier-supporting-carrier-csc/
If you are interested in something a little more complex, check out Nick Russo’s fantastic white paper, Global MPLS Design Using CSC http://njrusmc.net/pub/csc_optc.pdf
Last updated
