Защитить Cisco Router в ix

[bos9]

Планируется применять 6500 в качестве бордера. Будет 1-2 аплинка и 2 IX'а.

С аплинками понятно - линк напрямую в их роутер, из опасностей по сути только направленные атаки извне.

А вот на IX'ах все страшнее - не маленький L2 домен со всеми вытекающими. То loop кто-нибуть смастерит, то span-сессия другого оператора внезапно польётся в наш порт, то еще чего... Очень хочется, чтобы в этих случаях основной сервис (internet) продолжал работать.

Поделитесь наработками! Кто, что предпринимает в этом плане? CoPP? mls rate-limit? storm-control? Буду вдвойне признателен, если с примерами и реальными значениями.

[Alex/AT]

От лавины ARP вас не спасёт ничего, кроме mls qos protocol arp police. То же самое с OSPF и некоторыми другими. Остальное фильтровать на CoPP.

И да - под лавиной сервис всё равно будет деградировать, но по крайней мере не насмерть, и будет возможность отстрела стыка. Еще разумно для таких целей иметь хотя бы GSM-линк к консольке.

[bos9]

Провёл на стенде несколько экспериментов с arp штормами.

 

И в самом деле CoPP с "match protocol arp" не спасает совсем. Проц забивается даже при минимальном rate (32000 bps) да так, что не достучаться даже через консоль.

Судя по счетчикам policy-map control-plane - CoPP полисит arp софтверно, отсюда видимо и низкая эффективность.

 

"mls qos protocol ARP police" с задачей справляется. У меня до значения mls qos protocol ARP police 56000 1750 загрузка проца держалась примерно на 50%. При увеличении rate, загрузка подпрыгивает до 100%, хотя консоль хоть и с тормозами, но остаётся доступной. 56000 bps - это в среднем около 100-150 ARP в секунду, думаю более чем достаточно для уверенной работы в любом IX плюс несколько транзитных не абонентских вланов через железку.

[zi_rus]

mls qos protocol ARP police 56000 1750 загрузка проца держалась примерно на 50%. При увеличении rate, загрузка подпрыгивает до 100%, хотя консоль хоть и с тормозами, но остаётся доступной. 56000 bps - это в среднем около 100-150 ARP в секунду, думаю более чем достаточно для уверенной работы в любом IX плюс несколько транзитных не абонентских вланов через железку.

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

[bos9]

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

 

А в вашем случае железка какую функцию выполняла? По идее, если это бордер (транзитными вланами при форс мажоре можно и пренебреч), то постоянно есть трафик, который обновляет arp cache всех клиентов/аплинков и все будет работать. Некоторые реализации (например linux) правда переодически шлют arp реквесты (наверное для перестраховки), но я думаю даже, если этот arp "застрянет", то входящий траф все равно обновит таймеры кэша.

А какое значение шторм контроля для гигабитных портов используете?

[st_re]

Это в каком месте входящий трафик (не АРП) является источником записей в кеше АРП?

[zi_rus]

А в вашем случае железка какую функцию выполняла? По идее, если это бордер (транзитными вланами при форс мажоре можно и пренебреч), то постоянно есть трафик, который обновляет arp cache всех клиентов/аплинков и все будет работать. Некоторые реализации (например linux) правда переодически шлют arp реквесты (наверное для перестраховки), но я думаю даже, если этот arp "застрянет", то входящий траф все равно обновит таймеры кэша.

А какое значение шторм контроля для гигабитных портов используете?

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

 

на 100М портах 1%, на 1G - 100pps, на самом деле это первые значения которые пришли в голову, но корректировать их еще не приходилось - те клиетны на них не жалуются и шторм притаких значениях то ли больше не приходил, то ли мы его не замечали

 

можно конечно порассуждать, вероятность ситуации когда у клиентов истечет время жизни кеша и при этом возникнет шторм, но зачем, проще просто сделать по-другому, где такой проблемы нет, и просто оно работает

 

и советую не забыть зарезать мультикаст, у меня тут в одном кольце возник igmp storm, положил всю РЕ, пришлось экстренно на все интерфейсы вешать storm-control multicast. ключевое здесь - терминация на этой РЕ, если трафик проходит транзитом во влане, то ничего этой железке не будет, защащиться надо от того что идет на проц (арп или igmp)

[NikAlexAn]

А proxy-arp нельзя выключить?

или включить local-proxy-arp вместо proxy-arp?

 

ещё no ip gratuitous-arps помогает.

 

Нам вроде как помогло.

[bos9]

Это в каком месте входящий трафик (не АРП) является источником записей в кеше АРП?

 

Не совсем правильно выразился, но насколько я помню каждое использование записи arp cache обнуляет её (записи) таймер. Правда есть еще и глобальный таймер для каждой записи по истечении которого запись безусловно удаляется из кэша. Вполне допускаю, что у каждого вендора реализация arp cache хоть чуть-чуть да отличается от вышеописанной.

 

для транзитных вланов весь арп это обычный броадкаст и фильтроваться он будет соответственно.

 

не уверен, что hardware отличает транзитный arp от того, который нужно приземлить на cpu... для этого нужно делать проверку на наличие SVI в влане, в котором получен arp... надо проверить.

 

 

А proxy-arp нельзя выключить?

или включить local-proxy-arp вместо proxy-arp?

 

Выключено. Тут дело не в этом. Включенный proxy-arp может создавать повышенную нагрузку на цпу даже в относительно штатных случаях, а мы говорим про форс-мажор - loop на L2 и как следствие arp storm.

 

