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

No comments:

Post a Comment