Re: [nox-dev] End-to.End delay measurement
On Tue, May 31, 2011 at 9:18 AM, andrea simeoni wrote: > My question is: > > Does OpenFlow provide a mechanism to label notification packets with a > timestamp at the switch? In such a way i could get a more and more precise > measure of the > end-to-end delay. (I don't need to estimate the switch-controller delay, but > simply look at the two timestamps provided in event notifications). You're asking if there is a way to timestamp which of the following: 1) when the packet arrives at the switch's fast path? 2) when the packet is transferred from fast to slow path? 3) when the packet is pushed onto the control channel path? I guess the short answer is it doesn't really matter, because there isn't hardware support for any of these timestamps. That said, you might be able to do some tricks to estimate each of these points, but it really starts to get into the switch internals and seems difficult. In theory you could use the IP time stamp options, but my guess is that most _switches_ would not support it. Good luck, - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Getting multiple ports stats in a single request
Hi Hamid, At the openflow protocol level, you can ask for stats for the OFPP_ALL port, which will give you stats back on all of the ports. It's not possible to supply an arbitrary list: it's either a single specific port or ALL. - Rob . On Thu, Apr 14, 2011 at 1:15 AM, Hamid Bazzaz wrote: > Hi folks, > > I would like to write a function in my NOX application to get the stats from > a set of ports of a certain switch. I found a function called > "send_port_stats_request" in coreapps/pyrt/pycontext.cc which requests for > stats from a _single_ port. But given that a Port_stats_in_event contains a > vector of ports I am sure there should be a way to request for stats of > multiple ports through a single request. I am wondering what is the way to > do so. Is there any sample code for requesting and receiving ports stats > that I could use besides pycontext.cc? > > Thanks, > --Hamid > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] [openflow-discuss] OF - Nox keep alives issues
[keeping cross posting b/c it re-enforces my concerns about artificially dividing our mailing lists] Hi Yiannis, First, I would look at wireshark to figure out the exact sequence of messages. But second, nox sends a ofp_vendor message and gives the disconnect message similar to what you're seeing if it does not get a reply (either the right ofp_vendor reply or an ofp_error with unsupported). Did you somehow break this sequence? - Rob . On Mon, Feb 14, 2011 at 7:16 PM, Yiannis Yiakoumis wrote: > Hi, > Sorry for the cross-posting, not sure what's the most appropriate list. > i use OpenFlow 1.0 (reference impl) and nox-zaku. By default, both > ofprotocol and nox will start with a keep-alive of 15 secs. After a few > minutes of inactivity, the switch side disconnects, sending a tcp request > and complaining as follows : > Feb 15 02:02:04 172.24.74.231 sysinit: Feb 15 > 02:02:04|02563|rconn|ERR|tcp:openflow3.stanford.edu:6633: no response to > inactivity probe after 15 seconds, disconnecting > I changed nox keep-alive to 10 secs and ofprotocol to 20. I don't see any > resets at that point, but I am still confused with the switch sending > ECHO_REQUESTs. I was expecting that since it receives requests from nox, it > will consider the connection ACTIVE, thus not sending any keep-alives on its > own. Instead it keeps sending "echo requests" every 20 secs. What's the > intended behavior of rconn/vconn here? I suspect that this is related with > the periodic disconnects I mentioned earlier. > Note that this happens only when there is no traffic in the channel (aka no > LLDP or any other packets). > Srini, is this related with what we've seen with the > circuit-aggregation/flowvisor setup? > Thanks, > Yiannis > ___ > openflow-discuss mailing list > openflow-disc...@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Handling corrupted TCP header
Fwiw, I agree with what both Masa and KK. Masa's point: OFPP_TABLE shouldn't be a special case: i.e., it should be able to generate packet_in's on the second pss KK's point: this should be more explicitly called out in the spec. I think if you were to suggest a specific wording in the next week, this could still make it into the 1.1 spec. - Rob . On Thu, Jan 13, 2011 at 7:06 PM, Masayoshi Kobayashi wrote: > KK, > > I think the implementer will read the spec the other way around. > Spec requires nothing special about OFPP_TABLE action (it does not say > "don't generate pkt_in, if there is no match"). So the switch > just follows the default behavior, i.e., pkt_in will be generated. > > I would expect the reference design also does the same. > > Masa > > On 01/13/2011 06:38 PM, kk yap wrote: >>> >>> Because the action of pkt_out is "OFPP_TABLE". >>> (the packet in pkt_out does not match to the entry that is installed by >>> flow_mod, since the matching entry says nw_proto=0). >> >> Is there anything in the spec that says that the switch should send >> another packet-in if there is no matching entry for a OFPP_TABLE? I >> am failing to find that. Can someone point to why this behavior is >> specified by the spec? >> >> Regards >> KK >> >> On 13 January 2011 18:28, Masayoshi Kobayashi >> wrote: >>> >>> KK, >>> I thought about it a little. Why is the switch doing step 7? >>> >>> Because the action of pkt_out is "OFPP_TABLE". >>> (the packet in pkt_out does not match to the entry that is installed by >>> flow_mod, since the matching entry says nw_proto=0). >>> >>> Masa >>> >>> On 01/13/2011 06:06 PM, kk yap wrote: Hi Srini, I thought about it a little. Why is the switch doing step 7? Anyway, I do agree that NOX is not handling malformed packets right. I have included an invalid field in the struct flow, and created a component that ignore invalid packets. If anyone will double-check and test the patches attached, I will push it. Regards KK On 13 January 2011 16:13, Srini Seetharaman wrote: > > I explained this to KK in person. For others, here is the sequence of > events: > > 1. Packet arrives with (nw_proto=6, tp_src=0, tp_dst=0). Store in bufid > 'X' > 2. flow.cc identifies that the arrived TCP packet is corrupted, and > generates > pkt_in event with flow structure having (nw_proto=0, tp_src=0, > tp_dst=0) > 3. Authenticator generates a flow_in with flow_in.flow being same as > above > 3. routing.cc generates a flow_mod for the flow_in with the match > pattern > defined using the fields of the flow_in.flow > 4. Switch inserts a flow table entry for matching (nw_proto=0, > tp_src=0, tp_dst=0) > 5. routing.cc generates a pkt_out for the bufid 'X' with action = > OFPP_TABLE > 6. Switch notices that the packet in bufid 'X' has no matching flow > table > entry, > because there is a mismatch on the nw_proto field > 7. Switch generates a new pkt_in event > 8. Go to step (2) > > This is the infinite loop. > > Srini. > > On Thu, Jan 13, 2011 at 1:08 PM, kk yap wrote: >> >> Hi Srini, >> >> I think you are fixing this in the wrong place. Putting nw_proto=0 >> does not cause an infinite loop. Where is the loop happening? Can >> you provide more detailed NOX output so that we can even start looking >> at this. >> >> Regards >> KK >> >> On 13 January 2011 11:02, Srini Seetharaman >> wrote: >>> >>> We don't know who sent it, but it came from outside our network. If >>> it >>> is easy to take down a network by just sending 1 invalid packet, I'd >>> be worried! >>> >>> On Thu, Jan 13, 2011 at 10:59 AM, kk yap >>> wrote: Hi Srini, What is this packet? The length of TCP is zero?!?! I wish to understand the circumstance for which we are getting the packet before commenting on the right way to handle this. Regards KK On 13 January 2011 10:38, Srini Seetharaman wrote: > > When someone sends the attached packet to a switch, it generates an > infinite loop of packet_ins in our production network. This is > because > this incoming tcp packet has nw_proto=6 and tcp port numbers of > "0", > but outgoing flow_mod has nw_proto of "0" and tcp port numbers of > "0". > So, the packet_out generates a new packet_in and this loop > continues > forever. > > I see the following code in src/lib/flow.cc (both in NOX-Zaku and > SNAC). I believe this is what is causing the nw_proto to be "0" in > the > flow_mod. I'm not sure who wrote that piece of code. This is not > handl
Re: [nox-dev] Associate xid with a flow mod event
I'm not sure if this is what you're asking, but flow_mod's have a 'cookie' associated with them that gets returned in all sorts of flow_mod related messages, e.g., flow_removed messages. Maybe that is what you're looking for. - Rob . On Wed, Dec 15, 2010 at 10:04 PM, Derek Cormier wrote: > Hello, > > When you receive a flow mod event, is there any way to associate it with the > xid of the original request that caused it? I'm looking for a way to confirm > that a specific request generated a specific response. For example, if > multiple components are running and they both send a packet to add the same > flow (with the no overlapping flows flag on), then one will get an error and > the other will not. I suppose you could check the xid of the errors to > determine who's was successful, but that seems a bit hackish. > > Thanks! > Derek > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] [openflow-discuss] NOX performance improvement by a factor 10
On Tue, Dec 14, 2010 at 9:34 PM, Martin Casado wrote: > This is awesome Amin, thanks for posting. It is also probably worth > mentioning that cbench was broken and over-reporting numbers. Do you mind > sending out a few details about that? I presume that will be helpful to > those using cbench A problem with cbench might even be of interest to those who wrote it :-) If I could bother you to just send me a diff of what you've changed, it would be much appreciated. I can push it back into the main branch. Fwiw, cbench is something I wrote very quickly while jetlagged, so it's not surprising that there are bugs in it. I didn't realize that people were actually using it, or I would try to snag some time to make it less crappy :-) Thanks for the feedback, - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] order of processing packets
[maybe less of a nox question and more of an openflow question, but...] The switch opens a raw socket to listen on each interface, so it's effectively a read-only copy like tcpdump uses (exactly like tcpdump), so it doesn't interfere with any other processing that happens. You could imagine the switch doing something more exotic (e.g., hooking into the stack deeper with netfilter -- www.netfilter.org), but I think the common case is to use the switch on interfaces that do not have daemons running on them. What is the high level goal that you have here? I mean you could always block the response with iptables, but that begs the question of why not just turn the service off in the first place? - Rob . On Sun, Nov 21, 2010 at 10:39 AM, Aaron Rosen wrote: > Hello, > > I have a question about what happens when you are sending packets to a host > that is also running the openflow switch. For example, I'm running openflow > on a pc-engine with the following command. > > ofprotocol unix:/var/run/dp0 tcp:130.127.39.173:6639 --fail=closed & > ofdatapath punix:/var/run/dp0 -i eth0,wlan0 ptcp:6633 & > > This pc-engines ip address is 192.168.2.2. > > So, when this pc-engine receives a packet for 192.168.2.2 (under a special > condition) I want to change this packet and send it out to someone else by > modifiying the ip.dst (etc). Though it seems that when the pc-engine > receives this packet it will go a head and respond and then pass the packet > to openflow (which is running between eth0 + wlan0). Is this what is > expected? > > Thanks, > > Aaron > > > > > -- > Aaron O. Rosen > Masters Student - Network Communication > 306B Fluor Daniel > 843.425.9777 > > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] [PATCH] 64 bit DPID in discovery fix?
As a data point, the way I've (and Nick Bastin, who actually wrote the
code) solved this in the FlowVisor is the chassis ID is still the mac
subtype and uses the MAC of the outgoing interface, but we added a
description TLV that contains the 8 byte datatpath id.
The reason why we did this is that older NOX's still expect the
subtype of MAC, so this would be better backwards compatible. Not
sure if you care, but something to think about. FYI, the relevant
code is in discovery.py:
# parse out chassis id
if lldph.tlvs[0].subtype != chassis_id.SUB_MAC:
log.err("lldp chassis ID subtype is not MAC,
ignoring",system='discovery')
return
- Rob
.
On Mon, Nov 15, 2010 at 6:55 PM, James "Murphy" McCauley wrote:
> I know there's a longstanding issue with some switches that use more
> than 48 bits for their DPIDs. This problem stemming from the fact that
> discovery stuffs the DPID into a MAC subtype chassis ID TLV in the LLDP
> packet it sends out, which obviously only has 48 bits. Thus, when we
> get the LLDP packet back, the MAC/DPID in it doesn't match one of our
> DPIDs because the top bits have been stripped off.
>
> I notice that the chassis ID TLV also has a "local" subtype. According
> to 802.1AB-2005 (which isn't the current version), this is "an
> alpha-numeric string and is locally assigned". Can we just stuff the
> DPID in there as a string? Maybe prepend "dpid:" to weed out anything
> else that may use it and to look nice for other tools?
>
> I've attached a patch. Maybe someone would tell me what they think? I
> don't have any of the problematic switches to play with, though I did
> specify large dpids in OVS and had them work now.
>
> -- Murphy
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Modify ARP who-has Address
[going a bit astray from nox, but will keep the list in the CC just because I think it's still somewhat relevant] The problem is that, at least from what I've seen, most of the delay in "going to the controller" is actually internal to the switch in moving packets to and from the slowpath. So, if you're forcing the switch to emulate something it can't do in the fast path, e.g., rewriting the payload in an arp packet, you're already paying the majority of that cost. - Rob . On Fri, Nov 5, 2010 at 12:55 PM, wrote: > While that definitely works, using the packet_in/packet_out method means > every ARP message will need to be sent to the controller for processing, > so it will slow down the performance (if that is a critical factor). > > -Adam > >> In practice, what people do is not install flow_mod's for arps, but >> instead use packet_in/packet_out. That is, when you get a packet_in >> (new flow event in nox? I never remember the nox terms for things), >> you rewrite the packet directly and then write it back out as a >> packet_out as opposed to as a new flow. >> >> Fwiw, one reason why this isn't included in the OF spec is (I'm >> guessing) that no hardware manufacturer supports this in their chips >> at line rate. >> >> - Rob >> . >> >> >> >> On Fri, Nov 5, 2010 at 12:39 PM, wrote: >>> Hi Aaron, >>> >>> I am working on a similar idea for a project where I want to change the >>> contents of the ARP packet. OpenFlow only supports modifications that >>> change the packet headers and ARP fields are not one of them. What I am >>> doing, you might want to consider, is "extending" the OpenFlow protocol >>> so >>> that there is a new action that changes these packets. Next, you will >>> need >>> to change the switch implementation as well (I am using Open vSwitch) so >>> that it can make these modifications on all packets that match the flow >>> rule. >>> But other than that, I think you are out of luck. >>> >>> -Adam >>> Hello, I'm trying to modify the arp who-has address in order to trick a client into talking to a different gateway after he moves to a new subnet. Is this possible? I see how to modify the the L2 and L3 headers (using OFPAT_SET_*) but not the arp ones. (I don't see this functionality in src/nox/lib/packet/arp.py ? ) Thanks -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel 843.425.9777 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >>> >>> >>> ___ >>> nox-dev mailing list >>> nox-dev@noxrepo.org >>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >> > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Modify ARP who-has Address
In practice, what people do is not install flow_mod's for arps, but instead use packet_in/packet_out. That is, when you get a packet_in (new flow event in nox? I never remember the nox terms for things), you rewrite the packet directly and then write it back out as a packet_out as opposed to as a new flow. Fwiw, one reason why this isn't included in the OF spec is (I'm guessing) that no hardware manufacturer supports this in their chips at line rate. - Rob . On Fri, Nov 5, 2010 at 12:39 PM, wrote: > Hi Aaron, > > I am working on a similar idea for a project where I want to change the > contents of the ARP packet. OpenFlow only supports modifications that > change the packet headers and ARP fields are not one of them. What I am > doing, you might want to consider, is "extending" the OpenFlow protocol so > that there is a new action that changes these packets. Next, you will need > to change the switch implementation as well (I am using Open vSwitch) so > that it can make these modifications on all packets that match the flow > rule. > But other than that, I think you are out of luck. > > -Adam > >> Hello, >> >> I'm trying to modify the arp who-has address in order to trick a client >> into >> talking to a different gateway after he moves to a new subnet. Is this >> possible? I see how to modify the the L2 and L3 headers (using >> OFPAT_SET_*) >> but not the arp ones. >> >> (I don't see this functionality in src/nox/lib/packet/arp.py ? ) >> >> Thanks >> >> -- >> Aaron O. Rosen >> Masters Student - Network Communication >> 306B Fluor Daniel >> 843.425.9777 >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> > > > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Dpids disconnecting
FYI, this problem was tracked down to a config problem, not a flowvisor or nox bug ;-) - Rob . On Sat, Oct 16, 2010 at 1:51 AM, Niky Riga wrote: > Hi KK, > > Attached are nox's log files. > * pathlet.out : the log file when I run the pathlet controller on the slice > * pyswitch.out : the log file when I run the pyswitch module on the same > slice > > Thanks, > Niky > > > kk yap wrote: > >> Can someone send the pcap file on the list, so that people can >> actually start doing real investigation here? If it is too big, send >> to Nick Bastin? (Sorry, Nick...) >> >> I would still like to see the NOX's output. >> >> Regards >> KK >> >> On 15 October 2010 21:36, Rob Sherwood wrote: >> >> >>> Sorry... the "..." meant more packet_in's. >>> >>> - Rob >>> . >>> >>> >>> On Fri, Oct 15, 2010 at 9:15 PM, kk yap wrote: >>> >>> >>>> < ERROR (vendor unsupported) >>>> < PACKET_IN (lldp) >>>> >>>> and then disconnect >>>> >>>> Can I know the model of the switch, and what ... means? The front >>>> part looks correct at a glance. I am wondering why there is a LLDP >>>> without any packet out though. >>>> >>>> Regards >>>> KK >>>> >>>> PS>> Way to solve this: >>>> email >>>> more email >>>> >>>> solved >>>> >>>> :) >>>> >>>> On 15 October 2010 21:10, Rob Sherwood >>>> wrote: >>>> >>>> >>>>> KK: I've looked through the tcpdumps and the sequence is: >>>>> >>>>> >>>>>> HELLO >>>>>> >>>>>> >>>>> < HELLO >>>>> >>>>> >>>>>> FEATURE_REQUEST >>>>>> >>>>>> >>>>> < FEATURE_REPLY >>>>> >>>>> >>>>>> VENDOR MSG >>>>>> >>>>>> >>>>> < ERROR (vendor unsupported) >>>>> < PACKET_IN (lldp) >>>>> >>>>> and then disconnect >>>>> - Rob >>>>> . >>>>> >>>>> >>>>> On Fri, Oct 15, 2010 at 9:07 PM, kk yap wrote: >>>>> >>>>> >>>>>> What about having a tcpdump of the control traffic between NOX to/from >>>>>> FV, and FV to/from switch? Each disconnection will have a new >>>>>> connection following it, then you will see the hellos, feature >>>>>> requests and replies, etc. >>>>>> >>>>>> I would like to see the NOX's log too. NOX typically does not kill a >>>>>> connection silently. >>>>>> >>>>>> Just my knee-jerk reaction on how to debug this. >>>>>> >>>>>> Regards >>>>>> KK >>>>>> >>>>>> On 15 October 2010 20:23, Niky Riga wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have installed the latest FlowVisor 0.6 beta5, but we still see >>>>>>> the >>>>>>> dpids >>>>>>> flapping. >>>>>>> Rob believes that it's nox that initiates the disconnection so I >>>>>>> would >>>>>>> like >>>>>>> to try and debug this. >>>>>>> Is there a way to increase the debug level beyond debug?:-) Where >>>>>>> should >>>>>>> I >>>>>>> start looking >>>>>>> in the code to see why nox decides to tear down a connection? >>>>>>> >>>>>>> Thanks, >>>>>>> Niky >>>>>>> >>>>>>> ___ >>>>>>> nox-dev mailing list >>>>>>> nox-dev@noxrepo.org >>>>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>>>>>> >>>>>>> >>>>>>> >>>>>> ___ >>>>>> nox-dev mailing list >>>>>> nox-dev@noxrepo.org >>>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Problems about installing NOX 0.6.0
[pre-cursor to moving this conversation offlist] If you are interested in helping, we're on #gec9demos on EFNET (an IRC server) - Rob . On Sat, Oct 16, 2010 at 9:21 AM, Nicholas Bastin wrote: > On Fri, Oct 15, 2010 at 18:35, kk yap wrote: > >> >> Actually in this case, Chui-Hui will not be able to anything if we >> have went the tarball way. We are essentially not very customized to >> CentOS. Tarballs are also particularly hard to update. >> >> > > There doesn't have to be any difference between a source tarball and a git > clone, other than the fact that we at least all know what is in the tarball > - the unchanging nature of the tarball is what is appealing here, not a > downside. I would prefer that source tarballs at least didn't require > autoconf, but even that wouldn't be the end of the world in this case. > > I'm looking into getting it to build on CentOS 5.5, but unfortunately the > only way to get the DVD image is via torrent so my setup time is a bit > longer than I'd planned. > > ..insert obligatory gripe here about asking why distributions can't > just make iso's available on amazon s3 and pass the download cost on to me > in exchange for a download that actually works... > > -- > Nick > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Dpids disconnecting
I've put the pcapfile on yuba:~capveg/nineveh-fv.tcpdump (for those who have access... it's a 2MB file). It's a trace of both to the FV on nineveh:6633 (from the FV on openflow5) and to the controller on nineveh:1734. If you just filter on port 1734 you get just the controller traffic. - Rob . On Fri, Oct 15, 2010 at 9:44 PM, kk yap wrote: > Can someone send the pcap file on the list, so that people can > actually start doing real investigation here? If it is too big, send > to Nick Bastin? (Sorry, Nick...) > > I would still like to see the NOX's output. > > Regards > KK > > On 15 October 2010 21:36, Rob Sherwood wrote: > > Sorry... the "..." meant more packet_in's. > > > > - Rob > > . > > > > > > On Fri, Oct 15, 2010 at 9:15 PM, kk yap wrote: > >> > >> < ERROR (vendor unsupported) > >> < PACKET_IN (lldp) > >> > >> and then disconnect > >> > >> Can I know the model of the switch, and what ... means? The front > >> part looks correct at a glance. I am wondering why there is a LLDP > >> without any packet out though. > >> > >> Regards > >> KK > >> > >> PS>> Way to solve this: > >> email > >> more email > >> > >> solved > >> > >> :) > >> > >> On 15 October 2010 21:10, Rob Sherwood > wrote: > >> > KK: I've looked through the tcpdumps and the sequence is: > >> >> HELLO > >> > < HELLO > >> >> FEATURE_REQUEST > >> > < FEATURE_REPLY > >> >> VENDOR MSG > >> > < ERROR (vendor unsupported) > >> > < PACKET_IN (lldp) > >> > > >> > and then disconnect > >> > - Rob > >> > . > >> > > >> > > >> > On Fri, Oct 15, 2010 at 9:07 PM, kk yap wrote: > >> >> > >> >> What about having a tcpdump of the control traffic between NOX > to/from > >> >> FV, and FV to/from switch? Each disconnection will have a new > >> >> connection following it, then you will see the hellos, feature > >> >> requests and replies, etc. > >> >> > >> >> I would like to see the NOX's log too. NOX typically does not kill a > >> >> connection silently. > >> >> > >> >> Just my knee-jerk reaction on how to debug this. > >> >> > >> >> Regards > >> >> KK > >> >> > >> >> On 15 October 2010 20:23, Niky Riga wrote: > >> >> > Hi, > >> >> > > >> >> > We have installed the latest FlowVisor 0.6 beta5, but we still see > >> >> > the > >> >> > dpids > >> >> > flapping. > >> >> > Rob believes that it's nox that initiates the disconnection so I > >> >> > would > >> >> > like > >> >> > to try and debug this. > >> >> > Is there a way to increase the debug level beyond debug?:-) Where > >> >> > should > >> >> > I > >> >> > start looking > >> >> > in the code to see why nox decides to tear down a connection? > >> >> > > >> >> > Thanks, > >> >> > Niky > >> >> > > >> >> > ___ > >> >> > nox-dev mailing list > >> >> > nox-dev@noxrepo.org > >> >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >> >> > > >> >> > >> >> ___ > >> >> nox-dev mailing list > >> >> nox-dev@noxrepo.org > >> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >> > > >> > > > > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Dpids disconnecting
Sorry... the "..." meant more packet_in's. - Rob . On Fri, Oct 15, 2010 at 9:15 PM, kk yap wrote: > < ERROR (vendor unsupported) > < PACKET_IN (lldp) > > and then disconnect > > Can I know the model of the switch, and what ... means? The front > part looks correct at a glance. I am wondering why there is a LLDP > without any packet out though. > > Regards > KK > > PS>> Way to solve this: > email > more email > > solved > > :) > > On 15 October 2010 21:10, Rob Sherwood wrote: > > KK: I've looked through the tcpdumps and the sequence is: > >> HELLO > > < HELLO > >> FEATURE_REQUEST > > < FEATURE_REPLY > >> VENDOR MSG > > < ERROR (vendor unsupported) > > < PACKET_IN (lldp) > > > > and then disconnect > > - Rob > > . > > > > > > On Fri, Oct 15, 2010 at 9:07 PM, kk yap wrote: > >> > >> What about having a tcpdump of the control traffic between NOX to/from > >> FV, and FV to/from switch? Each disconnection will have a new > >> connection following it, then you will see the hellos, feature > >> requests and replies, etc. > >> > >> I would like to see the NOX's log too. NOX typically does not kill a > >> connection silently. > >> > >> Just my knee-jerk reaction on how to debug this. > >> > >> Regards > >> KK > >> > >> On 15 October 2010 20:23, Niky Riga wrote: > >> > Hi, > >> > > >> > We have installed the latest FlowVisor 0.6 beta5, but we still see the > >> > dpids > >> > flapping. > >> > Rob believes that it's nox that initiates the disconnection so I would > >> > like > >> > to try and debug this. > >> > Is there a way to increase the debug level beyond debug?:-) Where > should > >> > I > >> > start looking > >> > in the code to see why nox decides to tear down a connection? > >> > > >> > Thanks, > >> > Niky > >> > > >> > ___ > >> > nox-dev mailing list > >> > nox-dev@noxrepo.org > >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >> > > >> > >> ___ > >> nox-dev mailing list > >> nox-dev@noxrepo.org > >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Dpids disconnecting
Two of the switches are local to stanford and NECs: necsw2 (00:00:00:12:e2:78:31:f5) necsw(00:00:00:12:e2:78:67:65) necsw is the main connection point to the other flowvisors, so it would receive packet_in's from the other flowvisor. - Rob . On Fri, Oct 15, 2010 at 9:15 PM, kk yap wrote: > < ERROR (vendor unsupported) > < PACKET_IN (lldp) > > and then disconnect > > Can I know the model of the switch, and what ... means? The front > part looks correct at a glance. I am wondering why there is a LLDP > without any packet out though. > > Regards > KK > > PS>> Way to solve this: > email > more email > > solved > > :) > > On 15 October 2010 21:10, Rob Sherwood wrote: > > KK: I've looked through the tcpdumps and the sequence is: > >> HELLO > > < HELLO > >> FEATURE_REQUEST > > < FEATURE_REPLY > >> VENDOR MSG > > < ERROR (vendor unsupported) > > < PACKET_IN (lldp) > > > > and then disconnect > > - Rob > > . > > > > > > On Fri, Oct 15, 2010 at 9:07 PM, kk yap wrote: > >> > >> What about having a tcpdump of the control traffic between NOX to/from > >> FV, and FV to/from switch? Each disconnection will have a new > >> connection following it, then you will see the hellos, feature > >> requests and replies, etc. > >> > >> I would like to see the NOX's log too. NOX typically does not kill a > >> connection silently. > >> > >> Just my knee-jerk reaction on how to debug this. > >> > >> Regards > >> KK > >> > >> On 15 October 2010 20:23, Niky Riga wrote: > >> > Hi, > >> > > >> > We have installed the latest FlowVisor 0.6 beta5, but we still see the > >> > dpids > >> > flapping. > >> > Rob believes that it's nox that initiates the disconnection so I would > >> > like > >> > to try and debug this. > >> > Is there a way to increase the debug level beyond debug?:-) Where > should > >> > I > >> > start looking > >> > in the code to see why nox decides to tear down a connection? > >> > > >> > Thanks, > >> > Niky > >> > > >> > ___ > >> > nox-dev mailing list > >> > nox-dev@noxrepo.org > >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >> > > >> > >> ___ > >> nox-dev mailing list > >> nox-dev@noxrepo.org > >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Dpids disconnecting
KK: I've looked through the tcpdumps and the sequence is: > HELLO < HELLO > FEATURE_REQUEST < FEATURE_REPLY > VENDOR MSG < ERROR (vendor unsupported) < PACKET_IN (lldp) and then disconnect - Rob . On Fri, Oct 15, 2010 at 9:07 PM, kk yap wrote: > What about having a tcpdump of the control traffic between NOX to/from > FV, and FV to/from switch? Each disconnection will have a new > connection following it, then you will see the hellos, feature > requests and replies, etc. > > I would like to see the NOX's log too. NOX typically does not kill a > connection silently. > > Just my knee-jerk reaction on how to debug this. > > Regards > KK > > On 15 October 2010 20:23, Niky Riga wrote: > > Hi, > > > > We have installed the latest FlowVisor 0.6 beta5, but we still see the > dpids > > flapping. > > Rob believes that it's nox that initiates the disconnection so I would > like > > to try and debug this. > > Is there a way to increase the debug level beyond debug?:-) Where should > I > > start looking > > in the code to see why nox decides to tear down a connection? > > > > Thanks, > > Niky > > > > ___ > > nox-dev mailing list > > nox-dev@noxrepo.org > > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Dpids disconnecting
FYI, from the logs, nox is triggering the datapath_join() and then the datapath_leave(). - Rob . On Fri, Oct 15, 2010 at 8:23 PM, Niky Riga wrote: > Hi, > > We have installed the latest FlowVisor 0.6 beta5, but we still see the > dpids flapping. > Rob believes that it's nox that initiates the disconnection so I would like > to try and debug this. > Is there a way to increase the debug level beyond debug?:-) Where should I > start looking > in the code to see why nox decides to tear down a connection? > > Thanks, > Niky > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] [openflow-discuss] Problem with stat requests and reply
[dropped openflow-discuss from the CC line; it's mostly overlap in membership in any case] So, I'm confused. Your original mail said your errors from wireshark were for table stats messages, but you yourself are not using table stats? If the table stats messages are not coming from you, why are they in your trace? - Rob . On Thu, Oct 14, 2010 at 1:29 PM, Niky Riga wrote: > No, I am not using envi and actually I am not even using table stats, > this was just the standard monitor module of nox. > > I am seeing similar errors in my monitor module as well, which > i don't believe there were there before, and I am not doing table stats. > > --niky > > On 10/14/10 2:19 PM, Rob Sherwood wrote: >> >> Nicky: are you by chance using envi as well? >> >> There was a problem with table stats and envi, because envi was >> packing its own packets and was not updated properly for openflow 1.0. >> The result was that table stats messages were 2 (4? I forget) bytes >> shorter than they should be.If you're using envi, let me know and >> I can point you to the patch. >> >> If you're not using envi, it's entirely possible that this is the same >> bug in nox somewhere. >> >> Let us know, >> >> - Rob >> . >> >> >> >> On Thu, Oct 14, 2010 at 1:39 AM, Niky Riga wrote: >>> >>> Hi, >>> >>> I am using nox zaku and FV 0.4 beta4. I have been having problems with >>> a module that pokes periodically the switches for statistics. >>> >>> In an effort to debug this, I made a clean installation of nox (zaku >>> release) >>> and run the default monitoring module of nox. And the problems persisted. >>> >>> Basically I was seeing errors in the controller of the type : >>> >>> 8163|nox|DBG:Success receiving in 'receiving features reply' >>> 08164|nox|WARN:Received unsupported message type during handshake (17) >>> >>> I tried to run it with wireshark to be able to debug a little bit further >>> but by the >>> time I have set up my environment, the switches that were causing that >>> had >>> dropped of my FV. >>> >>> I was still seeing some errors from the remaining switches : >>> >>> 00112|openflow-event|ERR:received Openflow error packet from >>> dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data >>> 00146|openflow-event|ERR:received Openflow error packet from >>> dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data >>> 00151|openflow-event|ERR:received Openflow error packet from >>> dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data >>> >>> Running wireshark, the only thing I noticed was periodic messages of : >>> 04:14:14 Warn Dissector bug, protocol OFP, in packet 20286: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:14:14 Warn Dissector bug, protocol OFP, in packet 20345: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:14:15 Warn Dissector bug, protocol OFP, in packet 20461: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:14:15 Warn Dissector bug, protocol OFP, in packet 20475: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:14:16 Warn Dissector bug, protocol OFP, in packet 20608: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:14:16 Warn Dissector bug, protocol OFP, in packet 20627: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:14:16 Warn Dissector bug, protocol OFP, in packet 20639: >>> proto.c:1389: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> 04:15:23 Warn Dissector bug, protocol OFP, in packet 20639: >>> proto.c:2916: failed assertion "(guint)hfindex< gpa_hfinfo.len" >>> >>> Most of these, if not all, are in the stats reply for table stats. >>> >>> After a while more switches have dropped from the FV (there can be only >>> one:-)) ) >>> >>> Any ideas what might be wrong? >>> >>> Niky >>> >>> >>> >>> ___ >>> openflow-discuss mailing list >>> openflow-disc...@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] [openflow-discuss] Problem with stat requests and reply
Nicky: are you by chance using envi as well? There was a problem with table stats and envi, because envi was packing its own packets and was not updated properly for openflow 1.0. The result was that table stats messages were 2 (4? I forget) bytes shorter than they should be.If you're using envi, let me know and I can point you to the patch. If you're not using envi, it's entirely possible that this is the same bug in nox somewhere. Let us know, - Rob . On Thu, Oct 14, 2010 at 1:39 AM, Niky Riga wrote: > Hi, > > I am using nox zaku and FV 0.4 beta4. I have been having problems with > a module that pokes periodically the switches for statistics. > > In an effort to debug this, I made a clean installation of nox (zaku > release) > and run the default monitoring module of nox. And the problems persisted. > > Basically I was seeing errors in the controller of the type : > > 8163|nox|DBG:Success receiving in 'receiving features reply' > 08164|nox|WARN:Received unsupported message type during handshake (17) > > I tried to run it with wireshark to be able to debug a little bit further > but by the > time I have set up my environment, the switches that were causing that had > dropped of my FV. > > I was still seeing some errors from the remaining switches : > > 00112|openflow-event|ERR:received Openflow error packet from > dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data > 00146|openflow-event|ERR:received Openflow error packet from > dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data > 00151|openflow-event|ERR:received Openflow error packet from > dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data > > Running wireshark, the only thing I noticed was periodic messages of : > 04:14:14 Warn Dissector bug, protocol OFP, in packet 20286: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:14:14 Warn Dissector bug, protocol OFP, in packet 20345: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:14:15 Warn Dissector bug, protocol OFP, in packet 20461: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:14:15 Warn Dissector bug, protocol OFP, in packet 20475: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:14:16 Warn Dissector bug, protocol OFP, in packet 20608: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:14:16 Warn Dissector bug, protocol OFP, in packet 20627: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:14:16 Warn Dissector bug, protocol OFP, in packet 20639: > proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len" > 04:15:23 Warn Dissector bug, protocol OFP, in packet 20639: > proto.c:2916: failed assertion "(guint)hfindex < gpa_hfinfo.len" > > Most of these, if not all, are in the stats reply for table stats. > > After a while more switches have dropped from the FV (there can be only > one:-)) ) > > Any ideas what might be wrong? > > Niky > > > > ___ > openflow-discuss mailing list > openflow-disc...@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Installed flows deleted on datapath_join event?
My guess (yet to confirm) is that this is actually a flowvisor-related problem. When a controller first connects to a switch, it sends a "delete all flows" message, which the flowvisor translates into "delete all flows in the slice". This is somewhat error prone process, and I suspect the flowvisor is deleting flows that are outside of the controller's slice. Zdravko: any information you can provide about your flowvisor configuration would make it easier to help you debug your problem. - Rob . On Wed, Aug 11, 2010 at 11:57 AM, Martin Casado wrote: > I'm not sure I completely follow what is going on here, but Nox will delete > all flows of newly joined switches (see src/builtin/nox.cc > Handshake_fsm::register_switch() ). Perhaps that is contributing? >> >> Hi KK, >> thanks for the fast reply. Actually I'm trying to run the controllers >> independently of each other on different machines. The only shared component >> is the datapath, which also runs on a separate machine. My aim is to allow >> controllers to join/leave a specific datapath at any time and I want to make >> sure that they do not overwrite each other's entries (the "flowspaces" >> themselves do not overlap) when they are started, which is what currently >> happens. I hope this is somewhat clearer... >> >> Best regards, >> Zdravko >> >> >> On 08/11/2010 04:50 PM, kk yap wrote: >>> >>> Hi Zdravko, >>> >>> From what I understand, what you want is for the first component to >>> get the event and not the second component? If so, the first >>> component has to return STOP and not CONTINUE. Also check nox.xml to >>> make sure about the ordering of the components for each event. >>> >>> Regards >>> KK >>> >>> On 11 August 2010 06:14, Zdravko Bozakov wrote: Hello, I am trying to get two simple NOX (python) components running on different VMs to share a NetFPGA datapath using flowvisor. Generally, everything seems to be working fine, however I have the following problem: * When the first components starts, the datapath registers (datapath_join event) and its flows are installed. * When the second component starts and receives a datapath join event, all previously installed flows are removed from the datapath. Afterwards new flow entries are installed as expected. How can I avoid this behaviour, i.e. keep all flows installed? What am I missing? Thanks a lot in advance! Regards, Zdravko PS. I am using the current git source for all software packages ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Installed flows deleted on datapath_join event?
Hello. Question: how are you slicing the flowspace? Fwiw, if you are using ip addresses, apparently recently some bug has crept into the code[1] where the flowvisor deletes more than it should. I should be fixing the problem soon, but it would be ncie to know if this is a known or new issue. Thanks, - Rob . [1] It's in our bug trac DB as bug #162 (http://www.openflow.org/bugs/flowvisor/ticket/162) On Wed, Aug 11, 2010 at 8:49 AM, kk yap wrote: > Hi Zdravko, > > I think you might want to describe your setup a little more here. I > have cc-ed Rob that can give valuable inputs for the use of FlowVisor. > > Regards > KK > > On 11 August 2010 08:38, Zdravko Bozakov wrote: >> Yes, I'm using FlowVisor - however I do need write access. Each controller >> should connect to the datapath, install some flow entries, and after some >> time remove it's flows and disconnect. >> >> Thanks again, >> Zdravko >> >> On 08/11/2010 05:28 PM, kk yap wrote: >>> >>> Are you using the FlowVisor? If so, there is a read-only mode for >>> controllers. >>> >>> Regards >>> KK >>> >>> On 11 August 2010 08:26, Zdravko Bozakov wrote: Hi KK, thanks for the fast reply. Actually I'm trying to run the controllers independently of each other on different machines. The only shared component is the datapath, which also runs on a separate machine. My aim is to allow controllers to join/leave a specific datapath at any time and I want to make sure that they do not overwrite each other's entries (the "flowspaces" themselves do not overlap) when they are started, which is what currently happens. I hope this is somewhat clearer... Best regards, Zdravko On 08/11/2010 04:50 PM, kk yap wrote: > > Hi Zdravko, > > From what I understand, what you want is for the first component to > get the event and not the second component? If so, the first > component has to return STOP and not CONTINUE. Also check nox.xml to > make sure about the ordering of the components for each event. > > Regards > KK > > On 11 August 2010 06:14, Zdravko Bozakov wrote: >> >> Hello, >> >> I am trying to get two simple NOX (python) components running on >> different >> VMs to share a NetFPGA datapath using flowvisor. Generally, everything >> seems >> to be working fine, however I have the following problem: >> >> * When the first components starts, the datapath registers >> (datapath_join >> event) and its flows are installed. >> * When the second component starts and receives a datapath join event, >> all >> previously installed flows are removed from the datapath. Afterwards >> new >> flow entries are installed as expected. >> >> How can I avoid this behaviour, i.e. keep all flows installed? What am >> I >> missing? Thanks a lot in advance! >> >> Regards, >> Zdravko >> >> PS. I am using the current git source for all software packages >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> >> > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] malformed stats request in nox-0.4; maybe others
I'm working with a dreadfully old version of nox but just found a problem in how it makes aggregate stats requests. I'm posting it here in case anyone else is working with nox 0.4 with the of1.0 patch OR in case it still exists in more current versions. Srini, Masa: I found this bug because it really messed up framing with the flowvisor. Shot in the dark, but it might be the culprit that's also been causing CPU issues with our network. Short story: nox was sending a stats request that was well-formed in an openflow sense (the number of bytes sent is the same as the header.length) but the stats request was 4 bytes short: [from wireshark] 01 10 00 34 00 00 00 1a 00 02 00 00 00 0f ff ff 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 ff 00 00 03 This is a 52 byte packet, but a stats request is 12 bytes and an aggregate body is 44, so it should be a 56 byte packet. I'm not brave enough (or have enough free time) to delve into the actual cause... especially since it's such old code, but I thought I would mention it because I know a lot of others are using the same old code. Given that the embedded ofp_match grew by 4 bytes since 0.89, it seems likely some constant didn't get updated with the of1.0 patch. FYI, - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Issues with multiple OF instances on HP switch
[I was thinking someone closer to the deployments would answer this, but this question has been outstanding for a few days, so let me give it a try] \ Hi Tim, There was a previous bad interaction between the HP firmware and Nox. The crux of the problem was that HP firmware uses all 8 bytes of the datapath id and nox only considers 6 bytes, so Nox believed that two switches with the same DPID were connecting to it (because the DPIDs only differ in the two bytes that nox does not consider). The short story was there was a verison of the HP firmware that worked around this problem, but I can't seem to pull up that version information right now. Hopefully someone else on the list can provide this. - Rob . On Fri, Jun 25, 2010 at 10:48 AM, wrote: > Hi all, > > I am not sure if this is an issue with my configuration, HP, or nox, but here > is the issue... when I run multiple openflow instances in an HP switch, the > two instances seem to fight over the same dpid in nox. > > First, enable only one instance... > > 00033|openflow|DBG:Passive tcp interface bound to port 6633 > 00034|nox|INFO:nox bootstrap complete > 00035|openflow|DBG:Passive tcp interface received connection > 00036|openflow|DBG:stream: negotiated OpenFlow version 0x97 (we support > versions 0x97 to 0x97 inclusive, peer no later than version 0x97) > 00037|nox|DBG:Success sending in 'sending switch config' > 00038|nox|DBG:Success sending in 'receiving features reply' > 00039|nox|DBG:Success receiving in 'receiving features reply' > 00040|nox|DBG:Success sending in 'receiving ofmp capability reply' > 00041|nox|DBG:Success receiving in 'receiving ofmp capability reply' > 00042|nox|DBG:Datapath f500019bbb30d00 sent error in response to capability > reply, assuming no management support > 00043|nox|DBG:No switch auth module registered, auto-approving switch > 00044|nox|DBG:Registering switch with DPID = 19bbb30d00 > 00045|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > 00046|switch|DBG:learned that 00:0a:41:ad:c1:81 is on datapath 0019bbb30d00 > port 18 > 00047|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > 00048|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > 00049|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > 00050|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > 00051|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > > > Enable the second instance on the HP switch > > > 00052|openflow|DBG:Passive tcp interface received connection > 00053|openflow|DBG:stream: negotiated OpenFlow version 0x97 (we support > versions 0x97 to 0x97 inclusive, peer no later than version 0x97) > 00054|nox|DBG:Success sending in 'sending switch config' > 00055|nox|DBG:Success sending in 'receiving features reply' > 00056|nox|DBG:Success receiving in 'receiving features reply' > 00057|nox|DBG:Success sending in 'receiving ofmp capability reply' > 00058|nox|DBG:Success receiving in 'receiving ofmp capability reply' > 00059|nox|DBG:Datapath f510019bbb30d00 sent error in response to capability > reply, assuming no management support > 00060|nox|DBG:No switch auth module registered, auto-approving switch > 00061|nox|DBG:Registering switch with DPID = 19bbb30d00 > 00062|openflow-event|DBG:received packet-in event from 0019bbb30d00 (len:64) > 00063|openflow|DBG:Passive tcp interface received connection > 00064|openflow|DBG:stream: negotiated OpenFlow version 0x97 (we support > versions 0x97 to 0x97 inclusive, peer no later than version 0x97) > 00065|nox|DBG:Success sending in 'sending switch config' > 00066|nox|DBG:Success sending in 'receiving features reply' > 00067|nox|DBG:Success receiving in 'receiving features reply' > 00068|nox|DBG:Success sending in 'receiving ofmp capability reply' > 00069|nox|DBG:Success receiving in 'receiving ofmp capability reply' > 00070|nox|DBG:Datapath f500019bbb30d00 sent error in response to capability > reply, assuming no management support > 00071|nox|DBG:No switch auth module registered, auto-approving switch > 00072|nox|DBG:Registering switch with DPID = 19bbb30d00 > 00073|openflow|DBG:Passive tcp interface received connection > 00074|openflow|DBG:stream: negotiated OpenFlow version 0x97 (we support > versions 0x97 to 0x97 inclusive, peer no later than version 0x97) > 00075|nox|DBG:Success sending in 'sending switch config' > 00076|nox|DBG:Success sending in 'receiving features reply' > 00077|nox|DBG:Success receiving in 'receiving features reply' > 00078|nox|DBG:Success sending in 'receiving ofmp capability reply' > 00079|nox|DBG:Success receiving in 'receiving ofmp capability reply' > 00080|nox|DBG:Datapath f510019bbb30d00 sent error in response to capability > reply, assuming no management support > 00081|nox|DBG:No switch auth module registered, auto-approving switch > 00082|nox|DBG:Registering switch with DPID = 19bbb30d00 > 00083|openflow-event|DBG:received packet-in e
Re: [nox-dev] git nox error
IIRC, there was a post some time back (a year ago?) with a similar error. I believe the result was a firewall between the client and noxrepo caused the problem and accessing nox using http was the work around: I believe the following should work: git clone http://noxrepo.org/nox but returns "fatal: http://noxrepo.org/nox/info/refs not found: did you run git update-server-info on the server?" So either I'm misremembering or something else is broken. I can't seem to find the post in the nox-dev archives, but hopefully this reminder will jog someone's memory. - Rob . 2010/6/22 kk yap : > Hi, > > Hmm. you are right. That is strange. I will get someone with the > permission to take a look. Thanks. > > Regards > KK > > > 2010/6/22 冯涛 : >> the command is "git clone git://noxrepo.org/nox" >> >> 2010/6/22 kk yap >>> >>> What is your command used? >>> >>> Regards >>> KK >>> >>> On 21 June 2010 23:55, 冯涛 wrote: >>> > Hi, >>> > I installed nox by git, but the result was >>> > "Initialized empty Git repository in /home/op/nox/.git/ >>> > fatal: read error: Connection reset by peer" >>> > and then how can I get nox 6.0? >>> > thanks >>> > Tao >>> > ___ >>> > nox-dev mailing list >>> > nox-dev@noxrepo.org >>> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> > >>> > >> >> > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] OpenFlow/NOX available control applications
On Tue, Apr 20, 2010 at 1:55 AM, Luca Giraudo wrote: > 5. Slicing (http://www.openflowswitch.org/wk/index.php/Slicing): > support to network virtualization, how to slice the network in many > virtual networks (as much independent and isolated as possible) > controlled by different NOX/etc controllers. This should probably be a reference to the FlowVisor. The page you've found there is evaluation *bandwidth* slicing in OpenFlow 1.0. The FlowVisor slices bandwidth, as well as other resources. The main page is http://www.openflowswitch.org/wk/index.php/FlowVisor and the technical report for it is: http://www.openflowswitch.org/downloads/technicalreports/openflow-tr-2009-1-flowvisor.pdf Hope this helps, - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] What will happen when OFPBAC_BAD_OUT_PORT occurs
The more likely explanation is that you tried to sent to output:$port with where $port == $inport. To prevent loops, OpenFlow makes you explicitly use the action output:OFPP_INPORT if you want to send back out the port a packet came in on. Does that help? - Rob . On Thu, Mar 4, 2010 at 11:24 AM, Guanyao Huang wrote: > Hello > My program shows error of type2 code4. From specification it means > OFPBAC_BAD_OUT_PORT error. > I want to know if one simple case is the possible reason. > Suppose the switch already has one entry for the flow, but now I > OFPFC_ADD a new entry with different port. Will this lead to the error > above? Or, the switch will simply delete the existing entry and insert > the new one. It seems my calculated path will not have a bad port > which leads to nowhere. > Thanks. > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Building a module outside of Nox's source tree?
Can someone point me to an example of building a C++ module outside of Nox's source tree? Looking at the build system, it seems like such a thing should be possible. Apologies if I'm asking a FAQ, but I wasn't able to find the answer for C++ on the mailing list (found Martin's resp re: python though). - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] namespace vigil ?
Question: would "#define vigil nox" produce enough backwards compatibility to solve the problem? Intuitively it would... - Rob . On Sun, Feb 21, 2010 at 7:45 PM, Martin Casado wrote: > Yeah, that's a fair point. We have tons of internal code which still uses > the vigil namespace. It is temping to clean up the cruft however. > >> Assuming there is enough code not pushed upstream into NOX out there, >> I am personally against name changes like this. The last time someone >> changed secchan to ofprotocol in OpenFlow, too much work results. >> Unless someone volunteer to update everyone's code to the new >> namespace, I see no reason why such a change should be made. >> >> Regards >> KK >> >> On 21 February 2010 18:15, Martin Casado wrote: >> >>> >>> That would be fantastic. Yes, vigil is purely vestigial. >>> >>> IIRC, all of the "namespace vigil" references are historical and outdated -- is that correct? Is there any reason not to wholesale replace vigil with 'nox'? The current name causes some confusion in the source code. I can do the honors if people agree that it's a good idea. - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >>> ___ >>> nox-dev mailing list >>> nox-dev@noxrepo.org >>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >>> > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] namespace vigil ?
IIRC, all of the "namespace vigil" references are historical and outdated -- is that correct? Is there any reason not to wholesale replace vigil with 'nox'? The current name causes some confusion in the source code. I can do the honors if people agree that it's a good idea. - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] g++ in fedora
On Wed, Feb 17, 2010 at 8:49 AM, Elisa Bellagamba wrote: > I have a question, is there any of you who is running it on Fedora? > > > > My problem is that I can’t install g++ 4.2 as suggested in the tutorial > because in Fedora the last available version seems to be gcc-c++.4.1.2. I'm using FC10 (which is kind of old already) and I have successfully built nox using g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) which is the default (after you apply all of your updates). What version of fedora are you using that you have 4.1.2? ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Flow_stats_in_event's "more" field
Actually, the idea is that a single flow_stats request can produce multiple flow_stats responses. Each flow_stats response (i.e., struct ofp_flow_stats) corresponds to a single flow entry, so you get one per flow entry. Yes, we could have created a parent structure to hold all of the responses in one message, but that's not how it's done... Was a bit of a PITA to work around with the flowvisor, b/c it's the only time a single XID request returns multiple responses, each reusing the same XID. - Rob . On Tue, Feb 9, 2010 at 10:12 PM, kk yap wrote: > Hi, > > The Flow_stats_in_event has a boolean field "more". What does that > mean and how is it set? Just a random discovery. > > Regards > KK > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Believe we've found a nasty race condition in SNAC
On Thu, Jan 28, 2010 at 11:09 AM, Ben Pfaff wrote: > On Thu, Jan 28, 2010 at 11:06:18AM -0800, Rob Sherwood wrote: >> IMHO, the best fix is to have the flow_mod also release the buffered >> packet, but we're not sure about how NOX/SNAC's internals work, so >> that might not be the easiest change. >> >> Let us know if this makes sense to you and if you know of an easy solution, > > Would sending a barrier command be an easy solution (for OpenFlow 1.0)? If the switch implemented it, yes (although presumably it would be less efficient -- three messages instead of one). However, to the best of my understanding, that's an open question if and how hardware switches are going to implement the barrier command. - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Believe we've found a nasty race condition in SNAC
[resending this to nox-dev for a wider audience] Hello, We've been trying to investigate some weird behavior in our network and think we've nailed down the cause. The symptoms were that the first packet of a flow were sometimes getting dropped, but only for certain machines. Upon investigation, it looks like given a packet_in with a packet buffered, SNAC responds with two messages: a flow mod to insert a new rule (with bufferid set to NONE) and then a packet_out to release the buffered packet with output action = TABLE. We hypothesize that the flow table insert does not always complete by the time the packet_out arrives, and thus the buffered packet is dropped (or misrouted). The reason why this has probably gone unnoticed so far is that (single threaded) software switches are not going to have this problem, and because it's a race condition that causes a packet drop, it usually just affects performance and not correctness. I've only noticed it because I'm connected directly to the NEC and this was particularly problematic for DNS requests. With 3+ DNS servers and some timeout between requests, DNS was consistently completely failing as a result of this (the newly inserted flow entry would timeout before the requests round-robin'ed back to each DNS server). IMHO, the best fix is to have the flow_mod also release the buffered packet, but we're not sure about how NOX/SNAC's internals work, so that might not be the easiest change. Let us know if this makes sense to you and if you know of an easy solution, - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Some recent flow setup numbers
Thanks for the data Martin. Can you describe the switches used for this? Were they openvswitch? I assume the switches were running on a different machine than the nox instance, to avoid CPU contention? I've run similar numbers with the cbench utility that ships with oflops: it simply emulates k switches and for each switch, tests the number of packet_in/flow_mod responses a controller can produce, per second. AFAICT, these should be basically the same numbers. Also, as a data point, the hardware switches we've tested are no where near capable of producing that number of flow setups per second. They generally support hundreds of flow setups per second, due to their limited CPU. - Rob . On Sat, Jan 23, 2010 at 11:30 PM, Martin Casado wrote: > Minlan recently did some performance analysis of Nox and has kindly agreed > to let me post the results to the mailing list. For those who might be > interested: > > #switch flows/sec (peak rate) > 1 18K > 2 29K > 3 39K > 4 59K > 5 45K > 6 50K > > This is roughly consistent with the numbers I've seen when doing similar > tests. It is important to note that in general, multiple switches are > required to saturate Nox. > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A general question regarding discovery module
On Mon, Dec 21, 2009 at 12:47 PM, Martin Casado wrote: > I agree that if the problem is timeout due to loss from overload, then the > only solution is prioritization. In general yes, but the current discovery algorithm is fairly brittle. With a large number of ports (48) on a hardware switch, even a small amount of packet loss it can falsely report down links. Part of the goal of the rewrite is to address this issue. > Question for the slicing folks, does slicing extend to the control channel > (packets set to the controller?) In addition to what Yiannis said (short story == "not yet"), Jean from HP developed a "rate limiter" openflow action as a vendor extension that can affect control and data traffic, so that could be used here. I think this is a useful primitive and something I'm hoping will making it into a future release of openflow (1.1?). - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A general question regarding discovery module
Hello Guanyao, I don't work for Nicira, but there are some well known scaling issues with the algorithm used by the discovery protocol. I'm hoping that this week I should be able to get around to an improved algorithm that, if you're interested in previewing, I can send you a copy. - Rob . On Fri, Dec 18, 2009 at 2:44 PM, Martin Casado wrote: > Yeah, it could be due to high-loss from load (unfortunately). > > You could try increasing the timeout value in discovery.py. If you don't > have dynamic link events, this should be able to survive temporary timeouts. > > What switches are you using? > >> In my program the discovery module times out links sometimes, causing >> my program not working well. I will debug to find out details why the >> link fails. Actually they are not supposed to fail. Maybe it's because >> of huge data. >> >> On Fri, Dec 18, 2009 at 8:41 AM, Martin Casado wrote: >> >>> >>> The goal is to detect link failures, so one would hope that would be the >>> most common failure mode. >>> >>> I assume LLDP packets are sent periodically. If there is no LLDP, what will be the most possible reason? The controller or the switch is too busy? On Thu, Dec 17, 2009 at 3:07 PM, Martin Casado wrote: > > Discovery times out links when no LLDP packets have been received over > some > timeout period. Timer values are documented within discovery.py. > > > >> >> It seems this module will periodically construct the topology. I dont >> know why it will periodically time_out the links. I want to know in >> what situations the links will time_out. >> Thanks. >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> >> > > >>> >>> > > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Setting up tunnels between switches
Hi Holly, IMHO, this is likely a general openflow question rather than a nox question, so is probably best posted on openflow-disc...@openflowswitch.org. In any case, there is support for bandwidth slicing in the up coming openflow 1.0 release. You can grab a release candidate from the openflowswitch.org website and your feedback is most welcome. - Rob . On Mon, Dec 21, 2009 at 12:05 AM, Holly Esquivel wrote: > Hi All, > > I've currently set up an network topology that consists of several > openflow switches and Nox controllers over multiple machines and many > VMs. I'm looking for a way to set up a tunnel between two Openflow > switches of a specified bandwidth. My goal is to be able to test if I > can protect my traffic that gets routed in the tunnel from other > malicious flows are routed either via the BGP path or are not > authorized to use this special tunnel but their traffic flows along > that link between the two switches. Any advice/assistance is greatly > appreciated. > > Thanks! > Holly > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Doubt about Flow Action Structure
First, this conversation seems to be more about OpenFlow than nox... I would suggest if you want more responses, you might consider moving it to the openflow-discuss mailing list. Second, the uin32_t actions in switch_features is an array of flags to describe which actions are *supported* by the switch. You specify actions in a flow_mod or packet_out packet, which both have variable length action payloads. For example, if you look at struct ofp_flow_mod, the length of the message, minus the length of the structure is the number of bytes of actions specified. To parse them, read the action header of the first action, look up the length, and the next action starts that many bytes later. Let me know if this is not clear, but there are notes in the header file that also try to explain this. - Rob . On Wed, Jul 22, 2009 at 7:39 AM, puneet gupta wrote: > Hi Ben, > > I could do that but in the structure struct ofp_switch_features(Page21 Sec > 5.3.1), actions (which is of ofp_action_type ), is defined as uint32_t and > not as an array. > > So i can have only one value and not multiple values? > > Or are you saying that send ofp_switch_features struct for the same port "n" > number of times with different actions each time(Don't think anyone would do > that ???) > > Regards, > Puneet > On Wed, Jul 22, 2009 at 7:20 PM, Ben Pfaff wrote: >> >> puneet gupta writes: >> >> > In the doc "openflow-spec-v0 8 9.pdf" , Page 18- Sec 5.2.3, enum >> > ofp_action_type is defined having values like >> > OFPAT_OUTPUT,OFPAT_SET_VLAN_VID >> > etc. >> > >> > However, this is just an enum not a bit vec. >> > >> > So for a switch that can support multiple actions for a single packet, >> > how do >> > i define its action type ? >> >> You add multiple actions with one value per action. > > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Stuck After Handshaking with NOX
[caveat; I'm only a nox user, not a developer at Nicira; apply grains of salt as needed] On Mon, Jul 20, 2009 at 8:14 AM, puneet gupta wrote: > I am starting nox with cli- ./nox_core -i ptcp:6633. > > So here are my questions- > > 1. Is it true that by starting NOX like this it won't do anything since > according to noxrepo.org "NOX exports a programmatic interface on top of > which multiple network programs (which we call applications) can run. These > applications can hook into network events, gain access to traffic, control > the switch forwarding decisions, and generate traffic". > > Hence do i need to start it with an application like ./nox_core -i ptcp:6633 > hub ? Exactly: you should run some application along with nox. I would recommend as an easy first pass, the 'switch' application, i.e., ./nox_core -i ptcp:6633 switch This will get you basic mac address learning switch functionality, i.e., what a normal switch would do. > I did this and then i started receiving ADD messages. But i just want to > confirm that is this the right way to do? Yes, except I think you will find 'switch' more useful than 'hub', if only because switches are typically more useful than hubs :-) > 2. If i want NOX to act like a full fledged controller i.e., making > decisions about Flow Tables, telling what port to output packet coming from > an in-port,increasing bandwidth etc, basically doing everything what the > OpenFlow draft says about,then with which application should i run it ? Or > do i have to write an application in NOX by myself to do all this? You can do both. There are a long list of already build nox applications that you can use off-the-shelf that ship with the code or you can write your own. The above mentioned 'switch' app does everything you've listed above except likely "increasing bandwidth" because I don't know what you mean by that. OpenFlow does not *yet* support any QoS primitives but you likely meant something else. > I was under the impression that server code would all be written and i have > to implement only the Client side of it? All of the *switch* code is written and you only need implement the controller. Nox is actually a controller framework, reducing your task even further. One could in theory control an openflow switch without using nox, but you would likely have to replicate a lot of functionality. > Also is there any other link which clears all this and tells about how to > use it from scratch apart from noxrepo.org? Not directly that I know of. If you go to www.openflowswitch.org, click "getting started" will point you in the right direction, but wouldn't have answered your question. This web page (http://www.openflowswitch.org/wk/index.php/OpenFlowVMS) describes how to create a whole openflow network out of virtual machines, and you can infer a lot from that process. @others: Maybe this is a call for an OpenFlow FAQ? To be fair, I'm not sure these particular questions have come up before... - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Vlog and Syslog
On Wed, May 6, 2009 at 9:27 AM, Ben Pfaff wrote: > > That's not the right direction. Those sockets are used only for > configuring vlog. They are not a destination for log messages. > > I would verify that logging DBG-level messages is actually > enabled at runtime. The -l option to vlogconf can help you with > this. Apologies if this is documented somewhere that I don't know about- feel free to tell me to RTFM if you can point me to the 'M' :-) I must be doing something wrong. When I call vlogconf on a running nox, I get a timeout. cap...@openflowvisor:/home/basenox/Apr11-2009/openflow/utilities$ ps ww 30395 PID TTY STAT TIME COMMAND 30395 ?Ssl 52:25 /home/basenox/Apr11-2009/noxcore/build-vlan374/src/.libs/lt-nox_core -d -v -i ptcp:6633 dhcp lavi routing flowdblogger eventlogger snmp snmptrap mobiledb apdb cap...@openflowvisor:/home/basenox/Apr11-2009/openflow/utilities$ ./vlogconf -t30395 -l /tmp/vlogs.30395: /tmp/vlogs.30395: transaction error: Connection timed out - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Vlog and Syslog
To be a little more clear, we do have a '*.*' line in our syslog.conf, and I have (via small perl script) generated test log messages to syslog facility/level user.debug and made sure those lines end up in the desired file. So, syslog is doing its thing correctly. The missing nox messages we are looking for match /DBG/: the potential confusion is these messages might not go to syslog and might not go to syslog level debug. How do we log these messages? If we run in non-daemon mode, these messages show up on console a plenty, but when we run in daemon mode, they disappear. My guess from a quick glance through the code and `lsof` is that they get written to a unix socket (/tmp/vlog.$$) and are never heard from again. Is there some sort of extra daemon (vlogd?) that we are supposed to be running to get these messages? Hopefully that is enough information to point us in the right direction. Thanks in advance, - Rob . On Wed, May 6, 2009 at 7:42 AM, kk yap wrote: > == Posting to mailing list due to careless click of reply instead of > reply to all== > > Hi Ben, > > Thanks for the prompt reply. But risking appearing as naggy, Rob has > tested that syslog does log debug messages. So, that's unlikely to be > the reason. This has been preventing us from tracking down what is > the causing NOX to slow down in our deployment. > > Thanks > > Regards > KK > > > > 2009/5/6 Ben Pfaff : >> kk yap writes: >> >>> Rob and I was trying to get NOX to log into syslog today. Rob has >>> tested that syslog does log debug messages but we still fails to see >>> the debug messages for NOX. The interaction between vlog, vlog_server >>> and syslog is unclear to us. Can someone check if that is working? >> >> It's likely that syslog is not configured to log debug messages. >> Try adding a line to /etc/syslog.conf like this: >> *.* /var/log/verbose >> and see whether the messages appear. >> >> vlog_server allows vlog levels to be changed at runtime using the >> vlogconf program (from slightly older versions of the openflow >> distribution). >> > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Batch insert for SQLite in NOX
Assuming this is a normal sqlite db, I would just use the /usr/bin/sqlite3 command line interface with the .import command; check out .help for the online help and instructions. - Rob . On Tue, Feb 24, 2009 at 10:35 PM, kk yap wrote: > Hi, > > I was wondering how to do batch inserts to SQLite database in NOX. I > have managed to do row by row insertion using > Sync_transactional_storage. However, there does not seem to have any > batch insertion in storage from my grep efforts. Can someone point me > to the correct place to hunt? > > Thank you. > > Regards > KK > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] FLOW_MOD message ignored
On Sun, Feb 15, 2009 at 10:23 PM, kk yap wrote: > Hi, > > I managed to do the flow mod by changing the command the ADD instead > of MODIFY. Can someone explain what is the difference? [taking a stab] Add is if you want to create a brand new flow entry. Modify is if you want to change the actions of an existing flow entry: i.e., the ofp_match structure has to match an existing flow entry for the operation to be meaningful. - Rob . ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
