Routing

 View Only

Segment Routing | Service Route Allocation Across Multiple SR-TE LSPs

  • 1.  Segment Routing | Service Route Allocation Across Multiple SR-TE LSPs

    Posted 09-05-2025 19:19

    HI 

    I have an SR-TE D-CSPF setup, and between PE10 and PE4 I see two computed LSPs. In the inet.3 table, both LSPs are active.

    When I check the service routes learned from PE4, I notice that some prefixes are allocated to one LSP while others are using the second computed LSP. and the allocation is unequal. 

    Is this the expected behavior? Is there a configuration control knob to distribute service prefixes between the LSPs equally? If not, then there will not be equal load sharing among the links, correct?

    topology 

    PE10----P9-----P7----P3----PE4

                        |                             |

                         |-------P2-----|

    LSP via P7 is Green-path and P2 is RED path 

    PE10#

    set protocols source-packet-routing compute-profile green-path admin-group include-all GREEN
    set protocols source-packet-routing compute-profile red-path admin-group include-all RED
    set protocols source-packet-routing source-routing-path PE10-PE4 to 105.16.0.4
    set protocols source-packet-routing source-routing-path PE10-PE4 primary green-path compute green-path
    set protocols source-packet-routing source-routing-path PE10-PE4 primary red-path compute red-path

    root@PE10# run show route 105.16.0.4 table inet.3 
    --
    105.16.0.4/32      *[SPRING-TE/8] 00:12:31, metric 1, metric2 40
                           to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802002(top)
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
                        [L-ISIS/14] 2d 10:16:39, metric 40
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 802004
    root@PE10# run show route next-hop 105.16.0.4 | except val    
     
    inet.0: 53 destinations, 54 routes (53 active, 0 holddown, 0 hidden)
    20.2.0.150/32      *[BGP/170] 00:32:32, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802002(top)
    20.2.0.151/32      *[BGP/170] 00:32:32, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802002(top)
    20.2.0.152/32      *[BGP/170] 00:21:39, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.153/32      *[BGP/170] 00:21:39, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.154/32      *[BGP/170] 00:21:39, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.155/32      *[BGP/170] 00:21:39, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.156/32      *[BGP/170] 00:39:13, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.157/32      *[BGP/170] 00:21:39, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.158/32      *[BGP/170] 00:39:13, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)
    20.2.0.159/32      *[BGP/170] 00:39:13, localpref 100, from 105.16.0.8
                        >  to 11.19.10.9 via ge-0/0/0.0, Push 2020, Push 802007(top)


    ------------------------------
    Johnson V C
    ------------------------------