pmtud & ipsec

86 views
Skip to first unread message

Eugene Grosbein

unread,
Feb 26, 2007, 1:13:56 PM2/26/07
to
Привет!

Есть две территориально разнесенные локалки под одним административным
управлением. В каждой локалке есть роутер FreeBSD, через которые локалки
имеют выход в Интернет, роутеры имеют фиксированные реальные адреса,
MTU на внешних интерфейсах 1500 (впрочем, на внутренних тоже, но адреса
внутри серые).

Между роутерами организован gif-туннель, прописаны маршруты,
так что локалки спокойно общаются друг с другом, адресные пространства
локалок не пересекаются. Hа туннеле выставлен MTU 1500, так что крупные
пакеты, если после инкапсуляции в gif получаются больше 1500,
фрагментируются перед выходом во внешний мир. Фрагментируются уже пакеты
IPIP, внутри туннеля все ходит нефрагментированное.

Hа роутерах включен IPSEC - трафик между реальными адресами роутеров
шифруется в transport mode. Пока MTU трассы между роутерами
(назовем их R1 и R2) равен 1500, все работает.

Что должно происходить, если MTU трассы меньше? Промежуточный
роутер G, через который не может пройти ESP-пакет размером 1500 байт,
должен послать ICMP need-fragment, в идеале с указанием MTU следующего хопа?

Получив этот пакет, ядро FreeBSD должно фрагментировать пакет ESP
и послать его двумя частями? Если да, то два вопроса:

1. Видел ли кто-нибудь роутер, посылающий ICMP need-fragment в ответ
на такой ESP? В моем конкретном случае в ответ на ICMP echo request
возвращается ICMP need-fragment, в ответ на ESP-нет. Что там за роутер G,
неизвестно.

2. Будет ли FreeBSD фрагментировать ESP, буде получит need-fragment?

Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.

Alexander Motin

unread,
Feb 26, 2007, 10:05:56 AM2/26/07
to
Eugene Grosbein wrote:
> 1. Видел ли кто-нибудь роутер, посылающий ICMP need-fragment в ответ
> на такой ESP? В моем конкретном случае в ответ на ICMP echo request
> возвращается ICMP need-fragment, в ответ на ESP-нет. Что там за роутер G,
> неизвестно.

Вообще, признаком необходимости генерации ICMP служит флаг DF в IP
пакете. Если флага нет, то пакет обычно молча фрагменируется. Никакой
другой логики там быть не должно. Для TCP этот флаг стоит всегда, для
ESP не знаю, но сомневаюсь. tcpdump тебе поможет.

--
Alexander Motin

Eugene Grosbein

unread,
Feb 26, 2007, 2:33:01 PM2/26/07
to
26 фев 2007, понедельник, в 18:05 KRAST, Alexander Motin написал(а):

>> 1. Видел ли кто-нибудь роутер, посылающий ICMP need-fragment в ответ
>> на такой ESP? В моем конкретном случае в ответ на ICMP echo request
>> возвращается ICMP need-fragment, в ответ на ESP-нет. Что там за роутер G,
>> неизвестно.

AM> Вообще, признаком необходимости генерации ICMP служит флаг DF в IP
AM> пакете. Если флага нет, то пакет обычно молча фрагменируется. Hикакой
AM> другой логики там быть не должно.

Ok, а как дело обстоит на практике?

AM> Для TCP этот флаг стоит всегда,

Hе всегда, а когда pmtud не отключен.

AM> для ESP не знаю, но сомневаюсь. tcpdump тебе поможет.

Hе сомневайся. Четверка ставит DF всегда (даже когда pmtud отключен),
несмотря на значение net.inet.ipsec.dfbit (man ipsec).

Eugene
--
Смотри, но не смей трогать

Andrey Ostanovsky

unread,
Feb 26, 2007, 1:34:14 PM2/26/07
to
Hello Eugene.

26 Feb 07 21:13, you wrote to all:

EG> Что должно происходить, если MTU трассы меньше? Промежуточный
EG> роутер G, через который не может пройти ESP-пакет размером 1500 байт,
EG> должен послать ICMP need-fragment, в идеале с указанием MTU следующего
EG> хопа?

У меня есть подозрение, что года полтора назад кто-то уже бодался с таким
непрохождением. Там icmp то-ли посылались не на тот адрес, то-ли игнорировались
принимающей стороной - не помню.

Andrey

Victor Sudakov

unread,
Feb 26, 2007, 11:08:55 PM2/26/07
to
Eugene Grosbein wrote:

> AM> для ESP не знаю, но сомневаюсь. tcpdump тебе поможет.

> Hе сомневайся. Четверка ставит DF всегда (даже когда pmtud отключен),
> несмотря на значение net.inet.ipsec.dfbit (man ipsec).

Не подтверждается.

Есть ipsec между 4.10 и 6.2 - ни с той, ни с другой стороны DF не
ставится, только что специально посмотрел.

net.inet.ipsec.dfbit на обоих по умолчанию 0.

--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

Eugene Grosbein

unread,
Feb 28, 2007, 10:50:49 AM2/28/07
to
26 фев 2007, понедельник, в 18:05 KRAST, Alexander Motin написал(а):

>> 1. Видел ли кто-нибудь роутер, посылающий ICMP need-fragment в ответ
>> на такой ESP? В моем конкретном случае в ответ на ICMP echo request
>> возвращается ICMP need-fragment, в ответ на ESP-нет. Что там за роутер G,
>> неизвестно.
AM> Вообще, признаком необходимости генерации ICMP служит флаг DF в IP
AM> пакете. Если флага нет, то пакет обычно молча фрагменируется. Hикакой
AM> другой логики там быть не должно.

Почему соответствующий sysctl называется net.inet.tcp.path_mtu_discovery,
интересует часть tcp. Hастройка действует только на TCP, или это просто
косметическая небрежность?

Eugene
--
Choose no career

Eugene Grosbein

unread,
Feb 28, 2007, 11:56:08 AM2/28/07
to
27 фев 2007, вторник, в 07:08 KRAST, Victor Sudakov написал(а):

AM>> для ESP не знаю, но сомневаюсь. tcpdump тебе поможет.
>> Hе сомневайся. Четверка ставит DF всегда (даже когда pmtud отключен),
>> несмотря на значение net.inet.ipsec.dfbit (man ipsec).

VS> Hе подтверждается.
VS> Есть ipsec между 4.10 и 6.2 - ни с той, ни с другой стороны DF не
VS> ставится, только что специально посмотрел.
VS> net.inet.ipsec.dfbit на обоих по умолчанию 0.

tcpdump показывает, что ping -D remotehost при нулевом dfbit генерирует
ESP-пакеты с установленным DF. Еще tcpdump показывает, что
telnet remotehost 25 тоже генерирует ESP-пакеты с установленным DF.
4.11-STABLE.

Eugene
--
Что делать?! Мир стоит на воровстве!..
Воруют в Самарканде и в Хиве,
В Ширазе, в Тегеране и в Стамбуле
И даже - страшно вымолвить - в Москве!..

Victor Sudakov

unread,
Feb 28, 2007, 11:15:10 PM2/28/07
to
Eugene Grosbein wrote:

> AM>> для ESP не знаю, но сомневаюсь. tcpdump тебе поможет.
> >> Hе сомневайся. Четверка ставит DF всегда (даже когда pmtud отключен),
> >> несмотря на значение net.inet.ipsec.dfbit (man ipsec).
> VS> Hе подтверждается.
> VS> Есть ipsec между 4.10 и 6.2 - ни с той, ни с другой стороны DF не
> VS> ставится, только что специально посмотрел.
> VS> net.inet.ipsec.dfbit на обоих по умолчанию 0.

> tcpdump показывает, что ping -D remotehost при нулевом dfbit генерирует
> ESP-пакеты с установленным DF. Еще tcpdump показывает, что
> telnet remotehost 25 тоже генерирует ESP-пакеты с установленным DF.
> 4.11-STABLE.

Я просто собрал 3000 пакетов с esp между вышеназванными двумя роутерами.
Потом в Ethereal посмотрел их фильтром !(ip.flags.df == 0)
и не нашлось ни одного со взведённым DF bit.

Тогда как на соответствующем gif интерфейсе видно, что все TCP пакеты
имеют этот бит в 1.

Конфигурация там такая - между двумя вышеназванными роутерами построен
gif туннель, а ipencap шифруется в esp transport mode.

В gif(4) написано:

If the outer protocol is IPv4, gif does not try to perform path MTU dis-
covery for the encapsulated packet (DF bit is set to 0).

Если у тебя не gif, а ipsec в tunnel mode, или просто transport mode
между двумя хостами, может быть, DF bit наследуется из внутреннего
пакета?

Eugene Grosbein

unread,
Mar 1, 2007, 4:09:27 AM3/1/07
to
01 мар 2007, четверг, в 07:15 KRAST, Victor Sudakov написал(а):

VS> Если у тебя не gif, а ipsec в tunnel mode, или просто transport mode
VS> между двумя хостами, может быть, DF bit наследуется из внутреннего
VS> пакета?

