Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.

  • 1.  PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 04-24-2023 06:19

    Good day! I have been working on implementing PCE-initiated LSPs on Juniper PCC from a Cisco PCE for a SR-MPLS based network with multiple domains. It is working good, but for an unknown reason the color attribute of the SRTE tuple is not taken by the Juniper PCC. I have tried with Cisco PCC and it accepts the color as an attribute of the SRTE policy.

    From debugs, I don't see any clue about the reason of this issue. So I would like to ask first, if color is supported as an attribute of the srte tuple that can be received from the PCE, and second if there is anything that requires to be enabled in the PCC in order to accept this attribute.

    #PCEP 
    pce pccd {
        local-address 1.1.1.1;
        destination-ipv4-address 100.200.100.200;
        destination-port 4189;
        pce-type active stateful;
        lsp-provisioning;
        spring-capability;
    }

    #PCEP message received on PCC
    Mar 30 23:27:49.337245 [229] pccd_rpd_debug_lsp_info(): rx pcreq name(PCE-LATENCY) path() template() is src dest ipv6(0) src(1.1.1.1) dst(2.1.1.1) msg_trigger() type(3) state(1) control(1) flags(0x0) admin grp exclude(0) admin grp include any(0) admin grp include all(0) setup prio(0) hold prio(0) bw(0bps) metric(3100) binding type (0) binding value (0)

    It shows other attributes but not the srte color.

    #PCEP (Last line shows the color attribute)
    RP/0/RP0/CPU0:Mar 31 00:06:05.138 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_tx_msg:808 Sending Initiate to 1.1.1.1.
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9450 Size with SRP: 20
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9482 Size after adding LSP: 68
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9497 Size after adding EP: 80
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9503 Size after adding vendor-info: 104
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9517 Size after adding ASSO: 104
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9540 Size after adding ERO: 188
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9547 Size after adding metric: 200
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9902 *** ST 3, sr_ero_subobj_size = 16
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9902 *** ST 3, sr_ero_subobj_size = 16
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9902 *** ST 3, sr_ero_subobj_size = 16
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9902 *** ST 3, sr_ero_subobj_size = 16
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_send_initiate_msg:9902 *** ST 3, sr_ero_subobj_size = 16
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_add_vendor_object:8041 Added Vendor ID: 9
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_add_color_tlv:7904 Added COLOR TLV header: color: 10
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_add_preference_tlv:7930 Added PREFERENCE TLV header: preference: 100
    RP/0/RP0/CPU0:Mar 31 00:06:05.139 UTC: pce_server[1143]: DBG-PCEP:[139836093351680] pce_add_vendor_object:8051 Added vendor obj Vendor-id:9, color:10, preference:100

    Hope someone can help me to clarify this behaviour.

    Thanks!
    Willy



    ------------------------------
    WILLY MEIER
    ------------------------------


  • 2.  RE: PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 04-24-2023 13:56

    Hello Willy,

    I have experienced the same behavior and found the following in the documentation:
    https://www.juniper.net/documentation/en_US/junos/topics/reference/general/release-notes/20.1/infocus-topicmaps/infocus-pcep-for-spring-te.html

    Segment Routing for PCEP Limitations and Unsupported Features

    The support of segment routing for PCEP does not add any additional performance burden on the system; however, it has the following limitations:

    PCE-delegated LSPs does not support the following:

    • Colored SR-TE LSPs
    • IPv6 LSPs
    • Secondary segment list of source-routing-path. Only one path of the segment list can be delegated.
    • Multi-segment standard. Only one segment list must be present in the candidate path.



    Maybe it will be supported in future releases.

    Regards
    Peter



    ------------------------------
    Peter Weymann
    ------------------------------

    Original Message


  • 3.  RE: PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 04-25-2023 06:35

    Sorry, I just saw that this references a limitation of PCE-delegated LSPs and not PCE-initated LSPs. I have also tested PCE-delegated LSPs using dynamic tunnels in 22.4R1 and it works with using colors but the color definition is configured locally. For PCE-initiated LSPs, as I wrote, I see the same limitation as you have mentioned. Nevertheless I have my doubts that it is supported to use the color definition coming from the PCE for initated LSPs at the moment.



    ------------------------------
    Peter Weymann
    ------------------------------

    Original Message


  • 4.  RE: PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 04-25-2023 10:25

    Hi Peter,
    Yes, the documentation only mentions PCE-delegated but it seems that is not supported as well for PCE-initiated LSPs. I found out from a Cisco Community that it seems to be a vendor specific object, not required to be supported to be aligned to the standards. If I find out anything else I will let you know.
    Thanks for your help!
    Regards,
    Willy



    ------------------------------
    WILLY MEIER
    ------------------------------

    Original Message


  • 5.  RE: PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 05-21-2023 23:46

    Hi Peter,
    One additional question. Have you tried install-nexthop as an alternative way to steer traffic to a specific SRTE LSP received from the PCE?  AS there is not support for colours, I was wondering if there was a way to resolve to a specific based on a community.
    Thanks,
    Willy



    ------------------------------
    WILLY MEIER
    ------------------------------

    Original Message


  • 6.  RE: PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 05-23-2023 11:39

    Hi Willi,

    I have tested it because you made me curious with your question ;-)
    The outcome was a bit disillusioning in my opinion. The reason is that the mapping to PCE-inititad LSPs using install-nexthop lsp-regex works only if the intended SRTE LSPs and other available LSPs are of equal cost. For testing, I configured two additional static SRTE LSPs to check whether the mapping really works and to my surprise it will not use the PCE-initiated LSPs afterwards because it has a worse "tunnel source preference". Static configuration as the tunnel source is prefered over PCEP. Nevertheless, I decided to test a "nasty" workaround by applying a multipath policy to inet.3 that allows to take all SPRING-TE LSPs into account. Afterwards a multipath entry using both the static SRTE and the PCE-initiated SRTE was available in the inet.3, which in turn allowed the mapping of the VPN route to the PCE-initated LSPs. IMHO I wouldn't see such a configuration as valid option in a productive environment.

    Here are some outputs from the lab router:

    set routing-options rib inet.3 policy-multipath policy SPF-TE-LB

    set policy-options policy-statement SPF-TE-LB term 1 from protocol spring-te
    set policy-options policy-statement SPF-TE-LB term 1 then accept

    set policy-options policy-statement C-SRTE term 0 from community COLOR-128
    set policy-options policy-statement C-SRTE term 0 then install-nexthop strict
    set policy-options policy-statement C-SRTE term 0 then install-nexthop lsp-regex SRTE-R*
    set policy-options policy-statement C-SRTE term 0 then next policy
    deactivate policy-options policy-statement C-SRTE term 0
    set policy-options policy-statement C-SRTE term 1 from community COLOR-128
    set policy-options policy-statement C-SRTE term 1 then install-nexthop strict
    set policy-options policy-statement C-SRTE term 1 then install-nexthop lsp-regex PCE-POL-1_R*
    set policy-options policy-statement C-SRTE term 1 then next policy


    pweymann@r6> show path-computation-client lsp

      Name                                Status            PLSP-Id  LSP-Type       Controller       Path-Setup-Type       Template
      SRTE-R4                             (Act)             53       local          -                spring-te
      SRTE-R5                             (Act)             54       local          -                spring-te
      PCE-POL-1_R4                        (Act)             55       ext-provised   R9               spring-te
      PCE-POL-1_R5                        (Act)             56       ext-provised   R9               spring-te


    pweymann@r6> show route table inet.3 192.168.0.4 protocol spring-te

    inet.3: 8 destinations, 23 routes (8 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both

    192.168.0.4/32     *[SPRING-TE/8] 00:18:08, metric 1, metric2 16777215
                        >  to 192.168.1.33 via xe-0/0/1.0, Push 16004, Push 16003, Push 24(top)<<< SRTE-R4
                        [SPRING-TE/8] 00:17:57, metric 0, metric2 16777215
                        >  to 192.168.1.33 via xe-0/0/1.0, Push 16004, Push 16003, Push 16002(top)<<< PCE-POL-1_R4

    pweymann@r6> show route table inet.3 192.168.0.5 protocol spring-te

    inet.3: 8 destinations, 23 routes (8 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both

    192.168.0.5/32     *[SPRING-TE/8] 00:18:12, metric 1, metric2 16777215
                        >  to 192.168.1.33 via xe-0/0/1.0, Push 16005, Push 16007, Push 24(top)<<< SRTE-R5
                        [SPRING-TE/8] 00:18:01, metric 0, metric2 16777215
                        >  to 192.168.1.33 via xe-0/0/1.0, Push 16005, Push 16007, Push 16002(top)<<< PCE-POL-1_R5

    pweymann@r6> show route table inet.3 protocol multipath

    inet.3: 8 destinations, 23 routes (8 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both

    192.168.0.4/32      [Multipath/8] 00:07:32, metric 16777215
                           to 192.168.1.33 via xe-0/0/1.0, Push 16004, Push 16003, Push 24(top)
                        >  to 192.168.1.33 via xe-0/0/1.0, Push 16004, Push 16003, Push 16002(top)
    192.168.0.5/32      [Multipath/8] 00:07:32, metric 16777215
                           to 192.168.1.33 via xe-0/0/1.0, Push 16005, Push 16007, Push 24(top)
                        >  to 192.168.1.33 via xe-0/0/1.0, Push 16005, Push 16007, Push 16002(top)

    pweymann@r6> show route table VRF1 111.111.111.109

    VRF1.inet.0: 4 destinations, 10 routes (4 active, 0 holddown, 0 hidden)
    @ = Routing Use Only, # = Forwarding Use Only
    + = Active Route, - = Last Active, * = Both

    111.111.111.109/32 @[BGP/170] 00:06:30, localpref 100, from 192.168.0.1
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16004, Push 16003, Push 16002(top)
                        [BGP/170] 00:06:30, localpref 100, from 192.168.0.8
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16004, Push 16003, Push 16002(top)
                        [BGP/170] 00:06:30, localpref 100, from 192.168.0.1
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16005, Push 16007, Push 16002(top)
                        [BGP/170] 00:06:30, localpref 100, from 192.168.0.8
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16005, Push 16007, Push 16002(top)
                       #[Multipath/255] 00:06:30, metric2 16777215
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16004, Push 16003, Push 16002(top)
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16005, Push 16007, Push 16002(top)

    pweymann@r6> show route forwarding-table table VRF1 destination 111.111.111.109
    Routing table: VRF1.inet
    Internet:
    Destination        Type RtRef Next hop           Type Index    NhRef Netif
    111.111.111.109/32 user     0                    ulst  1048576     2
                                                     indr  1048574     3
                                  192.168.1.33      Push 17, Push 16004, Push 16003, Push 16002(top)      609     2 xe-0/0/1.0
                                                     indr  1048575     3
                                  192.168.1.33      Push 17, Push 16005, Push 16007, Push 16002(top)      610     2 xe-0/0/1.0


    When I set the install-nexthop to the LSPs named SRTE-R*, than the underlaying LSPs changes accordingly:

    pweymann@r6# show | compare
    [edit policy-options policy-statement C-SRTE]
    !     active: term 0 { ... }
    !     inactive: term 1 { ... }

    [edit]
    pweymann@r6# commit
    commit complete

    [edit]
    pweymann@r6# exit
    Exiting configuration mode

    pweymann@r6> show route table VRF1 111.111.111.109

    VRF1.inet.0: 4 destinations, 10 routes (4 active, 0 holddown, 0 hidden)
    @ = Routing Use Only, # = Forwarding Use Only
    + = Active Route, - = Last Active, * = Both

    111.111.111.109/32 @[BGP/170] 00:00:05, localpref 100, from 192.168.0.1
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16004, Push 16003, Push 24(top)
                        [BGP/170] 00:00:05, localpref 100, from 192.168.0.8
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16004, Push 16003, Push 24(top)
                        [BGP/170] 00:00:05, localpref 100, from 192.168.0.1
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16005, Push 16007, Push 24(top)
                        [BGP/170] 00:00:05, localpref 100, from 192.168.0.8
                          AS path: I, validation-state: unverified
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16005, Push 16007, Push 24(top)
                       #[Multipath/255] 00:00:05, metric2 16777215
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16004, Push 16003, Push 24(top)
                           to 192.168.1.33 via xe-0/0/1.0, Push 17, Push 16005, Push 16007, Push 24(top)


    pweymann@r6> show route forwarding-table table VRF1 destination 111.111.111.109
    Routing table: VRF1.inet
    Internet:
    Destination        Type RtRef Next hop           Type Index    NhRef Netif
    111.111.111.109/32 user     0                    ulst  1048579     2
                                                     indr  1048577     3
                                  192.168.1.33      Push 17, Push 16004, Push 16003, Push 24(top)      611     2 xe-0/0/1.0
                                                     indr  1048578     3
                                  192.168.1.33      Push 17, Push 16005, Push 16007, Push 24(top)      612     2 xe-0/0/1.0


    Really an interesting topic, but full of pitfalls and contraints. Not sure if this helps you.

    Regards,
    Peter



    ------------------------------
    Peter Weymann
    ------------------------------

    Original Message


  • 7.  RE: PCE-initiated coloured LSPs from a Cisco PCE to Juniper PCC

    Posted 05-26-2023 07:21

    Hi Peter,
    Thanks for taking the time to test it, I was checking it in my lab. Yeah I think it's better to wait for the color support as part of the srte tuple.  I have confirmed that is still not supported but will be supported in the future. Anyway I tried PCC-init LSPs using a Cisco PCE for a dual domain network and it partially worked. I saw some errors in the debug and it seems that the PCE couldn't recognize some parameters and responded to the PCC with the same LSP for paths with different metric type requirements igp|te|latency. For all of them it seems to be responding as if the request was for TE metric type. Thanks! Willy



    ------------------------------
    WILLY MEIER
    ------------------------------

    Original Message