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.
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#
Apply the following configuration on L4 to enable ODN. SR-TE On Demand Next-Hop (ODN) feature can be used to steer the BGP traffic towards the Flexible Algorithm paths - Flex-Algo(128).
segment-routing
traffic-eng
on-demand color 128
dynamic
sid-algorithm 128
After applying above mentioned ODN configuration, we check the output how does ODN template behaves when receives route with color 128. SR policy color 128 can be seen on the last output. It also shows one important thing which is bsid: binding sid 24008. VPNv4 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
Versions:
Process bRIB/RIB SendTblVer
Speaker 57 57
Last Modified: May 1 10:14:32.836 for 00:00:46
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
7.7.7.7 C:128 (bsid:24008) (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 54
Extended community: Color:128 RT:100:100
Originator: 7.7.7.7, Cluster list: 8.8.8.8
SR policy color 128, up, registered, bsid 24008, if-handle 0x000000b0
RP/0/0/CPU0:L4#
Below output shows that BSID 24008 is having prefix SID which is 17007 and 17007 is apped to Flex Algo 128. So for traffic destined to 100.0.0.7 will follow the flex algo(128) path. Remeber from the above output before applying ODN, it was prefix sid of node which was 16007 but after ODN SRTE policy instantiation it changes to flex-algo(128) prefix sid which is 17007.
RP/0/0/CPU0:L4#show segment-routing traffic-eng policy name bgp_AP_2
SR-TE policy database
---------------------
Name: bgp_AP_2 (Color: 128, End-point: 7.7.7.7) (bgp_AP_2 is dynamically created)
Status:
Admin: up Operational: up for 00:09:27 (since May 1 10:14:33.304)
Candidate-paths:
Preference 100:
Constraints:
Prefix-SID Algorithm: 128
Path Metrics:
Margin Absolute: 0
Margin Relative: 0%
Maximum SID Depth: 10
Dynamic (active)
17007 [Prefix-SID: 7.7.7.7, Algorithm: 128]
Attributes:
Binding SID: 24008
Allocation mode: dynamic
State: Programmed
Policy selected: yes
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Distinguisher: 0
Auto-policy info:
Creator: BGP
RP/0/0/CPU0:L4#
Output of vrf test 100.0.0.7 which shows that it is taking flex-algo (128) created path.
RP/0/0/CPU0:L4#traceroute vrf test 100.0.0.7
Tracing the route to 100.0.0.7
1 2.4.0.2 [MPLS: Labels 17007/24009 Exp 0] 9 msec 9 msec 9 msec
2 2.5.0.5 [MPLS: Labels 17007/24009 Exp 0] 9 msec 9 msec 9 msec
3 5.6.0.6 [MPLS: Labels 17007/24009 Exp 0] 9 msec 9 msec 9 msec
4 6.7.0.7 9 msec * 9 msec
For testing purpose I have created another vrf named test_without_odn on L3, L4 and PE7. PE7 is advertising another VPNv4 router 111.0.0.7 with no color attached to it for test_without_odn 111.0.0.7. Now PE7 has two vrfs one is advertising routes with color and another is advertising routes without color. For vrf test ODN will be instantiated and flex-algo(128) will be considered but for non color routes it will follow the standard path.
RP/0/0/CPU0:L4#traceroute vrf test_without_odn 111.0.0.7
Tracing the route to 111.0.0.7
1 2.4.0.2 [MPLS: Labels 16007/24023 Exp 0] 9 msec 9 msec 9 msec
2 2.5.0.5 [MPLS: Labels 16007/24023 Exp 0] 9 msec 0 msec 9 msec
3 5.6.0.6 [MPLS: Labels 16007/24023 Exp 0] 9 msec 9 msec 9 msec
4 6.7.0.7 0 msec * 9 msec
References
No comments:
Post a Comment