Всем привет. Может кому будет интересно. Я всегда думал что статика/дефолт типа 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, как было бы без уточняющего указания выходного интерфейса. Часто бывает полезно, например у провайдеров.
Не знаю, может во мне говорили инстинкты контрол-фрика, но с самого начала идея указывать интерфейс без адреса следующего перехода (в случае 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). Поэтому в таблице маршрутизации нужно избегать мультипоинт-интерфейсов в качестве места назначения для префиксов. Надо указывать адрес следующего перехода, а не интерфейс.
Комментарии
Переборол это только когда узнал о связке
- 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). Поэтому в таблице маршрутизации нужно избегать мультипоинт-интерфейсов в качестве места назначения для префиксов. Надо указывать адрес следующего перехода, а не интерфейс.