Thursday, May 10, 2018

Segment Routing with RSVP-Traffic Engineering Tunnels

In the previous post we discussed setting up SR.

SR is now running but its relying on IGP for the shortest path through the SP core. RSVP-TE is used to choose the best route and not necessarily the shortest path. We'll pretend that the connections between XR1 and XR2, XR3 and XR4 are 10 Gbps connections, the rest of the network is 40 Gbps. The goal is to build a TE tunnel that will take the path XR1 > XR5 > XR6 > XR2 > XR3 > XR7 > XR8 > XR4, which will effectively bypass the slower links. There will also be a backup path option that will be able to take the direct XR1 > XR2 > XR3 > XR4 path.

The first thing that needs to be done is enabling MPLS Traffic Engineering, RSVP and enabling OSPF to support MPLS TE for area 0.


XR1 - XR8
router ospf 1
 area 0
  mpls traffic-eng
 !
 mpls traffic-eng router-id Loopback0


XR1
rsvp
 interface GigabitEthernet0/0/0/0.112
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.115
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.112
 !
 interface GigabitEthernet0/0/0/0.115


XR2
rsvp
 interface GigabitEthernet0/0/0/0.112
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.123
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.126
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.112
 !
 interface GigabitEthernet0/0/0/0.123
 !
 interface GigabitEthernet0/0/0/0.126


XR3
rsvp
 interface GigabitEthernet0/0/0/0.123
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.134
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.137
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.123
 !
 interface GigabitEthernet0/0/0/0.134
 !
 interface GigabitEthernet0/0/0/0.137


XR4
rsvp
 interface GigabitEthernet0/0/0/0.134
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.148
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.134
 !
 interface GigabitEthernet0/0/0/0.148


XR5
rsvp
 interface GigabitEthernet0/0/0/0.115
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.156
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.115
 !
 interface GigabitEthernet0/0/0/0.156


XR6
rsvp
 interface GigabitEthernet0/0/0/0.126
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.156
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.167
  bandwidth 750000
 !
!
mpls traffic-eng
 !
 interface GigabitEthernet0/0/0/0.126
 !
 interface GigabitEthernet0/0/0/0.156
 !
 interface GigabitEthernet0/0/0/0.167


XR7
rsvp
 interface GigabitEthernet0/0/0/0.137
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.167
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.178
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.137
 !
 interface GigabitEthernet0/0/0/0.167
 !
 interface GigabitEthernet0/0/0/0.178


XR8
rsvp
 interface GigabitEthernet0/0/0/0.148
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.178
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.148
 !
 interface GigabitEthernet0/0/0/0.178

Now that we have built the TE topology, we can build the unidirectional tunnel from XR1 to XR4 via the path we laid out from above, there should also be another path option that follows the IGP path. The TE tunnel should advertise the TE tunnel as an IGP route.

XR1
explicit-path name SR_TE
 index 1 next-address strict ipv4 unicast 192.0.2.25
 index 2 next-address strict ipv4 unicast 192.0.2.26
 index 3 next-address strict ipv4 unicast 192.0.2.22
 index 4 next-address strict ipv4 unicast 192.0.2.23
 index 5 next-address strict ipv4 unicast 192.0.2.27
 index 6 next-address strict ipv4 unicast 192.0.2.28
 index 7 next-address strict ipv4 unicast 192.0.2.24
!
interface tunnel-te1
 ipv4 unnumbered Loopback0
 autoroute announce
 !
 destination 192.0.2.24
 path-option 5 explicit name SR_TE segment-routing
 path-option 10 segment-routing

RP/0/0/CPU0:XR1#sh ip int br
tunnel-te1                     192.0.2.21      Up              Up       default 

We can see that the tunnel was signaled successfully, if it wasn't the tunnel wouldn't not become up/up.

RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels 1 
Thu May 10 22:34:29.600 UTC


