XNB(4)

✨ XNB β€” Xen Paravirtualized Backend Ethernet Driver ✨

okay bestie, welcome to the XNB(4) page, straight outta the Kernel Interfaces Manual πŸŽ€ this is the whole thing, no skips, no cap πŸ’–


🌸 NAME 🌸

xnb β€” the Xen Paravirtualized Backend Ethernet Driver. say hi to the back half of your network connection, she's iconic πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

so if you wanna compile this driver into the kernel (not as a module, we're going full-time here), you gotta put these lines in your kernel configuration file:

options XENHVM
device xenpci

that's it. that's the whole ritual πŸ•―οΈβœ¨


πŸ’œ DESCRIPTION πŸ’œ

The xnb driver provides the back half of a paravirtualized xen(4) network connection. fr fr, it's giving duo energy.

So here's the vibe: the netback and netfront drivers appear to their respective operating systems as Ethernet devices linked by a crossover cable. like, imagine two ethernet ports and one lil cable between them, except it's all fake and in software πŸͺ„

Typically, xnb will run on Domain 0 and the netfront driver will run on a guest domain. However β€” plot twist β€” it is also possible to run xnb on a guest domain. she contains multitudes πŸ’…

It may be bridged or routed to provide the netfront domain access to other guest domains or to a physical network. networking queen behavior.

In most respects, the xnb device appears to the OS as any other Ethernet device. It can be configured at runtime entirely with ifconfig(8). In particular, it supports:

  • MAC changing 🎭
  • arbitrary MTU sizes πŸ“
  • checksum offload for IP, UDP, and TCP for both receive and transmit ✨
  • and TSO πŸ”₯

However, bestie, see β€œCAVEATS” before enabling txcsum, rxcsum, or tso. that's a read-before-you-leap situation, trust πŸ™ˆ


🌈 SYSCTL VARIABLES 🌈

The following read-only variables are available via sysctl(8). read-only means look, don't touch 🫢

  • dev.xnb.%d.dump_rings β€” Displays information about the ring buffers used to pass requests between the netfront and netback. Mostly useful for debugging, but can also be used to get traffic statistics. lowkey a lil two-for-one deal πŸŽ€
  • dev.xnb.%d.unit_test_results β€” Runs a builtin suite of unit tests and displays the results. Does not affect the operation of the driver in any way, promise. Note that the test suite simulates error conditions; this will result in error messages being printed to the system log. not me reading my own tests and getting scared 😭 those errors are on purpose bestie, breathe.

⭐ SEE ALSO ⭐

the whole friend group πŸ’– go say hi.


πŸ‘‘ HISTORY πŸ‘‘

The xnb device driver first appeared in FreeBSD 10.0. a true 10.0 era legend, we love a debut 🌟


πŸ’– AUTHORS πŸ’–

The xnb driver was written by Alan Somers <asomers@FreeBSD.org> and John Suykerbuyk. absolute icons, we thank them for their service πŸ«‘πŸ’


🚨 CAVEATS 🚨

okay this is the serious part, sit down and put your drink away bestie πŸ“

Packets sent through Xennet pass over shared memory, so the protocol includes no form of link-layer checksum or CRC. none. zero. nada. πŸ’€

Furthermore, Xennet drivers always report to their hosts that they support receive and transmit checksum offloading. They "offload" the checksum calculation by simply skipping it. the audacity 😭

That works fine for packets that are exchanged between two domains on the same machine. cool cool cool. However, when a Xennet interface is bridged to a physical interface, a correct checksum must be attached to any packets bound for that physical interface. mandatory. no exceptions.

Currently, FreeBSD lacks any mechanism for an Ethernet device to inform the OS that newly received packets are valid even though their checksums are not. So if the netfront driver is configured to offload checksum calculations, it will pass non-checksumed packets to xnb, which must then calculate the checksum in software before passing the packet to the OS. so xnb is doing the homework nobody else wanted to do 🫠

For this reason, it is recommended that if xnb is bridged to a physical interface, then transmit checksum offloading should be disabled on the netfront. The Xennet protocol does not have any mechanism for the netback to request the netfront to do this β€” the operator must do it manually. no autopilot for this one, you're the pilot πŸ§‘β€βœˆοΈβœ¨


πŸ› BUGS πŸ›

The xnb driver does not properly checksum UDP datagrams that span more than one Ethernet frame. Nor does it correctly checksum IPv6 packets. yikes, we know, we know πŸ˜”

To workaround that bug: disable transmit checksum offloading on the netfront driver. that's the move. do that.


and that's the whole page, bestie!! every flag, every caveat, every bug, all of it, no skips πŸ’œ

cute lil sign-off: this page ships from Debian, dated June 6, 2014 β€” so if you're reading this, know that the XNB(4) manual has been serving looks since way back πŸŽ€βœ¨

take care of your ring buffers and your friends πŸ¦‹πŸ’– mwah!

πŸ“¦ where this page comes from