On Tue, Jul 9, 2013 at 4:07 AM, Isaku Yamahata <yamah...@valinux.co.jp> wrote: > The upstream has the fix for dev_forward_skb() to reset pkt_type to > PACKET_HOST. the change set of 06a23fe31ca3992863721f21bdb0307af93da807 > So the pkt_type of PACKET_OTHERHOST doesn't come in. > This patch is a workaround for older kernel, reset skb->pkt_type when > receiving pkt_type of PACKET_OTHERHOST. > > When two tunnel ports created on two OVS bridges on same host and > two ports are the end point of the tunnel, packets are dropped as below. > > If a packet has pkt_type of PACKET_OTHERHOST when coming to ovs bridge, > the packet is dropped by ip_rcv() if rules are installed and skb are > forwarded by loopback device. > Packet isn't dropped if flow rule isn't installed in kernel datapath, > OVS_ACTION_ATTR_OUTPUT is used to send the packet. > > netns A | root netns | netns B > veth<->veth=ovs bridge=gre<-loop back->gre=ovs bridge=veth<->veth > > arp packet -> > pkt_type > BROADCAST------------>ip_rcv()------------------------> > > <- arp reply > pkt_type > > rule exists > ip_rcv()<-----------------OTHERHOST > drop > > <--------------------ip_rcv()<--- PACKET_HOST rule doesn't exists > pass ^ | > | |upcall > | V > OVS_ACTION_ATTR_OUTPUT > ovs-switchd > > Cc: Murphy McCauley <murphy.mccau...@gmail.com> > Cc: Jesse Gross <je...@nicira.com> > Signed-off-by: Isaku Yamahata <yamah...@valinux.co.jp>
Doesn't the upstream change only work if you go through a veth first? What happens if the physical device is directly attached to OVS? X-CudaMail-Whitelist-To: dev@openvswitch.org _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
