Что происходит с таблицей arp cisco

Случай №1. Secondary IP-адрес у провайдера

Подключали к провайдеру межсетевой экран Cisco ASA. Подключение прошло успешно и все сервисы работали корректно. Однако через некоторое время связь пропадала. Детальный анализ показывал, что если инициировать исходящее соединение, то оно работает стабильно (трафик ходит в обе стороны). Проблема появляется только со входящими соединениями из сети Интернет (например, удалённое подключение к маршрутизатору). При этом прослеживается прямая зависимость входящих соединений от исходящих: если есть исходящие соединения, то и входящие соединения начинают корректно работать. Однако, по прошествии некоторого времени подключиться удалённо или «пропинговать» устройство из Интернета снова не удаётся.

Так как с физическим и канальным уровнем предположительно всё в порядке, мы стали проверять работу ARP. Запустили debug arp на ASA и попробовали очистить arp-cache. По debug-сообщениям увидели, что ASA корректно отправляет ARP-запрос и без проблем получает ARP-ответ от провайдера. В данном примере IP нашей ASA 80.X.X.4, её MAC-адрес a0ec.****.****, IP-шлюза провайдера 80.X.X.1, MAC-шлюза провайдера aa43.****.****:

arp-send: arp request built from 80.X.X.4 a0ec.****.**** for 80.X.X.1 at 978772020 arp-refresh: Trying to refresh ARP for outside 80.X.X.1 arp-in: response at outside from 80.X.X.1 aa43.****.**** for 80.X.X.4 a0ec.****.**** having smac aa43.****.**** dmac a0ec.****.****\narp-set: added arp outside 80.X.X.1 aa43.****.**** and updating NPs at 978772020 arp-in: resp from 80.X.X.1 for 80.X.X.4 on outside at 978772020 

Однако, через какое-то время заметили сообщение в debug arp на ASA:

arp-in: request at outside from 195.Y.Y.1 aa43.****.**** for 80.X.X.4 0000.0000.0000 having smac aa43.****.**** dmac ffff.ffff.ffff\narp-in: Arp packet received from 195.Y.Y.1 which is in different subnet than the connected interface 80.X.X.4/255.255.255.0 

Судя по данному сообщению ASA получает ARP-запрос с верным Sender MAC Address aa43.****.**** но неверным Sender IP Address – 195.Y.Y.1. Данный некорректный ARP-запрос ASA отбрасывает и не отправляет ARP-ответ.

Таким образом, когда существует исходящий трафик, ASA отправляет ARP-запрос (при необходимости, когда соответствующая запись в ARP-таблице ASA требуется обновления) в сторону провайдера и получает ARP-ответ. Благодаря ARP-запросу от ASA оборудование провайдера также получает запись об ASA в своей ARP-таблице. Однако, когда исходящий трафик от ASA отсутствует продолжительное время и ASA не отправляет ARP-запрос, на оборудовании провайдера в ARP-таблице запись об ASA истекает. Оборудование провайдера пробует обновить запись, отправляя ARP-запрос, но ответ не получает. Отсюда и появляются «плавающие» проблемы со связью.

Осталось понять, почему оборудование провайдера отправляет ARP-запрос с неверным Sender IP Address. Позже провайдер проверил данную ситуацию со своей стороны и даже показал дамп ARP-трафика, который подтверждал debug-сообщения ASA:

324: 22:03:41.056546 802.1Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1 325: 22:03:41.937329 802.1Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1 326: 22:03:42.822909 802.1Q vlan#2 P0 arp who-has 80.X.X.4 tell 195.Y.Y.1 

Оказалось, что на интерфейсе провайдера адрес 195.Y.Y.1 был настроен как основной, а IP-адрес 80.X.X.4, который являлся для нас шлюзом по умолчанию, был настроен как secondary. Эта настройка полностью объясняла ситуацию. В данном случае проблема была решена добавлением статической ARP-записи на оборудовании провайдера.

Абсолютно аналогичная ситуация у нас возникала на другой площадке, когда мы использовали для подключения к провайдеру маршрутизатор Cisco. На оборудовании провайдера наш шлюз был также настроен как seconday IP-адрес. В этом случае, чтобы ускорить процесс решения проблемы, мы добавили на маршрутизаторе secondary IP-адрес из той же подсети, что и основной IP-адрес на интерфейсе провайдера. После этого наш маршрутизатор стал успешно отвечать на ARP-запросы со стороны провайдера, так как на нашем интерфейсе появился IP-адрес из той же подсети, что и адрес в ARP-запросе.

Случай №2. ARP-несовместимость

Перед нами была поставлена задача в одном из офисов заменить маршрутизатор Cisco ISR на межсетевой экран Cisco ASA. Межсетевой экран ASA предварительно был настроен и отправлен в точку установки. После подключения к провайдеру Cisco ASA оказался недоступным для удалённого подключения. На первый взгляд на устройстве всё работало корректно. Межсетевой экран ASA корректно определял MAC адрес маршрутизатора провайдера с помощью стандартной процедуры ARP-запрос/ARP-ответ. Пакеты уходили с внешнего интерфейса устройства в Интернет. При этом в обратную сторону на ASA ничего не приходило. Этот факт фиксировался встроенными средствами перехвата пакетов (packet capture).

