Basic SRv6
Load top1.vpnv4v6.over.ipv6.core.cfg
L3VPN for IPv4 and IPv6 is currently setup between all CEs. The data plane is currently not working - neither MPLS nor SRv6 are setup.
Using SRv6, enable these L3VPN services. Use 2001:db8:400::/40 as the SRv6 locator block.
Answer
Explanation
SRv6 uses IPv6 in the data plane instead of MPLS. The SID takes the form of an IPv6 address instead of an MPLS label. Otherwise, all SR concepts are essentially the same whether IPv6 or MPLS is used as the data plane.
The SRv6 SID is composed of three items:
The locator
Consists of a common ::/40 locator block among all nodes in the SR domain, and a ::/24 Node ID portion. This produces a ::/64 locator prefix on each node.
The function
This is the behavior of the SID. This might simply be that the SID identifies a specific node, and the node processes the SRH. (This is an END SID). Or perhaps the SID is a “VPN label” equivalent and the function is that the PE should forward the packet in the customer VRF.
The argument to the function
So far this is only used for EVPN multicast flooding. The agrument is the ESI split-horizon “label” which tells the remote PE not to flood to a particular multihomed CE in order to implement split horizon filtering.
Otherwise this is not usually present in the SRv6 SID.
In SR-MPLS, we use the prefix-sid index # command under the loopback. This defines a prefix SID and the index into the global MPLS block for the MPLS label value. However, in SRv6, we instead define the locator ::/64 block on each router. Technically, in this lab we can do this on only the PEs, but to support abitrary path steering and TI-LFA, we should configure a locator on every router in the SR domain.
We then advertise this locator into ISIS (OSPFv3 does not support SRv6 yet) using the following configuration:
Multiple locators (up to 8) can be advertised by a node. However, every locator prefix must belong to the same ::/40 block. This is because this single ::/40 block will hold SRv6 locator prefixes for the entire SRv6 domain. Each locator can be associated with a flex algo. However, in this introductory lab, we simply use the default algo #0.
We can confirm the SRv6 locator prefix using the following command:
The router advertises its ::/64 locator prefix into the IGP. This allows all routers in the domain to simply steer SIDs for each router using normal longest-match IPv6 forwarding. For example, on XR6 we see a ::/64 route for every other router’s locator prefix:
This happens due to the LSP each router originates into ISIS. We can see several details here:
Above, we see that 2001:db8:400:6::/64 is advertised as a regular unicast prefix. This allows transit nodes to simply forward based on longest-match routing, without needing to support SRv6.
Additionally we see “node maximum SID depth” values for various SRv6 encap functions. We also see an SRv6 locator TLV. This contains the ::/64 prefix and the End SID (which is like an SRv6 prefix SID). This End SID appears to support both PSP (penultimate segment pop, where the second-to-last endpoint removes the SRH) and USD (the final endpoint, XR6, removes the IPv6 header completely). Note that the block length is 40 and node-ID length is 24. This doesn’t appear to be configurable. Finally, at the bottom, we see an END.X SID (SRv6 Adj-SID). One is listed for every adjacency.
We can see each SID allocated by the router using the following command. The VPN SIDs (End.DT4 and End.DT6) will be discussed later in this article.
Instead of stacking MPLS labels to steer onto a path that differs from the IGP bestpath, you stack IPv6 destination addresses by using an SRH (segment routing header).
The SRH contains the upper layer protocol (next header), routing type (SRH is type 4), segments left (a pointer to the active segment), last entry (an optimization for the router to quickly find where the optional TLVs start), flags and tags (both unused currently).
The segments are listed in reverse order. The last segment is index 0, and the first segment is the last index. The segments left pointer then points to the active segment. (i.e. if there are three segments, and two segments are left, the active segment is the second segment at index[1]).
As the SRH passes through the segments, the segment list is kept intact. As each segment is processed, the segments left field is decremented by one, and the IPv6 destination address is updated to reflect the currently active segment.
L3VPN Services
Now that we have the locator configured and advertised into the IGP, we must configure BGP L3VPN to use an SRv6 SID instead of an MPLS label. First we configure segment-routing srv6 under BGP. This appears to enable SRv6 for BGP in general. We can also set the locator at this level. Optionally, we can set the locator under the individual VRFs instead.
Under each VRF’s address-family, we configure the SRv6 allocation mode. (In MPLS, this would be the label-allocation mode). Our only options with SRv6 are per-CE and per-VRF. There is no per-prefix allocation mode as we have with MPLS. (We only have 2^13=8192 possible values for local functions, so per-prefix mode would not be safe).
Each PE now includes the prefix SID path attribute with the VPN route. This is a PA, not an extcommunity. For example, let’s look at the route for 1.1.1.1/32 on XR6:
The prefix SID attribute is type 5 which is L3VPN. The TLV has a SubTLV which is the SID information. This SubTLV contains the SID of 2001:db8:400:5::. However, this is only the locator ::/64 prefix. The SubSubTLV contains the breakdown of each component of the SID, and an offset for the function. This tells the router to take the received MPLS label and place it in the function portion of the SID. This cannot be seen in the CLI output. However, we see that XR6 concatenates 2001:db8:400:5 with 0x41 to produce the correct SID for this L3VPN route:
The encoding of the MPLS label in the VPNv4 route appears to be off, because the MPLS label is 0x410, yet the function is just 0x41.
Note that the entire purpose of transcoding the function into the MPLS label is for more efficient BGP update packing. Since all NLRI sharing the same PAs can be packed into an update, this allows multiple L3VPN routes to share the same prefix SID path attribute with the SID as simply the locator prefix. Then each NLRI’s label field determines the function field of the SID.
The H.Encaps.Red means that the ingress PE acts as a headend and encapsulates the customer packet with an IPv6 header that uses a reduced SRH. A reduced SRH does not include the very first segment in the SRH as an optimization. Since there is only one segment in the SID list, no SRH is needed at all. We can see this on a customer packet sent from 2.2.2.2 to 1.1.1.1:
When XR5 receives this packet, it does a normal FIB look for this destination address. The FIB lookup points to a End.DT4 behavior, which means decapsulate and forward in the IPv4 VRF table.
This process works the same for VPNv6 routes. We can see that XR6 receives MPLS label 0x420 and the same prefix SID locator block:
The VRF FIB contains a SID-list of 2001:db8:400:5:42::
XR5’s FIB has a End.DT6 function for this entry:
Last updated
