On Wed, Jan 18, 2017 at 04:56:00PM -0600, Chad Norgan wrote:
> Thanks so much for the deeper understanding. I think from here I'm
> going to get a mirror port setup on the switch so I can confirm that
> the switch is indeed sending that pdu on the restored link. I can then
> take that to the
Shu,
Thanks so much for the deeper understanding. I think from here I'm
going to get a mirror port setup on the switch so I can confirm that
the switch is indeed sending that pdu on the restored link. I can then
take that to the switch vendor to address.
I love the idea of patching OVS to handle
Shu, thanks for all the debugging!
If this is a correct interpretation of the standard, and the peer switch
is misbehaving, and it's common behavior across a product line, then
possibly we'll need to make OVS cope with it.
Chad, do you have thoughts on Shu's discoveries?
Thanks,
Ben.
On Wed,
Hi Chad,
I now have a theory on what's happening in your case.
I realized that the first LACPDU packet the peer switch sent for
re-negotiation contains all zeros in Actor Informaiton TLV, line
81-84 from your gist:
20:38:17.109650 00:00:00:00:00:00 > 01:80:c2:00:00:02, ethertype Slow
Given that the partner port_id on the rogue packet matches the slave
it's sent out. I lean towards #1, that the LACP implementation is
somehow mixing up the status for the slave's pdu, rather than leaking
eth1's pdu out the eth0 interface.
-Chad
___
