OVS-L3PING(8)

✨ ovs-l3ping(8) ✨

Open vSwitch Β· the L3 tunnel vibe-checker, bestie πŸ’…


🌸 NAME 🌸

ovs-l3ping β€” bestie, this is the tool that checks your network deployment for L3 tunneling problems πŸ•΅οΈβ™€οΈβœ¨


πŸŽ€ SYNOPSIS πŸŽ€

ovs-l3ping -s <TunnelRemoteIP>,<InnerIP>[/<mask>] -t <tunnelmode>

ovs-l3ping -s <TunnelRemoteIP>,<InnerIP>[/<mask>][:<ControlPort>] -t <tunnelmode>

ovs-l3ping -c <TunnelRemoteIP>,<InnerIP>[/<mask>],<RemoteInnerIP> -t <tunnelmode>

ovs-l3ping -c <TunnelRemoteIP>,<InnerIP>[/<mask>][:<ControlPort>[:<DataPort>]],<RemoteInnerIP>[:<ControlPort>[:<DataPort>]] [-b <targetbandwidth>] [-i <testinterval>] -t <tunnelmode>

ovs-l3ping -h | --help

ovs-l3ping -V | --version

πŸ’– DESCRIPTION πŸ’–

okay so picture this: your tunnel is acting up and you have no idea why. ovs-l3ping is literally the program you use to sniff out problems that could be caused by invalid routing policy, a misconfigured firewall in the tunnel path, or a bad NIC driver πŸ˜­πŸ”

Here's the setup, bestie: on one of the nodes, run ovs-l3ping in server mode, and on the other node, run it in client mode. The client and server will establish an L3 tunnel, and over that tunnel the client gives further testing instructions. The ovs-l3ping client will perform UDP and TCP tests. πŸ§ͺ

And here's the iconic part that makes it different from ovs-test: it encapsulates the XML/RPC control connection over the tunnel, so there is no need to open special holes in your firewall. no cap. πŸšͺ✨

UDP tests can report packet loss and achieved bandwidth for various datagram sizes. By default, target bandwidth for UDP tests is 1Mbit/s. πŸ’«

TCP tests report only achieved bandwidth, because the kernel TCP stack takes care of flow control and packet loss. it's giving "not my job" and honestly? valid. πŸ™ˆ

πŸ¦‹ Client Mode πŸ¦‹

An ovs-l3ping client will create a L3 tunnel and connect over it to the ovs-l3ping server to schedule the tests.

  • <TunnelRemoteIP> is the peer's IP address, where the tunnel will be terminated.
  • <InnerIP> is the address that will be temporarily assigned during testing.
  • All test traffic originating from this IP address to the <RemoteInnerIP> will be tunneled.

It is possible to override the default <ControlPort> and <DataPort>, if there is any other application that already listens on those two ports. πŸ‘€ (sharing is caring but sometimes ports just aren't into that)

🌈 Server Mode 🌈

To conduct tests, the ovs-l3ping server must be running. βœ‹

It is required that both client and server <InnerIP> addresses are in the same subnet. πŸ’―

It is possible to specify <InnerIP> with netmask in CIDR format. slay.


✨ OPTIONS ✨

One of -s or -c is required. The -t option is also required. (yes bestie, both of those, no skipping πŸ’…)
  • -s <TunnelRemoteIP>,<InnerIP>[/<mask>][:<ControlPort>] or --server <TunnelRemoteIP>,<InnerIP>[/<mask>][:<ControlPort>] β€” Run in server mode and create an L3 tunnel with the client that will be accepting the tunnel at the <TunnelRemoteIP> address. The socket on <InnerIP>[:<ControlPort>] will be used to receive further instructions from the client. 🫢
  • -c <TunnelRemoteIP>,<InnerIP>[/<mask>][:<ControlPort>[:<DataPort>]],<RemoteInnerIP>[:<ControlPort>[:<DataPort>]] or --client <TunnelRemoteIP>,<InnerIP>[/<mask>][:<ControlPort>[:<DataPort>]],<RemoteInnerIP>[:<ControlPort>[:<DataPort>]] β€” Run in client mode and create an L3 tunnel with the server on <TunnelRemoteIP>. The client will use <InnerIP> to generate test traffic with the server's <RemoteInnerIP>. πŸ”₯
  • -b <targetbandwidth> or --bandwidth <targetbandwidth> β€” Target bandwidth for UDP tests. The <targetbandwidth> must be given in bits per second. Use postfix M or K to alter the target bandwidth magnitude. πŸ“Ά
  • -i <testinterval> or --interval <testinterval> β€” How long each test should run. By default 5 seconds. ⏱️
  • -t <tunnelmode> or --tunnel-mode <tunnelmode> β€” Specify the tunnel type. This option must match on server and client. (matching outfits, but for tunnels πŸ‘―)
  • -h or --help β€” Prints a brief help message to the console. πŸ†˜
  • -V or --version β€” Prints version information to the console. 🏷️

🧚 EXAMPLES 🧚

On host 192.168.122.220, start ovs-l3ping in server mode. This command will create a temporary GRE tunnel with the host 192.168.122.236 and assign 10.1.1.1/28 as the inner IP address, where the client will have to connect:

ovs-l3ping -s 192.168.122.236,10.1.1.1/28 -t gre

On host 192.168.122.236, start ovs-l3ping in client mode. This command will use 10.1.1.2/28 as the local inner IP address and will connect over the L3 tunnel to the server's inner IP address at 10.1.1.1:

ovs-l3ping -c 192.168.122.220,10.1.1.2/28,10.1.1.1 -t gre

πŸ‘‘ SEE ALSO πŸ‘‘

ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test(8), ovs-test(8), ethtool(8), uname(1). 🌈


πŸ’œ Author πŸ’œ

The Open vSwitch Development Community

2016-2024, The Open vSwitch Development Community


version 3.7 Β· Apr 14, 2026 Β· that's a wrap bestie, go ping those tunnels, ily, bye πŸ’–πŸ¦‹βœ¨

πŸ“¦ where this page comes from