В предыдущем примере мы получили аналог стандартного «bridge_load=»YES»". На вид все кажется сложнее, но возможности netgraph значительно шире.

Например, попробуйте в стандартном случае добавить (используя net.link.ether.bridge.config) третий Ethernet интерфейс или соединить удаленные сети в одну виртуальную, и можно столкнуться с кучей проблем. Может быть даже придется прибегнуть к построению целой схемы использования виртуальных интерфейсов, VPN сетей и прочее.
При использовании netgraph для подключения третьего Ethernet достаточно добавить несколько строчек, взяв за образец подключение le1 в нашем примере. Если же необходимо подключить удаленную сеть в единый виртуальный свич, то порядок чуть отличается. Как раз в этом случае применение netgraph уже не покажется таким сложным (возможно, несколько запутанным, но это только на первый взгляд).
Настроим узел ksocket (kernel socket), способный оперировать UDP туннелями, и подключим его к созданному ранее узлу bnet0 (модуль ядра ng_ksocket в этом случае стартует автоматически). Имя хука должно быть вида «family/type/proto» (значения параметров доступны в socket(2)):

# ngctl mkpeer bnet0: ksocket link4 inet/dgram/udp

Отправляем сообщение узлу bnet0:link4 (к которому подключен ksocket), чтобы он создал сокет, куда будут поступать данные с внешнего IP-адреса (пусть адрес будет 1.2.3.4, порт выберем произвольный выше 1024):

# ngctl msg bnet0:link4 bind inet/1.2.3.4:1111

На другом сервере повторяем эти настройки, только указываем свой IP-адрес (имена могут быть другими):

server2# ngctl msg bnet0:link0 bind inet/2.3.4.5:2222

И теперь подключаемся к удаленному сокету:

# ngctl msg bnet0:link4 connect inet/2.3.4.5:2222
server2# ngctl msg bnet0:link0 connect inet/1.2.3.4:1111

Теперь локальные и удаленная сеть соединены в одну при помощи виртуального свича, причем без использования VPN.