По крайней мере, в одной реализации существует жесткое ограничение емкости таблицы ARP. Что происходит, когда кэш ARP заполнен и пакет предлагается с пунктом назначения (или следующим переходом), который не кэшируется? Что происходит под капотом и как влияет на качество обслуживания?
Например, маршрутизаторы Brocade NetIron XMR и Brocade MLX имеют максимум настраиваемой ip-arpсистемы . Значением по умолчанию в этом случае является 8192; размер подсети а / 19. Из документации не ясно, относится ли это к интерфейсу или ко всему маршрутизатору, но для целей этого вопроса можно предположить, что это для интерфейса.
Немногие сетевые узлы специально настроили бы подсеть / 19 на интерфейсе, но этого не произошло. Мы переносили основной маршрутизатор с модели 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 был парчой и имел следующий маршрут.
ip route 10.1.0.0 255.255.0.0 iface0
R2 является маршрутизатором Cisco, и маршрутизаторы Cisco по умолчанию выполняют прокси-ARP . Это (неправильная) конфигурация в производстве, которая подготовила почву для того, что оказалось переполнением кэша ARP.
- R1 получает пакет, предназначенный для сети 10.1.0.0/16.
- На основе статического маршрута интерфейса R1 ARP для пункта назначения на
iface0 - R2 распознает, что он может достичь пункта назначения, и отвечает на ARP своим собственным MAC.
- 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, я чувствую, что для этого вопроса важно ответить на те, которые есть. Вопрос заключается в том, «что происходит, когда», а не « подвержен ли поставщик Х ». Я сделал свою часть сейчас, описав конкретный пример.
РЕДАКТИРОВАТЬ 3 Другой вопрос, который это не так: «Как я могу предотвратить переполнение кэша ARP?»