b0b672c4 | 21-Jul-2023 |
Jiri Benc <jbenc@redhat.com> |
vxlan: fix GRO with VXLAN-GPE
In VXLAN-GPE, there may not be an Ethernet header following the VXLAN header. But in GRO, the vxlan driver calls eth_gro_receive unconditionally, which means the follow
vxlan: fix GRO with VXLAN-GPE
In VXLAN-GPE, there may not be an Ethernet header following the VXLAN header. But in GRO, the vxlan driver calls eth_gro_receive unconditionally, which means the following header is incorrectly parsed as Ethernet.
Introduce GPE specific GRO handling.
For better performance, do not check for GPE during GRO but rather install a different set of functions at setup time.
Fixes: e1e5314de08ba ("vxlan: implement GPE") Reported-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
17a0a644 | 21-Jul-2023 |
Jiri Benc <jbenc@redhat.com> |
vxlan: generalize vxlan_parse_gpe_hdr and remove unused args
The vxlan_parse_gpe_hdr function extracts the next protocol value from the GPE header and marks GPE bits as parsed.
In order to be used
vxlan: generalize vxlan_parse_gpe_hdr and remove unused args
The vxlan_parse_gpe_hdr function extracts the next protocol value from the GPE header and marks GPE bits as parsed.
In order to be used in the next patch, split the function into protocol extraction and bit marking. The bit marking is meaningful only in vxlan_rcv; move it directly there.
Rename the function to vxlan_parse_gpe_proto to reflect what it now does. Remove unused arguments skb and vxflags. Move the function earlier in the file to allow it to be called from more places in the next patch.
Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
08f876a7 | 15-Mar-2023 |
Ido Schimmel <idosch@nvidia.com> |
vxlan: Enable MDB support
Now that the VXLAN MDB control and data paths are in place we can expose the VXLAN MDB functionality to user space.
Set the VXLAN MDB net device operations to the appropri
vxlan: Enable MDB support
Now that the VXLAN MDB control and data paths are in place we can expose the VXLAN MDB functionality to user space.
Set the VXLAN MDB net device operations to the appropriate functions, thereby allowing the rtnetlink code to reach the VXLAN driver.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
0f83e69f | 15-Mar-2023 |
Ido Schimmel <idosch@nvidia.com> |
vxlan: Add MDB data path support
Integrate MDB support into the Tx path of the VXLAN driver, allowing it to selectively forward IP multicast traffic according to the matched MDB entry.
If MDB entri
vxlan: Add MDB data path support
Integrate MDB support into the Tx path of the VXLAN driver, allowing it to selectively forward IP multicast traffic according to the matched MDB entry.
If MDB entries are configured (i.e., 'VXLAN_F_MDB' is set) and the packet is an IP multicast packet, perform up to three different lookups according to the following priority:
1. For an (S, G) entry, using {Source VNI, Source IP, Destination IP}. 2. For a (*, G) entry, using {Source VNI, Destination IP}. 3. For the catchall MDB entry (0.0.0.0 or ::), using the source VNI.
The catchall MDB entry is similar to the catchall FDB entry (00:00:00:00:00:00) that is currently used to transmit BUM (broadcast, unknown unicast and multicast) traffic. However, unlike the catchall FDB entry, this entry is only used to transmit unregistered IP multicast traffic that is not link-local. Therefore, when configured, the catchall FDB entry will only transmit BULL (broadcast, unknown unicast, link-local multicast) traffic.
The catchall MDB entry is useful in deployments where inter-subnet multicast forwarding is used and not all the VTEPs in a tenant domain are members in all the broadcast domains. In such deployments it is advantageous to transmit BULL (broadcast, unknown unicast and link-local multicast) and unregistered IP multicast traffic on different tunnels. If the same tunnel was used, a VTEP only interested in IP multicast traffic would also pull all the BULL traffic and drop it as it is not a member in the originating broadcast domain [1].
If the packet did not match an MDB entry (or if the packet is not an IP multicast packet), return it to the Tx path, allowing it to be forwarded according to the FDB.
If the packet did match an MDB entry, forward it to the associated remote VTEPs. However, if the entry is a (*, G) entry and the associated remote is in INCLUDE mode, then skip over it as the source IP is not in its source list (otherwise the packet would have matched on an (S, G) entry). Similarly, if the associated remote is marked as BLOCKED (can only be set on (S, G) entries), then skip over it as well as the remote is in EXCLUDE mode and the source IP is in its source list.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-2.6
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
bc6c6b01 | 15-Mar-2023 |
Ido Schimmel <idosch@nvidia.com> |
vxlan: mdb: Add an internal flag to indicate MDB usage
Add an internal flag to indicate whether MDB entries are configured or not. Set the flag after installing the first MDB entry and clear it befo
vxlan: mdb: Add an internal flag to indicate MDB usage
Add an internal flag to indicate whether MDB entries are configured or not. Set the flag after installing the first MDB entry and clear it before deleting the last one.
The flag will be consulted by the data path which will only perform an MDB lookup if the flag is set, thereby keeping the MDB overhead to a minimum when the MDB is not used.
Another option would have been to use a static key, but it is global and not per-device, unlike the current approach.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
a3a48de5 | 15-Mar-2023 |
Ido Schimmel <idosch@nvidia.com> |
vxlan: mdb: Add MDB control path support
Implement MDB control path support, enabling the creation, deletion, replacement and dumping of MDB entries in a similar fashion to the bridge driver. Unlike
vxlan: mdb: Add MDB control path support
Implement MDB control path support, enabling the creation, deletion, replacement and dumping of MDB entries in a similar fashion to the bridge driver. Unlike the bridge driver, each entry stores a list of remote VTEPs to which matched packets need to be replicated to and not a list of bridge ports.
The motivating use case is the installation of MDB entries by a user space control plane in response to received EVPN routes. As such, only allow permanent MDB entries to be installed and do not implement snooping functionality, avoiding a lot of unnecessary complexity.
Since entries can only be modified by user space under RTNL, use RTNL as the write lock. Use RCU to ensure that MDB entries and remotes are not freed while being accessed from the data path during transmission.
In terms of uAPI, reuse the existing MDB netlink interface, but add a few new attributes to request and response messages:
* IP address of the destination VXLAN tunnel endpoint where the multicast receivers reside.
* UDP destination port number to use to connect to the remote VXLAN tunnel endpoint.
* VXLAN VNI Network Identifier to use to connect to the remote VXLAN tunnel endpoint. Required when Ingress Replication (IR) is used and the remote VTEP is not a member of originating broadcast domain (VLAN/VNI) [1].
* Source VNI Network Identifier the MDB entry belongs to. Used only when the VXLAN device is in external mode.
* Interface index of the outgoing interface to reach the remote VXLAN tunnel endpoint. This is required when the underlay destination IP is multicast (P2MP), as the multicast routing tables are not consulted.
All the new attributes are added under the 'MDBA_SET_ENTRY_ATTRS' nest which is strictly validated by the bridge driver, thereby automatically rejecting the new attributes.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-3.2.2
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
6ab271aa | 15-Mar-2023 |
Ido Schimmel <idosch@nvidia.com> |
vxlan: Expose vxlan_xmit_one()
Given a packet and a remote destination, the function will take care of encapsulating the packet and transmitting it to the destination.
Expose it so that it could be
vxlan: Expose vxlan_xmit_one()
Given a packet and a remote destination, the function will take care of encapsulating the packet and transmitting it to the destination.
Expose it so that it could be used in subsequent patches by the MDB code to transmit a packet to the remote destination(s) stored in the MDB entry.
It will allow us to keep the MDB code self-contained, not exposing its data structures to the rest of the VXLAN driver.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
e92695e5 | 05-May-2022 |
Alaa Mohamed <eng.alaamohamedsoliman.am@gmail.com> |
net: vxlan: Add extack support to vxlan_fdb_delete
This patch adds extack msg support to vxlan_fdb_delete and vxlan_fdb_parse. extack is used to propagate meaningful error msgs to the user of vxlan
net: vxlan: Add extack support to vxlan_fdb_delete
This patch adds extack msg support to vxlan_fdb_delete and vxlan_fdb_parse. extack is used to propagate meaningful error msgs to the user of vxlan fdb netlink api
Signed-off-by: Alaa Mohamed <eng.alaamohamedsoliman.am@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|