# SRv6 uSID - Scale (Pt. 4) (Flex Algo)

Load **top1.vpnv4v6.srv6.usid.multi.area.part4.init.cfg** in the XRv9K topology in CML.

```
#IOS-XR
configure
load top1.vpnv4v6.srv6.usid.multi.area.part4.init.cfg
commit replace
y

#IOS-XE
config replace flash:top1.vpnv4v6.srv6.usid.multi.area.part4.init.cfg
```

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fs3Q4NI08EkB9jpt8tIai%2Fimage.png?alt=media&#x26;token=d8ec7624-42c4-47d7-98d0-c9bb49fc02ff" alt=""><figcaption></figcaption></figure>



The leaking and summarization of loopbacks has been added back in.



Add a new locator that uses flex algo 128. This should optimize latency. Ensure that prefixes are summarized at the L1/L2 routers and propagated to all L1 areas. Use **fd00:1::/32** for the prefix block, using the same formula for the node ID (XXYY, where XX is the domain, and YY is the node number).



Static latency values have been added to all links, as shown in the diagram above. If a latency value is not specified, it is statically set to 10.













































## Answer <a href="#id-7be862e9-8cd9-4372-8afb-38bf1559a0ba" id="id-7be862e9-8cd9-4372-8afb-38bf1559a0ba"></a>

```
#XR1-XR10
router isis 1
 flex-algo 128
  metric-type delay
  advertise-definition 
 !
 exit
 address-family ipv6 unicast
  segment-routing srv6
   locator LATENCY
!
segment-routing
 srv6
  locators
   locator LATENCY
    micro-segment behavior unode psp-usd
    algorithm 128
    prefix fd00:1:YYXX::/48   ! Where YY is the domain, and XX is the router number

#XR1, XR3, XR4
route-policy L2_TO_L1
  if destination in (fd00::/32 ge 40 le 40) then
    pass
  endif
  if destination in (2001:db8:200::/40 ge 128) then
    pass
  endif
  if destination in (fd00:1::/32 ge 40 le 40) then
    pass
  endif
end-policy

#XR1
router isis 1
 address-family ipv6 unicast
  summary-prefix fd00:1:5600::/40 algorithm 128

#XR3, XR4
router isis 1
 address-family ipv6 unicast
  summary-prefix fd00:1:7800::/40 algorithm 128
```



## Explanation <a href="#id-400c16c7-e4fe-494f-85f6-03d02778252b" id="id-400c16c7-e4fe-494f-85f6-03d02778252b"></a>

Using flex algo with prefix summarization uses the same configuration you are familiar with from the previous summarization lab, but with a slight twist to ensure that the algorithm is included in the prefix summary.



First we configure the Flex-Algo Defintion (FAD), the locator, and advertise the locator in ISIS:

```
router isis 1
 flex-algo 128
  metric-type delay
  advertise-definition 
 !
 address-family ipv6 unicast
  segment-routing srv6
   locator LATENCY
!
segment-routing
 srv6
  locators
   locator LATENCY
    micro-segment behavior unode psp-usd
    algorithm 128
    prefix fd00:1:YYXX::/48   ! Where YY is the domain, and XX is the router number
```



Next, we add the ::/32 to the RPL that is used to control route leaking from L2 into L1:

```
#XR1, XR3, XR4
route-policy L2_TO_L1
  if destination in (fd00::/32 ge 40 le 40) then
    pass
  endif
  if destination in (2001:db8:200::/40 ge 128) then
    pass
  endif
  if destination in (fd00:1::/32 ge 40 le 40) then
    pass
  endif
end-policy
```



Finally we add the prefix summarization. We must include the **algorithm** keyword so that the flex algo is included on the summary prefix. Without this, the prefix will simply be a normal IGP summary.



To demonstrate the issue, let’s remove the algorithm from the prefix summarization on XR3 and XR4:

```
#XR3, XR4
router isis 1
 address-family ipv6 unicast
  summary-prefix fd00:1:7800::/40
```



XR3 and XR4 add a fd00:1:7800::/40 IPv6 external prefix to their L2 LSP. They supress the more specific SRv6 locator advertisements for fd00:1:7807::/48 and fd00:1:7808::/48:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FDau5cigywsLElCSn2HUm%2Fimage.png?alt=media&#x26;token=3438e86c-5006-455c-8fb5-3409ca40d1c8" alt=""><figcaption></figcaption></figure></div>



The problem is that to XR1, this simply looks like a normal IGP prefix. So essentially, the default algo #0 is used.



