mbox series

[ovs-dev,0/6] Implement MTU Path Discovery for multichassis ports

Message ID 20230503011239.2100488-1-ihrachys@redhat.com
Headers show
Series Implement MTU Path Discovery for multichassis ports | expand

Message

Ihar Hrachyshka May 3, 2023, 1:12 a.m. UTC 
This series fixes a non-optimal behavior with some multichassis ports.

Specifically,

- when a multichassis port belongs to a switch that also has a localnet
  port,
- because ingress and egress traffic for the port is funnelled through
  tunnels to guarantee delivery of packets to all chassis that host the
  port,
- because tunnels add overhead to each funnelled packet,
- leaving less space for actual packets,

... the effective MTU of the path for multichassis ports is reduced by
the size that takes the tunnel to wrap a packet around. (This depends on
the type of tunnel, also on IP version of the tunnel.)

When this happens, the port and its peers are not notified about the
reduced MTU for the path to the port, effectively blackholing some of
the larger packets.

This patch series makes OVN detect these scenarios and handle them as
follows:

- for all multichassis ports, 4 flows are added - for inport and
  outport matches - to detect "too-big" IP packets;
- for all "too-big" packets, 2 flows are added to produce a ICMP
  Fragmentation Needed (for IPv4) or Too Big (for IPv6) packet and
  return it to the offending sender.

The proposed implementation is isolated in ovn-controller. An
alternative would be to implement flows producing ICMP errors via the
existing Logical_Flow action icmp4_error, as is done for router ports.
In this case, the 4 flows that detect "too-big" packets would still have
to reside in ovn-controller because of limitations of the current OVN
port model, namely lack of `mtu` as an attribute of OVN logical port.

Caveats: this works for IP traffic only. The party receiving the ICMP
error should handle it by temporarily lowering the MTU used to reach the
port. Behavior may depend on protocol implementation of the offending
peer as well as its networking stack configuration.

This patch series was successfully tested with Linux kernel 6.0.8.

This patch series is designed to simplify backporting process. It is
split in logical pieces to simplify cherry-picking. I consider the
original behavior described at the start of the cover letter a bug and
worth a backport.

Ihar Hrachyshka (6):
  Track ip version of tunnel in chassis_tunnel struct
  Track interface MTU in if-status-mgr
  if-status: track interfaces for additional chassis
  Add new egress tables to accommodate for too-big packets handling
  Implement MTU Path Discovery for multichassis ports
  Update multichassis physical flows on interface MTU update

 controller/binding.c        |  48 +--
 controller/binding.h        |   4 +
 controller/if-status.c      |  44 ++-
 controller/if-status.h      |  11 +-
 controller/lflow.c          |   4 +-
 controller/lflow.h          |  49 +--
 controller/local_data.c     |   2 +
 controller/local_data.h     |   1 +
 controller/ovn-controller.c |  76 +++++
 controller/ovsport.c        |   9 +
 controller/ovsport.h        |   2 +
 controller/physical.c       | 369 +++++++++++++++++++++--
 controller/physical.h       |   2 +
 controller/pinctrl.c        |   8 +-
 lib/ovn-util.h              |  11 +
 ovn-architecture.7.xml      |  76 ++---
 tests/ovn-controller.at     | 174 +++++------
 tests/ovn.at                | 586 ++++++++++++++++++++++++++++--------
 18 files changed, 1137 insertions(+), 339 deletions(-)