Install Arista EOS Swix

Reference:

• Arista's - "Package RPM into an Arista swix"
• Arista Extension ylb.jp

In the Linux world, RPM package is used for software installation. Simply put, the swix (software image extension) is a software package which contains multiple RPM files and a manifest file, which is used to install software or software patch on Arista EOS. 

Generally, a swix is installed in the following steps:

1. copy to local extension directory - "scp, copy"

2. install - "extension"

3. copy them to boot-extension - "copy"

4. if a modular system, install on the standby supervisor - "session"

5. restart agents or reset hardware components if required - "agent terminate"

Additionally, 

1. uninstall - "no extension"

2. remove packet - "delete" 

3. If both sup running mismatched swix, login console and reset boot-extension file

Below is the step by step:

Step 1 - copy

[admin@eosrouter flash]$ scp solomonyang@server:/users/solomonyang/swix/*swix /mnt/flash

patch.swix                                                                            100%   11MB  11.4MB/s   00:00

eosrouter#copy flash:patch.swix extension:

eosrouter#show extensions

Name                          Version/Release      Status      Extension

----------------------------- -------------------- ----------- ---------

patch.swix                    1.0.4 .              A, NI       6

A: available | NA: not available | I: installed | NI: not installed | F: forced

eosrouter#show extensions detail

       Name: patch.swix

    Version: 1.0.4

    Release: blahblah

   Presence: available

     Status: not installed
    Summary: SandFap agent related libs

   Packages:

 Total size: 0 bytes

Description: SandFap agent related libs.

Step 2 - install

eosrouter#extension patch.swix

eosrouter#show extensions

Name                          Version/Release      Status      Extension

----------------------------- -------------------- ----------- ---------

patch.swix                    1.0.4                A, I        6

Step 3 - copy to boot extension

eosrouter#show installed-extensions

patch.swix

eosrouter#show boot-extensions

eosrouter#copy installed-extensions boot-extensions

Copy completed successfully.

eosrouter#show boot-extensions

patch.swix

Step 4 - install them on standby sup

eosrouter#copy flash:patch.swix supervisor-peer:/mnt/flash

Copy completed successfully.

eosrouter#session peer-supervisor

Warning: Permanently added '[127.1.0.2]:3601' (RSA) to the list of known hosts.

WARNING - you are currently logged in to the standby supervisor.

Not all cli commands are available or supported. Configuration mode

is disabled for SSO.

s1:eosrouter#copy flash:patch.swix extension:

Copy completed successfully.

s1:eosrouter#extension patch.swix

s1:eosrouter#copy installed-extensions boot-extensions

Copy completed successfully.

Step 5 - restart agents or reset hardware component

For some software patches, it is required to restart software agents or hardware components to make patch effective. 

eosrouter#show agent names | grep SandFap

SandFap-Linecard3

SandFap-Linecard4

SandFap-Linecard5

eosrouter#agent SandFap-Linecard3 SandFap-Linecard4 SandFap-Linecard5 terminate

SandFap-Linecard3 was terminated

SandFap-Linecard4 was terminated

SandFap-Linecard5 was terminated

Also you need to do the same on the standby sup

How to fix unmatched swix'ed sup

If you run into unmatched swix supervisor due to mis-configuration, the way to fix them is as follows:

1. Login in the console of both supervisor. Sometimes the standby sup is at bad shape, then you have to fix it in Aboot mode

Arista Networks EOS 4.20.5.2F

localhost login: admin

[PyServer ar.Aaa not responding, still trying -- is it running?]

2. Reboot both and press ctrl-C to enter Aboot mode

3. Vi /mnt/flash/boot-extensions to remove swix entries. Then reboot so you will have a clean EOS w/o any extensions. 

Arista EOS - dot1q tunnel

There are 2 common use cases for dot1q tunnel:
1) Service providers tunnel customer's VLAN-tag traffic across different sites;
2) Lab harness switch for flexible connectivity between devices

But with one limitation: L2 control packets can't traverse. For example, "show lldp neighbor" on cd644 indicates yo412 instead of remote router. 

Arista BGP-LU/SR

In this blog, talking a bit about BGP-LU/SR and its use cases.  Here are some References:

Arista BGP-LU

• By the RFC 3107, the equivalent Cisco feature is called labeled BGP. The concept is quite simple to advertise an IPv4 prefix with a label. 
• Use case 1) - replace RSVP-TE, cloud provider
• Central controllers push routes with multiple label via BGP-LU
• Replace RSVP-TE
• Use case 2) - CSC
• ce1--pe1---asbr1--[--cPE1-----cPE2--]--asbr2---pe2--ce2
• between asbr and cPE, eBGP-LU, so cPEs know the label to reach PEs
• cPEs switch packets based on labels of PEs' loopback
• Configuration:
• router bgp 100
•   bgp labeled-unitcast rib tunnel|ip
•   neighbor 77.255.11.11 remote-as 100
•   neighbor 77.255.11.11 update-source lo77
•   address-family ipv4 labeled-unicast
•     neighbor 77.255.11.11 act
• show platform jericho mpls route
• Tunnel RIB vs IP RIB
• Mutli-agent vs GateD

Arista MPLS Segment Routing WP

• 3 segment routing approaches
• 1) Static mpls push + NHG
• prefix based - 100.1.1.0/24 -> NHG1 3.3.3.3 {2, 3, 5, 8}
• class based - 100.1.1.0/24 EF -> NHG1 3.3.3.3 {1,2,3}
• 2) EOS SDK by controller
• Listen: controller leans ISIS topology SIDs (node, adj, prefix) via ISISoGRE or BGP-LS (not supported by Arista EOS yet as of Feb 2019)
• Write: program SR multi-label stack tunnel using NHG
• 3) BGP-LU
• Listen: same as 2)
• Write: use BGP-LU

Arista MPLS VPN Step by Step (2c) L2VPN - Tcpdump

One powerful tool in Arista/EOS is tcpdump. In this setup, for example, if you see some traffic issue and want to see if the PE sending out the packets, you can do the tcpdump this way:

If you want to check the type 5 pw between CE1 and CE2, 

Step 1: find out the mpls ldp tunnel

PE1(config)#sh patch panel forwarding
In/Out                     Type CW VLAN Status Patch
-------------------------- ---- -- ---- ------ --------------------
....
Et47/3                        5         Up     ce1-ce2-pw5-1
   Label 132770, LDP Tun 5  <<< tunnel 5

Step 2: check mpls ldp tunnel 5 fwding info so have the interface name

PE1(config)#sh mpls ldp tunnel 5
   Index       Endpoint              Nexthop         Interface      Labels
----------- --------------------- --------------- ----------------- ----------
   5           88.255.22.22/32       88.1.11.1       Ethernet3/1    [ 100005 ]

Step 3: create the monitor session to dump packet to cpu

monitor session ldp-et3-1 source Ethernet3/1

monitor session ldp-et3-1 destination Cpu

Step 4: tcpdump the packet

bash tcpdump -nevvi mirror0 ether proto 0x8847 -w /mnt/flash/ldp.pcp

Arista MPLS VPN Step by Step (2c) L2VPN - Type 4 PW, MTU

In the LDP PW configuration, one thing needs to be careful is the MTU. You have to ensure the MTU along the underlying LSP matched. Here is an example:

So we have OSPF and ISIS enabled on VLAN 301/302 on CEs. But only OSPF up, no ISIS neighbor at all

CE1#sh ip os neighbor vrf ce1-pw4-301
Neighbor ID     VRF      Pri State                  Dead Time   Address         Interface
101.255.2.2     ce1-pw4-301 1   FULL/DR                00:00:32    101.101.101.2   Vlan301
CE1#sh isis neighbors vrf ce1-pw4-302
CE1#

Well the ping works as expected, CE1 can ping CE2's vlan 302 address - 102.102.102.2

CE1#ping vrf ce1-pw4-302 102.102.102.2
PING 102.102.102.2 (102.102.102.2) 72(100) bytes of data.
80 bytes from 102.102.102.2: icmp_seq=1 ttl=64 time=0.276 ms
80 bytes from 102.102.102.2: icmp_seq=2 ttl=64 time=0.119 ms
80 bytes from 102.102.102.2: icmp_seq=3 ttl=64 time=0.112 ms
80 bytes from 102.102.102.2: icmp_seq=4 ttl=64 time=0.111 ms
80 bytes from 102.102.102.2: icmp_seq=5 ttl=64 time=0.110 ms

--- 102.102.102.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.110/0.145/0.276/0.066 ms, ipg/ewma 0.202/0.208 ms

Both sides configured with MTU 9000

CE1#sh run int vlan 302
interface Vlan302
   mtu 9000
   vrf forwarding ce1-pw4-302
   ip address 102.102.102.1/24
   isis enable isis-ce1-pw4-302

CE2#sh run int vlan 302
interface Vlan302
   mtu 9000
   vrf forwarding ce2-pw4-302
   ip address 102.102.102.2/24
   isis enable isis-ce2-pw4-302

Let's try ping the destination with size of data plus DF-bit

CE1#ping vrf ce1-pw4-302 102.102.102.2 size 9000 df-bit
PING 102.102.102.2 (102.102.102.2) 8972(9000) bytes of data.
--- 102.102.102.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 40ms

Ok, it fails but where is the culprit?

PE1 and PE2 are good:

PE1(config-if-Et47/2)#sh ip int brief | grep 88
Ethernet3/1            88.1.11.11/24      up         up              9082
Ethernet45/3           88.3.11.11/24      down       down            9082

PE2(config-if-Et51/1)#sh ip int brief | grep 88
Ethernet33/1           88.4.22.22/24      up         up              9082
Ethernet51/1           88.2.22.22/24      up         up              9082

Let's move on to P routers:

P1#sh ip int brief | grep 88
Ethernet35/1           88.1.4.1/24        up         up              8000
Ethernet51/1           88.1.2.1/24        up         up              8000
Ethernet52/1           88.1.3.1/24        up         up              9082
Ethernet54/1           88.1.11.1/24       up         up              9082

Ok, here is the issue. Let's correct them and ISIS neighbor is up!

CE1#sh isis neighbors vrf ce1-pw4-302

Instance  VRF      System Id        Type Interface          SNPA              State Hold time   Circuit Id
isis-ce1- ce1-pw4- CE2              L2   Vlan302            44:4c:a8:11:6b:e1 UP    8           CE2.02

So, the reason is, the ISIS pads hello packet upto MTU and the oversized packets will be dropped siliently on underlying P routers. Hence ISIS fails to form neighbor. 

The OSPF just negotiates the MTU of connecting interfaces, which are 9000 in both sides, so ospf neighbor is up w/o any issues. But if you have a large LSA database, and ospf utilize the full MTU to transmit it, you will hit this MTU mismatch later, but not in the neigobor discoverage stage. 

How to detect a problem with 1 ECMP link

The ICMP packets are not hashed over ECMP path, which is shown in a quick test below on Arista EOS 4.20.8M. 

But we can use traceroute with multiple probes (Thanks for my buddy Janardhan Madabattular's idea), because the traceroute uses UDP with random port numbers.

And the traceroute has a limitation with 10 probes, so need to run multiple times for high-number-way ECMP existing. 

[admin@R1 ~]$ traceroute 3.3.3.3 -s 1.1.1.1 -q 10
traceroute to 3.3.3.3 (3.3.3.3), 30 hops max, 60 byte packets
 1  12.12.12.2 (12.12.12.2)  0.147 ms  0.078 ms  0.111 ms  0.069 ms  0.082 ms  0.068 ms  0.098 ms  0.072 ms  0.155 ms  0.089 ms

 2  3.3.3.3 (3.3.3.3)  0.116 ms *  0.064 ms *  0.069 ms  0.085 ms  0.167 ms  0.060 ms  0.073 ms  0.062 ms

R1(1.1.1.1)-----R2==(4-way ip ecmp)===R3 (3.3.3.3)

1) I send 10K ping to R3
R1(config-if-Lo0)#ping 3.3.3.3 source 1.1.1.1 repeat 10000

2) R2 has a 4-way ecmp
R2(config)#sh ip route 3.3.3.3
 S      3.3.3.3/32 [1/0] via 23.23.1.3, Ethernet6/1/1
                         via 23.23.2.3, Ethernet6/1/2
                         via 23.23.3.3, Ethernet6/1/3
                         via 23.23.4.3, Ethernet6/1/4

3) All 10K goes the 1st link
R2(config)#sh int et6/1/1 - 4 | egrep 'ets input|ets output|^Eth'
Ethernet6/1/1 is up, line protocol is up (connected)
     3 packets input, 699 bytes
     10003 packets output, 1180696 bytes <<<< R1-R3 
Ethernet6/1/2 is up, line protocol is up (connected)
     3 packets input, 699 bytes
     3 packets output, 696 bytes
Ethernet6/1/3 is up, line protocol is up (connected)
     3 packets input, 699 bytes
     3 packets output, 696 bytes
Ethernet6/1/4 is up, line protocol is up (connected)
     10003 packets input, 1180699 bytes  <<<< R3-R1
     3 packets output, 696 bytes
....

I believe hashing is based on 5-tuple (proto#, src/dst ip, src/dst port) for tcp/udp. How about ICMP? It misses src/dst port, in stead type/code/checksum in the place. The packet capture shows the checksum is calculated and varied. 

Arista MPLS VPN Step by Step (2b) L2VPN - Type 5 PW

This blog covers type 5 pw configuration. Here is the topology:

Configuration-wise, type 5 is simpler than type 4. And between 2 CEs, it is just a like direct ethernet link. From above topology, there is 2 vlans between CEs over 1 pw. 

PE1 Configuration:

mpls ldp
   router-id 88.255.11.11
   transport-address interface Loopback88
   fec filter prefix-list fec-pfx-list
   no shutdown
   !
   pseudowires
      pseudowire to-ce2-type5-pw
         neighbor 88.255.22.22
         pseudowire-id 303
         mtu 9082
!
patch panel
   patch ce1-ce2-pw5-1
      connector 1 interface Ethernet47/3
      connector 2 pseudowire ldp to-ce2-type5-pw
!
interface Ethernet47/3
   description mpls.ldp5pw.pe1=>ce1.et51/3
   !! PE to CE interface MUST be routed port !!
   no switchport

L2 Control Packets

One different between type4 and 5 is the forwarding behavior of L2 control packets. From above link, the LLDP is forwarded. So "show lldp neighbor" on CE1 shows CE2, not PE1

CE1(config)#ln
Et51/1     PE1                              Ethernet47/1               120
Et51/2     PE1                              Ethernet47/2               120
Et51/3     PE1                              Ethernet47/3               120
Et51/3     CE2                              Ethernet52/3               120

Arista MPLS VPN Step by Step (2a) L2VPN - Type 4 PW

Based on the MPLS LDP configuration completed in the previous session, I will talk about the MPLS LDP type 4 pseudowire configuration.

Regarding the LDP/BGP/IGP configuration, please refer to this blog.

Here is the topology:



Here we have 2 pseudowires: ce1-ce2-pw4-vlan-301 and ce1-ce2-pw4-vlan-302 to L2 connectivity between CE1 and CE2 across LDP cloud. From CEs' perspective, the pw works like a directly connected L2 link. So the VLANs are in same subnet and running IGPs (OSPF/ISIS) on the top of it. 

PE 1 configuration:

interface Ethernet3/1
   description mpls.pe1=>p1:et54/1
   mtu 9082
   no switchport
   ip address 88.1.11.11/24
!
interface Ethernet45/3
   description mpls.pe1=>p3:et45/3
   mtu 9082
   no switchport
   ip address 88.3.11.11/24
!
interface Ethernet47/2
   description mpl1.pe1=>ce1:et51/1
   mtu 9082
   ! pw intf to CE1 must be routed port, otherwise pw down !
   no switchport
!
interface Loopback88
   ip address 88.255.11.11/32
!
mpls ip
!
mpls ldp
   ! mpls ldp config is same as mpls ldp l3vpn !
   router-id 88.255.11.11
   transport-address interface Loopback88
   fec filter prefix-list fec-pfx-list
   no shutdown
   !
   pseudowires
      pseudowire to-ce2-vlan-301
         ! 88.255.22.22 is PE2's ldp/pw loopback ip addr !
         neighbor 88.255.22.22
         pseudowire-id 301
         mtu 9082
      !
      pseudowire to-ce2-vlan-302
         neighbor 88.255.22.22
         pseudowire-id 302
         mtu 9082
!
patch panel
   patch ce1-ce2-pw4-vlan-301
      ! note, e47/2 is cfg'ed as routed port, NOT sw/trunk port !
      connector 1 interface Ethernet47/2 dot1q vlan 301
      connector 2 pseudowire ldp to-ce2-vlan-301
   !
   patch ce1-ce2-pw4-vlan-302
      connector 1 interface Ethernet47/2 dot1q vlan 302
      connector 2 pseudowire ldp to-ce2-vlan-302

PE 2 configuration:

interface Ethernet33/1

   description pe2-p4=>p4.et33/1

   mtu 9082

   no switchport

   ip address 88.4.22.22/24

!

interface Ethernet37/2

   description pe2-ce2=>ce2.et52/2

   mtu 9082

   no switchport

!

interface Ethernet51/1

   description pe2-p2=>p2.et51/1

   mtu 9082

   no switchport

   ip address 88.2.22.22/24

!

interface Loopback88

   ip address 88.255.22.22/32

!

mpls ip

!

mpls ldp

   router-id 88.255.22.22

   transport-address interface Loopback88

   fec filter prefix-list fec-pfx-list

   no shutdown

   !

   pseudowires

      pseudowire to-ce1-vlan-301

         neighbor 88.255.11.11

         pseudowire-id 301

         mtu 9082

      !

      pseudowire to-ce1-vlan-302

         neighbor 88.255.11.11

         pseudowire-id 302

         mtu 9082

!

patch panel

   patch ce1-ce2-pw4-vlan-301

      connector 1 interface Ethernet37/2 dot1q vlan 301

      connector 2 pseudowire ldp to-ce1-vlan-301

   !

   patch ce1-ce2-pw4-vlan-302

      connector 1 interface Ethernet37/2 dot1q vlan 302

      connector 2 pseudowire ldp to-ce1-vlan-302

For the CE's configuration, please note that I use VRF on CE to simulate multiple hosts. 

CE1 configuration:

vrf definition ce1-pw4-301

   rd 301:1

!

vrf definition ce1-pw4-302

   rd 302:1

!

interface Ethernet51/2

   description mpls.ce1=>pe1:et47/2

   ! compare with PE1's et47/2, here is sw + trunk !

   switchport trunk allowed vlan 301-302

   switchport mode trunk

!

interface Vlan301

   vrf forwarding ce1-pw4-301

   ip address 101.101.101.1/24

!

interface Vlan302

   mtu 9000

   vrf forwarding ce1-pw4-302

   ip address 102.102.102.1/24

   isis enable isis-ce1-pw4-302

!

interface Loopback301

   vrf forwarding ce1-pw4-301

   ip address 101.255.1.1/24

!

interface Loopback302

   vrf forwarding ce1-pw4-302

   ip address 102.255.1.1/24

   isis enable isis-ce1-pw4-302

!

ip routing vrf ce1-pw4-301

ip routing vrf ce1-pw4-302

!

router isis isis-ce1-pw4-302 vrf ce1-pw4-302

   net 47.0002.0001.0001.0001.00

   is-type level-2

   !

   address-family ipv4 unicast

!

router ospf 301 vrf ce1-pw4-301

   network 101.0.0.0/8 area 0.0.0.0

   max-lsa 12000

CE2 configuration:

interface Ethernet52/2

   description mpls.ce2=>pe2:et37/2

   switchport trunk allowed vlan 301-302

   switchport mode trunk

!

vrf definition ce2-pw4-301

   rd 301:2

!

vrf definition ce2-pw4-302

   rd 302:2

!

interface Loopback301

   vrf forwarding ce2-pw4-301

   ip address 101.255.2.2/24

!

interface Loopback302

   vrf forwarding ce2-pw4-302

   ip address 102.255.2.2/24

   isis enable isis-ce2-pw4-302

!

interface Vlan301

   vrf forwarding ce2-pw4-301

   ip address 101.101.101.2/24

!

interface Vlan302

   mtu 9000

   vrf forwarding ce2-pw4-302

   ip address 102.102.102.2/24

   isis enable isis-ce2-pw4-302

!

ip routing vrf ce2-pw4-301

ip routing vrf ce2-pw4-302

!

router isis isis-ce2-pw4-302 vrf ce2-pw4-302

   net 47.0002.0002.0002.0002.00

   is-type level-2

   !

   address-family ipv4 unicast

!

router ospf 301 vrf ce2-pw4-301

   network 101.0.0.0/8 area 0.0.0.0

   max-lsa 12000

Arista MPLS VPN Step by Step (1e) MPLS L3VPN PE/CE ISIS

Now it is the PE/CE routing option - ISIS. Here is the simplified topology



PE1 Configuration:

router bgp 65001

   !

   vrf pe1-isis

      rd 100:115

      route-target import vpn-ipv4 100:115

      route-target import vpn-ipv4 200:115 << import PE2's routes

      route-target export vpn-ipv4 100:115 << pe1=100:115, pe2=200:115

      maximum-paths 2 ecmp 2

      redistribute connected

      redistribute isis level-2

!

router isis isis-pe1 vrf pe1-isis

   net 47.0001.0011.0011.0011.00

   is-type level-2

   redistribute bgp

   !

   address-family ipv4 unicast

CE Configuration:

router isis isis-ce1 vrf ce1-isis

   net 47.0001.0001.0001.0001.00

   is-type level-2

   !

   address-family ipv4 unicast

Ping check:

CE1(vrf:ce1-isis)#sh ip route
.......
 C       100.100.115.0/24 is directly connected, Vlan104
 I L2    100.250.115.0/24 [115/20] via 100.100.115.11, Vlan104
 C       100.255.115.0/24 is directly connected, Loopback104
 I L2    200.200.115.0/24 [115/10] via 100.100.115.11, Vlan104
 I L2    200.250.115.0/24 [115/10] via 100.100.115.11, Vlan104
 I L2    200.255.115.0/24 [115/10] via 100.100.115.11, Vlan104

CE1(vrf:ce1-isis)#ping 200.250.115.22 << ping pe2's loopback
....
--- 200.250.115.22 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.117/0.181/0.335/0.083 ms, ipg/ewma 0.243/0.253 ms

CE1(vrf:ce1-isis)#ping 200.255.115.2  << ping ce2's loopback
.....
--- 200.255.115.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.120/0.156/0.291/0.069 ms, ipg/ewma 0.214/0.221 ms

CE1(vrf:ce1-isis)#ping 200.200.115.2 << ping pe2-ce2's ip @ ce2
....
--- 200.200.115.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.120/0.153/0.274/0.061 ms, ipg/ewma 0.210/0.211 ms

CE1(vrf:ce1-isis)#ping 200.200.115.22  << ping pe2-ce2's ip @ pe2
.....
--- 200.200.115.22 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.115/0.151/0.253/0.053 ms, ipg/ewma 0.208/0.199 ms

Arista MPLS VPN Step by Step (1d) MPLS L3VPN PE/CE OSPF

In this post I will discuss the PE/CE routing option - OSPF. Here is the simplified topology



PE Configuration:

router bgp 65001
....
   vrf pe1-ospf
      rd 100:110
      route-target import vpn-ipv4 100:110
      route-target import vpn-ipv4 200:110
      route-target export vpn-ipv4 100:110
      maximum-paths 2 ecmp 2
      redistribute connected
      redistribute ospf
!
router ospf 100 vrf pe1-ospf
   router-id 88.255.11.11
   passive-interface Loopback103
   redistribute bgp
   network 100.100.110.11/32 area 0.0.0.0
   network 100.250.110.11/32 area 0.0.0.0
   max-lsa 12000

CE Configuration:

router ospf 100 vrf ce1-ospf
   router-id 100.250.100.100
   passive-interface Loopback103
   network 100.100.110.1/32 area 0.0.0.0
   network 100.255.110.1/32 area 0.0.0.0
   max-lsa 12000

Arista MPLS VPN Step by Step (1c) MPLS L3VPN PE/CE eBGP

Following the previous blog, in this post I will discuss the PE/CE routing option - eBGP. Here is the simplified topology

PE Configuration

router bgp 65001

   router-id 88.255.22.22

   neighbor vpnv4-rr peer-group

   neighbor vpnv4-rr remote-as 65001

   neighbor vpnv4-rr update-source Loopback88

   neighbor vpnv4-rr send-community standard extended

   neighbor vpnv4-rr maximum-routes 12000 

   neighbor 88.255.1.1 peer-group vpnv4-rr

   neighbor 88.255.2.2 peer-group vpnv4-rr

   address-family vpn-ipv4

      neighbor vpnv4-rr activate

      neighbor default encapsulation mpls next-hop-self source-interface Loopback88

   !

   vrf pe2-ebgp

      rd 200:20

      route-target import vpn-ipv4 100:20

      route-target import vpn-ipv4 200:20

      route-target export vpn-ipv4 200:20

      maximum-paths 2 ecmp 2

      neighbor 200.200.20.2 remote-as 65500

      neighbor 200.200.20.2 maximum-routes 12000 

      redistribute connected

CE configuration is as below. In my lab, I use vrf on CE router to segregate and simulate different CEs. 

router bgp 65500

   router-id 100.255.100.100

   !

   vrf ce1-ebgp

      rd 100:20

      neighbor 100.100.20.11 remote-as 65001

      ! need alllowas-in to permit remote prefix with same AS#

      neighbor 100.100.20.11 allowas-in 3

      neighbor 100.100.20.11 maximum-routes 12000 

      redistribute connected

Arista MPLS VPN Step by Step (1b) MPLS L3VPN PE/CE Static

In this blog, I will discuss the PE/CE routing option - static. Here is the simplified topology

The configuration is quite simple. 

router bgp 65001
   router-id 88.255.11.11
   neighbor vpnv4-rr peer-group
   neighbor vpnv4-rr remote-as 65001
   neighbor vpnv4-rr update-source Loopback88
   neighbor vpnv4-rr send-community standard extended
   neighbor vpnv4-rr maximum-routes 12000 
   neighbor 88.255.1.1 peer-group vpnv4-rr
   neighbor 88.255.2.2 peer-group vpnv4-rr
   !
   address-family vpn-ipv4
      neighbor vpnv4-rr activate
      neighbor default encapsulation mpls next-hop-self source-interface Loopback88
   !
....
   vrf pe1-static
      !! pe/ce: static, intf:vlan101+lo101, addr:100.1.11.0/24+100.1.100.0/32
      rd 100:1
      !
      ! PE1 ex/import 100:1, and import PE2's 200:1 
      !
      route-target import vpn-ipv4 100:1
      route-target import vpn-ipv4 200:1
      route-target export vpn-ipv4 100:1
      maximum-paths 2 ecmp 2
      redistribute connected
      redistribute static

So on PE1, we can 6 vpn-ipv4 routes (doubled by 2 RRs)

PE1(config)#sh bgp vpn-ipv4 rd 200:1

BGP routing table information for VRF default

Router identifier 88.255.11.11, local AS number 65001

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: 200:1 IPv4 prefix 200.200.1.0/24

                                88.255.22.22          -       100     0        i Or-ID: 88.255.22.22 C-LST: 88.255.1.1

 *       RD: 200:1 IPv4 prefix 200.200.1.0/24

                                88.255.22.22          -       100     0        i Or-ID: 88.255.22.22 C-LST: 88.255.2.2

 * >     RD: 200:1 IPv4 prefix 200.250.1.0/24

                                88.255.22.22          -       100     0        i Or-ID: 88.255.22.22 C-LST: 88.255.1.1

 *       RD: 200:1 IPv4 prefix 200.250.1.0/24

                                88.255.22.22          -       100     0        i Or-ID: 88.255.22.22 C-LST: 88.255.2.2

 * >     RD: 200:1 IPv4 prefix 200.255.1.0/24

                                88.255.22.22          -       100     0        ? Or-ID: 88.255.22.22 C-LST: 88.255.1.1

 *       RD: 200:1 IPv4 prefix 200.255.1.0/24

                                88.255.22.22          -       100     0        ? Or-ID: 88.255.22.22 C-LST: 88.255.2.2

Arista MPLS VPN Step by Step (1a) MPLS LDP L3VPN Configuration

Above is the topology, in which we have:

• 2 PE + 4 P routers, all full mesh connections (we will leverage this setup for later configurations)
• IGP: OSPF process 71
• iBGP: AS 65001, peering with loopback 71 (71.#.#.#/32, # is the router-id)
• MPLS LDP is enabled on all interfaces

P router configuration:

mpls ip
!
mpls ldp
   router-id 88.255.1.1
   transport-address interface Loopback88
   fec filter prefix-list fec-pfx-list
   no shutdown
!
router bgp 65001
   router-id 88.255.1.1
   maximum-paths 4 ecmp 4
   neighbor pe peer-group
   neighbor pe remote-as 65001
   neighbor pe update-source Loopback88
   neighbor pe route-reflector-client
   neighbor pe send-community standard extended
   neighbor pe maximum-routes 12000 
   !
   ! RR configuration, peering to PE1/PE2
   !
   neighbor 88.255.11.11 peer-group pe
   neighbor 88.255.22.22 peer-group pe
   !
   address-family vpn-ipv4
   ! active vpn-ipv4 AF
      neighbor pe activate
!
router ospf 88
   router-id 88.255.1.1
   passive-interface Loopback88
   network 88.0.0.0/8 area 0.0.0.0
   max-lsa 12000

PE router configuration:

mpls ip
!
mpls ldp
router bgp 65001
   router-id 88.255.11.11
   neighbor vpnv4-rr peer-group
   neighbor vpnv4-rr remote-as 65001
   neighbor vpnv4-rr update-source Loopback88
   neighbor vpnv4-rr send-community standard extended
   neighbor vpnv4-rr maximum-routes 12000 
   neighbor 88.255.1.1 peer-group vpnv4-rr
   neighbor 88.255.2.2 peer-group vpnv4-rr
   !
   address-family vpn-ipv4
      neighbor vpnv4-rr activate
      neighbor default encapsulation mpls next-hop-self source-interface Loopback88

For the full router configuration, please go to the directory. 

Arista MPLS VPN Step by Step (0)

In this step-by-step series, I will cover the Arista MPLS VPN solution. All of the configuration is based on the following topology. For the technical details, please refer to "Arista MPLS IPv4/v6 MPLS VPN Configuration Guide" 

And some other references:

• Arista Software TOI - click TOI
• 4-15-0F:
• MPLS Label Encap
• Static MPLS Label Pop/Swap (T2)
• 4-17F:
• MPLS LDP (4-17-0F)
• ISIS Segment Routing
• MPLS over GRE
• LDP Pw
• 4-18-1F:
• Static MPLS Label Push (T2/TH)
• 4-20F:
• L3 EVPN MPLS
• LDP Pw type 5
• BGP LU/SR
• L2 EVPN MPLS
• 4-21F:
• MPLS Traceroute
• Inter-VRF Route Leaking
• Arista MPLS Manual
• Arista EVPN Manual

OSPF Fast Convergence

This blog is the best article on this subject, maybe a little old but very informational. 

Some takeaway notes:

• IGP has micro loop during convergence, because FIB update from near to far，EIGRP is an exception - explicit route due to diffusing computation. 
• Convergence = Detection + Propogation + SpfComp + FibUpdTime
• 1. Detection:
• Don't use IGP KA, instead use hw failure detection, like p2p Ethernet. 
• No debounce timers. SONET is 例外，有50 ms protection, can set 50ms+
• If P2P, OSPF does not need DR elections to save time. And no type2 LSA, reduces LSDB size
• If no hw failure detection, have to use fast protocol hello, like ospf fast timer - "ip ospf dead-interval minimal hello-multiplier 5" = 5 hello/sec
• Can do 1-sec failure detection, but cpu load is high
• Use BFD, workload is off to LC. 
• 2. Propagation:
• Out: ISIS/OPSF, using LSA flood. IGP has throttling mechanism, like Cisco has exceptional backoff algorithm. so set initial as low as 5-10 ms. don't use 0, because multiple link down event better in ONE LSA. 
• In: should be ok
• Processing: 
• ISIS has fast-flood, flood before SPF processing.
• Timer pacing flood, the interval between LSA. 
• OutIfQueue: Need Qos to reserve b/w for CP pkts
• Packet propagation: small not serious
• 3. SPF Computation
• Used to be a big impact before, but not now thanks for fast hw and some algorithm improvement like iSPF (incremental)
• 4. Fib update
• This stage contributes the MOST to convergence time
• 2 ways to speed up: 1) less prefixes; 2) sequence important first
• Edge routers don't need core transit prefixes. So, 
• (1) use ip unumbered so to put loopback0; 
• (2) ospf 2 LSA for p2p links, type-1 router; and type-3 network. "ip ospf prefix-suppression", only process type 1, no type-3
• (3) ISIS has priority driven installation