Segment Routing: Explicit Traffic Engineering Policies (SR-TE)
We have a shiny new Segment-Routing MPLS core, and one of the many available features this brings is enhanced Traffic Engineering. Here we will run through one such example implementation of a SR Traffic Engineering (SR-TE) policy...
We have the below example topology, in which a CPE device is announcing two prefixes to us, X.X.X.X/X and Y.Y.Y.Y/Y:
As you can see, we will be "colouring" the two prefixes, Red and Blue, with traffic engineering policies to ensure that all traffic from Router B to each prefix takes diverse routing paths through the network.
Blue will route explicitly to Router D, and then route out of an explicitly defined interface to Router A. Red, however, will route explicitly to Router C, and will then route out of an explicitly defined interface towards Router A.
In order to structure these explicit routing instructions, we use Segment IDs (SIDs). We have two types of SID defined in the above topology:
- Node-SID: Globally unique, specific to an SR device
- Adjacency-SID: Locally unique, specific to a SR interface
Our PCE has it's address defined, as well as a password configured that PCE Clients must authenticate with:
configure terminal pce address ipv4 <PCE Address> password <Password>
And other Segment Routing hosts likewise have an association to the PCE configured:
configure terminal segment-routing pcc pce address ipv4 <PCE Address> precedence 1 password <Password>
End routers A and B will need to be configured with the PCE address, and must have the extended communities present that translate to the policies we will be configuring:
configure terminal extcommunity-set opaque RED 1 end-set extcommunity-set opaque RED 2 end-set
Likewise, the mid-path routers C and D must have the necessary local Adjacency-SIDs configured on the associated interfaces in your IGP, ISIS in our case:
configure terminal router isis <Process Tag> interface <SR interface> address-family ipv4 unicast adjacency-sid index 4 commit
Now we can create and push the traffic engineering policies on the Segment Routing Policy Control Engine (SR-PCE). We will create the segment-lists with the label path that traffic must follow:
configure terminal pce segment-routing traffic-eng segment-list name RED_ROUTE index 10 mpls label 16101 !Router C Node-SID index 20 mpls label 15004 !Router C Adjacency-SID index 30 mpls label 16127 !Router A Node-SID segment-list name BLUE_ROUTE index 10 mpls label 16104 !Router D Node-SID index 20 mpls label 15004 !Router D Adjacency-SID index 30 mpls label 16127 !Router A Node-SID
In the Segment-List, you will see that we are stipulating the first label hop as a Node-SID, then the Adjacency-SID of the interface on that device that the traffic must route through. We can then declare the end-device Node-SID as the last hop in the path.
Next, we will need to configure the Traffic Engineering Peer for Router B, and the associated policies. Configure the below on the PCE:
pce segment-routing traffic-eng peer ipv4 <Router B Address> policy RED color 1 end-point ipv4 <Router A Address> candidate-paths preference 100 explicit segment-list RED_ROUTE policy BLUE color 2 end-point ipv4 <Router A Address> candidate-paths preference 100 explicit segment-list BLUE_ROUTE
We are now ready to configure the CPE. Build the necessary route-policies for colouring the prefixes:
configure terminal prefix-set BLUE X.X.X.X/X end-set prefix-set RED Y.Y.Y.Y/Y end-set extcommunity-set opaque RED 1 end-set extcommunity-set opaque BLUE 2 end-set route-policy COLOURING if destination in RED then set extcommunity color RED elseif destination in BLUE then set extcommunity color BLUE else pass endif end-policy
And we can now bring up the BGP session from the CPE to Router A. On the CPE, apply the COLOURING route-policy outbound:
router bgp <CPE AS> address-family ipv4 unicast network X.X.X.X/X network Y.Y.Y.Y/Y neighbor <Router A Address> remote-as <Remote AS> address-family ipv4 unicast route-policy COLOURING out send-extended-community-ebgp
And Router A, to complete the BGP session establishment:
router bgp <Local AS> neighbor <CPE Address> remote-as <CPE AS>
We are now done configuring!
We can see that the BGP session is now established:
RP/0/RSP0/CPU0:Router-A#show bgp neighbor <CPE Address> Fri Dec 7 17:48:51.058 GMT BGP neighbor is <CPE Address> Remote AS <CPE AS>, local AS <Local AS>, external link Remote router ID <CPE Address> BGP state = Established, up for 00:00:05
And we are receiving our prefixes:
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> X.X.X.X/X <CPE Address> 0 0 <Local AS> <CPE AS> i *> Y.Y.Y.Y/Y <CPE Address> 0 0 <Local AS> <CPE AS> i
Looking on Router B, we can see the the PCE has pushed the newly created policies:
RP/0/RSP0/CPU0:Router-B#show segment-routing traffic-eng policy SR-TE policy database --------------------- Color: 1, End-point: <Router A Address> Name: srte_c_1_ep_<Router A Address> Status: Admin: up Operational: down for 00:02:56 Candidate-paths: Preference: 100 (PCEP) Name: RED Requested BSID: dynamic PCC info: Symbolic name: RED PLSP-ID: 1 Dynamic (pce <PCE Address>) (valid) Metric Type: TE, Path Accumulated Metric: 0 16001 [Prefix-SID, <Router C Address>] 15004 [Adjacency-SID, <Router C Address>] 16004 [Prefix-SID, <Router D Address>] Attributes: Forward Class: 0 Steering BGP disabled: no IPv6 caps enable: no Color: 2, End-point: <Router A Address> Name: srte_c_2_ep_<Router A Address> Status: Admin: up Operational: down for 00:02:56 Candidate-paths: Preference: 100 (PCEP) Name: BLUE Requested BSID: dynamic PCC info: Symbolic name: BLUE PLSP-ID: 2 Dynamic (pce <PCE Address>) (valid) Metric Type: TE, Path Accumulated Metric: 0 16004 [Prefix-SID, <Router D Address>] Attributes: Forward Class: 0 Steering BGP disabled: no IPv6 caps enable: no
And a traceroute from Router B to each prefix shows we are correctly routing along the corresponding engineered path:
RP/0/RSP0/CPU0:Router-B#traceroute X.X.X.X Tracing the route to X.X.X.X 2 <Router D Address> 3 msec * 3 msec 3 <CPE Address> 5 msec * 5 msec RP/0/RSP0/CPU0:Router-B#traceroute Y.Y.Y.Y Tracing the route to Y.Y.Y.Y 3 <Router C Address> 4 msec * 4 msec 7 <Router D Address> 11 msec * 11 msec 8 <CPE Address> 13 msec * 13 msec
Success, routing to our two prefixes are each taking their respective explicit paths!
This has been a quick run through of an example implementation of Segment Routing Traffic Engineering. I will be continuing to study and test these technologies and use-cases as we progress with phasing in Segment Routing into our MPLS Core.
Thanks for reading!