Hello my friend,

Two years ago we’ve discussed how to configure Segment Routing between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. Both of these vendors are well-known in Service Provider industry as they are delivering networks in this filed for a long time. But the world isn’t stable and nobody knows what will happen tomorrow. And traditional data centre vendors start looking to SP WAN.

Brief description

I won’t explain the details of Segment-Routing or IP VPN as it was done previously. Please, refer to those articles. In this article, we’ll take a look on multivendor topology with Segment Routing as MPLS data plane and IP VPN as service running in top. Both these features are quite new to Arista, and for example IP VPN was released just recently, though EVPN was there for quite a long time.

In general, we could say that Segment Routing with IP VPN (or any kind of L2 service on top) is de facto standard for modern service provider networks in the same manner as EVPN/VXLAN for modern data centres.

What are we going to test?

We will test the communication of the customers within IP VPN connected to PE network functions running on Arista EOS, Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS. The MPLS data will be done using Segment Routing.

Software version

The following software components are used in this lab:

  • CentOS 7.5.1804 with python 2.7.5
  • Ansible 2.7.0
  • Nokia SR OS 16.0.R4 [guest VNF]
  • Cisco IOS XR 6.1.2 [guest VNF]
  • Arista EOS 4.21.1.F [guest VNF]

See the previous article to get details how to build the lab

Topology

The physical topology is exactly the same as we have used for all our labs, even the data centres:

The logical topology is the same, as we had previously in original Segment Routing lab, where we just replace Nokia SR OS based router SR2 to Arista EOS based router EOS1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
+----------------------------------------------------------------------------------------------------------------------------------+
|                                                                                                                                  |
|                                                    10.11.22.0/24                                                                 |
|           +--------------------------------------------------------------------------------------------+                         |
|           | 1/1/c1/1:0                                                                            Eth1 |                         |
|           |  .11                                                                                  .22  |                         |
|   +-------+--------+       10.11.33.0/24        +----------------+       10.22.33.0/24        +--------+-------+                 |
|   | SR1 (AS:65000) +----------------------------+ XR3 (AS:65000) +----------------------------+ EOS2(AS:65000) |                 |
|   +-------+--------+ 1/1/c1/1:13    g0/0/0/0.13 +--------+-------+ g0/0/0/1              Eth2 +--------+-------+                 |
|           |           .11                  .33           |          .33                  .22           |                         |
|           |                                              |                                             |                         |
|           | system: 10.0.0.11/32                         | loopback0: 10.0.0.33/32                     | loopback0: 10.0.0.22/32 |
|                                                                                                                                  |
|           <-----------BGP:VPNV4_UNI/VPNV6_UNI------------x-----------BGP:VPNV4_UNI/VPNV6_UNI----------->                         |
|           <-----------------------------------BGP:VPNV4_UNI/VPNV6_UNI---------------------------------->                         |
|                                                                                                                                  |
|                                                                                                                                  |
|                                       ISIS 0 (CORE) / level-2 / Segment Routing                                                  |
|                                                                                                                                  |
+----------------------------------------------------------------------------------------------------------------------------------+

 

All the interconnect links as well as system interface or loopback 0 will be part of ISIS process called CORE on Cisco XR3 and Arista EOS2 and having ID 0 at Nokia SR1. The BGP process will be configure in a full-mesh manner between loopbacks 0 and system interface at PE routers for VPNv4/VPNv6 unicast address families (AFI/SAFI: 1/128, 2/128).

Initial configuration you can find on my GitHub page.

Configuration of underlay infrastructure for Arista, Cisco, Nokia: MPLS data plane (ISIS-SR)

Let’s get started. First of all, we need to configure IGP to provide connectivity between all the loopbacks 0 and system interface of the routers so that we can establish full-mesh iBGP later on. As we need to establish BGP only loopbacks, we announce only passive interfaces and we make loopbacks 0 and system interface as passive interface in ISIS. Also we configure Segment Routing now to establish working MPLS data plane for traffic forwarding. The good point is that the configuration is fairly simple as you can see below.

The first in a row is the ISIS and Segment Routing configuration for Arista EOS based network function EOS2 running EOS 4.21.1.1F:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
EOS2#show run
! Command: show running-config
! device: EOS2 (vEOS, EOS-4.21.1.1F)
!
service routing protocols model multi-agent
!
mpls ip
!
router isis CORE
   net 49.0000.0100.0000.0022.00
   is-type level-2
   log-adjacency-changes
   advertise passive-only
   !
   address-family ipv4 unicast
   !
   segment-routing mpls
      router-id 10.0.0.22
      no shutdown
      prefix-segment 10.0.0.22/32 index 22
!
interface Loopback0
   isis enable CORE
   isis passive
!
interface Ethernet1
   isis enable CORE
   isis network point-to-point
!
interface Ethernet2
   isis enable CORE
   isis network point-to-point
!
end

 

For some of, you have the experience with different Cisco products, the configuration is pretty simple and well-known. We’ve discussed this earlier in data-center articles. The key point is to enable ISIS on all the respective interfaces and to announce loopback with associated prefix SID for Segment Routing. Also, pay attention that segment routing requires additional router-id within the process.

You can’t change metric-style, it is wide by default, so make sure other routers have the same metric style.

