Arista EOS/Networking Tips by Solomon Yang

4/12/2018

Arista/EOS: How to trace/debug BGP Update

[2019/9/24] Besides turning on the bgp update trace, anther quick way is to use tcpdump with -vvv option. For example,

router bgp 65000
neighbor ebgp.v6 peer group
neighbor ebgp.v6 remote-as 65020

neighbor ebgp.v6 maximum-routes 12000
vrf v3
bgp default ipv4-unicast transport ipv6
bgp default ipv6-unicast
neighbor fe80::20%Et3/12/4 peer group ebgp.v6

But neighbor fe80::20%Et3/12/4 has no incoming prefixes

yo412.mlagA.13:47:59(config-router-bgp)#sh ip bgp summary vrf v3
BGP summary information for VRF v3
Router identifier 100.17.80.251, local AS number 65000
Neighbor Status Codes: m - Under maintenance
Description Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc

v3#1, v46@6L, L3/eth fe80::20%Et3/12/4 4 65020 22 24 0 0 00:05:27 Estab 0 0

Enable the tcpdump and clear this session in anther session

yo412.mlagA.13:45:36#bash tcpdump -nvvvi et3_12_4 tcp port 179
yo412.mlagA.13:50:00#clear ip bgp fe80::20%Et3/12/4 vrf v3

Now We can see the contents of bgp update packets

13:44:32.751791 44:4c:a8:8d:10:5f > 00:1c:73:44:58:b6, ethertype IPv6 (0x86dd), length 1485: (class 0xc0, flowlabel 0x5ad94, hlim 1, next-header TCP (6) payload length: 1431) fe80::20.38957 > fe80::1.bgp: Flags [P.], seq 85:1484, ack 101, win 225, options [nop,nop,TS val 1506709860 ecr 3429570], length 1399: BGP
Update Message (2), length: 738
Origin (1), length: 1, Flags [T]: IGP
0x0000: 00
AS Path (2), length: 10, Flags [T]: 65020 65000
0x0000: 0202 0000 fdfc 0000 fde8
Multi-Protocol Reach NLRI (14), length: 694, Flags [OE]:
AFI: IPv6 (2), SAFI: Unicast (1)
nexthop: fe80::20, fe80::20, nh-length: 32, no SNPA
100:13:22::/64

How to trace/debug BGP updates

This page is to provide a detailed procedure on how to enable BGP trace in gated to debug incoming/outgoing bgp updates.

Step 1: Find the trace facility

In the gated implementation, the bgp is included in the Ribd agent. So there is no such bgp agent, you have to search the exact trace facility under Rib.

Arista.7050QX(config)#show trace Rib | grep -i bgp

.....

GatedBgpHelper enabled ............

Rib::Bgp enabled ............

Rib::Bgp::Keepalive enabled ............

Rib::Bgp::Normal enabled ............

Rib::Bgp::Notification enabled ............

Rib::Bgp::Open enabled ............

Rib::Bgp::Policy enabled ............

Rib::Bgp::Route enabled ............

.....

Rib::Bgpwhite::Keepalive enabled ............

Rib::Bgpwhite::Normal enabled ............

Rib::Bgpwhite::Notification enabled ............

Rib::Bgpwhite::Open enabled ............

Rib::Bgpwhite::Policy enabled ............

Rib::Bgpwhite::Route enabled ............

Rib::Bgpwhite::State enabled ............

Rib::Bgpwhite::Task enabled ............

Rib::Bgpwhite::Timer enabled ............

Rib::Bgpwhite::Update enabled ............

....

From above output, there is separate bgp facilities for BGP process under different vrf. In this example, the one I am looking at is Bgp updates under vrf white.

Step 2: Enable Trace

Arista.7050QX(config)#trace Rib enable Rib::Bgpwhite::Update all

Step 3: Locate the agent log file.

Arista.7050QX(config)#bash ls -lt /var/log/agents/*white*