Там transport mode. Есть gif, но есть и трафик между реальными адресами,
который идет не внутри gif, это SMTP. DF bit, конечно, наследуется
из внутреннего пакета, так как если pmtud отключить, то DF бит на ESP
пропадает. Hо man ipsec говорит:

ipsec.dfbit
The variable configures the kernel behavior on IPv4 IPsec tunnel
encapsulation. If set to 0, DF bit on the outer IPv4 header will
be cleared.

Так вот нифига он не cleared, а наследуется, как если бы ipsec.dfbit=2.

Eugene
--
И друзей успокоив и ближних любя,
Мы на роли героев вводили себя.

Victor Sudakov

unread,
Mar 1, 2007, 12:29:01 AM3/1/07
to
Eugene Grosbein wrote:

> VS> Если у тебя не gif, а ipsec в tunnel mode, или просто transport mode
> VS> между двумя хостами, может быть, DF bit наследуется из внутреннего
> VS> пакета?

> Там transport mode. Есть gif, но есть и трафик между реальными адресами,
> который идет не внутри gif, это SMTP. DF bit, конечно, наследуется
> из внутреннего пакета, так как если pmtud отключить, то DF бит на ESP
> пропадает. Hо man ipsec говорит:

> ipsec.dfbit
> The variable configures the kernel behavior on IPv4 IPsec tunnel
> encapsulation. If set to 0, DF bit on the outer IPv4 header will
> be cleared.

> Так вот нифига он не cleared, а наследуется, как если бы ipsec.dfbit=2.

Процитированный ман говорит про IPsec tunnel encapsulation. А у тебя
SMTP разве в tunnel mode идёт? А в transport mode нет никакого
"внутреннего пакета", в этом режиме AFAIK криптуется только payload, а
IP header не трогают.

2 All: кто хорошо знает IPv6, прокомментируйте pls, как вся эта кухня
будет там выглядеть, ведь в IPv6 роутеры не фрагментируют пакеты.

Alexander Kolesnikoff

unread,
Mar 1, 2007, 9:55:59 AM3/1/07
to

И в IPv4 заставлять маршрутизаторы фрагментировать пакеты - диверсия,
что бы там не говорили.

Alexander

Valentin Nechayev

unread,
Mar 1, 2007, 10:23:43 AM3/1/07
to

>>> Alexander Kolesnikoff wrote:

AK> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты - диверсия,

С чего вдруг?

AK> что бы там не говорили.

Ага, значит, религия - никакие аргументы не принимаем.


-netch-

Alexander Kolesnikoff

unread,
Mar 1, 2007, 10:37:50 AM3/1/07
to
Valentin Nechayev <ne...@segfault.kiev.ua> wrote:
>
>>>> Alexander Kolesnikoff wrote:
>
> AK> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты - диверсия,
>
> С чего вдруг?

Это просто лажа.

>
> AK> что бы там не говорили.
>
> Ага, значит, религия - никакие аргументы не принимаем.

Мне одного раза хватило понаблюдать за этим делом, хватило. Маршрутизатор
занимется ненужной работой (читай процессор загружается хрен знает чем), при
этом сеть работает как ... , да собственно это уже сетью назвать трудно IMO.
Пытались мы как-то заставить семитонную кошку фрагментировать пакеты - хрен
там, нет такой возможности. Да, другие модели можно заставить заниматься
фрагментацией, но надо ли оно ? Поэтому фрагментацию на маршрутизаторах надо
давить, средства для этого есть.

Alexander

Valentin Nechayev

unread,
Mar 1, 2007, 11:13:08 AM3/1/07
to

>>> Alexander Kolesnikoff wrote:

> AK>> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты - диверсия,
>> С чего вдруг?

AK> Это просто лажа.

Удивительно детальная аргументация.


> AK>> что бы там не говорили.
>> Ага, значит, религия - никакие аргументы не принимаем.

AK> Мне одного раза хватило понаблюдать за этим делом, хватило. Маршрутизатор
AK> занимется ненужной работой (читай процессор загружается хрен знает чем), при
AK> этом сеть работает как ... , да собственно это уже сетью назвать трудно IMO.
AK> Пытались мы как-то заставить семитонную кошку фрагментировать пакеты - хрен
AK> там, нет такой возможности. Да, другие модели можно заставить заниматься
AK> фрагментацией, но надо ли оно ? Поэтому фрагментацию на маршрутизаторах надо
AK> давить, средства для этого есть.

Если бы PMTUD во всём Интернете работал бы как следует - я бы с Вами
согласился. А сейчас, когда каждый второй идио^W корпоративный админ
режет весь ICMP, IPSec тупо лажается на попытке просунуть
увеличенный пакет в интерфейс, туннели страдают вообще непонятно
чем, а тот же PMTUD основывается на древнем как дерьмо мамонта RFC
который даже не обязывает указывать граничный размер - рекомендовать
ликвидацию фрагментации на раутерах - это не просто непонимание. Это
позиция совы, которая вырабатывает стратегию "мышки, станьте
слонами", или мудреца из ivory tower - но никак не основанная на
практическом опыте.


-netch-

Eugene Grosbein

unread,
Mar 1, 2007, 3:15:24 PM3/1/07
to
01 мар 2007, четверг, в 18:37 KRAST, Alexander Kolesnikoff написал(а):

AK> Поэтому фрагментацию на маршрутизаторах надо


AK> давить, средства для этого есть.

Как быть в таком случае:

- R1 имеет подключение к интернету на реальном адресе, plain ethernet,
mtu 1500, обслуживание почтового домена - R1 есть публичный MX
(вход и выход).
- на этом же адресе IPSEC туннель до удаленного хоста R2, причем
mtu трассы до этого хоста меньше чем 1500.
- У R2 все то же самое, что у R1 (MX, IPSEC).

При отключении Path MTU Discovery все работает (при этом получается
фрагментация на маршрутизаторах). При включенном pmtud:

1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF.
2) промежуточный роутер на пути убивает пакет и посылает ICMP need-fragment
3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и нифига не работает.

Что делать?

Eugene
--
За то, что все вольются реки
Когда-нибудь в морскую гладь.

Alexander Kolesnikoff

unread,
Mar 1, 2007, 7:46:16 PM3/1/07
to

tcpmssadjust не пробовал?

Alexander

Alexander Kolesnikoff

unread,
Mar 1, 2007, 8:20:24 PM3/1/07
to
Valentin Nechayev <ne...@segfault.kiev.ua> wrote:
>
>>>> Alexander Kolesnikoff wrote:
>
>> AK>> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты -
>>> диверсия, С чего вдруг?
> AK> Это просто лажа.
>
> Удивительно детальная аргументация.

Каков вопрос - таков ответ.


>
>
>> AK>> что бы там не говорили.
>>> Ага, значит, религия - никакие аргументы не принимаем.
> AK> Мне одного раза хватило понаблюдать за этим делом, хватило.
> Маршрутизатор AK> занимется ненужной работой (читай процессор загружается
> хрен знает чем), при AK> этом сеть работает как ... , да собственно это
> уже сетью назвать трудно IMO. AK> Пытались мы как-то заставить семитонную
> кошку фрагментировать пакеты - хрен AK> там, нет такой возможности. Да,
> другие модели можно заставить заниматься AK> фрагментацией, но надо ли оно
> ? Поэтому фрагментацию на маршрутизаторах надо AK> давить, средства для
> этого есть.
>
> Если бы PMTUD во всём Интернете работал бы как следует - я бы с Вами
> согласился. А сейчас, когда каждый второй идио^W корпоративный админ
> режет весь ICMP, IPSec тупо лажается на попытке просунуть
> увеличенный пакет в интерфейс, туннели страдают вообще непонятно
> чем, а тот же PMTUD основывается на древнем как дерьмо мамонта RFC
> который даже не обязывает указывать граничный размер - рекомендовать
> ликвидацию фрагментации на раутерах - это не просто непонимание. Это
> позиция совы, которая вырабатывает стратегию "мышки, станьте
> слонами", или мудреца из ivory tower - но никак не основанная на
> практическом опыте.

Жену свою учи щи варить. Без цветастых литературных изысков никак нельзя?

Пошли по второму кругу: есть киска,семитонная, которая не умеет
фрагментировать пакеты, а до зарезу надо. Ваши предложения?

Alexander

Alexander Kolesnikoff

unread,
Mar 1, 2007, 10:19:54 PM3/1/07
to

И потом, почему 4.11 не фрагментирует? У меня - фрагменитрует.

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 3:04:25 AM3/2/07
to
02 мар 2007, пятница, в 03:46 KRAST, Alexander Kolesnikoff написал(а):

>> При отключении Path MTU Discovery все работает (при этом получается
>> фрагментация на маршрутизаторах). При включенном pmtud:
>>
>> 1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF.
>> 2) промежуточный роутер на пути убивает пакет и посылает ICMP need-fragment
>> 3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и нифига не работает.
>> Что делать?

AK> tcpmssadjust не пробовал?

Причем тут TCP? В ESP-пакетах нету MSS.

Eugene
--
Choose no life

Eugene Grosbein

unread,
Mar 2, 2007, 3:05:12 AM3/2/07
to
02 мар 2007, пятница, в 06:19 KRAST, Alexander Kolesnikoff написал(а):

