Showing posts with label SR Policy. Show all posts
Showing posts with label SR Policy. Show all posts

Friday, April 24, 2026

Segment Routing: Managing SRv6 Header Overhead with uSID and SRm6

In my last post, we looked at how to configure SRv6 on the Nokia 7750 SR. One big challenge with SRv6 is the header overhead. Since every "Segment Identifier" (SID) is a full 128-bit IPv6 address inside the SRH header, the header gets very large very quickly.

This extra weight often causes fragmentation. When a packet is too big for the MTU of a link, it has to be broken into pieces.

This is bad for two reasons:

  1. It slows down the network because of the processing power needed for fragmentation/reassembly.

  2. It's a security risk, as hackers often use fragmentation attacks to sneak past security filters.

We have two main options to make the IPv6 headers smaller:

1. Micro-SID (uSID)

Micro-SID is strongly recommended by Nokia and Cisco. Instead of giving every hop a full 128-bit address, uSID uses a "container" concept.

How it works: It takes one 128-bit address and divides it up. The first part (the Locator) identifies the network, and the rest of the bits are used for "mini-IDs" (16-bit length in FP-based platforms or 32-bit for other platforms in Nokia).

Ideally, 6 mini-SID hops are injected inside a single 128-bit address. This keeps the header small and prevents the packet from needing to be fragmented.

2. SRm6

This is a different approach, mostly recommended by Juniper. Juniper always does things differently!

SRm6 runs Segment Routing over "Native IPv6" without using the heavy SRv6 header. It uses much smaller IDs—only 16 or 32 bits per destination. This makes the packet look more like a standard IPv6 packet, which saves a lot of space.


Lab Example: SRH Header Capture

Here is a screenshot from my lab. You can see the SRH (Segment Routing Header) in the packet capture. Notice how much space the segment list takes up when we use standard 128-bit SIDs.




Final Thoughts

In my view, if you are working in a multi-vendor environment, sticking with uSID is the better path for SRv6. It’s becoming the industry standard for keeping the data plane efficient while ensuring compatibility between the big players like Nokia and Cisco.

Tuesday, March 31, 2026

SR-MPLS Troubleshooting: Identifying and Fixing Controller-Injected Null EROs

Recently I faced the issue where SR-MPLS is down due to an empty ERO path for SR-TE LSP, and the path is managed by the controller.

Background:

Implemented SR-MPLS LSP for one of our customers. where the LSP paths are injected from the controller based on the constraint. We faced some issues with respect to the controller recently and fixed them after the upgrade. Post upgrade, we observed that one of the LSPs didn't come up.

Verification:

End-to-end path manually to see whether it meets the constraints mentioned for the path. Everything seems to be fine.

The team checked the controller logs; there are no errors but it is sending empty ERO to the router

As this is very critical, I did perform troubleshooting and am finally able to bring the LSP path with correct path details instead of the empty ERO from the controller:


LSP Configuration:

            lsp "srte-access1-pre-agg" sr-te
                to X.X.X.X
                path-computation-method pce
                max-sr-labels 4 additional-frr-labels 2
                pce-report enable
                pce-control
                bfd
                    failure-action failover-or-down
                exit
                path-profile 1 path-group 128946735
                primary "srte-p"
                    priority 1 1
                exit
                secondary "srte-s"
                    standby
                    priority 7 7
                exit
                no shutdown
            exit
            no shutdown


Troubleshooting Steps:

# show router mpls sr-te-lsp

=====================================================================
MPLS SR-TE LSPs (Originating)
=====================================================================
LSP Name                                            Tun     Protect   Adm  Opr
  To                                                Id      Path
---------------------------------------------------------------------

srte-access1-pre-agg                   4       N/A       Up   Dwn
  X.X.X.X
---------------------------------------------------------------------
LSPs : 1
=====================================================================

Enabled Debug for SR-TE LSP:

debug
    router "Base"
        mpls lsp "srte-access1-pre-agg"
            event
                iom
                lsp-setup
                xc
                frr
                mbb
                misc
                pcc
                te
            exit
        exit
    exit

config>log>log-id$ info
----------------------------------------------
            from debug-trace
            to session
            no shutdown

Debug Logs

Received PCC Reply for srte-access1-pre-agg::srte-p(LspId 62454)
User SR-TE, GenId 2, NumRequests 1
[Reply 1]
  LspType SR-TE, TunnelId 4, PathIdx 10
  LspId 62454, VrId 1, ExtTunnelId X.X.X.X
  LspName "srte-access1-pre-agg::srte-p"
  From X.X.X.X, To X.X.X.X
  Status Path not found, PCCHasLspState Yes
  ERO:
    No hops
  OperBandwidth 0Mbps, HopCnt 0, IgpMetric 0, TeMetric 0

From debug it's clear the controller is not able to calculate the path for the LSP. The next step removed the LSP control from PCC to PCE.

After configuring the local-cspf to calculate the path, LSP has come up. So it gave me an idea that there is no issue with the path or the CSPF configuration along the path.

PE>config>router>mpls>lsp# path-computation-method pce

