Forum Discussion
smp_86112
Cirrostratus
CirrostratusLACP Behavior
I'm collaborating with our network team on setting up an etherchannel to a couple of new 6900 LTM units running in Active/Standby mode. I've got interface 1.1 and 1.3 on the LTM in a trunk on both LTMs, and the trunk is assigned to the external VLAN. I've got a MAC Masquerade and floating IP address assigned to the external VLAN.
While "LTM1" is Active, "SWITCH1" shows the floating MAC on the port channel while "SWITCH2" shows the floating MAC on the trunk link between the two switches. That's all fine and good. When we flip so that "UNIT2" is Active, it runs OK for a short amount of time - it has varied somewhere between about 30 seconds and a couple of minutes. Initially SWITCH2 sees the floating MAC on the port channel, while SWITCH1 sees the floating MAC on the trunk link, which is what I expect. However after a short period of time, the switches revert back - the floating MAC is seen in the port channel of SWITCH1, while SWITCH2 sees the floating MAC on the trunk link between the two switches. Yet on the LTMs, there was no failover activity - LTM2 remains active. But of course since the switches have reverted back, the traffic is being forwarded by SWITCH1 to the Standby so nothing works.
The F5 trunk is configured with LACP in Active mode, a Short timeout, Auto link selection policy, and Source/Destination IP address Frame Distribution Hash. My network guys suggested Active mode, and they made it sound like the Cisco was also running in Active mode which is what they believe Cisco recommends.
I have been doing tcpdumps on the external VLAN while this happens, and I can't see anything transmitted from the Standby (LTM1) that would make SWITCH1 think it suddenly has the floating MAC. Of course there isn't anything on the Cisco side to make us think anything is wrong there either. So we are left pointing fingers. I'd appreciate the perspective from someone a bit more familiar with the Cisco side of things.
The etherchannel and it's port members look like this on both switches.
interface Port-channel10
switchport access vlan 73
switchport mode access
end
interface FastEthernet0/21
switchport access vlan 73
switchport mode access
speed 100
duplex full
udld port
channel-group 10 mode active
end
interface FastEthernet0/23
switchport access vlan 73
switchport mode access
speed 100
duplex full
udld port
channel-group 10 mode active
end
4 Replies
HamishCirrocumulus
Its not really an answer to your questions, but is there a reason you want to use floating MAC's? The gratuitous ARP code is a lot more robust nowadays than it used to be, and you only have to worry about ARP caches in extreem circumstances now.
Obvious question sorry... You do have LTM1 connected solely to SWITCH1 and LTM2 solely to SWITCH2 don't you?
H
smp_86112Yes, LTM1 is only connected to SWITCH1, and 2->2.
Our organization was seriously damaged about 2 years ago because the arp cache on a directly-connected router did not update after a failover event. Using the masquerade feature is an additional layer of redundancy that our organization desires. And it has worked great in my experience so far.- smp_86112I did a closer study of the network traces, and in fact I did find the evidence I was looking for. In a nutshell, it appears the Standby unit uses the masquerade MAC address of the external VLAN when it ARPs. The Active unit appears to be using the base MAC address of the external VLAN. This seems like a problem - the Standby unit should never be using the masquerade MAC. Am I crazy?
- smp_86112I closely examined the configs between the Active and Standby units, and found that I had created a VLAN group in a different partition at some point during my testing. I don't really know how to use VLAN groups yet (this was just a sandbox), but obviously it can seriously mess with my L2 communication. I removed the group and network traces confirm the L2 behavior I expect - the Standby now uses the base MAC address of the external VLAN instead of the masquerade MAC.
