Документация по ОС FreeBSD Среда, 04.12.2024, 20:54
Главная
Регистрация
Вход
Приветствую Вас Гость | RSS
Меню сайта

Категории каталога
Apache [58]
DNS [25]
FTP [27]
Mail [74]
Samba [24]
Squid [46]
SSH [23]
VPN [35]
РРР [20]
Net [173]

Главная » Статьи » Сеть » Net
Особенности ipnat [2011]
Недавно столкнулся с проблемой, о причине которой давно забыл. Итак, имеем схему
 
мир ---> (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 echo 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 echo 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. Не забывайте эту особенность!

Источник: http://myfreebsd.ru/network/osobennosti-ipnat
Категория: Net | Добавил: oleg (25.12.2011) | Автор: admin
Просмотров: 1148 | Комментарии: 1 | Рейтинг: 0.0/0 |
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Форма входа

Beastie

Друзья сайта

Статистика
Онлайн всего: 1
Гостей: 1
Пользователей: 0
links

Copyright MyCorp © 2024