SRv6 uSID - Scale (Pt. 1)
Last updated
Last updated
Load top1.vpnv4v6.srv6.usid.multi.area.init.cfg
Configure SRv6 uSID using fd00:0000::/32 as the locator block on XR1-XR8.
Use a node ID of XXYY, where XX is the domain, and YY is the node number.
Use domain 00 for XR1-XR4
Use domain 56 for XR5 and XR6
Use domain 78 for XR7 and XR8
At the L1/L2 routers, summarize the locator prefixes so only one prefix is present in the RIB of L2-only routers for each domain.
Ensure that L3VPN fully works for the CUSTOMER VRF.
SRv6 uses the IPv6 destination address as the SID. Nodes simply need IPv6 reachability towards SRv6 SIDs, so we can summarize these prefixes just like any other IP prefix in order to achieve scalability.
By summarizing the SRv6 locator blocks in each L1 area, we can have 100s or even 1000s of ISIS L1 areas and keep the core routing tables at their minimum entries. Only one prefix will exist per L1 area.
First we use a particular addressing scheme to support unique locator blocks per-area that are easily summarized. We must use the same 32 bit block within the IGP altogether, but we are left with 16 bits to use for the node. In this lab, the first 8 bits are the area, and the last 8 bits are the node ID.
For example, a core router such as XR1 is fd00:0000:0001::/48. An L1 PE such as XR5 is fd00:0000:5605::/48, where 56 is the area and 05 is the node ID.
At the L1/L2 routers, we must manually inject summary prefixes for these locator prefixes. On XR1 we summarize fd00:0000:5600::/40, and on XR3/4 we summarize fd00:0000:7800::/40:
We should have reachability between locator SIDs now. For example, XR5 can trace to XR7’s END SID. We first find XR7’s END SID using the following command:
XR5 can trace to this:
XR5, as an L1-only node, simply follows its default route to the closest L1/L2 router, which is XR1:
XR1 follows the summary ::/40 prefix it has learned in L2:
XR3 follows the ::/48 prefix that R7 has advertised:
As you can see, this is just basic IP forwarding principles. Because the SRv6 SID is simply an IPv6 destination address, simple summarization can be used to scale SRv6.
Next we must ensure the L3VPN services are working. First we need to specify the locator for SRv6 under BGP:
Right now we notice a problem: Each PE is only marking the routes from the other PE in its own L1 area as usable:
We can see the problem by inspecting any single prefix. Notice that the nexthop is inaccessible:
The BGP nexthop cannot be reachable via a default route (::/0). To fix this we have a few options. We can simply leak all prefixes from L2 into L1, or we can leak a summary route that covers the loopback prefixes. To make this easier, let’s leak all /128 loopback prefixes into L1.
The VPNv4 paths are now marked as bestpath:
However, we still have a problem. A CE can reach another CE in connected to a PE in the same L1 domain, but not a CE connected to a PE in a remote ISIS domain. For example, CE1 can reach CE2 but not CE3:
Looking at the detailed route on XR5, we see that the SID list is correct:
However, in the CEF table, we see a clue:
In L3VPN with MPLS, we must resolve the BGP nexthop to a /32 route. In L3VPN with SRv6, we must resolve the SID to a route in the FIB. It cannot match the ::/0. Currently the route to the SID fd00:0:7807:e002:: simply matches the default route:
In addition to leaking the loopbacks into L1, we must leak the locator prefix blocks:
Now XR5 has the summary ::/40 for the SRv6 SID:
The CEF entry is now resolved:
Traffic is now working:
In summary, we use ISIS levels to achieve high scalability with SRv6. This allows us to easily summarize locator prefixes at each level boundary. However, we must be careful to make sure that the BGP nexthops and SRv6 SIDs are resolvable through a route that is more specific than the default route (::/0).