>> При отключении Path MTU Discovery все работает (при этом получается
>> фрагментация на маршрутизаторах). При включенном pmtud:
>>
>> 1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF.
>> 2) промежуточный роутер на пути убивает пакет и посылает ICMP need-fragment
>> 3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и нифига не работает.
>>
>> Что делать?

AK> И потом, почему 4.11 не фрагментирует? У меня - фрагменитрует.

ESP? Все что пробовал кроме ESP и у меня фрагментирует.

Eugene
--
Смерть не разбирается, что сделано и что не сделано. (Артха)
Пожалуста... сделайте так чтобы я неразучился читать и писать. (Чарли Гордон)

Alexander Kolesnikoff

unread,
Mar 1, 2007, 11:53:20 PM3/1/07
to

Ну а в ESP ты что запихиваешь?

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 4:11:18 AM3/2/07
to
02 мар 2007, пятница, в 07:53 KRAST, Alexander Kolesnikoff написал(а):

>>> При отключении Path MTU Discovery все работает (при этом получается
>>> фрагментация на маршрутизаторах). При включенном pmtud:
>>> 1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF. 2)
>>> промежуточный роутер на пути убивает пакет и посылает ICMP
>>> need-fragment 3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и
>>> нифига не работает. Что делать?
AK>> tcpmssadjust не пробовал?
>> Причем тут TCP? В ESP-пакетах нету MSS.

AK> Hу а в ESP ты что запихиваешь?

Есть и TCP, и много UDP, ICMP, IPIP.
Я не спрашиваю, как вручную добиться того, чтобы ESP-пакеты стали меньше
размером, чем MTU трассы. Это значение MTU меняется со временем,
мне надо, чтобы ESP проходили. Один способ есть - отключить pmtud
и пусть фрагментируются на маршрутизаторах по пути. Как иначе сделать?

Eugene
--
Знаете ли вы, что...
Иисус имел не менее 4 братьев и 2 сестер (Матф.13:54)

Alexander Kolesnikoff

unread,
Mar 2, 2007, 12:32:59 AM3/2/07
to

Это не наш метод! ;-) Я то как раз делаю так, чтобы ESP-пакет влазил в MTU
интерфейса и нет проблем. Если же тебя эта фрагментация устраивает - да нет
проблем, юзай.

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 4:53:30 AM3/2/07
to
02 мар 2007, пятница, в 08:32 KRAST, Alexander Kolesnikoff написал(а):

>> Есть и TCP, и много UDP, ICMP, IPIP.
>> Я не спрашиваю, как вручную добиться того, чтобы ESP-пакеты стали меньше
>> размером, чем MTU трассы. Это значение MTU меняется со временем,
>> мне надо, чтобы ESP проходили. Один способ есть - отключить pmtud
>> и пусть фрагментируются на маршрутизаторах по пути. Как иначе сделать?

AK> Это не наш метод! ;-) Я то как раз делаю так, чтобы ESP-пакет влазил в
AK> MTU
AK> интерфейса и нет проблем. Если же тебя эта фрагментация устраивает - да
AK> нет
AK> проблем, юзай.

Да не знаю я, какой MTU трассы заранее-то, вот в чем проблема.
Вчера он было 1492, сегодня стал 1484 (реальный случай).
Мы же не про идеальный мир, да? :-)

Eugene
--
Choose no friends

Alexander Kolesnikoff

unread,
Mar 2, 2007, 1:23:44 AM3/2/07
to

От чего такие флуктуации?

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 6:30:32 AM3/2/07
to
02 мар 2007, пятница, в 09:23 KRAST, Alexander Kolesnikoff написал(а):

>>> Есть и TCP, и много UDP, ICMP, IPIP.
>>> Я не спрашиваю, как вручную добиться того, чтобы ESP-пакеты стали меньше
>>> размером, чем MTU трассы. Это значение MTU меняется со временем,
>>> мне надо, чтобы ESP проходили. Один способ есть - отключить pmtud
>>> и пусть фрагментируются на маршрутизаторах по пути. Как иначе сделать?
AK>> Это не наш метод! ;-) Я то как раз делаю так, чтобы ESP-пакет влазил в
AK>> MTU
AK>> интерфейса и нет проблем. Если же тебя эта фрагментация устраивает - да
AK>> нет
AK>> проблем, юзай.
>> Да не знаю я, какой MTU трассы заранее-то, вот в чем проблема.
>> Вчера он было 1492, сегодня стал 1484 (реальный случай).
>> Мы же не про идеальный мир, да? :-)

AK> От чего такие флуктуации?

Оттого, что публичный интернет. В нём еще BGP, бывает, перестраиваится :-)

Eugene
--
Устав от радостных пиров,
Hе зная страхов и желаний

Alexander Kolesnikoff

unread,
Mar 2, 2007, 2:53:29 AM3/2/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
> 02 мар 2007, пятница, в 09:23 KRAST, Alexander Kolesnikoff написал(а):
[...]

>
> фрагментация устраивает - да AK>> нет AK>> проблем, юзай.
> >> Да не знаю я, какой MTU трассы заранее-то, вот в чем проблема.
> >> Вчера он было 1492, сегодня стал 1484 (реальный случай).
> >> Мы же не про идеальный мир, да? :-)
> AK> От чего такие флуктуации?
>
> Оттого, что публичный интернет. В нём еще BGP, бывает, перестраиваится :-)

Сделал бы минимально приемлемый MSS. А почему нет? Клинические случаи
можно отдельно выправлять но всё равно обойтись без фрагментации. У меня
почему-то стойкая аллергия на все эти фрагментации на роутерах.

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 7:13:48 AM3/2/07
to
02 мар 2007, пятница, в 10:53 KRAST, Alexander Kolesnikoff написал(а):

>> фрагментация устраивает - да AK>> нет AK>> проблем, юзай.
>>> Да не знаю я, какой MTU трассы заранее-то, вот в чем проблема.
>>> Вчера он было 1492, сегодня стал 1484 (реальный случай).
>>> Мы же не про идеальный мир, да? :-)
AK>> От чего такие флуктуации?
>> Оттого, что публичный интернет. В нём еще BGP, бывает, перестраиваится :-)

AK> Сделал бы минимально приемлемый MSS.

Какой MSS для не TCP? Тривиальные случаи, когда сидит юзер, который
только порнуху смотрит, хм, тривиальны :-) и дополнительного обсуждения
не требуют. Проблемы начинаются, когда появляется "шаг влево, шаг вправо" :-)

AK> А почему нет? Клинические случаи
AK> можно отдельно выправлять но всё равно обойтись без фрагментации.

Да вот как-то не хочется по каждому "клиническому" случаю дергаться
отдельно, найти бы верное решение.

AK> У меня почему-то стойкая аллергия на все эти фрагментации на роутерах.

А я к ней (фрагментации) отношусь, как к палочке-выручалочке,
но правда, пока CPU хватает :-)

Eugene
--
Трогай, но не пробуй на вкус

Valentin Nechayev

unread,
Mar 2, 2007, 3:20:20 AM3/2/07
to

>>> Alexander Kolesnikoff wrote:

>> AK>>> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты -
>>>> диверсия, С чего вдруг?
> AK>> Это просто лажа.
>> Удивительно детальная аргументация.

AK> Каков вопрос - таков ответ.

Я вообще-то ожидал, что вопрос "почему?" должен вызывать
аргументацию, а не окрашивание эпитетами.:)

AK> Жену свою учи щи варить. Без цветастых литературных изысков никак нельзя?

А что, найти знакомые слова никак не получается?;)) Например, про
качество реализации IPSec (тут обсуждают в соседнем треде) или про
туннели. Неужели слово IPSec является для Вас цветастым литературным
изыском?

AK> Пошли по второму кругу: есть киска,семитонная, которая не умеет
AK> фрагментировать пакеты, а до зарезу надо. Ваши предложения?

Предложение - фрагментировать, выделяя на это часть лимитированную
часть загрузки процессора (настраиваемо) и сделав это менее
приоритетной задачей, чем например собственно раутинг или ответ на
telnet.


-netch-

Alexander Kolesnikoff

unread,
Mar 2, 2007, 4:11:59 AM3/2/07
to
Valentin Nechayev <ne...@segfault.kiev.ua> wrote:
[...]

>
>
> AK> Пошли по второму кругу: есть киска,семитонная, которая не умеет
> AK> фрагментировать пакеты, а до зарезу надо. Ваши предложения?
>
> Предложение - фрагментировать, выделяя на это часть лимитированную
> часть загрузки процессора (настраиваемо) и сделав это менее
> приоритетной задачей, чем например собственно раутинг или ответ на
> telnet.

Валентин! Как мне тебе ещё объяснять, что данная киска НЕ УМЕЕТ
ФРАГМЕНТИРОВАТЬ ? Я это привёл в качестве аргумента, что нефиг роутерам
заниматся фрагментацией. И как это ты на кошке часть проца отдашь под
фрагментацию? А кошка эта держит нехилый трафик и проц там как раз хорошо и
так загружен. А вышли из положения как раз с помощью tcpmssadjust.
Остаюсь при своём мнении: фрагментация на роутерах - зло. Нужно и можно
заставлять клиентов уменьшать размер пакета до нужного значения. Средства
для этого есть.

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 8:27:48 AM3/2/07
to
02 мар 2007, пятница, в 12:11 KRAST, Alexander Kolesnikoff написал(а):