-rw-rw-rw- 1 root root 339387 Jun 21 14:15 /var/log/agents/Rib-vrf-white-4032

Step 4: Trigger bgp update and monitor updates

Tail the agent log

Arista.7050QX(config)#bash tail -f /var/log/agents/Rib-vrf-white-4032

Then trigger the bgp clear from another session or other bgp router

Arista.7050QX#clear ipv6 bgp 130:1:10::10 soft vrf white

Here is the output:

....

14:18:08.130842 VR white BGP PACKET: bgp_send_peer_reachability: bnp 130:1:10::1: send path id 4294967295 for prefix 122.130.10.0[apsend=false, entp=edab4460]

14:18:08.130894 VR white BGP PACKET: bgp_rt_send_message: 130:1:10::1, flags 0x5608880, len 108

14:18:08.130947 VR white

14:18:08.130947 VR white BGP SEND 130:1:10::10+49700 -> 130:1:10::1+179

14:18:08.130994 VR white BGP SEND message type 2 (Update) length 108

14:18:08.131190 VR white BGP SEND flags 0x40 code Origin(1): IGP

14:18:08.131231 VR white BGP SEND flags 0x40 code ASPath(2) length 12: 2222

14:18:08.131281 VR white BGP SEND {1} (0x40 0x03 0x04 0x82)

.....

Step 5: clear the trace

Arista.7050QX(config)#no trace Rib setting

Reference

Arista EOS Trouble-shooting ipv4/v6 packet loss

Steps:

stop traffic and clear hw/sw drop counter

clear hardware counter drop - show hardware counter drop
clear counter - show cpu counter queue

start traffic, and repeat trigger or test case, hold for some time then stop traffic
check drop counter:

show hard counter drop
show cpu counter queue | nz

repeat this step along the data path if needed

Output:

wa462.bug228215.01:04:40#sh cpu counters queue | nz
....
---------------------------------------------------------------------------------------------------------------
Jericho5.0:
CPU Queue Pkts Octets DropPkts DropOctets

---------------------------------------------------------------------------------------------------------------
CpuQueueLinkLocal 5 610 0 0
CpuQueueLldp 31 8060 0 0
CpuQueueBgp 60 5370 0 0
CpuQueueL3DstMiss 469817 121682603 89773442 23251321478
CpuQueueL3LpmOverflow 1693 438487 754666 195458494
Jericho5.1:
CPU Queue Pkts Octets DropPkts DropOctets

CpuQueueL3DstMiss means, 1) unresolved ipv4 arp; 2) unresolved ipv6 neighbor.

Solution:

After configuring no platform sand ipv6 host-route exact-match", the traffic is recovered.

Finally it turns out that I missed the vxlan config.

4/11/2018

Arista L3 Leaf/Spine Step by Step (0) - Overview

(updated Dec 2018, add more platform)

In this series of blog, I will demo a sample configuration a simple L3 Leaf/Spine DC network based on Arista EOS devices by using VXLAN, EVPN, MLAG, and BGP. Here are some reference links:

This blog is NOT a detailed technical review on protocols or how it works. You can find them in the above links. But most of the times, these official documentation doesn't give details on configurations. So that's why I write up this detailed hands-on guide which focuses on the configuration and troubleshooting.

I will try to configure the whole topology step by step in the following order.

Step 1 - Basic config (BGP and MLAG)
Step 2 - VXLAN Bridging
Step 3 - VXLAN Routing
Step 4 - EVPN
Step 5 - Troubleshooting

Here is the topology:

From above topology, we have

Spine Layer:

2 Spines - DCS-7512N
AS# = 65000

1 x Bow-tie MLAG leaf (on the top of diagram):

Trident 2, DCS-7050QX2-32S-F
AS# = 65041

2 x MLAG leaves: (left bottom)

Trident 2+ and Jericho (no need for recirculation)
AS# = 65021, 65022

