mvanopst at umiacs
Feb 22, 2011, 6:30 PM
Views: 1069
Permalink
|
|
MAC table update problems with PBR applied E1200
|
|
Hi All,
I do have a case open with Force10 support on this, but it's been a long
standing issue and I've gone so far as to re-architect our rather
heterogeneous network to maintain a force10-only network path between
our various F5s and ServerIrons to stop vendor finger-pointing, so I'm
interested to hear if anyone else is experiencing something similar.
In a nutshell, the MAC address table isn't getting updated on an E1200
terascale that has PBR ip-redirect lists on all of my vlans. I can make
virtual IPs (whose actual mac address moves with the IP's home) fail
over from systems connected to the stated E1200 to a C300 that's doing
only layer 2 switching, but failing back to the original loadbalancers
doesn't work. No link-state events necessarily occur when they move,
which may be part of why it seems to ignore the gratuitous ARPs. I need
to clear the arp cache on the E1200 so it will flood and relearn to
restore connectivity.
I have the basic things like "mac-address-table station-move
refresh-arp" and "arp learn-enable" set. I'm aware of the various PBR
fixes that have been made lately, and I've recently taken the downtime
to update to the latest FTOS (8.4.2.1) and enable the microcode ipv4-lda
to no effect (which also removes IPv6 support ... good thing I only had
that in testing and not production yet). So I'm appealing to a larger
audience to see if anyone has had similar experiences, or can recommend
some way to redesign around this. I'm not in a position to pitch-fork
these particular boxes yet, and PBR is important for my ability to get
line-rate connectivity between our public and non-public IP spaces
without a NAT bottleneck.
Thanks,
- mike
_______________________________________________
force10-nsp mailing list
force10-nsp [at] puck
https://puck.nether.net/mailman/listinfo/force10-nsp
|
MAC table update problems with PBR applied E1200