The second station in the configuration journey is the ISIS and Segment Routing configuration for Nokia SR OS based network function SR1 running SR OS 16.0.R4 in model-driven mode:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
*(gl)[]
A:admin@SR1# compare
    configure {
        router "Base" {
+           router-id 10.0.0.11
+           mpls-labels {
+               sr-labels {
+                   start 500000
+                   end 524287
+               }
+           }
+           isis 0 {
+               admin-state enable
+               advertise-passive-only true
+               advertise-router-capability as
+               level-capability 2
+               area-address [49.0000]
+               segment-routing {
+                   admin-state enable
+                   tunnel-table-pref 8
+                   prefix-sid-range {
+                       global
+                   }
+               }
+               interface "system" {
+                   admin-state enable
+                   passive true
+                   ipv4-node-sid {
+                       index 11
+                   }
+               }
+               interface "toEOS2" {
+                   admin-state enable
+                   interface-type point-to-point
+               }
+               interface "toXR3" {
+                   admin-state enable
+                   interface-type point-to-point
+               }
+               level 2 {
+                   wide-metrics-only true
+               }
+           }
        }
    }

 

In greater details the configuration of ISIS at Nokia SR OS and Segment Routing in Nokia SR OS was explained earlier. What is new here is the 16.0.R4 version, so you can see that some commands are new or have different format.

Don’t forget to define MPLS label range for Segment Routing

The last point in creation of the ISIS-SR underlay is the configuration of ISIS and Segment Routing for Cisco IOS XR based network function XR3 (the 3rd PE) running XR 6.1.2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
RP/0/0/CPU0:XR3(config)#show conf
Sun Nov 25 10:56:32.538 UTC
Building configuration...
!! IOS XR Configuration 6.1.2
!! Last configuration change at Sun Nov 25 10:56:15 2018 by cisco
!
router isis CORE
 is-type level-2-only
 net 49.0000.0100.0000.0033.00
 log adjacency changes
 address-family ipv4 unicast
  metric-style wide
  advertise passive-only
  segment-routing mpls sr-prefer
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
   prefix-sid index 33
  !
 !
 interface GigabitEthernet0/0/0/0.13
  point-to-point
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
  !
 !
!
end

 

Again, both ISIS and SR were explained in greater details earlier, so here we just do the same set of commands we’ve done already twice today, now in Cisco IOS XR language.

After the configuration of ISIS and Segment Routing is done, the next logical step is to make some verifications. The first one is to check the ISIS adjacency to see if the routers are connected to each other. The following example shows such verification of ISIS neighbors in Arista EOS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
EOS2# show isis neighbors detail

Instance  VRF      System Id        Type Interface          SNPA              State Hold time   Circuit Id
CORE      default  SR1              L2   Ethernet1          P2P               UP    19          00
  Area Address(es): 49.0000
  SNPA: P2P
  Advertised Hold Time: 27
  State Changed: 00:17:13 ago
  IPv4 Interface Address: 10.11.22.11
  IPv6 Interface Address: none
  Interface name: Ethernet1.12
  Graceful Restart: Not Supported
  Segment Routing Enabled
    Router ID: 10.0.0.11
    SRGB Base: 500000 Range: 24288
    Adjacency Label IPv4: 100000

CORE      default  XR3              L2   Ethernet2          P2P               UP    25          00
  Area Address(es): 49.0000
  SNPA: P2P
  Advertised Hold Time: 30
  State Changed: 01:14:19 ago
  IPv4 Interface Address: 10.22.33.33
  IPv6 Interface Address: none
  Interface name: Ethernet2
  Graceful Restart: Supported
  Segment Routing Enabled
    Router ID: 10.0.0.33
    SRGB Base: 16000 Range: 8000
    Adjacency Label IPv4: 116384

 

You can (and probably should) do the same check on 2 other vendors. Below you have the commands to get the same information for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR:

1
2
3
A:admin@SR1# show router isis adjacency detail

RP/0/0/CPU0:XR3#show isis neighbors detail

 

The output is truncated in order to reduce the length of the article. It’s just important to understand how the same information can be viewed on different platforms