A traceroute from XR5 to XR1 follows the IGP path XR5-XR1-XR3-XR7.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FTBaYOG4KzWD2xFBtqQ8c%2Fimage.png?alt=media&#x26;token=9ffa445e-b8ad-43c8-8d39-9e8bd308bd1c" alt=""><figcaption></figcaption></figure></div>



Let’s add the **algorithm** keyword back onto the prefix summary:

```
#XR3, XR4
router isis 1
 address-family ipv6 unicast
  summary-prefix fd00:1:7800::/40 algorithm 128
```



The prefix has been removed as a normal IPv6 external prefix, and is now an SRv6 locator with an associated algorithm:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FHN4KsE6HyC3kbU1BfenG%2Fimage.png?alt=media&#x26;token=268b399c-a945-4b1e-a7a7-c5aa5f47c83e" alt=""><figcaption></figcaption></figure></div>



XR1 now uses its delay values for the metric instead of its IGP costs, as it sees that the prefix is associated with algo 128, not the default algo 0. XR1 has a best path via XR4 due to lower latency values. Additionally, XR1 passes this prefix from L2 into L1 as an SRv6 locator, not an external prefix. So you only need to set the algorithm at the local ABRs which do L1 to L2 propagation.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FULpcTSSq4saxTR8U53pP%2Fimage.png?alt=media&#x26;token=84297d9a-0753-4f37-b948-179c5cb6e22b" alt=""><figcaption></figcaption></figure></div>



A traceroute from XR5 to XR7 now takes the lowest latency path:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FWvwcUSSQqRqufvgErMG2%2Fimage.png?alt=media&#x26;token=a82b4316-b2cc-4dd5-95dd-b3a4ab209647" alt=""><figcaption></figcaption></figure></div>



Note that there is also optional **explicit** knob that can be used on the summary advertisement. This means that only SRv6 locators that have the specified algorithm attached will be candidate contributing prefixes towards the summary.

```
#XR3, XR4
router isis 1
 address-family ipv6 unicast
  summary-prefix fd00:1:7800::/40 algorithm 128 explicit
```



We also saw in the previous article that the **adv-unreachable** knob should be used as well. This enables UPA (unreachable prefix advertisement) so that upon failure of a contributing prefix, the L1/L2 router will leak the contributing prefix with an unreachable metric to allow PEs to correctly do fast reroute (BGP PIC).

```
#XR3, XR4
router isis 1
 address-family ipv6 unicast
  summary-prefix fd00:1:7800::/40 algorithm 128 adv-unreachable explicit 
```



While this UPA for each flex algo summary is enabled on the XR docs design guide, I don’t quite know if this is really necessary. The BGP service routes should all be via the loopback, so simply using UPA for the single loopback should be all that is necessary. The flex algo summary will only be used for the SRv6 SID, not BGP nexthop reachability.



### The need for a PCE <a href="#id-25330f3a-a5f8-4dd6-a92f-0550c38e9da7" id="id-25330f3a-a5f8-4dd6-a92f-0550c38e9da7"></a>

Notice that a traceroute from XR7 to XR5 does not take the lowest latency path. Why is this?

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FJGoeglqrbPNQz34wez2H%2Fimage.png?alt=media&#x26;token=a81d617c-e691-45b1-afaa-5044353ca3c4" alt=""><figcaption></figcaption></figure></div>



The reason is the inherent rules for L1/L2 redistribution in ISIS. XR7’s lowest latency path is through XR3. However, XR3 has two routes for fd00:1:5600::/40. It knows this via L2 from XR1, and via L1 from XR4. The L1 path via XR4 has a lower metric (latency), but XR4 has set the down bit as the prefix is propagated from L2 into L1, so XR3 cannot use this route for risk of looping. Therefore, XR3 must use its L2 route via XR1.



Notice that XR7 actually calculates the correct metric of 60 for the path:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FX0f6wyaMz6J5qc1ehwPz%2Fimage.png?alt=media&#x26;token=51163a47-1c52-4b9c-aefb-11855c66c8a3" alt=""><figcaption></figcaption></figure></div>



However, XR3 has a metric of 110 because it must use its L2 route:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FzrSRQCGW41nbtDW9P95O%2Fimage.png?alt=media&#x26;token=e43b42d4-a0f1-4ffe-82d4-c4d04778abcb" alt=""><figcaption></figcaption></figure></div>



The best solution to this is to use a PCE for end-to-end inter-area path calculation.
