Monday 9 October 2017

Segment Routing TE

Recently the company that i work(changed job again ) for has roll out segment routing. This is still limited to 7 countries.

Next step for us is to look into PCEP-SR/BGP-LU/and SR-TE ( this post ). We don't have loots of rsvp-te tunnels, ~90 or so, 70% used for igp-shortcuts uneaqul load balancing and rest for services ( some customers want to go via a specific subsea cable , for some reason :) ).

We don't have a controller , and probably never will... and it's going to be a while while the segment features are present in all 3 vendors( that we use).

Anywho this is about SR-TE ... what it supposed to do and current implementation on JNP.

SR-TE is defined in:
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-00 ;

Mapping traffic over this is defined :
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-01;

JNP implementation of SR-TE is not there , so end of blogpost.... What they do have at this stage , is a static SR feature.
This means instead of learning the SR policy via BGP ( and help me crete a proper post ) the current implementation is static for now...

In terms of mapping traffic onto the SR ( draft-filsfils-spring-segment-routing-policy-01) this is fine , at least the use case below.


Topology



vmx8->10.11.11.11/32 follows the spf ; xrv2->xrv1
Label traffic is SR-based ; top-most label 800001

root@vmx8> show route 10.11.11.11

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

10.11.11.11/32     *[BGP/170] 00:00:00, MED 0, localpref 100, from 10.1.1.1
                      AS path: I, validation-state: unverified
                    > to 10.2.8.2 via ge-0/0/0.0, Push 800001

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

10.1.1.1/32        *[L-ISIS/14] 00:03:29, metric 20
                    > to 10.2.8.2 via ge-0/0/0.0, Push 800001

root@vmx8> traceroute 10.11.11.11
traceroute to 10.11.11.11 (10.11.11.11), 30 hops max, 52 byte packets
 1  10.2.8.2 (10.2.8.2)  116.892 ms  2.880 ms  2.667 ms
     MPLS Label=800001 CoS=0 TTL=1 S=1
 2  10.1.2.1 (10.1.2.1)  4.990 ms *  4.668 ms

The goal is to create an SR-TE policy so that traffic flows vmx8->xrv2-xrv5>xrv3->xrv1. Ideally this would have been created by BGP SR-TE,
but that is not working in the current code ... so let's do it static.

set protocols source-packet-routing segment-list sr-te_to_xrv1 xrv5 label 800005
set protocols source-packet-routing segment-list sr-te_to_xrv1 xrv3 label 800003
set protocols source-packet-routing segment-list sr-te_to_xrv1 xrv1 label 800001

set protocols source-packet-routing source-routing-path to_xrv1 to 10.1.1.1
set protocols source-packet-routing source-routing-path to_xrv1 color 0
set protocols source-packet-routing source-routing-path to_xrv1 primary sr-te_to_xrv1

What this does is , create the SR-TE with a label stack of 3, the next hop label is not needed.

root@vmx8> show spring-traffic-engineering lsp         
To              State     LSPname
10.1.1.1-0<c>   Up        to_xrv1

the -0<c> is really important. This is the color of the tunnel... this as this as SLA agreement. In fact let create another one with different color. The 10.1.1.1 is the end-point , matching the next-hop of the ipv4 unicast route.

This time is xrv2-xrv5-xrv2-xrv1

set protocols source-packet-routing segment-list sr-te_to_xrv1#2 xrv5 label 800005
set protocols source-packet-routing segment-list sr-te_to_xrv1#2 xrv2 label 800002
set protocols source-packet-routing segment-list sr-te_to_xrv1#2 xrv1 label 800001

set protocols source-packet-routing source-routing-path to_xrv1#2 to 10.1.1.1
set protocols source-packet-routing source-routing-path to_xrv1#2 color 10
set protocols source-packet-routing source-routing-path to_xrv1#2 primary sr-te_to_xrv1#2

As expected :

root@vmx8> show spring-traffic-engineering lsp
To              State     LSPname
10.1.1.1-0<c>   Up        to_xrv1
10.1.1.1-10<c>  Up        to_xrv1#2

root@vmx8> show route table inetcolor.0

inetcolor.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.1.1-0<c>/64             
                   *[SPRING-TE/8] 00:08:58, metric 1, metric2 20
                    > to 10.2.8.2 via ge-0/0/0.0, Push 800001, Push 800003, Push 800005(top)
