I am making some changes to OvS to suit a new packet processing stack. As part of the changes I wrote a netdev-provider that takes the packets from this packet processing stack and passes it to OvS, so that it can act as the control path. These packets are GRE encapsulated packets with outer eth and ip headers, a gre header and inner ip and tcp headers and are passed to the netdev datapath. How can I use ovs-ofctl to match the inner ip headers of my packets? For example, suppose that I want to add a rule that matches the src tcp port and sets the tunnel id to 1 for every packet with port src port 1234.
ovs-ofctl add-flow br0 "tcp_src=1234, actions=set_tunnel:1" This actually doesn't work and when I add some logging to the netdev datapath I have noticed that only the outer eth and ip headers for the flow are getting parsed, but the GRE tunneling is not being identified. All of the tunneling metadata is empty, the data in the inner ip header which I expected to populate the nw_src and nw_dst fields have the outer ip header info instead, and the tp_src and tp_dst fields are empty. I expected the netdev datapath to properly parse gre packets and fill the information of a flow properly so that we can add flow rules and actions based on this information. The end goal of what I am trying to do is to parse packet information and create a flow, match certain packets based on their inner ip headers and tunneling information, and send the packet back to the netdev-provider that I created. How do I make sure OvS parses and matches GRE packets coming from a netdev-provider's netdev_rxq_recv function? Furthermore, should I be adding a decapsulation action to these packets to strip the outer headers before attempting further matching and actions? I have noticed that there is a OVS_ACTION_ATTR_TUNNEL_POP action in ovs_action_attr, but I haven't found the equivalent way to trigger this action using ovs-ofctl. For example: ovs-ofctl add-flow br0 "tcp_src=1234, actions=tnl_pop" returns unknown action "tnl_pop". Cheers Notes: * I have added a GRE port ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.11.20 options:key=1 * I believe the GRE packets are properly formed. When I don't use OvS and use my packet processing stack to send GRE packets to a Linux server with a tunnel setup I get replies back and things function normally.
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