После обращения к провайдеру было установлено, что пакеты от ASA успешно доставлялись на оборудование провайдера, также провайдер видел ответные пакеты, приходящие с вышестоящего оборудования. После того как был обратно подключен маршрутизатор, трафик снова начал ходить корректно в обе стороны. Это означало, что проблема где-то на стыке между провайдером и межсетевым экраном ASA. После повторного обращения к провайдеру с детальным описанием проблемы было определено, что оборудование провайдера не видит MAC адрес межсетевого экрана ASA. Собранный демо-стенд доказал корректность работы ASA (роль провайдера играл маршрутизатор Cisco). По какой-то причине устройство провайдера не заносило запись об ASA в ARP-таблицу после получения ARP-ответа от ASA. Самое интересное, что ARP-запрос, поступающий от Cisco ASA не отбрасывался. Оборудование провайдера корректно отвечало на ARP-запрос от ASA, но также, не заносило запись ASA в ARP-таблицу.

В итоге провайдеру было предложено сделать статическую привязку в таблице ARP. Данный случай показал несовместимость по ARP оборудования провайдера с межсетевым экраном Cisco ASA. К сожалению, провайдер не озвучил производителя своего оборудования.

Случай №3. Gratuitous ARP

И опять подключаем к провайдеру Cisco ASA. В этот раз вместо сервера MS TMG. Особенность данного случая в том, что MS TMG был подключен к устройству провайдера через L2-коммутатор. Предполагалось подключение ASA также через L2-коммутатор:

Итак, отключаем MS TMG и вместо него в тот же порт L2-коммутатора подключаем Cisco ASA. Видим стандартную ситуацию: с внешнего порт Cisco ASA трафик уходит, но ответные пакеты отсутствуют. После обращения к провайдеру выясняется, что оборудование провайдера по-прежнему видит MAC-адрес сервера MS TMG за IP-адресом, перешедшим на Cisco ASA.

Дальнейшее разбирательство показало, что межсетевой экран Cisco ASA не шлёт Gratuitous ARP сообщение при переходе интерфейса из состояния DOWN в состояние UP. А так как оборудование провайдера подключено через L2-коммутатор, при смене устройства на нашей стороне канал до провайдера не падает, и интерфейс маршрутизатора провайдера всегда остаётся во включенном состоянии. Единственный способ своевременно оповестить провайдера о том, что на нашей стороне изменилось устройство и MAC-адрес, – Gratuitous ARP. В противном случае, придётся ждать таймаута ARP-записи у провайдера, а это как, как правило, 4 часа.
В данном случае мы сделали на интерфейсе Cisco ASA команды no ip address, ip address x.x.x.x y.y.y.y. После этого ASA всё же отправила Gratuitous ARP, и всё взлетело.

В данной статье, состоящей из двух частей, я постарался рассмотреть тонкости работы ARP на оборудовании Cisco в случаях использования трансляции сетевых адресов (NAT), а также функционал Proxy ARP. Разобрал отличия в работе ARP между маршрутизаторами Сisco и межсетевыми экранами Cisco ASA. В заключении статьи я рассмотрел проблемы, возникающие при подключении к Интернет-провайдеру, обусловленные работой ARP.

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

Жду комментарии. Может быть кто-то сможет рассказать собственные интересные случаи, связанные с работой ARP.

• Блог компании CBS
• Системное администрирование
• IT-инфраструктура
• Cisco
• Сетевые технологии

Как посмотреть arp таблицу в Cisco

Добрый день уважаемые коллеги, сегодня мы разберем вот такой вопрос. Все вы прекрасно знаете, что такое arp таблица, и для чего используется, немного напомню, что ее ведут операционные системы и сетевые устройства второго уровня OSI, в которой каждому ip адресу соответствует mac адрес. Так как устройства общаются именно по мак адресам. Для того чтобы посмотреть arp таблицу в Cisco, нужно воспользоваться командой

sh arp

Выведется вся arp таблица, в которой есть поля как протокол, ip адрес, mac адрес, vlan.

Как посмотреть arp таблицу в Cisco-01

Можно посмотреть arp таблицу для конкретного vlan

sh arp vlan 1

Как посмотреть arp таблицу в Cisco-02

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

sh arp summary

Популярные Похожие записи:

• Импорт таблицы на веб-странице в Google Sheets
• Что такое виртуальный сетевой адаптер и в каких случаях он может пригодиться?
• Как сделать сводную таблицу, за минуту
• Использование таблиц в качестве шаблонов в базе данных Azure для PostgreSQL
• Настройка сети в CentOS 8, за минуту
• Поиск mac-адреса на DHCP с помощью PowerShell

Июн 3, 2017 17:25 Автор — Сёмин Иван

