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

Attachment: lldp_packet_in
Description: Binary data

_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Reply via email to