Extreme Networks ExtremeWare XOS 11.3, Manual

Page: 76 / 698

Managing the Switch
ExtremeWare XOS 11.3 Concepts Guide
76
EAPS Continued EAPS Shared Ports, Partner Mode
Since the Partner node does not actively block traffic, whether the state is
Ready or Blocking, it does not make any difference if the master MSM fails
over. There should be no data loss. However, if the Partner is in the Blocking
state, and it needs to advertise blocking-ids in a "Root Blocker" situation, it
could take a couple of seconds to relearn the neighbors states and to advertise
the correct information.
No
Extreme Standby
Router Protocol
(ESRP) If MSM failover occurs on the ESRP MASTER switch, it sends a hello packet
with the HOLD bit set. On receiving this packet, the ESRP SLAVE switch
freezes all further state transitions. The MASTER switch keeps sending hellos
with the HOLD bit set on every hello interval. When the MASTER is done with
its MSM failover, it sends another hello with the HOLD bit reset. The SLAVE
switch resumes normal processing. (If no packet is received with HOLD bit
reset, the SLAVE timeouts after a certain time interval and resumes normal
processing).
MSM failover on the ESRP SLAVE switch is of no importance because it is the
SLAVE switch.
Yes
Virtual Router
Redundancy
Protocol (VRRP) There is a brief interruption of traffic flow as the VRRP protocol re-establishes
the correct state. With the default configuration settings, the worst-case
interruption is 3 seconds. No
Extreme Discovery
Protocol (EDP) EDP does not checkpoint protocol data units (PDUs) or states, so the backup
MSM does not have the neighbor’s information. If the backup MSM becomes
the master MSM, and starts receiving PDUs, the new master learns about its
neighbors. No
Protocol
Independent
Multicast (PIM) After a failover, all hardware and software caches are cleared and learning from
the hardware is restarted. This causes a traffic interruption since it is the same
as if the switch rebooted for all Layer 3 multicast traffic. No
Extreme Loop
Recovery Protocol
(ELRP) If you use ELRP as a standalone tool, hitless failover support is not needed
since the you initiate the loop detection.
If you use ELRP in conjunction with ESRP, ELRP does not interfere with the
hitless failover support provided by ESRP.
Although there is no hitless failover support in ELRP itself, ELRP does not
affect the network behavior if a failover occurs.
No
Link Layer Discovery
Protocol (LLDP) Since LLDP is more of a tool than a protocol, there is no hitless failover
support. LLDP is similar to EDP, but there is also a MIB interface to query the
information learned. After a failover, it takes 30 seconds or greater before the
MIB database is fully populated again. No
Link Aggregation
Control Protocol
(LACP) If the Backup MSM becomes the primary MSM, it starts receiving PDUs, which
causes the aggregator’s membership to change while the protocol converges.
This causes a disruption to traffic but should settle within 6 seconds. No
Routing Information
Protocol (RIP) RIP does not support graceful restart, so the route manager deletes all RIP
routes 1 second after the failover occurs. This results in a traffic interruption
as well as an increase in control traffic as RIP
re-establishes its database. No
Routing Information
Protocol next
generation (RIPng) RIPng does not support graceful restart, so the route manager deletes all RIPng
routes 1 second after the failover occurs. This results in a traffic interruption.
In addition, after RIPng comes up on the new primary MSM, it relearns the
routes from its neighbors. This causes an increase in control traffic onto the
network.
No
Table 11: Protocol support for hitless failover (Continued)
Protocol Behavior Hitless