On 7/6/23 11:51, mstolet--- via discuss wrote:
> So I wrote two custom netdev providers, one of them receives GRE encapsulated
> packets and passes them to OvS. These encapsulated packets have an outer
> ethernet header and ip header, a gre header and an inner ip and tcp header. I
> want OvS to create flow rules that match different fields in the inner and
> outer headers and perform different actions based on this and pass the packet
> to my second custom netdev provider. For example, suppose my custom netdev
> providers are identified by in_port=2 and in_port=3. I might want to add the
> following flow:
>
> ovs-ofctl add-flow br0 "table=0, in_port=2, ip, nw_dst=10.0.0.1,
> tun_src=192.168.10.5, actions=set_tunnel:3, mod_nw_src:10.0.0.5, output:3”
>
> So basically in this flow I want every packet coming from port 2 and with
> inner Ip address 10.0.0.1 and outer ip address 192.168.10.5 to be sent to
> port 3, have the gre key set to 3 and the inner ip address to be set to
> 10.0.0.5.
Hi. The main issue here is that OpenFlow and OVS do not provide
a way to match on inner headers or modify them with actions.
'tun_*' fields are only populated from a tunnel header after the
packet is decapsulated. set_tunnel action only sets a tunnel ID
for a subsequent output to a tunnel port for encapsulation.
So, basically, you need a tunnel port that will decapsulate packets,
then you may match on a header of the decapsulated packet and the
tunnel metadata. Then you should be able to send this packet to
a tunnel port to encapsulate it back.
Alternative will be to add new OpenFlow extensions that will be
able to look inside of the packet without decapsulating it. It
will be a bit more work though. You may look at commit
3d2fbd70bda5 ("userspace: Add support for NSH MD1 match fields")
for all the places you'll need to change.
>
> I haven’t been able to get these actions executed on my packets, even a
> fairly simple rule such as:
>
> ovs-ofctl add-flow br0 "table=0, in_port=2, actions=set_tunnel:3 ,output:3”
>
> where I want every packet coming from my custom netdev provider to get its
> gre key changed and the output is sent to the other port running my other
> custom netdev provider. I have noticed that if I don’t have actions messing
> with tunneling information and just have an output action, the packet gets
> properly redirect to port 3, so I imagine I am missing some essential
> tunneling configuration or something of the sort on my custom netdev
> provider. So what are the necessary things I need to add to a custom netdev
> provider that receives encapsulated packets if I want it to be able to match
> encapsulated GRE packets? I have looked at some of the netdev-vport and
> netdev-dpdk for vhost code, to see how this is done, but I can’t identify the
> missing information that leads my packets to get a drop action when I have
> anything related to tunneling information in add-flow.
>
> For reference, this is how I set up my OvS bridge:
>
> ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
>
> ovs-vsctl add-port br0 gre1 -- set interface gre1 type=gre
> options:remote_ip=flow options:local_ip=flow options:key=flow
>
> ovs-vsctl add-port br0 p2 -- set Interface p2 type=customnetdeva of_port=2
>
> ovs-vsctl add-port br0 p3 -- set Interface p3 type=customnetdevb of_port=3
>
>
> I have also tried creating my GRE tunnel with
>
> ovs-vsctl add-port br0 gre1 -- set interface gre1 type=gre
> options:remote_ip=192.168.10.6 options:key=3
>
> but this also didn’t change things and the chosen action for the packets was
> to drop them instead, of executing my custom actions.
You can find an example of a tunnel configuration with a userspace
datapath here:
https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/
Best regards, Ilya Maximets.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
