L2 Control Packet Fwding on J-based system

[Update, Nov 1, 2019] Starting from 4.22.0F, EOS can support multiple L2 protocols packets but NEED to create/apply a TCAM profile. 

The L2 control packets like LACP/LLDP/STP are trapped by a switch and sent to CPU for processing. But for some use cases, this behavior requires to be changed. For example, In the below diagram, the CE1 and CE2 want to form a port-channel across the service provider's MPLS cloud network. 



Another use case is the create an L2 harness switch. As shown below, R1 and R2 can establish a port-channel across a harness switch transparently. 




Starting from Arista EOS 4.21.3F, a feature called - L2 protocol forwarding was introduced. With that, above requirement can be achieved. 

The configurations are quite straightforward, 
1) Step 1 - create l2-protocol forwarding profile and enable lacp forward
2) Step 2 - apply this profile under all the client facing interfaces
3) Step 3 - configure LDP type 5 pw - local patch to stitch 2 local eth ports

1. The port-channel is up. 

R1.gts425.15:54:21#sh port-ch 100
Port Channel Port-Channel100:
  Active Ports: Ethernet21 Ethernet22

2. "show lldp neighbor" shows remote and intermediate devices

R1.gts425.16:15:26#sh lldp nei et21, 22
Port       Neighbor Device ID   Neighbor Port ID           TTL
Et21       lp232                Ethernet12/1               120
Et21       R2.hss457            Ethernet21                 120
Et22       lp232                Ethernet12/2               120
Et22       R2.hss457            Ethernet22                 120

Limitation:

• In 4.21.3F, only LACP/LLDP supported. STP and other L2 protocols will be supported in later releases. 
• From 4.22.0F, more protocols are supported, but need to create a tcam profile. 

Arista BGP Peering Options (5) - v6 link-local peering/NH

Arista TOI Link

Compared with "v4 over v6 NH", the configuration is quite similar, except the interface address and neighbor use link-local address. 

So the benefits here are obvious:

• Minimizing the configuration efforts, no need ipv4 and global ipv6 address. 
• IPv4 NLRI over IPv6 link-local NH. 

Because the link-local address is a local address and not accessible by remote devices, the bgp configure is considered to be a special one. The following regular bgp knobs don't work as usually:

• iBGP
• eBGP multi-hop
• confed BGP
• local AS if changing to iBGP
• Link-local eBGP learnt routes are not advertised to iBGP peers, because of lacking NH address

Please note that this is ONLY supported in Gated, not in multi agent mode. 

Arista BGP Peering Options (4) - IPv4 NRLI over IPv6 NH

This blog is about the v4 NRLI over v6 NH. Based on Arista 4.17.0F TOI, this feature comprises 2 parts:

• IPv4 forwarding on IPv6 interface
• IPv6 NRLI with IPv6 NH

Compared with previous configurations, 2 configures are needed:

1. IPv4 forwarding on IPv6 interface, which is enabled by "ip routing ipv6 interfaces  vrf v3"
2. neighbor <ipv6Nei> next-hop address-family ipv6 originate

Another way of 2nd part is to enable "bgp next-hop address-family ipv6". But in the above topology, the NRLI is originated directly, so have to put originate. 

From the output of "show ip route", you can see the v4 route's NH is the ipv6 address

R1.lp231.20:13:59(config-router-bgp-vrf-v3)#sh ip route bgp detail

VRF: v3

 B E   103.2.2.0/24 [200/0]

       via 12:12:103::2, Vlan103

R1.lp231.20:14:07(config-router-bgp-vrf-v3)#sh ip bgp 103.2.2.0

BGP routing table information for VRF v3

Router identifier 103.2.2.2, local AS number 1

BGP routing table entry for 103.2.2.0/24

 Paths: 1 available

  2

    12:12:103::2 from 12:12:103::2 (103.2.2.2)

      Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:18:46 ago, valid, external, best

      Rx SAFI: Unicast

Arista BGP Peering Options (3) - IPv6 NRLI over IPv4 Peering

This peering configuration is the reverse version of the previous one. So the configuration-wise, it is very similar. 

The benefit is clear, we only need 1 BGP peering to carry both address families. But we still need to keep a dual stack on the interfaces to be used as NH. In today data center network, ECMP is very popular and wide. Evening using /31, the finest network mask, a /24 can only afford 128 links. 

And this youtube explains very well on the requirement behind RFC 5549, ipv4 over v6 NH, which is shown in the next blog

Arista BGP Peering Options (2) - IPv4 NRLI over IPv6 Peering

Here is the TOI link

On the top of regular IPv6 BGP configuration, you need to configure 2 things:

