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.
r...@loadgen134:~# ovs-dpctl show br_out
dp4:
[...]
port 3: vif10.2
[...]
r...@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
[...]
r...@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!]
r...@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
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.
--Justin
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