AK>> Пошли по второму кругу: есть киска,семитонная, которая не умеет
AK>> фрагментировать пакеты, а до зарезу надо. Ваши предложения?
>> Предложение - фрагментировать, выделяя на это часть лимитированную
>> часть загрузки процессора (настраиваемо) и сделав это менее
>> приоритетной задачей, чем например собственно раутинг или ответ на
>> telnet.

AK> Валентин! Как мне тебе ещё объяснять, что данная киска HЕ УМЕЕТ
AK> ФРАГМЕHТИРОВАТЬ ?

Hо ведь это лишь проблема этой кошки, нет?

AK> Я это привёл в качестве аргумента, что нефиг роутерам
AK> заниматся фрагментацией.

А по-моему, это аргумент чинить софт на роутере :-)

AK> И как это ты на кошке часть проца отдашь под
AK> фрагментацию? А кошка эта держит нехилый трафик и проц там как раз хорошо
AK> и
AK> так загружен. А вышли из положения как раз с помощью tcpmssadjust.

А что с не TCP-шным трафиком?

Eugene
--
Комбинация заискивания, подкупа и устрашения заставит молодого ученого
работать над управляемыми снарядами или атомной бомбой. (Hорберт Винер)

Alexander Kolesnikoff

unread,
Mar 2, 2007, 6:54:32 AM3/2/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
> 02 мар 2007, пятница, в 10:53 KRAST, Alexander Kolesnikoff написал(а):
>
> >> фрагментация устраивает - да AK>> нет AK>> проблем, юзай.
> >>> Да не знаю я, какой MTU трассы заранее-то, вот в чем проблема.
> >>> Вчера он было 1492, сегодня стал 1484 (реальный случай).
> >>> Мы же не про идеальный мир, да? :-)
> AK>> От чего такие флуктуации?
> >> Оттого, что публичный интернет. В нём еще BGP, бывает, перестраиваится
> :-) AK> Сделал бы минимально приемлемый MSS.
>
> Какой MSS для не TCP? Тривиальные случаи, когда сидит юзер, который только
> порнуху смотрит, хм, тривиальны :-) и дополнительного обсуждения не
> требуют. Проблемы начинаются, когда появляется "шаг влево, шаг вправо" :-)

С этого места по-подробнее. Огласите весь список не-TCP трафика, который
не пролазит в MTU интерфейса, пожалуйста. ;-)

>
> AK> А почему нет? Клинические случаи
> AK> можно отдельно выправлять но всё равно обойтись без фрагментации.
>
> Да вот как-то не хочется по каждому "клиническому" случаю дергаться
> отдельно, найти бы верное решение.

Как proof on concept: сделать табличку в ipfw или несколько, куда
заносить хосты/сети src/dst для/от которых необходимо посылать клиенту ICMP
need-fragment (в идеале с next hop MTU), причём не для всех пакетов, а размер
которых больше допустимого. Проверено - работает. Поверь - это лучше чем
фрагментация на роутере. Загрузка процессора - это полбеды, работает сеть
погано - вот что мне больше всего не нравится. Разумеется, в случае с
зарезанием ICMP где-то по дороге в инете такой фокус не пройдёт. В общем, я
настаивать не буду, дело вкуса.

>
> AK> У меня почему-то стойкая аллергия на все эти фрагментации на роутерах.
>
> А я к ней (фрагментации) отношусь, как к палочке-выручалочке,
> но правда, пока CPU хватает :-)

;-)

Alexander

Alexander Kolesnikoff

unread,
Mar 2, 2007, 7:00:04 AM3/2/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
> 02 мар 2007, пятница, в 12:11 KRAST, Alexander Kolesnikoff написал(а):
>
> AK>> Пошли по второму кругу: есть киска,семитонная, которая не умеет
> AK>> фрагментировать пакеты, а до зарезу надо. Ваши предложения?
> >> Предложение - фрагментировать, выделяя на это часть лимитированную
> >> часть загрузки процессора (настраиваемо) и сделав это менее
> >> приоритетной задачей, чем например собственно раутинг или ответ на
> >> telnet.
> AK> Валентин! Как мне тебе ещё объяснять, что данная киска HЕ УМЕЕТ
> AK> ФРАГМЕHТИРОВАТЬ ?
>
> Hо ведь это лишь проблема этой кошки, нет?

Это фича. ;-)

>
> AK> Я это привёл в качестве аргумента, что нефиг роутерам
> AK> заниматся фрагментацией.
>
> А по-моему, это аргумент чинить софт на роутере :-)

Специально сделали, чтоб руки ни у кого не чесались, IMO. ;-)

>
> AK> И как это ты на кошке часть проца отдашь под AK> фрагментацию? А кошка
> эта держит нехилый трафик и проц там как раз хорошо AK> и AK> так
> загружен. А вышли из положения как раз с помощью tcpmssadjust.
>
> А что с не TCP-шным трафиком?

Тут только ICMP need ...

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 11:22:24 AM3/2/07
to
02 мар 2007, пятница, в 14:54 KRAST, Alexander Kolesnikoff написал(а):

>>> фрагментация устраивает - да AK>> нет AK>> проблем, юзай.
>>>> Да не знаю я, какой MTU трассы заранее-то, вот в чем проблема.
>>>> Вчера он было 1492, сегодня стал 1484 (реальный случай).
>>>> Мы же не про идеальный мир, да? :-)
AK>>> От чего такие флуктуации?
>>> Оттого, что публичный интернет. В нём еще BGP, бывает, перестраиваится
>> :-) AK> Сделал бы минимально приемлемый MSS.
>> Какой MSS для не TCP? Тривиальные случаи, когда сидит юзер, который только
>> порнуху смотрит, хм, тривиальны :-) и дополнительного обсуждения не
>> требуют. Проблемы начинаются, когда появляется "шаг влево, шаг вправо" :-)

AK> С этого места по-подробнее. Огласите весь список не-TCP трафика, который
AK> не пролазит в MTU интерфейса, пожалуйста. ;-)

Hе MTU интерфейса, а MTU трассы. Имеет значение именно MTU трассы.
И легко может выйти пакет с интерфейса длиной, бОльшей, чем MTU трассы.

AK>> А почему нет? Клинические случаи
AK>> можно отдельно выправлять но всё равно обойтись без фрагментации.
>> Да вот как-то не хочется по каждому "клиническому" случаю дергаться
>> отдельно, найти бы верное решение.

AK> Как proof on concept: сделать табличку в ipfw или несколько, куда
AK> заносить хосты/сети src/dst для/от которых необходимо посылать клиенту
AK> ICMP
AK> need-fragment (в идеале с next hop MTU), причём не для всех пакетов, а
AK> размер
AK> которых больше допустимого. Проверено - работает.

Hе, вопрос не в том, как быть провайдеру. Вопрос в том, как быть клиенту.
Которому надо общаться с удаленным хостом, MTU трассы до которого
может оказаться ниже, чем MTU на интерфейсе клиента.

AK> Поверь - это лучше чем
AK> фрагментация на роутере. Загрузка процессора - это полбеды, работает сеть
AK> погано - вот что мне больше всего не нравится.

От чего сеть-то погано работает, в чем это выражается?
Пока CPU хватает и задержки в пределах нормы, никаких нежелательных
эффектов быть не должно.

Eugene
--
Hе зная страхов и желаний,
Благословляем мы богов

Alexander Kolesnikoff

unread,
Mar 2, 2007, 8:00:06 AM3/2/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
> 02 мар 2007, пятница, в 14:54 KRAST, Alexander Kolesnikoff написал(а):
>
> AK> С этого места по-подробнее. Огласите весь список не-TCP трафика,
> который AK> не пролазит в MTU интерфейса, пожалуйста. ;-)
>
> Hе MTU интерфейса, а MTU трассы. Имеет значение именно MTU трассы.
> И легко может выйти пакет с интерфейса длиной, бОльшей, чем MTU трассы.

Да, конечно, MTU трассы, так будет точнее. И всё-таки: много ли не-TCP
трафика?

>
> AK>> А почему нет? Клинические случаи
> AK>> можно отдельно выправлять но всё равно обойтись без фрагментации.
> >> Да вот как-то не хочется по каждому "клиническому" случаю дергаться
> >> отдельно, найти бы верное решение.
> AK> Как proof on concept: сделать табличку в ipfw или несколько, куда
> AK> заносить хосты/сети src/dst для/от которых необходимо посылать клиенту
> AK> ICMP
> AK> need-fragment (в идеале с next hop MTU), причём не для всех пакетов, а
> AK> размер
> AK> которых больше допустимого. Проверено - работает.
>
> Hе, вопрос не в том, как быть провайдеру. Вопрос в том, как быть клиенту.
> Которому надо общаться с удаленным хостом, MTU трассы до которого
> может оказаться ниже, чем MTU на интерфейсе клиента.

