[ovs-discuss] STP Support
Goodmorning, Does anyone know if OVS return the OFPC_STP bit in the capabilities field when STP is activated? ThankYou, LP ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] warning messages regarding buffer space and unknown buffer
Hi, We are getting the following warnings while using OVS. 1) Apr 23 13:19:27|00019|dpif|WARN|system@br0: recv failed (No buffer space available) 2) Apr 23 13:19:37|00033|pktbuf|WARN|cookie mismatch: 01fa != 02fa Apr 23 13:19:37|00034|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BUFFER_UNKNOWN error reply to OFPT_FLOW_MOD message We get the warnings after a few seconds of traffic switching. First error is less frequent as compared to second one which is much frequent. We have not done any special configurations while running OVS. We are receiving packets from one ether port and sending out on the other port after matching five tuple (src/dst IP, src/dst port, protocol). A log of error messages is attached in a file. Following are the platform specifications: OVS version: 1.4.0 traffic type: MTU size UDP packets @7.3 Gbps, generating 100,000 flows by changing src IPs. OS: Fedora release 12, Linux 2.6.31.5-127.fc12.i686.PAE CPU: Intel Core i3 @ 2100 GHz Controller: NOX, simple IP based switching application. Also tried beacon controller but the problem persists. Does this have any effect on performance or functionality of OVS? How should we resolve this problem? Any suggestions or pointers are highly appreciated. thanks and regards, Junaid Khalid Apr 23 13:19:16|1|reconnect|INFO|unix:./var/run/openvswitch/db.sock: connecting... Apr 23 13:19:16|2|reconnect|INFO|unix:./var/run/openvswitch/db.sock: connected Apr 23 13:19:16|3|bridge|INFO|created port eth3 on bridge br0 Apr 23 13:19:16|4|bridge|INFO|created port br0 on bridge br0 Apr 23 13:19:16|5|bridge|INFO|created port eth4 on bridge br0 Apr 23 13:19:16|6|ofproto|INFO|using datapath ID 002320cc711c Apr 23 13:19:16|7|ofproto|INFO|datapath ID changed to 001b2173ed48 Apr 23 13:19:16|8|rconn|INFO|br0-tcp:127.0.0.1:6633: connecting... Apr 23 13:19:16|9|rconn|INFO|br0-tcp:127.0.0.1:6633: connected Apr 23 13:19:16|00010|ofp_util|WARN|received Nicira extension message of unknown type 8 Apr 23 13:19:16|00011|ofp_util|WARN|received Nicira extension message of unknown type 8 Apr 23 13:19:16|00012|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BAD_SUBTYPE error reply to invalid message Apr 23 13:19:24|00013|rconn|INFO|br0-tcp:127.0.0.1:6633: connection closed by peer Apr 23 13:19:25|00014|rconn|INFO|br0-tcp:127.0.0.1:6633: connecting... Apr 23 13:19:25|00015|rconn|INFO|br0-tcp:127.0.0.1:6633: connected Apr 23 13:19:25|00016|ofp_util|WARN|received Nicira extension message of unknown type 8 Apr 23 13:19:25|00017|ofp_util|WARN|received Nicira extension message of unknown type 8 Apr 23 13:19:25|00018|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BAD_SUBTYPE error reply to invalid message Apr 23 13:19:27|00019|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:28|00020|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:29|00021|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:30|00022|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:31|00023|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:31|00024|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:32|00025|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:32|00026|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:33|00027|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:34|00028|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:35|00029|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:35|00030|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:36|00031|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:36|00032|dpif|WARN|system@br0: recv failed (No buffer space available) Apr 23 13:19:37|00033|pktbuf|WARN|cookie mismatch: 01fa != 02fa Apr 23 13:19:37|00034|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BUFFER_UNKNOWN error reply to OFPT_FLOW_MOD message Apr 23 13:19:37|00035|pktbuf|WARN|cookie mismatch: 01fb != 02fb Apr 23 13:19:37|00036|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BUFFER_UNKNOWN error reply to OFPT_FLOW_MOD message Apr 23 13:19:37|00037|pktbuf|WARN|cookie mismatch: 01fc != 02fc Apr 23 13:19:37|00038|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BUFFER_UNKNOWN error reply to OFPT_FLOW_MOD message Apr 23 13:19:37|00039|pktbuf|WARN|cookie mismatch: 01fd != 02fd Apr 23 13:19:37|00040|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BUFFER_UNKNOWN error reply to OFPT_FLOW_MOD message Apr 23
Re: [ovs-discuss] STP Support
I would like to know also if it is possible to know who is the root bridge and which the root/designed ports are With ovs-ofctl show br0 I just see BLOCK or FORWARD Thankyou, LP Il 23/04/2012 11:18, Luca Prete ha scritto: Goodmorning, Does anyone know if OVS return the OFPC_STP bit in the capabilities field when STP is activated? ThankYou, LP ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] STP Support
it can be enabled with *ovs-vsctl -- clear Bridge br0 sflow* *802.1D Spanning Tree Protocol (STP)* Configure bridge *br0* to participate in an 802.1D spanning tree: *ovs-vsctl set Bridge br0 stp_enable=true* Set the bridge priority of *br0* to 0x7800: *ovs-vsctl set Bridge br0 other_config:stp-priority=0x7800* Set the path cost of port *eth0* to 10: *ovs-vsctl set Port eth0 other_config:stp-path-cost=10* Deconfigure STP from above: *ovs-vsctl clear Bridge br0 stp_enable* In 1.0 specs there's written: *Spanning Tree *OpenFlow switches may optionally support 802.1D Spanning Tree Protocol. Those switches that do support it are expected to process all 802.1D packets locally before performing ow lookup. A switch that implements STP must set the OFPC_STP bit in the 'capabilities' eld of its OFPT_FEATURES_REPLY message. A switch that implements STP must make it available on all of its physical ports, but it need not implement it on virtual ports (e.g. OFPP_LOCAL). Port status, as speci ed by the spanning tree protocol, is then used to limit packets forwarded to the OFP_FLOOD port to only those ports along the spanning tree. Port changes as a result of the spanning tree are sent to the controller via port-update messages. Note that forward actions that specify the outgoing port or OFP_ALL ignore the port status set by the spanning tree protocol. Packets received on ports that are disabled by spanning tree must follow the normal flow table processing path. Switches that do not support 802.1D spanning tree must allow the controller to specify the port status for packet flooding through the port-mod messages. About Beacon Controller, for switches that support STP, they can return the OFPC_STP bit in the capabilities field of the features reply message. This will then limit the ports that the flow mod action flood will send to, and Beacon will automatically take advantage of this for flooding. Otherwise everything should be done manualy on the controller. LP Il 23/04/2012 18:55, Ben Pfaff ha scritto: On Mon, Apr 23, 2012 at 09:50:20AM -0700, Justin Pettit wrote: On Apr 23, 2012, at 9:22 AM, Ben Pfaff wrote: On Mon, Apr 23, 2012 at 11:18:07AM +0200, Luca Prete wrote: Does anyone know if OVS return the OFPC_STP bit in the capabilities field when STP is activated? I think that it doesn't. Perhaps it should. You're right; this looks like an oversight. I'll look into it. I think we should set that bit whenever a DPIF-based datapath is used, not just when STP is enabled, though. I don't recall how OVS enables or disables STP. If it can't be enabled through OpenFlow, then it might not make sense to set OFPC_STP. If it can, then of course it does make sense. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] warning messages regarding buffer space and unknown buffer
On Mon, Apr 23, 2012 at 03:54:09PM +0600, junaid khalid wrote: 1) Apr 23 13:19:27|00019|dpif|WARN|system@br0: recv failed (No buffer space available) Packets are arriving at your interfaces faster than ovs-vswitchd can set up flows. What traffic is going through the switch? 2) Apr 23 13:19:37|00033|pktbuf|WARN|cookie mismatch: 01fa != 02fa OVS is sending buffered packets to your OpenFlow controller. The OpenFlow controller is sending back replies to use those buffers, but the replies are arriving slowly enough that by the time that they arrive the switch has already discarded those buffers. Apr 23 13:19:37|00034|connmgr|INFO|br0-tcp:127.0.0.1:6633: sending type OFPET_BAD_REQUEST, code OFPBRC_BUFFER_UNKNOWN error reply to OFPT_FLOW_MOD message Also a consequence of the above. traffic type: MTU size UDP packets @7.3 Gbps, generating 100,000 flows by changing src IPs. NOX isn't going to be able to keep up with that rate. OVS 1.4.0 isn't, either, but OVS 1.6.90 from the tip of master should be able to handle it without a controller. Throwing in an OpenFlow controller that sees every packet will probably bog things down a lot. Apr 23 13:19:16|00010|ofp_util|WARN|received Nicira extension message of unknown type 8 That message has been obsolete for ages, why are you using it? ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
