Hi Murphy, Thanks for the quick reply, which seemed to skip my attention for the last two days. I've replied inline..
On Tue, Feb 25, 2014 at 3:46 AM, Murphy McCauley <murphy.mccau...@gmail.com>wrote: > > On Feb 24, 2014, at 10:08 PM, Naman Muley <naman.g.mu...@gmail.com> wrote: > > Hello, > > I was working with pox and a vendor open-flow switch (hardware). When I > connect my configured switch to the pox controller, I get the following > error message > > I did some looking around and found that type 4520, code 0 is not standard > openflow but a ovs extension. but this is not possible in my case as my > vendor is no where related to nicira / ovs / vmware. > > > Are you sure? I believe a number of hardware vendors have based their > implementations on OVS. Or is it possible that the switch that's > connecting isn't the one that you think it is (e.g., it's a random OVS > instance somewhere)? You could try running info.switch_info and see what > it says. > > hmm.. I wouldn't know if they are using OVS internally. I'd have to talk to their support guys. A random instanace of OVS somewhere wouldn't connect to exactly 192.168.2.1 for the controller. I doubt it but I'll still check for any leftover ovs instances somewhere. > Even if it's not actually a Nicira switch, it still could use the Nicira > extension in order to report extended error information. > > BUT... this certainly looks like an OVS switch. Examining the error > hexdump you can see that the first byte is a 0, and the next bytes are > 00-23-20. Following the extended error format, the 0 means the next three > bytes should be an OUI, and... 00-23-20 is Nicira's OUI. > > whoa I didn't know this. Can you point me to somewhere I can read up on this ? is this mentioned in the Openflow specs ? > The next four bytes are two 16 bit fields: the "inner" type and code. > Again, is this given in the openflow specs? or this is something that I should read up on the switch specs ? > In this case, it's 1,514. OVS's ofp-errors.h has this to say: > /* NX1.0(1,514), NX1.1(1,514), OF1.2+(1,11). Invalid port. > * [ A non-standard error (1,514), formerly > * OFPERR_NXBRC_BAD_IN_PORT is used for OpenFlow 1.0 and 1.1 as there > * seems to be no appropriste error code defined the specifications. > ] */ > OFPERR_OFPBRC_BAD_PORT, > > This seems to indicate that an in_port is set to something the switch > doesn't like. > ^ I didn't quite understand the above sentence. *set to something* ? am I missing something here ? > This seems a bit strange, since I think l2_learning always uses one from > a packet_in, so you'd think it would be valid. > Looking further at the data, we can see it's an OpenFlow 1.0 message > (0x01), type 0x0e (which I think is a flow_mod). Unfortunately, it's > truncated in the error message. If we had the OpenFlow traffic we could > find the original message which caused the error via its XID (9) and take a > look. > > I can send the whole pox.log file if anyone wants. > > > The control (OpenFlow) traffic is probably more immediately useful. > > here are the components on pox I was running - > $./pox.py openflow.of_01 --port=6633 --address=192.168.2.1 log > --file=pox.log,w log.level --DEBUG forwarding.l2_learning > > > With no modifications? > > with no modifications. > I saw the same error message on dart as well as betta forks. > > I have attached the detailed pox.log file. > > I am afraid I don't have the capture as yet. But I am working on getting a > capture of the traffic. > > > A simulated capture of the control traffic can be gathered with the > openflow.debug component. > > i'll get you that. > I was wondering if someone could shed more light on what could be causing > this ? a version mismatch or is there something wrong with the vendor > implementation of the openflow ? > > -------- ERROR message : --------------------------------- > > DEBUG:core:POX 0.3.0 (dart) going up... > DEBUG:core:Running on CPython (2.7.3/Sep 26 2013 20:03:06) > DEBUG:core:Platform is > Linux-3.2.0-29-generic-x86_64-with-Ubuntu-12.04-precise > INFO:core:POX 0.3.0 (dart) is up. > DEBUG:openflow.of_01:Listening on 192.168.2.1:6633 > INFO:openflow.of_01:[xx-xx-xx-xx-xx-xx 1] connected > DEBUG:forwarding.l2_learning:Connection [xx-xx-xx-xx-xx-xx 1] > DEBUG:forwarding.l2_learning:Port for 00:e0:2b:00:00:00 unknown -- flooding > DEBUG:forwarding.l2_learning:Port for 00:e0:2b:00:00:00 unknown -- flooding > DEBUG:forwarding.l2_learning:installing flow for 00:16:41:ef:46:47.11 -> > 00:16:41:ef:5f:70.15 > ERROR:openflow.of_01:[xx-xx-xx-xx-xx-xx 1] OpenFlow Error: > [xx-xx-xx-xx-xx-xx 1] Error: header: > [xx-xx-xx-xx-xx-xx 1] Error: version: 1 > [xx-xx-xx-xx-xx-xx 1] Error: type: 1 (OFPT_ERROR) > [xx-xx-xx-xx-xx-xx 1] Error: length: 84 > [xx-xx-xx-xx-xx-xx 1] Error: xid: 9 > [xx-xx-xx-xx-xx-xx 1] Error: type: 45250 > [xx-xx-xx-xx-xx-xx 1] Error: code: 0 > [xx-xx-xx-xx-xx-xx 1] Error: datalen: 72 > [xx-xx-xx-xx-xx-xx 1] Error: 0000: 00 00 23 20 00 01 02 02 01 0e 00 50 00 > 00 00 09 |..# .......P....| > [xx-xx-xx-xx-xx-xx 1] Error: 0010: 00 00 00 00 00 0b 00 16 41 ef 46 47 00 > 16 41 ef |........A.FG..A.| > [xx-xx-xx-xx-xx-xx 1] Error: 0020: 5f 70 ff ff 00 00 08 06 00 02 00 00 0a > 0a 01 0a |_p..............| > [xx-xx-xx-xx-xx-xx 1] Error: 0030: 0a 0a 01 0c 00 00 00 00 00 00 00 00 00 > 00 00 00 |................| > [xx-xx-xx-xx-xx-xx 1] Error: 0040: 00 00 00 0a 00 1e 80 00 > |........ | > > -------------- ERROR message -------------------------------------- > > Naman > <pox.log> > > > Naman