Так это вообще говоря уже не твоя головная боль. (Надеюсь MTU трассы
занижается хостами вне твоей административной досягаемости)

>
> AK> Поверь - это лучше чем AK> фрагментация на роутере. Загрузка
> процессора - это полбеды, работает сеть AK> погано - вот что мне больше
> всего не нравится.
>
> От чего сеть-то погано работает, в чем это выражается?
> Пока CPU хватает и задержки в пределах нормы, никаких нежелательных
> эффектов быть не должно.

Я это наблюдал на запросном канале по земле через туннель для
одностороннего спутникового инета. Может конфигурация была специфичная,
допускаю, но после настройки tcpmssadjust проблема ушла сама собой. Через
космос же вообще вот такой туннель был: IP->IPCOMP->ESP->IP-IP. И то же
самое - никаких фрагментаций.

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 12:27:23 PM3/2/07
to
02 мар 2007, пятница, в 16:00 KRAST, Alexander Kolesnikoff написал(а):

AK>> С этого места по-подробнее. Огласите весь список не-TCP трафика,
>> который AK> не пролазит в MTU интерфейса, пожалуйста. ;-)
>> Hе MTU интерфейса, а MTU трассы. Имеет значение именно MTU трассы.
>> И легко может выйти пакет с интерфейса длиной, бОльшей, чем MTU трассы.

AK> Да, конечно, MTU трассы, так будет точнее. И всё-таки: много ли не-TCP
AK> трафика?

У кого как. Бывает много. А даже если и мало, что - пусть бъется?

AK>>> А почему нет? Клинические случаи
AK>>> можно отдельно выправлять но всё равно обойтись без фрагментации.
>>> Да вот как-то не хочется по каждому "клиническому" случаю дергаться
>>> отдельно, найти бы верное решение.
AK>> Как proof on concept: сделать табличку в ipfw или несколько, куда
AK>> заносить хосты/сети src/dst для/от которых необходимо посылать клиенту
AK>> ICMP
AK>> need-fragment (в идеале с next hop MTU), причём не для всех пакетов, а
AK>> размер
AK>> которых больше допустимого. Проверено - работает.
>> Hе, вопрос не в том, как быть провайдеру. Вопрос в том, как быть клиенту.
>> Которому надо общаться с удаленным хостом, MTU трассы до которого
>> может оказаться ниже, чем MTU на интерфейсе клиента.

AK> Так это вообще говоря уже не твоя головная боль.

Это моя головная боль, когда я - клиент. Что мне, клиенту, делать
в дважды уже описанном случае? :-)

AK> (Hадеюсь MTU трассы
AK> занижается хостами вне твоей административной досягаемости)

Да.

AK>> Поверь - это лучше чем AK> фрагментация на роутере. Загрузка
>> процессора - это полбеды, работает сеть AK> погано - вот что мне больше
>> всего не нравится.
>> От чего сеть-то погано работает, в чем это выражается?
>> Пока CPU хватает и задержки в пределах нормы, никаких нежелательных
>> эффектов быть не должно.

AK> Я это наблюдал на запросном канале по земле через туннель для
AK> одностороннего спутникового инета. Может конфигурация была специфичная,
AK> допускаю, но после настройки tcpmssadjust проблема ушла сама собой. Через
AK> космос же вообще вот такой туннель был: IP->IPCOMP->ESP->IP-IP. И то же
AK> самое - никаких фрагментаций.

Я так и не понял, в чем выражалась поганость работы сети при наличии
фрагментации. PMTUD ломался? Так это поганость при _отсутствии_ фрагментации
(DF не дает фрагментировать), и tcpmssadjust просто обходит проблему.
Точно так же обходит её принудительное снятие df на роутере
или отключение PMTUD на клиенте (последнее актуально, когда я - клиент :-)

Eugene
--
О, сколько их было - один другого круче,
И каждый знал правду, и каждый был лучше
Того, что был прежде.

Andrey Ostanovsky

unread,
Mar 2, 2007, 8:15:38 AM3/2/07
to
Hello Eugene!

02 Mar 07 16:27, you wrote to Alexander Kolesnikoff:

AK>> раз хорошо и так загружен. А вышли из положения как раз с помощью
AK>> tcpmssadjust.

EG> А что с не TCP-шным трафиком?

(округляя глаза) Как можно "не TCP-шный трафик" гнать через дорогущую кошку? :)

Для этого рядом ставится парочка дешевых DLink-ов.

Andrey

Alexander Kolesnikoff

unread,
Mar 2, 2007, 9:08:55 AM3/2/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
> 02 мар 2007, пятница, в 16:00 KRAST, Alexander Kolesnikoff написал(а):
>
> AK>> С этого места по-подробнее. Огласите весь список не-TCP трафика,
> >> который AK> не пролазит в MTU интерфейса, пожалуйста. ;-)
> >> Hе MTU интерфейса, а MTU трассы. Имеет значение именно MTU трассы.
> >> И легко может выйти пакет с интерфейса длиной, бОльшей, чем MTU трассы.
> AK> Да, конечно, MTU трассы, так будет точнее. И всё-таки: много ли не-TCP
> AK> трафика?
>
> У кого как. Бывает много. А даже если и мало, что - пусть бъется?

Из моей практики - ну совсем мало. Нет, биться он не должен, вот для него
как раз и можно ICMP-need-frag использовать. Т.е. tspmssajust решает большую
часть проблем. Почему не использовать ?

>
> AK>>> А почему нет? Клинические случаи
> AK>>> можно отдельно выправлять но всё равно обойтись без фрагментации.
> >>> Да вот как-то не хочется по каждому "клиническому" случаю дергаться
> >>> отдельно, найти бы верное решение.

[...]


> >> Пока CPU хватает и задержки в пределах нормы, никаких нежелательных
> >> эффектов быть не должно.
> AK> Я это наблюдал на запросном канале по земле через туннель для AK>
> одностороннего спутникового инета. Может конфигурация была специфичная,
> AK> допускаю, но после настройки tcpmssadjust проблема ушла сама собой.
> Через AK> космос же вообще вот такой туннель был: IP->IPCOMP->ESP->IP-IP.
> И то же AK> самое - никаких фрагментаций.
>
> Я так и не понял, в чем выражалась поганость работы сети при наличии
> фрагментации. PMTUD ломался? Так это поганость при _отсутствии_ фрагментации
> (DF не дает фрагментировать), и tcpmssadjust просто обходит проблему.

Обходить-то обходит, но как элегантно! ;-)

> Точно так же обходит её принудительное снятие df на роутере
> или отключение PMTUD на клиенте (последнее актуально, когда я - клиент :-)

Похоже, это как раз мой случай и был, я первый раз тогда так плотно с
туннелями воевал. ;-) Убедил. Тогда остаётся только один аргумент против
фрагментации на роутере - проц. Ну это мы уже обсудили. Абгемахт, короче.
;-)

Alexander

Eugene Grosbein

unread,
Mar 2, 2007, 1:52:01 PM3/2/07
to
02 мар 2007, пятница, в 17:08 KRAST, Alexander Kolesnikoff написал(а):

>>> который AK> не пролазит в MTU интерфейса, пожалуйста. ;-)
>>> Hе MTU интерфейса, а MTU трассы. Имеет значение именно MTU трассы.
>>> И легко может выйти пакет с интерфейса длиной, бОльшей, чем MTU трассы.
AK>> Да, конечно, MTU трассы, так будет точнее. И всё-таки: много ли не-TCP
AK>> трафика?
>> У кого как. Бывает много. А даже если и мало, что - пусть бъется?

AK> Из моей практики - ну совсем мало.

Это сильно зависит от "контингента" :-) Бывает такой, что
TCP вообще нету, зато другого полно. Или есть все подряд.

Hет, биться он не должен, вот для него
AK> как раз и можно ICMP-need-frag использовать. Т.е. tspmssajust решает
AK> большую
AK> часть проблем. Почему не использовать ?

Против tspmssajust ничего не имею. Только оно не панацея.

>> Я так и не понял, в чем выражалась поганость работы сети при наличии
>> фрагментации. PMTUD ломался? Так это поганость при _отсутствии_
>> фрагментации
>> (DF не дает фрагментировать), и tcpmssadjust просто обходит проблему.

AK> Обходить-то обходит, но как элегантно! ;-)

Только для домашних пользователей, у которых кроме TCP наружу ничего
вообще не идет.

>> Точно так же обходит её принудительное снятие df на роутере
>> или отключение PMTUD на клиенте (последнее актуально, когда я - клиент :-)

AK> Похоже, это как раз мой случай и был, я первый раз тогда так плотно с
AK> туннелями воевал. ;-)

Если туннель идет не поверх L2, а поверх L3, есть еще один способ:
выставить MTU 1500 на туннельном интерфейсе и пусть низлежащий IP
фрагментирует :-)

AK> Убедил. Тогда остаётся только один аргумент против
AK> фрагментации на роутере - проц. Hу это мы уже обсудили. Абгемахт, короче.
AK> ;-)

Угу :-)

Eugene
--
Смотри, но не смей трогать

Alexander Kolesnikoff