Вот интересно... когда создаешь политику qos пишет:

#mls qos protocol arp police 60000 
This overrides the per interface ARP policing

что за per interface ARP policing имеется ввиду?

[zi_rus]

не уверен, что hardware отличает транзитный arp от того, который нужно приземлить на cpu... для этого нужно делать проверку на наличие SVI в влане, в котором получен arp... надо проверить.

а я уверен

если нет svi для определенного влана то аппаратура и не будет свитчить туда трафик.

[srg555]

не уверен, что hardware отличает транзитный arp от того, который нужно приземлить на cpu... для этого нужно делать проверку на наличие SVI в влане, в котором получен arp... надо проверить.

а я уверен

если нет svi для определенного влана то аппаратура и не будет свитчить туда трафик.

 

Да, это поведение "нормальной" "аппаратуры". А бывает всякое убогое говно, которое не выставляет чётких критериев для траппинга фреймов на CPU. Далеко за примерами ходить не надо. Например, dhcp-snooping в коммутаторах huawei S-серии. Настраиваем на коммутаторе dhcp-snooping(в system-view) и в одном из vlan-ов. Потом бросаем dhcp discover на скорости порта в другой влан, весь трафик идёт на CPU и дропается самой CPU, но загрузка проца при этом 100%. Так что, всё надо проверять, если не уверен на 100%. Я не говорю, что производитель huawei - говно, наверняка такая штука есть и многих других вендоров, просто для примера привёл.

[zi_rus]

Я не говорю, что производитель huawei - говно, наверняка такая штука есть и многих других вендоров, просто для примера привёл.

а я говорю, если они позволяют себе такое неадекватное поведение, значит они говно

 

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

[Telesis]

Можно тут посмотреть, может что есть полезного.

AMS-IX

[bos9]

если нет svi для определенного влана то аппаратура и не будет свитчить туда трафик.

 

да, проверил, так оно и есть. интересно, что сама циска пишет по этому поводу:

"Router(config)#mls qos protocol arp police 32000

Note, however, that although this throttling mechanism effectively protects the route processor CPU against such attacks as line-rate ARP attacks, this mechanism does not only police routing protocols and ARP packets to the switch. It also polices traffic through the box and is less granular than CoPP." © http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd802ca5d6.html

[bos9]

Еще немного про ARP:

Four mechanisms have been used, sometimes in
                combination, to flush out-of-date cache entries.

                (1)  Timeout -- Periodically time out cache entries,
                     even if they are in use.  Note that this timeout
                     should be restarted when the cache entry is
                     "refreshed" (by observing the source fields,
                     regardless of target address, of an ARP broadcast
                     from the system in question).  For proxy ARP
                     situations, the timeout needs to be on the order
                     of a minute.

                (2)  Unicast Poll -- Actively poll the remote host by
                     periodically sending a point-to-point ARP Request
                     to it, and delete the entry if no ARP Reply is
                     received from N successive polls.  Again, the
                     timeout should be on the order of a minute, and
                     typically N is 2.

                (3)  Link-Layer Advice -- If the link-layer driver
                     detects a delivery problem, flush the
                     corresponding ARP cache entry.

                (4)  Higher-layer Advice -- Provide a call from the
                     Internet layer to the link layer to indicate a
                     delivery problem.  The effect of this call would
                     be to invalidate the corresponding cache entry.
                     This call would be analogous to the
                     "ADVISE_DELIVPROB()" call from the transport layer
                     to the Internet layer (see Section 3.4), and in
                     fact the ADVISE_DELIVPROB routine might in turn
                     call the link-layer advice routine to invalidate

© http://tools.ietf.org/html/rfc1122#page-22

 

Cisco насколько я вижу придерживается 1-ого механизма, причем таймаут по умолчанию 4 часа. А вот например ядро линукс в том числе использует 2-ой механизм (реализация кэширования ARP в Linux вобще, как оказалось, штука сложная), так что при использовании глобальной политики для ARP во время шторма все Linux based нейборы очень быстро отвалятся. Ввиду этого per interface storm-control на самом деле выглядит выгоднее. По тестам даже level 1 (на гигабитном порту) позволяет предотвратить завал цпу, а это целых 10 мегабит броадкаста.

[zi_rus]

если нет svi для определенного влана то аппаратура и не будет свитчить туда трафик.

 

да, проверил, так оно и есть. интересно, что сама циска пишет по этому поводу:

"Router(config)#mls qos protocol arp police 32000

Note, however, that although this throttling mechanism effectively protects the route processor CPU against such attacks as line-rate ARP attacks, this mechanism does not only police routing protocols and ARP packets to the switch. It also polices traffic through the box and is less granular than CoPP." © http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd802ca5d6.html

 

в другом истчнике видел отсылку на этот документ, что даже как-то засомневался

а проверка точно нормально прошла? лимит в 100 arp и пустить транзитом 10000 не приводит к дропам?

[bos9]

а проверка точно нормально прошла? лимит в 100 arp и пустить транзитом 10000 не приводит к дропам?

 

ну я немного другим путем проверял. убрал все лимиты и пустил транзитом влан с лупом, в который запустил arp. дальше сделил за цпу, пока svi в шатдауне все ок, как только делаешь no shutdown - все встает колом. т.е. я по сути проверял, что оно умеет отличать транзитные arp, а не полисит ли их mls qos.

Edited June 29, 2013 by bos9

[zi_rus]

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