FRAG_TABLE_OVERFLOW

Unanswered Question
Dec 8th, 2011

Периодически в логах на интерфейсе в сторону локальной сети проскакивает такое:

*Dec  8 02:17:50: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/0.200:  the fragment table has reached its maximum threshold 16

На интерфейсе, смотрящим в строну интернета также появлялись такие сообщения, и я ради эксперимента установил на этом интерфейсе:

ip virtual-reassembly max-reassemblies 32

Соответственно теперь, хотя и значительно реже, но все же можно увидеть в логах превышение даже в 32.

С чем это может быть связано?

На сколько это нормальная ситуация?

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

Если эта ситуация может классифицироваться как проблема, то в какую сторону копать для более детального анализа её причин?

Если ещё увеличивать значение max-reassemblies то до каких пределов это увеличение можно считать нормальным и чем вообще чревато такое увеличение?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.4 (5 ratings)
sKruglov Tue, 12/13/2011 - 22:39

Я так понял, что за "Reassembly timeout" успевает накапливаться более чем "max-reassemblies" необработанных пакетов и надо увеличить величину "max-reassemblies". Методом научного тыка выбрано 64 для Интернет-канала в 2Мбит/с.

#sh ip virtual-reassembly dialer 0

Dialer0:

   Virtual Fragment Reassembly (VFR) is ENABLED...

   Concurrent reassemblies (max-reassemblies): 16

   Fragments per reassembly (max-fragments): 32

   Reassembly timeout (timeout): 3 seconds

   Drop fragments: OFF

   Current reassembly count:0

   Current fragment count:0

   Total reassembly count:32609

   Total reassembly timeout count:28

conf t

int d0

ip virtual-reassembly max-reassemblies 64

end

Sergey Goffert Tue, 12/13/2011 - 22:55

Спасибо за ответ!

У меня такое безобразие творится на двух разных железках и разных провайдерах.

В обоих случайх Ethernet.

В первом случае канал 10 Мбит\с на C2821, во втором случае 28 Мбит\с на C3825, причём попорту Gi 0/0.157 - т.е. ошибки появляются именно на отдельном сабинтерфейсе.

Т.е. предлагаете экспериментировать дальше и при наличии необходимости шагать за 64 смело?

sKruglov Tue, 12/13/2011 - 23:07

Я не ЭКСПЕРТ - просто у меня более 40 региональных офисов и в половине случаев пришлось увеличивать до 64 и этого везде оказалось достаточно - работает стабильно. Больших значений ставить не приходилось - возможно что для более скоростных каналов (или менее надежных) 64 будет мало, и придется увеличивать.

Действительно было-бы интересно узнать мнение эксперта: какие величины типичны для 2, 10, 100 Мбит/с и каков разумный предел max-reassemblies ?

Sergey Goffert Tue, 12/13/2011 - 23:27

Ясно. Эксперт, не эксперт, а 40 РО - это какой-никакой, а практический опыт. Значит 64 - нормально живёт и работает.

Мне кажется, нет прямой зависимости кол-ва фрагментированного трафика от ширины канала.

Да, хотелось бы увидеть обещанные комментарии\рекомендации специалистов TAC или иных представителей вендора по данному вопросу, что бы решать подобные задачи с пониманием сути, а не наобум и методом экспериментального тыка.

Eugene Khabarov Tue, 12/13/2011 - 23:39

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

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gt_vfrag.html#wp1047243

Покажите ваш вывод show ip virtual-reassembly

Зачем у вас virtual-reassembly вообще включен на внешнем интерфейсе? На нем используется CBAC? NAT?

Всё это к тому, что может быть есть смысл его выключить, т.к. virtual-reassembly занимает лишнее CPU на сборку покета и память на хранение фрагментов.

sKruglov Wed, 12/14/2011 - 00:18

У меня virtual-reassembly включается сам, так как на интерфейсе есть NAT, и "ip inspect".

#sh ip virtual-reassembly приведен во втором посте (см. переписку выше).

А вот откуда берутся эти фрагменты - я не знаю .
Может действительно выключить "virtual-reassembly"? Чем это чревато?

Sergey Goffert Wed, 12/14/2011 - 00:22

В первом случае на 2821 на том интерфейсе, по которому проскакивают такие сообщения присутствует только NAT. Этот интерфейс смотрит в сторону провайдера, а на локальном интерфейсе никаких проблем нет, хотя VFR также включен, так как этот интерфейс имеет  "ip nat inside", но там даже все каунтеры по VFR нулевые.

#show ip virtual-reassembly:

WAN interface:

   Virtual Fragment Reassembly (VFR) is ENABLED...

   Concurrent reassemblies (max-reassemblies): 16

   Fragments per reassembly (max-fragments): 32

   Reassembly timeout (timeout): 3 seconds

   Drop fragments: OFF

   Current reassembly count:0

   Current fragment count:0

   Total reassembly count:1835517

   Total reassembly timeout count:33887

#sh run int

description ISP1

ip address x.x.x.x m.m.m.m

ip flow ingress

ip nat outside

ip virtual-reassembly

load-interval 30

!

end

Во втором случае на 3825 присутствует и NAT и CBAC на интерфейсе в сторону провайдера и nat inside на локальном интерфейсе. Проблемка проскакивает на обоих интерфейсах.

#sh ip virtual-reassembly

WAN interface:

   Virtual Fragment Reassembly (VFR) is ENABLED...

   Concurrent reassemblies (max-reassemblies): 32

   Fragments per reassembly (max-fragments): 32

   Reassembly timeout (timeout): 3 seconds

   Drop fragments: OFF

   Current reassembly count:0

   Current fragment count:0

   Total reassembly count:5637982

   Total reassembly timeout count:44159

#sh run int

interface GigabitEthernet0/1.157

description ISP1

bandwidth 28000

encapsulation dot1Q 157

ip address x.x.x.x m.m.m.m

ip access-group ACL_IN in

ip nbar protocol-discovery

ip flow ingress

ip flow egress

ip nat outside

ip inspect FIREWALL out

ip virtual-reassembly max-reassemblies 32

logging event subif-link-status

crypto map VPN

service-policy input QoS_ISP1

end

Sergey Goffert Wed, 02/08/2012 - 01:03

хм...ну пожалуйста:

#sh ip traffic

  Frags: 224 reassembled, 1386 timeouts, 0 couldn't reassemble

         235599 fragmented, 529879 fragments, 403 couldn't fragment

(исключил из вывода явно лишную инфу)

Только вот я думаю не в ту сторону копаете...я пришёл к выводу, что ситуация эта сама по себе вызвана была большим количеством NAT-сессий. А если быть точнее, то тем, что некоторые пользователи оказались активными сидерами в пирринговых сетях (ну т.е. торренты раздавали).

В данном случае имеет смысл обращать внимание на вывод команд sh ip nat statistics и sh ip inspect statistics.

Приведу пример такого вывода с одной из железок:

#sh ip inspect statistics - Этот ввод не так интересен, потому как кол-во сессий на этой железке конкретно сейчас весьма малое.

...

TCP reassembly statistics

  received 0 packets out-of-order; dropped 0

  peak memory usage 0 KB; current usage: 0 KB

  peak queue length 0

#sh ip nat statistics

Total active translations: 2874 (11 static, 2863 dynamic; 2874 extended) - текущее кол-во трансляций

Peak translations: 6805, occurred 2w1d ago - пик этого кол-ва, и самое главное время, которое прошло с этого момента (т.е. в данном случае пик в 6805 трансляций был 2 недели и один день назад)

Outside interfaces...

Ну это вот текущая картинка, а например reached its maximum threshold 32 легко достигался при 18000 активных сессий.

Соответственно сообщения в логах (FRAG_TABLE_OVERFLOW), о которых вообщем-то этот топик, почти всегда коррелировали во времени с пиками количества трансляций, что и позволило мне сделать выводы о соответствующей причинно-следственной связи указанной выше... - о как загнул!  =)

Тут же нашлось и хорошее средство борьбы с этим безобразием и также дополнительной диагностики -

ip nat translation max-entries all-host XXX

Такая команда выполненная в глобальном режиме ограничивает максимальное кол-во активных сессий для одного хоста заданным значением XXX.

Почему диагностики? А потому что после установки этого ограничения в выводе команды sh ip nat statistics появляется очень интересный дополнительный раздел "nat-limit statistics"со статистикой по всем хостам и кол-ву сессий у каждого. Т.е. все "качки" сразу как на ладони.

Заметьте! Хост активно разадющий торренты может ничем не выделяться из серой массы по объёмам трафика, но при этом иметь тысячи сессий, нагружающих процессор маршрутизатора. Например при 18000 nat-сессий+QoS+ACL на 3825 cpu-load доходил до 100% и начинались дропы пакетов, хотя трафику при этом было всего-то на 20Мбит\с. Так что это вообщем-то чуть ли не единчтвенное подручное средство выявления злостных сидеров в подобных ситуациях.

Ради эксперимента и диагностики, что бы не рисковать, можно указать заведомо очень большое кол-во сессий на один хост, например 5000:

(config)#ip nat translation max-entries all-host 5000

Жизнь мы этим скорее всего никому не испортим, зато после этого сможем посмотреть вывод статистики nat:

#sh ip nat statistics

...

nat-limit statistics:

All Host Max allowed: 5000

host 172.16.2.172: max allowed 5000, used 90, missed 0 -  разрешено 5000, использовано 90

host 172.16.2.173: max allowed 5000, used 85, missed 0

host 172.16.0.53: max allowed 5000, used 1180, missed 0 -  вот вам и предполагаемый "качок"!

host 172.16.2.116: max allowed 5000, used 1, missed 0

...

Да, вообщем-то в добавок к вышеприведённым оперативным действиям выставить ещё и ip  virtual-reassembly max-reassemblies 64 - я думаю тоже ничего не мешает, это значение в моей практике ещё нигде не превышалось.

Ну вот собственно и весь трабл до копейки!

Жаль, свой собственный пост нельзя пометить как "правильный ответ".

=)

Actions

Login or Register to take actions

This Discussion

Posted December 8, 2011 at 2:45 AM
Stats:
Replies:9 Avg. Rating:4.4
Views:1185 Votes:0
Shares:0
Tags: fragment
+