3 x Single Leaves: (right bottom)

Trident 2, Jericho and Tomahawk
AS# = 65011, 65012, 65013

Each router has 2 loopback:

loopback 0 = 200.255.255.<rtrid>/32, for routing/id
loopback10 = 200.255.200.<RtrId/VxlanId>/32, for vxlan src ip

RtrId/VxlanId (the red block in diagram):

spine1/2 = 100/200
BT MLAG peers = 1/2/11/22

VxlanId = 12

MLAG Leaves = 3/4/5/6

VxlanID = 34 and 56

Single Leves: 7/8/9

Interface IP address = 200.rtr-id1*rtr-id2.<seq>.rtrid/24

for example 200.101.1.1/24, router spine1 to r1

The basic MLAG and BGP configuration are quite straightforward:

BGP only advertises the Vxlan source loopback - 200.255.200.<rtrID>

MLAG vs LACP fast rate

Arista doesn't recommend LACP rate fast enabled with MLAG, which is not very reliable especially in scale environment.

For example:

mlagA/Primary mlagB/Secondary
\ /
\ /
\ /
mlagLeaf

When either primary or secondary peer reloads, the mlagLeaf will see LAG flaps during this process.

In 4.20.2.1F Release Note, on page 21

LACP PDU fast rate ("lacp rate fast" on an Arista switch) should not be configured on any port in an MLAG pair, or any port connected to an MLAG pair. (13950)

Reference:
bug13950/SR 101110/Old post

Max # of MLAGs supported on Arista switch

One the biggest limitations of # MLAG support on an Arista switch, is the port-id. If you see the following the error message when configuring MLAG port-channels, it means you hit the ceiling.
Mar 25 23:44:55 Arista.EOS Ebra: %SYS-1-PORT_ID_ERROR: Unable to allocate a port ID for interface

Well, this kind of failure is quite rare especially if your devices are only fixed 1RU or 2RU systems or the # of mlag port-channels is below 100. But if your system is a heavily loaded modular system like 7508 or 7512 with all LCs plugged, it may hit you surprisingly.

What is the port-id, why important?

The port-id is used in LACP and STP. In STP, the port-id field is 16-bit, after 4-bit for priority, only 12 bit left for port-id, which is 4096.
2 MLAG peers are considered as 1 virtual switch, which means MLAG agent also needs to assign a port-id for corresponding peer-port and track their status. So now the space is cut half to 2048.
All physical ports need port-id, including ethernet and port-channel.
Considering a 7508N chassis with 8 x 7500R-36CQ-LC LC, how many port-id consumed?

By default, 1 QSFP port reserve 4 port-ids, no matter the speed or up/down status - "transceiver qsfp default-mode 4x10G"
1 36CQ-LC = 4 x 36 = 144 port-ids
8 36CQ-LC = 144 x 8 = 1152
After all, we still have 2048 - 1152 = 896 port-ids available for port-channels.

And still need some for L3 uplink, peer link and management interfaces, say 32.
Now the max # is 896 - 32 = 864

What happens if you have a 7512N with 12 x 36CQ LC?

12 36CQ-LC = 144 x 12 = 1728 port-id
Max# of MLAG port-channel = 2048 - 1728 - 32 = 285
Opps! Surprising, right? A chassis with more slots and more LCs supports much fewer MLAGs.
So the best system for scale MLAG is 7508 chassis with 8 x 36CQ LC.

How to check port-id usage?

Arista.EOS#bash echo "ls -l /ar/Sysdb/interface/eth/portid" | python -m Acons Sysdb | more

Connecting to local unix socket @00002 ...

Connected to process 2244

.....

default collection portId has:

Ethernet10/1/1 !!! local ethernet ports

Ethernet10/1/2

.....

Management1/1 !!! local management interfaces

Management1/2

PeerEthernet10/1/1 !!! remote ethernet ports

PeerEthernet10/1/2

....

