Segment routing for traffic engineering (SR-TE) uses a SR policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list or it can be defined as next hop prefix-sid too. Each segment is an end-to-end path from the source to the destination and implemented on headend node only. SR-TE policy instructs the headend routers to program the specified path instead of following the path calculated by the IGP. If packet is steered into an SR-TE policy, the SID list is pushed on the packet by the head-end and rest of the network executes it.

Let’s understand how ODN works?
Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required. SR-ODN works by encoding the intent as a BGP color extended community at the egress PE (PE who is advertising routes); the ingress PE(receiver or headend) is pre-configured with an ODN template that provides the node with the steps to follow in case a route with the intended color appears.

SR-ODN automates the instantiation of SR-TE policy without the need of SDN controller as the template has to be locally configured on headend router. If you are having SDN controller installed, in that case PCEP can be leverage for the dynamic instantiation of SR-ODN. In our topology, as soon as L4 received VPNv4 color route from PE7; L4 automattically instantiate locally configured ODN template on L4. Now the selected candidate path will be ODN instantiated path.

Another concept is of Binding SID which may be defined by candidate path. Binidng SID is also known as BSID also. The Binding SID (BSID) is fundamental to Segment Routing and provides scaling, network opacity and service independence. (Excerpt from Segment Routing Policy for Traffic Engineering). BSID can be locally configured on router with SID-Lists attached to it or headend node can allocate BSID locally from the SRGB block too. A valid SR Policy installs a BSID entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the SR Policy.

Traffic Steering into an SR Policy A headend can steer a packet flow into a valid SR Policy in various ways: o Incoming packets have an active SID matching a local BSID at the head-end. o Per-destination Steering: incoming packets match a BGP/Service route which recurses on an SR policy. [We will be testing this scenario) o Per-flow Steering: incoming packets match or recurse on a forwarding array of where some of the entries are SR Policies. o Policy-based Steering: incoming packets match a routing policy which directs them on an SR policy. For demo purpose, we will be using the below topology. Network slicing is already configured as per the earlier post “Deploy Network Slice By Using Flex-Algo”. Now the next step is to color the VRF test VPNv4 prefix on router from PE7. On PE4, create ODN template, match color and steer the traffic into ODN instantiated candidate path.

Look at the output of vrf test, this is vpnv4 prefixes received by L3 and PE7.

RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf test)
*>i100.0.0.3/32 3.3.3.3 0 100 0 ?
*> 100.0.0.4/32 0.0.0.0 0 32768 ?
*>i100.0.0.7/32 7.7.7.7 0 100 0 ?

M/br>Configure PE7 with below given configuration. vrf TEST (100.0.0.7 router) is exporting color128 to RR and RR is further sending the same to the respective PEs.

vrf test
address-family ipv4 unicast
export route-policy SET_COLOR_128
!
!
!
extcommunity-set opaque color128 128 end-set
!
route-policy SET_COLOR_128
set extcommunity color color128
pass end-policy
!

Now check whether we are receiving color128 as extended community on L4 node by issuing the following command. Few points to check, extended community with 100:100 ; Color:128 is also added. Received label is 24009.

RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test 100.0.0.7/32
BGP routing table entry for 100.0.0.7/32, Route Distinguisher: 100:100
Local
7.7.7.7 (metric 40) from 8.8.8.8 (7.7.7.7)
Received Label 24009
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 36
Extended community: Color:128 RT:100:100
Originator: 7.7.7.7, Cluster list: 8.8.8.8
Source AFI: VPNv4 Unicast, Source VRF: test, Source Route Distinguisher: 100:100
RP/0/0/CPU0:L4#

RP/0/0/CPU0:L4#show bgp vpnv4 unicast vrf test (Check that 100.0.0.7 is receiving with C:128)
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf test)
*>i100.0.0.3/32 3.3.3.3 0 100 0 ?
*> 100.0.0.4/32 0.0.0.0 0 32768 ?
*>i100.0.0.7/32 7.7.7.7 C:128 0 100 0 ?

Below is the CEF output of vrf test 100.0.0.7/32, which shows that 24009 is vpnv4 label and 16007 is prefix-sid label of PE7. Remember the prefix-sid label as this will change once we apply ODN and it will use underneath flex-algo(128) as network slice which we created in earlier post.

RP/0/0/CPU0:L4#show cef vrf test 100.0.0.7/32
100.0.0.7/32, version 24, internal 0x5000001 0x0 (ptr 0xa14165d0) [1], 0x0 (0x0), 0x208 (0xa1757268)
Updated May 1 09:52:29.665
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 7.7.7.7/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa17cc058 0x0]
recursion-via-/32
next hop VRF – ‘default’, table – 0xe0000000
next hop 7.7.7.7/32 via 16007/0/21
next hop 2.4.0.2/32 Gi0/0/0/1 labels imposed {16007 24009}
RP/0/0/CPU0:L4#