1) Enable IPv4 NLRI over v6 peering and 2 ways to do it:

1. Under ipv4 address-family, activate it on ipv6 peering, which is shown in R1's configuration
2. Global configuration of "bgp default ipv4-unicast transport ipv6" in R2's show run

2) Specify the IPv4 NH of IPv4 prefixes, and we can do it 3 ways:

1. Global automatic NH address - "bgp auto-local-addr" in R'2 configuration. But this is a global knob, so if you have IPv6 prefixes over IPv4 NH, it will break peering silently. 
2. Neighbor-base automatic NH address - "neighbor 12:12:101::1 auto-local-addr"
3. Neighbor-base manual NH address in R1's configuration - "neighbor 12:12:101::2 local-v4-addr 12.12.101.1"

Here is the output of "sh ip bgp 101.2.2.0" (I enable "routing-context vrf v1", so no need vrf)

R1.lp231.16:28:58(config)#sh ip bgp 101.2.2.0

BGP routing table information for VRF v1

Router identifier 101.1.1.1, local AS number 1

BGP routing table entry for 101.2.2.0/24

 Paths: 1 available

  2

    12.12.101.2 from 12:12:101::2 (101.2.2.2)

      Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:02:03 ago, valid, external, best

      Rx SAFI: Unicast

And both ipv4/ipv6 ping work as expected. 

R1.lp231.16:29:11(config)#ping 101.2.2.2

PING 101.2.2.2 (101.2.2.2) 72(100) bytes of data.

80 bytes from 101.2.2.2: icmp_seq=1 ttl=64 time=0.242 ms

80 bytes from 101.2.2.2: icmp_seq=2 ttl=64 time=0.100 ms

80 bytes from 101.2.2.2: icmp_seq=3 ttl=64 time=0.093 ms

80 bytes from 101.2.2.2: icmp_seq=4 ttl=64 time=0.091 ms

80 bytes from 101.2.2.2: icmp_seq=5 ttl=64 time=0.093 ms

--- 101.2.2.2 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.091/0.123/0.242/0.060 ms, ipg/ewma 0.174/0.180 ms

R1.lp231.16:31:39(config)#ping ipv6 101:2:2::2

PING 101:2:2::2(101:2:2::2) 72 data bytes

80 bytes from 101:2:2::2: icmp_seq=1 ttl=64 time=0.262 ms

80 bytes from 101:2:2::2: icmp_seq=2 ttl=64 time=0.106 ms

80 bytes from 101:2:2::2: icmp_seq=3 ttl=64 time=0.103 ms

80 bytes from 101:2:2::2: icmp_seq=4 ttl=64 time=0.099 ms

80 bytes from 101:2:2::2: icmp_seq=5 ttl=64 time=0.103 ms

--- 101:2:2::2 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.099/0.134/0.262/0.064 ms, ipg/ewma 0.184/0.196 ms

Arista BGP Peering Options (1)

In this series of blogs, I will discuss a bit on the Arista EOS BGP peering options. As of March 2019, the EOS has the following peering options:



Here is the Arista official TOI links:

• BGP IPv4 NLRI over IPv6 Transport
• BGP IPv4 NLRI over IPv6 NH
• BGP IPv6 Link-local Peering

So, why do we need them, what's the difference and how to configure them?

1) Why
Today's network needs to support dual address spaces - IPv4 and IPv6, which requires providers to run 2 parallel control/forward planes. So the purpose of all the above features is to decrease the complexity by reducing control plane even forward plane.

For example, a data center with public ipv4/ipv6 address and needs support worldwide ipv4 and ipv6 access. Is that possible to use ipv4/ipv6 address space at the server pool and service routers, and only ipv6 infrastructure? The answer is yes.

2)  What's the difference between the above 3 options?

1. The basic way is to have dual ipv4/ipv6 infrastructures and control planes, which means, 2 BGP sessions and 2 address planes. 
2. IPv4 NRLI over IPv6 Transport is to send v4 prefixes over v6 peering. So it saves 1 just 1 control plane - ipv6 bgp but still needs ipv4 next hop as ipv4 prefixes, which means 2 data planes or dual v4/v6 stack. 
3. RFC 5549 - IPv4 NRLI over IPv6 NH, this feature is one step further, ipv4 prefixes can use ipv6 NH. So 1 BGP session and 1 data planes (v6 infrastructure)
4. BGP IPv6 link-local peering, this utilizes the ipv6 link-local address to establish BGP peering w/o assigning global IPv6 interface addresses. 

3) How to configure them? In the following blogs, I will show the configuration 1 by 1. (Please note that I use vrf under router bgp, in order to configure them together in one place. But it is not required and most of the time, you only need ONE)

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