PeerPort-Channel1001 !!! remote port-channels

PeerPort-Channel1002

....

Port-Channel1001 !!! local port-channels

Port-Channel1002

4049

A refresh post of 2 old blog posts, 1 and 2.

4/10/2018

Arista EOS: CLI to predict egress LAG/ECMP interface

This is a very useful command when troubleshooting packet loss in an ECMP link. A refresh post of an old post.

arista.EOS.7050SX#sh ip route 22.0.2.91
B E 22.0.2.0/24 [200/0] via 210.100.21.0, Ethernet11/1
via 210.100.22.0, Ethernet21/1
via 210.100.21.12, Vlan3304
via 210.100.21.14, Vlan3305
via 210.100.21.16, Vlan3306
via 210.100.22.12, Vlan3404
via 210.100.22.14, Vlan3405
via 210.100.22.16, Vlan3406
via 210.100.21.2, Port-Channel1931
via 210.100.21.4, Port-Channel1932
via 210.100.22.2, Port-Channel1941
via 210.100.22.4, Port-Channel1942
via 210.100.21.6, Ethernet12/1.3301
via 210.100.21.8, Port-Channel1933.3302
via 210.100.21.10, Port-Channel1934.3303
via 210.100.22.6, Ethernet22/1.3401
via 210.100.22.8, Port-Channel1943.3402
via 210.100.22.10, Port-Channel1944.3403

arista.EOS.7050SX#sh load-balance destination ip ingress-interface ethernet 36 src-ipv4-addr 20.0.1.100 dst-ipv4-addr 22.0.2.91 ip-protocol 9
Output Interface: Port-Channel1934.3303

arista.EOS.7050SX#sh load-balance destination ip ingress-interface ethernet 36 src-ipv4-addr 20.0.1.100 dst-ipv4-addr 22.0.2.91 ip-protocol 1
Output Interface: Port-Channel1941

show load-balance destination port-channel portchannel [ingress-interface intf] [src-mac srcmac] [dst-mac dstmac] [eth-type ethtype] [src-ip-address src-ip] [dst-ip-address dst-ip] [ip-ttl ttl] [flow-label fl] [ip-protocol proto] [src-l4-port src-port] [dst-l4-port dst-port] [vlan vlan] [non-unicast]

4/09/2018

Arista EOS: ASU/ASU2

Why needed:

Requested by tier-1 cloud/internet customers
For the servers connecting to only 1 TOR switch, the software upgrade down time is very critical because of lacking redundant path.

How does it work?

To look deep into the process of an Arista switch upgrade/reload (just a rough one):

1. Kernel reboot
2. EOS starting
3. Hardware drivers are called to refresh HW
4. Control plane is converged and create forwarding information
5. Hw programming

The whole idea is: keep the hw programing intact while starting software; then re-program hw entries to reflect new forwarding decisions.

AUS vs ASU2:

ASU: retain the hw programming and keep forwarding till step 3. Maximum down time is around 30 seconds
ASU2: A big step further, no hw hard reset but a soft one. Plus hw overwrite so maximum down time is lowered to 300 msec. And graceful-restart must be turned on.

Limitation:

only Trident2 platform supported

CLI:

reload fast-boot - ASU
reload hitless - ASU2

Arista EOS, MLAG (3) - MLAG peer gateway

Arista: MLAG peer gateway
Cisco: vPC peer gateway

Why do we need it?

Some vendors like NetApp and F5, they use switch system MAC to construct packets instead of virtual MAC.
Or it is by a feature called fast path, which just flip the source and destination MAC.
when mlagA receives a packet with destination mac of mlagB, it has to forward it to mlag peer via peer link, which is not a favored behavior

Configuration:

ip virtual-router mac mlag-peer

How does it work?

MLAG peer create an additional MY_MAC entry with MLAG peer address.
When it gets packet with this MAC, just route them instead of fwding via peer link

Useful command and supported platforms

