Re: [nox-dev] discovery
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 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 to associate
multiple Openflow instances on the same HP switch with the same
controller because the TLV contains only the least significant 48
bits. I thought this was solved with NOX-destiny branch which has
support for 64 bit dpid. I'll let the NOX team put in the patch.
Also, I noticed that the switchstats.py in the switchstats component has the
following call:
self.ctxt.send_port_stats_request(dp)
Shouldn't this call be:
self.ctxt.send_port_stats_request(dp, openflow.OFPP_NONE)
I believe the default value of OFPP_NONE for the second argument is
set elsewhere.
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] discovery
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 to associate multiple Openflow instances on the same HP switch with the same controller because the TLV contains only the least significant 48 bits. I thought this was solved with NOX-destiny branch which has support for 64 bit dpid. I'll let the NOX team put in the patch. I actually believe it doesn't work even if the connections are on the distinct HP switches. Because the keys in self.dps are 8 bytes long and the chassisid is 6 bytes long (and ignores the first 2 bytes of the dpid). So unless the first 2 bytes of the dpid is all zero, this will never work. Moreover, the first 2 bytes cannot be zero as they represent the openflow instance vlan id which cannot be 0 (at least on HP switches). Please correct me, if I am wrong. Also, I noticed that the switchstats.py in the switchstats component has the following call: self.ctxt.send_port_stats_request(dp) Shouldn't this call be: self.ctxt.send_port_stats_request(dp, openflow.OFPP_NONE) I believe the default value of OFPP_NONE for the second argument is set elsewhere. When I run the switchstats module, I get this error: 12:30:48 a...@pcepatr39[src]$ ./nox_core -i ptcp:2525 switchstats NOX 0.8.0~full~beta (nox_core), compiled Sep 2 2010 16:32:28 Compiled with OpenFlow 0x01 1|reactor|ERR:Unhandled Error Traceback (most recent call last): --- exception caught here --- File ./nox/coreapps/pyrt/pyoxidereactor.py, line 86, in __call__ self.func(*self.args, **self.kw); File ./nox/netapps/switchstats/switchstats.py, line 123, in lambda lambda : self.port_timer(dp)) File ./nox/netapps/switchstats/switchstats.py, line 88, in port_timer self.ctxt.send_port_stats_request(dp) File ./nox/coreapps/pyrt/pycomponent.py, line 476, in send_port_stats_request def send_port_stats_request(*args): return _pycomponent.PyContext_send_port_stats_request(*args) exceptions.TypeError: PyContext_send_port_stats_request() takes exactly 3 arguments (2 given) It is fixed by adding the OFPP_NONE Thanks! -- Ali Al-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch Tel : +41 22 767 86 46 Mob : +41 78 609 04 84 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] discovery
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 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-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch mailto:ali.al-shab...@cern.ch Tel : +41 22 767 86 46 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] discovery
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 StudentPH-ATDCERN - European Organization for Nuclear ResearchOffice: 513 R-018ali.al-shab...@cern.chTel : +41 22 767 86 46 discovery.patch Description: Binary data ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Discovery Assertion Error Patch
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 we have, but I checked and the code has not changed other than a delay value for .5, so it still seems vulnerable to the same problem. There also is a second assertion check after calling packet.next to verify the object is actually LLDP, negating the need for the first assertion. diff --git a/src/nox/netapps/discovery/discovery.py b/src/nox/netapps/discovery/discovery.py index 3ad0a7c..0a2de37 100644 --- a/src/nox/netapps/discovery/discovery.py +++ b/src/nox/netapps/discovery/discovery.py @@ -227,8 +227,9 @@ class discovery(Component): def lldp_input_handler(self, dp_id, inport, ofp_reason, total_frame_len, buffer_id, packet): -assert (packet.type == ethernet.LLDP_TYPE) - +if (packet.type == ethernet.VLAN_TYPE): +packet = packet.next + if not packet.next: lg.error(lldp_input_handler lldp packet could not be parsed) return Thanks, David ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org -- Martin Casado CTO, Nicira Networks 650-776-1457 (m) ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Discovery sends packets out the local OpenFlow port
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 release). I should also mention that the switch I've connected to has no physical ports in case that would make any difference. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
