Hi John, Patch submitted.
https://gerrit.fd.io/r/c/vpp/+/25563 On 27. Feb 2020, at 00:46, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> wrote: Hi Nick, I agree the current bypass node for various tunnel types, including geneve, gtpu, vxlan, and vxlan_gbp all have this issue in its hash lookup using only incoming packet DIP without checking VRF. It is generally not an issue if bypass feature is enabled on all interfaces which are on the same VRF/IP-table corresponding to the same underlay network. If another underlay VRF is setup on other interfaces with bypass enabled, the bypass error as you described will happen. I have no objection if you like to submit a patch to fix this limitation. I hope you are willing to fix bypass node not just for gtpu but all 4 tunnel types. The code for all 4 bypass nodes are very similar except tunnel type check, validation, and node names, etc. Regards, John From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Nick Zavaritsky Sent: Wednesday, February 26, 2020 12:23 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] VRF-aware bypass nodes Hi, There are multiple kinds of bypass nodes in vpp. Bypass nodes intercept packets matching certain criteria and pass them directly to the protocol handler node. I am going to use GTPU as the illustrating example. Bypass node SHOULD intercept packets with destination IP matching a local address and UDP destination port equal to 2152. Bypass node MUST NOT intercept a packet if destination IP doesn’t match a local address. Otherwise enabling GTPU bypass would change the observable system behaviour. An address is local within a certain VRF. It’s possible that an address is local in one VRF but it’s not in another. But GTPU bypass node is not VRF aware. Image a vpp setup with 2 interfaces, associated with different VRF-s. The first interface address is 10.0.10.100, the other one — 192.168.0.7. Both have GTPU bypass enabled. Now GTPU bypass in the second interface will intercept packets sent to 10.0.10.100 (the first interface’s address), though it shouldn’t. This is a somewhat contrived example, but it looks like bypass node should be VRF-aware for correctness. Am I missing something? Would you be open to a patch making GTPU bypass VRF-aware? Best, Nick
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15644): https://lists.fd.io/g/vpp-dev/message/15644 Mute This Topic: https://lists.fd.io/mt/71569502/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
