Вопросы Теги

Почему там меньше задержки на обратной петле, чем в интерфейсе карпа?

фигура, какой IP-адрес имеет гостевую систему (хотя это - присвоенный dhcp, более вероятно, что это будет иметь тот же адрес после перезагрузки; в противном случае переключитесь на статический IP),

iptables -t nat -A PREROUTING -s 0/0 -d IP_HOST -p tcp --dport 80 -j DNAT --to IP_GUEST:80
8
задан 25 July 2010 в 00:54
3 ответа

Постоянная задержка на 100 мс выглядит странной. Похоже, что пакеты буферизуются и не сразу поставленные. Или возможно некоторые из них отбрасываются и ретранслируются. Можно ли выполнить tcpdump в этом интерфейсе для показа проблемы? Я не знаю, как стек IP работает над FreeBSD, ни как CARP реализован, но было бы возможно, например, что ведомое устройство регулярно рекламирует свой MAC-адрес с бесплатным ARPs и что ведущее устройство альтернативно отправляет пакеты каждой стороне?

Вы могли также выполнить tcpdump в реальном интерфейсе, чтобы гарантировать, что ничто не испускается?

Действительно ли возможно, что система воздерживается от кэширования устройства CARP запись ARP, таким образом заставляя запрос ARP быть испущенной для каждого пакета сессии, что демон CARP должен был бы ответить?

Большинство из тех является некоторыми глупыми идеями, но это в порядке, чтобы помочь Вам искать в правильном направлении.

2
ответ дан 2 December 2019 в 23:07
  • 1
    Спасибо за идеи, Willy. Я кладу обратно конфигурацию к интерфейсу, вне часов, и вижу то, что поднимает трассировка пакетов. –  Michael Gorsuch 25 July 2010 в 00:55

Я рассматривал обратную петлю, реализованную как программное обеспечение уровня прерывания, i/f таким образом, что трафик никогда не выбирается наружу поле. Это, возможно, имело место при выполнении обратной петли?Отказ от ответственности: Просто общий вопрос; я ничего не знаю о FreeBSD.

- pete

0
ответ дан 2 December 2019 в 23:07
  • 1
    Это не способ, которым это работает в FreeBSD. –  Chris S 23 July 2010 в 18:57

Только для ясности, Вы только изменились, как к ней получали доступ, от этих 127 адресов, к локальному IP; корректный?

Если это так, и это имело значение, что-то не правильно. Проверьте свою таблицу маршрутизации с netstat -rn и посмотрите то, к чему локальному дюйм/с направляются, он должен быть направлен к интерфейсу lo0 (точно так же, как 127).

Ваш netstat -rn вывод должен быть неопределенно подобен этому:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            1.2.3.1            UGS       131  2655014   nge1
1.2.3.0/23         link#2             U           0       88   nge1
1.2.3.4            link#2             UHS         0    34848    lo0
127.0.0.1          link#5             UH          0    64678    lo0
192.168.0.0/26     link#1             U           2 41703537   nge0
192.168.0.1        link#1             UHS         0    70088    lo0
1
ответ дан 2 December 2019 в 23:07
  • 1
    я должен был включать это в сообщение: эти интерфейсы являются интерфейсами карпа. Полностью выскочивший из головы, пока я не выполнил netstat. Это имеет значение? –  Michael Gorsuch 23 July 2010 в 22:56
  • 2
    Да, вот именно тут же. Если адрес, который Вы используете, присвоен использованию интерфейса карпа, что IP вызовет его через стопку карпа, прежде чем он поразит устройство закольцовывания; 100 мс были бы чрезмерными все еще все же. Действительно ли хост рассматриваем ведущее устройство того IP, или Вы используете выравнивание нагрузки? Это могло отправлять трафик в другой хост карпа. –  Chris S 23 July 2010 в 23:56
  • 3
    Хост является ведущим устройством того IP. –  Michael Gorsuch 24 July 2010 в 01:53
  • 4
    я только что закончил сделать на скорую руку аналогичную среду и проверить его. Я не видел заметного различия в ответ времена между интерфейсом IP карпа, 127 IP и физическим IP. Я только заставил один сервер здесь тестировать, таким образом, никакие ведомые устройства карпа, но я подозреваю, что что-то находится неправильно в другом месте в Вашей среде (брандмауэр или формирование трафика?) это вызывает задержку. Это - i386-8.1-STABLE. –  Chris S 24 July 2010 в 06:49
  • 5
    Спасибо, Chris. Я буду видеть, могу ли я собрать больше информации, когда трафик утихает. Существующая система не использует пакета брандмауэра или делает любое формирование трафика. Я должен также отметить (обновит исходный вопрос), что мы получаем большой объем трафика из-за рекламы задания, которую мы отображаем на ТАК сайты семейства. Мы перемещаемся 15 Мбит/с каждый путь в течение нормальных часов. –  Michael Gorsuch 25 July 2010 в 00:53

Теги

Похожие вопросы