Name: tunnel-te1  Destination: 192.0.2.24  Ifhandle:0x680 
  Signalled-Name: XR1_t1
  Status:
    Admin:    up Oper:   up   Path:  valid   Signalling: connected

    path option 5, (Segment-Routing) type explicit SR_TE (Basis for Setup)
      Protected-by PO index: none
    path option 10,  type segment-routing 
    G-PID: 0x0800 (derived from egress interface properties)
    Bandwidth Requested: 0 kbps  CT0
    Creation Time: Thu May 10 21:31:07 2018 (01:03:23 ago)
  Config Parameters:
    Bandwidth:        0 kbps (CT0) Priority:  7  7 Affinity: 0x0/0xffff
    Metric Type: TE (default)
    Path Selection:
      Tiebreaker: Min-fill (default)
      Protection: any (default)
    Hop-limit: disabled
    Cost-limit: disabled
    Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
    AutoRoute:  enabled  LockDown: disabled   Policy class: not set
    Forward class: 0 (default)
    Forwarding-Adjacency: disabled
    Loadshare:          0 equal loadshares
    Auto-bw: disabled
    Path Protection: Not Enabled
    BFD Fast Detection: Disabled
    Reoptimization after affinity failure: Enabled
    SRLG discovery: Disabled
  History:
    Tunnel has been up for: 01:03:22 (since Thu May 10 21:31:08 UTC 2018)
    Current LSP:
      Uptime: 00:52:10 (since Thu May 10 21:42:20 UTC 2018)
    Prior LSP:
      ID: 2 Path Option: 10
      Removal Trigger: reoptimization completed

  Segment-Routing Path Info (OSPF 1 area 0)
    Segment0[Node]: 192.0.2.25, Label: 16025
    Segment1[Node]: 192.0.2.26, Label: 16026
    Segment2[Node]: 192.0.2.22, Label: 16022
    Segment3[Node]: 192.0.2.23, Label: 16023
    Segment4[Node]: 192.0.2.27, Label: 16027
    Segment5[Node]: 192.0.2.28, Label: 16028
    Segment6[Node]: 192.0.2.24, Label: 16024
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

The MPLS TE tunnel output shows that SR is being used to build the tunnel, meaning that SR labels will be used and not RSVP-TE which would be labels starting at 24000 and above. The current path being leveraged is option 5, the explicit path, which is defined above. 

RP/0/0/CPU0:XR1#sh route 192.0.2.24
Thu May 10 22:35:40.545 UTC

Routing entry for 192.0.2.24/32
  Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
  Installed May 10 21:31:09.200 for 01:04:31
  Routing Descriptor Blocks
    192.0.2.24, from 192.0.2.24, via tunnel-te1
      Route metric is 4
  No advertising protos. 

Expanding the route to XR4's loopback, we see that the path now follows the TE1 path and is using a labeled SR path.

RP/0/0/CPU0:XR1#sh cef 192.0.2.24
Thu May 10 22:35:56.954 UTC
192.0.2.24/32, version 46, internal 0x1000001 0x1 (ptr 0xa12b3a74) [1], 0x0 (0xa127f584), 0xa20 (0xa150d320)
 Updated May 10 21:31:09.460
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 192.0.2.24/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa0f164f0 0xa0f16154]
    next hop 192.0.2.24/32
    local adjacency
     local label 24007      labels imposed {ImplNull}

Looking at the CEF table we can see label 24007 was allocated as adjacency SID since the TE1 tunnel is a new tunnel and therefore a label needs to be allocated.

RP/0/0/CPU0:XR1#sh mpls forwarding labels 24007
Thu May 10 22:50:33.174 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------

24007  Pop         192.0.2.24/32      tt1          192.0.2.24      0   

We can prove that by looking at what label 24007 was applied to, in this case it is the TE tunnel.

Once the tunnel is up, re-optimization maybe needed to take the explicit path.

RP/0/0/CPU0:XR1#mpls traffic-eng reoptimize 1

Now that we have a TE tunnel up and running, the routing table shows that traffic towards XR4 will take the TE tunnel. Let's do a trace from XR1 to XR4 and see what happens.

RP/0/0/CPU0:XR1#traceroute 192.0.2.24 source 192.0.2.21 num
Thu May 10 22:36:40.701 UTC

Type escape sequence to abort.
Tracing the route to 192.0.2.24

 1  100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024 Exp 0] 139 msec  119 msec  109 msec 
 2  100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024 Exp 0] 119 msec  109 msec  149 msec 
 3  100.64.126.12 [MPLS: Labels 16023/16027/16028/16024 Exp 0] 119 msec  119 msec  119 msec 
 4  100.64.123.13 [MPLS: Labels 16027/16028/16024 Exp 0] 129 msec  109 msec  119 msec 
 5  100.64.137.17 [MPLS: Labels 16028/16024 Exp 0] 109 msec  119 msec  119 msec 
 6  100.64.178.18 [MPLS: Label 16024 Exp 0] 119 msec  129 msec  109 msec 
 7  100.64.148.14 109 msec  *  109 msec 

We can see that the TE tunnel is being taken with the 7 SR label stack. This stack is encoded as it hits the ingress PE.

R1#ping 192.0.2.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/86/90 ms

R1#traceroute 192.0.2.2 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.101.11 19 msec 7 msec 10 msec
  2 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024/24004 Exp 0] 131 msec 133 msec 126 msec
  3 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024/24004 Exp 0] 143 msec 134 msec 123 msec
  4 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024/24004 Exp 0] 143 msec 129 msec 124 msec
  5 100.64.123.13 [MPLS: Labels 16027/16028/16024/24004 Exp 0] 140 msec 133 msec 126 msec
  6 100.64.137.17 [MPLS: Labels 16028/16024/24004 Exp 0] 141 msec 138 msec 124 msec
  7 100.64.178.18 [MPLS: Labels 16024/24004 Exp 0] 135 msec 132 msec 128 msec
  8 100.64.148.14 [MPLS: Label 24004 Exp 0] 130 msec 133 msec 127 msec
  9 100.64.103.2 133 msec *  136 msec


We see that in the above ping worked, but that doesn't showcase the SR TE output. The traceroute showcases the SR TE stack. The screenshot shows that the entire stack is encoded as traffic enters the SP core.

Thanks for stopping by!
Rob Riker, CCIE #50693

Wednesday, May 9, 2018

Segment Routing on IOS XR 6.0

Segment Routing or SR is another labeling mechanism on IOS XR. Most people are familiar with LDP or Label Distribution Protocol for allocating labels the PE and P loopbacks and their connected links. LDP requires the network to maintain a level state equal to the size of the network, if there are only a few routers making up the core, the level of state is pretty low.

The purpose of SR is to control the label allocation that the PE and P routers will use for their loopbacks and the transit links. The key difference between SR and LDP is SR allocates the label to the loopback interface. LDP does not do this, static labeling is supported but configuration intensive. SR uses a dedicated block of labels, the SRGB with a range of 16000-23999.

LDP is deployed along side of IGP but as a different process, IGP needs to be converged before LDP converges or micro loops can occur.

SR is configured under the IGP process for both OSPF and IS-IS. The SR labels are propagated inside of the IS-IS TLVs and OSPF Opaque LSAs.

There are 2 different label allocations, the loopback of the P or PE router and the connected links between the P and PE routers.

The loopback label is called the "Prefix SID" or Prefix Segment Identifier.
The transit label is called the "Adjacency SID" or Adjacency Segment Identifier.

The Prefix SID comes from the 16000-23999 label range, the SRGB.
The Adjacency SID comes from the dynamic label range 24000-1048575.

The only thing that changes in the MPLS L3VPN deployment here is SR is the labeling technique, VRFs, MP-BGP, VRF Aware BGP PE-CE and IGP routing are still needed. The above IOS routers, R1-R4 R1 is ASN 101, R2 is ASN 102 and so forth. The ASN in the core is ASN1. XR6 is a RR to the PE routers.

The configuration and verification outputs are below.

XR1
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16021
  !
  interface GigabitEthernet0/0/0/0.112
  !
  interface GigabitEthernet0/0/0/0.115

XR2
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16022
  !
  interface GigabitEthernet0/0/0/0.112
  !
  interface GigabitEthernet0/0/0/0.123
  !
  interface GigabitEthernet0/0/0/0.126

XR3
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16023
  !
  interface GigabitEthernet0/0/0/0.123
  !
  interface GigabitEthernet0/0/0/0.134
  !
  interface GigabitEthernet0/0/0/0.137

XR4
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16024
  !
  interface GigabitEthernet0/0/0/0.134
  !
  interface GigabitEthernet0/0/0/0.148

XR5
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16025
  !
  interface GigabitEthernet0/0/0/0.115
  !
  interface GigabitEthernet0/0/0/0.156

XR6
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16026
  !
  interface GigabitEthernet0/0/0/0.126
  !
  interface GigabitEthernet0/0/0/0.156
  !
  interface GigabitEthernet0/0/0/0.167

XR7
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16027
  !
  interface GigabitEthernet0/0/0/0.137
  !
  interface GigabitEthernet0/0/0/0.167
  !
  interface GigabitEthernet0/0/0/0.178

XR8
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid index 28
  !
  interface GigabitEthernet0/0/0/0.148
  !
  interface GigabitEthernet0/0/0/0.178

XR8 is running 5.3 XR code, so the "absolute" option isn't supported, Index and absolute do the same thing, index just calls the label value that will get added to 16000 where absolute defines it completely.


RP/0/0/CPU0:XR1#sh mpls interfaces  detail 
Wed May  9 19:17:00.751 UTC
Interface GigabitEthernet0/0/0/0.112:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS enabled
Interface GigabitEthernet0/0/0/0.115:
        LDP labelling not enabled
        LSP labelling not enabled

        MPLS enabled

