On Fri, Aug 01, 2014 at 07:02:39PM +0200, Ronald van der Pol wrote: > On Fri, Aug 01, 2014 at 09:29:43 -0700, Ben Pfaff wrote: > > > > rvdp@lithium:~$ sudo ovs-ofctl show br-of > > > OFPT_FEATURES_REPLY (xid=0x2): dpid:00000002c9ee01d0 > > > n_tables:254, n_buffers:256 > > > capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP > > > actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC > > > SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE > > > 1(eth2): addr:00:02:c9:ee:01:d1 > > > config: 0 > > > state: 0 > > > current: COPPER > > > advertised: 10GB-FD COPPER > > > supported: 10GB-FD COPPER > > > speed: 0 Mbps now, 10000 Mbps max > > > 5(phy-br-of): addr:52:92:c1:84:d9:99 > > > config: 0 > > > state: 0 > > > current: 10GB-FD COPPER > > > speed: 10000 Mbps now, 0 Mbps max > > > 7(eth1): addr:00:02:c9:ee:01:d0 > > > config: 0 > > > state: 0 > > > current: 10GB-FD COPPER > > > advertised: 10GB-FD COPPER > > > supported: 10GB-FD COPPER > > > speed: 10000 Mbps now, 10000 Mbps max > > > LOCAL(br-of): addr:00:02:c9:ee:01:d0 > > > config: 0 > > > state: 0 > > > speed: 0 Mbps now, 0 Mbps max > > > > ... > > > > > rvdp@lithium:~$ sudo ovs-ofctl dump-flows br-of > > > NXST_FLOW reply (xid=0x4): > > > cookie=0x0, duration=19204.821s, table=0, n_packets=14388, > > > n_bytes=604592, idle_age=1, priority=4,in_port=5,dl_vlan=3 > > > actions=mod_vlan_vid:101,NORMAL > > > cookie=0x0, duration=19205.755s, table=0, n_packets=6, n_bytes=268, > > > idle_age=11353, priority=4,in_port=5,dl_vlan=2 > > > actions=mod_vlan_vid:103,NORMAL > > > cookie=0x0, duration=19210.085s, table=0, n_packets=236, n_bytes=15528, > > > idle_age=162, priority=2,in_port=5 actions=drop > > > cookie=0x0, duration=19210.713s, table=0, n_packets=1778506, > > > n_bytes=160065556, idle_age=15259, priority=1 actions=NORMAL > > > rvdp@lithium:~$ > > > > > > -------------------------------------- > > > > > > Counters on the flow rule "in_port=5,dl_vlan=3" increase. > > > > > > ofproto/trace gives: > > > > > > > > > rvdp@lithium:~$ sudo ovs-appctl ofproto/trace br-of > > > in_port=7,dl_vlan=103,dl_src=fa:16:3e:e4:a0:7f,dl_dst=ff:ff:ff:ff:ff:ff,arp,arp_spa=10.101.0.2,arp_tpa=10.101.0.5,arp_sha=fa:16:3e:e4:a0:7f,arp_tha=00:00:00:00:00:00 > > > Flow: > > > arp,metadata=0,in_port=7,dl_vlan=103,dl_vlan_pcp=0,dl_src=fa:16:3e:e4:a0:7f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.101.0.2,arp_tpa=10.101.0.5,arp_sha=fa:16:3e:e4:a0:7f,arp_tha=00:00:00:00:00:00 > > > Rule: table=0 cookie=0 priority=1 > > > OpenFlow actions=NORMAL > > > no learned MAC for destination, flooding > > > > > > Final flow: unchanged > > > Relevant fields: > > > skb_priority=0,arp,in_port=7,dl_vlan=103,dl_src=fa:16:3e:e4:a0:7f,dl_dst=ff:ff:ff:ff:ff:ff,nw_frag=no > > > Datapath actions: 4,6,8 > > > rvdp@lithium:~$ > > > > > > This is what should happen. This is what I expect. But the tshark > > > shows that the vlan id has changed from 103 to 3. > > > > > > Is in_port=7 the correct port? If I use in_port=5 the packet gets dropped. > > > > For a packet ingressing on eth1, the in_port should be 5 because this > > form of ofproto/trace uses OpenFlow port numbers and we can see from > > "ovs-ofctl show br-of" above that eth1 has OpenFlow port 5. > > > > If you use OpenFlow port 5 then the packet gets dropped because that's > > what your OpenFlow table says to do: this packet with VLAN 103 doesn't > > match the rules that say in_port=5,dl_vlan=2 or in_port=5,dl_vlan=3 and > > therefore falls back to the lower-priority in_port=5 rule that just says > > actions=drop. > > Thanks, but port = 7 is the correct port, right? The 'show br-of' has: > > 7(eth1): addr:00:02:c9:ee:01:d0
OK, got it. The datapath actions only show output actions. Nothing is modifying VLANs. The kernel module doesn't do that on its own. I have no idea how the VLAN ID could be changing. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
