SRv6 uSID w/ L3 IGW
Load top1.vpnv4v6.srv6.igw.init.cfg
The PEs XR5/XR6/XR7 are SR-MPLS only. They only use XR9 as the RR.
XR8 is SRv6 only, and only uses XR10 as the RR.
Configure XR2, which belongs to both the SR-MPLS and SRv6 domains, to be the interworking gateway (IWG), translating between SRv6 and SR-MPLS for both L3VPNv4 and L3VPNv6.
Answer
Explanation
When an operator wants to transition from MPLS to SRv6, there may be a transition period in which there are domains that only use MPLS and some domains that only use SRv6. Or it might be the case that two domains are merged together, and you must support interworking betwen an SRv6-only domain and SR-MPLS or LDP-only domain. An IWG (interworking gateway) is needed to translate between the MPLS domain and SRv6 domain.
This sounds complex, but the operation is fairly straightforward. The IWG simply inserts itself in the middle of all flows, somewhat performing option A inter-AS functionality. Every customer VRF must be defined on the IWG. The IWG will advertise routes learned from the MPLS domain into the SRv6 domain with an SRv6 SID. Likewise, it will advertise routes learned from the SRv6 domain into the MPLS domain with an MPLS label. The IWG simply translates between these two domains by advertising these routes from itself and performing a routing lookup upon received traffic.
First we must define the VRF on the IGW. The stitching RTs are the SRv6 RTs. The normal RTs are the SR-MPLS RTs. Currently, XR5, XR6 and XR7 use 100:1, and XR8 uses 100:2.
We enable SRv6 for BGP, and enable SRv6 under the VRF. The mode will automatically be a per-VRF mode, as the router will need to do a table lookup when stitching traffic coming from the SRv6 side onto the SR-MPLS side. Additionally, we enable MPLS label allocation for the VRF as well, as the VRF will be allocating both MPLS labels and SRv6 SIDs.
Next we configure the stitching on the SR-MPLS side. This is done under the neighbor statement. R9 is the RR for the SR-MPLS domain, and R10 is the RR for the SRv6 domain. We peer with R9 and use three special commands:
import reoriginate stitching-rt means to import routes as normal (using the normal 100:1 RT), and then reoriginate them with the stitching RT
route-reflector-client is needed, because the IGW needs to reflect routes learned from the SRv6 RR to the SR-MPLS RR
advertise vpnv4 unicast re-originated means to advertise the VPN unicast routes that have been re-originated from SRv6. These will use the normal RT (not the stitching RT) when they are reoriginated, because the stitching-rt keyword is not added.
On the SRv6 side, we use a similar configuration:
import stitching-rt reoriginate means to import routes with the stitching RT (100:2) and then reoriginate them using the normal RT
route-reflector-client is needed as above, to reflect routes between the RRs
encapsulation-type srv6 is required so that the router advertises the VPN routes with only the prefix SID, not an MPLS label. (We have previously allocated a normal MPLS label under the VRF).
advertise vpnv4 unicast re-originated stitching-rt means to advertise the VPN unicast routes that have been re-originated from SR-MPLS, and use the stitching RT when re-originating them.
Note that you can use the same RT for the normal and stitching RT. This works without any issue. For example, I've changed R8 to use the same RTs as the SR-MPLS PEs:
The IGW now uses the same RT for both the normal RT and stitching RT:
Whether you are using the same or different RTs for SRv6 and SR-MPLS, traffic shold now be working between CEs on the SR-MPLS side, and CE4 (on the SRv6 side):
Within each domain, each PE believes that the IGW is the “true” PE for routes in the other domain. For example, within the SR-MPLS domain, XR5 believes that XR2 is the PE for 4.4.4.4/32.
XR8 believes that XR2 is the PE for 1.1.1.1/32:
XR2 simply does a stitching operation in each direction using normal routing procedures. The packet arrives either via the MPLS label or SRv6 SID, and XR2 does a routing table lookup. The route points to the other domain, so the packet is forwarded either with an SRv6 encapsulation, or MPLS label.
The per-VRF label 24003 simply means “do a table lookup in the CUSTOMER VRF”:
Likewise, the SRv6 SID fd00:0:2:e004:: means to do a table lookup in the CUSTOMER VRF:
XR2 performs a table lookup, and then preforms normal ingress PE functionality by sending the packet either down the SR-MPLS LSP or encapsulating it with an SRv6 SID.
EVPN and L3VPN Reminder
It is useful to compare this to interworking for EVPN and L3VPN. The commands for SRv6/MPLS interworking appear to be borrowed from EVPN/L3VPN interworking.
With EVPN/L3VPN stitching, VRF routes learned via VPNv4/v6 are re-advertised into the EVPN domain as type 5 routes. The DCI router (a sort of IWG for EVPN/L3VPN) has two sets of RTs:
Normal RTs for the VPNv4 L3VPN domain
“Stitching” RTs for the EVPN domain
Using the same commands we have just used in this lab, the DCI router will import the stitching RTs in the EVPN domain, and re-originate them into L3VPN:
The DCI router also must advertise the L3VPN routes into the EVPN domain as type 5 routes. The router imports routes from VPNv4 and re-originates them with the stitching RT. Then it advertises these re-originated routes with the stitching RT into EVPN. The stitching-rt keyword in the advertise command essentially means “advertise re-originated routes from VPNv4 but change the RT to the export stitching RT.”
See this post for more details on EVPN/L3VPN interworking: https://xrdocs.io/ncs5500/tutorials/bgp-evpn-and-l3vpn-interworking/
Last updated