RP/0/0/CPU0:XR2#show mpls interfaces detail 
Wed May  9 19:18:20.711 UTC
Interface GigabitEthernet0/0/0/0.112:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS enabled
Interface GigabitEthernet0/0/0/0.123:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS enabled
Interface GigabitEthernet0/0/0/0.126:
        LDP labelling not enabled
        LSP labelling not enabled

        MPLS enabled

As you can see, LDP is not being used here, Segment Routing is.

R1 and R2 have now peered with the SP and advertised their loopbacks into BGP.

R1#sh ip route bgp | b  Gateway
Gateway of last resort is not set

      192.0.2.0/32 is subnetted, 2 subnets

B        192.0.2.2 [20/0] via 100.64.101.11, 10:18:02


R2#sh ip route bgp | b  Gateway
Gateway of last resort is not set

      192.0.2.0/32 is subnetted, 2 subnets
B        192.0.2.1 [20/0] via 100.64.103.14, 10:18:48

Now we'll do some trace routes to see how Segment Routing will look different than what LDP will look. NOTE - BGP VPNv4 is still used to allocate labels for customer learned routes, these labels are pulled from the global dynamic label pool.

R2#traceroute 192.0.2.1 source loopback 0 numeric 
Type escape sequence to abort.
Tracing the route to 192.0.2.1
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.103.14 23 msec 14 msec 8 msec
  2 100.64.134.13 [MPLS: Labels 16021/24004 Exp 0] 107 msec 92 msec 91 msec
  3 100.64.123.12 [MPLS: Labels 16021/24004 Exp 0] 99 msec 97 msec 100 msec
  4 100.64.112.11 [MPLS: Label 24004 Exp 0] 99 msec 85 msec 88 msec
  5 100.64.101.1 89 msec *  110 msec

The 16021/24004 is the 2 label stack we would normally see with LDP, the top label, the transport label, 16021 wouldn't be in the range of 16000-23999.

In this case, the label 16021 isn't LDP allocating labels arbitrarily, this label value is configured on XR1 on the loopback interface and propagated to the other P/PE routers inside of OSPF Opaque LSAs. All of the routers in the core know that to reach XR1 via a labeled path, they must use label 16021 to get there.

We'll take the next several outputs and examine them to breakdown how we the label values above were allocated and understand where they fit in.

Let's see what routes we received in from XR1 via the RR of XR6.

RP/0/0/CPU0:XR4#sh bgp vpnv4 unicast neighbors 192.0.2.26 routes | b Network
Wed May  9 19:31:25.218 UTC
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf A)
*>i192.0.2.1/32       192.0.2.21               0    100      0 101 i

Processed 1 prefixes, 1 paths

We can see that we learned 192.0.2.1 from 192.0.2.21, let's expand that to see what label value VPNv4 applied.

RP/0/0/CPU0:XR4#sh bgp vrf A 192.0.2.1/32
Wed May  9 19:25:24.652 UTC
BGP routing table entry for 192.0.2.1/32, Route Distinguisher: 1:1
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  4           4
Last Modified: May  9 09:00:02.407 for 10:25:22
Paths: (1 available, best #1)
  Advertised to CE peers (in unique update groups):
    100.64.103.2    
  Path #1: Received by speaker 0
  Advertised to CE peers (in unique update groups):
    100.64.103.2    
  101
    192.0.2.21 (metric 4) from 192.0.2.26 (192.0.2.21)
      Received Label 24004
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 4
      Extended community: RT:1:1 
      Originator: 192.0.2.21, Cluster list: 192.0.2.26
      Source AFI: VPNv4 Unicast, Source VRF: A, Source Route Distinguisher: 1:1

We see that label 24004 was allocated by VPNv4 for the 192.0.2.1/32 route advertised by XR1. We have the VPN label, now we need to know what to configure as the transport label.

RP/0/0/CPU0:XR4#sh route 192.0.2.21
Wed May  9 19:34:21.986 UTC

Routing entry for 192.0.2.21/32
  Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
  Installed May  8 22:23:31.979 for 21:10:50
  Routing Descriptor Blocks
    100.64.134.13, from 192.0.2.21, via GigabitEthernet0/0/0/0.134
      Route metric is 4

  No advertising protos.

We see that the route was learned via OSPF intra area propagation, more importantly, labeled SR is propagated as well.

RP/0/0/CPU0:XR4#show cef 192.0.2.21
Wed May  9 19:36:06.659 UTC
192.0.2.21/32, version 16, internal 0x1000001 0x81 (ptr 0xa12b3a74) [1], 0x0 (0xa12994f4), 0xa28 (0xa150d140)
 Updated May  8 22:23:32.049 
 local adjacency 100.64.134.13
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 100.64.134.13/32, GigabitEthernet0/0/0/0.134, 9 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa0f592a4 0x0]
    next hop 100.64.134.13/32
    local adjacency
     local label 16021      labels imposed {16021}

