1. 18 1月, 2019 6 次提交
  2. 21 12月, 2018 1 次提交
  3. 19 12月, 2018 3 次提交
    • P
      vxlan: changelink: Fix handling of default remotes · ce5e098f
      Petr Machata 提交于
      Default remotes are stored as FDB entries with an Ethernet address of
      00:00:00:00:00:00. When a request is made to change a remote address of
      a VXLAN device, vxlan_changelink() first deletes the existing default
      remote, and then creates a new FDB entry.
      
      This works well as long as the list of default remotes matches exactly
      the configuration of a VXLAN remote address. Thus when the VXLAN device
      has a remote of X, there should be exactly one default remote FDB entry
      X. If the VXLAN device has no remote address, there should be no such
      entry.
      
      Besides using "ip link set", it is possible to manipulate the list of
      default remotes by using the "bridge fdb". It is therefore easy to break
      the above condition. Under such circumstances, the __vxlan_fdb_delete()
      call doesn't delete the FDB entry itself, but just one remote. The
      following vxlan_fdb_create() then creates a new FDB entry, leading to a
      situation where two entries exist for the address 00:00:00:00:00:00,
      each with a different subset of default remotes.
      
      An even more obvious breakage rooted in the same cause can be observed
      when a remote address is configured for a VXLAN device that did not have
      one before. In that case vxlan_changelink() doesn't remove any remote,
      and just creates a new FDB entry for the new address:
      
      $ ip link add name vx up type vxlan id 2000 dstport 4789
      $ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.20 self permanent
      $ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.30 self permanent
      $ ip link set dev vx type vxlan remote 192.0.2.30
      $ bridge fdb sh dev vx | grep 00:00:00:00:00:00
      00:00:00:00:00:00 dst 192.0.2.30 self permanent <- new entry, 1 rdst
      00:00:00:00:00:00 dst 192.0.2.20 self permanent <- orig. entry, 2 rdsts
      00:00:00:00:00:00 dst 192.0.2.30 self permanent
      
      To fix this, instead of calling vxlan_fdb_create() directly, defer to
      vxlan_fdb_update(). That has logic to handle the duplicates properly.
      Additionally, it also handles notifications, so drop that call from
      changelink as well.
      
      Fixes: 0241b836 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce5e098f
    • P
      vxlan: Fix error path in __vxlan_dev_create() · 6db92468
      Petr Machata 提交于
      When a failure occurs in rtnl_configure_link(), the current code
      calls unregister_netdevice() to roll back the earlier call to
      register_netdevice(), and jumps to errout, which calls
      vxlan_fdb_destroy().
      
      However unregister_netdevice() calls transitively ndo_uninit, which is
      vxlan_uninit(), and that already takes care of deleting the default FDB
      entry by calling vxlan_fdb_delete_default(). Since the entry added
      earlier in __vxlan_dev_create() is exactly the default entry, the
      cleanup code in the errout block always leads to double free and thus a
      panic.
      
      Besides, since vxlan_fdb_delete_default() always destroys the FDB entry
      with notification enabled, the deletion of the default entry is notified
      even before the addition was notified.
      
      Instead, move the unregister_netdevice() call after the manual destroy,
      which solves both problems.
      
      Fixes: 0241b836 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6db92468
    • P
      vxlan: Unmark offloaded bit on replaced FDB entries · 6ad0b5a4
      Petr Machata 提交于
      When rdst of an offloaded FDB entry is replaced, it certainly isn't
      offloaded anymore. Drivers are notified about such replacements, and can
      re-mark the entry as offloaded again if they so wish. However until a
      driver does so explicitly, assume a replaced FDB entry is not offloaded.
      
      Note that replaces coming via vxlan_fdb_external_learn_add() are always
      immediately followed by an explicit offload marking.
      
      Fixes: 0efe1173 ("vxlan: Support marking RDSTs as offloaded")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ad0b5a4
  4. 17 12月, 2018 1 次提交
  5. 13 12月, 2018 1 次提交
  6. 08 12月, 2018 3 次提交
  7. 04 12月, 2018 1 次提交
    • A
      vxlan: add support for underlay in non-default VRF · aab8cc36
      Alexis Bauvin 提交于
      Creating a VXLAN device with is underlay in the non-default VRF makes
      egress route lookup fail or incorrect since it will resolve in the
      default VRF, and ingress fail because the socket listens in the default
      VRF.
      
      This patch binds the underlying UDP tunnel socket to the l3mdev of the
      lower device of the VXLAN device. This will listen in the proper VRF and
      output traffic from said l3mdev, matching l3mdev routing rules and
      looking up the correct routing table.
      
      When the VXLAN device does not have a lower device, or the lower device
      is in the default VRF, the socket will not be bound to any interface,
      keeping the previous behaviour.
      
      The underlay l3mdev is deduced from the VXLAN lower device
      (IFLA_VXLAN_LINK).
      
      +----------+                         +---------+
      |          |                         |         |
      | vrf-blue |                         | vrf-red |
      |          |                         |         |
      +----+-----+                         +----+----+
           |                                    |
           |                                    |
      +----+-----+                         +----+----+
      |          |                         |         |
      | br-blue  |                         | br-red  |
      |          |                         |         |
      +----+-----+                         +---+-+---+
           |                                   | |
           |                             +-----+ +-----+
           |                             |             |
      +----+-----+                +------+----+   +----+----+
      |          |  lower device  |           |   |         |
      |   eth0   | <- - - - - - - | vxlan-red |   | tap-red | (... more taps)
      |          |                |           |   |         |
      +----------+                +-----------+   +---------+
      Signed-off-by: NAlexis Bauvin <abauvin@scaleway.com>
      Reviewed-by: NAmine Kherbouche <akherbouche@scaleway.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NAmine Kherbouche <akherbouche@scaleway.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aab8cc36
  8. 22 11月, 2018 6 次提交
  9. 09 11月, 2018 2 次提交
    • S
      vxlan: Allow configuration of DF behaviour · b4d30697
      Stefano Brivio 提交于
      Allow users to set the IPv4 DF bit in outgoing packets, or to inherit its
      value from the IPv4 inner header. If the encapsulated protocol is IPv6 and
      DF is configured to be inherited, always set it.
      
      For IPv4, inheriting DF from the inner header was probably intended from
      the very beginning judging by the comment to vxlan_xmit(), but it wasn't
      actually implemented -- also because it would have done more harm than
      good, without handling for ICMP Fragmentation Needed messages.
      
      According to RFC 7348, "Path MTU discovery MAY be used". An expired RFC
      draft, draft-saum-nvo3-pmtud-over-vxlan-05, whose purpose was to describe
      PMTUD implementation, says that "is a MUST that Vxlan gateways [...]
      SHOULD set the DF-bit [...]", whatever that means.
      
      Given this background, the only sane option is probably to let the user
      decide, and keep the current behaviour as default.
      
      This only applies to non-lwt tunnels: if an external control plane is
      used, tunnel key will still control the DF flag.
      
      v2:
      - DF behaviour configuration only applies for non-lwt tunnels, move DF
        setting to if (!info) block in vxlan_xmit_one() (Stephen Hemminger)
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4d30697
    • S
      vxlan: ICMP error lookup handler · c3a43b9f
      Stefano Brivio 提交于
      Export an encap_err_lookup() operation to match an ICMP error against a
      valid VNI.
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3a43b9f
  10. 07 11月, 2018 1 次提交
  11. 18 10月, 2018 7 次提交
  12. 16 10月, 2018 1 次提交
  13. 27 9月, 2018 1 次提交
  14. 30 8月, 2018 1 次提交
  15. 23 7月, 2018 3 次提交
  16. 07 7月, 2018 2 次提交