Недавно столкнулся с проблемой, о причине которой давно забыл.

Итак, имеем схему

мир ---> (igb0) маршрутизатор А (ng0) --> / / --> (ng0) маршрутизатор В (vlan101) -> (re0) хост.

На интерфейсе re0 конечного хоста присутствует IP-адрес 192.168.0,32, его необходимо транслировать от «реального» адреса, допустим 193.0.0.32. Маршрутизаторы А и В связаны между собой по «узкому» каналу и, в принципе, нежелательно осуществлять трансляцию адреса именно на маршрутизаторе В, тем более, что номер интерфейса ng может изменяться. Пишу на внешнем интерфейсе маршрутизатора А правило для пакетного фильтра ipnat

map igb0 192.168.0.32/32 -> 193.0.0.32/32

и маршрутизирую сеть 192.168,0.0 на маршрутизатор В.

Запускаю на хосте ping на 8.8.8.8, ответов нет, запускаю на один из IP-адресов, присвоенных маршрутизатору А, — ответы приходят! Проверяю с помощью tcpdump наличие запросов/ответов на всех, указанных на схеме, интерфейсах, оказывается на внешнем интерфейсе маршрутизатора А есть и запросы и ответы, а на внутреннем — только запросы. Добавляю везде первым правилом ipfw разрешение icmp-пакетов — ответы не появляются. Никакого объяснения не нахожу, даже сгоряча заменил внутренний сетевой адаптер маршрутизатора В с re на проверенный sk (малоли, какие глюки с vlan) — результат не изменяется. Через несколько дней догадался запустить tcpdump с волшебными ключами -vvv

router-B# tcpdump -vvv -n -i ng0 host 8.8.8.8 and icmp
tcpdump: listening on ng0, link-type NULL (BSD loopback), capture size 96 bytes
16:26:48.170040 IP (tos 0x0, ttl 63, id 37107, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.32 > 8.8.8.8: ICMP request, id 14118, seq 10, length 64
16:26:48.222775 IP (tos 0x0, ttl 56, id 48671, offset 0, flags [none], proto ICMP (1), length 84, bad cksum dfa4 (->b08e)!)
8.8.8.8 > 192.168.0.32: ICMP reply, id 14118, seq 10, length 64
16:26:49.171105 IP (tos 0x0, ttl 63, id 37118, offset 0, flags [none], proto ICMP (1), length 84)

Такие же битые контрольные суммы на интерфейсе ng0 маршрутизатора А. Google практически сразу дал ответ — fastforwargibng!

И действительно,

route-A# sysctl net.inet.ip.fastforwarding=0
net.inet.ip.fastforwarding: 1 -> 0

и ping, что называется, пошел.

В сети есть описания опции примерно в следующем виде:

net.inet.ip.fastforwarding - обрабатывать входящие пакеты непосредственно в момент приема (в т.ч. прохождение ipfw на входе,
до попадания в очередь netisr). Есть смысл включать, если количество ядер меньше или равно количеству сетевых карточек, так же как и
net.isr.direct. Влияет на скорость ПРИЕМА пакетов. Обработка пакета происходит прямо в обработчике прерывания. Следует учесть, что не
все сетевухи и не все драйвера нормально умеют складировать новые пакеты в очередь, пока обрабатывается текущий. При включеном
net.inet.ip.fastforwarding будет еще 1 спецэффект - маршрутизация пакета и прохождение ipfw (оба раза) будут происходить в том же
обработчике прерывания. Фактически, на время обработки входящего пакета сетевая карта будет заблокирована. Это неплохо смотрится при
преобладающем входящем трафике и на однопроцессорных машинах.

Практически ускоренная обработка пакетов получается «обходит» модуль ipnat. Не забывайте эту особенность!

Вы отыщете по выгодной цене прилипатели там . .