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

Andreas Wundsam andi at net.t-labs.tu-berlin.de
Tue Oct 20 00:31:23 UTC 2009


Hi Justin,

Thanks for the quick reply, I added a concrete example of the problem
further down:

Justin Pettit schrieb:
>> I am confused by the port0->0 and port8->0 in these listings -- my dp
>> does not have a port 8?!
> 
> The vswitch process caches out "exploded" wildcard entries in the
> datapath for performance.  While these flows should have been limited to
> ports 1, 2, and 4, the flows themselves are not unexpected, since you
> allow traffic between these ports.  You can see that the IP protocol
> type is 1, which is ICMP.  These are just flow related to ping traffic,
> ("port" 8 is an echo request and "port" 0 is an echo reply).  This
> overloading of the transport ports for ICMP is part of the OpenFlow
> specification.  Does this all make sense?

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!

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:127.0.0.1
 [...]
  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->192.168.10.2 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->0.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->192.168.10.1 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 192.168.10.2 > 192.168.10.1: ICMP echo request, id
33077, seq 205, length 64
00:20:25.749499 IP 192.168.10.1 > 192.168.10.2: ICMP echo reply, id
33077, seq 205, length 64
00:20:26.749351 IP 192.168.10.2 > 192.168.10.1: ICMP echo request, id
33077, seq 206, length 64
00:20:26.749553 IP 192.168.10.1 > 192.168.10.2: ICMP echo reply, id
33077, seq 206, length 64

4 packets captured
4 packets received by filter
0 packets dropped by kernel

Best,

Andi

-- 
Andreas Wundsam
Technische Universität Berlin, Deutsche Telekom Laboratories
FG INET, Research Group Anja Feldmann

address: Sekr. TEL 16, FG INET, Ernst-Reuter-Platz 7, 10587 Berlin
e-mail: andi at net.t-labs.tu-berlin.de
web: http://www.net.t-labs.tu-berlin.de/people/andi.shtml




More information about the discuss mailing list