T2 and Arad
show ip virtual-router
show platform trident l3 shadom my-station

Arista EOS, MLAG (2) - Dual-Primary Detection

MLAG Dual-Primary Detection

This is a long-waiting MLAG feature and was introduced from EOS 4.20.1F around late 2017. When peer link is down, the secondary takes over primary. But sometime, the problem is only on the peer link and the peer is still alive. Without this feature, there will be dual MLAG primary and caused traffic disruption like bursty traffic loop.

But if you enable this feature, MLAG will communicate with peer via management interface + peer link. Since out-of-band management interface is considered less chance to be clogged, it will prevent above dual primary scenario.

How does it work?

When peer link is down, the secondary takes over primary immediately.
Meanwhile it starts the dual-primary detection.
If the peer receives heartbeats, it concludes a dual-primary found. As a result, secondary peer will disable ALL interfaces to avoid loop.
When peer link is up, it will start MLAG negotiation and recovers

Here is the configuration:

mlag configuration
peer-address heartbeat 172.30.134.180
! heartbeat via management ip address
dual-primary detection delay 10 action errdisable all-interfaces

How to verify:

Arista.EOS#show mlag det
MLAG Configuration:
domain-id : pg.mlag.leaf1
local-interface : Vlan4094
peer-address : 192.168.255.0
peer-link : Port-Channel2000
hb-peer-address : 172.30.134.181
peer-config : consistent

MLAG Status:
state : Active
negotiation status : Connected
peer-link status : Up
local-int status : Up
system-id : 46:4c:a8:97:83:7d
dual-primary detection : Configured

What happen if heartbeat connection has issue? If there is misconfiguration like missing vrf in hb-peer-address line, or out-of-band management network has connection issue, the system will report

Arista.EOS#sh mlag det
MLAG Configuration:
domain-id : pg.mlag.leaf1
......
MLAG Detailed Status:
....
Heartbeat timeouts since reboot : 1
UDP heartbeat alive : False

Arista.EOS#show logg | grep MLAG-3

Apr 10 00:06:28 Arista.EOS Mlag: %MLAG-3-PEER_HEARTBEAT_TIMEOUT: MLAG stopped receiving UDP heartbeats from the peer 172.30.134.180.

MLAG split-brain

When the mlag split brain happens (the trigger is to disconnect the peer link), both leaf could hash BPDU to 1 peer, and the other peer doesn't receive any BPDU, so all ports are in forwarding and causes a loop.

The STP may kick in and put ports in designated-dispute mode. But after 2 x fdWhile timer, another round of negotiation starts and form a bursty loop every 2 seconds.

An interesting RFE 11825.

FHRP/GLBP vs VRRP vs VARP

Reference links:

1. Active-Active by using VARP - "ip virtual address x.x.x.x" w/o mask

Arista recommends VARP, which is Active-Active Redundancy
HSRP and VRRP是Active-Standby Redundancy

Host发送数据包，如果hash到VRRP slave/HSRP standby，是不处理的，而是bridge到对方，这个是MLAG里面最不希望的情况，就是数据走PeerLink
如果想Active-Active，客户必须手工分配Vlan和Master，比较烦

Configuration is quite simple:

ip virtual mac-address feed:dead:beef
interface vlan 101

ip address 10.10.10.2/24
ip virtual address 10.10.10.1

2. Comparison of virtual ip commands

Summary:

MLAG/"ip virtual addr x.x.x.x":

when sending ARP requests to dstHost, it uses its own eth hw MAC!!
so ARP Resonse肯定回到Sender, 即使ARP Response hash到另外一个Peer, eth hw is booked peerLink.

VXLAN+MLAG/"ip addr virtual x.x.x.x"

uses vMAC in the ARP requests to dstHost;
so need ARP sync between mlag peers.

"ip virtual addr x.x.x.x/24" vs "ip addr virtual x.x.x.x/24"

