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