=====================================================================
MPLS SR-TE LSPs (Originating)
=====================================================================
LSP Name                                            Tun     Protect   Adm  Opr
  To                                                Id      Path
---------------------------------------------------------------------

srte-access1-pre-agg                   4       N/A       Up   Up
  X.X.X.X
---------------------------------------------------------------------
LSPs : 1
=====================================================================

LSP Path Detail:

Primary         : srte-p
                                            Down Time: 0d 00:19:02
Bandwidth       : 0 Mbps
Standby         : srte-s
                                            Down Time: 0d 00:19:10
Bandwidth       : 0 Mbps



Rollback the configuration to PCC from PCE, then check again, but the LSP is again gone down with an empty ERO. Due to some reason, the controller is not able to calculate the path for the LSP. seems something is stuck but not able to figure out until this point

Next, path profiles are responsible for setting the constraint on the controller, so remove it, and the LSP has come up. So it's clear that something is wrong in controller in calculating the path, maybe due to something got stuck and its not able to remove it from its cache. 

PE>config>router>mpls>lsp# no path-profile 1

=============================================================
MPLS SR-TE LSPs (Originating)
=============================================================
LSP Name                                            Tun     Protect   Adm  Opr
  To                                                Id      Path
-------------------------------------------------------------
srte-access1-pre-agg                   4       N/A       Up   Up
  X.X.X.X
-------------------------------------------------------------
LSPs : 1
=============================================================

This time I enabled the path profile configuration on the router, but I did change the path group value, and then the LSP came up, and now the controller was able to calculate the path and send the details to the router.

Debug Logs:

"MPLS: SR-TE : PCC
Received PCC Reply for srte-access1-pre-agg (LspId XXX)
User SR-TE, GenId 2, NumRequests 1
[Reply 1]
  LspType SR-TE, TunnelId 4, PathIdx 9
  LspId XXX, VrId 1, ExtTunnelId XXXX
  LspName "srte-access1-pre-agg"
  From X.X.X.X, To X.X.X.X
  Status Path found, PCCHasLspState Yes
  ERO:
    [1] SIDType IPv4 Node, SID 23434343, RemoteAddr X.X.X.X, Loose
    [2] SIDType IPv4 Node, SID 23432434, RemoteAddr X.X.X.X, Loose
  OperBandwidth 0Mbps, HopCnt 2, IgpMetric XXX, TeMetric 0
"

LSP status:

show router mpls sr-te-lsp "srte-access1-pre-agg" path "srte-p"

=============================================================
MPLS SR-TE LSP srte-access1-pre-agg
Path srte-p
=============================================================
-------------------------------------------------------------
LSP Name    : srte-access1-pre-agg
From             : X.X.X.X
To               : X.X.X.X
Adm State        : Up                      Oper State        : Up
-------------------------------------------------------------
Path Name                        Type           Adm  Opr
-------------------------------------------------------------
srte-p
                                 Primary         Up   Up
=============================================================

This LSP was down before the controller upgrade, and this group value was copied somehow after the upgrade. Group value in the cache with the previous issue state causes the controller to send the empty ERO continuously. After reconfiguring with the new value, the old group value got cleared, and the LSP came up. After monitoring the LSP for some time, I changed the group value as per the agreed standard. 

Recommandation:


It's not recommended to perform the troubleshooting without the support team because, from my experience with various roles, it gave me enough confidence to do all the various ways of bringing up the LSP without causing the traffic impact in the network.


Thursday, March 12, 2026

Flex-Algo Configuring on Nokia 7750 SR and steering VPRN traffic via Flex-algo 129 : A Step-by-Step Implementation Guide

Flex Algo provides the mechanism for IGP to use constraint-based paths like RSVP or SR TE using ISIS or OSPF extensions. By default, ISIS uses default algorithm 0. Along with it, there are 128 to 255 algorithms supported in Nokia. 

As of writing, Nokia does not support flex-algo 1. but it does supported by juniper because we have identified during a project to swap Juniper MX with Nokia 7750 SR

All the routers participating in the Flex Algorithm should have the same definition of how it should work.

Consider the SRGB block of 2000-3000. To reach prefix F1, index-1, algorithm 0, label is 2001, then we have prefix F2, index-101, algorithm 128 and to reach F2 label is 2101

Nokia supports Flex algo 128, 129 and 130.

 



By default the IGP cost-based tunnel travels through PE5 to PE3 via PE5-PE1-ASBR1-ASBR3-PE5. 

Let's configure Flex Algo 129 based on delay and push the traffic towards PE5-PE5-PE2-ASBR2-ASBR4-PE4-PE3.

*A:PE5>config>router>fad>flex-algo$ metric-type

{igp|te-metric|delay}

We can map the flex algo to SR-MPLS as well or steer traffic to SR-TE.

Delay metric:

We can configure the delay metric statically or dynamically and advertise it in ISIS or OSPF. 

Configuring the delay metric on the interface directly.

        interface "PE1"

            if-attribute

                delay

                    static 100000

                exit

            exit

            no shutdown

        exit

        interface "PE6"

            if-attribute

                delay

                    static 10000

                exit

            exit

            no shutdown

        exit