"ip addr virtual" for VXLAN anycast
"ip airtual addr" for non-VXLAN MLAG, 看上面

"ip virtual address <vip>/mask"，无论有没有mask，必须有phy IP.
vlan - "ip virtual address 10.10.10.1" + global - "ip virtual mac aa:bb:cc"

标准的VARP config
host resolves GW

GARP: dMac=ff:ff:ff | sMAC=aa:bb:cc | sndHw=aa:bb:cc | sndIP = vip,10.10.10.1
关键是vMAC aa:bb:cc hosts vIP
ARP reply: 如何一个收到Arp req 的router都可以返回, dMac = hostMAC, 其他和上面一样

GW resolves host:

ARP request: dMAC=ff:ff:ff | sMAC = swMAC | sndHW = swMAC | sndIP = phyIP, 不是vIP
所以会有mlag-peer的问题?
不需要ARP sync, 因为sndHW = swMAC?

vlan - "ip virtual address 10.10.10.1/24" + global - "ip virtual mac aa:bb:cc"

注意是有network mask. 而且phy ip 和 vip不是一个网段
还要增加一个static route - "ip route 10.10.10.0/24 vlan 100"

为了节省phy ip, 如果一个vlan across 100 vtep/mlag, 200 phy ip 就被用掉了。

host resolves GW:

GARP/ARP和前面一样

GW resolves host:

ARP req: dMAC=allFF | sMAC = swMAC | sndHW = vMAC | sndIP = vIP
需要ARP sync, 因为sndHW = vMAC, sw2收到应该sw1的ARP reply，也吃了因为是vMAC?

vlan - "ip address virtual 10.10.10.1/24" + global - "ip virtual mac aa:bb:cc"

不需要phy IP under vlan
专门为VXLAN, = Anycast Gateway
host resolves GW:

没有GARP，为啥？
只能是ARP reply, 里面全virtual, srcMAC = vMAC | sndHW = vMAC | sndIP = vIP

GW resolves host:

也一样，全是vritual address
需要ARP sync

Arista EOS, MLAG (1) - Basic Configuration

Arista MLAG - basic configuration

For the details, please refer above link. Here is the list of needed configurations:

Port-channel for peer link
VLAN for peer link
L3 SVI for peer link VLAN
MLAG configuration:

domain-id (must be matched on both peers)
local-interface (above L3 SVI)
peer-address
peer-link

Useful commands:

show mlag detail
show mlag interface

Arista EOS: trunk group

From the below link of "MLAG - basic configuration", there have the following configuration of MLAG peer link VLAN:

vlan 4094
trunk group peerLink
interface port-ch 2000
switch trunk group peerLink

Why do we need to assign vlan 4094 to trunk group? Quota from the reference of EOS configuration - VLAN,

"VLANs configured in a trunk group are 'pruned' off all ports that are not associated with the trunk group".

So if you have other ethernet or port-channels are configured as trunk, by default ALL VLANs are enabled if you don't specify the VLAN range. In this case, peerLink VLAN is also included. This is not an expected behavior or good practice, since the peerLink carries the critical control plane information.
But if you configure VLAN in trunk group, you have to specify the physical interfaces are associated with this trunk group. This is to provide a casual configuration causing the disruption of peerLink Vlan

4/06/2018

Tips on EOS tcpdump

Since Arista EOS is based on Linux kernel, it inherits the tcpdump, the powerful debug tool. Here is some tips on how to use it in EOS.

Reference (most contents from) : Using tcpdump for troubleshooting @ Arista.com. A refresh post of old blog.

1. Use "bash ifconfig" to find out interface names

bn303.jhm.mlagA.profA0.w.16:01:14#bash ifconfig | grep mtu
et10_10_1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9214
et10_10_2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9214
....
vlan200: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
vlan201: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

2. dump pkts on vlan interface