10.1.1.1-10<c>/64             
                   *[SPRING-TE/8] 00:08:58, metric 1, metric2 20
                    > to 10.2.8.2 via ge-0/0/0.0, Push 800001, Push 800002, Push 800005(top)


Now , one of the method to inject traffic into the SR-TE is to color a destination prefix. So let's do just that. I'm using yabgp to insert
the bgp route.

the json it's below:

{
    "attr": {
    "1": 0,
    "2": [[2, []]],
    "3": "10.1.1.1",
    "5": 200,
        "8": ["NO_ADVERTISE"],
        "16": [[779, 0]]
    },
    "nlri":["10.11.11.11/32"]
}

Test 1:
Advertise 10.11.11.11/32 with next-hop 10.1.1.1 and with extended community 779 (BGP_EXT_COM_COLOR = 0x030b) with value 0.

root@vmx8> show route 10.11.11.11

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

10.11.11.11/32     *[BGP/15] 00:00:06, localpref 200, from 10.97.97.2
                      AS path: I, validation-state: unverified
                    > to 10.2.8.2 via ge-0/0/0.0, Push 800005
                    [BGP/170] 00:01:56, MED 0, localpref 100, from 10.1.1.1
                      AS path: I, validation-state: unverified
                    > to 10.2.8.2 via ge-0/0/0.0, Push 800001

root@vmx8> ...32 extensive | match "color|Protocol next hop"               
                Protocol next hop: 10.1.1.1-0<c>
                Communities: no-advertise color:0:0

As expected route is received with corect color , and the next hop is the SR-TE policy.

Traceroute :

root@vmx8> traceroute 10.11.11.11
traceroute to 10.11.11.11 (10.11.11.11), 30 hops max, 52 byte packets
 1  10.2.8.2 (10.2.8.2)  99.071 ms  215.040 ms  6.419 ms
     MPLS Label=800005 CoS=0 TTL=1 S=0
     MPLS Label=800003 CoS=0 TTL=1 S=0
     MPLS Label=800001 CoS=0 TTL=1 S=1
 2  10.2.5.5 (10.2.5.5)  5.144 ms  4.763 ms  4.597 ms
     MPLS Label=800003 CoS=0 TTL=1 S=0
     MPLS Label=800001 CoS=0 TTL=2 S=1
 3  10.3.5.3 (10.3.5.3)  4.751 ms  4.642 ms  4.752 ms
     MPLS Label=800001 CoS=0 TTL=1 S=1
 4  10.1.3.1 (10.1.3.1)  4.762 ms *  44.309 ms

Test 2:
Advertise 10.11.11.11/32 with next-hop 10.1.1.1 and with extended community 779 (BGP_EXT_COM_COLOR = 0x030b) with value 10.


{
    "attr": {
    "1": 0,
    "2": [[2, []]],
    "3": "10.1.1.1",
    "5": 200,
        "8": ["NO_ADVERTISE"],
        "16": [[779, 10]]
    },
    "nlri":["10.11.11.11/32"]
}

root@vmx8> ...extensive | match "Communities|Protocol next hop"             
                Protocol next hop: 10.1.1.1-10<c>
                Communities: no-advertise color:0:10

root@vmx8> traceroute 10.11.11.11
traceroute to 10.11.11.11 (10.11.11.11), 30 hops max, 52 byte packets
 1  10.2.8.2 (10.2.8.2)  6.217 ms  5.156 ms  4.686 ms
     MPLS Label=800005 CoS=0 TTL=1 S=0
     MPLS Label=800002 CoS=0 TTL=1 S=0
     MPLS Label=800001 CoS=0 TTL=1 S=1
 2  10.2.5.5 (10.2.5.5)  4.722 ms  4.470 ms  4.569 ms
     MPLS Label=800002 CoS=0 TTL=1 S=0
     MPLS Label=800001 CoS=0 TTL=2 S=1
 3  10.2.5.2 (10.2.5.2)  4.681 ms  4.500 ms  4.715 ms
     MPLS Label=800001 CoS=0 TTL=1 S=1
 4  10.1.2.1 (10.1.2.1)  4.806 ms *  9.379 ms

No comments:

Post a Comment