3 Responses to Как посмотреть arp таблицу в Cisco

vmware-user :
Спасибо теперь буду знать как выглядит arp таблица cisco

Добрый день! Есть Cisco catalist 2970, есть MS NLB, необходимо создать статические записи в таблице MAC адресов и ARP записи
Пробовал
arp 10.0.0.133 03bf.0a21.0070
mac-address-table static 03bf.0a21.0070 vlan 1 interface GigabitEthernet0/18 Не понимает эти команды! Можете, что подсказать? Не приходилось с балансировщиком сталкиваться?

Иван Семин :

Для начала я бы посоветовал вам его обновить, с балансировкой не сталкивался, но могу у приятеля спросить

Добавить комментарий

Поиск по сайту

Подписка на youtube канал

Выберите рубрику

Active directory, GPO, CA Android Apple ASUS, Sony VAIO CentOS Cisco, Mikrotik Debian, FreeBSD DNS Exchange, Power Shell HP/3Com Hyper-V IBM IIS и FTP, web и seo Juniper Lenovo, intel, EMC, Dell Microsoft Office Microsoft SQL server, Oracle Microsoft System Center NetApp Network, Телефония News Raid, LSI, Adaptec Supermicro Ubuntu Utilities Veeam Backup & Replication, Windows Server Backup Vmware, VirtualBox Windows 7 Windows 8/8.1 Windows 10, Windows 11 Windows 2008/2008 R2 Windows 2012/2012 R2 Windows Server 2016, Windows Server 2019, Windows Server 2022 WordPress, 1C Битрикс Безопасность, Kali СХД Сертификация перед сном

Подписка не Telegram

Последние записи

• Get-ADGroup: Управление группами Active Directory
• Get-ADUser и примеры использования
• Ошибка: There is a problem loading the Widget resources
• Как запустить скрипт PowerShell на удаленном компьютере через SCCM
• Служба 1С отображается абракадаброй

Артём Санников

Данная книга является руководством для начинающих специалистов в области анализа и обработки данных. В книге рассматривается язык SQL и его процедурное расширение PL/SQL от компании Oracle.

Главная › Cisco › Cisco Packet Tracer › Вывод таблицы ARP на устройстве. Cisco packet tracer.

Вывод таблицы ARP на устройстве. Cisco packet tracer.

Чтобы вывести таблицу ARP на маршрутизаторе или коммутаторе, необходимо выполнить команду show arp в CLI.

Router> en // переход в привилегированный режим EXEC
Router# show arp // выводим таблицу ARP
Router#

Результат выполнения команды show arp.

Записи по теме

• Запрет на передачу данных для MAC-адресов. Cisco packet tracer.
• Запись MAC-адреса в рабочую конфигурацию. Cisco packet tracer.
• Время старения MAC-адреса. Cisco packet tracer.
• Количество MAC-адресов на порт устройства. Cisco packet tracer.
• Активация функции port-security. Cisco packet tracer.
• Исключение IP-адреса из пула DHCP. Cisco packet tracer.
• Адрес домена для пула DHCP. Cisco packet tracer.
• Срок аренды IP-адреса для пула DHCP. Cisco packet tracer.

Семейка протокола ARP

Многие думают, что если протокол мелкий и незаметный, то про него не надо ничего знать. Нетрудно догадаться, что это не так, и именно детальное знание подобных низкоуровневых и “простых” технологий является тем, что отличает профессионала от гуглоиксперта или фанатика, верующего, что в его любимой ОС всё работает “само по себе и априори идеально”.

Чуть-чуть поговорим о протоколах семейства ARP – обычно они не изучаются, и лишь поверхностно проводится обзор протокола ARP, на уровне рамочного понимания функционала – ну, а мы посмотрим, какие ещё варианты бывают.

Семейка протоколов ARP

