Что происходит, когда кеш ARP переполняется?

В по крайней мере одной реализации существует жесткий предел пропускной способности таблицы ARP. Что происходит, когда кеш ARP заполнен и пакет предлагается с местом назначения (или следующего перехода), которое не кэшируется? Что происходит под капотом и каково влияние на качество обслуживания?

Например, маршрутизаторы Brocade NetIron XMR и Brocade MLX имеют конфигурируемый ip-arp максимальный уровень . Значение по умолчанию в этом случае равно 8192; размер подсети. Из документации не ясно, является ли это для интерфейса или для всего маршрутизатора, но для целей этого вопроса мы можем предположить, что это для интерфейса.

Немногие сетевые пользователи будут настраивать //подсеть на интерфейсе по назначению, но это не то, что произошло. Мы перенесли основной маршрутизатор с модели Cisco на Brocade. Одним из многих различий между Cisco и Brocade является то, что Cisco принимает статические маршруты, которые определяются как исходящим интерфейсом, так и адресом следующего хоста, но Brocade настаивает на том или ином. Мы сбросили адрес следующего перехода и сохранили интерфейс. Позже мы узнали ошибку наших способов и изменили с интерфейса на адрес следующего перехода, но все, казалось, работало изначально.

+----+ iface0    +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1       .2+----+
      10.0.0.0/30

До миграции R1 был Cisco и имел следующий маршрут.

ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2

После миграции R1 был Brocade и имел следующий маршрут.

ip route 10.1.0.0 255.255.0.0 iface0

R2 является маршрутизатором Cisco, а маршрутизаторы Cisco выполняют прокси-сервер ARP по умолчанию. Это (неверная) конфигурация в производстве, которая заложила основу для того, что оказалось переполнением кеша ARP.

  1. R1 получает пакет, предназначенный для сети 10.1.0.0/16.
  2. На основе маршрута статического интерфейса R1 ARP для адресата в iface0
  3. R2 распознает, что он может достичь адресата и отвечает на ARP своим собственным MAC.
  4. R1 кэширует результат ARP, который объединяет IP-адрес в удаленной сети с MAC-адресом R2.

Это происходит для каждого отдельного пункта назначения в 10.1.0.0/16. Следовательно, несмотря на то, что /16 должным образом подключен за пределы R2, и на ссылке, примыкающей к R1 и R2, есть только два узла, R1 страдает перегрузкой кеша ARP, поскольку он побуждает R2 вести себя так, как если бы все адреса 65k были напрямую связаны.

Причина, по которой я задаю этот вопрос, состоит в том, что я надеюсь, что это поможет мне разобраться в сообщениях о проблемах с сетевыми сервисами (дни спустя), что привело нас в конечном итоге к переполненному кешу ARP. В духе модели StackExchange я попытался переделать то, что, по моему мнению, является четким, конкретным вопросом, на который можно ответить объективно.

РЕДАКТИРОВАТЬ 1 Чтобы быть ясным, я спрашиваю о части слоя клея между линией передачи данных (уровень 2) и сетью (уровень 3), а не таблицей переадресации MAC в пределах уровня канала передачи данных. Хост или роутер строит первый для сопоставления IP-адресов MAC-адресам, а коммутатор строит последний для сопоставления MAC-адресов портам.

РЕДАКТИРОВАТЬ 2 . Хотя я высоко оцениваю усилия, с которыми ответчики пришли объяснить, почему некоторые реализации не подвержены переполнению кеша ARP, я считаю, что для этого вопроса важно решить те, которые есть. Вопрос заключается в том, «что происходит, когда», а не «является продавцом X восприимчивым к». Теперь я сделал свою часть, описав конкретный пример.

РЕДАКТИРОВАТЬ 3 Другой вопрос: «Как предотвратить переполнение кэша ARP?»

12 голосов | спросил neirbowj 13 J000000Saturday13 2013, 00:51:12

6 ответов


4

Изменить 2 :

Как вы упомянули ...

ip route 10.1.0.0 255.255.0.0 iface0

Принуждает Brocade к proxy-arp для каждого адресата в 10.1.0.0/16, как если бы он был напрямую подключен к iface0.

Я не могу ответить на вопрос о реализации кэша ARP от Brocade, но я просто хотел бы указать на простое решение вашей проблемы ... настроить свой маршрут по-другому:

ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP

Делая это, вы запрещаете Brocade из ARP-ing для всех 10.1.0.0/16 (обратите внимание, вам может потребоваться перенумеровать связь между R1 и R2, чтобы быть вне 10.1.0.0/16, в зависимости от реализации Brocade вещей).


Оригинальный ответ :

  

Я ожидаю, что в большинстве или даже во всех реализациях существует жесткий предел пропускной способности таблицы ARP.