bn303.jhm.mlagA.profA0.w.16:02:34#bash tcpdump -i vlan200
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan200, link-type EN10MB (Ethernet), capture size 262144 bytes
16:11:35.518187 de:ad:be:ef:ba:11 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 86: 2000:22:0:c8::fd > ff02::1: ICMP6, neighbor advertisement, tgt is 2000:22:0:c8::fd, length 32

3. dump pkts on ethernet interface with more info

bn303.jhm.mlagA.profA0.w.16:11:41#bash tcpdump -i et10_10_1 -v -vv
tcpdump: listening on et10_10_1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:12:58.382825 28:99:3a:10:3b:90 (oui Arista Networks) > 01:80:c2:00:00:0e (oui Unknown), ethertype LLDP (0x88cc), length 324: LLDP, length 310
Chassis ID TLV (1), length 7
Subtype MAC address (4): 44:4c:a8:a5:11:40 (oui Arista Networks)
0x0000: 0444 4ca8 a511 40
Port ID TLV (2), length 16
Subtype Interface Name (5): Ethernet10/10/1
0x0000: 0545 7468 6572 6e65 7431 302f 3130 2f31

4. Run tcpdump directly in EOS

bn303.jhm.mlagA.profA0.w.15:35:13#tcpdump int eth3/1/1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on et3_1_1, link-type EN10MB (Ethernet), capture size 262144 bytes
15:54:45.654907 44:4c:a8:97:8c:52 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110

bn303.jhm.mlagA.profA0.w.15:56:37#tcpdump int vlan 2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan2, link-type EN10MB (Ethernet), capture size 262144 bytes
15:57:05.393026 de:ad:be:ef:ba:11 > Broadcast, ethertype ARP (0x0806), length 56: Reply 22.0.2.253 is-at de:ad:be:ef:ba:11, length 42

5. dump ospf packets

# bash tcpdump -ni vlan1224 proto ospf

yo411.15:24:18#bash tcpdump -ni vlan1224 proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1224, link-type EN10MB (Ethernet), capture size 262144 bytes
15:24:31.110294 00:1c:73:c6:b0:0d > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 110.2.13.10 > 224.0.0.5: OSPFv2, Hello, length 48

15:24:35.394905 00:1c:73:44:58:d0 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 110.2.13.2 > 224.0.0.5: OSPFv2, Hello, length 48

6. dump mlag udp KA

[admin@bn302 ~]$ tcpdump -i ma1_1 udp 4432 -vv -X
tcpdump: syntax error in filter expression: syntax error
[admin@bn302 ~]$ tcpdump -i ma1_1 udp port 4432 -vv -X
tcpdump: listening on ma1_1, link-type EN10MB (Ethernet), capture size 262144 bytes
15:03:22.707628 44:4c:a8:34:cc:d0 (oui Arista Networks) > 00:1c:73:ac:36:09 (oui Arista Networks), ethertype IPv4 (0x0800), length 121: (tos 0xe0, ttl 255, id 41931, offset 0, flags [DF], proto UDP (17), length 107)
bn302-1.sjc.aristanetworks.com.4432 > bn303.sjc.aristanetworks.com.4432: UDP, length 79
0x0000: 45e0 006b a3cb 4000 ff11 715a ac1e 871e E..k..@...qZ....
0x0010: ac1e 8620 1150 1150 0057 65e4 0224 7688 .....P.P.We..$v.
0x0020: ecb6 2000 7564 7048 6561 7274 6265 6174 ....udpHeartbeat
0x0030: 80c0 8000 0000 0100 0000 08ff f000 0000 ................
0x0040: 0000 00ff f000 0000 0000 0040 b24f ef05 ...........@.O..
0x0050: 4984 c84d 0100 0869 6e61 6374 6976 654d I..M...inactiveM

0x0060: 0200 0800 0001 7900 0000 02 ......y....

7. Other useful options and samples

bash tcpdump -nevvi et1 ether dst host 01:80:c2:00:00:0e
bash tcpdump -nevvi any host 10.1.1.1