• Протокол ARP
  • Вкратце про сам протокол и формат заголовка
  • Базовые настройки и тюнинг – тайм-ауты и кэш
  • ARP и QoS
  • ARP и NLB
  • ARP и SNAP
  • ARP и NUD
  • ARP и DAD
  • ARP и WOL
  • ARP и РПГ-7

  Как работает протокол ARP

  Протокол Address Resolution Protocol (ARP) используется для простой задачи – выяснить по известному адресу сетевого уровня (IPv4) неизвестный адрес канального уровня (обычно это MAC-адрес 802.3, но возможны и другие варианты).

  Данные ARP вкладываются в протокол канального уровня (что напрямую, что через SNAP-заголовок) и являются, если рассуждать по логике “уровень протокола определяется по глубине вложения”, уже не протоколом канального уровня, а вот по функционалу ARP остаётся протоколом канального уровня, т.к. работает в пределах домена широковещания. Это я к тому, что модель OSI надо знать не хорошо, а очень хорошо, и различать два варианта определения “на каком уровне работает данный протокол”.

  Например протокол RIPv2 занимается передачей маршрутной информации. Данные этого протокола вкладываются внутрь UDP, и по “глубине вложения” RIP будет “внутри транспортного уровня”. Только вот решать задачу он будет сетевого уровня – маршрутизацию. А допустим его коллега OSPF будет для передачи своих данных использовать не UDP или какой-либо другой протокол транспортного уровня, а напрямую вкладывать свои данные в IP-датаграммы, имея свой личный код вложения. Но при этом заниматься опять-таки будет задачей сетевого уровня – маршрутизации.

  Так что будьте внимательны в терминологии – и “протокол выполняет задачи уровня N модели OSI” – это одно, а “протокол технически реализуется как вложение уровня N модели OSI” – другое.

  • Тип оборудования (длина поля – 2 байта): Код, обозначающий тип среды, в которой идёт работа. Для Ethernet’ов это будет единица, готы могут ставить 5 (для протокола Chaos), эстеты – 149.
  • Тип протокола сетевого уровня, про который идёт речь в ARP-пакете (длина поля – 2 байта): Стандартный код протокола, такой же, как в 802.3, например. То есть для IPv4 – это 0x0800.
  • Длина адреса канального уровня (длина поля – 1 байт): Сколько байт в адресе канального уровня. Например, для 802.3 это будет 6.
  • Длина адреса сетевого уровня (длина поля – 1 байт): Сколько байт в адресе сетевого уровня. Например, для IPv4 это будет 4.
  • Код операции ARP (длина поля – 2 байта): У операции ARP Request это единица, у ARP Response – двойка. Да, такой вот обильный в плане функционала протокол. 🙂
  • Адрес канального уровня отправителя (SRC MAC, говоря проще) – уникастовый MAC-адрес интерфейса, с которого отправляется запрос.
  • Адрес сетевого уровня отправителя (SRC IP, говоря проще) – уникастовый IP-адрес интерфейса, с которого отправляется запрос. В случае нескольких IP-адресов на интерфейсе – основной адрес интерфейса (primary).
  • Искомый адрес канального уровня – в случае ARP – широковещательный 802.3 адрес вида FF-FF-FF-FF-FF-FF. Ведь очевидно, что раз делается ARP-запрос вида “я знаю только искомый IP-адрес”, то искомый адрес канального уровня неизвестен, поэтому сюда пишется “заглушка” из броадкаста. На фактическое распространение она не влияет, т.к. в самом Ethernet-кадре, в котором вложен ARP-запрос, уже указан броадкаст как DST MAC.
  • Искомый адрес сетевого уровня – в случае ARP – тот самый IP-адрес, для которого надо найти соответствующий MAC.

  Задачи, стоящие перед протоколом, достаточно прозрачны. Как он будет настраиваться?

  Базовые настройки и операции с ARP на Windows-системах

  Почистить локальный кэш ARP или удалить отдельную запись

  Кэш: arp -d

  Запись: arp -d ip-адрес

  Добавить статическую ARP-запись

  arp -s ip-адрес mac-адрес

  Детально посмотреть кэш

  arp -a -v

  Будут видны все типы записей – и static, и dynamic, и invalid. Сам вывод будет разбит по критерию привязки записей к интерфейсам – в начале каждого раздела будет выводиться primary IP интерфейса, а потом его внутренний идентификатор (Вы можете посмотреть табличку интерфейсов и их ID командой netsh int ipv4 sh int).

  Есть и более современный вариант отображения кэша:netsh interface ipv4 show nei. В этой команде вывод также разбит по интерфейсам (правда, пишутся их человеческие названия, а не primary IP), статические и системные записи будут называться Permanent, обычные – Reachable (если доступны), Unreacheable (если нет) и Stale (если запись устарела).

  Базовые операции с ARP на оборудовании Cisco

  Как добавить статическую запись

  (config)#arp ip-адрес или “vrf имя-vrf” mac-адрес тип-вложения тип-интерфейса

  Из интересного тут разве что тип вложения – можно указать, какой именно вариант вложения (из реально возможных сейчас – ARPA или SNAP) будет у записи. Параметр “Тип интерфейса” можно не указывать.

  Настроить включение-выключение ARP и его тип

  (config-if)#arp arpa или frame-relay или snap

  Как понятно, обычно тип ARP будет ARPA и в модификации нуждаться тоже особо не будет. Внимание – типы не являются взаимоисключающими – т.е. можно сделать и arp arpa и arp snap, и это лишь покажет, что на данном интерфейсе надо обрабатывать и тот и тот варианты.

  Настроить время нахождения записи в ARP-кэше

  (config-if)#arp timeout секунды

  Настройка идёт на интерфейсе, т.к. данный тайм-аут будет только у записей в ARP-кэше, сделанных через этот интерфейс.

  Очистить кэш ARP

  #clear arp-cache

  #clear arp-cache ip-адрес

  Все записи, привязанные к конкретному интерфейсу:

  #clear arp-cache интерфейс

  Настроить работу с incomplete ARP records

  Данные настройки будут нужны, чтобы задать поведение системы в случае “Я точно знаю, что есть сосед с таким IP-адресом, но у меня нет его MAC-адреса”.

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

  (config)#ip arp incomplete enable

  (config)#ip arp incomplete entries число

  (config)#ip arp incomplete retry число

  Базовый тюнинг ARP – тайм-ауты и кэш

  • Есть кэш “соседей” – для IPv4 и IPv6
  • Запись туда идёт после получения ARP-ответа, после чего у строки кэша появляется статус “Reachable”
  • Статус теряется в случае отказа интерфейса или по тайм-ауту – если прошло более “ReachableTime” секунд, то статус меняется на “Stale”
  • Если хочется отправить пакет узлу, строка кэша для которого находится в состоянии “Stale”, то предварительно надо отправить ARP-запрос

  ARP и QoS

  В случае, когда сетевой интерфейс загружен трафиком, часть трафика может теряться. Увы, ни один из методов queuing не является от этого панацеей. Начиная с Cisco IOS 15.1 можно указать, что на данном интерфейсе необходимо всегда обрабатывать ARP-пакеты в первую очередь, что может значительно сократить процент потери ARP-данных. На общую загрузку это, как понятно, повлияет мало, а вот пользы может принести много. Ведь ARP-пакеты передаются без механизма подтверждения доставки и терять их не очень хорошо. Данный механизм включается на L3-интерфейсах, командой: arp packet-priority enable Выключается, как понятно, no arp packet-priority enable . В Windows аналогичной процедуры нет.

  ARP и NLB

  Чтобы ARP дружил с NLB, он должен обрабатывать ситуацию, когда придёт ARP-запрос с не-юникастового адреса. То есть, смотрите ситуацию. Допустим, есть NLB, который работает в мультикастовом режиме. Два хоста, соответственно, прикидываются одним IP-адресом, отвечая на ARP-запросы про этот адрес общим мультикастовым MAC’ом, и потом договариваясь друг меж другом, что делать с пришедшим трафиком. Вот чтобы эта схема работала, надо, чтобы когда этот “общий виртуальный узел”, который обладает виртуальным IP и мультикастовым MAC, решил узнать через ARP чей-то MAC, ему вообще ответили. Потому что есть тонкость – у мультикастового MAC есть характерный вид, по которому понятно, что он мультикастовый. А не-юникастовые source MAC в общем-то не являются нормальной ситуацией и нуждаются в особой обработке. Соответственно, для этого надо явно включить обработку ситуации “к нам пришёл ARP-запрос от товарища, у которого обратный MAC-адрес не-юникастовый”. Делается это путём установки параметра:

  в единицу. Если она будет в нуле – в ряде ситуаций поимеете проблемы с NLB.

  ARP и SNAP

  По умолчанию, ARP вкладывается в 802.3 кадр простым, Ethernet II способом. Это можно поменять в случае, если необходима поддержка SNAP-механизма, который, как известно, нужен для мультиплексирования потоков данных на канальном уровне. Напомню, что по RFC 1042 данные IP и ARP всегда передаются поверх 802.x сетей используя связку LLC+SNAP, за исключением обычного Ethernet (802.3), где они вкладываются напрямую (см. RFC 894). Примечание: Если не известно, то надо задуматься об изучении базовых курсов по сетевым технологиям, потому что детальное рассмотрение “что такое SNAP, зачем, почему, когда, с кем” не входит в спектр задач по изучению ARP.

  Для этой задачи есть ключ:

  По умолчанию он в нуле, установив в единицу Вы получите ситуацию, что ARP-запросы будут вкладываться в SNAP (притом в LLC+SNAP, что увеличит суммарный размер кадра на 3+5=8 байт).

  ARP и NUD

  NUD – это Neighbor Unreachability Detection. По умолчанию включается на интерфейсах, которые смотрят в broadcast-среды, и выключается на других. Помогает узнать о том, что сосед (что обычный, что шлюз) перешёл в нефункциональное состояние до времени, пока его запись в ARP-кэше стала Stale. Механизм полезный, поэтому его рекомендуется включать в явном виде. Делается это командой:

  netsh int ipv4 set int имя интерфейса nud=enabled

  ARP и DAD

  DAD – это Duplicate Address Detection. То самое, что не даёт взять себе адрес, который уже есть у кого-то. Проводится путём отправки Gratuious ARP, про который чуть ниже. Тюнингуется достаточно просто, двумя параметрами:

  netsh int ipv4 set int имя интерфейса retransmittime=миллисекунды

  netsh int ipv4 set int имя интерфейса dadtransmits=попытки По умолчанию retransmittime – т.е. время между попытками обнаружить соседа, который уже занял адрес – 1 секунда, количество попыток dadtransmits – 3. Можете сократить их, если уверены, что все соседи отвечают достаточно быстро, это уменьшит время инициализации интерфейса – система не будет ждать “вдруг кто проснётся и скажет, что адрес уже занят”.

  ARP и WOL

  Функция Wake-On-Lan, думается, хорошо Вам известна. Она нужна, чтобы узел “проснулся” в определённый момент – когда увидит на сетевом интерфейсе соответствующие неким условиям данные. Обычно это данные, напрямую идущие на данный узел, притом содержащие некую последовательность – Magic Pattern. Так вот, можно заранее указать условие – будет ли данный Magic Pattern искаться вообще во всех сетевых данных, которые попадут на нужный узел, либо только не некоторых. В частности, так как статья про ARP, есть настройка, позволяющая установить для интерфейса условие – анализировать ли на предмет наличия Magic Pattern’а пакеты протоколов ARP (для IPv4) и ND (для IPv6). Включается следующим образом: netsh int ipv4 set int имя интерфейса forcearpndwolpattern=enabled Как выключается, надеюсь, понятно. Рекомендуется к выключению на узлах, у которых нет задачи просыпаться по WOL, т.к. ускоряет обработку путём раннего отбрасывания механизмом поиска Magic Pattern указанных пакетов. Теперь про RARP.

  Протокол RARP

  RARP – это как ARP, только наоборот. Логично. По сути, RARP – это очень сильно простой сервис по динамическому конфигурированию узлов. Он ведь отрабатывает задачу, обратную ARP. ARP: Я знаю искомый L3-адрес, дайте мне соответствующий ему L2-адрес. RARP: Я знаю искомый L2-адрес, дайте мне соответствующий ему L3-адрес.

  Примечание: Обратите внимание, для работы ARP выделенный сервер не нужен, а для RARP – нужен. У RARP-сервера есть табличка соответствий MAC и IP-адресов, из которой он берёт указанную информацию и отправляет её. Различия на технологическом уровне будут следующими: RARP-пакеты будут иметь код вложения 0x8035 , плюс коды операций у них будут 3 для RARP-запроса и 4 для RARP-ответа.

  Примечание: Если код вложения будет от RARP, а коды – 1 или 2 (т.е. как у обычного ARP), то RARP-сервер отдаст данный пакет на обработку ARP-стеку.

  Вообще, RARP сейчас практически не используется, но если хотите почитать – есть RFC 903.

  Примечание: А если хотите почитать, и чтобы накрыло – почитайте про Dynamic RARP, это RFC 1931.

  Реализация RARP-сервера в Windows

  Реализация RARP-сервера на оборудовании Cisco

  Она есть. Конфигурируется в несколько этапов. По порядку:

  Шаг первый: Добавляем запись для потенциального RARP-клиента (т.е. того, кто хочет получить IP-адрес). В глобальной конфигурации:

  (config)#arp ip-адрес mac-адрес-клиента arpa

  Шаг второй: Разрешаем на интерфейсе, в качестве параметра – тот адрес на интерфейсе, от которого отправляем RARP-ответы.

  (config-if)#ip rarp-server ip-адрес

  Протокол InARP (Inverse ARP)

  InARP – специальная модификация ARP для не-broadcast сетей (например, Frame Relay или ATM). Суть проста – в сетях, где нет широковещания, обычный ARP работать не сможет, а задачи, которые им решаются, никуда не пропадают. Соответственно, нужна схема работы. Она будет достаточно интересна и проста. Узел, который поддерживает InARP, будет самостоятельно с указанной периодичностью отправлять в субинтерфейсы, поддерживающие InARP (например, в FR’овские), InARP-сообщения, в которых будет указано что-то вида “привет, я от узла с сетевым адресом таким-то”. Соответственно, принимающая сторона, получая такое сообщение из-под субинтерфейса с DLCI=abc, будет записывать у себя в таблицу – “За DLCI abc живёт товарищ с IP xyz“. В общем-то и всё.

  Другие отличия будут состоять в использовании других кодов операций – 8 для запроса InARP, 9 для ответа. Ну и в механизме вложения – понятное дело, в Q.922 вкладываться – это не в 802.3

  Протокол UnARP

  Предлагался в RFC 1868. Суть проста – сам формат пакета ARP не менялся, добавлялся лишь новый тип сообщения – сообщение вида “Я ушёл из сети”. Т.е. задачей дополнения UNARP являлось то, что узлы, которые отключаются, могут послать сообщение “Стирайте меня все из ARP-кэшей”, чтобы остальные не ждали время окончания кэширования записей. К сожалению, не поддерживается (основная причина – небезопасен, т.к. такое сообщение легко подделать).

  Протокол SLARP (Serial Line ARP)

  Специальный субпротокол, работающий внутри цисковского варианта HDLC (который обычно cHDLC). Используемый код вложения – 0x8035. Протокол простой, но интересный тем, что может делать две штуки – проверять состояние канала, периодически передавая кадры, и назначать IPv4-адреса в случае, если с одной стороны serial link адрес IPv4 есть, а с другой – нет. Адрес назначается по логике “Если у меня последний бит адреса 1, предложить такой же, но с нулём, и наоборот”. Маска предлагается такая же, как у себя.

  • Адрес (один байт) – стандартный адрес вида b1111111 из xHDLC/PPP.
  • Контроль (один байт) – то же самое, опять LLC3, т.е. b00000011.
  • Код протокола вложения (два байта) – личный номер SLARP, 0x8035.
  • Код операции (один байт) – вариант или Address request(0x00), или address reply (0x01), или Keep-alive (0x02).
  • IPv4-адрес и маска (два раза по 4 байта) – предлагаемый партнёру по serial link адрес.
  • Резерв (один байт) – вечно 0xFF.
  • FCS в варианте CRC-16 (два байта)
  • Флаг (один байт) – стандартный флаг xHDLC вида b0111110.

  Протокол DirectedARP

  Протокол описан в RFC 1433. Сейчас как отдельный протокол не используется, хотя многие мысли, высказанные в этом RFC, достаточно дельные и повлияли, например, на формирование современного IPv6.

  Безопасность ARP

  В общем-то, в ARP нет никаких встроенных средств безопасности. Это очень простой служебный протокол, поэтому о какой-то отдельной защите его говорить трудно. Можно высказать лишь общие мысли – например, что в случае малого количества хостов проще ввести все их IP-MAC соответствия как статические – в этом случае ARP они передавать перестанут (в кэше-то записи про соседей будут всё время), а если кто-то злонамеренный специально передаст поддельный ARP-ответ, то никакого влияния он не окажет – динамически полученный ARP-ответ не перезапишет собой статическую запись. Есть ряд дополнительных механизмов (которых достаточно много), которые могут помочь в этом вопросе. Например, на оборудовании Cisco есть команда: arp authorized которая, в случае включения на интерфейсе, отключит динамические записи в кэш ARP. Т.е. интерфейс перестанет слушать ARP-ответы от неизвестных клиентов и дополнять ими кэш ARP. Для ряда моделей оборудования (например, на старших линейках маршрутизаторов – это 7600) можно задать в режиме глобальной конфигурации максимальный размер ARP-кэша для устройства (по умолчанию он не ограничен и составляет 256.000 записей):

  ip arp entry learn количество

  Есть, в общем-то, множество доп.механизмов безопасности ARP – тот же DAI или ARP ACL, про которые, возможно, я тоже допишу сюда.

  Механизм Proxy ARP

  Суть механизма Proxy ARP, детально обозначенного в RFC 1027, проста – дать возможность узлу, который в силу каких-то причин (например, у него не указан шлюз по умолчанию) не может понять, куда маршрутизировать трафик для других сетей, всё же сделать это. Притом сделать просто – используя то, что в сегменте с этим узлом присутствует добрый узел, на котором включен Proxy ARP, и который, увидев что узел пытается через ARP-запрос найти получателя трафика, “прикинется” этим получателем и ответит на запрос.

  Т.е. вот есть маршрутизатор, на котором включен Proxy ARP. Он получает ARP-запрос на разрешение адреса узла, который находится в другом сегменте относительно спрашивающего и помогает – просто отвечает ему от имени этого узла. Соответственно, этот роутер и будет передавать трафик между данными узлами, а отправитель будет думать, что отправляет трафик напрямую.

  Данный механизм включен “по умолчанию” на большинстве систем и нуждается в отключении – т.е. описанная ситуация, в общем-то, по производственной необходимости возникает довольно-таки редко.

  Пример: Например, у хоста A адрес 10.1.1.1/24, а у хоста B – 10.1.1.2/16. Технологически они в разных сетях, и между ними даже есть роутер – у него в сторону хоста A смотрит интерфейс 10.1.1.254/24, в сторону хоста B – 10.1.255.254/16. Но вот проблема в том, что хост A не понимает, что хост B – в другой сети, а думает, что B – его сосед. И пытается найти его, отправляя ARP-запрос. Вот в этом случае если роутер будет поддерживать Proxy ARP, то всё будет хорошо – связь между A и B будет.

  Как включить Proxy ARP на оборудовании Cisco

  Зайдите на нужный интерфейс и введите там команду:

  (config-if)#ip proxy-arp

  Выключить глобально – (config)#ip arp proxy disable.

  Как включить Proxy ARP в Windows

  В случае, когда у Вас используется RRaS, proxy ARP работает автоматически.

  Что такое и как работает Gratuitous ARP

  Это страшное слово переводится как “самопроизвольный” ARP. Суть события в следующем. Любой узел, который инициирует новый интерфейс, на котором есть поддержка ARP, должен при завершении процесса конфигурирования IP-адреса (статически ли, по DHCP, через APIPA’у – без разницы) уведомить соседей о том, что он появился. Делается это при помощи отправки одиночного ARP Reply, в котором указывается, что логично, связка “мой MAC – мой новый IP”. Т.е. выглядит этот ARP-ответ несколько странно с точки зрения классической схемы работы ARP – узел рассылает на броадкастовый MAC и свой IP информацию о своём настоящем MAC и своём же IP. Т.е. совпадают SRC IP и DST IP.

  Примечание: По сути, этот механизм – это “форсированное” обновление ARP-кэша соседей новой информацией – “теперь я по этому MAC-адресу”. Заодно, именно благодаря этому механизму, происходит обнаружение дублирующихся IP-адресов – тот, кто пытается присвоить себе IP-адрес, рассылая это уведомление “засветится”.

  Но, в общем-то, мы и договорились, что это – исключительная и разовая ситуация. Казалось бы, в чём проблема-то?

  Проблема в том, что когда такое происходит на сервере удалённого доступа, к которому подключено несколько клиентов (более 1, по сути), то этот сервер при подключении каждого своего клиента получает от него данный стартовый запрос ARP и ретранслирует запрос далее, выступая, по сути, прокси. В результате, допустим, порт коммутатора, в который включен этот сервер, впадает в тягостные размышления о здоровье сервера, который постоянно сообщает всей сети о том, что за его MAC-адресом интерфейса (того, который воткнут в коммутатор) очень много IP-адресов, и все они разные. И каждый раз, когда клиент будет подключаться (например, VPN-канал переподключит, или другим способом вызовет переход через NCP-фазу PPP), такой ARP-ответ будет создаваться и отправляться серверу, а тот будет отдавать его дальше – чтобы уведомить сеть, что трафик на такой-то IP-адрес надо отправлять на его, сервера, MAC, а дальше он уж сам разберется.

  Соответственно, в ряде ситуаций (например, много клиентов, краткие сессии) такой механизм надо отключать. Зачастую проще привязать статически целую пачку ARP-соответствий (например, когда на сервере удалённого доступа выделен пул в 20 адресов, и абоненты подключаются, делают какую-то краткую операцию и отключаются), чем постоянно форвардить в сеть эти ARP Reply.

  Примечание: На самом деле, делать это надо с умом, как и всё остальное. Есть ситуации, когда gratuitous ARP является штатным и нужным. Например, у Вас сделан HSRP-балансировщик. Активный узел упал – второй становится активным. И в этот момент он тоже “просто так, внезапно” отправит gratuitous ARP – чтобы сразу уведомить всю сеть, что теперь у виртуального IP новый MAC, а не ждать, пока у всех узлов кончится тайм-аут кэша.

  Как настроить Gratuitous ARP на оборудовании Cisco

  router(config)#ip gratuitous-arps

  Если добавить в конце команды слово non-local, то будет обрабатываться вышеописанная ситуация с PPP.

  Отключить приём всех gratuitous ARP’ов:

  router(config)#ip arp gratuitous none

  Включить приём только gratuitous ARP’ов, source которых из connected-сетей:

  router(config)#ip arp gratuitous local

  Как настроить Gratuitous ARP на Windows Server

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

  Управлять же Gratuitous ARP со стороны узла вполне можно. Для этого есть ключ реестра:

  HKLM\System\CurrentControlSet\Services\TcpIp\Parameters

  а в нём – параметр ArpRetryCount типа DWORD32. Если поставить этот параметр в нуль, то механизм будет выключен. По умолчанию Windows-хосты делают Gratuitous ARP три раза – сразу после инициализации адреса, потом через 1/2 секунды, потом через ещё 1/10 секунды. Можете поставить единицу, если уверены в качестве работы сети и её не-критичной загруженности на момент выхода ARP Reply – “сэкономите трафик”.

  Примечание: Считаются фактически отправленные ARP, а не попытки. Т.е. если среда была недоступна, то все равно отправят три, просто чуть позже.

  Примечание: Если поставить нуль, то вдобавок отвалится функция обнаружения конфликтов DHCP, но это будет в другой истории.

  Cisco ARP Optimization Feature – что это?

  Это достаточно полезное архитектурное изменение, появившееся в релизах IOS 12.0 – 12.2 и закрепившееся в более поздних. Идея проста. Устройство хранит информацию о связках IP-MAC-интерфейс в отдельной таблице. Эта таблица организована для быстрого поиска информации по известному IP-адресу. Соответственно, этот механизм эффективен, когда надо обработать единичный пакет. В ситуации же, когда интерфейс попеременно переходит из состояния включения в выключенное и наоборот (interface flapping), надо сразу же обработать в этой таблице все ARP-записи, относящиеся ко всем IP и MAC, находящимся за данным интерфейсом. Вот фича Cisco ARP Optimization как раз умеет делать эту операцию – например, очистить все записи за соответствующий интерфейс. Выигрыш – резко сниженная загрузка CPU, которому надо обработать событие “падение интерфейса”.

  Как настроить Cisco ARP Optimization Feature

  Никак – это просто другая структура хранения данных ARP в оперативной памяти, используемая в современных версиях IOS.

  Заключение

  Если я вспомню ещё что-то, или меня наведут на мысль, то обязательно напишу сюда в качестве дополнения к статье.

  Похожие публикации:

  1. Defender x7 как подключить к пк
  2. Intel corporation display что это
  3. Как обозначаются дюймы в тексте значок
  4. Как удалить верхний колонтитул в ворде на второй странице