Маршрутизаторы CPU Cisco IOS ограничены только количеством DRAM в маршрутизаторе, но это, как правило, не будет ограничивающим фактором. Некоторые переключатели (например, Catalyst 6500) имеют жесткое ограничение в таблице смежности (которая коррелирует с таблицей ARP); Sup2T имеет 1 миллион примыканий .

  

Итак, что происходит, когда кеш ARP заполнен и пакет предлагается с адресатом (или следующим-хопом), который не кэшируется?

Маршрутизаторы Cisco IOS CPU не имеют места в таблице ARP, потому что эти ARP хранятся в DRAM. Предположим, вы говорите о Sup2T. Подумайте об этом так, предположите, что у вас есть Cat6500 + Sup2T, и вы настроили все возможные Vlans, технически это

4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans

Предположим, что вы делаете каждый Vlan a /24 (так что это 252 возможных ARP), и вы упаковываете каждый Vlan полный ..., который составляет 1 миллион записей ARP.

4094 * 252 = 1,030,680 ARP Entries

Каждый из этих ARP будет потреблять определенный объем памяти в самой таблице ARP плюс таблицу смежности IOS. Я не знаю, что это такое, но предположим, что общая нагрузка ARP составляет 10 байт ...

Это означает, что вы теперь потребляли 10 МБ для служебных расходов ARP; это все еще не очень много места ... если бы вы были настолько низким по памяти, вы бы увидели что-то вроде %SYS-2-MALLOCFAIL.

С учетом того, что много ARP и четырехчасовой тайм-аут ARP, вам придется обслуживать в среднем почти 70 ARP в секунду; более вероятно, что обслуживание на 1 миллион записей ARP приведет к утечке CPU маршрутизатора (возможно, сообщения CPUHOG).

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

ответил Mike Pennington 15 J000000Monday13 2013, 15:07:28
2

Только реальный опыт, который я имел с этим случаем, был на коммутаторах C3550 (ограничение 2-8k MAC, в зависимости от шаблона sdm), и там он удалил самую старую запись из таблицы.

ответил 13 J000000Saturday13 2013, 01:39:41
2

Для IOS и JunOS и других коммерческих стеков вам просто нужно проверить, это не очень сложно.

Но для linux , freebsd, netbsd, openbsd, uIP, lwIP и, возможно, многие другие реализации, вы можете просто проверить их исходный код для поведения.

В Linux вам нужно проверить 'net /core /neighbour.c' (начать с строки 'if (entries> = tbl-> gc_thresh3' || ') и' net /ipv4 /arp.c '.
В Linux у вас есть три полных уровня

  1. gc_thresh1 - ничего не сделано, пока это не будет нажато
  2. gc_thresh2 - мгновенно можно нанести удар
  3. gc_thresh3 - этот размер не может быть превышен

Когда gc_thresh3 пытается превзойти, он пытается принудительно запустить сбор мусора, если только он не был запущен в последнее время. Кажется, что сбор мусора удаляет записи, которые больше не упоминаются, поэтому не означает старейший или новейший, однако gc_staletime превышает один из способов записи разыменования, что снова переводится как самая старая запись. Если сбор мусора не может быть запущен, новая запись просто не добавляется. Все эти gc_threshN и периодические интервалы сбора мусора могут быть настроены.
Код - это семейство адресов (ipv4, ipv6) агностик, поэтому таблицы ARP для IPv6 ND и IPv4 обрабатываются с помощью одного и того же кода, а не дублирующего пути.

ответил ytti 13 J000000Saturday13 2013, 11:16:37
1

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

ответил fredpbaker 13 J000000Saturday13 2013, 01:25:57
1

Коммутатор переходит к ARP для этого IP-адреса получателя, чтобы получить его MAC-адрес (который также заполнил бы таблицу CAM ответом). Запрос ARP передается всем портам. Для этого требуется процессор и включает в себя процесс ARP Input. Если ARP-запросы предназначены для одного и того же IP-адреса, из-за того, что таблица ARP переполняется часто, коммутатор должен ограничивать скорость ARP раз в две секунды. Если запросы на случайные IP-адреса достаточно часто, CPU может всплывать, поскольку этот процессор задействован как в ARP-запросах, так и в ответах.

ответил generalnetworkerror 13 J000000Saturday13 2013, 12:32:38
1

Из атак, которые я узнал по коммутаторам Cisco 3550, 3560 и т. д., вы можете превратить их в гигантский концентратор после перегрузки предела MAC-адреса. Коммутаторы имеют установленный предел MAC-адреса (около 6000), который может быть сохранен, и как только этот предел будет достигнут, он наполнит все данные своими интерфейсами. Не помню, идет ли речь о пакетах 802.1q, потому что мне не пришлось делать это за долгое время. Может потребоваться запустить мою сетевую лабораторию дома, чтобы узнать.

ответил SysEngT 15 J000000Monday13 2013, 16:36:47

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132