unread,
Mar 2, 2007, 10:25:58 AM3/2/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
> 02 мар 2007, пятница, в 17:08 KRAST, Alexander Kolesnikoff написал(а):
>
[...]

> >> У кого как. Бывает много. А даже если и мало, что - пусть бъется?
> AK> Из моей практики - ну совсем мало.
>
> Это сильно зависит от "контингента" :-) Бывает такой, что
> TCP вообще нету, зато другого полно. Или есть все подряд.
>
> Hет, биться он не должен, вот для него
> AK> как раз и можно ICMP-need-frag использовать. Т.е. tspmssajust решает
> AK> большую
> AK> часть проблем. Почему не использовать ?
>
> Против tspmssajust ничего не имею. Только оно не панацея.

Для себя, по крайней мере, я делаю вывод:

1. tcpmssadjust - использовать всегда
2. icmp need-frag - для не TCP
3. фрагментация на роутере - как крайний случай, но не в первую очередь

[...]


>
> Если туннель идет не поверх L2, а поверх L3, есть еще один способ:
> выставить MTU 1500 на туннельном интерфейсе и пусть низлежащий IP
> фрагментирует :-)

Тот роутер, 4.11 кстати, просто загнулся бы тогда от таких способов ;-)
Там есть такие потребители проца как natd и IPSEC.

[...]

Вспомнил, нюанс один выяснился тогда: если пакет летит в туннель не по
роутингу, а с помощью PBR, фряха (и киска тоже) не выдают ICMP need-frag.
А будет ли фряха фрагментировать в этом случае?

Alexander

Valentin Nechayev

unread,
Mar 2, 2007, 10:57:17 AM3/2/07
to

>>> Alexander Kolesnikoff wrote:

> AK>> Пошли по второму кругу: есть киска,семитонная, которая не умеет
> AK>> фрагментировать пакеты, а до зарезу надо. Ваши предложения?
>> Предложение - фрагментировать, выделяя на это часть лимитированную
>> часть загрузки процессора (настраиваемо) и сделав это менее
>> приоритетной задачей, чем например собственно раутинг или ответ на
>> telnet.

AK> Валентин! Как мне тебе ещё объяснять, что данная киска НЕ УМЕЕТ
AK> ФРАГМЕНТИРОВАТЬ ?

В этом случае она НЕ ИМЕЕТ ПРАВО называться раутером. ТОЧКА.
Извини за Caps Lock, но это твой стиль.

Кстати, откуда вывод, что "не умеет"? Да, тратит процессор. Но не
"не умеет", извини, Cisco при всех их тараканах так не делает.
Извини, не верю.

AK> Я это привёл в качестве аргумента, что нефиг роутерам
AK> заниматся фрагментацией.

Это не аргумент. Это сообщение о проблемах одной версии софта одной
модели одного устройства. Может, ты ещё из того что в 12.0 были
жуткие проблемы с качеством CEF - сделаешь вывод, что нефиг
раутерам заниматься раутингом, не их это собачье дело?

AK> И как это ты на кошке часть проца отдашь под
AK> фрагментацию? А кошка эта держит нехилый трафик и проц там как раз хорошо и
AK> так загружен. А вышли из положения как раз с помощью tcpmssadjust.

Угу, замечательный метод - вместо основного метода (DF+needfrag) или
даже запасного (фрагментация) делаем подпорку, которая сокращает
фактический размер встречного пакета в любом случае (ты ведь не
проверил, с каким именно направлением проблемы? зарезал всех?)

AK> Остаюсь при своём мнении: фрагментация на роутерах - зло.

И в качестве обоснования - пример, который собственно-то возник из
того, что эту фрагментацию не делают. Великолепно! Так держать!

AK> Нужно и можно
AK> заставлять клиентов уменьшать размер пакета до нужного значения. Средства
AK> для этого есть.

Средства есть, они не могут не есть.
Извините, с вашими подходами на серьёзный тон как-то не
настраиваешься:)))


-netch-

Eugene Grosbein

unread,
Mar 2, 2007, 3:03:43 PM3/2/07
to
02 мар 2007, пятница, в 18:25 KRAST, Alexander Kolesnikoff написал(а):

AK> Вспомнил, нюанс один выяснился тогда: если пакет летит в туннель не по
AK> роутингу, а с помощью PBR, фряха (и киска тоже) не выдают ICMP need-frag.
AK> А будет ли фряха фрагментировать в этом случае?

Hе знаю. Очень может быть, что нет :-)

Valentin Nechayev

unread,
Mar 2, 2007, 11:13:57 AM3/2/07
to

>>> Alexander Kolesnikoff wrote:

>> Какой MSS для не TCP? Тривиальные случаи, когда сидит юзер, который только
>> порнуху смотрит, хм, тривиальны :-) и дополнительного обсуждения не
>> требуют. Проблемы начинаются, когда появляется "шаг влево, шаг вправо" :-)

AK> С этого места по-подробнее. Огласите весь список не-TCP трафика, который
AK> не пролазит в MTU интерфейса, пожалуйста. ;-)

Ну вот читаем RFC3261:
=== cut ===
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
=== end cut ===

А теперь вспоминаем, что ещё 28 байт на IP+UDP, а минимальный MTU
по требованию для IPv6 - 1280, а для IPv4 - вообще 296.
А реальный размер пакета - бывает и 1000.

Этого мало? Как для меня - достаточно "с головой".

>>
> AK>> А почему нет? Клинические случаи
> AK>> можно отдельно выправлять но всё равно обойтись без фрагментации.
>> Да вот как-то не хочется по каждому "клиническому" случаю дергаться
>> отдельно, найти бы верное решение.

AK> Как proof on concept: сделать табличку в ipfw или несколько, куда
AK> заносить хосты/сети src/dst для/от которых необходимо посылать клиенту ICMP
AK> need-fragment (в идеале с next hop MTU), причём не для всех пакетов, а размер
AK> которых больше допустимого. Проверено - работает. Поверь - это лучше чем
AK> фрагментация на роутере.

Жууууть. И чем это лучше чем штатная таблица имени PMTUD?

AK> Загрузка процессора - это полбеды, работает сеть
AK> погано - вот что мне больше всего не нравится. Разумеется, в случае с
AK> зарезанием ICMP где-то по дороге в инете такой фокус не пройдёт.

Аааагаааа! - сказали крепкие сибирские мужики, взвалили топоры на
плечи и пошли рубить тайгу...


-netch-

Alex Bakhtin

unread,
Mar 2, 2007, 11:28:07 AM3/2/07
to
>>>>> "EG" == Eugene Grosbein writes:
Привет,

>>> Hе, вопрос не в том, как быть провайдеру. Вопрос в том, как быть клиенту.
>>> Которому надо общаться с удаленным хостом, MTU трассы до которого
>>> может оказаться ниже, чем MTU на интерфейсе клиента.
AK> Так это вообще говоря уже не твоя головная боль.

EG> Это моя головная боль, когда я - клиент. Что мне, клиенту, делать
EG> в дважды уже описанном случае? :-)

Жаловаться в техподдержку провайдера, естественно. Тебя, как клиента,
не должно вообще волновать каким образом они обеспечивают тебе ip mtu 1500
по всей трассе. Я могу вспомнить реально один случай только, когда проблема
на стороне провайдера была нерешаемая - это необходимость положить
EoMPLS в TE туннель. Вообще-то, через такого горе-провайдера не должны
открываться всякие мелкософтовские сервера, типа хотмейла.

AK> (Hадеюсь MTU трассы
AK> занижается хостами вне твоей административной досягаемости)

EG> Да.

Ну дык пусть повышают. Никаких технических причин (кроме желания
использовать найденное на помойке оборудование, выпущенное при царе горохе)
для занижения mtu я не вижу. Для завышения - тоже. ping 1500 с установленным df
должен проходить всегда. Как они этого добиваются - не твои проблемы.

EG> Я так и не понял, в чем выражалась поганость работы сети при наличии
EG> фрагментации. PMTUD ломался? Так это поганость при _отсутствии_ фрагментации
EG> (DF не дает фрагментировать), и tcpmssadjust просто обходит проблему.
EG> Точно так же обходит её принудительное снятие df на роутере
EG> или отключение PMTUD на клиенте (последнее актуально, когда я - клиент :-)

Жень, ты чего добиться хочешь? Фрагментация на транзитном железе -
зло, с этим я полностью согласен. Решения два - либо занижать mtu у тебя,
либо лечить провайдера.

--
Best regards, Alex Bakhtin, CCIE #8439
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru

Alex Bakhtin

unread,
Mar 2, 2007, 11:35:42 AM3/2/07
to
>>>>> "VN" == Valentin Nechayev writes:
Привет,

AK> Остаюсь при своём мнении: фрагментация на роутерах - зло.

VN> И в качестве обоснования - пример, который собственно-то возник из
VN> того, что эту фрагментацию не делают. Великолепно! Так держать!

Фрагментация на роутерах - зло. При построенной руками, растущими из
плеч, а не из задницы сети фрагментация на роутерах не возникает в
принципе. В данном случае речь про сети ISP, естественно.

Eugene Grosbein

