[ovs-discuss] Openvswitch: Rules matching ports behaving strangely - Rules translation problem?

Justin Pettit jpettit at nicira.com
Tue Oct 20 00:47:38 UTC 2009

On Oct 19, 2009, at 5:31 PM, Andreas Wundsam wrote:

> Aahh, ok. I figured out the fact that dp-ctl shows low-level
> non-wildcard caching flows. But I got caught by the overloading of
> "port" with "physical port" and "ICMP message type" :). Thanks for
> clearing that one out!

Our emails crossed, so it looks like you got a bit more clarification  
on this.  However, I'd like to point out that the ICMP type overload  
the transport port, not the physical port.  The confusion lies in that  
the output lists two different attributes with the name "port".  We  
should really change the transport port to something like "tp_port" or  
something.  I regret that we didn't call the physical port "interface"  
or something like that in OpenFlow.

> Some more info on the "drop rule not respected" aspect of the issue:
> Here's an example where I see traffic forwarded for a port that the  
> high
> level rule says "DROP" for, without any low-level rule appearing in  
> dpctl.
> root at loadgen134:~# ovs-dpctl show br_out
> dp4:
> [...]
>        port 3: vif10.2
> [...]
> root at loadgen134:~# ovs-ofctl dump-flows tcp:
> [...]
>  duration=250727s, table_id=1, priority=32768, n_packets=268,
> n_bytes=26024, in_port=3,actions=drop
> [...]
> root at loadgen134:~# ovs-dpctl dump-flows br_out
> port0001:vlan65535 mac00:1b:21:10:8c:7e->00:16:3e:76:4f:93 type0800
> proto1 ip192.168.10.1-> port0->0, packets:244, bytes: 
> 23912,
> used:0.185s, actions:0,2,5,4,3
> port0001:vlan65535 mac00:24:97:f3:a8:4a->01:80:c2:00:00:00 type05ff
> proto0 ip0.0.0.0-> port0->0, packets:20283, bytes:1216980,
> used:0.781s, actions:2,4
> port0002:vlan65535 mac00:16:3e:76:4f:93->00:1b:21:10:8c:7e type0800
> proto1 ip192.168.10.2-> port8->0, packets:244, bytes: 
> 23912,
> used:0.185s, actions:0,1,5,4,3
> [NOTE: no rule for port0003!]
> root at loadgen134:~# tcpdump -i vif10.2
> tcpdump: WARNING: vif10.2: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol  
> decode
> listening on vif10.2, link-type EN10MB (Ethernet), capture size 96  
> bytes
> 00:20:25.749387 IP > ICMP echo request, id
> 33077, seq 205, length 64
> 00:20:25.749499 IP > ICMP echo reply, id
> 33077, seq 205, length 64
> 00:20:26.749351 IP > ICMP echo request, id
> 33077, seq 206, length 64
> 00:20:26.749553 IP > ICMP echo reply, id
> 33077, seq 206, length 64

The datapath only gets cached entries on demand.  If a datapath entry  
hasn't seen traffic for five second, it will be ejected by the vswitch  
process, which is the master maintainer of the rules.  So, in this  
case, I wouldn't expect to see an entry explicitly dropping traffic  
coming in on port 3.  The ping traffic you're showing appears to be  
traveling between ports 1 and 2.  If you generated traffic from the VM  
with vif10.2, then I would expect you to see an entry dropping it in  
the datapath.


More information about the discuss mailing list