Hi Ali
The following three lines in the code ensure that the HP isn't
dropping the LLDP packets. So, it is not that issue.
# To insure that the LLDP src mac address is not a multicast
# address, since we have no control on choice of dpid
eth.src = '\x00' + struct.pack('!Q',dpid)[3:8]
1. Creates
1. Creates a lldp packet with the 6 least significant bytes of the dpid as a
tlv (see line 65 and 66 of discovery.py).
2. The received lldp packet's tlv field is then used to compute a chassis id
(line 276), this chassis id is only 6 bytes long
You are right. The problem is that you are unable
Yeah, we've run into this before. Basically, the HP drops invalid
MACs (which are just treat as a string of bits).
KK, could you push this to revival?
Hi all,
I noticed that the discovery module in the destiny branch does not
work with HP switches (at least). So attached is a patch that
Hi all, I noticed that the discovery module in the destiny branch does not work with HP switches (at least). So attached is a patch that resolves this situation. I am not entirely sure this is the appropriate way to solve the problem but it works for me.Hope it helps,
Ali Al-ShabibiDoctoral
Awesome, thanks for the patch Dave.
Hi all,
I ran into a bug in discovery when it receives an LLDP packet with a
vlan tag, the matcher takes into account the fact that it has the VLAN
tag but the actual discovery code does not and throws an assertion
error. This was happening in the .4 branch
Hi all,
Discovery seems to be sending out LLDP packets on the local OpenFlow
port. This seems a little odd to me as I would expect we're unlikely to
encounter any other switches on the local port.
I'm running the 0.40 pre/beta nox (I haven't yet merged in the latest
changes with 0.40
