ASU = Accelerated Software Upgrade
- EOS Docu
- 就是在Control Plane booting的时候，Hardware继续Fwd Traffic based on old state
- 等Control Plane is up and running, refresh hw. 所以Traffic disruption大概是30 seconds.
- CLI: reload fast-boot
- 还有一个ASU+
ASU2
- 没有Document ?
- 就是加上Protocol GR，例如BGP, OSPF
- Traffic disruption is about 50ms
- CLI: reload hitless
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