Checking the CEF table we can see that both the imposed label and the local label are both 16021. Imposed means that 16021 will be used to forward these packets through the core.

RP/0/0/CPU0:XR4#show mpls forwarding labels 16021        
Wed May  9 19:38:12.840 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------
16021  16021       SR Pfx (idx 21)    Gi0/0/0/0.134 100.64.134.13   5628  

This is a prefix SID that is applied to XR1's loopback. It is both the local label and the outgoing label.

RP/0/0/CPU0:XR4#sh ospf database opaque-area adv-router 192.0.2.21
Wed May  9 19:39:44.484 UTC


            OSPF Router with ID (192.0.2.24) (Process ID 1)

                Type-10 Opaque Link Area Link States (Area 0)

  LS age: 926
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 4.0.0.0
  Opaque Type: 4
  Opaque ID: 0
  Advertising Router: 192.0.2.21
  LS Seq Number: 80000027
  Checksum: 0x8ceb
  Length: 52

    Router Information TLV: Length: 4
    Capabilities:
      Graceful Restart Helper Capable
      Stub Router Capable
      All capability bits: 0x60000000

    Segment Routing Algorithm TLV: Length: 1
      Algorithm: 0

    Segment Routing Range TLV: Length: 12
      Range Size: 8000

        SID sub-TLV: Length 3
         Label: 16000

  LS age: 664
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 7.0.0.1
  Opaque Type: 7
  Opaque ID: 1
  Advertising Router: 192.0.2.21
  LS Seq Number: 80000027
  Checksum: 0xc5ee
  Length: 44

    Extended Prefix TLV: Length: 20
      Route-type: 1
      AF        : 0
      Flags     : 0x40
      Prefix    : 192.0.2.21/32

      SID sub-TLV: Length: 8
        Flags     : 0x0
        MTID      : 0
        Algo      : 0
        SID Index : 21

Looking at the bolded parts of the OSPF Opaque LSA, we see that the Prefix SID begins at 16000 and carries for 8000 which ranges from 16000 - 23999. Below that we see the Prefix of 192.0.2.21 with an index of 21. 16000 plus 21 gets us 16021. This boils down that 16021 will be the transport label for every SP core router, XR2 through XR8 to reach XR1. 

Friday, April 13, 2018

MPLS Layer 2 VPN with L2VPN Context and Service Instances

Layer 2 VPN is a large topic domain, as such, its important to cover the basics first. There are older posts breaking down some of the behind the scenes, but we are focusing on the configuration, the mapping and proving L2VPN is actually working. The goal is to basically "simulate" 2 Customer sites or 2 sites period being able to see each other over the WAN as directly connected. Historically the "xconnect" or cross connect configured under the interface facing the customer was used to bridge traffic over the SP core. 

We're taking that same concept, and using newer syntax that is used to scale the L2VPN design overall. No more xconnects under the interface, rather several individual pieces tied together to extend the broadcast domain over the SP core.

There are three components used here:
1. The service instance
2. The Pseudowire interface
3. The l2vpn xconnect context

The SI or service instance creates the EFP or Ethernet Flow Point that allows highly scalable L2 services to be configured at the same time under the interface facing the customer. Instead of just bridging, EFP gives us several options to match on for enhanced flexibility. SI 1 could be used for P2P connectivity while SI 2 could be used for VPLS, while SI 3 could be used for H-VPLS, each matching on different L2 traffic. 

The Pseudowire or PW as I'll reference it, is used to create a tLDP or Targeted LDP peering between the PE devices in this case. There are several options that are available under the PW construct, too many to list here. The goal is to have a dedicated construct that can be used for signaling and other options between the PEs. Remote AC or Attachment Circuit failure detection on the local PE is useful and enabled with the use of the CW or Control Word.

The L2VPN xconnect context is what connect or maps the SI to the PW to allow the PEs to communicate with each other. Like the other 2 constructs, there are many options available. The context references the SI and PW as members of the construct which pretty much just binds them together. That's a simplification of course.

Between the three components, this makes L2VPN much more scalable than just the "xconnect". So much so, that when I kickoff the CCIE SPv4 video series later this year, L2VPN will have a dedicated section. One thing to note is that L2VPN is not limited to 1 PW or context but rather several of each, and not just one AS either, Inter AS and CSC designs are supported and will be covered later, after I test them out of course.
The goal here, enable R18 and R16 to communicate with each other over AS 50693 with each router having an interface in the common subnet, 10.1.1.0/24.

