[pox-dev] link detected problem in l2_multi

[Murphy McCauley]

Indeed, this is a problem with "reactive" type applications.  There are various things you can do which involve various tradeoffs.  In general, you want to install broader matches (e.g., don't use from_packet(), or wildcard some of the fields) and you want to install them earlier.

You also can use OVS's learning feature to control the speed of packet-in messages.  For example, have the first table operate mostly like l2_multi.  If the packet misses the first table, send it to the second table.  The default rule on the second table will send the packet to the controller as well as using the learn action to add a rule with a one second timeout to the second table which drops all packets from that MAC address.  This way, the controller gets at most one packet per second from a host.

Alternatively, don't be reactive.  Do something more like the forwarding.topo_proactive component, which doesn't use arbitrary traffic to drive the configuration of the switches.

-- Murphy 

On Jul 5, 2013, at 2:29 AM, Yanan Wu wrote:

> 
> Hi, Murphy
> 
> 
>> [90-e2-ba-0a-bc-8e 3] Error: type: OFPET_BAD_REQUEST (1)
>> [90-e2-ba-0a-bc-8e 3] Error: code: OFPBRC_BUFFER_UNKNOWN (8)
> 
> It pretty much says why -- the switch is sending a packet out, but the buffer ID it says to send isn't on the switch.  The most common reasons are: 1) the buffer has already been sent and discarded, and 2) the switch is out of buffers.
> 
> ========================================================================
> 
> The problem has remained unsolve.
> 
> The cause was that I used the 'iperf ' to test my modified l2_multi code.  Before establishing  the first path,  there are a lot of "packet-In" appeared.  So the  error described above  may arise.
> 
> It seems that I cannot control the speed of 'packet-in'.
> 
> How to fix it ? Do I need to modify the openvswith? or Just modify the l2_multi? 
> 
> Best Regards,
> Yanan
> 
> 
> 
> 
> -----Original E-mail-----
> From: "Murphy McCauley" <murphy.mccauley at gmail.com>
> Sent Time: 2013-7-2 22:34:37
> To: "Yanan Wu" <wyanan at mail.ustc.edu.cn>
> Cc: pox-dev at lists.noxrepo.org
> Subject: Re: [pox-dev] link detected problem in l2_multi
> 
> On Jul 2, 2013, at 7:05 AM, Yanan Wu wrote:
> 
>> I want to achieve the 'multipath' in l2_multi. It means I could neither use the openflow.spanning_tree nor use the stp protocol?
> 
> You might or might not be able to use STP, but you can definitely use openflow.spanning_tree.  The latter only affects broadcast traffic.  The paths for unicast are entirely under the control of _get_path() in l2_multi.  Currently this doesn't take advantage of multiple paths, but you could modify it to do so (and it will give you shortest paths, which STP might not).  Broadcasts would all be done on a single tree, which may be fine.  If it's not, you'll have to install flows yourself to do broadcasts.
> 
>> Besides, when the controller sends delayed packet out, there is some openflow error like this.
>> 
>> Why it shows the openflow error ? what kind of influence can the errors have on the "sending delayed packet out"?
> 
>> [90-e2-ba-0a-bc-8e 3] Error: type: OFPET_BAD_REQUEST (1)
>> [90-e2-ba-0a-bc-8e 3] Error: code: OFPBRC_BUFFER_UNKNOWN (8)
> 
> It pretty much says why -- the switch is sending a packet out, but the buffer ID it says to send isn't on the switch.  The most common reasons are: 1) the buffer has already been sent and discarded, and 2) the switch is out of buffers.
> 
> If you're running l2_multi without spanning tree on a network with loops (which I think is the case based on your diagram), you've probably got a broadcast storm which is running the switches out of buffers.
> 
> The result of the error is that the packet from the delayed packet out is probably getting dropped.  If you've got a broadcast storm, this is the absolute least of your problems.
> 
> -- Murphy
>> -----Original E-mail-----
>> From: "Murphy McCauley" <murphy.mccauley at gmail.com>
>> Sent Time: 2013-6-23 18:16:01
>> To: Yanan <wyanan at mail.ustc.edu.cn>
>> Cc: pox-dev at lists.noxrepo.org
>> Subject: Re: [pox-dev] link detected problem in l2_multi
>> 
>> I am guessing that your switch has an implementation of the Spanning Tree Protocol and is using that to disable links; this is exactly what STP is supposed to do on topologies with loops in order to prevent broadcast storms.
>> 
>> You may be able to disable STP in your switch's configuration.  If you do this, you should run POX's spanning_tree module for the same reason. POX's spanning tree component with l2_multi should allow all shortest paths to be discovered and used by unicasts to known addresses, and should only affect broadcast/multicast/unknown frames (in contrast to the STP built into the switch).
>> 
>> -- Murphy
>> 
>> On Jun 23, 2013, at 2:55 AM, Yanan wrote:
>> 
>>> 
>>> hi,Murphy
>>> 
>>> I have 3 openvswitch, like this            .
>>> 
>>> In the discovery, link detected: of-br-10 -> of-br-9      (I just leave out the 'port'). But I cannot get the link " of-br-9 -> of-br-8" .
>>>                                              of-br-9  -> of-br-10
>>>                                              of-br-10 -> of-br-8
>>>                                              of-br-8 -> of-br-10
>>>                                              of-br-8 -> of-br-9
>>> 
>>> wireshark of of-br-8, 
>>>                       I did't have  the PacketIn   "Intel_28_2d_d5  NiciraNe_00:00:01 OFP+LLDP PacketIn"
>>> 
>>> wireshark of of-br-9,
>>>                              But in the of-br-9, I can see the controller send the LLDP packet to the of-br-9, "Intel_28_2d_d5  NiciraNe_00:00:01 OFP+LLDP PacketOut"
>>> 
>>> 
>>> Then I see about the information of bridge of-br-9,  the state of "Intel_28_2d_d5" is STP_BLOCK.  And how to change the state?
>>> 
>>> In fact , I did not know the 'STP_FORWADING ' or 'STP_BLOCK' very well.   All of this is my guess.
>>> 
>>> Can u help me t
>>> 
>>> sdn at IPL209:~$ sudo ovs-ofctl show of-br-9
>>> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:000090e2ba282dd5
>>> n_tables:255, n_buffers:256
>>> features: capabilities:0xc7, actions:0xfff
>>>  3(eth6): addr:90:e2:ba:28:2d:d7
>>>      config:     0
>>>      state:      STP_FORWARD
>>>      current:    1GB-FD COPPER AUTO_NEG
>>>      advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>      supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>  4(eth4): addr:90:e2:ba:28:2d:d5
>>>      config:     0
>>>      state:      STP_BLOCK
>>>      current:    1GB-FD COPPER AUTO_NEG
>>>      advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>      supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>  LOCAL(of-br-9): addr:90:e2:ba:28:2d:d5
>>>      config:     0
>>>      state:      0
>>> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
>>> 
>>> Best Regards,
>>> Yanan
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20130705/e06163b0/attachment-0001.htm>