unread,
Mar 2, 2007, 4:08:54 PM3/2/07
to
02 мар 2007, пятница, в 19:35 KRAST, Alex Bakhtin написал(а):

AK>> Остаюсь при своём мнении: фрагментация на роутерах - зло.
VN>> И в качестве обоснования - пример, который собственно-то возник из
VN>> того, что эту фрагментацию не делают. Великолепно! Так держать!

AB> Фрагментация на роутерах - зло. При построенной руками, растущими из
AB> плеч, а не из задницы сети фрагментация на роутерах не возникает в
AB> принципе. В данном случае речь про сети ISP, естественно.

Что там говаривал медведь бегемоту насчет хлебала и мёда? Ж-)
Hа практике еще как возникает, а мы поверх таких сетей работать потом
пытаемся, большей частью успешно :-)

Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.

Alex Semenyaka

unread,
Mar 2, 2007, 12:24:24 PM3/2/07
to
Hello Valentin!

01 Mar 07 18:23, you wrote to Alexander Kolesnikoff:

AK>> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты -

AK>> диверсия,
VN> С чего вдруг?

Зло не фрагментация, зло - отсутствие pMTUd :) Конечно, коль его нету,
фрагментация лучше, чем убиение пакета, но если её нет - лучше.
Чтобы потом не искать причину, по которой вдруг вот одна, но зато важная
транзакция не проходит. Hу, вот неизбежный именно в этом случае мелкий
фрагментом транзитным умным файрволом считается подозрительным и грохается.
Hапример.

Alex

Alex Semenyaka

unread,
Mar 2, 2007, 10:10:50 AM3/2/07
to
Hello Eugene!

01 Mar 07 23:15, you wrote to Alexander Kolesnikoff:

EG> 1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF.
EG> 2) промежуточный роутер на пути убивает пакет и посылает ICMP
EG> need-fragment 3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и
EG> нифига не работает.
EG> Что делать?

Hу, в данном-то случае - делать PR с помощью send-pr.

Alex

Alex Semenyaka

unread,
Mar 2, 2007, 12:17:16 PM3/2/07
to
Hello Alexander!

02 Mar 07 12:11, you wrote to Valentin Nechayev:

>> AK> Пошли по второму кругу: есть киска,семитонная, которая не умеет
>> AK> фрагментировать пакеты, а до зарезу надо. Ваши предложения?
>> Предложение - фрагментировать, выделяя на это часть лимитированную
>> часть загрузки процессора (настраиваемо) и сделав это менее
>> приоритетной задачей, чем например собственно раутинг или ответ на
>> telnet.

AK> Валентин! Как мне тебе ещё объяснять, что данная киска HЕ УМЕЕТ

AK> ФРАГМЕHТИРОВАТЬ ? Я это привёл в качестве аргумента, что нефиг роутерам
AK> заниматся фрагментацией.

Вот странная аргументация. А я знаю как минимум 3 разные железки (софтсвитч,
систему видеонаблюдения и коробки мониторинга энергооборудования), которые
только одну TCP-сессию умеют. Это повод требовать запрета параллельных сессий?
А ещё куча свитчей не умеют 802.1q - тоже отказаться?

С кошкой тоже непонятно, чего такое случилось, но это уже не для этой эхи.

Alex

Eugene Grosbein

unread,
Mar 2, 2007, 4:31:54 PM3/2/07
to
02 мар 2007, пятница, в 19:28 KRAST, Alex Bakhtin написал(а):

>>>> Hе, вопрос не в том, как быть провайдеру. Вопрос в том, как быть клиенту.
>>>> Которому надо общаться с удаленным хостом, MTU трассы до которого
>>>> может оказаться ниже, чем MTU на интерфейсе клиента.
AK>> Так это вообще говоря уже не твоя головная боль.
EG>> Это моя головная боль, когда я - клиент. Что мне, клиенту, делать
EG>> в дважды уже описанном случае? :-)

AB> Жаловаться в техподдержку провайдера, естественно. Тебя, как клиента,
AB> не должно вообще волновать каким образом они обеспечивают тебе ip mtu 1500
AB> по всей трассе.

Дык нигде не прописано, что path mtu должен быть 1500.

AB> Я могу вспомнить реально один случай только, когда проблема
AB> на стороне провайдера была нерешаемая - это необходимость положить
AB> EoMPLS в TE туннель.

Что-то похожее, по крайней мере буковки EoMPLS тама есть.
А что такое TE туннель?

AB> Вообще-то, через такого горе-провайдера не должны
AB> открываться всякие мелкософтовские сервера, типа хотмейла.

А до хотмейла MTU трассы 1500. И вообще почти до всего 1500,
окромя нужного мне хоста; netstat -aW показывает mtu 1484
в настоящий момент для этого хоста. icmp need fragment шлются
исправно и этот размер в себе содержат.

AK>> (Hадеюсь MTU трассы
AK>> занижается хостами вне твоей административной досягаемости)
EG>> Да.

AB> Hу дык пусть повышают. Hикаких технических причин (кроме желания
AB> использовать найденное на помойке оборудование, выпущенное при царе
AB> горохе)
AB> для занижения mtu я не вижу. Для завышения - тоже. ping 1500 с
AB> установленным df
AB> должен проходить всегда. Как они этого добиваются - не твои проблемы.

Основание?

EG>> Я так и не понял, в чем выражалась поганость работы сети при наличии
EG>> фрагментации. PMTUD ломался? Так это поганость при _отсутствии_

AB> фрагментации


EG>> (DF не дает фрагментировать), и tcpmssadjust просто обходит проблему.
EG>> Точно так же обходит её принудительное снятие df на роутере
EG>> или отключение PMTUD на клиенте (последнее актуально, когда я - клиент

EG>> :-)
AB> Жень, ты чего добиться хочешь?

Чтобы трафик ходил. Желательно, без отключения pmtud :-)

AB> Фрагментация на транзитном железе -
AB> зло, с этим я полностью согласен. Решения два - либо занижать mtu у тебя,
AB> либо лечить провайдера.

Либо отключать pmtud :-) Фрагментация на транзитном роутере делает
хуже только самому роутеру. Хост назначения свой поток как-нибудь
уж дефрагментирует, а вот роутеру хуже.

Eugene
--
Choose SMTP and wondering why the fsck you are logged on on a Sunday morning

Alex Semenyaka

unread,
Mar 2, 2007, 12:39:34 PM3/2/07
to
Hello Alex!

02 Mar 07 19:28, you wrote to Eugene Grosbein:

EG>> Это моя головная боль, когда я - клиент. Что мне, клиенту, делать
EG>> в дважды уже описанном случае? :-)
AB> Жаловаться в техподдержку провайдера, естественно. Тебя, как

AB> клиента, не должно вообще волновать каким образом они обеспечивают тебе
AB> ip mtu 1500 по всей трассе. Я могу вспомнить реально один случай только,

Они скажут "это за пределами нашей сети" и будут правы. Этот подход работает
для карманных SP, которые, например, обслуживают нескоколько энтерпрайзов, и
все дружно сидят в одном холдинге, например. А вот для обычных ISP и обычного
клиента (который не делает, условно говоря, 20% выручки ISP) оно ни фига не
пройдёт.

Alex

Eugene Grosbein

unread,
Mar 2, 2007, 5:03:14 PM3/2/07
to
02 мар 2007, пятница, в 18:10 KRAST, Alex Semenyaka написал(а):

EG>> 1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF.
EG>> 2) промежуточный роутер на пути убивает пакет и посылает ICMP
EG>> need-fragment 3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и
EG>> нифига не работает.
EG>> Что делать?

AS> Hу, в данном-то случае - делать PR с помощью send-pr.

Hа четверку несколько поздно. Кстати, все сложнее, чем я описал.

Пункты 1-3 имеют место на самом деле, и TCP-коннект застревает
и потом обламывается по таймауту, это так. Hо. Ядро все-таки обрабатывает
need-fragment и появляется cloned route с правильным mtu трассы,
просто почему-то на текущий коннект это знание благотворно не действует.
Если же не ждать обрыва TCP, а вручную срубить процесс (и таким образом
коннект) и тут же процесс перезапустить - ядро начинает посылать пакеты
ESP размера равными mtu трассы (ну, не более) и данные тут же благополучно
уходят.

К сожалению, в случае с sendmail-ом получяется фигня - обломившись
по таймауту, он кладет письмо в очередь, а к следующему моменту
разбора очереди, видимо, этот cloned route уже протухает и процесс
начинается с самого начала. В итоге почта так и не уходит никогда.

Бага где-то в ядре :-(

Eugene Grosbein

unread,
Mar 2, 2007, 5:13:04 PM3/2/07
to
03 мар 2007, суббота, в 01:03 KRAST, Eugene Grosbein написал(а):

EG>>> 1) R1 посылает ESP-пакет на R2 размером 1500 байт с флагом DF.
EG>>> 2) промежуточный роутер на пути убивает пакет и посылает ICMP
EG>>> need-fragment 3) R1 (FreeBSD 4.11) тупо игнорирует need-fragment и
EG>>> нифига не работает.
EG>>> Что делать?
AS>> Hу, в данном-то случае - делать PR с помощью send-pr.

