What is Segment Routing and why should I use it?
Segment routing is a method of source path routing which removes the need for a signalling protocol in MPLS such as LDP or RSVP, instead IGPs such as OSPF or IS-IS are extended to provide labels, meaning that transit routers do not need to maintain state information because path state information is placed into packet headers at the ingress device. Segment routing emerged as a new technology in 2013 and has since made its way into a multitude of network device platforms – one of these being Juniper Junos, which there doesn’t currently seem to be much documentation for, so I thought it would be a good topic to cover.
Segment routing works by breaking the network into “segments” (go figure) and assigning them identifiers, these are knows as SIDs. Each router has it’s own SID, called a Node SID and each adjacency has it’s own SID, called an Adjacency SID.
More information on segment routing can be found here.
The lab
Terminology
- CE – Customer Edge router (does not participate in MPLS, connects to the PE router for MPLS transport)
- PE – Provider Edge router (participates in MPLS, connects to the CE router to allow customers to use the MPLS backbone)
- P – Provider router (participates in MPLS, connects only to PE and P routers in the MPLS backbone)
- Node SID – The segment ID of a router participating in Segment Routing
- AS – autonomous system
- OSPF – Open Shortest Path First IP routing protocol
- LSDB – Link State Database
- BGP – Border Gateway Protocol IP routing protocol
- Adjacency SID – The segment ID of an adjacency in a Segment Routing domain
- inet.0 – The Juniper routing table for IPv4 unicast routes
- inet.3 – The Juniper routing table for IPv4 MPLS. This table stores the egress address of an MPLS label-swiched path (LSP), the LSP name and the outgoing interface name. This routing table is used only when the local router is the ingress node to an LSP
- mpls.0 – The Juniper routing table containing MPLS labels and the action a router should take when receiving MPLS packets
For this example we’ll be configuring Segment Routing on Junos and will be running the topology pictured below on vQFX images in GNS3. The CE routers are both configured with BGP AS 65000 and have eBGP peerings to the PE routers configured with AS 65050, the PE routers also run OSPF along with the P routers, with the entire OSPF domain configured as area 0. All links use 10.0.0.x/31 P2P IPs and every router has a loopback address consisting of a number repeated 4 times, the loopback to router mappings are as follows:
- 1.1.1.1/32 – CE-R1
- 2.2.2.2/32 – PE-R1
- 3.3.3.3/32 – P-R1
- 4.4.4.4/32 – P-R2
- 5.5.5.5/32 – P-R3
- 6.6.6.6/32 – PE-R2
- 7.7.7.7/32 – CE-R2
Basic configuration
Firstly, we’ll configure the interfaces with IP addresses, eBGP, some basic BGP <-> OSPF redistribution and OSPF area 0. Here’s the configuration:
CE-R1
root@CE-R1> show configuration interfaces xe-0/0/0
unit 0 {
family inet {
address 10.0.0.0/31;
}
}
root@CE-R1> show configuration interfaces lo0
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
root@CE-R1> show configuration protocols bgp
group ISP {
export ADVERTISE-LOOPBACK;
peer-as 65050;
neighbor 10.0.0.1 {
local-address 10.0.0.0;
}
}
root@CE-R1> show configuration policy-options
policy-statement ADVERTISE-LOOPBACK {
from {
route-filter 1.1.1.1/32 exact;
}
then accept;
}
CE routers are configured with a BGP export policy named ADVERTISE-LOOPBACK to allow the local loopback to be advertised to the PE routers, therefore allowing it to be redistributed into the OSPF domain.
PE-R1
root@PE-R1> show configuration interfaces xe-0/0/0
unit 0 {
family inet {
address 10.0.0.1/31;
}
}
root@PE-R1> show configuration interfaces xe-0/0/1
unit 0 {
family inet {
address 10.0.0.6/31;
}
}
root@PE-R1> show configuration interfaces xe-0/0/2
unit 0 {
family inet {
address 10.0.0.2/31;
}
}
root@PE-R1> show configuration interfaces lo0
unit 0 {
family inet {
address 2.2.2.2/32;
}
}
root@PE-R1> show configuration protocols ospf
area 0.0.0.0 {
interface xe-0/0/1.0;
interface xe-0/0/2.0;
interface lo0.0 {
passive;
}
}
export BGP-TO-OSPF;
root@PE-R1> show configuration protocols bgp
group CUST1 {
export OSPF-TO-BGP;
peer-as 65000;
neighbor 10.0.0.0 {
local-address 10.0.0.1;
}
}
root@PE-R1> show configuration policy-options
policy-statement BGP-TO-OSPF {
from protocol bgp;
then accept;
}
policy-statement OSPF-TO-BGP {
from protocol [ ospf direct ];
then accept;
}
PE routers are configured with BGP and OSPF export policies, namely OSPF-TO-BGP and BGP-TO-OSPF, BGP peers (in this case the CE routers) will receive routes learnt from OSPF as well as the local loopback, and OSPF peers will receive routes learnt from BGP, which at this point is only the CE router loopbacks.
P-R1
root@P-R1> show configuration interfaces xe-0/0/0
unit 0 {
family inet {
address 10.0.0.4/31;
}
}
root@P-R1> show configuration interfaces xe-0/0/2
unit 0 {
family inet {
address 10.0.0.3/31;
}
}
root@P-R1> show configuration interfaces lo0
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
root@P-R1> show configuration protocols ospf
area 0.0.0.0 {
interface xe-0/0/2.0;
interface xe-0/0/0.0;
interface lo0.0 {
passive;
}
}
P routers at this point are only configured with simple OSPF configuration to build neighborships to other P and PE routers and advertise their local loopbacks.
Note: configuration for all routers will not be displayed for brevity.
Enabling MPLS and Segment Routing
In order for segment routing and OSPF to become our MPLS signalling protocol, we first need to create an MPLS backbone, we’ll establish that with the following bits of configuration on all of the PE and P routers:
PE-R1
root@PE-R1> show configuration interfaces xe-0/0/1
unit 0 {
family inet {
address 10.0.0.6/31;
}
family mpls;
}
{master:0}
root@PE-R1> show configuration interfaces xe-0/0/2
unit 0 {
family inet {
address 10.0.0.2/31;
}
family mpls;
}
root@PE-R1> show configuration protocols
...
mpls {
interface xe-0/0/1.0;
interface xe-0/0/2.0;
}
...
P-R1
root@P-R1> show configuration interfaces xe-0/0/0
unit 0 {
family inet {
address 10.0.0.4/31;
}
family mpls;
}
root@P-R1> show configuration interfaces xe-0/0/2
unit 0 {
family inet {
address 10.0.0.3/31;
}
family mpls;
}
root@P-R1> show configuration protocols
...
mpls {
interface xe-0/0/2.0;
interface xe-0/0/0.0;
}
...All we’re doing is adding family mpls under the unit 0 interface configuration for non-CE facing interfaces, and then including them in the protocols mpls interface configuration. Now we’re ready to configure Segment Routing on all of the PE and P routers:
PE-R1
root@PE-R1> show configuration protocols ospf
source-packet-routing {
node-segment ipv4-index 1;
srgb start-label 4000 index-range 1000;
}
...P-R1
root@P-R1> show configuration protocols ospf
source-packet-routing {
node-segment ipv4-index 2;
srgb start-label 4000 index-range 1000;
}
...Yes, it’s as easy as that!
Under the protocols ospf configuration we enable source-packet-routing with a few options:
node-segment ipv4-index– specifies the routers Node SID relative to the start label numbersrgb start-label 4000 index-range 1000– specifies our segment routing global block with a Node SID start label and index range, so in this case Node SIDs start from 4000 and can range up to 4999
Node SIDs are configured as follows:
- PE-R1 – 4001
- P-R1 – 4002
- P-R2 – 4003
- P-R3 – 4004
- PE-R2 – 4005
Verifying that Segment Routing is working
Lets start exploring routing tables and see what’s actually going on in the OSPF LSDB:
CE-R1
root@CE-R1> show route table inet.0
inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[Direct/0] 01:14:48
> via lo0.0
2.2.2.2/32 *[BGP/170] 00:27:28, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
3.3.3.3/32 *[BGP/170] 00:56:20, MED 1, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
4.4.4.4/32 *[BGP/170] 00:55:41, MED 1, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
5.5.5.5/32 *[BGP/170] 00:55:26, MED 2, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
6.6.6.6/32 *[BGP/170] 00:54:36, MED 2, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
7.7.7.7/32 *[BGP/170] 00:54:41, MED 0, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.0/31 *[Direct/0] 00:58:21
> via xe-0/0/0.0
[BGP/170] 00:27:28, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.0/32 *[Local/0] 00:58:21
Local via xe-0/0/0.0
10.0.0.2/31 *[BGP/170] 00:27:28, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.4/31 *[BGP/170] 00:56:20, MED 2, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.6/31 *[BGP/170] 00:27:28, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.8/31 *[BGP/170] 00:55:41, MED 2, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.10/31 *[BGP/170] 00:54:36, MED 2, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
10.0.0.12/31 *[BGP/170] 00:55:26, MED 3, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
169.254.0.0/24 *[Direct/0] 01:14:48
> via em1.0
[BGP/170] 00:27:28, localpref 100
AS path: 65050 I, validation-state: unverified
> to 10.0.0.1 via xe-0/0/0.0
169.254.0.2/32 *[Local/0] 01:14:48
Local via em1.0
Here we can see that we’re learning the majority of the 10.0.0.x/31 subnets and all of the other routers loopbacks via BGP, which is exactly what we expect to see due to the redistribution we configured earlier.
Now the PE and P routers are where things get interesting and we can start diving into the details of segment routing, because OSPF stores all topology information in the LSDB, we only need to look at PE-R1 to get a full picture of what’s going on:
PE-R1
Routing tables
root@PE-R1> show route table inet.0
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:41:11, localpref 100
AS path: 65000 I, validation-state: unverified
> to 10.0.0.0 via xe-0/0/0.0
2.2.2.2/32 *[Direct/0] 00:56:38
> via lo0.0
3.3.3.3/32 *[OSPF/10/10] 00:40:03, metric 1
> to 10.0.0.3 via xe-0/0/2.0
4.4.4.4/32 *[OSPF/10/10] 00:41:06, metric 1
> to 10.0.0.7 via xe-0/0/1.0
5.5.5.5/32 *[OSPF/10/10] 00:39:00, metric 2
> to 10.0.0.7 via xe-0/0/1.0
to 10.0.0.3 via xe-0/0/2.0
6.6.6.6/32 *[OSPF/10/10] 00:39:38, metric 2
> to 10.0.0.7 via xe-0/0/1.0
7.7.7.7/32 *[OSPF/150/10] 00:39:06, metric 0, tag 0
> to 10.0.0.7 via xe-0/0/1.0
10.0.0.0/31 *[Direct/0] 00:41:12
> via xe-0/0/0.0
10.0.0.1/32 *[Local/0] 00:41:12
Local via xe-0/0/0.0
10.0.0.2/31 *[Direct/0] 00:41:12
> via xe-0/0/2.0
10.0.0.2/32 *[Local/0] 00:41:12
Local via xe-0/0/2.0
10.0.0.4/31 *[OSPF/10/10] 00:40:03, metric 2
> to 10.0.0.3 via xe-0/0/2.0
10.0.0.6/31 *[Direct/0] 00:41:12
> via xe-0/0/1.0
10.0.0.6/32 *[Local/0] 00:41:12
Local via xe-0/0/1.0
10.0.0.8/31 *[OSPF/10/10] 00:41:06, metric 2
> to 10.0.0.7 via xe-0/0/1.0
10.0.0.10/31 *[OSPF/10/10] 00:41:06, metric 2
> to 10.0.0.7 via xe-0/0/1.0
10.0.0.12/31 *[OSPF/10/10] 00:39:00, metric 3
> to 10.0.0.7 via xe-0/0/1.0
to 10.0.0.3 via xe-0/0/2.0
169.254.0.0/24 *[Direct/0] 00:56:38
> via em1.0
169.254.0.2/32 *[Local/0] 00:56:38
Local via em1.0
224.0.0.5/32 *[OSPF/10] 00:56:40, metric 1
MultiRecv
As for the inet.0 table, everything looks as expected – we’re learning CE-R1s loopback via BGP and the majority of the 10.0.0.x/31 subnets and all of the other routers loopbacks via OSPF.
root@PE-R1> show route table inet.3
inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
3.3.3.3/32 *[L-OSPF/10/5] 00:43:20, metric 1
> to 10.0.0.3 via xe-0/0/2.0
4.4.4.4/32 *[L-OSPF/10/5] 00:44:23, metric 1
> to 10.0.0.7 via xe-0/0/1.0
5.5.5.5/32 *[L-OSPF/10/5] 00:42:17, metric 2
> to 10.0.0.7 via xe-0/0/1.0, Push 4004
to 10.0.0.3 via xe-0/0/2.0, Push 4004
6.6.6.6/32 *[L-OSPF/10/5] 00:42:55, metric 2
> to 10.0.0.7 via xe-0/0/1.0, Push 4005Looking at the inet.3 table is where we first start to see segment routing at work, we can see that multiple LSPs have been learnt from OSPF and when sending traffic to routers participating in segment routing that are more than one hop away (in this case P-R3 and PE-R2), we see that PE-R1 will push a label of the Node SID assigned to the destination router, 4004 being P-R3 and 4005 being PE-R2.
root@PE-R1> show route table mpls.0
mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 01:25:06, metric 1
to table inet.0
0(S=0) *[MPLS/0] 01:25:06, metric 1
to table mpls.0
1 *[MPLS/0] 01:25:06, metric 1
Receive
2 *[MPLS/0] 01:25:06, metric 1
to table inet6.0
2(S=0) *[MPLS/0] 01:25:06, metric 1
to table mpls.0
13 *[MPLS/0] 01:25:06, metric 1
Receive
18 *[L-OSPF/10/5] 01:08:35, metric 0
> to 10.0.0.3 via xe-0/0/2.0, Pop
18(S=0) *[L-OSPF/10/5] 01:08:35, metric 0
> to 10.0.0.3 via xe-0/0/2.0, Pop
19 *[L-OSPF/10/5] 00:58:27, metric 0
> to 10.0.0.7 via xe-0/0/1.0, Pop
19(S=0) *[L-OSPF/10/5] 00:58:27, metric 0
> to 10.0.0.7 via xe-0/0/1.0, Pop
4002 *[L-OSPF/10/5] 01:08:29, metric 1
> to 10.0.0.3 via xe-0/0/2.0, Pop
4002(S=0) *[L-OSPF/10/5] 01:08:29, metric 1
> to 10.0.0.3 via xe-0/0/2.0, Pop
4003 *[L-OSPF/10/5] 01:09:32, metric 1
> to 10.0.0.7 via xe-0/0/1.0, Pop
4003(S=0) *[L-OSPF/10/5] 01:09:32, metric 1
> to 10.0.0.7 via xe-0/0/1.0, Pop
4004 *[L-OSPF/10/5] 01:07:26, metric 2
to 10.0.0.7 via xe-0/0/1.0, Swap 4004
> to 10.0.0.3 via xe-0/0/2.0, Swap 4004
4005 *[L-OSPF/10/5] 01:08:04, metric 2
> to 10.0.0.7 via xe-0/0/1.0, Swap 4005
root@PE-R1> show ospf neighbor extensive
Address Interface State ID Pri Dead
10.0.0.7 xe-0/0/1.0 Full 4.4.4.4 128 33
Area 0.0.0.0, opt 0x52, DR 10.0.0.7, BDR 10.0.0.6
Up 01:10:29, adjacent 01:10:29
SPRING Adjacency Labels:
Label Flags Adj-Sid-Type
19 VL Default Dynamic
Topology default (ID 0) -> Bidirectional
10.0.0.3 xe-0/0/2.0 Full 3.3.3.3 128 38
Area 0.0.0.0, opt 0x52, DR 10.0.0.2, BDR 10.0.0.3
Up 01:09:27, adjacent 01:09:26
SPRING Adjacency Labels:
Label Flags Adj-Sid-Type
18 VL Default Dynamic
Topology default (ID 0) -> BidirectionalThe mpls.0 table further clarifies what we saw in the inet.3 table, multiple labels have been learnt from OSPF and we can see that when sending traffic to directly connected routers participating in segment routing PE-R1 will pop labels due to Penultimate Hop Popping, whereas for traffic destined to non-directly connected routers the label will be swapped with a label of the Node SID assigned to the destination router.
Notice how there are only a couple Adjacency SIDs shown? This is because they are only stored for links to directly connected routers, however Adjacency SIDs for all routers are stored in the OSPF LSDB, which we’ll see later. Exploring this more by looking at the OSPF neighbors extensive command output shows that Label 19 is the Adjacency SID for P-R2 and Label 18 is the Adjacency SID for P-R1.
OSPF LSDB
root@PE-R1> show ospf database opaque-area detail | find "4.0.0.0"
OpaqArea*4.0.0.0 2.2.2.2 0x80000003 2223 0x22 0x2535 44
Opaque LSA
SR-Algorithm (8), length 1:
Algo (1), length 1:
0
SID/Label Range (9), length 12:
Range Size (1), length 3:
1000
SID/Label (1), length 3:
Label (1), length 3:
4000
OpaqArea 4.0.0.0 3.3.3.3 0x80000003 2264 0x22 0x74f 44
Opaque LSA
SR-Algorithm (8), length 1:
Algo (1), length 1:
0
SID/Label Range (9), length 12:
Range Size (1), length 3:
1000
SID/Label (1), length 3:
Label (1), length 3:
4000
OpaqArea 4.0.0.0 4.4.4.4 0x80000004 1265 0x22 0xe66a 44
Opaque LSA
SR-Algorithm (8), length 1:
Algo (1), length 1:
0
SID/Label Range (9), length 12:
Range Size (1), length 3:
1000
SID/Label (1), length 3:
Label (1), length 3:
4000
OpaqArea 4.0.0.0 5.5.5.5 0x80000003 2134 0x22 0xca83 44
Opaque LSA
SR-Algorithm (8), length 1:
Algo (1), length 1:
0
SID/Label Range (9), length 12:
Range Size (1), length 3:
1000
SID/Label (1), length 3:
Label (1), length 3:
4000
OpaqArea 4.0.0.0 6.6.6.6 0x80000003 1424 0x22 0xac9d 44
Opaque LSA
SR-Algorithm (8), length 1:
Algo (1), length 1:
0
SID/Label Range (9), length 12:
Range Size (1), length 3:
1000
SID/Label (1), length 3:
Label (1), length 3:
4000As segment routing makes use of OSPF opaque LSAs, we can dive into the OSPF LSDB and verify exactly what the routers are seeing. OpaqArea*4.0.0.0 shows us the Segment Routing Global Block (SRGB) configured on all routers participating in segment routing, we can see the loopbacks of all 5 PE and P routers and that they’re using Node SIDs starting at 4000 with a range of 1000, which is exactly what we configured earlier.
root@PE-R1> show ospf database opaque-area detail | find "7.0.0.1"
OpaqArea*7.0.0.1 2.2.2.2 0x8000000e 1347 0x22 0xc1bd 44
Opaque LSA
Extended Prefix (1), length 20:
Route Type (1), length 1:
1
Prefix Length (2), length 1:
32
AF (3), length 1:
0
Flags (4), length 1:
0x40
Prefix (5), length 32:
2.2.2.2
Prefix Sid (2), length 8:
Flags (1), length 1:
0x00
MT ID (2), length 1:
0
Algorithm (3), length 1:
0
SID (4), length 4:
1
OpaqArea 7.0.0.1 3.3.3.3 0x8000000f 1265 0x22 0xed87 44
Opaque LSA
Extended Prefix (1), length 20:
Route Type (1), length 1:
1
Prefix Length (2), length 1:
32
AF (3), length 1:
0
Flags (4), length 1:
0x40
Prefix (5), length 32:
3.3.3.3
Prefix Sid (2), length 8:
Flags (1), length 1:
0x00
MT ID (2), length 1:
0
Algorithm (3), length 1:
0
SID (4), length 4:
2
OpaqArea 7.0.0.1 4.4.4.4 0x80000014 600 0x22 0x1255 44
Opaque LSA
Extended Prefix (1), length 20:
Route Type (1), length 1:
1
Prefix Length (2), length 1:
32
AF (3), length 1:
0
Flags (4), length 1:
0x40
Prefix (5), length 32:
4.4.4.4
Prefix Sid (2), length 8:
Flags (1), length 1:
0x00
MT ID (2), length 1:
0
Algorithm (3), length 1:
0
SID (4), length 4:
3
OpaqArea 7.0.0.1 5.5.5.5 0x80000011 781 0x22 0x461b 44
Opaque LSA
Extended Prefix (1), length 20:
Route Type (1), length 1:
1
Prefix Length (2), length 1:
32
AF (3), length 1:
0
Flags (4), length 1:
0x40
Prefix (5), length 32:
5.5.5.5
Prefix Sid (2), length 8:
Flags (1), length 1:
0x00
MT ID (2), length 1:
0
Algorithm (3), length 1:
0
SID (4), length 4:
4
OpaqArea 7.0.0.1 6.6.6.6 0x8000000e 8 0x22 0x7ae0 44
Opaque LSA
Extended Prefix (1), length 20:
Route Type (1), length 1:
1
Prefix Length (2), length 1:
32
AF (3), length 1:
0
Flags (4), length 1:
0x40
Prefix (5), length 32:
6.6.6.6
Prefix Sid (2), length 8:
Flags (1), length 1:
0x00
MT ID (2), length 1:
0
Algorithm (3), length 1:
0
SID (4), length 4:
5Further to the above, OpaqArea*7.0.0.1 shows us the actual Node SIDs that are configured for each of the 5 segment routing participating routers, which are also as expected – 4001, 4002, 4003, 4004 and 4005.
root@PE-R1> show ospf database opaque-area detail | find "8.0.0.1"
OpaqArea*8.0.0.1 2.2.2.2 0x80000006 327 0x22 0xfb54 48
Opaque LSA
Extended Link (1), length 24:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.7
Link Data (3), length 4:
10.0.0.6
Adjacency Sid (2), length 7:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Label (4), length 3:
19
OpaqArea 8.0.0.1 3.3.3.3 0x80000004 216 0x22 0xd189 48
Opaque LSA
Extended Link (1), length 24:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.2
Link Data (3), length 4:
10.0.0.3
Adjacency Sid (2), length 7:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Label (4), length 3:
16
OpaqArea 8.0.0.1 4.4.4.4 0x80000007 145 0x22 0x22c 52
Opaque LSA
Extended Link (1), length 28:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.7
Link Data (3), length 4:
10.0.0.7
Lan Adjacency Sid (3), length 11:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Neighbor ID (4), length 4:
2.2.2.2
Label (4), length 3:
17
OpaqArea 8.0.0.1 5.5.5.5 0x80000003 2849 0x22 0x58ef 48
Opaque LSA
Extended Link (1), length 24:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.8
Link Data (3), length 4:
10.0.0.9
Adjacency Sid (2), length 7:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Label (4), length 3:
16
OpaqArea 8.0.0.1 6.6.6.6 0x80000003 2015 0x22 0x97a7 48
Opaque LSA
Extended Link (1), length 24:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.10
Link Data (3), length 4:
10.0.0.11
Adjacency Sid (2), length 7:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Label (4), length 3:
17
OpaqArea*8.0.0.2 2.2.2.2 0x80000004 1152 0x22 0x60e2 52
Opaque LSA
Extended Link (1), length 28:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.2
Link Data (3), length 4:
10.0.0.2
Lan Adjacency Sid (3), length 11:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Neighbor ID (4), length 4:
3.3.3.3
Label (4), length 3:
18
OpaqArea 8.0.0.2 3.3.3.3 0x80000003 2201 0x22 0x2333 48
Opaque LSA
Extended Link (1), length 24:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.5
Link Data (3), length 4:
10.0.0.4
Adjacency Sid (2), length 7:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Label (4), length 3:
17
OpaqArea 8.0.0.2 4.4.4.4 0x80000004 2044 0x22 0x968a 52
Opaque LSA
Extended Link (1), length 28:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.8
Link Data (3), length 4:
10.0.0.8
Lan Adjacency Sid (3), length 11:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Neighbor ID (4), length 4:
5.5.5.5
Label (4), length 3:
18
OpaqArea 8.0.0.2 5.5.5.5 0x80000004 2415 0x22 0xdd48 52
Opaque LSA
Extended Link (1), length 28:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.5
Link Data (3), length 4:
10.0.0.5
Lan Adjacency Sid (3), length 11:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Neighbor ID (4), length 4:
3.3.3.3
Label (4), length 3:
18
OpaqArea 8.0.0.2 6.6.6.6 0x80000004 897 0x22 0xfc12 52
Opaque LSA
Extended Link (1), length 28:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.13
Link Data (3), length 4:
10.0.0.13
Lan Adjacency Sid (3), length 11:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Neighbor ID (4), length 4:
5.5.5.5
Label (4), length 3:
16
OpaqArea 8.0.0.3 4.4.4.4 0x80000004 1302 0x22 0x60b6 52
Opaque LSA
Extended Link (1), length 28:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.10
Link Data (3), length 4:
10.0.0.10
Lan Adjacency Sid (3), length 11:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Neighbor ID (4), length 4:
6.6.6.6
Label (4), length 3:
19
OpaqArea 8.0.0.3 5.5.5.5 0x80000003 1545 0x22 0x1a21 48
Opaque LSA
Extended Link (1), length 24:
Link Type (1), length 1:
2
Link Id (2), length 4:
10.0.0.13
Link Data (3), length 4:
10.0.0.12
Adjacency Sid (2), length 7:
Flags (1), length 1:
0x60
MT ID (2), length 1:
0
Weight (3), length 1:
0
Label (4), length 3:
17Finally, looking at OpaqArea 8.0.0.1, OpaqArea 8.0.0.2 and OpaqArea 8.0.0.3 we can see all of the Adjacency SIDs that have been generated and assigned to links in the OSPF domain, including details such as router ID, link side A and link side B IPs and the label assigned to the adjacency.
Note: There does seem to be a bug in some of the output above, showing the same IP for side A and side B of the link.
In further lab exercises we’ll look at adding an L3VPN to this topology along with some traffic engineering.
Thanks for reading!