R15
interface GigabitEthernet2
 no ip address
 negotiation auto
 no keepalive
 service instance 1 ethernet
  encapsulation default
!
interface pseudowire1
 encapsulation mpls
 neighbor 192.0.2.17 1
 control-word include
!
l2vpn xconnect context P2P
 member pseudowire1
 member GigabitEthernet2 service-instance 1 


R17
interface GigabitEthernet2
 no ip address
 negotiation auto
 no keepalive
 service instance 1 ethernet
  encapsulation default
!
interface pseudowire1
 encapsulation mpls
 neighbor 192.0.2.15 1
 control-word include
!
l2vpn xconnect context P2P
 member GigabitEthernet2 service-instance 1 
 member pseudowire1


Now that we have the PEs configured, let's verify some basic connectivity.

R17#show l2vpn atom vc 

                                       Service
Interface Peer ID         VC ID      Type   Name                     Status
--------- --------------- ---------- ------ ------------------------ ----------
pw1       192.0.2.15      1          p2p    P2P                      UP        

This output simply prove that there is an active pseudowire between R15 and R17.

R17#  show mpls ldp neighbor 192.0.2.15
    Peer LDP Ident: 192.0.2.15:0; Local LDP Ident 192.0.2.17:0
        TCP connection: 192.0.2.15.646 - 192.0.2.17.27620
        State: Oper; Msgs sent/rcvd: 37/36; Downstream
        Up time: 00:04:19
        LDP discovery sources:
          Targeted Hello 192.0.2.17 -> 192.0.2.15, active, passive
        Addresses bound to peer LDP Ident:
          100.64.157.15   100.64.158.15   192.0.2.15      100.64.151.15   

This output shows that there is a targeted LDP peering between R15 and R17. Targeted meaning that R15 and R17 are not directly connected. 

Let's test connectivity between R16 and R18.

R16
interface GigabitEthernet2
 ip address 10.1.1.16 255.255.255.0

R18
interface GigabitEthernet2
 ip address 10.1.1.18 255.255.255.0

The verficiation:

R16#ping 10.1.1.18
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.18, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/21/65 ms

R15#show mpls forwarding-table labels 44
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
44         No Label   l2ckt(1)         647           Gi2        point2point 

We'll send more pings to verify it again.

R15#show mpls forwarding-table labels 44
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
44         No Label   l2ckt(1)         1217          Gi2        point2point 

As you can see, there are packets being labeled switched.

Thursday, April 12, 2018

MPLS Inter AS Option 1 / Option A Back to Back VRF Exchange

In this post we will be taking a look at the "easiest" Inter AS VPN technique, at least in my opinion. It takes advantage of what is already understood with VRF connectivity, instead of connecting to a customer device, we peer with the remote provider in a VRF. This is done per customer, so for every customer we're trying to extend between the SPs, a VRF must be created. This also means that a routing protocol adjacency/peering needs to be configured as well. This is where the scalability of Option A becomes an issue, 1 for 1 VRFs and BGP/IGP peerings will quickly tie up resources on the ASBRs.
I added 2 new customers, each with a VRF, VPNA and VPNB. Having just a single customer on all the PE and ASBRs doesn't show the pros/cons of Option A. The cool thing about this design is that if a PE has a VRF configured with the appropriate RT import/export policy setup, it will only receive traffic that matches the RT policies. The drawback about this design is that an ASBR with multiple VRFs configured will have to form 1 to 1 VRF to IGP/BGP peerings with the remote ASBR.

The VRFs laid out below will be needed to learn and then propagate BGP routes between the providers.

R5 and R6
vrf definition CSC
 rd 1:1
 route-target export 1:1
 route-target import 1:1
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
vrf definition VPNA
 rd 2:2
 route-target export 2:2
 route-target import 2:2
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
vrf definition VPNB
 rd 3:3
 route-target export 3:3
 route-target import 3:3
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family



XR6
vrf TEST
 address-family ipv4 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
 !
 address-family ipv6 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
vrf VPNA
 address-family ipv4 unicast
  import route-target
   2:2
  !
  export route-target
   2:2
  !
 !
 address-family ipv6 unicast
  import route-target
   2:2
  !
  export route-target
   2:2
  !
 !
!
vrf VPNB
 address-family ipv4 unicast
  import route-target
   3:3
  !
  export route-target
   3:3
  !
 !
 address-family ipv6 unicast
  import route-target
   3:3
  !
  export route-target
   3:3
  !
 !
