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
suppressed.
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
stack:
$ ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\
load:0->NXM_OF_IN_PORT[],\
2,3,4,5,6,\
pop:NXM_OF_IN_PORT[]
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
