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
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
