Magnum72 Posted June 9, 2016 Проблема: Есть 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Oni Posted June 9, 2016 Может это поможет: call admission new-model call admission limit 700 call admission cpu-limit 85 call admission vpdn 30 1 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
darkagent Posted June 9, 2016 Может это поможет: Практика показывает что нет. Расскажу как это наблюдали у себя одно время (call admission, естественно, настроен как надо): Перезагрузка asr1k (по питанию или еще как, не суть важно), после загрузки начинают массово забиваться l2tp туннели на уровне транспорта (примерно после отметки в 16к туннелей), проц почти моментально показывает уход к отметке 99% и... сразу 0%. При этом наличие vpdn session-limit не влияет никак, умирает процесс l2tp mgmt daemon, и не оживает до следующей перезагрузки asr1k. TAC рекомендовал обходить эту проблему контролируемым стартом, запуская хомячков не всех сразу, а по частям, в т.ч. с регулированием vpdn session-limit. Личные рекомендации - запускать хомячков по-районно (если есть возможность), сначала безболезненно запускаем 8к, даем 2-3 минуты отдышаться процессам, после чего запускаем следующих с шагом 4к и т.д. Номер кейса не вспомню, но проблема вроде как до сих пор актуальная. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted June 9, 2016 Можно поставить rate-limit и случайную задержку на access-request'ы на радиус-сервере Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Magnum72 Posted June 9, 2016 Еще заметил, когда разом упало 5000 абонентов (при этом они не переподключились, так как там связи еще часа два не было), то циска резко затупила (видимо начала сбрасывать сессии по таймауту), в этот момент я так понимаю начали переподключатся живые сессии, так как вовремя не получили кипалив пакеты, ну и окончательно добили ее. Может это поможет: Практика показывает что нет. Расскажу как это наблюдали у себя одно время (call admission, естественно, настроен как надо): Перезагрузка asr1k (по питанию или еще как, не суть важно), после загрузки начинают массово забиваться l2tp туннели на уровне транспорта (примерно после отметки в 16к туннелей), проц почти моментально показывает уход к отметке 99% и... сразу 0%. При этом наличие vpdn session-limit не влияет никак, умирает процесс l2tp mgmt daemon, и не оживает до следующей перезагрузки asr1k. TAC рекомендовал обходить эту проблему контролируемым стартом, запуская хомячков не всех сразу, а по частям, в т.ч. с регулированием vpdn session-limit. Личные рекомендации - запускать хомячков по-районно (если есть возможность), сначала безболезненно запускаем 8к, даем 2-3 минуты отдышаться процессам, после чего запускаем следующих с шагом 4к и т.д. Номер кейса не вспомню, но проблема вроде как до сих пор актуальная. У меня не циска перегружается, а абоненты падают, и видимо вот эти несколько тысяч упавших сессии, перенапрягают циску и становятся катализатором падения остальных. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...