Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

статический маршрут на броадкастный интерфейс

Всем привет. Может кому будет интересно.
Я всегда думал что статика/дефолт типа ip route 0.0.0.0 0.0.0.0 fa0/0 - это вполне нормально. Фрейм L2 при этом уходит на бродкастный адрес.
А вот нет.
Сначала я прочел А вы хорошо знаете статическую маршрутизацию? где описано как работает CEF при различных трюках со статикой. В статье в основном о важности контроля next-hop ip, чтобы он к вам не пришел со стороны в рамках другого маршрута. Там была ссылка на LinkMeUp. Выпуск 0 где сказано, что статика на интерфейс черевата валом ARP.
И наконец https://supportforums.cisco.com/document/116711/static-routes-next-hop-exit-interface-or-ip-address поставило точку.
При выключенном proxy-arp (а именно так у нас по политикам ИБ) - не работает :)

Короч я в шоке.

Комментарии

  • Ну да, не стоит писать статику в интерфейс без указания next hop, т.к. иначе на каждый destination ip будет создаваться arp запись через механизм proxy arp. А комбинация выходной интерфейс плюс next hop полезна тем что при выключенном интерфейсе маршрут из таблицы маршрутизации исчезает и не пытается рекурсивно найти next hop, как было бы без уточняющего указания выходного интерфейса. Часто бывает полезно, например у провайдеров.
  • Так и есть. Но вот то что вообще не будет работать - я не ожидал.
  • отредактировано апреля 2016
    Не знаю, может во мне говорили инстинкты контрол-фрика, но с самого начала идея указывать интерфейс без адреса следующего перехода (в случае ethernet) вызывала во мне душевные страдания перед неизвестностью, ибо кто знает - что там за интерфейсом )).
    Переборол это только когда узнал о связке
    - ip unnumbered,
    - статических маршрутах /32->интерфейс,
    - proxy-arp
    для экономии адресов. Так можно назначать 1 адрес на влан (а не подсеть /30 на влан).
    Тогда же появилось и рациональное понимание, почему не стоит так делать для крупных префиксов, включая дефолт.
    Сформулировал это в ходе написания ответов на тему про основы маршрутизации.

    Процесс построения нового L2-кадра при посылке пакета через исходящий интерфейс, зависит от типа инкапсуляции исходящего интерфейса.

    * Если в маршруте в качестве next-hop указан L3-адрес следующего перехода, то маршрутизатор заранее определяет (по ARP, Inverse-ARP… и т.п.) и знает соответствующий ему L2-адрес в среде за интерфейсом, и использует его при формирования L2-заголовка кадра, в который упаковывается IP-пакет.

    * Если в маршруте в качестве next-hop указан исходящий интерфейс (а не адрес следующего перехода), то подразумевается, что речь идёт о маршруте к конечной точке, которая доступна через этот интерфейс.
    ** Если это p2p-интерфейс, где нет адресации, то пакет просто инкапсулируется в L2-кадр и посылается. Никаких проблем.
    ** Если же это мультипоинт-интерфейс, чтобы была возможность выполнить инкапсуляцию, нужно знать правильный L2 dst-address, соответствующий L3-dst-адресу точки назначения. Маршрутизатор пытается преобразовать dst-ip в L2-адрес конечной точки (c помощью тех же ARP, Inverse-ARP, NHRP и т.д. - в зависимости от среды). Это ресурсозатратный и относительно долгий процесс, особенно если речь идёт о крупных префиксах (или маршруте по-умолчанию), т.к. маршрутизатору каждый раз перед отправкой пакета для каждого нового dst-ip из префикса придётся выяснять (и хранить) MAC-адрес, даже если в большинстве записей будет фигурировать один и тот же MAC-адрес (вышестоящего маршрутизатора по-умолчанию с включенной функцией proxy-arp). Поэтому в таблице маршрутизации нужно избегать мультипоинт-интерфейсов в качестве места назначения для префиксов. Надо указывать адрес следующего перехода, а не интерфейс.
Войдите или Зарегистрируйтесь чтобы комментировать.