>[оверквотинг удален]
>>>> рекомендуется
>>> Это вообще для всех multi access сетей недопустимо . Гнать из профессии
>>> за такие маршруты :)
>> Ну почему же,
>> если у вас хосты с полной реализацией ICMP, вам начхать на
>> джиттер, у вас 10-ти кратный запас по производительности и прорва времени
>> на траблжуттинг...
>> То почему бы и не нет
>> ;)
> А с чем это связанно? Что почитать на эту тему можно?С связано это с тем фактом, что в среде с множественным доступом, в отличие от сред точка-точка, в одном сегменте могут быть одновременно более двух устройств.
А значит требуется протокол способный выполнить преобразование сетевых адресов в канальные (ARP в Ethernet), или наоборот (inverse ARP/NHRP в Frame-Relay/ATM), зависит от типа канального протокола.
Так вот суть проблемы в том, что такое преобразование будет выполняться для каждого адреса назначения, для которого в ARP/ND кэше нет соответствующей записи.
Но, такие устройства физически находятся за пределами нашего сегмента, а значит возникает дилемма, кто же нам ответит на запрос? Например шлюз с поддержкой Proxy ARP/ND, а если такового нет, то вообще никто не ответит.
Но, даже получив ответ, мы столкнёмся с тем, что наша таблица кэша канальных адресов, станет не прилично большой, возрастёт нагрузка на CPU, поскольку такие протоколы относятся к группе протоколов управления, они выполняются на CPU, процессора маршрцтизацит. Увеличится общее время требуемое на первичную отправку пакетов, поскольку ранее достаточно было всего один раз выполнить запрос канального адреса нашего адреса следующего перехода, то теперь мы выполняем такой запрос для каждого адреса назначения. Увеличится и количество служебных пакетов, которые к слову могут быть ещё и широковещательными, что будет создавать лишнюю паразитную нагрузку на всё узлы нашего широковещательного домена.
Описание данной проблемы специалистом Cisco TAC:
“Static Route to Broadcast Interface
If you point a static route to a broadcast interface, the route is inserted into the routing table only when the broadcast interface is active. This configuration is not recommended because when the next hop of a static route points to an interface, the router considers each of the hosts within the range of the route to be directly connected through that interface. An example of such a static route is ip route 0.0.0.0 0.0.0.0 Ethernet0. With this type of configuration, a router performs Address Resolution Protocol (ARP) on the Ethernet for every destination that the router finds through the default route because the router considers all of these destinations as directly connected to Ethernet 0. This kind of static route, especially if it is used by many packets to many different destination subnets, can cause high processor utilization and a very large ARP cache (along with memory allocation failures). So, this kind of static route is not recommended.
When you specify the next hop address on a directly connected interface, it prevents the router from performing ARP for each destination address. An example is ip route 0.0.0.0 0.0.0.0 Ethernet0 192.168.1.1. You can specify the directly connected next hop address only, but this is not recommended for reasons that are described in this document. You do not need to specify the directly connected next hop address. You can specify the remote next hop address and the interface to which the remote next hop recurses.
If the interface with the next hop goes down and the next hop is reachable through a recursive route, you should specify both the next hop IP address and the alternate interface through which the next hop should be found. For example, ip route 0.0.0.0 0.0.0.0 Serial 3/3 192.168.20.1. This enables the static route installation to become more deterministic.”
Вариант для распечатки
(ok) on 16-Дек-17, 08:45 
