Re: [ovs-discuss] Encapsulate VXLAN and then process other flows
On 1/25/24 10:42, Lim, Derrick via discuss wrote: > Hey all, > > Is there a way I can encapsulate a packet with VXLAN, and then resubmit > it through OVS again to run other flow actions based on this encapsulated > packet? > > Currently, I have a OVS-DPDK setup where in the final step, before a packet > leaves the host, the group action is used to pick between multiple physical > ports, and then rewrite the mac address (mod_dl_dst) to that of the > destination's, as well as apply the appropriate vlan tag (mod_vlan_vid). > > I would like the encapsulate action to take place before the step mentioned > above. I created a tunnel port (eg. vxlan0). But if I set the action to this > port, the packet basically leaves OVS and I can't resubmit it. > > In the userspace tunneling example, two bridges are used so that information > from the kernel can be used for routing and ARP resolution. Is there a way I > can populate these fields through various flow actions if I already know what > they should be without going through the kernel? Or is going through the > kernel > absolutely required to create the data structure for encapsulation? The output to a tunnel is an 'output' action, i.e. the packet always leaves the bridge. And so, it requires routing after encapsulation in order to identify where it should go next. For routing we need IP addresses and a routing table. This information is normally synced from the kernel. You can add static routes via ovs-appctl ovs/route/add, but you still need IP addresses configured on bridges. Normally the problem of applying actions after encapsulation is solved by having a tunnel interface in one bridge (br-int) and the egress interfaces in the other bridge (br-phy). The br-phy should have an IP address from the tunnel subnet, so after encapsulation the packet is getting routed to br-phy. In br-phy the packet can be matched with OF rules and actions can be executed before sending it to the egress interface. Best regards, Ilya Maximets. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] GTP-U: in RX inner packets with TTL < 64 or > 79 are not recognised as IP packets
Hello. GTP-U tunnel packet containing inner packets with TTL < 63 or > 79 are not recognised as IP packets, due to wrong parsing. Packets are then dropped as “receive tunnel port is not found” (see logs). The start of the inner IP header is wrong because gtpu_hlen includes also 8 bytes from the tunnel UDP header. ip = ALIGNED_CAST(struct ip_header *, (char *)gtph + gtpu_hlen); and so IP_VER(ip->ip_ihl_ver) is actually the TTL byte. https://github.com/openvswitch/ovs/blob/20a7654d240f2af5da73a32c1791442e6aac0101/lib/netdev-native-tnl.c#L57 https://github.com/openvswitch/ovs/blob/20a7654d240f2af5da73a32c1791442e6aac0101/lib/netdev-native-tnl.c#L729-L741 2024-01-23T10:59:14.407Z|00068|native_tnl|WARN|GTP-U: Receive non-IP packet. 2024-01-23T10:59:14.407Z|00069|dpif_netdev|DBG|ovs-netdev: miss upcall: recirc_id(0),dp_hash(0),skb_priority(0),tunnel(tun_id=0x1388,src=198.18.0.1,dst=198.18.0.2,ttl=64,tp_src=2152,tp_dst=2152,gtpu(flags=0x30,msgtype=255),flags(csum|key)),in_port(4),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),packet_type(ns=0,id=0),eth(src=40:00:3d:01:5e:97,dst=45:00:00:54:bf:0e),eth_type(0x1000) vlan_tci=0x,dl_src=40:00:3d:01:5e:97,dl_dst=45:00:00:54:bf:0e,dl_type=0x1000 2024-01-23T10:59:14.408Z|00070|tunnel|WARN|receive tunnel port not found (tun_src=198.18.0.1,tun_dst=198.18.0.2,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_erspan_ver=0,gtpu_flags=0x30,gtpu_msgtype=255,tun_flags=csum,in_port=4,vlan_tci=0x,dl_src=40:00:3d:01:5e:97,dl_dst=45:00:00:54:bf:0e,dl_type=0x1000) Git commit: cc670e741170972de5da4cfad294991468954df BR Michele ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Encapsulate VXLAN and then process other flows
Hey all, Is there a way I can encapsulate a packet with VXLAN, and then resubmit it through OVS again to run other flow actions based on this encapsulated packet? Currently, I have a OVS-DPDK setup where in the final step, before a packet leaves the host, the group action is used to pick between multiple physical ports, and then rewrite the mac address (mod_dl_dst) to that of the destination's, as well as apply the appropriate vlan tag (mod_vlan_vid). I would like the encapsulate action to take place before the step mentioned above. I created a tunnel port (eg. vxlan0). But if I set the action to this port, the packet basically leaves OVS and I can't resubmit it. In the userspace tunneling example, two bridges are used so that information from the kernel can be used for routing and ARP resolution. Is there a way I can populate these fields through various flow actions if I already know what they should be without going through the kernel? Or is going through the kernel absolutely required to create the data structure for encapsulation? Thank you, Derrick ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
