1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
.\"-
.\" Copyright (c) 2008 The FreeBSD Foundation
.\"
.\" This software was developed by CK Software GmbH under sponsorship
.\" from the FreeBSD Foundation.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.Dd January 30, 2026
.Dt EPAIR 4
.Os
.Sh NAME
.Nm epair
.Nd A pair of virtual back-to-back connected Ethernet interfaces
.Sh SYNOPSIS
To compile this driver into the kernel,
place the following line in your
kernel configuration file:
.Bd -ragged -offset indent
.Cd "device epair"
.Ed
.Pp
Alternatively, to load the driver as a
module at boot time, place the following line in
.Xr loader.conf 5 :
.Bd -literal -offset indent
if_epair_load="YES"
.Ed
.Sh DESCRIPTION
The
.Nm
is a pair of Ethernet-like software interfaces,
which are connected back-to-back with a virtual cross-over cable.
.Pp
Each
.Nm
interface pair is created at runtime using interface cloning.
This is most easily done with the
.Xr ifconfig 8
.Cm create
command or using the
.Va cloned_interfaces
variable in
.Xr rc.conf 5 .
While for cloning you only give either
.Pa epair
or
.Pa epair<n>
the
.Nm
pair will be named like
.Pa epair<n>[ab] .
This means the names of the first
.Nm
interfaces will be
.Pa epair0a
and
.Pa epair0b .
.Pp
Like any other Ethernet interface, an
.Nm
needs to have a network address.
If the tunable
.Va net.link.epair.ether_gen_addr Ns
=0, each
.Nm
will be assigned a random locally administered address,
that is only guaranteed to be unique within one network stack.
The tunable
.Va net.link.epair.ether_gen_addr Ns
=1 will generate a stable MAC address with
.Fx
OUI using
.Xr ether_gen_addr 9 .
This tunable defaults to 1 in
.Fx 15.0 and might be removed in
.Fx 16.0 .
To change the default addresses one may use the SIOCSIFADDR
.Xr ioctl 2 or
.Xr ifconfig 8 utility.
.Pp
The basic intent is to provide connectivity between two virtual
network stack instances.
When connected to an
.Xr if_bridge 4 ,
one end of the interface pair can also be part of another (virtual) LAN.
As with any other Ethernet interface,
.Nm epair
can have a
.Xr vlan 4
configured on top of it.
.Pp
The
.Nm
has RXCSUM and RXCSUM6 enabled because it may receive a packet where the
checksum has already been validated by a physical interface.
.Pp
The
.Nm
supports TXCSUM and TXCSUM6 for TCP and UDP, but only by forwarding the order
to compute the checksum.
Thus, when using an
.Nm
interface, a TCP or UDP sender can offload checksum computation
to a physical interface.
Note that, in case the packet does not leave the host, the checksum is
unnecessary and will be ignored if offloaded.
Such packets contain an incorrect checksum, since it is not computed yet.
TXCSUM and TXCSUM6 are synchronized between the
.Nm
interface pair (i.e., enabling/disabling the capability on one end
enables/disables it on the other end).
In case one end is in a bridge and the bridge disabled TXCSUM or TXCSUM6,
this avoids a sender to send packets with checksum offloading into the
bridge by using the other end.
.Pp
The
.Nm
supports VLAN_HWTAGGING without actually adding a VLAN tag.
The sending
.Nm
end just forwards the offloading information to the other end.
The receiving
.Nm
end leaves the offloading information set to pretend that there was a VLAN tag
in the Ethernet header, which has been removed already.
To avoid a situation where the receiving
.Nm
end has VLAN_HWTAGGING disabled, this capability is synchronized between the
.Nm
interface pair (i.e., enabling/disabling the capability on one end
enables/disables it on the other end).
.Sh SEE ALSO
.Xr ioctl 2 ,
.Xr altq 4 ,
.Xr bpf 4 ,
.Xr if_bridge 4 ,
.Xr vlan 4 ,
.Xr loader.conf 5 ,
.Xr rc.conf 5 ,
.Xr ifconfig 8
.Sh HISTORY
The
.Nm
interface first appeared in
.Fx 8.0 .
.Sh AUTHORS
The
.Nm
interface was written by
.An Bjoern A. Zeeb, CK Software GmbH,
under sponsorship from the FreeBSD Foundation.
|
