solving fragmentation issues
привет, возился с одной проблемкой... похоже, нашел workaround, но хочу свериться с коллективным разумом. Итак: 1. я подключен к домонету по PPPoE 2. и со своего компьютера поднимаю L2TP до работы 3. поэтому на Virtual-Template на LNS@work написал: mtu 1452 <<-- 1500 - PPPoE[8] - IP[20] - UDP[8] - L2TP[12] ip tcp adjust-mss 1412 <<-- MTU[1452] - IP[20] - TCP[20] вроде правильно? но есть проблема с нелинейным ростом загрузки CPU при росте трафика и я для проверки одной из теорий сделал вот такие ACL'и: Extended IP access list 101 10 permit tcp any any fragments Extended IP access list 102 10 permit udp any any fragments (7420 matches) и включал "debug ip packet NNN det", чтобы посмотреть на наличие фрагментации. Как видно из счетчиков, TCP не фрагментируется. А дальше интересно - как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов: Oct 27 03:02:31.176: IP: s=92.249.101.154 (FastEthernet2/1/0), d=62.244.59.200 (Virtual-Access2), len 34, sending last fragment Oct 27 03:02:31.176: IP Fragment, Ident = 14591, fragment offset = 1432 Oct 27 03:02:31.852: IP: s=92.244.112.163 (FastEthernet2/0/0), d=62.244.59.200 (Virtual-Access2), len 34, sending last fragment Oct 27 03:02:31.852: IP Fragment, Ident = 20890, fragment offset = 1432 Исходя из того, что именно в этот момент происходит резкий и довольно серьезный скачок нагрузки на CPU (в процессе IP Input), я делаю вывод, что фрагментация делается именно этим устройством. Поскольку кошка не шибко мощная (7500/VIP4-80), то в качестве workaround было придумано следующее: на интерфейсах, которые смотрят во внешний мир, я поставил "ip mtu 1452", что теоретически привело к смещению функции фрагментации на предыдущее устройство (Sup2/PFC2), которое справляется с этим незаметно для нагрузки. Во-всяком случае, запуск торрента на моем компе больше не приводит к резкому скачку нагрузки. Скажите мне, коллеги - 1) к каким последствиям может привести использованный мною трюк? 2) винда ваще кладет с прибором на мой mtu и ставит свой - 1400. Есть какие-то магические команды у цыски, которые могут сделать винду более сговорчивой в части MTU? Или лучше отталкиваться от MTU 1400 во всей вышеописанной процедуре? 3) как понимать "offset 1432" в дебагах выше? Это ж каким протоколом прикидывается uTorrent? Спасибо. -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/ "Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
интересно - как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов:
Насколько я помню, торренту в настройках можно объяснить MTU, вопрос - поймет ли это *отдающий* торрент, когда ты принимаешь
1) к каким последствиям может привести использованный мною трюк?
Да ни к каким вроде. Для проверки поставь MTU == 500 и посмотри.
2) винда ваще кладет с прибором на мой mtu и ставит свой - 1400. Есть какие-то магические команды у цыски, которые могут сделать винду более сговорчивой в части MTU? Или лучше отталкиваться от MTU 1400 во всей вышеописанной процедуре? 3) как понимать "offset 1432" в дебагах выше? Это ж каким протоколом прикидывается uTorrent?
Забавно. Это надо схемку пакета нарисовать чтоб понять почему именно 1432 и где и почему он режется.
See below On 10/27/2011 9:40 AM, Andrew Stesin wrote:
интересно - как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов: Насколько я помню, торренту в настройках можно объяснить MTU, вопрос - поймет ли это *отдающий* торрент, когда ты принимаешь
теоретически, торрентов и абонентов может быть много разных и каждый не настроишь - приходится выкручиваться средствами сети :)
2) винда ваще кладет с прибором на мой mtu и ставит свой - 1400. Есть какие-то магические команды у цыски, которые могут сделать винду более сговорчивой в части MTU? Или лучше отталкиваться от MTU 1400 во всей вышеописанной процедуре? 3) как понимать "offset 1432" в дебагах выше? Это ж каким протоколом прикидывается uTorrent? Забавно. Это надо схемку пакета нарисовать чтоб понять почему именно 1432 и где и почему он режется.
а в другом тесте, но с тем же компьютером и тем же торрент клиентом, возникала фрагментация на дельте 24 байта. uTorrent - вещь страшная, мимикрирует под что угодно, я с этим сталкивался, когда еще в цыске с SCE баловался :) -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/ "Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
Привет! Ты пробовал менять настройки на utorrent? pref->advanced->net.uTP_dynamic_packet_size =false pref->advanced->net.utp_initial_packet_size = 8 (x 150 = 1200 ) Best wishes, Maxim On 27 Oct 2011, at 02:47, Vladimir Litovka wrote:
как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов:
привет не пробовал - задача состоит не в настройке конкретного торрент-клиента, а в тюнинге сети под подобного рода проблемы. Теоретически, PMTU на стороне конечных узлов должен решать их, но опять же - видимо, не решает. On 10/27/2011 10:20 AM, Maxim Tuliuk wrote:
Привет!
Ты пробовал менять настройки на utorrent?
pref->advanced->net.uTP_dynamic_packet_size =false pref->advanced->net.utp_initial_packet_size = 8 (x 150 = 1200 )
Best wishes, Maxim
On 27 Oct 2011, at 02:47, Vladimir Litovka wrote:
как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов:
-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/ "Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
Hi, PMTUD никогда не работало; об этом написали RFC 2923: TCP Problems with Path MTU Discovery. Вкратце, PMTUD зависит от того получит он ICMP "Fragmentation Needed", если рутер не послал это сообщение или файервол порезал, то получилась PMTUD black hole. Кроме того, если TCP завязан на PMTUD, то тоже получаются интересные эффекты. Проблему пытались решить через RFC 4821 "Packetization Layer Path MTU Discovery", но установка заниженного MTU на CPE обычно решает все проблемы ;) Best wishes, Maxim On 27 Oct 2011, at 09:28, Vladimir Litovka wrote:
привет
не пробовал - задача состоит не в настройке конкретного торрент-клиента, а в тюнинге сети под подобного рода проблемы. Теоретически, PMTU на стороне конечных узлов должен решать их, но опять же - видимо, не решает.
On 10/27/2011 10:20 AM, Maxim Tuliuk wrote:
Привет!
Ты пробовал менять настройки на utorrent?
pref->advanced->net.uTP_dynamic_packet_size =false pref->advanced->net.utp_initial_packet_size = 8 (x 150 = 1200 )
Best wishes, Maxim
On 27 Oct 2011, at 02:47, Vladimir Litovka wrote:
как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов:
-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
"Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
Hi! On Thu, Oct 27, 2011 at 09:56 +0200, Maxim Tuliuk wrote:
Hi,
PMTUD никогда не работало; об этом написали RFC 2923: TCP Problems with Path MTU Discovery. Вкратце, PMTUD зависит от того получит он ICMP "Fragmentation Needed", если рутер не послал это сообщение или файервол порезал, то получилась PMTUD black hole. Кроме того, если TCP завязан на PMTUD, то тоже получаются интересные эффекты.
Ну и в дополнение - активная фрагментация начинается на UDP (торренты и по UDP тоже шмаляют), поэтому PMTUD даже теоретически не влияет.
Проблему пытались решить через RFC 4821 "Packetization Layer Path MTU Discovery", но установка заниженного MTU на CPE обычно решает все проблемы ;)
Best wishes, Maxim
On 27 Oct 2011, at 09:28, Vladimir Litovka wrote:
привет
не пробовал - задача состоит не в настройке конкретного торрент-клиента, а в тюнинге сети под подобного рода проблемы. Теоретически, PMTU на стороне конечных узлов должен решать их, но опять же - видимо, не решает.
On 10/27/2011 10:20 AM, Maxim Tuliuk wrote:
Привет!
Ты пробовал менять настройки на utorrent?
pref->advanced->net.uTP_dynamic_packet_size =false pref->advanced->net.utp_initial_packet_size = 8 (x 150 = 1200 )
Best wishes, Maxim
On 27 Oct 2011, at 02:47, Vladimir Litovka wrote:
как только я включаю uTorrent (я-я, сильная программа), то дебаг начинает ловить сумасшедше много фрагментированных пакетов:
-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
"Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
On 10/27/2011 11:39 AM, Andrey Blochintsev wrote:
PMTUD никогда не работало; об этом написали RFC 2923: TCP Problems with Path MTU Discovery. Вкратце, PMTUD зависит от того получит он ICMP "Fragmentation Needed", если рутер не послал это сообщение или файервол порезал, то получилась PMTUD black hole. Кроме того, если TCP завязан на PMTUD, то тоже получаются интересные эффекты. Ну и в дополнение - активная фрагментация начинается на UDP (торренты и по UDP тоже шмаляют), поэтому PMTUD даже теоретически не влияет.
ну, собственно, проблема именно на UDP трафике и лезет и, видимо, проблема в другом - несмотря на то,что с фрагментацией я разобрался путем описанного мною workaround'а (перенос фрагментации на другое устройство), нагрузка на CPU существенно не снизилась. Похоже, процессор затыкается на генерации L2TP пакетов. Несмотря на то, что в архитектуре 7500 некоторые сервисы (включая L2TP) могут оффлоадиться на VIP, в случае с L2TP этот оффлоад, видимо, касается только добавления протокольных заголовков, а собственно генерация пакета осуществляется на RSP, который на throughput 400Mbps/40Kpps подходит к загрузке ~80% : CPU utilization for five seconds: 82%/79%; one minute: 82%; five minutes: 81% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 40 1124344 44918 25031 1.63% 1.77% 1.79% 0 RSP Background 174 269688 311017 867 1.22% 0.89% 0.82% 0 PPTP Data 97 9188 69849 131 0.08% 0.01% 0.00% 0 CEF process 172 9824 31147 315 0.08% 0.01% 0.00% 0 L2X Data Daemon 5 82680 6106 13540 0.00% 0.13% 0.12% 0 Check heaps FastEthernet2/0/0 is up, line protocol is up 30 second input rate 67978000 bits/sec, 11503 packets/sec 30 second output rate 48043000 bits/sec, 4551 packets/sec FastEthernet2/1/0 is up, line protocol is up 30 second input rate 48656000 bits/sec, 4417 packets/sec 30 second output rate 53403000 bits/sec, 13032 packets/sec FastEthernet3/0/0 is up, line protocol is up 30 second input rate 38961000 bits/sec, 3619 packets/sec 30 second output rate 50264000 bits/sec, 5462 packets/sec FastEthernet3/1/0 is up, line protocol is up 30 second input rate 42668000 bits/sec, 8511 packets/sec 30 second output rate 48946000 bits/sec, 5061 packets/sec -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/ "Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
participants (4)
-
Andrew Stesin -
Andrey Blochintsev -
Maxim Tuliuk -
Vladimir Litovka