Arista 7050CX - Packet Forwarding Pipeline

 

Reference: https://www.arista.com/assets/data/pdf/Whitepapers/Arista_7050X_Switch_Architecture.pdf

TH/Trident low LPM

On Arista DCS-7260CX-64-F platform, if you see hw resource - LPM/V4Routes running out, have to change the "platform trident forward partition". Agent will restart but doesn't a reboot. 

nv475.08:45:07(config)#sh hardware capacity utilization percent exceed 50
Forwarding Resources Usage

Table   Feature    Chip       Used   Used      Free    Committed    Best Case        High
                           Entries    (%)   Entries      Entries          Max   Watermark
                                                                      Entries
------- ---------- ------ --------- ------ ---------- ------------ ------------ ---------
LPM                           8190   100%         0            0         8190        8190
LPM     V4Routes              8190   100%         0            0         8190        8190

nv475.08:52:45(config)#sh ip route 151.131.34.0

VRF: default
======================================================
WARNING: Some of the routes are not programmed in
hardware, and they are marked with '*'.
======================================================

*B E    151.131.34.0/24 [200/0] via 100.1.0.44, Vlan10

nv476.11:05:47#sh platform trident forwarding-table partition

L2 Table Size: 72k

L3 Host Table Size: 72k

LPM Table Size: 16k, uRPF is disabled

nv475.09:27:35(config)#platform trident forwarding-table partition ?

  0  136k l2 entries, 8k l3 host, 16k lpm entries

  1  104k l2 entries, 40k l3 host, 16k lpm entries

  2  72k l2 entries, 72k l3 host, 16k lpm entries

  3  40k l2 entries, 104k l3 host, 16k lpm entries

  4  8k l2 entries, 8k l3 host, 90k lpm entries <<< this one!

But this change will impact MLAG because lower MAC capacity. 

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

Trident Platform: route not hw programmed

If you see some v4 or v6 routes not hw programmed in the output of "show ip route", you may need to try to adjust hardware routing-table partition. 

ck494.17:37:15.(config)#platform trident routing-table partition ?
  1  16K IPv4, 6K IPv6 ( prefix len up to /64 ), 1K IPv6 ( any prefix length )
  2  16K IPv4, 4K IPv6 ( prefix len up to /64 ), 2K IPv6 ( any prefix length )
  3  16K IPv4, 2K IPv6 ( prefix len up to /64 ), 3K IPv6 ( any prefix length )
  4  16K IPv4, 0K IPv6 ( prefix len up to /64 ), 4K IPv6 ( any prefix length )