<div dir="auto"> I’ve seen it happen with udp, in my case it was a syslog server, that hardly ever “spoke” so eventually it’s MAC address disappears from the Cam table long before it leaves the arp table and the UDP packets get flooded hoping to find the server. </div><div dir="auto"><br></div><div dir="auto">I’ve also seen this happen in an HA environment, Where it’s possible that traffic can take an asymmetric path. It happens enough that Cisco wrote an article about it years ago. </div><div dir="auto"><br></div><div dir="auto"><div><a href="https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html">https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html</a></div><br></div><div dir="auto">Hope this helps.</div><div dir="auto"><br></div><div dir="auto">rgt</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 16, 2021 at 7:38 AM Michael Di Domenico <<a href="mailto:mdidomenico4@gmail.com">mdidomenico4@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">thanks after two days of digging, i think i finally figured out that<br>
we have a layer 2 routing problem.  i'm not the network guy so i'm not<br>
digging into it deeper, but it appears that there are either<br>
malfunctioning LACP trunks or more likely a misconfigured VPC<br>
connection inside the menagerie of switches the network team built.<br>
<br>
the network is too complicated to describe here, but the base issue is<br>
that there are two switches 'supposedly' operating jointly, but don't<br>
seem to be sharing their CAM/ARP tables correctly.  for whatever<br>
reason packets get duped to the switch that does not have the<br>
destination machine and since there's no arp/cam entry the switch just<br>
blasts the packet out all the ports.<br>
<br>
its not clear why the packets are being sent to layer 2 devices where<br>
the device doesn't exist, but it's clear there's something broken in<br>
the spanning tree database.  it's also not clear why it only affects<br>
one of the vlans and not all.<br>
<br>
but again, not the network guy...  and for once it is the network... :)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Jun 16, 2021 at 12:48 AM Greg Lindahl <<a href="mailto:lindahl@pbm.com" target="_blank">lindahl@pbm.com</a>> wrote:<br>
><br>
> On Mon, Jun 14, 2021 at 12:38:50PM -0400, Michael Di Domenico wrote:<br>
> > i got roped into troubleshooting an odd network issue.  we have a mix<br>
> > of cisco (mostly nexus) gear spread over our facility.  on one<br>
> > particular vlan it's operating as if it's a hub instead of switch.<br>
><br>
> I have run into this situation when I have servers that have incoming<br>
> UDP traffic and never talk or do TCP. The switches have no idea where the<br>
> server is, so they broadcast all of the incoming packets.<br>
><br>
> An ARP reply or connecting with TCP tells the switch which port to use.<br>
><br>
> -- greg<br>
><br>
><br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
</blockquote></div></div>