On Feb 26, 2014, at 12:18 PM, Naman Muley <naman.g.mu...@gmail.com> wrote:
> 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 ? Not in the OpenFlow specs since it's an extension. It's documented in the context of OVS. Mostly I think this is in the form of comments in the OVS code; I'm not sure if there's manual-type documentation of it somewhere. It'd be nice if POX parsed it all out for you, but it hasn't happened yet. > 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 ? The in_port field of an ofp_match, e.g., as part of a flow_mod or packet_out. In your case, judging by the log, this is likely to be the one set by the call to ofp_match.from_packet() on line 169 of l2_learning (in dart). Again, this seems a bit weird, since it's using the port number from the incoming packet (event.port). Maybe your switch can't match on the in_port or something? You could try removing the second parameter to from_packet() which will probably still work and will just wildcard the in_port. You also might try running a different forwarding component which works differently and what happens (e.g., l2_pairs). > 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
