Catalyst 3570G, число /24 сетей которые можно пророутить

[sirmax]

Есть сабжевый свитч с загрузкой процессора 90-100%

 

Предпологаю, что из-за вирусной активности на нем появляется куча записей arp incomplete которые забивают ему мозг..

на нем стерменировано порядка 10 000 потенциальнных клиентов (сетями /24) но естественно такого числа реальных маков там нет...

Но если попробовать просканить весь диапазон этих сетей, то естественно на каждый хост он попробует послать запрос...

 

Это пока мысли в слух... кто то сталкивался с таким?

 

Симптомы

CPU utilization for five seconds: 72%/20%; one minute: 89%; five minutes: 87%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   7    13545432   3450787       3925 24.28% 31.90% 28.60%   0 ARP Input

sh mac-addres-table
...
Total Mac Addresses for this criterion: 1082

sh ip traffic
....
ARP statistics:
  Rcvd: 17927004 requests, 11195 replies, 0 reverse, 0 other
  Sent: 995403 requests, 2258268 replies (0 proxy), 0 reverse
  Drop due to input queue full: 100797221
[code]

 

  sh sdm prefer
The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  6K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    8K
    number of directly-connected IPv4 hosts:        6K
    number of indirect IPv4 routes:                 2K
  number of IPv4 policy based routing aces:         0
  number of IPv4/MAC qos aces:                      512
  number of IPv4/MAC security aces:                 1K

 

Ну естествено ни по ACE ни по routes нет превышений

[ingress]

что здесь сказать, сделайте 10к статичных записей, чтобы реквесты не посылались :)

но тогда оно точно умрёт :D

[username]

Mirror одного из каталистовских портов на юникс-сервер,

на юниксе смотришь на этот трафик через tcpdump с аргументами '-vv arp',

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

Edited February 15, 2009 by username

[ktoto]

Mirror одного из каталистовских портов на юникс-сервер,

на юниксе смотришь на этот трафик через tcpdump с аргументами '-vv arp',

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

Ну на крайний случай и мирорить никуда не надо.

По очереди порты вырубать и смотреть загрузку проца.

Найти линк откуда гадят и спускаясь по активке ниже найти злоумышленника уже проблем не составит.

 

[Nafanya]

Mirror одного из каталистовских портов на юникс-сервер,

на юниксе смотришь на этот трафик через tcpdump с аргументами '-vv arp',

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

Ну на крайний случай и мирорить никуда не надо.

По очереди порты вырубать и смотреть загрузку проца.

Найти линк откуда гадят и спускаясь по активке ниже найти злоумышленника уже проблем не составит.

вы представляете что значит вырубать порты по очереди на железке, терминирующей 10к пользователей? :)

ТП повесится.

[Konstantin Klimchev]

Mirror одного из каталистовских портов на юникс-сервер,

на юниксе смотришь на этот трафик через tcpdump с аргументами '-vv arp',

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

Ну на крайний случай и мирорить никуда не надо.

По очереди порты вырубать и смотреть загрузку проца.

Найти линк откуда гадят и спускаясь по активке ниже найти злоумышленника уже проблем не составит.

вы представляете что значит вырубать порты по очереди на железке, терминирующей 10к пользователей? :)

ТП повесится.

неверное не много не так. ИХ повесят. :(

 

[ktoto]

Mirror одного из каталистовских портов на юникс-сервер,

на юниксе смотришь на этот трафик через tcpdump с аргументами '-vv arp',

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

Ну на крайний случай и мирорить никуда не надо.

По очереди порты вырубать и смотреть загрузку проца.

Найти линк откуда гадят и спускаясь по активке ниже найти злоумышленника уже проблем не составит.

вы представляете что значит вырубать порты по очереди на железке, терминирующей 10к пользователей? :)

ТП повесится.

Я подозреваю что ТП и так не легко при лагающем каталисте?

Можно порты мониторить заранее.

Например видим загрузку cpu:

И ищем порты с аномальной активностью:

Соответственно за этим портом и ищем негодяя.

[UglyAdmin]

А броадкасты ограничить не пробовали?

traffic-control broadcast limit XX

[f13]

sh platform tcam utilization

 

[sirmax]

sh platform tcam utilization

нет там превышений

[mschedrin]

sh platform tcam utilization

нет там превышений

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

 

еще надо посмотреть sh ip arp summary - если сильно больше чем активных маков, значит кто-то подбирает.

 

Попробуйте временно включить ip arp inspection и почитать логи этой функции. Сразу будет видно кто может флудить арпами. Хотя я думаю, что дело всё-таки в ткаме.

[sirmax]

Ну, разнес нагрузку на 2 железки (вторая - МЕ-шка), отпустило.

Конечно дело в том что ткама не хватает.. вопрос в том куда он вытек весь )

Но дебагать на боевой точке не хочется..

[rus-p]

Может так получилось, что за время разноса по двум железкам шторм из реквестов прекратился ?

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

 

Есть и другой вариант развития, когда у вас реальные адреса для клиентов и опрашивают со стороны интернета, такие сканы на весь блок адресов идут постоянно с разной интенсивностью. Если суммарно на железке висит большой блок, помогает только такое вот разделение как сделали Вы или умощение железки.

[sirmax]

rus-p

Я списал именно на такие сканы, куча incomplete записей...