EG> Hа четверку несколько поздно. Кстати, все сложнее, чем я описал.

EG> Пункты 1-3 имеют место на самом деле, и TCP-коннект застревает
EG> и потом обламывается по таймауту, это так. Hо. Ядро все-таки обрабатывает
EG> need-fragment и появляется cloned route с правильным mtu трассы,
EG> просто почему-то на текущий коннект это знание благотворно не действует.
EG> Если же не ждать обрыва TCP, а вручную срубить процесс (и таким образом
EG> коннект) и тут же процесс перезапустить - ядро начинает посылать пакеты
EG> ESP размера равными mtu трассы (ну, не более) и данные тут же благополучно
EG> уходят.

Можно даже не обрывать первый процесс/коннект, а параллельно запустить
другой такой же - он, используя верный mtu трассы, благополучно данные
отправляет и завершается, тем временем первых так и продолжает висеть,
периодически перепосылая пакеты размером в 1500 байт и получая в ответ
icmp need-fragment.

Eugene Grosbein

unread,
Mar 3, 2007, 6:13:16 AM3/3/07
to
EG>> Кстати, все сложнее, чем я описал.

EG>> Пункты 1-3 имеют место на самом деле, и TCP-коннект застревает
EG>> и потом обламывается по таймауту, это так. Hо. Ядро все-таки обрабатывает
EG>> need-fragment и появляется cloned route с правильным mtu трассы,
EG>> просто почему-то на текущий коннект это знание благотворно не действует.
EG>> Если же не ждать обрыва TCP, а вручную срубить процесс (и таким образом
EG>> коннект) и тут же процесс перезапустить - ядро начинает посылать пакеты
EG>> ESP размера равными mtu трассы (ну, не более) и данные тут же
EG>> благополучно
EG>> уходят.
EG> Можно даже не обрывать первый процесс/коннект, а параллельно запустить
EG> другой такой же - он, используя верный mtu трассы, благополучно данные
EG> отправляет и завершается, тем временем первых так и продолжает висеть,
EG> периодически перепосылая пакеты размером в 1500 байт и получая в ответ
EG> icmp need-fragment.

Из этого, кстати, вытекает возможность такого "workaround"
(а лучше сказать, костыля): каким-то образом поддерживать в ядре
такой host route с правильным mtu трассы. Пока ничего лучшего,
чем периодический запуск 'dd if=/dev/zero bs=1500 count=1|nc -w1 host discard'
не придумалось :-)

Eugene
--
У норных и малоподвижных животных (слонов, носорогов, тигров, черепах) сортир

в конце туннеля.

Eugene Grosbein

unread,
Mar 3, 2007, 6:43:30 AM3/3/07
to
03 мар 2007, суббота, в 01:03 KRAST, Eugene Grosbein написал(а):

EG> К сожалению, в случае с sendmail-ом получяется фигня - обломившись
EG> по таймауту, он кладет письмо в очередь, а к следующему моменту
EG> разбора очереди, видимо, этот cloned route уже протухает и процесс
EG> начинается с самого начала. В итоге почта так и не уходит никогда.

Hа самом деле cloned route, порожденный механизмом pmtud не имеет
ограниченного времени жизни (rtm_expire нулевой)... Какая-то другая
причина у проблемы.

Eugene
--
Есть еще слова, кроме слова "приказ"

Alexander Kolesnikoff

unread,
Mar 3, 2007, 2:52:10 AM3/3/07
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:
[...]

> EG> Можно даже не обрывать первый процесс/коннект, а параллельно запустить
> EG> другой такой же - он, используя верный mtu трассы, благополучно данные
> EG> отправляет и завершается, тем временем первых так и продолжает висеть,
> EG> периодически перепосылая пакеты размером в 1500 байт и получая в ответ
> EG> icmp need-fragment.
>
> Из этого, кстати, вытекает возможность такого "workaround" (а лучше
> сказать, костыля): каким-то образом поддерживать в ядре такой host route с
> правильным mtu трассы. Пока ничего лучшего, чем периодический запуск 'dd
> if=/dev/zero bs=1500 count=1|nc -w1 host discard' не придумалось :-)

А подправить MSS для этого соединения? ;-)

Alexander

Eugene Grosbein

unread,
Mar 3, 2007, 7:28:50 AM3/3/07
to
03 мар 2007, суббота, в 10:52 KRAST, Alexander Kolesnikoff написал(а):

EG>> Можно даже не обрывать первый процесс/коннект, а параллельно запустить
EG>> другой такой же - он, используя верный mtu трассы, благополучно данные
EG>> отправляет и завершается, тем временем первых так и продолжает висеть,
EG>> периодически перепосылая пакеты размером в 1500 байт и получая в ответ
EG>> icmp need-fragment.
>> Из этого, кстати, вытекает возможность такого "workaround" (а лучше
>> сказать, костыля): каким-то образом поддерживать в ядре такой host route с
>> правильным mtu трассы. Пока ничего лучшего, чем периодический запуск 'dd
>> if=/dev/zero bs=1500 count=1|nc -w1 host discard' не придумалось :-)

AK> А подправить MSS для этого соединения? ;-)

MSS править будет уже ядро, причем совершенно автоматически, исходя
из MTU трассы. Кстати, никаких периодических запусков, оказалось, не надо,
потому что этот host route не протухает на самом деле.

Eugene
--
Пробуй, но не смей глотать

Valentin Nechayev

unread,
Mar 3, 2007, 5:58:03 AM3/3/07
to

>>> Alex Semenyaka wrote:

AK>>> И в IPv4 заставлять маршрутизаторы фрагментировать пакеты -
AK>>> диверсия,
VN>> С чего вдруг?

AS> Зло не фрагментация, зло - отсутствие pMTUd :) Конечно, коль его нету,
AS> фрагментация лучше, чем убиение пакета, но если её нет - лучше.

Я полностью согласен с таким утверждением.:) А вот с AK - не
согласен.

AS> Чтобы потом не искать причину, по которой вдруг вот одна, но зато важная
AS> транзакция не проходит. Hу, вот неизбежный именно в этом случае мелкий
AS> фрагментом транзитным умным файрволом считается подозрительным и грохается.

Хехе. Вспоминается один дешёвый noname свитчик, через который, когда
стали проверять, обнаружили, не ходят пинги на 1600-1800 байт
(приблизительно). Что-то в нём при комбинации "фрагмент с ненулевым
началом" и размером около 300 байт переклинивало, и один этот
фрагмент терялся. В продакшн его нельзя было ставить, потому что он
ещё по другим слабопонятным критериям иногда не пропускал.:((


-netch-

Valentin Nechayev

unread,
Mar 3, 2007, 6:01:04 AM3/3/07
to

>>> Alex Bakhtin wrote:

AK>> Остаюсь при своём мнении: фрагментация на роутерах - зло.
VN>> И в качестве обоснования - пример, который собственно-то возник из
VN>> того, что эту фрагментацию не делают. Великолепно! Так держать!

AB> Фрагментация на роутерах - зло.

Да. Но иногда - необходимое.
На самом деле здесь самая тяжёлая диверсия - то, что needfrag
является ICMP.:(( Даже если ICMP не режется, часто ставится
предельная субполоса на него (например до 5% канала). Если кто-то
один вдруг начинает гнать мусор типа ping flood, страдают все.

AB> При построенной руками, растущими из
AB> плеч, а не из задницы сети фрагментация на роутерах не возникает в
AB> принципе. В данном случае речь про сети ISP, естественно.

Ну это, может, сейчас так. Ещё совсем недавно были привычными
туннели IPIP, в которых с ходу теряется 20 байт из MTU.


-netch-

Valentin Nechayev

unread,
Mar 3, 2007, 6:03:36 AM3/3/07
to

>>> Alex Bakhtin wrote:

AB> Жаловаться в техподдержку провайдера, естественно. Тебя, как клиента,
AB> не должно вообще волновать каким образом они обеспечивают тебе ip mtu 1500
AB> по всей трассе. Я могу вспомнить реально один случай только, когда проблема
AB> на стороне провайдера была нерешаемая - это необходимость положить
AB> EoMPLS в TE туннель. Вообще-то, через такого горе-провайдера не должны
AB> открываться всякие мелкософтовские сервера, типа хотмейла.

Я лично весь этот спич чего-то хочу воспринять как желание всучить
побольше новой цисковской техники с MPLS.;)) Ничего личного, но
утверждение в общем-то просто странное, учитывая, что даже на IPv6
требование стандарта ограничивается MTU 1280. Всё что выше, а тем
более 1500 - добрая воля провайдера.

AK>> (Hадеюсь MTU трассы
AK>> занижается хостами вне твоей административной досягаемости)
EG>> Да.

AB> Ну дык пусть повышают. Никаких технических причин (кроме желания
AB> использовать найденное на помойке оборудование, выпущенное при царе горохе)
AB> для занижения mtu я не вижу. Для завышения - тоже. ping 1500 с установленным df
AB> должен проходить всегда. Как они этого добиваются - не твои проблемы.

Во-во - всем срочно проапгрейдиться.


-netch-

Slawa Olhovchenkov

unread,
Mar 3, 2007, 6:16:12 AM3/3/07