As per our topology, shortest path to reach the PE5 to PE3 is via PE1 through IGP metric calculation. 

Propogating the delay in IGP

*A:PE5>config>router>isis# info

----------------------------------------------

            level-capability level-2

            area-id 49.0001

            traffic-engineering-options

                advertise-delay

                application-link-attributes

                exit

            exit

We can configure both static and dynamic delay together and have the option to configure which one we prefer. I am using a static delay. In a later blog, we will use the dynamic delay calculation using twamp.








Configuring the flex algo and metric-type










ISIS advertising flex algo 129 and delay as metric type



A:PE3>conf>router>segment-routing# info

            sr-mpls

                prefix-sids "system"

                    ipv4-sid index 13

                    flex-algo 129

                        ipv4-sid index 53

                    exit

                exit

            exit

            sr-policies

                shutdown

                reserved-label-block "sr-policy"

            exit

A:PE3>conf>router>segment-routing# sr-mpls prefix-sids "system"

A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# flex-algo 129 no ipv

ipv4-sid  ipv6-sid

A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# flex-algo 129 no ipv4-sid

*A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# info

----------------------------------------------

                    ipv4-sid index 13

                    flex-algo 129

                    exit

----------------------------------------------

*A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# no flex-algo 129

*A:PE3>config>router>isis# interface "system" flex-algo

<[128..255]>

 

*A:PE3>config>router>isis# interface "system" flex-algo 129

ipv4-node-sid   ipv6-node-sid

*A:PE3>config>router>isis# interface "system" flex-algo 129 ipv4-node-sid

index <[0..4294967295]>

label <[0..4294967295]>


*A:PE3>config>router>isis# interface "system" flex-algo 129 ipv4-node-sid index 53

A:PE3>config>router>isis# info

            interface "system"

                level-capability level-2

                passive

                flex-algo 129

                    ipv4-node-sid index 53

                exit

                no shutdown

            exit

*A:PE2>conf>router>segment-routing# sr-mpls prefix-sids "system" no flex-algo 129

*A:PE2>conf>router>segment-routing#

*A:PE2>conf>router>segment-routing#

*A:PE2>conf>router>segment-routing# /co

configure  compare

*A:PE2>conf>router>segment-routing# /conrouter is

                                   ^

Error: Bad command.

*A:PE2>conf>router>segment-routing# /configure router isis 1

*A:PE2>config>router>isis# interface "system" flex-algo      

<[128..255]>

*A:PE2>config>router>isis# interface "system" flex-algo 129  

ipv4-node-sid   ipv6-node-sid

*A:PE2>config>router>isis# interface "system" flex-algo 129 ipv4-node-sid index 52

After swapping the flex-algo index from shared sid to system interface under isis. Route-table is populated with routes. Output below

A:PE5# show router tunnel-table

 

===============================================================================

IPv4 Tunnel Table (Router: Base)

===============================================================================

Destination           Owner     Encap TunnelId  Pref   Nexthop        Metric

   Color                                                             

-------------------------------------------------------------------------------

1.0.0.1/32 [L]        isis (1)  MPLS  524359    11     10.1.5.1       10

1.0.0.2/32 [L]        isis (1)  MPLS  524372    11     10.1.5.1       20

1.0.0.2/32            isis (1)  MPLS  524379    11     10.5.6.6       18000


















From below output we need to fix the PE4 to advertise the flex algo 129 route properly


















After remapping the flex-algo node index under the ISIS context, now we see tunnel table entries separately for algo 0 and algo 129.








Steering traffic using an auto-bind tunnel, or we can use the Flex algorithm label used for 129 under path in SR-TE.

Let's use an auto-bind tunnel via VPRN service and make it work end to end to use flex-algo for VPRN traffic









Now we can see that for the PE3 destination, we have SR-ISIS flex-algo 129 tunnel based on delay installed.






Tuesday, March 3, 2026

Implementing BGP-Signaled SR Policy on Nokia 7750 SR

In the previous post, we discussed the SR-Static policy on the local router. Do we have the option to create a policy and advertise to other routers in the network? Then yes, it is possible to send the SR policy from the centralized controller or from the SR-OS routers within the network.

Let’s configure and advertise the SR policy from ASBR1 using BGP for PE3 to PE5.

It’s like the previous configuration, but the only difference is we mention the headend router ip address of PE3.

PE3 to PE5 SR policy

Enabling the sr-policy ipv4 in bgp family and importing the sr-policy, the sr-policy-import command in bgp allows the static policy to be advertised in BGP except for the local policy.

Enabling the sr-policy-ipv4 family under BGP neighbors

SR-policy advertisement from ASBR1

BGP advertisement of SR policy

PE3 to PE6 sr-policy verification


LSP trace confirms the traffic via the sr-policy path


SR-Policy Route installed in the tunnel table


PE5: Adding color to the route advertisement from PE5 to PE3



Add the policy in VPRN import/export policy

We can see the PE5 adding the color while advertising the routes to PE3


SR-policy applied for the route towards PE5 

Ping between PE3 and PE5 via SR policy