I get the same exact error after doing a fresh build (and after
commenting out that line)
./nox_core -i ptcp:6633 discovery switch
NOX 0.9.1~full~beta (nox_core), compiled Jun 22 2011 21:50:51
Compiled with OpenFlow 0x01
00001|discovery|ERR:lldp chassis ID subtype is 4 not 'local', ignoring
Thanks,
Aaron
On Wed, Jun 22, 2011 at 9:39 PM, Aaron Rosen <aro...@clemson.edu> wrote:
> Hi Murphy,
>
> I did a branch checkout of what i had but I'm doing a completely clean
> one now. (I'll let you know those results shortly).
>
> Also there is a flowvisor in between. I've attached a packet in of
> this type. Wireshark is also claiming they are malformed.
>
> Thanks,
>
> Aaron
>
> On Wed, Jun 22, 2011 at 9:28 PM, Murphy McCauley <jam...@nau.edu> wrote:
>> Did you clone a totally clean branch?
>>
>> I don't immediately see a way that the current destiny code could generate
>> this. Maybe it's just relaying them? Or are you using FlowVisor? Can you
>> see these packets being sent TO the controller (wrapped in a packet_in)?
>>
>> Try commenting out the send_openflow_packet() around line 331 in discovery.py
>> and see if you still get them. And try running just pyswitch and discovery
>> or
>> something.
>>
>> (BTW, the chassis id subtype in the packet you sent is 4 -- MAC address.
>> This
>> is correct for the unpatched code, but not for the patched code.)
>>
>> -- Murphy
>>
>> On Wednesday, June 22, 2011 06:12:20 PM Aaron Rosen wrote:
>>> Hi Murphy,
>>>
>>> I pulled in all your changes on destiny and am having the same issue.
>>> In wireshark the chassis ID subtype is 1. I've attached a packet_out
>>> OFP+LLDP case it helps.
>>>
>>> Thanks for your help!
>>>
>>> Aaron
>>>
>>> On Wed, Jun 22, 2011 at 8:01 PM, Murphy McCauley <jam...@nau.edu> wrote:
>>> > I've just pushed a couple cleanups and fixes to destiny (including the
>>> > aforementioned patch). Why don't you pull destiny again and see what the
>>> > results are?
>>> >
>>> > If you continue getting the "lldp chassis ID subtype is 4 not 'local',
>>> > ignoring" message, it's time to fire up Wireshark with the OpenFlow
>>> > plugin and look at the packet_out messages from the controller to the
>>> > switches. Find the OFP+LLDP packets and look at the chassis ID subtype.
>>> >
>>> > -- Murphy
>>> >
>>> > On Wednesday, June 22, 2011 03:41:31 PM Aaron Rosen wrote:
>>> >> Also,
>>> >>
>>> >> I just checked out destiny to try it there and when I run my code I
>>> >> get the following error:
>>> >>
>>> >> 00003|pyrt|ERR:unable to invoke a Python event handler:
>>> >> Traceback (most recent call last):
>>> >> File "./nox/lib/util.py", line 136, in f
>>> >> ret = f.cb(event.datapath_id, attrs)
>>> >> File "./nox/netapps/discovery/discovery.py", line 155, in <lambda>
>>> >> self.register_for_datapath_join ( lambda dp,stats :
>>> >> discovery.dp_join(self, dp, stats) )
>>> >> File "./nox/netapps/discovery/discovery.py", line 184, in dp_join
>>> >> print self.adjacency_list
>>> >> TypeError: <lambda>() takes no arguments (2 given)
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >> {}
>>> >>
>>> >>
>>> >> Thanks again,
>>> >>
>>> >> Aaron
>>> >>
>>> >> On Wed, Jun 22, 2011 at 6:21 PM, Aaron Rosen <aro...@clemson.edu> wrote:
>>> >> > Hi Murphy,
>>> >> >
>>> >> > It looks like the patch git applied fine.
>>> >> >
>>> >> > Changing that line yields the following output:
>>> >> >
>>> >> > 00453|discovery|ERR:lldp chassis ID subtype is 4 not 'local', ignoring
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > Aaron
>>> >> >
>>> >> > On Wed, Jun 22, 2011 at 6:16 PM, Murphy McCauley <jam...@nau.edu>
>> wrote:
>>> >> >> Hm. Maybe this is bitrot. Please check that the first part of the
>>> >> >> patch got applied and wasn't rejected. Specifically, line 65ish
>>> >> >> should be:
>>> >> >>
>>> >> >> cid.fill(chassis_id.SUB_LOCAL, array.array('B', 'dpid:' +
>>> >> >> hex(long(dpid)) [2:-1]))
>>> >> >>
>>> >> >> If it is, try replacing the log message around line 268 with
>>> >> >> something slightly more useful:
>>> >> >> lg.error("lldp chassis ID subtype is " + str(lldph.tlvs[0].subtype)
>>> >> >> + " not 'local', ignoring")
>>> >> >>
>>> >> >> -- Murphy
>>> >> >>
>>> >> >> On Wednesday, June 22, 2011 03:03:15 PM Aaron Rosen wrote:
>>> >> >>> Hi Murphy,
>>> >> >>>
>>> >> >>> After applying the patch I'm getting the following messages from
>>> >> >>> nox:
>>> >> >>>
>>> >> >>>
>>> >> >>> 00396|discovery|ERR:lldp chassis ID subtype is not 'local', ignoring
>>> >> >>> 00397|discovery|ERR:lldp chassis ID subtype is not 'local', ignoring
>>> >> >>> 00398|discovery|ERR:lldp chassis ID subtype is not 'local', ignoring
>>> >> >>>
>>> >> >>>
>>> >> >>> Thanks,
>>> >> >>>
>>> >> >>> Aaron
>>> >> >>>
>>> >> >>> On Wed, Jun 22, 2011 at 5:54 PM, Aaron Rosen <aro...@clemson.edu>
>> wrote:
>>> >> >>> > Hi Murphy you are right, I was mistaken on the dpid.
>>> >> >>> >
>>> >> >>> > I've applied this patch and still seeing the same results. (I am
>>> >> >>> > using zaku perhaps i should switch to destiny and try?).
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > checking 492581376499901568 inport 41
>>> >> >>> > False
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > Any ideas?
>>> >> >>> >
>>> >> >>> > Thanks,
>>> >> >>> >
>>> >> >>> > Aaron
>>> >> >>> >
>>> >> >>> > On Wed, Jun 22, 2011 at 5:42 PM, Murphy McCauley <jam...@nau.edu>
>>> >
>>> > wrote:
>>> >> >>> >> You say your DPID is actually 00:26:f1:3f:e4:80, but... I am
>>> >> >>> >> guessing (and hoping) that you're wrong. I am guessing it's
>>> >> >>> >> actually 06:d6:00:26:f1:3f:e4:80 (which is 492581376499901568,
>>> >> >>> >> BTW).
>>> >> >>> >>
>>> >> >>> >> So I think you're hitting a longstanding bug in discovery where
>>> >> >>> >> it doesn't work right with DPIDs over 48 bits. This following
>>> >> >>> >> message contains a patch addressing that, and I think it is a
>>> >> >>> >> prerequisite for you getting this working:
>>> >> >>> >> http://noxrepo.org/pipermail/nox-dev/2010-November/006705.html
>>> >> >>> >>
>>> >> >>> >> -- Murphy
>>> >> >>> >>
>>> >> >>> >> On Wednesday, June 22, 2011 02:18:17 PM Aaron Rosen wrote:
>>> >> >>> >>> Hi Murphy,
>>> >> >>> >>>
>>> >> >>> >>> I managed to get it running but I can't seem to get it working
>>> >> >>> >>> correctly: In discovery.py I've uncommented line 334 to print
>>> >> >>> >>> the following:
>>> >> >>> >>>
>>> >> >>> >>> print 'Sending packet out of ',longlong_to_octstr(dp), ' port
>>> >> >>> >>> ',str(port)
>>> >> >>> >>>
>>> >> >>> >>> From that I see:
>>> >> >>> >>>
>>> >> >>> >>> Sending packet out of 06:d6:00:26:f1:3f:e4:80 port 41
>>> >> >>> >>> Sending packet out of 06:d6:00:26:f1:3f:e4:80 port 36
>>> >> >>> >>> Sending packet out of 06:d6:00:26:f1:3f:e4:80 port 39
>>> >> >>> >>>
>>> >> >>> >>> Port 41 is the port that connects to another OF switch
>>> >> >>> >>> Also the DPID of my switch is really (00:26:F1:3F:E4:80), I'm
>>> >> >>> >>> guessing the it's padding with 06:d6?
>>> >> >>> >>>
>>> >> >>> >>> Though if I print the dpid value in create_discovery_packet()
>>> >> >>> >>> it's 06:d6:00:26:f1:3f:e4:80.
>>> >> >>> >>>
>>> >> >>> >>> Anyways: port 41 connects into an OF switch that has a dpid of:
>>> >> >>> >>> 0e:83:00:24:a8:d2:b8:40 So I expect to see packet in events
>>> >> >>> >>> here with my LLDP packet from port 41.
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>> >>> Using a modified packet print I print out the packets and the
>>> >> >>> >>> DPID they came in on. From that i see the following packet from
>>> >> >>> >>> dpid: 0e:83:00:24:a8:d2:b8:40
>>> >> >>> >>>
>>> >> >>> >>> [00:26:f1:3f:e4:80>01:23:20:00:00:01:LLDP]<chassis
>>> >> >>> >>> ID:00:26:f1:3f:e4:80><port ID:00:29><ttl:120><tlv end>
>>> >> >>> >>>
>>> >> >>> >>> This seems like everything is working perfectly here because
>>> >> >>> >>> this switch is the one that connects:
>>> >> >>> >>>
>>> >> >>> >>> 00:26:f1:3f:e4:80 <--> 0e:83:00:24:a8:d2:b8:40 and port id =
>>> >> >>> >>> 41 which is correct.
>>> >> >>> >>>
>>> >> >>> >>> Though when I the following code in my controller gets run it
>>> >> >>> >>> returns false, but It should return true since port 41 connects
>>> >> >>> >>> to another switch. (and this switch returned an LLDP that I
>>> >> >>> >>> sent as a packet in event)
>>> >> >>> >>>
>>> >> >>> >>> TRUNK_PORT = inst.discovery.is_switch_only_port(dpid, inport)
>>> >> >>> >>> if str(dpid) == "492581376499901568": # this is
>>> >> >>> >>> 00:26:f1:3f:e4:80 print "checking " + str(dpid) + " inport " +
>>> >> >>> >>> str(inport)
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>> >>> checking 492581376499901568 inport 41
>>> >> >>> >>> False
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>> >>> Any ideas whats going wrong here?
>>> >> >>> >>>
>>> >> >>> >>> Thanks,
>>> >> >>> >>>
>>> >> >>> >>> Aaron
>>> >> >>> >>>
>>> >> >>> >>> On Wed, Jun 22, 2011 at 1:44 PM, Murphy McCauley
>>> >> >>> >>> <jam...@nau.edu>
>>> >
>>> > wrote:
>>> >> >>> >>> > Try putting discovery before mymodule on the commandline (or,
>>> >> >>> >>> > better, making mymodule depend on discovery in its meta.json).
>>> >> >>> >>> >
>>> >> >>> >>> > -- Murphy
>>> >> >>> >>> >
>>> >> >>> >>> > On Tuesday, June 21, 2011 01:52:18 PM Aaron Rosen wrote:
>>> >> >>> >>> >> Or maybe doing
>>> >> >>> >>> >>
>>> >> >>> >>> >> from nox.netapps.discovery import discovery
>>> >> >>> >>> >> if(self.resolve(discovery).is_switch_only_port(self, dpid,
>>> >> >>> >>> >> port) ?
>>> >> >>> >>> >>
>>> >> >>> >>> >> Though if I import discovery in this manner I end up with the
>>> >> >>> >>> >> following error after nox starts:
>>> >> >>> >>> >>
>>> >> >>> >>> >> Current state: ERROR
>>> >> >>> >>> >> Required state: INSTALLED
>>> >> >>> >>> >> Dependencies: 'python' OK, 'python' OK
>>> >> >>> >>> >> Error:
>>> >> >>> >>> >> cannot import a Python module
>>> >> >>> >>> >> 'nox.coreapps.examples.sos': Traceback (most recent call
>>> >> >>> >>> >> last): File "./nox/coreapps/examples/sos.py", line 8, in
>>> >> >>> >>> >> <module> from nox.netapps.discovery import discovery File
>>> >> >>> >>> >> "./nox/netapps/discovery/discovery.py", line 24, in <module>
>>> >> >>> >>> >> from nox.netapps.discovery.pylinkevent import Link_event
>>> >> >>> >>> >> File
>>> >> >>> >>> >> "./nox/netapps/discovery/pylinkevent.py", line 25, in
>>> >> >>> >>> >> <module> _pylinkevent = swig_import_helper()
>>> >> >>> >>> >> File
>>> >> >>> >>> >> "./nox/netapps/discovery/pylinkevent.py", line 21, in
>>> >> >>> >>> >> swig_import_helper
>>> >> >>> >>> >> _mod = imp.load_module('_pylinkevent', fp,
>>> >> >>> >>> >> pathname, description) ImportError:
>>> >> >>> >>> >> ./nox/netapps/discovery/_pylinkevent.so: undefined symbol:
>>> >> >>> >>> >> vigil::Link_event::Link_event(vigil::datapathid,
>>> >> >>> >>> >> vigil::datapathid, unsigned short, unsigned short,
>>> >> >>> >>> >> vigil::Link_event::Action)
>>> >> >>> >>> >>
>>> >> >>> >>> >> On Tue, Jun 21, 2011 at 4:22 PM, Aaron Rosen
>>> >> >>> >>> >> <aro...@clemson.edu>
>>> >> >>
>>> >> >> wrote:
>>> >> >>> >>> >> > Hello,
>>> >> >>> >>> >> >
>>> >> >>> >>> >> > I would like to use: ./nox/netapps/discovery/discovery.py
>>> >> >>> >>> >> > to find interconnected links.
>>> >> >>> >>> >> >
>>> >> >>> >>> >> > I'm running nox in the following way ./nox_core -v -i
>>> >> >>> >>> >> > ptcp:6644 mymodule discovery
>>> >> >>> >>> >> >
>>> >> >>> >>> >> > When doing this I see discovery messages getting printed
>>> >> >>> >>> >> > out. Now In mymodule I believe I should be calling:
>>> >> >>> >>> >> > is_switch_only_port(self, dpid, port)? How can I call this
>>> >> >>> >>> >> > from mymodule?
>>> >> >>> >>> >> >
>>> >> >>> >>> >> > Thanks,
>>> >> >>> >>> >> >
>>> >> >>> >>> >> > Aaron
>>> >> >>> >>> >> >
>>> >> >>> >>> >> >
>>> >> >>> >>> >> >
>>> >> >>> >>> >> > --
>>> >> >>> >>> >> > Aaron O. Rosen
>>> >> >>> >>> >> > Masters Student - Network Communication
>>> >> >>> >>> >> > 306B Fluor Daniel
>>> >> >>> >
>>> >> >>> > --
>>> >> >>> > Aaron O. Rosen
>>> >> >>> > Masters Student - Network Communication
>>> >> >>> > 306B Fluor Daniel
>>> >> >
>>> >> > --
>>> >> > Aaron O. Rosen
>>> >> > Masters Student - Network Communication
>>> >> > 306B Fluor Daniel
>>
>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
>
--
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
