Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Вопрос 22.09.06 23:32 Число просмотров: 2508
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
Отредактировано 22.09.06 23:37 Количество правок: 3
|
Не знаю, почему ось принудительно всем пакетам выставляет этот флаг, но хочу спросить: а проблемы есть в связи с этим? Я так понимаю, что нет, иначе бы вопрос шел в ином ключе. То есть PMTU нормально работает. В принципе, наверное, это делается для того, чтобы уменьшить нагрузку на роутеры провайдера (без DF=1 и ICMP PMTU работать не будет).
Скорее всего, можно как-то отключить принудительное выставление этого флага в опциях (или вообще хирургически) той службы, которая его устанавливает (вероятно, это nat, хотя и не факт).
А можно и принудительно снимать этот флаг со всех пакетов, к примеру, как-то вот так:
ipfw add 10 modify df=0 tcp from any to any
(по идее, во всех фаерах должны быть какие-то средства для подобных манипуляций).
Только, имхо, это заставит маршрутизатор провайдера (или, в общем случае, - один из вышестоящих маршрутизаторов - может непосредственный провайдер тоже хитрит и модифицирует это поле у себя ;) ) пересобирать и фрагментировать все пакеты, которые не влазят в MTU, но это плохая практика, приводящая к повышеной нагрузке на оборудование.
Поправьте, если ошибаюсь...
|
|
<operating systems>
|
FreeBSD && DF bit 20.09.06 10:33
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
Отредактировано 20.09.06 10:34 Количество правок: 1
|
Есть сервер FreeBSD 4.11-STABLE. Заметил что на нем все исходящие соединения идут с флагом DF. Никак не могу понять почему? Вот пример лога tcpdump:
---8<---
tcpdump -i ed0 -n host revolver.ru
tcpdump: listening on ed0
09:50:32.258644 x.x.x.x.4591 > 217.16.16.106.80: S 732277126:732277126(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 5248419 0> (DF) [tos 0x10]
09:50:32.361830 217.16.16.106.80 > x.x.x.x.4591: S 1113346761:1113346761(0) ack 732277127 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 135717580 5248419> (DF)
09:50:32.362225 x.x.x.x.4591 > 217.16.16.106.80: . ack 1 win 57920 <nop,nop,timestamp 5248429 135717580> (DF) [tos 0x10]
09:50:43.650812 x.x.x.x.4591 > 217.16.16.106.80: F 1:1(0) ack 1 win 57920 <nop,nop,timestamp 5249558 135717580> (DF) [tos 0x10]
09:50:43.751509 217.16.16.106.80 > x.x.x.x.4591: . ack 2 win 57920 <nop,nop,timestamp 135718719 5249558> (DF)
09:50:43.751909 217.16.16.106.80 > x.x.x.x.4591: F 1:1(0) ack 2 win 57920 <nop,nop,timestamp 135718719 5249558> (DF)
09:50:43.752023 x.x.x.x.4591 > 217.16.16.106.80: . ack 2 win 57919 <nop,nop,timestamp 5249568 135718719> (DF) [tos 0x10]
---8<--
У кого есть идеи?
|
|
Вопрос 22.09.06 23:32
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
Отредактировано 22.09.06 23:37 Количество правок: 3
|
Не знаю, почему ось принудительно всем пакетам выставляет этот флаг, но хочу спросить: а проблемы есть в связи с этим? Я так понимаю, что нет, иначе бы вопрос шел в ином ключе. То есть PMTU нормально работает. В принципе, наверное, это делается для того, чтобы уменьшить нагрузку на роутеры провайдера (без DF=1 и ICMP PMTU работать не будет).
Скорее всего, можно как-то отключить принудительное выставление этого флага в опциях (или вообще хирургически) той службы, которая его устанавливает (вероятно, это nat, хотя и не факт).
А можно и принудительно снимать этот флаг со всех пакетов, к примеру, как-то вот так:
ipfw add 10 modify df=0 tcp from any to any
(по идее, во всех фаерах должны быть какие-то средства для подобных манипуляций).
Только, имхо, это заставит маршрутизатор провайдера (или, в общем случае, - один из вышестоящих маршрутизаторов - может непосредственный провайдер тоже хитрит и модифицирует это поле у себя ;) ) пересобирать и фрагментировать все пакеты, которые не влазят в MTU, но это плохая практика, приводящая к повышеной нагрузке на оборудование.
Поправьте, если ошибаюсь...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