[admin@wa466 ~]$ tcpdump -vv ip6 -i et56_1 -w /mnt/flash/bgp.cap
tcpdump: listening on et56_1, link-type EN10MB (Ethernet), capture size 262144 bytes
2 packets captured
...

[admin@wa466 ~]$ tcpdump -vvv -r /mnt/flash/bgp.cap -n | more
reading from file /mnt/flash/v6.bgp.cap, link-type EN10MB (Ethernet)
22:17:32.070318 44:4c:a8:97:72:b7 > 00:12:01:00:00:01, ethertype IPv6 (0x86dd), length 94: (hlim 255, next-header TCP (6) payload length: 40) 2000:88:88
::1.48744 > 2000:88:88::2.bgp: Flags [S], seq 4088296625, win 28800, options [mss 1440,sackOK,TS val 3863837 ecr 0,nop,wscale 7], length 0
22:17:32.070466 00:12:01:00:00:01 > 44:4c:a8:97:72:b7, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 64, next-header TCP (6) payload length: 40)
2000:88:88::2.bgp > 2000:88:88::1.48744: Flags [S.], seq 3002335018, ack 4088296626, win 14280, options [mss 1440,sackOK,TS val 8967227 ecr 3863837,nop
,wscale 9], length 0
22:17:32.070489 44:4c:a8:97:72:b7 > 00:12:01:00:00:01, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header TCP (6) payload length: 32) 2000:88:88
::1.48744 > 2000:88:88::2.bgp: Flags [.], seq 1, ack 1, win 225, options [nop,nop,TS val 3863837 ecr 8967227], length 0
22:17:32.070661 44:4c:a8:97:72:b7 > 00:12:01:00:00:01, ethertype IPv6 (0x86dd), length 141: (class 0xc0, hlim 255, next-header TCP (6) payload length: 8
7) 2000:88:88::1.48744 > 2000:88:88::2.bgp: Flags [P.], seq 1:56, ack 1, win 225, options [nop,nop,TS val 3863837 ecr 8967227], length 55: BGP
Open Message (1), length: 55
Version 4, my AS 23456, Holdtime 180s, ID 5.5.5.5
Optional parameters, length: 26
Option Capabilities Advertisement (2), length: 24
Multiprotocol Extensions (1), length: 4
AFI IPv6 (2), SAFI Unicast (1)
0x0000: 0002 0001
Route Refresh (2), length: 0
Graceful Restart (64), length: 2
Restart Flags: [none], Restart Time 300s
0x0000: 012c
32-Bit AS Number (65), length: 4
4 Byte AS 4264492530
0x0000: fe2e fdf2
Multiple Paths (69), length: 4
AFI IPv6 (2), SAFI Unicast (1), Send/Receive: Receive
0x0000: 0002 0101

Eos: last 100 commands you ran

Starting from bloomington release - 4.20.4F, the following command will print out last 100 commands you ran and duration details.

bn303.jhm.mlagA.profA0.w.14:21:02#bash CliCtrl --print-state | more
Activity Lock owner is: 0
Recently run commands:
TID: 17702, Duration: 0.0779159069061*, Start: 1523050110.22, End: None, Cmd: bash CliCtrl --print-state | more
TID: 17702, Duration: 0.139348983765, Start: 1523049662.16, End: 1523049662.3, Cmd: bash CliCtrl --print-state
TID: 17702, Duration: 0.00744891166687, Start: 1523049649.22, End: 1523049649.23, Cmd: enable
TID: 11106, Duration: 0.0013120174408, Start: 1523046913.33, End: 1523046913.33, Cmd: show monitor device-health category
TID: 11106, Duration: 0.00137400627136, Start: 1523046913.33, End: 1523046913.33, Cmd: show monitor device-health component
TID: 11106, Duration: 0.107572078705, Start: 1523046913.22, End: 1523046913.33, Cmd: show agent event history