Mesh drops first packet(s)

[Mathias Sundman]

We have just bought 5 new 5412 switches and installed them in a full mesh.

Everything works fine except that we have noticed that we are loosing the very first packets when hosts not already in the mac-table tries to send anything.

While googling around I found a few posts here saying that this how they behave by design.

My question is - Is this acceptable??

What about non-acklowleded UDP based protocols like syslog, snmp etc.

If I run such protocols over internet or congested links I realize that I have to count on losing some data, but shouldn't I even be able to trust my own internal non-congested brand-new network any longer?

I just find that kinda unacceptable. Couldn't the switches buffer the packets while it is determining the forwarding path?

Is there a solution to the problem?

[rick jones]

I'm not from ProCurve land so cannot speak specifically to the 5412, and may have missed an implication of being in a full mesh, but will point-out that I would have thought that prior to the attempt to send the UDP datagram to a station connected to the mesh, there would be a broadcast ARP request and unicast ARP reply for the destination IP going through the mesh which would allow the switch(es) to learn the MACs involved.

Now, if the hosts are using static ARP tables... but I doubt anyone really ever does that these days.

I suppose if a host were snooping the broadcast ARP requests to build-up its ARP cache in anticipation of sending to that IP, it *could* send a UDP datagram without a previous ARP request, but even then, the broadcast ARP request from the as-yet-uncontacted-by-this-host remote would have allowed the switch(es) to learn the path to the destination MAC. So, for *that* to be a problem I would guess that in addition to having an anticipatory ARP cache strategy (which IMO isn't such a hot idea) the host(s) also have to have an ARP cache timeout longer than the switches timeout for their forwarding tables.

So, I would probably try to make sure that my hosts didn't do anticipatory ARP snooping, so they would ARP for destination IPs on the first traffic, and also make certain the ARP cache timeout was < the MAC forwarding timeout.

But that is just a guess. BTW are you sure this is while filling the MAC forwarding table(s) and not while doing spanning tree?

[Mathias Sundman]

Hi Rick,

I got it confirmed from HP yesterday that this is how the mesh works by design, so yes, it is a mesh problem and not a spanning tree problem or anything else.

Good point you have about that ARP packets will "wake n learn" the switches before any real traffic can be sent.

I guess in my tests the arp cache lifetime in the testhosts have been higher than the mac-table lifetime in the switches (5 min per default), which is why I see my first pings disappear.

Now that I've raised the mac-age-time in the switches to 30 min I don't see the problem any longer.

I will probably see a dropped arp request packet in the beginning, that is just retransmitted, so that's not a problem.

Thanks, now I can sleep tight again :)

[Pieter 't Hart]

I agree there should have been an ARP request first this should have filled the MAC-adress table.

a switch that doesn't have a mac-address in it's forwarding table should forward this packet on all ports in the same vlan.
5400's full mesh is something different than spanning tree.
so to prevent loops, a full mesh cannot do this forwarding to all ports.

see page 5-17 of the "Advanced Traffic Management guide"
Unicast Packets with Unknown Destinations
A meshed switch receiving a unicast packet with an unknown destination does not flood the packet onto the mesh. Instead, the switch sends a query on the mesh to learn the location of the unicast destination. The meshed switches then send 802.2 test packets through their non-meshed ports. After the unicast destination is found and learned by the mesh, subsequent packets having the same destination address will be forwarded. By increasing the MAC Age Time you can cause the switch address table to retain device addresses longer.

If you use routing instead, and use the full-mesh to tie the routed networks together you won't have the mac-address table problem.
But then again page 5-5 says :
If meshing is configured on the switch, the routing features (IP routing, RIP, and OSPF) must be disabled.
So you would need to use (an )external router(s) instead of the 5412.