ArubaOS-CX VRRP and Active Gateway: First Hop Redundancy - 夜莺博客

ArubaOS-CX VRRP and Active Gateway: First Hop Redundancy

ArubaOS-CX gives you two ways to provide a redundant default gateway: VSX active-gateway, which makes both switches forward with a shared virtual MAC, or VRRP, which elects one master and keeps the other on standby. Choosing well matters because the two are mutually exclusive in the same SVI context, and the wrong choice adds protocol overhead you do not need - or removes the failure protection you do. This guide configures both, explains the virtual MAC rules, and shows the verification commands and failure behaviour for each.

Which option fits

VSX active-gateway VRRP
Model Active-active Active-standby
Protocol overhead None (no FHRP) VRRP advertisements
Requires VSX pair with ISL and keepalive Any two L3 switches
Bandwidth use Both peers forward north-south Standby idle until failover
Best for Leaf pairs inside a VSX domain Edges, mixed vendors, non-VSX pairs

The rule of thumb: inside a VSX pair, use active-gateway and skip VRRP entirely; use VRRP when the two routers are not a VSX pair or are from different vendors. Note the documented exclusivity - VSX active-gateway and VRRP cannot be configured on the same VLAN interface, and active-forwarding cannot coexist with active-gateway on the same SVI.

VSX active-gateway configuration

! both peers: same VSX domain, ISL and keepalive already up
switch(config)# interface vlan 10
switch(config-if-vlan)# ip address 192.168.10.2/24
switch(config-if-vlan)# active-gateway ip 192.168.10.1 mac 00:00:00:00:01:01
switch(config-if-vlan)# active-gateway ipv6 fe80::100 mac 00:00:00:01:01:01
switch(config-if-vlan)# ipv6 address link-local fe80::100/64
switch(config-if-vlan)# exit
switch(config)# vsx
switch(config-vsx)# vsx-sync active-gateways

switch# show active-gateway
switch# show active-gateway interface vlan 10
switch# show ip route 192.168.10.0/24
switch# show vsx status

Two ordering rules from the product documentation are worth memorising: the SVI must have an IP address in the same subnet as the active-gateway IP, and if you use the same MAC on both VSX peers the synchronisation can cause traffic disruption - the recommended pattern is a distinct virtual MAC for the gateway, configured identically on both peers via vsx-sync. Without a MAC configured, the switch uses the system MAC, and active-gateway l3-src-mac controls the source MAC used for routed packets.

VRRP on AOS-CX

switch(config)# router vrrp enable
switch(config)# interface vlan 20
switch(config-if-vlan)# ip address 192.168.20.2/24
switch(config-if-vlan)# vrrp 20 address-family ipv4
switch(config-if-vlan-vrrp)# vrrp 20 ip 192.168.20.1 primary
switch(config-if-vlan-vrrp)# vrrp 20 priority 200
switch(config-if-vlan-vrrp)# vrrp 20 preempt
switch(config-if-vlan-vrrp)# vrrp 20 preempt delay minimum 30
switch(config-if-vlan-vrrp)# vrrp 20 track 1
switch(config-if-vlan-vrrp)# exit
switch(config-if-vlan)# exit
switch(config)# track 1 interface 1/1/25
switch(config-track)# exit

switch# show vrrp
switch# show vrrp brief
switch# show vrrp interface vlan 20
switch# show track

The primary keyword marks the owning router and lets it keep the real interface IP as the virtual IP where you want that. Priority decides the master (higher wins, 255 is the owner); a preempt delay of 30 seconds prevents a rebooting switch from stealing mastership before its routing table has converged, which is the failure mode that makes VRRP look unreliable. Tracking an uplink port means the gateway yields when its path to the core is gone.

Failure behaviour to test

switch# show vsx status
switch# show vsx brief
switch# show interface lag 10 vsx
switch# show vrrp statistics
switch# show logging -r | include -i 'vrrp|vsx|active-gateway'

Before you trust either design, break it on purpose in a lab: pull the ISL, power off one peer, and drop an uplink. With active-gateway you should see no gateway change at all from the host's perspective; with VRRP you should see a mastership transition inside a second, and the ARP/ND entries converging. If hosts lose their gateway for longer than that, the failure is usually in the L2 convergence or in a stale virtual MAC entry, not in the FHRP itself. Related reading: ArubaOS-CX VSX configuration, VSF stacking, Cisco HSRP and Junos VRRP for the equivalent designs elsewhere.

原文链接:https://arubanetworking.hpe.com/techdocs/AOS-CX/10.13/HTML/vsx/Content/VSX_cmds/act-gat-10.htm