30.01.2017

Годный пост про семейство ARP

Заслуживающий отдельного внимания пост про семейство протоколов ARP и особенности их работы на Windows от Руслана Карманова
Оригинал тут. Я просто скопипастил весь текст

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

Протокол ARP вроде бы простой и тривиальный, но количество его однофамильцев с различным функционалом - достаточно серьёзно. Разбираемся.


Привет.

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

Оглавление

    • Протокол ARP
      •  Вкратце про сам протокол и формат заголовка
      •  Базовый тюнинг – тайм-ауты и кэш
      •  ARP и QoS
      •  ARP и NLB
      •  ARP и SNAP
      •  ARP и NUD
      •  ARP и DAD
      •  ARP и WOL
      • ARP и РПГ-7
    • Протокол RARP
    • Протокол InARP
    • Протокол UNARP
    • Протокол SLARP
    • Протокол DirectedARP
    • Безопасность ARP
    • Механизм Proxy ARP
    • Что такое и как работает Gratuitous ARP
    • Cisco ARP Optimization Feature – что это?

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

    Протокол Address Resolution Protocol (ARP) используется для простой задачи – выяснить по известному адресу сетевого уровня (IP) неизвестный адрес канального уровня (например MAC). Данные ARP вкладываются в протокол канального уровня и являются, по уровню вложения, протоколом 3го уровня, а вот по функционалу остаются протоколом 2го уровня. Это я к тому, что модель OSI надо знать не хорошо, а очень хорошо. Для идентификации ARP внутри кадра Ethernet будет использоваться код протокола 0x0806. В состав ARP-пакета будет входить следующие интересные поля:
    • Тип оборудования (длина поля – 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 – тайм-ауты и кэш

    В NT 6.0 сетевой стек был ощутимо изменен (приведён в соответствие с RFC 4861), поэтому то, что действовало для XP/2003, работать в большинстве своём не будет. Схема работы ARP-кэша теперь следующая:
    • Есть кэш “соседей” – для IPv4 и IPv6
    • Запись туда идёт после получения ARP-ответа, после чего у строки кэша появляется статус “Reachable”
    • Статус теряется в случае отказа интерфейса или по тайм-ауту – если прошло более “ReachableTime” секунд, то статус меняется на “Stale”
    • Если хочется отправить пакет узлу, строка кэша для которого находится в состоянии “Stale”, то предварительно надо отправить ARP-запрос
    Как точнее считается время? Формула подсчёта такова:
    ReachableTime = BaseReachableTime * (случайный коэффициент между MIN_RANDOM_FACTOR и MAX_RANDOM_FACTOR)
    Параметры, от которых идёт вычисление, выглядят так: BaseReachableTime = 30 секунд, MIN_RANDOM_FACTOR = 0.5, а MAX_RANDOM_FACTOR – 1.5. Параметр BaseReachableTime изменяем командой:
    netsh interface ipv4 set interface имя интерфейса basereachable=количество миллисекунд
    Заметьте, для каждого интерфейса это устанавливается отдельно. Ранее действовавшее общесистемное значение по умолчанию в 120 секунд, таким образом, теперь не актуально. Я бы рекомендовал увеличить это значение до тех же 2х минут, что были раньше – количество трафика снизится, а минусов практически нет – узлы, которые сменят MAC за время устаревания кэша, сами об этом уведомят.
    В случае работы с оборудованием Cisco, данный параметр – тайм-аут записи в ARP-кэше – задаётся на интерфейсе командой:
    arp timeout время в секундах
    и имеет базовое значение в 14400 (это 4 часа).
    Суммарный же объём кэша IPv4-соседей можно установить так:
    netsh interface ipv4 set global neighborcachelimit=количество
    По умолчанию их 256. Как понятно, в случае, если соседей по среде передачи данных мало (например, есть единственный сетевой интерфейс в сеть с маской /28), этот кэш увеличивать не надо, а уменьшить вполне можно. Помните, это именно кэш ARP, т.е. явных адресов соседей по vlan плюс служебных мультикастов. Нет смысла его раздувать до огромных габаритов, если в сети банально мало узлов, нечего кэшировать особо будет.
    Давайте теперь чуть углубимся.

    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-адрес не-юникастовый”. Делается это путём установки параметра:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableBcastArpReply
    в единицу. Если она будет в нуле – в ряде ситуаций поимеете проблемы с NLB.

    ARP и SNAP

    По умолчанию, ARP вкладывается в 802.3 кадр простым, Ethernet II способом. Это можно поменять в случае, если необходима поддержка SNAP-механизма, который, как известно, нужен для мультиплексирования потоков данных на канальном уровне. Напомню, что по RFC 1042 данные IP и ARP всегда передаются поверх 802.x сетей используя связку LLC+SNAP, за исключением обычного Ethernet (802.3), где они вкладываются напрямую (см. RFC 894).
    Примечание: Если не известно, то надо задуматься об изучении курса ICND1, потому что детальное рассмотрение “что такое SNAP, зачем, почему, когда, с кем” не входит в спектр задач по изучению ARP.
    Для этой задачи есть ключ:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ArpUseEtherSNAP
    По умолчанию он в нуле, установив в единицу Вы получите ситуацию, что 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 windows server быстро бесплатно без sms.

    Реализация 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=xxx, будет записывать у себя в таблицу – “За DLCI xxx живёт товарищ с IP yyy”. В общем-то и всё.
    Другие отличия будут состоять в использовании других кодов операций – 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.

    Заключение

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

    Комментариев нет:

    Отправить комментарий