[andryas]

Решил опробовать старушку 3550 в дикой провайдерской сети очень близко к доступу :)

 

Поиск выдал достаточно больщое количество сообщений о высокой загрузки CPU, связанной с работой arp протокола.

Дабы не ходить по граблям, просьба к бывалым цисководам подсказать по 3550:

 

1. Какой максимальн размер arp-кеша, в часности, какое примерно максимальное количество статических записей поместиться в память. Планирую около 2K, Routing Template. Можно больше, или нужно меньше?

 

2. Каким образом наименее затратно ( с точки зрения ресурсов процессора) заливать в комутатор статические записи arp?

 

3. Насколько ухудшает (и ухудшает ли) производительность ip local-proxy-arp?

 

4. Как научить сабж отвечать не на первый arp-запрос с одного хоста на другой, а только на второй? Надеюсь уменьшить нагрузку на железку при сканировании сети.

[SokolovS]

Использоваться будет как L3? Какая схема подключения? По опыту могу сказать что если использовать IP Unnumbered + ARP Inspection + DHCP Snooping, то 1500 хостов в арп кэше не создавало сильной нагрузки, а еще был включен OSPF с парой соседей.

[andryas]

Схема - сегментация + local proxy arp. По идее, нагрузка должна быть меньше, чем в unnumbered, т.к всего один SVI. Но реально разницу между local proxy arp и proxy arp, думаю, можно увидеть лишь практически. Маршрутизация статическая (всего одна подсеть на железке)

Поскольку пока не всё железо на доступе шибко умное, но умники в сети попадаются, думаю временно буду заливать в железку статические arp. Но вот не уверен в вместительности статического arp кеша.

[SokolovS]

Зачем статический кэш? Включите DHCP Snooping и ARP Inspection и выдавайте IP по MAC адресу. Так оно удобней будет. При смене IP или MAC юзером, весь его трафик будет заблокирован. Мы вместо сегментации делаем каждый порт в свой SVI и включаем ip unnumbered. Нагрузки большой нет. Если у вас всего 2000 юзеров на этой железке, то будет все нормально, если это количество активных то для нее это много.

[andryas]

По 2000 вообще на каждую. Статический кеш, кроме всего прочего, должен сильно уменьшить количество ARP в сети.

У Вас какой процесс занимает бОльшую часть ресрсов CPU?

[SokolovS]

У нас максимальная загрузка была от OSPF. Сейчас у нас нет таких узлов, где на c3550 много абонентов повешено. Схема у нас все таки немного другая была, на доступе у нас сегментации не было. Вот скорее всего проксирование ARP и съест кучу ресурсов! Я бы оставил сегментацию на доступе + еще бы разбил на отдельные VLAN все порты + включил бы ip unnumbered. Проксирования ARP при этом не будет, т.к. циска всегда будет отвечать своим маком.

 

А со статической таблицей боюсь замучаетесь, обновлять каждый раз при регистрации нового хоста ((

Edited December 18, 2012 by SokolovS

[andryas]

Ну в крайнем случае переделаю на unn, немного переделывать. Сейчас мне больше подходит такая архитектура.

 

Как боролись с флудом от клиентов? Тестировал, всего 30-40к пакетов в сторону IP интерфейса 3550 вводит её процессор в полную загрузку.

[SokolovS]

Какого типа эти пакеты? Если броадкаст, так он на доступе отфильтровывается. Чтобы 3550 начала грузиться эти пакеты должны подлежать обработке, как в случае с ARP или DHCP (когда релей поднят), но это все броадкаст и свыше нормы будет отфильтровано уже на абонентском порту.

[andryas]

Сервера я тестировал утилитой udpflood.exe, когда-то, лет 5 назад, встретил её на этом форуме.

 

 

Флудил на IP интерфейс комутатора, 40-50kpps. В качестве источника флуда могут выступать подгоревшие свичи, неудачные модели роутеров. Фильтрация на доступе даёт ощутимый эффект, но у меня не все свитчи доступа умеют фильтрировать.

С помощю ACL полностью отрезал доступ к свитчу, заргузка уменьшается, но только при ширине полосы флуда до 30-40 мбит. Дальше загрузка растёт до 40-50% и выше.

[dmvy]

28 SVI + local proxy arp + 4500 dynamic arp = полет нормальный.

9#sh processes cpu history

   2222111111111133333555552222222222111111111122222111112222
   0000999999999900000333331111100000999999999933333999992222
100
90
80
70
60
50                    *****
40                    *****
30               **********
20 **********************************************************
10 **********************************************************
  0....5....1....1....2....2....3....3....4....4....5....5....
            0    5    0    5    0    5    0    5    0    5
              CPU% per second (last 60 seconds)

   5454444456345599454566874444644465994444444443444454349454
   3568454914961099988600652066084524997777244527334233829131
100               **                  **                  *
90               **      *           **                  *
80               **      **          **                  *
70               **      **          **                  *
60   *      *    ** * *****    *   * **                  #
50 **** * *** ****#********  **** ***#*****   *      *   # *
40 ***************#******************##******************#***
30 **************##*#*#*###****#***#####*####*#*##***##**#*#*
20 ##########################################################
10 ##########################################################
  0....5....1....1....2....2....3....3....4....4....5....5....
            0    5    0    5    0    5    0    5    0    5
              CPU% per minute (last 60 minutes)
             * = maximum CPU%   # = average CPU%

   9999999999999999999999999999999999999999999999999999999999999999999999
   9999999999999999999999999999999999999999999999999999999999999999989999
100 **********************************************************************
90 **********************************************************************
80 **********************************************************************
70 **********************************************************************
60 **********************************************************************
50 **********************************************************************
40 **********************************************************************
30 ##*********************###*********************###********************
20 ############*******#################********################********##
10 ######################################################################
  0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
            0    5    0    5    0    5    0    5    0    5    0    5    0
                  CPU% per hour (last 72 hours)
                 * = maximum CPU%   # = average CPU%

#sh ip arp summary
4548 IP ARP entries, with 540 of them incomplete

CPU utilization for five seconds: 20%/6%; one minute: 22%; five minutes: 23%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
 97    28394580  93723512        302  4.79%  4.90%  5.22%   0 IP Input
  8    22473616  28731512        782  2.63%  3.41%  3.65%   0 ARP Input
100    18913976  59208205        319  2.39%  2.45%  2.52%   0 ADJ resolve proc
 63     9988536  48941606        204  0.95%  1.11%  1.15%   0 VUR_MGR bg proce
 60     8409368   4608110       1824  1.35%  1.02%  1.00%   0 L3MD_STAT
172     3451444   1151299       2997  0.39%  0.47%  0.47%   0 CEF: IPv4 proces
 55     2842680   1427898       1990  0.39%  0.36%  0.37%   0 Vegas Statistics
192    10082224    216980      46466  0.00%  0.01%  0.25%   0 SNMP ENGINE
 64     1284836    741189       1733  0.15%  0.20%  0.24%   0 PI MATM Aging Pr

 

пики загрузки - раз в 20 минут снимается arp-таблица.

 

кстати, arp timeout 240 секунд.

[andryas]

2 dmvy, спасибо, это очень радует. Какие-то необычные грабли были?

Можно попросить (хотя-бы в личку) вырезку конфига?

 

И ещё вопрос: зачем так много SVI?

[namake]

Использоваться будет как L3? Какая схема подключения? По опыту могу сказать что если использовать IP Unnumbered + ARP Inspection + DHCP Snooping, то 1500 хостов в арп кэше не создавало сильной нагрузки, а еще был включен OSPF с парой соседей.

Сколько у Вас на ней svi заведено?