- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- Mesh drops first packet(s)
Switches, Hubs, and Modems
1753971
Members
7779
Online
108811
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-06-2009 02:07 AM
тАО10-06-2009 02:07 AM
Mesh drops first packet(s)
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?
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?
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-06-2009 05:01 PM
тАО10-06-2009 05:01 PM
Re: Mesh drops first packet(s)
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?
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?
there is no rest for the wicked yet the virtuous have no pillows
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-07-2009 12:14 AM
тАО10-07-2009 12:14 AM
Re: Mesh drops first packet(s)
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 :)
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 :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-07-2009 12:34 AM
тАО10-07-2009 12:34 AM
Re: Mesh drops first packet(s)
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.
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.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP