[Magnum72]

Проблема: Есть ASR1006/RP2/ESP100, на ней в нормальном состоянии прмерно поднято 30000 L2TP сессий. 90% из них роутерщики. В момент времени когда мигает свет на районе? то резко перегружаются от 5000 до 15000 абонентских роутеров. Соответственно они после загрузки одновременно начинают ломится на циску. В принципе циска от такого количества в нормальном состоянии тупит но работает, но в нашем случае на ней еще остались предыдущии сессии от абонентов у которых не вышел еще таймаут.

Что происходит на мой взгляд:

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

В итоге имеем дохлую сессию, и несколько пустых туннелей. Через минуту у циски заканчиваются туннели, и она встает раком.

 

Картина по одному абоненту:

LocTunID        RemTunID        Remote Name 	State   Remote Address  Sessn Count 	L2TP Class/VPDN Group
44685   12184   TL-WDR3600      shutdn  10.1.1.200      0   	no L2TP class
32786   27396   TL-WDR3600      shutdn  10.1.1.200      0   	no L2TP class
62527   31285   TL-WDR3600      shutdn  10.1.1.200      0   	no L2TP class
22557   33586   TL-WDR3600      shutdn  10.1.1.200      0   	3
37286   38833   TL-WDR3600      shutdn  10.1.1.200      0   	no L2TP class
65402   62568   TL-WDR3600      shutdn  10.1.1.200      0   	no L2TP class

 

 

Сейчас лечим так:

 

Блокируем порт 1701, убиваем vpdn и сбрасываем туннели:

conf t

ip access-list extended vpn_client

9 deny udp any any eq 1701

exit

no vpdn enable

end

clear vpdn tunnel l2tp all

 

Поднимаем vpdn:

conf t

vpdn enable

vpdn aaa attribute nas-ip-address vpdn-nas

vpdn-group 3

accept-dialin

protocol l2tp

virtual-template 2

force-local-chap

no l2tp tunnel authentication

exit

 

и начинаем запускать частями народ:

 

conf t

ip access-list extended vpn_client

3 permit udp 10.1.0.0 0.0.127.255 any eq 1701

end

[Oni]

Может это поможет:

call admission new-model
call admission limit 700
call admission cpu-limit 85
call admission vpdn 30 1

[darkagent]

Может это поможет:

Практика показывает что нет.

Расскажу как это наблюдали у себя одно время (call admission, естественно, настроен как надо):

Перезагрузка asr1k (по питанию или еще как, не суть важно), после загрузки начинают массово забиваться l2tp туннели на уровне транспорта (примерно после отметки в 16к туннелей), проц почти моментально показывает уход к отметке 99% и... сразу 0%. При этом наличие vpdn session-limit не влияет никак, умирает процесс l2tp mgmt daemon, и не оживает до следующей перезагрузки asr1k.

TAC рекомендовал обходить эту проблему контролируемым стартом, запуская хомячков не всех сразу, а по частям, в т.ч. с регулированием vpdn session-limit. Личные рекомендации - запускать хомячков по-районно (если есть возможность), сначала безболезненно запускаем 8к, даем 2-3 минуты отдышаться процессам, после чего запускаем следующих с шагом 4к и т.д. Номер кейса не вспомню, но проблема вроде как до сих пор актуальная.

[s.lobanov]

Можно поставить rate-limit и случайную задержку на access-request'ы на радиус-сервере

[Magnum72]

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

 

Может это поможет:

Практика показывает что нет.

Расскажу как это наблюдали у себя одно время (call admission, естественно, настроен как надо):

Перезагрузка asr1k (по питанию или еще как, не суть важно), после загрузки начинают массово забиваться l2tp туннели на уровне транспорта (примерно после отметки в 16к туннелей), проц почти моментально показывает уход к отметке 99% и... сразу 0%. При этом наличие vpdn session-limit не влияет никак, умирает процесс l2tp mgmt daemon, и не оживает до следующей перезагрузки asr1k.

TAC рекомендовал обходить эту проблему контролируемым стартом, запуская хомячков не всех сразу, а по частям, в т.ч. с регулированием vpdn session-limit. Личные рекомендации - запускать хомячков по-районно (если есть возможность), сначала безболезненно запускаем 8к, даем 2-3 минуты отдышаться процессам, после чего запускаем следующих с шагом 4к и т.д. Номер кейса не вспомню, но проблема вроде как до сих пор актуальная.

 

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