[ovs-discuss] Matching on tun_id in a flow rule
keith.holleman at gmail.com
Sun Apr 17 16:43:29 UTC 2016
I have GRE traffic transiting an OVS switch, in other words the tunnel
source and destination is not in this OVS instance. I had wanted to match
on the GRE key ID in this to apply some very specific policy to it. The
transit traffic looks like this:
:~# tcpdump proto gre -ne
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:27:04.742520 dc:39:79:80:29:48 > dc:39:79:80:29:02, ethertype IPv4
(0x0800), length 102: 10.0.12.254 > 10.0.13.1: GREv0, key=0x3f3, proto TEB
(0x6558), length 68: 00:0c:29:45:34:a7 > dc:39:79:80:29:33, ethertype ARP
(0x0806), length 60: Request who-has 10.11.169.25 tell 10.11.1.239, length
And I created these rules:
:~# ovs-ofctl dump-flows br0 table=5 | grep nw_proto=47
cookie=0x1234, duration=90.802s, table=5, n_packets=0, n_bytes=0,
cookie=0x3ea0000000b, duration=43112.786s, table=5, n_packets=395700,
I was expecting the first flow to see all the traffic but it sees none.
After reading more of the documentation and looking at and experimenting
with tun_src and tun_dst usage, I think I know what the problem is. The
tun_* fields can only be used if OVS is aware of the GRE tunnel and has
terminated the GRE tunnel and is looking at packets after the GRE
decapsulation has occurred. Or put another way, the GRE tunnel must be the
incoming port to use those fields in the match criteria.
I couldn't find any documentation that clearly stated that although in
hindsight, it could be considered obvious. But I also think my usage and
assumptions aren't completely insane either. Is my current understanding
correct? Is there any other way to match on a GRE key for GRE traffic
transiting an OVS switch?
Thanks in advance for the time.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss