VMAC for VRRPv3? Analysis of Design Tradeoffs
Whirlwind Historical Context A few rare, broken ARP implementations for IPv4 ignored gratuitous broadcasts To maximize interoperability, VRRP (and its proprietary forerunners) used VMAC VMAC has both benefits and drawbacks Current VRRP for IPv6 continues with VMAC mainly because it worked for IPv4
Advantages of VMAC Router failover is nearly invisible to hosts Non-compliant ND implementations work Packet loss between router and host at failover time is benign Helps router choose source address for ICMP error messages
Disadvantages of VMAC (1 of 2) Contributes to complexity of draft –special rules for FDDI –source routing concerns for Token Ring –"When a VRRP router restarts or boots, it SHOULD not send any ND messages with its physical MAC address for the IPv6 address it owns,..." Duplicate MAC addresses may not be handled well in some LAN environments –ATM LAN Emulation “beyond the scope” of draft –one wireless station is limited to one address –however, note that 802.1X access control looks OK
Disadvantages of VMAC (2 of 2) Tracing and quarantining failures or mis- configurations by MAC address is harder Hosts cannot readily detect failover Timing issues around LAN partitioning and reconnection become more complex Some router hardware does not support multiple MAC addresses (e.g., Cisco 4000 series)
Additional issues from the list Don Provan’s NetGear FS524S switch did not forward a new packet to the port where its source MAC address was last heard from –two Masters will never hear each other Bridges using 802.1Q Shared VLAN Learning (SVL) would have trouble if the same VRID appeared on two VLAN’s
Scenario: Normal Failover Two participating routers, on same switch VMAC works well here Only Switch B even notices a change
Scenario: Rogue Router Unexpected VRRP router appears on LAN With VMAC, bridge tables change twice per second; about half the packets get out Without VMAC, bridge forwarding tables never change; host’s cache changes slowly LAN administrator traces MAC address
Scenario: Packet Loss Router 1 is cut off; Router 2 takes over Router 2’s Neighbor Advertisement is lost VMAC has an advantage here But if Router 2 just repeats it 1 sec later… If VRRP packet is lost, switches won’t learn; this works better without VMAC
Scenario: Spanning Tree Switch B loses its connection to Switch A Switch C will join A’s span. tree in ~20 sec Meanwhile, Router 2 becomes Master also With VMAC, Host 3 may lose for ½ sec Easier to analyze without VMAC
Questions?
Summary of Proposed Changes Eliminate use of VMAC, but… Use virtual IPv6 address Bag “MUST NOT” answer ping if prio<255 Listen/audit VRRP packets when prio=255 Accept VRRP packets with wrong interval Send unsolicited ND broadcast twice