Routing

Expand all | Collapse all

SPRING: extended-nexthop-color for inet[6]-vpn AF

Jump to Best Answer
  • 1.  SPRING: extended-nexthop-color for inet[6]-vpn AF

    Posted 10-03-2019 08:09

    Hi,

    Does aybody know when extended-nexthop-color will be supported for inet-vpn/inet6-vpn address families?

    I just checked on: Model: vmx Junos: 19.3R1.8 but it wasn't there.

    thanks


    doc for inet/inet6: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/extended_nexthop_colorr_edit_protocols_bgp_family_inet.html


    #Spring
    #srte


  • 2.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF

     
    Posted 10-03-2019 09:08

    It seems not yet support on any existing junos for vpn both ipv4 and ipv6. 

     

    [edit logical-systems name protocols bgp family inet |inet6 unicast],
    [edit logical-systems name protocols bgp group name family inet | inet6 unicast],
    [edit logical-systems name protocols bgp group name neighbor name family inet |inet6 unicast],
    [edit protocols bgp family inet |inet6 unicast],
    [edit protocols bgp group name family inet | inet6 unicast],
    [edit protocols bgp group name neighbor name family inet |inet6 unicast],
     
    Is there any RFC you are referring to for this requirement? If there's a use case, I suggest you to work with your local system engineer to rasie an Enhancement Request with Juniper 


  • 3.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF
    Best Answer

    Posted 10-03-2019 12:12

    Hello,

    "inet[6]-vpn" NLRI resolution over colored SRTE LSP is done differently, You need to configure a resolution-map and reference it in VRF import policy

    https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/resolution-map-edit-policy-options.html

    https://www.juniper.net/documentation/en_US/junos/topics/concept/color-based-mapping-of-vpn-services-overview.html

    And if You have 2 or more equal-cost colored SRTE LSP, You need to configure "multipath-resolve" policy as well (see the second link above)

    HTH

    Thx

    Alex



  • 4.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF

    Posted 10-09-2019 02:04

    Hello @aarseniev,

    thank you for pointing me to correct documentation. I manged to configure inet[6]-vpn NLRI resolution based on color.

    I have just one more question if you don't mind.

    Now I'm trying to configure dynamic creation of SRTE path. I already tried multiple combinations but it seems I always have to provide some primary segment-list for temlate which requires to define a least one hop.

    This seems to me very weird as endpoint is taken from protocol next hop so I don't understand why do I have to define any intermediate hop.

    Also do you happend to know if there is similar feature to SR ODN implemented by Cisco IOSXR? I haven't been able to find anything in public doc.

     

    # show routing-options dynamic-tunnels | display set 
    set routing-options dynamic-tunnels SRTE-DYN spring-te source-routing-path-template SRTE-DYN-TEMPLATE color 20
    set routing-options dynamic-tunnels SRTE-DYN spring-te destination-networks 10.0.0.0/24
    
    # show protocols source-packet-routing | display set                
    set protocols source-packet-routing segment-list SR-LIST-PRIMARY inherit-label-nexthops
    set protocols source-packet-routing segment-list SR-LIST-PRIMARY dynamic
    set protocols source-packet-routing segment-list SR-LIST-PRIMARY nh ip-address 10.0.0.4
    set protocols source-packet-routing segment-list SR-LIST-PRIMARY nh label-type node
    set protocols source-packet-routing source-routing-path-template SRTE-DYN-TEMPLATE primary SR-LIST-PRIMARY


  • 5.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF

    Posted 10-09-2019 02:42

    Hello,

     


    @patrickh wrote:

     

    I have just one more question if you don't mind.

     

    I actually counted 3 but never mind Smiley Happy

     

     


    @patrickh wrote:

     

    Now I'm trying to configure dynamic creation of SRTE path. I already tried multiple combinations but it seems I always have to provide some primary segment-list for temlate which requires to define a least one hop.

     

    Dynamic CSPF SRTE policies are supported from JUNOS 19.2R1-S1, make sure You run it.

     

    The colored SRTE policy with dynamic path, without any constraints, can be configured with "compute" knob as below:

     

    set protocols source-packet-routing source-routing-path SRP1 to 203.0.113.1
    set protocols source-packet-routing source-routing-path SRP1 color 203113 set protocols source-packet-routing source-routing-path SRP1 primary BLAH compute

     

    You only need to define a primary segment-list with hop-list when You need explicit routing along this segment-list and currently only loopbacks/router-ids are supported in such hop-list.

     


    @patrickh wrote:

     

    Also do you happend to know if there is similar feature to SR ODN implemented by Cisco IOSXR? I haven't been able to find anything in public doc.

     

    Cisco ODN has 2 flavors:

    1) ODN as described on www.segment-routing.net  landing page, it does NOT require BGP route injection - it explicitly says so
    2) ODN as described in this video from Cisco https://video.cisco.com/detail/videos/service-provider/video/5227897785001/on-demand-next-hop-odn?autoStart=true&page=10  and it DOES require BGP route injection.
    Juniper does not support ODN flavour #1.

    Juniper supports a feature similar to ODN flavor #2 - its is called "Dynamic creation of segment routing LSPs using BGP protocol next hops", see https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/19.2/jd0e4798.html#jd0e4874

     

    HTH

    Thx

    Alex



  • 6.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF

    Posted 10-09-2019 11:41

    Hello Alex,

    thanks for taking time to answer.

    As I mentioned in initial post, I'm testing this on vMX 19.3 so these features should be available.

    > show version 
    Model: vmx
    Junos: 19.3R1.8

    Dynamic policies are working, I had varios types of configuration and kind of missed that combination of tunnel-end + compute works too, thanks 🙂

     

    For ODN i'm interested in flavor #2 as you desscribed it. I read doc which you referenced before but based on that it's still not clear to me how configuration should be crafted, here are steps I followed:

    1) dyn tunnels are defined with/out color, SR PATH TEMPLATE and destination networks -> both mandatory argument

    [edit routing-options dynamic-tunnels]
    +    SRTE-ODN {
    +        spring-te {
    +            source-routing-path-template {
    +                SRTE-PATH-TEMPLATE color 22222;
    +            }
    +            destination-networks {
    +                10.0.0.0/24;
    +            }
    +        }
    +    }

    2) then SR TEMPLATE has to be defined with mandatory argument -> primary SR-LIST

    [edit protocols source-packet-routing]
    +    source-routing-path-template SRTE-PATH-TEMPLATE {
    +        primary {
    +            SRTE-LIST-ODN;
    +        }
    +    }

    3) last SR-LIST must be defined where <hop-list> is mandatory, dynamic only can't be used here

    [edit protocols source-packet-routing]
    +    segment-list SRTE-LIST-ODN {
    +        dynamic;
    +        ## Warning: missing mandatory statement(s): <hop-list>
    +    }

    I'm not sure what I'm missing here but for ODN triggered by BGP route I don't want to define explicit hops. even docs says dynamic LSP , so tunnel-end (BGP route NH) should be enough to compute dynamic LSP. Is this doc complete or have I missed something obvious?

    thanks



  • 7.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF

    Posted 10-10-2019 08:57

    Hello,

     


    @patrickh wrote:

    for ODN triggered by BGP route I don't want to define explicit hops. even docs says dynamic LSP , so tunnel-end (BGP route NH) should be enough to compute dynamic LSP. Is this doc complete or have I missed something obvious?

     


     

     

    I checked the funcspec for this feature and yes, You have to define at least 1 hop for the SRTE policy' outgoing interface to be resolved.

    This feature was developed with specific topology in mind (dual plane) so it was thought that for a given dynamic SRTE policy' its primary paths shall take RED plane and secondary path shall take BLUE plane, etc etc.

    Both BGP-triggered SRTE policies and CSPF-computed SRTE policies are not supported together, AFAIK.

    HTH

    Thx

    Alex

     



  • 8.  RE: SPRING: extended-nexthop-color for inet[6]-vpn AF

    Posted 10-10-2019 13:16

    Hi Alex,

    thank you for info you managed to provide.

    Hopefully missing features will be implemented in coming releases of Junos.