[c-nsp] Unicast traffic being sent to every port? Aging issue?
Jay Nakamura
zeusdadog at gmail.com
Mon Mar 22 23:27:56 EDT 2010
Long ago, I had this problem but the zfs1 in this case was a syslog
server. What was happening was, all the hosts were sending traffic to
the server but since it was just receiving syslog/UDP, that host
rarely ever sent any traffic back out. So switches didn't know where
it was once the forwarding table expired the MAC and flooded all
ports. We just setup a cron job every 10 minutes (or something. It
was 13 years ago.) to send out a ping to the host connected to the
farthest switch. So, I guess it kind of depends on what traffic is
going/coming from zfs1. If it's like syslog, it may be the same as
what I went through.
On Mon, Mar 22, 2010 at 11:14 PM, Ray Van Dolson <rvandolson at esri.com> wrote:
> On Mon, Mar 22, 2010 at 08:04:10PM -0700, Jay Hennigan wrote:
>> On 3/22/10 7:03 PM, Ray Van Dolson wrote:
>> > We have two Dell PowerConnect M6220 switches (A1 and B1). They are not
>> > cross-connected, but both have uplinks to the same subnet:
>> >
>> > zfs1
>> > /
>> > +----+
>> > | A1 |---------|
>> > +----+ +-------+
>> > | Cisco |------- linux1
>> > +----+ +-------+
>> > | B1 |---------|
>> > +----+
>> > / \
>> > esx1 esx2
>> >
>> > There's a host hanging off of A1 (zfs1) and several ESX hosts hanging
>> > off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the
>> > Cisco as well (actually many hosts, but for the sake of description
>> >
>> > What's happening is, esx1/2 beging talking to zfs1. All is well for a
>> > while... but at some point, zfs1's MAC address expires from the CAM on
>> > the switch (I guess that is what is happening).
>> >
>> > At that point, the Cisco begins forwarding the unicast packets to all
>> > its ports. The result -- linux1, and all other hosts see the packets.
>> > Occasionally, when we're dealing with a lot of traffic, this seriously
>> > impacts performance.
>>
>> Is the Cisco a router or a layer 2 switch? All hosts in the same IP
>> subnet? Subnet masks all match? Nothing doing proxy-arp?
>>
>> > My question here is.. what is the _right_ way to deal with this? This
>> > "flooding" can continue for many minutes at a time.. it isn't until an
>> > ARP reply eminates from zfs1 that the CAM table is populated again and
>> > the broadcasting stops.
>>
>> If these are layer 2 switches, ARP won't have anything to do with it.
>>
>> If zfs1's MAC expires from the MAC address table on the cisco, it will
>> flood the next packet for that MAC. A1 will forward it to zfs1 or flood
>> if it too has expired the MAC.
>>
>> When zfs1 replies, A1 forwards the reply to the cisco. At that point,
>> the cisco should re-install the MAC into its address table and the
>> flooding cease.
>>
>> This should happen with a single packet.
>>
>> Does this happen with any other hosts behind A1? Any interface errors
>> on any of the devices?
>>
>> > I wonder if zfs1 would send back an ARP response quicker were it not
>> > behind an additional switch (the PowerConnect)...
>>
>> If layer 2 switches, ARP doesn't have anything to do with it.
>
> I'll have to find out how the Cisco's are configured. I wouldn't be
> surprised if they're doing some Layer 3 though as I know some VLAN
> routing is going on...
>
> The Dell switches both seem to have "Routing Mode" enabled as well (but
> proxy arp disabled).
>
> There currently aren't any other hosts behind A1, but that would be a
> good test. No interface errors currently.
>
> Firmware is old on A1, so at this point I'm a little suspicious it's to
> blame.
>
> Just wanted to try and wrap my head around this first.
>
> Thanks,
> Ray
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list