[ovs-discuss] How to monitor packets being dropped? Sent back a packet back to the port where it came from?
rault.clement at gmail.com
Wed Apr 22 13:54:30 UTC 2015
Thanks for your answer!
Could you point to me where in the openvswitch code this check (inport
== outport) is done?
On 15 April 2015 at 01:10, Ben Pfaff <blp at nicira.com> wrote:
> On Fri, Apr 10, 2015 at 06:15:18PM +0200, Cl??ment Rault wrote:
>> I am trying to develop inband mechanisms for fast reaction to failures
>> and I am experiencing a very high packet loss.
>> "--- 126.96.36.199 ping statistics ---
>> 573 packets transmitted, 13 received, 97% packet loss, time 574650ms
>> rtt min/avg/max/mdev = 1.259/2.291/5.683/1.140 ms"
>> which is probably due to the fact that some of my packets get in a
>> infinite (or not infinite but very long) loop (even though it
>> shouldn't happen) but I would like to
>> understand why and where they get dropped.
>> And therefore I would like to know if there is a way to check if a
>> switch (I am using mininet) is dropping packets?
>> Because I didn't put any rule to drop them and I am not decrementing
>> the ttl so it cannot from that...
>> What is the default behaviour/scenario for a OVS switch to decide to
>> drop a packet?
>> Could it be because sometimes I am sending the packet back to the port
>> where the packet came from?
> This FAQ entry might be a good start:
> ### Q: I added a flow to send packets out the ingress port, like this:
> ovs-ofctl add-flow br0 in_port=2,actions=2
> but OVS drops the packets instead.
> A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
> out its ingress port. The rationale is that dropping these packets
> makes it harder to loop the network. Sometimes this behavior can
> even be convenient, e.g. it is often the desired behavior in a flow
> that forwards a packet to several ports ("floods" the packet).
> Sometimes one really needs to send a packet out its ingress port
> ("hairpin"). In this case, output to OFPP_IN_PORT, which in
> ovs-ofctl syntax is expressed as just "in_port", e.g.:
> ovs-ofctl add-flow br0 in_port=2,actions=in_port
> This also works in some circumstances where the flow doesn't match
> on the input port. For example, if you know that your switch has
> five ports numbered 2 through 6, then the following will send every
> received packet out every port, even its ingress port:
> ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port
> or, equivalently:
> ovs-ofctl add-flow br0 actions=all,in_port
> Sometimes, in complicated flow tables with multiple levels of
> "resubmit" actions, a flow needs to output to a particular port
> that may or may not be the ingress port. It's difficult to take
> advantage of OFPP_IN_PORT in this situation. To help, Open vSwitch
> provides, as an OpenFlow extension, the ability to modify the
> in_port field. Whatever value is currently in the in_port field is
> the port to which outputs will be dropped, as well as the
> destination for OFPP_IN_PORT. This means that the following will
> reliably output to port 2 or to ports 2 through 6, respectively:
> ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT,2
> ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT,2,3,4,5,6
> If the input port is important, then one may save and restore it on
> the stack:
> ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT,\
More information about the discuss