!


Now we'll have to apply the VRFs to interfaces.

R5#sh vrf
  Name                             Default RD            Protocols   Interfaces
  CSC                              1:1                   ipv4,ipv6   Gi1.56
  VPNA                             2:2                   ipv4,ipv6   Gi1.22
  VPNB                             3:3                   ipv4,ipv6   Gi1.33

R6#sh vrf
  Name                             Default RD            Protocols   Interfaces
  CSC                              1:1                   ipv4,ipv6   Gi1.56
                                                                     Gi1.166
  VPNA                             2:2                   ipv4,ipv6   Gi1.22
                                                                     Gi1.122
  VPNB                             3:3                   ipv4,ipv6   Gi1.33
                                                                     Gi1.133

RP/0/0/CPU0:XR6#sh ip int br | ex default
Thu Apr 12 15:01:34.989 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
GigabitEthernet0/0/0/0.122     100.64.122.16   Up              Up       VPNA 
GigabitEthernet0/0/0/0.133     100.64.133.16   Up              Up       VPNB 
GigabitEthernet0/0/0/0.166     100.64.166.16   Up              Up       TEST 


Now that the interfaces are in the correct VRFs, we can go ahead and setup the BGP configuration.

R5
router bgp 50693
 !
 address-family ipv4 vrf CSC
  neighbor 100.64.56.6 remote-as 2
  neighbor 100.64.56.6 activate
 exit-address-family
 !
 address-family ipv4 vrf VPNA
  neighbor 100.64.22.6 remote-as 2
  neighbor 100.64.22.6 activate
 exit-address-family
 !
 address-family ipv4 vrf VPNB
  neighbor 100.64.33.6 remote-as 2
  neighbor 100.64.33.6 activate
 exit-address-family


R6
router bgp 2
 address-family ipv4 vrf CSC
  neighbor 100.64.56.5 remote-as 50693
  neighbor 100.64.56.5 activate
  neighbor 100.64.166.16 remote-as 50693
  neighbor 100.64.166.16 activate
 exit-address-family
 !     
 address-family ipv4 vrf VPNA
  neighbor 100.64.22.5 remote-as 50693
  neighbor 100.64.22.5 activate
  neighbor 100.64.122.16 remote-as 50693
  neighbor 100.64.122.16 activate
 exit-address-family
 !
 address-family ipv4 vrf VPNB
  neighbor 100.64.33.5 remote-as 50693
  neighbor 100.64.33.5 activate
  neighbor 100.64.133.16 remote-as 50693
  neighbor 100.64.133.16 activate
 exit-address-family


XR6
router bgp 50693
  vrf TEST
  rd 1:1
  address-family ipv4 unicast
  !
  neighbor 100.64.166.6
   remote-as 2
   address-family ipv4 unicast
    route-policy RPL_EBGP_PEERINGS in
    route-policy RPL_EBGP_PEERINGS out
   !
  !
 !
 vrf VPNA
  rd 2:2
  address-family ipv4 unicast
  !
  neighbor 100.64.122.6
   remote-as 2
   address-family ipv4 unicast
    route-policy RPL_EBGP_PEERINGS in
    route-policy RPL_EBGP_PEERINGS out
   !
  !
 !
 vrf VPNB
  rd 3:3
  address-family ipv4 unicast
  !
  neighbor 100.64.133.6
   remote-as 2
   address-family ipv4 unicast
    route-policy RPL_EBGP_PEERINGS in
    route-policy RPL_EBGP_PEERINGS out


The next thing for us to do is verify the VRF/BGP configuration.

RP/0/0/CPU0:XR6#sh bgp vrf all summary | i "Neighbor|100.64."
Thu Apr 12 15:06:51.637 UTC
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
100.64.166.6      0     2     371     334      110    0    0 05:28:33          6
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
100.64.122.6      0     2      16      13      110    0    0 00:09:58          4
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
100.64.133.6      0     2      16      13      110    0    0 00:09:57          4

R5#            sh bgp vpnv4 unicast all summary | b Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.64.22.6     4            2     250     247       57    0    0 03:39:37        4
100.64.33.6     4            2     244     244       57    0    0 03:36:02        4
100.64.56.6     4            2     400     401       57    0    0 05:58:40        6
192.0.2.8       4        50693    1379    1343       57    0    0 20:08:40       12