The first verification step is successful, so we move further. After the ISIS adjacency is established, you should check, what information is distributed via ISIS and contained in ISIS LSDB (link-state data base. The following example shows, how to review the content of ISIS database in Cisco IOS XR:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
RP/0/0/CPU0:XR3#show isis database verbose
Sun Nov 25 10:57:22.284 UTC

IS-IS CORE (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
EOS2.00-00            0x0000000c   0x6d54        1142            0/0/0
  Area Address:   49.0000
  NLPID:          0xcc
  Metric: 10         IS-Extended XR3.00
    ADJ-SID: F:0 B:0 V:1 L:1 S:0 weight:0 Adjacency-sid:116384
    Neighbor IP Address: 10.22.33.33
    Interface IP Address: 10.22.33.22
  Router Cap:     10.0.0.22, D:0, S:0
    Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 16
  Hostname:       EOS2
  IP Address:     10.22.33.22
  IP Address:     10.11.22.22
  IP Address:     10.0.0.22
  Metric: 10         IP-Extended 10.0.0.22/32
    Prefix-SID Index: 22, Algorithm:0, R:0 N:0 P:0 E:0 V:0 L:0
SR1.00-00             0x0000000c   0x91bc        746             0/0/0
  Area Address:   49.0000
  NLPID:          0xcc
  Hostname:       SR1
  Router ID:      10.0.0.11
  Router Cap:     10.0.0.11, D:0, S:0
    TE PCE Discovery (Old):
      PCE sub TLV 232: Length 2 <Unknown TLV>
    Segment Routing: I:1 V:1, SRGB Base: 500000 Range: 24288
    SubTLV 19Length: 1
  IP Address:     10.0.0.11
  IP Address:     10.11.22.11
  IP Address:     10.11.33.11
  Metric: 10         IS-Extended XR3.00
    Interface IP Address: 10.11.33.11
    Neighbor IP Address: 10.11.33.33
    ADJ-SID: F:0 B:0 V:1 L:1 S:0 weight:0 Adjacency-sid:499998
  Metric: 0          IP-Extended 10.0.0.11/32
    Prefix-SID Index: 11, Algorithm:0, R:0 N:1 P:1 E:0 V:0 L:0
XR3.00-00           * 0x00000004   0x1307        1145            0/0/0
  Area Address:   49.0000
  NLPID:          0xcc
  Hostname:       XR3
  IP Address:     10.0.0.33
  Router Cap:     10.0.0.33, D:0, S:0
    Segment Routing: I:1 V:0, SRGB Base: 16000 Range: 8000
  Metric: 10         IS-Extended EOS2.00
    Interface IP Address: 10.22.33.33
    Neighbor IP Address: 10.22.33.22
    ADJ-SID: F:0 B:1 V:1 L:1 S:0 weight:0 Adjacency-sid:24000
    ADJ-SID: F:0 B:0 V:1 L:1 S:0 weight:0 Adjacency-sid:24001
  Metric: 0          IP-Extended 10.0.0.33/32
    Prefix-SID Index: 33, Algorithm:0, R:0 N:1 P:0 E:0 V:0 L:0

 Total Level-2 LSP count: 3     Local Level-2 LSP count: 1

 

The most important information for us (besides IP addresses of loopbacks/system interface) is range of Segment Routing labels expressed as “SRGB Base” and “SRGB Range” and Prefix-SID index for loopback/system prefixes.

The same information is collected at Nokia (Alcatel-Lucent) SR OS and Arista EOS network functions using the following commands:

1
2
3
A:admin@SR1# show router isis database detail

EOS2#show isis database detail

 

The last point in this verification process is to check, what we have in LFIB (Label forwarding information base – MPLS data plane) as these labels associated with IP addresses of loopbacks/system interfaces will be used for actual data forwarding. The following examples show such check in Nokia SR OS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
A:admin@SR1# show router tunnel-table detail

===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination      : 10.0.0.22/32
NextHop          : 10.11.22.22
Tunnel Flags     : entropy-label-capable
Age              : 00h38m11s
CBF Classes      : (Not Specified)
Owner            : isis (0)             Encap            : MPLS
Tunnel ID        : 524290               Preference       : 8
Tunnel Label     : 3                    Tunnel Metric    : 20
Tunnel MTU       : 9190                 Max Label Stack  : 1
-------------------------------------------------------------------------------
Destination      : 10.0.0.33/32
NextHop          : 10.11.33.33
Tunnel Flags     : entropy-label-capable
Age              : 00h37m23s
CBF Classes      : (Not Specified)
Owner            : isis (0)             Encap            : MPLS
Tunnel ID        : 524292               Preference       : 8
Tunnel Label     : 3                    Tunnel Metric    : 10
Tunnel MTU       : 9190                 Max Label Stack  : 1
-------------------------------------------------------------------------------
Destination      : 10.11.22.22/32
NextHop          : 10.11.22.22
Tunnel Flags     : is-adjacency-tunnel
Age              : 00h40m49s
CBF Classes      : (Not Specified)
Owner            : isis (0)             Encap            : MPLS
Tunnel ID        : 524289               Preference       : 8
Tunnel Label     : 3                    Tunnel Metric    : 0
Tunnel MTU       : 9190                 Max Label Stack  : 1
-------------------------------------------------------------------------------
Destination      : 10.11.33.33/32
NextHop          : 10.11.33.33
Tunnel Flags     : is-adjacency-tunnel
Age              : 00h37m29s
CBF Classes      : (Not Specified)
Owner            : isis (0)             Encap            : MPLS
Tunnel ID        : 524291               Preference       : 8
Tunnel Label     : 3                    Tunnel Metric    : 0
Tunnel MTU       : 9190                 Max Label Stack  : 1
-------------------------------------------------------------------------------
Number of tunnel-table entries          : 4
Number of tunnel-table entries with LFA : 0
===============================================================================

 

It’s crucial to have the first two routes as later on system/loopback interfaces will be used as BGP next-hops, hence we need to have MPLS labels for them You see that the label value is “3” both for Arista EOS and Cisco IOS XR based routers, as both of them performs PHP (penultimate-hop-popping) meaning removing of MPLS transport label on previous hop to itself to make less lookup operations.

The following commands are used in Cisco IOS XR and Arista EOS routers to obtain the same information about LFIB:

1
2
3
EOS2#show mpls lfib route

RP/0/0/CPU0:XR3#show mpls forwarding detail

 

The first level of configuration accompanied with corresponding verification is done and we can proceed further with multiprotocol BGP (MP-BGP) for VPNv4/VPNv6 unicast address families (AFI/SAFI 1/128 and 2/128).

Configuration of underlay infrastructure for Arista, Cisco, Nokia: services (MP-BGP)

In this point we’ll configure full-mesh iBGP peering between loopback0/system interfaces of SR1, EOS2 and XR3. We don’t use any kind of route reflectors, because in such a small deployment it is just not necessary. There are also no useful feature, as BFD or authentication provided, as it isn’t the focus of the article, but for sure you can use them as explained earlier.

We start with the configuration of MP-BGP for VPNv4/VPNv6 unicast address family (AFI/SAFI 1/128, 2/128) for Nokia SR OS based network function SR1 running SR OS 16.0.R4 in model-driven CLI:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
A:admin@SR1# compare
    configure {
        router "Base" {
+           autonomous-system 65000
+           bgp {
+               admin-state enable
+               next-hop-resolution {
+                   labeled-routes {
+                       transport-tunnel {
+                           family vpn {
+                               resolution filter
+                               resolution-filter {
+                                   sr-isis true
+                               }
+                           }
+                       }
+                   }
+               }
+               group "iBGP_PEERS" {
+                   peer-as 65000
+                   local-address "10.0.0.11"
+                   family {
+                       vpn-ipv4 true
+                       vpn-ipv6 true
+                   }
+               }
+               neighbor "10.0.0.22" {
+                   group "iBGP_PEERS"
+               }
+               neighbor "10.0.0.33" {
+                   group "iBGP_PEERS"
+               }
+           }
        }
    }

 

As you can see the configuration of BGP in Nokia SR OS 16.0.R4 for BGP has significantly changed since previous version. Now it’s more similar to the Cisco IOS XR structure in terms that peer-group is configured and then it’s assigned to neighbor as an attribute, not the vice versa as it was. What is also important here is the “next-hop-resolution” context, as we define there, which MPLS LSPs should be used. ISIS-SR is chosen as we have configured it earlier in this article.

The second PE router waits to get BGP. Hence we proceed with configuration of MP-BGP for VPNv4/VPNv6 unicast address family (AFI/SAFI 1/128, 2/128) for Cisco IOS XR based network function XR3 running IOS XR 6.1.2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
RP/0/0/CPU0:XR3(config)#show conf
Sun Nov 25 11:02:42.153 UTC
Building configuration...
!! IOS XR Configuration 6.1.2
router bgp 65000
 bgp router-id 10.0.0.33
 bgp log neighbor changes detail
 address-family vpnv4 unicast
 !
 address-family vpnv6 unicast
 !
 session-group SG_iBGP_PEER
  remote-as 65000
  update-source Loopback0
 !
 neighbor-group iBGP_PEER
  use session-group SG_iBGP_PEER
  address-family vpnv4 unicast
  !
  address-family vpnv6 unicast
  !
 !
 neighbor 10.0.0.11
  use neighbor-group iBGP_PEER
 !
 neighbor 10.0.0.22
  use neighbor-group iBGP_PEER
 !
!
end

 

In Cisco IOS XR you don’t need to configure next-hop resolution policy, as it takes by default route from LFIB of it exists. As we have only ISIS-SR, there is no problem. The rest of the configuration is identical (conceptually). Also, as you see, Cisco IOS XR uses “interface loopback” source instead of particular “IP address” as Nokia SR OS does.

The last point in the construction of the underlay infrastructure is the 3rd PE, which is EOS2 this time. So, here is the configuration of MP-BGP for VPNv4/VPNv6 unicast address family (AFI/SAFI 1/128, 2/128) for Arista EOS based network function EOS2 running EOS 4.21.1.F:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
EOS2#show run
! Command: show running-config
! device: EOS2 (vEOS, EOS-4.21.1.1F)
!
service routing protocols model multi-agent
!
router bgp 65000
   router-id 10.0.0.22
   neighbor iBGP_PEERS peer-group
   neighbor iBGP_PEERS remote-as 65000
   neighbor iBGP_PEERS update-source Loopback0
   neighbor iBGP_PEERS send-community standard extended
   neighbor iBGP_PEERS maximum-routes 12000
   neighbor 10.0.0.11 peer-group iBGP_PEERS
   neighbor 10.0.0.33 peer-group iBGP_PEERS
   !
   address-family ipv4
      no neighbor iBGP_PEERS activate
   !
   address-family vpn-ipv4
      neighbor iBGP_PEERS activate
   !
   address-family vpn-ipv6
      neighbor iBGP_PEERS activate
!
end

 

The first important thing is enable multi address-family capabilities, what Arista calls ArBGP or Arista BGP by “service routing protocols model multi-agent”. It’s important to make IP VPN working.

The configuration of Arista EOS is different both Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. First of all, you configure the parameters of the session, which is also possible with peer groups as provided. Then you need you to activate per address-family the neighbors as by default only IPv4 unicast is activated, which we need to deactivate by the way.

After the configuration is performed, we need to make sure that it works properly. The basic, and probably the most useful check, is to see if the BGP sessions are built. The example below shows how to review the status of BGP neighbors for dedicated address families in Arista EOS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
EOS2#show bgp vpn-ipv4 summary
BGP summary information for VRF default
Router identifier 10.0.0.22, local AS number 65000
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  10.0.0.11        4  65000              3         3    0    0 00:00:20 Estab  2      2
  10.0.0.33        4  65000             79        92    0    0 01:13:22 Estab  2      2


EOS2#show bgp vpn-ipv6 summary
BGP summary information for VRF default
Router identifier 10.0.0.22, local AS number 65000
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  10.0.0.11        4  65000              3         3    0    0 00:00:26 Estab  2      2
  10.0.0.33        4  65000             79        92    0    0 01:13:38 Estab  2      2

 

To get the information about BGP peering in Nokia SR OS and Cisco IOS XR use the following commands:

1
2
3
4
A:admin@SR1# show router bgp summary

RP/0/0/CPU0:XR3#show bgp vpnv4 unicast summary
RP/0/0/CPU0:XR3#show bgp vpnv6 unicast summary

 

As you see, both in Arista EOS and Cisco IOS XR you review the peering per respective address family, whereas in Nokia (Alcatel-Lucent) SR OS all the active address-families per neighbors will be listed in a single output.

So far so good. By this time, we have fully configured underlying SP WAN, so we need to configure service on top now.

Configuration of overlay services (IP VPN)

To create any service overlay, we need to define the service topology. The following ASCII scheme explains it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
                           +++ Int:  toCUST                            +++ Int:  GigabitEthernet0/0/0/0.333
                            |  IPv4: 192.168.11.1/24                    |  IPv4: 192.168.33.1/24
                            |  IPv6: fc00::192:168:11:1/112             |  IPv6: fc00::192:168:33:1/112
                  +---------+----------+                      +---------+----------+
      +           | VRF: CUST          |                      | VRF: CUST          |           +
      +-----------+ RD:  10.0.0.11:123 +--+                +--+ RD:  10.0.0.33:123 +-----------+
      +           | RT:  65000:123     |  |                |  | RT:  65000:123     |           +
Int:  Loopback123 +---------+----------+  |                |  +---------+----------+Int:  Loopback123
IPv4: 192.168.1.11/32       |     SR1     +----------------+    XR3     |           IP^4: 192.168.1.33/32
IPv6: fc00::192:168:1:11/128|             |                |            |           IPv6: fc00::192:168:1:33/128
                            +------+------+                +-----+------+
                                   |                             |
                                   |        MPLS / ISIS-SR       |
                                   |                             |
                                   |       +--------------+      |
                                   +-------+              +------+
                                           |    EOS2      |
                                        +--+--------------+--+
        Int:  Ethernet3             +   | VRF: CUST          |   +Int:  Loopback123
        IPv4: 192.168.22.1/24       +---+ RD:  10.0.0.22:123 +---+IPv4: 192.168.1.22/32
        IPv6: fc00::192:168:22:1/112+   | RT:  65000:123     |   +IPv6: fc00::192:168:1:22/128

 

Now we just need to implement that service. This time we starts with theconfiguration of customer-facing VRF at Cisco IOS XR based network function XR3 running IOS XR 6.1.2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
RP/0/0/CPU0:XR3(config)#show conf
Sun Nov 25 11:05:05.583 UTC
Building configuration...
!! IOS XR Configuration 6.1.2
vrf CUST
 address-family ipv4 unicast
  import route-target
   65000:123
  !
  export route-target
   65000:123
  !
 !
 address-family ipv6 unicast
  import route-target
   65000:123
  !
  export route-target
   65000:123
  !
 !
!
interface GigabitEthernet0/0/0/0.333
 vrf CUST
 ipv4 address 192.168.33.1 255.255.255.0
 ipv6 address fc00::192:168:33:1/112
 encapsulation dot1q 333
!
interface Loopback123
 vrf CUST
 ipv4 address 192.168.1.33 255.255.255.255
 ipv6 address fc00::192:168:1:33/128
!
router bgp 65000
 vrf CUST
  rd 10.0.0.33:123
  address-family ipv4 unicast
   redistribute connected
  !
  address-family ipv6 unicast
   redistribute connected
  !
 !
!
end

 

The configuration is quite straightforward, we need to define VRF name, RD/RT, interfaces and instruct BGP to redistribute connected subnets. All of these things we’ve done earlier.

The next step is to bring the configuration of customer-facing VRF to Arista EOS based network function EOS2 running EOS 4.21.1.1F:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
EOS2#show run
! Command: show running-config
! device: EOS2 (vEOS, EOS-4.21.1.1F)
!
vrf definition CUST
!
interface Ethernet2
   logging event link-status
   no switchport
   vrf forwarding CUST
   ip address 192.168.22.1/24
   ipv6 address fc00::192:168:22:1/112
!
interface Loopback123
   vrf forwarding CUST
   ip address 192.168.1.22/32
   ipv6 address fc00::192:168:1:22/128
!
ip routing vrf CUST
!
ipv6 unicast-routing
ipv6 unicast-routing vrf CUST
!
router bgp 65000
   vrf CUST
      rd 10.0.0.22:123
      route-target import vpn-ipv6 65000:123
      route-target import vpn-ipv4 65000:123
      route-target export vpn-ipv6 65000:123
      route-target export vpn-ipv4 65000:123
      redistribute connected
!
end

 

Important! In order the traffic can reach loopback there must be at least one physical interface in active states assigned to the same VRF. Without it the traffic will be dropped by Arista EOS

The configuration could be a bit misleading on the first time, but it’s quite easy as well. You need to define VRF in a global configuration context without any parameters. Then you add interfaces to that VRF. Make sure you add interfaces to VRF prior to assignment of IP addresses, otherwise they will be removed. After that you need to enable routing within VRF for IPv4 and IPv6 separately (Arista is a switch, hence you need enable routing. And finally you define all the BGP related parameters within VRF context in BGP configuration. Pay attention that RTs for IPv4 and IPv6 addresses are configured separately. On the other hand, the command “redistribute connected” works both for IPv4 and IPv6 address families simultaneously.

Finally, we configure the customer-facing VRF at Nokia SR OS based network function SR1 running SR OS 16.0.R4:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
A:admin@SR1# compare
    configure {
+       port 1/1/c2/1 {
+           admin-state enable
+           ethernet {
+               mode access
+               encap-type dot1q
+           }
+       }
+       service {
+           vprn "CUST" {
+               admin-state enable
+               service-id 123
+               customer "1"
+               route-distinguisher "10.0.0.11:123"
+               vrf-target {
+                   community "target:65000:123"
+               }
+               auto-bind-tunnel {
+                   resolution any
+               }
+               interface "test_lo" {
+                   admin-state enable
+                   loopback true
+                   ipv4 {
+                       primary {
+                           address 192.168.1.11
+                           prefix-length 32
+                       }
+                   }
+                   ipv6 {
+                       address fc00::192:168:1:11 {
+                           prefix-length 128
+                       }
+                   }
+               }
+               interface "toCUST" {
+                   admin-state enable
+                   ipv4 {
+                       primary {
+                           address 192.168.11.1
+                           prefix-length 24
+                       }
+                   }
+                   sap 1/1/c2/1:111 {
+                   }
+                   ipv6 {
+                       address fc00::192:168:11:1 {
+                           prefix-length 112
+                       }
+                   }
+               }
+           }
+       }
    }

 

As you remember, the customers port in Nokia (Alactel-Lucent) SR OS require that physical port has “ethernet mode access” and the rest of the configuration is done within the VRF itself. Pay attention that since SR OS16.* the naming structure of the services (vprn, vpls, etc) has changed so that they have “name” now instead of “id”.

As soon as the configuration for the service is done everywhere, the customer routes starts being distributed between the PE routers. The snippet below shows the verification of BGP routes for VPNv4/VPNv6 address families at Arista EOS based network function EOS2 running Arista 4.21.1.1F:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
EOS2#show bgp vpn-ipv4
BGP routing table information for VRF default
Router identifier 10.0.0.22, local AS number 65000
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
                    S - Stale, c - Contributing to ECMP, b - backup
                    % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

         Network             Next Hop         Metric  LocPref Weight Path
 * >     RD: 10.0.0.11:123 IPv4 prefix 192.168.1.11/32
                             10.0.0.11        -       100     0       i
 * >     RD: 10.0.0.22:123 IPv4 prefix 192.168.1.22/32
                             -                0       -       0       i
 * >     RD: 10.0.0.33:123 IPv4 prefix 192.168.1.33/32
                             10.0.0.33        0       100     0       ?
 * >     RD: 10.0.0.11:123 IPv4 prefix 192.168.11.0/24
                             10.0.0.11        -       100     0       i
 * >     RD: 10.0.0.22:123 IPv4 prefix 192.168.22.0/24
                             -                -       -       0       i
 * >     RD: 10.0.0.33:123 IPv4 prefix 192.168.33.0/24
                             10.0.0.33        -       100     0       ?


EOS2#show bgp vpn-ipv6
BGP routing table information for VRF default
Router identifier 10.0.0.22, local AS number 65000
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
                    S - Stale, c - Contributing to ECMP, b - backup
                    % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

         Network             Next Hop         Metric  LocPref Weight Path
 * >     RD: 10.0.0.11:123 IPv6 prefix fc00::192:168:1:11/128
                             ::ffff:10.0.0.11
                                              -       100     0       i
 * >     RD: 10.0.0.22:123 IPv6 prefix fc00::192:168:1:22/128
                             -                0       -       0       i
 * >     RD: 10.0.0.33:123 IPv6 prefix fc00::192:168:1:33/128
                             ::ffff:10.0.0.33
                                              0       100     0       ?
 * >     RD: 10.0.0.11:123 IPv6 prefix fc00::192:168:11:0/112
                             ::ffff:10.0.0.11
                                              -       100     0       i
 * >     RD: 10.0.0.22:123 IPv6 prefix fc00::192:168:22:0/112
                             -                -       -       0       i
* >     RD: 10.0.0.33:123 IPv6 prefix fc00::192:168:33:0/112
                             ::ffff:10.0.0.33
                                              0       100     0       ?

 

The general structure of the routes is the same for both address families: you see respective RD and IPv4/IPv6 prefix. The BGP next-hop for remote routes are IPv4 addresses of the loopback0/system interfaces, which are used for BGP session construction. For IPv6 it’s encoded as “::ffff:ipv4_1st_octet.ipv4_2nd_octet.ipv4_3rd_octet.ipv4_4th_octet”. Also you can spot that both Arista EOS and Nokia (Alcatel-Lucent) SR OS are sending the routes with IGP “i” origin, whereas the Cisco sends incomplete “?”, which is caused by “redistribute connected” behavior on Cisco IOS XR platform.

The same information about BGP VPNv4/VPNv6 unicast routes can be obtained on Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR using the following commands:

1
2
3
4
5
6
A:admin@SR1# show router bgp routes vpn-ipv4
A:admin@SR1# show router bgp routes vpn-ipv6


RP/0/0/CPU0:XR3#show bgp vpnv4 unicast
RP/0/0/CPU0:XR3#show bgp vpnv6 unicast

 

For Nokia SR OS only received routes are shown, check the respective article for more details.

The topology, both underlay and overlay, is created and we need to do just the last thing that is verification of data plane. By the end of the day, only it matters, as that is something the customers expect from your network: packet forwarding.

Verification of connectivity

Before we will really push the packets on the network, we will verify the routing tables on all the routers to make sure that the routes are installed and how the packets will be forwarded over the network

As Arista EOS is newcomer to this world, let’s start with it. The following output explains the verification of routing for VRF from Arista EOS based network function EOS2 running EOS 4.21.1.1F:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
EOS2#show ip route vrf CUST
VRF: CUST
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
       O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
       NG - Nexthop Group Static Route, V - VXLAN Control Service,
       DH - DHCP client installed default route, M - Martian,
       DP - Dynamic Policy Route

Gateway of last resort is not set

 B I    192.168.1.11/32 [200/0] via 10.0.0.11/32, IS-IS SR tunnel index 2, label 499999
                                   via 10.11.22.11, Ethernet1, label 500011
 C      192.168.1.22/32 is directly connected, Loopback123
 B I    192.168.1.33/32 [200/0] via 10.0.0.33/32, IS-IS SR tunnel index 1, label 24002
                                   via 10.22.33.33, Ethernet2, label imp-null(3)
 B I    192.168.11.0/24 [200/0] via 10.0.0.11/32, IS-IS SR tunnel index 2, label 499999
                                   via 10.11.22.11, Ethernet1, label 500011
 C      192.168.22.0/24 is directly connected, Ethernet3
 B I    192.168.33.0/24 [200/0] via 10.0.0.33/32, IS-IS SR tunnel index 1, label 24002
                                   via 10.22.33.33, Ethernet2, label imp-null(3)


EOS2#show ipv6 route vrf CUST
VRF: CUST
Displaying 3 of 6 IPv6 routing table entries
Codes: C - connected, S - static, K - kernel, O3 - OSPFv3, B - BGP, R - RIP, A B - BGP Aggregate, I L1 - IS-IS level 1, I L2 - IS-IS level 2, DH - DHCP, NG - Nexthop Group Static Route, M - Martian, DP - Dynamic Policy Route

 B    fc00::192:168:1:11/128 [200/0]
       via 10.0.0.11/32, IS-IS SR tunnel index 2, label 499999
          via 10.11.22.11, Ethernet1, label 500011
 C    fc00::192:168:1:22/128 [0/0]
       via Loopback123, directly connected
 B    fc00::192:168:1:33/128 [200/0]
       via 10.0.0.33/32, IS-IS SR tunnel index 1, label 24003
          via 10.22.33.33, Ethernet2, label imp-null(3)
 B    fc00::192:168:11:0/112 [200/0]
       via 10.0.0.11/32, IS-IS SR tunnel index 2, label 499999
          via 10.11.22.11, Ethernet1, label 500011
 C    fc00::192:168:22:0/112 [0/0]
       via Ethernet3, directly connected
 B    fc00::192:168:33:0/112 [200/0]
       via 10.0.0.33/32, IS-IS SR tunnel index 1, label 24003
          via 10.22.33.33, Ethernet2, label imp-null(3)

 

You can see that output is very rich in terms of provided information. Basically, Arista is the single vendor who provides all the relevant information such as IP prefix, MPLS service label, MPLS transport label, next-hop and outgoing interface in a single output of the routing table. You see that such detailed information is provided both for IPv4 and IPv6 address families. It doesn’t mean that other vendors can’t provide such details, but they provide it rather on request per particular prefix.

This time we’ll show the same details for other vendors without shortcuts, so that you can compare the level of details Below you can find the verification of routing for VRF from Nokia SR OS based network function SR1 running SR OS 16.0.R4:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
A:admin@SR1# show router service-name "CUST" route-table family ipv4

===============================================================================
Route Table (Service: 123)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric  
-------------------------------------------------------------------------------
192.168.1.11/32                               Local   Local     00h12m06s  0
       test_lo                                                      0
192.168.1.22/32                               Remote  BGP VPN   00h11m31s  170
       10.0.0.22 (tunneled:SR-ISIS:0)                               20
192.168.1.33/32                               Remote  BGP VPN   00h14m09s  170
       10.0.0.33 (tunneled:SR-ISIS:0)                               10
192.168.11.0/24                               Local   Local     00h11m40s  0
       toCUST                                                       0
192.168.22.0/24                               Remote  BGP VPN   00h11m31s  170
       10.0.0.22 (tunneled:SR-ISIS:0)                               20
192.168.33.0/24                               Remote  BGP VPN   00h00m20s  170
       10.0.0.33 (tunneled:SR-ISIS:0)                               10
-------------------------------------------------------------------------------
No. of Routes: 6
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================


A:admin@SR1# show router service-name "CUST" route-table family ipv6
===============================================================================
IPv6 Route Table (Service: 123)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric  
-------------------------------------------------------------------------------
fc00::192:168:1:11/128                        Local   Local     00h12m07s  0
       test_lo                                                      0
fc00::192:168:1:22/128                        Remote  BGP VPN   00h11m33s  170
       10.0.0.22 (tunneled:SR-ISIS:0)                               20
fc00::192:168:1:33/128                        Remote  BGP VPN   00h29m06s  170
       10.0.0.33 (tunneled:SR-ISIS:0)                               10
fc00::192:168:11:0/112                        Local   Local     00h11m42s  0
       toCUST                                                       0
fc00::192:168:22:0/112                        Remote  BGP VPN   00h11m33s  170
       10.0.0.22 (tunneled:SR-ISIS:0)                               20
fc00::192:168:33:0/112                        Remote  BGP VPN   00h15m17s  170
       10.0.0.33 (tunneled:SR-ISIS:0)                               10
-------------------------------------------------------------------------------
No. of Routes: 6
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================

 

The first thing that the people familiar with Nokia SR OS should point out is that the VPRN is called by “name”, not by “service id”. It’s a change in 16.0.R* SR OS release. Now, the level of the details is lower here comparing to Arista EOS, as you don’t see the MPLS service and transport levels here. But you can obtain those details by using “show router bgp routes vpn-ipv4 rd 10.0.0.33:123” and “show router tunnel-table ip-prefix-mask 10.0.0.33/32 detail” commands for a particular prefix.

The last but not least is the verification of routing for VRF from Cisco IOS XR based network function XR3 running IOS XR 6.1.2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
RP/0/0/CPU0:XR3#show route vrf CUST ipv4
Sun Nov 25 13:17:28.004 UTC

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP
       A - access/subscriber, a - Application route
       M - mobile route, r - RPL, (!) - FRR Backup path

Gateway of last resort is not set

B    192.168.1.11/32 [200/0] via 10.0.0.11 (nexthop in vrf default), 00:17:12
L    192.168.1.33/32 is directly connected, 00:19:13, Loopback123
B    192.168.11.0/24 [200/0] via 10.0.0.11 (nexthop in vrf default), 00:17:12
C    192.168.33.0/24 is directly connected, 00:01:25, GigabitEthernet0/0/0/0.333
L    192.168.33.1/32 is directly connected, 00:01:25, GigabitEthernet0/0/0/0.333


RP/0/0/CPU0:XR3#show route vrf CUST ipv6
Sun Nov 25 13:18:04.031 UTC

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP
       A - access/subscriber, a - Application route
       M - mobile route, r - RPL, (!) - FRR Backup path

Gateway of last resort is not set

B    fc00::192:168:1:11/128
      [200/0] via ::ffff:10.0.0.11 (nexthop in vrf default), 00:17:48
L    fc00::192:168:1:33/128 is directly connected,
      00:19:49, Loopback123
B    fc00::192:168:11:0/112
      [200/0] via ::ffff:10.0.0.11 (nexthop in vrf default), 00:17:48
C    fc00::192:168:33:0/112 is directly connected,
      00:02:01, GigabitEthernet0/0/0/0.333
L    fc00::192:168:33:1/128 is directly connected,
      00:02:01, GigabitEthernet0/0/0/0.333

 

Here you see even less amount of information about particular e2e LSP construction in the routing table itself. To obtain further details, you need to take a look into CEF per interesting prefix as show below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
RP/0/0/CPU0:XR3#show cef vrf CUST 192.168.1.11/32
Mon Nov 26 17:19:30.820 UTC
192.168.1.11/32, version 5, internal 0x5000001 0x0 (ptr 0xa141a574) [1], 0x0 (0x0), 0x208 (0xa1583168)
 Updated Nov 26 17:18:26.255
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 10.0.0.11/32, 5 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xa15eb6f4 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    next hop 10.0.0.11/32 via 16011/0/21
     next hop 10.11.33.11/32 Gi0/0/0/0.13 labels imposed {500011 499999}


RP/0/0/CPU0:XR3#show cef vrf CUST ipv6 fc00::192:168:1:11/128
Mon Nov 26 17:20:09.677 UTC
fc00::192:168:1:11/128, version 5, internal 0x5000001 0x0 (ptr 0xa14000f4) [1], 0x0 (0x0), 0x208 (0xa15831b8)
 Updated Nov 26 17:18:26.254
 Prefix Len 128, traffic index 0, precedence n/a, priority 3
   via ::ffff:10.0.0.11/128, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xa17a3050 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    next hop ::ffff:10.0.0.11/128 via 16011/0/21
     next hop 10.11.33.11/32 Gi0/0/0/0.13 labels imposed {500011 499999}

 

As soon as the review of routing within VRF is done, we can start with the data plane itself. To do this, we are using traditional ping tool.

#1. EOS2 to XR3

The first case is to ping Cisco virtual router XR3 from Arista virtual router EOS2:

1
2
3
4
5
6
7
8
9
10
11
EOS2#ping vrf CUST ip 192.168.1.33
PING 192.168.1.33 (192.168.1.33) 72(100) bytes of data.
80 bytes from 192.168.1.33: icmp_seq=1 ttl=255 time=15.6 ms
80 bytes from 192.168.1.33: icmp_seq=2 ttl=255 time=20.1 ms
80 bytes from 192.168.1.33: icmp_seq=3 ttl=255 time=23.3 ms
80 bytes from 192.168.1.33: icmp_seq=4 ttl=255 time=36.8 ms
80 bytes from 192.168.1.33: icmp_seq=5 ttl=255 time=31.1 ms

--- 192.168.1.33 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 67ms
rtt min/avg/max/mdev = 15.629/25.445/36.896/7.651 ms, pipe 2, ipg/ewma 16.915/21.018 ms

 

The ping is successful, which is good. Also you can see the associated packet flow sniffed on the wire with Wireshark:

As you see, there is only MPLS service label visible as both Arista and Cisco IOS XR performs PHP.

#2. EOS2 to SR1

The second case is to check the connectivity between Arista EOS2 and Nokia SR1:

1
2
3
4
5
6
7
8
9
10
11
EOS2#ping vrf CUST ip 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 72(100) bytes of data.
80 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=18.5 ms
80 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=24.1 ms
80 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=27.9 ms
80 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=29.9 ms
80 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=30.3 ms

--- 192.168.1.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 76ms
rtt min/avg/max/mdev = 18.547/26.194/30.397/4.407 ms, pipe 2, ipg/ewma 19.095/22.641 ms

 

Again, the connectivity is working perfectly fine so we can take a look on wire:

Here you see the different situation comparing to the previous one, as Nokia SR OS doesn’t perform PHP by default, hence we you see EOS2 sending packets to SR1 with 2 labels (transport level segment routing and service level BGP).

#3. SR1 to XR3

The last but not least is the communication between Nokia SR1 and Cisco XR3:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
A:admin@SR1# //ping router-instance "CUST" 192.168.1.33
INFO: CLI #2051: Switching to the classic CLI engine
A:SR1# /ping router-instance "CUST" 192.168.1.33
PING 192.168.1.33 56 data bytes
64 bytes from 192.168.1.33: icmp_seq=1 ttl=255 time=6.90ms.
64 bytes from 192.168.1.33: icmp_seq=2 ttl=255 time=93.1ms.
64 bytes from 192.168.1.33: icmp_seq=3 ttl=255 time=3.62ms.
64 bytes from 192.168.1.33: icmp_seq=4 ttl=255 time=48.9ms.
64 bytes from 192.168.1.33: icmp_seq=5 ttl=255 time=4.01ms.

---- 192.168.1.33 PING Statistics ----
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 3.62ms, avg = 31.3ms, max = 93.1ms, stddev = 35.3ms
INFO: CLI #2052: Switching to the MD-CLI engine

 

As you see, in Nokia SR OS 16.0.R* another command is used for ping out of VRF comparing to previous.

From the Wireshark we see the expected output: 2 labels from XR3 to SR1, and one label back

All the verifications are done and our multivendor network with Nokia (Alcatel-Lucent) SR OS, Cisco IOS XR and Arista EOS network functions running ISIS with Segment Routing and BGP/MPLS VPN (IP VPN) on top are fully interoperable.

Final configuration files you can find at my GitHub page.

Lessons learned

Testing is a key answer for all interoperability questions. It’s not given that all the vendors will work with each other without problems. On the other side, you will never now, if they don’t until you test it.

Don’t be afraid and test your multi-vendor scenario. In the 99% cases you can get it working

Conclusion

So far we’ve done recap of Segment Routing with ISIS and IP VPN as an MPLS service on top. It’s working pretty well across Arista EOS, Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. In the next article we’ll take a look on Segment Routing with EVPN in the same multivendor environment. Take care and good bye!

Support us





P.S.

If you have further questions or you need help with your networks, I’m happy to assist you, just send me message. Also don’t forget to share the article on your social media, if you like it.

BR,

Anton Karneliuk