Segment Routing

Segment Routing (SR) is a proposed solution to replace MPLS in the wireline networks which is picking up a lot of traction.

RFC 8402 is the Segment Routing Architecture standard which was accepted & published in July last year, it had been worked on for around 5 years before becoming an RFC. It is considered a relatively new protocol. There are currently 42 draft IETF standards in progress for various features around the SR architecture. Lots of information can be found on SR at https://www.segment-routing.net/

It works currently by leveraging either MPLS or IPv6 to represent segments in a network.

A segment can be a network link, the link between two router. It can be a node, identifying the router itself, or it can represent a service – which is essentially the customer network.

Each segment in the network is represented by a Segment Identifier or SID. As you can see in the diagram below, Segment routing works together with an IGP. IGP stands for Interior Gateway Protocol, which is an umbrella term for the routing protocols that share routing information within a common routing domain. Segment Routing currently leverages  IGPs to spread information of the SIDs throughout the network. The two IGPs that SR can use at the moment are OSPF and IS-IS. When SR uses OSPF, the SIDs are distributed in the extended prefix Link State Advertisements. When using IS-IS they are distributed using the router capability advertisements

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKRST-2124.pdf

In SR, every node has a unique identifier called the node SID. This identifier is globally unique and would normally be configured on a loopback address on the device.

In IPv4 networks, the SID is encoded as a standard MPLS label, whereas in IPv6 it is encoded as an IPv6 address associated with the segment.

I’m going to work through an example that focuses on SR-MPLS. This has been done in VIRL and I will attach the VIRL file at the end of this blog post.

You can see in this network the SID allocated to each of the routers.

There is a concept of the global block in  segment routing which begins at 16000, in my case I’ve kicked the numbering off at 19000, just because I could. The last digit of the SID corresponds to the router number in this network.

By default in this network, when a router goes into the ingress router it will take the best path through the network as determined by IS-IS. In this case, it is vi R1, R2, R3 and finally through R4.

To demonstrate one of the features of SR, I’m going to force a packet to go via R5.

In the configuration below I’ve set up a tunnel through to R4 which an explicit path titled SIDLIST1.

In the example you can see I’m explicitly stating the pathway to be 19002, 19003 and then 19005 before going to 19004.

  interface tunnel-te1

    ipv4 unnumbered Loopback0

    autoroute destination 100.0.0.4

    destination 100.0.0.4

    path-option 1 explicit name SIDLIST1 segment-routing

  explicit-path name SIDLIST1

    index 10 next-label 19002

    index 20 next-label 19003

    index 30 next-label 19005

    index 40 next-label 19004

The options for defining path are fairly extensive. It can be configured to avoid a router, to always go through a particular router and many other options. But for now we’ll see what happens when we apply this to the lab network.

I have the explicit SID list configured and what I’ve done is tapped each link and opened the traffic in wireshark so we can see exactly what the packet looks like as it goes through a segment routed network.

I have set up a ping from R7 to R8 across the SR network. The packet goes straight into the ingress router. The router will look up the route and then put the appropriate stack of segments within the packet and forward to the next router. This is were I first tap it.

Here (above) between R1 and R2 you can see the stack of MPLS labels indicating the segment route to take.

The active segment is on the top and is the segment that the router inspects when it arrives at R2. In this case R2 will see 19003 and will forward the packet on to R3. Before forward it will remove the top label.

Between R2 and R3 (above) we can see that stack is slightly smaller and the active SID is now 19005. This means R3 will forward the packet to R5, once again removing one of the labels.

Between R3 and R5 (above) we see the active SID is now 19004, meaning that R5 will forward to R4 removing the SID before doing so.

Above we see between R5 and R4 all the SIDs have been removed, there is just a final label which represents the customers vrf, and so R4 knows to forward to R8.

In summary, we can see how segment routing uses the MPLS labels to represent SIDS and how it is possible to configure explicit routes through the providers network.

Click here for the VIRL demo file

0x001A

I completed a Bachelor of Engineering with Honours specialising in Telecommunications and Digital Systems between 1995 - 1999.

I worked as a Design and then Senior Engineer in Network Development and Optimisation for OnAir Networks and then later in Terminal Interworking within Cellular Engineering. I loved it.

After 9 months of maternity leave I tendered my resignation to care for my 3 children that I opted to have within 3.5 years to ensure I wasn't too long out of work.

I completed a Masters in Computer Networking, multiple Cisco certifications and a couple of security certifications.

I've worked as a Network & Security specialist from 2009 until current.

I am currently working as the Director of a highly technical section.

This is my history and here is what I've learnt from spending the last 0x001A years as a minority in my career.

• My view of women in STEM events has evolved throughout my career. I've had times I hated them. Times I thought they achieved nothing and were a waste of time. I still see my former thoughts echo'd back in other tech women that just want to do their jobs. Today - they are not everything, but they raise awareness that there is a lack of women in tech roles and if only one more female is enabled from an event, then they are worth it. 

• When you meet another woman in tech, it can sometimes feel awkward. I'm so used to working with men that when I get to work with a female, I'm not so sure how to act. Some women love having an ally others will see you as competition. And some people will compare the only two women on the team, with comments like "Jenny is more technical than Sally". Don't compete with other women. We have enough to deal with.

• When you start a new role, its harder to get credibility than a male. Not getting good projects, not being given full TACACS access, questioned on new engagements - it happens. As a female, its easier not to move around as much. Because once you've proven yourself and its understood you know your job very well - its easier to stay where you are. But don't. Put yourself out there - believe in yourself. 

• You will be mansplained to - multiple times. It's frustrating when that tech director painfully explains how to use ls on a linux system. This isn't a reflection on you, this is a reflection on them. This is their embarrassment not yours. Don't take this responsibility on, its not yours. Move on and ignore them.

• There is an expectation that because you are female that you have better social skills, higher emotional intelligence and can represent and lead other generations. This is sexist. I had someone tell me that as a female I had a duty to behave better, kinder and nicer than everyone else. I don't. I'm shy, I'm introvert and I don't owe any more to the community than any other person doing their job in tech.

• Take credit for your work. For many years I would allow other people to take credit for my work. When my name was forgotten in the credits, I would dismiss it and say it was okay. It's not okay. Don't be modest and accepting - women have the right to be as proud of their work as men do. If they say, "Sorry we forgot to give you credit", don't say its okay - tell them to correct the situation and do the right thing. Women are adverse to boastfulness. Don't be afraid of being proud of your work.

• Remember why you're doing it. You will have bad days. You will be undermined and minimised. You will be talked over and mansplained. You will be dismissed as attending the "partners program" at tech conferences - the partners program being for wives and girlfriends of attendees. Forget all that and remember why you are here. When this happens, I put on my headphones, I sit at my computer and I lose myself in my tech. Because no matter what people say or think - this is my job, this is what I love doing and this is what I will continue doing.

Now get out there and do your tech jobs ladies!!