Arista EOS Segment Routing (3) - SR Routing #1, Static Route + NHG

The Arista MPLS Segment Routing White Paper(Page 8) lists 4 SR routing solutions:
1) Static label push via NHG
2) Controller via EOS SDK
3) BGP LU with SR
4) SR-TE

This blog gives an example of solution #1. 



The configuration is straightforward:

• Instead of running a routing protocol between PE1 and PE2, a static route of remote destination (100.255.4.1/32 on PE1) is configured and pointing to NHG. 
• The NHG defines:
• MPLS encapsulation
• Push a label of 900004
• The NH is 10.1.2.2 for out-interface and destination MAC. 
• Obviously, 2 NHGs are needed to 2 way traffic. 
• Not like the regular NHG setup, decap group is NOT needed. 
• P1 and P2 have no idea of destination ip - 100.255.4.1, but use label to forward traffic

PE1#sh ip route 100.255.4.1

VRF: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,

       R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,

       O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route, V - VXLAN Control Service,

       DH - DHCP client installed default route, M - Martian,

       DP - Dynamic Policy Route, L - VRF Leaked

 NG       100.255.4.1/32 [1/0] via sr-1-push-label-900004, Nexthop Group ID 1

The output of tcpdump on P2's et42/4 (the interface facing to P1) shows MPLS with the correct label in both directions. 

23:10:17.713412 44:4c:a8:97:84:5f > 44:4c:a8:97:8c:51, ethertype MPLS unicast (0x8847), length 118: MPLS (label 900001, exp 0, [S], ttl 63)

(tos 0x0, ttl 64, id 6381, offset 0, flags [none], proto ICMP (1), length 100)

    100.255.4.1 > 100.255.1.1: ICMP echo request, id 9258, seq 5, length 80

23:10:17.713473 44:4c:a8:97:8c:51 > 44:4c:a8:97:84:5f, ethertype MPLS unicast (0x8847), length 118: MPLS (label 900004, exp 0, [S], ttl 63)

(tos 0x0, ttl 64, id 2480, offset 0, flags [none], proto ICMP (1), length 100)

    100.255.1.1 > 100.255.4.1: ICMP echo reply, id 9258, seq 5, length 80 

Now you have the simplest, but completed ISIS segment-routing solution, control plane + data plane :-) In the real network, you can complete the puzzle by adding, 

• Have a controller participate in the ISIS domain via the ISIS over GRE tunnel. 
• As an ISIS neighbor, it can fetch the full ISIS LSDB to have a global view of the network including the segment. 
• Then it can program the edge router vi CLI/capi to steer the traffic. Or use the EOS SDK for faster program speed (this is the solution #2)