R6# sh bgp vpnv4 unicast all summary | b Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.64.22.5     4        50693     248     250       65    0    0 03:40:04        4
100.64.33.5     4        50693     245     244       65    0    0 03:36:29        4
100.64.56.5     4        50693     402     401       65    0    0 05:59:07        4
100.64.122.16   4        50693      18      21       65    0    0 00:14:20        2
100.64.133.16   4        50693      18      21       65    0    0 00:14:19        2
100.64.166.16   4        50693     338     375       65    0    0 05:32:56        4

Now that we have all the verification complete. We need to test.

R2#sh bgp ipv4 unicast | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 r>  100.64.21.0/24   100.64.21.1              0             0 50693 i
 *>  100.64.114.0/24  100.64.21.1                            0 50693 2 65004 i
 *>  100.64.144.0/24  100.64.21.1                            0 50693 2 65014 i
 *>  100.64.165.0/24  100.64.21.1                            0 50693 65016 i
 *>  100.64.222.0/24  100.64.21.1                            0 50693 2 65014 i
 *>  100.64.233.0/24  100.64.21.1                            0 50693 2 65014 i
 *>  192.0.2.2/32     0.0.0.0                  0         32768 i
 *>  192.0.2.4/32     100.64.21.1                            0 50693 2 65004 i
 *>  192.0.2.14/32    100.64.21.1                            0 50693 2 65014 i
 *>  192.0.2.16/32    100.64.21.1                            0 50693 65016 i

We see that we've learned several loopbacks, R4, R14 and R16. We trace to R14 from our loopback.

R2#traceroute 192.0.2.14 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.14
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.21.1 [AS 50693] 5 msec 3 msec 3 msec
  2 100.64.18.8 [MPLS: Labels 20/44 Exp 0] 6 msec 6 msec 7 msec
  3 100.64.56.5 [MPLS: Label 44 Exp 0] 14 msec 16 msec 15 msec
  4 100.64.56.6 19 msec 11 msec 10 msec
  5 100.64.106.10 [MPLS: Labels 22/24010 Exp 0] 16 msec 25 msec 17 msec
  6 100.64.103.13 [MPLS: Labels 24008/24010 Exp 0] 20 msec 19 msec 21 msec
  7 100.64.134.14 [MPLS: Label 24010 Exp 0] 18 msec 19 msec 20 msec
  8 100.64.144.14 [AS 65014] 21 msec *  11 msec

We reach it taking the R5-R6 path to get there. You'll also notice that the traceroute is 2 LSPs and an IP path. LSP1 is R1 to R5, the IP path is R5 to R6 and LSP2 is R6 to XR4. This is expected with option A since it is back to back VRF exchange. There is no label exchange or allocation.

R12#sh bgp ipv4 unicast | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.64.121.0/24  0.0.0.0                  0         32768 i
 *>  100.64.144.0/24  100.64.121.11                          0 50693 2 65014 i
 *>  100.64.178.0/24  100.64.121.11                          0 50693 65018 i
 *>  100.64.222.0/24  100.64.121.11                          0 50693 2 65014 i
 *>  100.64.233.0/24  100.64.121.11                          0 50693 2 65014 i
 *>  192.0.2.12/32    0.0.0.0                  0         32768 i
 *>  192.0.2.14/32    100.64.121.11                          0 50693 2 65014 i
 *>  192.0.2.18/32    100.64.121.11                          0 50693 65018 i

We check R12 as well, which is a different customer. We see that R18 and R14 loopbacks are learned. R14 is peered with XR4 in all VRFs, so it has visibility in all VPNs. This can be done by peering the PE to the CE in all VRFs or simply importing/exporting the right RT values in the VRF confguration.

R12#traceroute 192.0.2.14 so lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.14
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.121.11 2 msec 2 msec 1 msec
  2 100.64.151.15 [MPLS: Labels 20/49 Exp 0] 8 msec 9 msec 7 msec
  3 100.64.158.8 [MPLS: Labels 20/49 Exp 0] 28 msec 31 msec 31 msec
  4 100.64.33.5 [MPLS: Label 49 Exp 0] 21 msec 21 msec 20 msec
  5 100.64.33.6 20 msec 13 msec 12 msec
  6 100.64.106.10 [MPLS: Labels 22/24014 Exp 0] 15 msec 20 msec 20 msec
  7 100.64.103.13 [MPLS: Labels 24008/24014 Exp 0] 23 msec 19 msec 23 msec
  8 100.64.134.14 [MPLS: Label 24014 Exp 0] 25 msec 19 msec 22 msec
  9 100.64.233.14 [AS 65014] 22 msec *  14 msec

We trace over the Inter AS path, again with 2 LSPs and 1 IP path. We also have Intra AS reachability with R18 but the focus was Inter AS here.