I am testing failover using the 'Failover VIP' option within the GUI. The nodes are on the same VLAN, and the latency is <10ms on average. I was on the phone with the JTAC yesterday and they stated that the ~120 seconds failover time we are seeing is expected behavior when using ESP with Network Connect, and that if we wanted better failover performance that we could switch to using SSL instead. I tested this, and the time is indeed better when using SSL, but is this expected behavior? Both the internal and external interfaces are on a separate VLAN, but the VLAN is shared between each interface (in other words, the external interfaces of each node share a common VLAN, and the internal interfaces on each node also share a common VLAN, but this VLAN is different than the external VLAN). Each node is using an HSRP virtual address (again, this is unique per VLAN) as their common gateway. Also, I haven't received a satisfactory answer to the dual leader issue - according to the JTAC, multicast/broadcast should only be used when deploying multiple nodes in an active/active deployment. Even though unicast should be more efficient, I can't think of a reason why multicast or broadcast shouldn't work with dual nodes in an active/passive deployment.
... View more
I am in the process of building an active/passive cluster which spans two trunked Cisco 6509 switches. The external interfaces are in a common VLAN, and the internal interfaces are in their own VLAN as well. Each VLAN is using HSRP (which the SA6500s are using as their gateway). The issues I am seeing are: 1) If the cluster is set to unicast mode, the two nodes show up as leader and enabled, as expected. However, when testing VIP failover, the failover performance is slow, with users experiencing an outage of 20 - 120 seconds, in some cases losing their network connect access altogether. 2) If the cluster is changed to multicast or broadcast mode, each node shows up as a leader, and failover doesn't work at all. I should mention that there are no ACLs, firewalls, etc. between the nodes. In addition, they are both running v7.0R3. I've tested the same scenario on other code revisions (e.g. 6.5R2), with no change in the behavior. I appreciate any insight that you could provide.
... View more