[ovs-discuss] skipping output to input port

Ben Pfaff blp at ovn.org
Wed Nov 20 23:29:59 UTC 2019

On Tue, Nov 12, 2019 at 04:27:19PM -0500, Nicolas Bouliane via discuss wrote:
> Sometimes, icmpv6 neighbor advertisement packets are being sent out of the
> hypervisor without their VLAN tag. It seems to only happens when the icmpv6
> is sent to a multicast address. That doesn't happen to every VMs, and not
> all the time. Can't reproduce the problem on demand yet.
> I'm trying to better understand what the log message "skipping output to
> input port" really means. Because every time a packet is sent without a
> VLAN tag, we also see this printed in the log. Normally, these packets are
> being VLAN tagged, and when we  ofproto/trace, we see that the packet
> should be tagged.
> 2019-11-12T21:06:13.838Z|01842|ofproto_dpif_xlate(handler148)|INFO|skipping
> output to input port on bridge br0 while processing
> recirc_id=0x5a4de60,ct_state=inv|trk,eth,icmp6,in_port=10227,vlan_tci=0x0000,dl_src=6a:5e:dd:34:f9:be,dl_dst=33:33:ff:25:80:0b,ipv6_src=fe80::685e:ddff:fe34:f9be,ipv6_dst=ff02::1:ff25:800b,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=255,icmp_type=135,icmp_code=0,nd_target=2604:xxxx:x:xx::xx:xxxx,nd_sll=6a:5e:dd:34:f9:be,nd_tll=00:00:00:00:00:00

Since in_port=10227 here, the message means that some action is trying
to output the packet to port 10227.  OpenFlow says that this must be

The FAQ has more information:

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

         $ ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\

More information about the discuss mailing list