I summaried the hands-on at 2019.7, public on my blog now. So you will find the version is old (652/661), new version(721/731) include more inovation features in SR solution.
Introduction
I summarized SR/SRTE hands-on-deck that includes our highlight features and show information in the same topology, content includes the following topic, now revised version is v3:
router isis srte
affinity-map red bit-position 23
flex-algo 128
priority 200
metric-type delay
advertise-definition
affinity exclude-any red
Config follows configuration at exclude/include function router:
router isis srte
affinity-map red bit-position 23
flex-algo 128
metric-type delay <-- define in FAD affinity exclude-any red
!
inter gix/x/x/x
affinity flex-algo red
Config follows configuration at normal router:
router isis srte
flex-algo 128
metric-type delay<-- define in FAD
Now more customer complains their Peering network not flexible and hard to control, that will cause peering link’s utilization not balance and waste of resources. As follow the example on Router-2, customer peering device connect to multi ISP, each ISP sends full internet route, select only based on the BGP. BGP select rule only based on the route but not real traffics, that may be cause port-A’s traffics have 8G, but port-B and port-C only have 4G, if want to adjust BGP select, only change RPL that more complex, and due to route from internet and multi ISP, so route maybe change at some time, in order to balance peering link, customer must continue to adjust their RPL.
Could we have more flexible and simplest way to resolve the issue? The answer is Yes 🙂 we can achieve the task by Segment Routing – Egress Peer Engineering. Now some customer had deployed the solution, that combine NetFlow, Openbmp to check AS/traffics of prefix, then send BGP LU(EPE label) to ingress node, and easy to control traffics.