Свич имеет достоинство - ему не нужны ip-адреса. Однако, если вы хотите уметь к нему досуп, скажем, по ssh, а не только с консоли - можно назначить один ip-адрес на один из интерфейсов, что мы и сделаем.
Благодаря возможностям ipfw и dummynet вы сможете также ограничивать трафик, проходящий через мост.

Конфигурация ядра.
Допустим, уже имеется машина с двумя сетевыми картами. Мы использовали две 3COM 3C905B-TX.
Добавим необходимые параметры в конфиг ядра:
options BRIDGE
# Включим поддержку firewall
options IPFIREWALL
# для того, чтобы добавить возможность firewall вести логи добавим параметр:
options IPFIREWALL_VERBOSE
# ограничим число пакетов, о которых ядро будет сообщать:
options IPFIREWALL_VERBOSE_LIMIT=10
# Добавим еще парочку нужных параметров
ICMP_BANDLIM включает ограничение полосы для ответов icmp error Поскольку мы дадим мосту 1 ip-адрес, этот параметр в
некоторых случаях помогает от D.O.S. атак.
options ICMP_BANDLIM
#Добавим также параметр, который заблокирует перезагрузку системы при нажатии Ctrl+Alt+Del
options SC_DISABLE_REBOOT

3. Конфигурационные файлы.
Прежде всего необходимо добавить параметр
firewall_enable="YES".
Параметр
firewall_script="/etc/rc.firewall"
укажет, какой скрипт будет запускаться для активизации правил firewall.
Мы создадим файл ipfw.rules со своими собственными правилами, посему поставим в rc.conf
firewall_type="/etc/ipfw.rules"
Также необходим параметр
firewall_quiet
Если его поставить в YES, то при загрузке будет отключен вывод на экран правил firewall. Однако для начала лучше ему дать значение NO, чтобы видеть активируемые правила при загрузке. Парметр
firewall_logging
установим в YES для того, чтобы велись логи. Поскольку у нас машина с двумя сетевыми картами и чтобы она вдруг не заработала как маршрутизатор поставим
gateway_enable="NO"

4. Настройка правил для Firewall.
Создадим и отредактируем файл
/etc/ipfw.rules, который мы указали в параметрах в rc.conf.
Пусть у нас есть 2 интерфейса - xl0 и xl1. Для свичей приемлимым решением (а иногда и необходимым) является разрешение любого трафика на одном из интерфейсов и фильтрация входящего и исходящего на другом. Так и поступим - разрешим любой трафик на интерфейсе xl1, а фильтровать будем входящий на xl0.
При работе свича есть еще одна особенность. Дело в том, что для корректной работы ip протокола необходимо использование протокола ARP. Если пакеты этого протокола не будут проходит через свич, то станции по разные стороны свича не смогут передавать друг другу пакеты, т.к. не будет выполняться преобразование ip-адресов в mac-адреса сетевых карт. ipfw имеет возможность ограничивать ethernet-протоколы. Для этого создается специальное правило для udp пакетов с адресом источника 0.0.0.0, а порт источника будет показывать номер ethernet-протокола. Таким образом можно заставить мост пропускать или не пропускать протоколы, отличные от IP. Для вышеупомянутого протокола arp правило будет выглядеть следующим образом:
add allow udp from 0.0.0.0 2054 to 0.0.0.0
Поскольку мы решили помимо фильтрации также использовать traffic shaper dummynet, напишем правило, ограничивающее, например, весь проходящий icmp-трафик (входящий+исходящй) на 50Кб/с:
add pipe 1 icmp from any to any
pipe 1 config bw 50Kbit/s

Если первыми стоят правила шейпера, то существует возможность пропустить пакет по правилам, котрые стоят ниже правил шейпера. Для этого нужно установить переменную
net.inet.ip.fw.one_pass=0.
Добавим еще парочку правил, например, разрешающих прохождение входящего dns-трафика, обращений к web-серверу и icmp-трафика через интерфейс xl0. Также не забудем разрешить любой трафик через xl1:
add 1000 allow tcp from any to any in via xl0 established
add 1200 allow tcp from any to any domain in via xl0
add 1300 allow udp from any to any domain in via xl0
add 1400 allow udp from any domain to any 1024-65535 in via xl0
add 1500 allow tcp from any to any www in via xl0
add 1600 allow icmp from any to any
add 1700 allow ip from any to any via xl1

Итого, наш итоговый файл /etc/ipfw.rules получился следующим:
add pipe 1 icmp from any to any
pipe 1 config bw 50Kbit/s queue 10
add 0900 allow udp from 0.0.0.0 2054 to 0.0.0.0
add 1000 allow tcp from any to any in via xl0 established
add 1200 allow tcp from any to any domain in via xl0
add 1300 allow udp from any to any domain in via xl0
add 1400 allow udp from any domain to any 1024-65535 in via xl0
add 1500 allow tcp from any to any www in via xl0
add 1600 allow icmp from any to any
add 1700 allow ip from any to any via xl1


5. Запуск свича с фильтрацией.
Перезагрузимся, чтобы вступили в силу настройки rc.conf и загрузилось новое ядро.
По умолчанию мост не работает. Для его запуска необходимо установить параметры
net.link.ether.bridge_ipfw
(чтобы работала фильтрация) и
net.link.ether.bridge
(чтобы активировать мост) в 1. Также необходимо для одновременной работы шейпера и фильтрации переменную net.inet.ip.fw.one_pass установить в 0. Сделаем это из приглашения командной строки:
# sysctl -w net.inet.ip.fw.one_pass=0
# sysctl -w net.link.ether.bridge_ipfw=1
# sysctl -w net.link.ether.bridge=1
# sysctl -w net.link.ether.bridge_cfg=xl0:0,xl1:0
Все, мост работает. Для того, чтобы каждый раз после перезагрузки не надо было изменять значения переменных, добавим следующие строки в /etc/sysctl.conf (если нет такого файла - создайте его):
net.inet.ip.fw.one_pass=0
net.link.ether.bridge_ipfw=1
net.link.ether.bridge=1
6. Производительность и несколько замечаний.
Итак, мост готов. Я провел примерные замеры производительности. Конфигурация: PIII-500MHz, 128Mb RAM, 2 сетевых интерфейса 3COM 3C905B-TX, 3 очереди для шейпера + фильтр на 30 правил. Результаты получились следующими: задержка в 0.2 ms при отсутствии трафика и 0.8 ms при интенсивном обмене. список команд для запуска моста имхо стоит добавить согласно man для перевода карт в promiscoius режим.