Я не уверен, откуда ваш дизайн и таблица маршрутизации.
В любом случае, в такой среде, как ваша, маршруты к удаленным сетям обычно определяются через протоколы маршрутизации (т. Е. Динамическая маршрутизация); использование статических маршрутов (определяемых пользователем / администратором) со всеми имеющимися у вас избыточными путями в конечном итоге вызовет петли маршрутизации или черные дыры.
Другими словами, каждая подсеть вашей диаграммы может быть достигнута через каждый интерфейс R8, в зависимости от конфигурации других маршрутизаторов.
Например: если вы определите интерфейс 1 R8 как следующий переход для 14.0.0.0 (имеется в виду, что пакеты предназначены для любого IP-адреса 14.0.0.0/? в подсеть будет отправлен интерфейс 1), и если R4 (фактический следующий переход из интерфейса 1 R8) имеет другую статическую связь с 14.0.0.0 через R1, ваш пакет пересечет R8-> R4-> R1-> Destination , С другой стороны, если в этом примере вы все еще отправляете свой пакет для 14.0.0.0 на R4, но R4 настроен с другим статическим для 14.0.0.0, который указывает на R8, у вас будет цикл маршрутизации, и ваш пакет будет отказов между R8 и R4, пока не истечет его TTL.
Та же теория применима к любой другой удаленной сети, такой как 12.0.0.0, где менее очевидно, должен ли R8 пересылать свой пакет в R2 или R4.
Главное, что нужно помнить, это то, что IP-пакеты не имеют памяти, они просто пересылаются путем оценки их назначения (т. Е. Маршрутизаторы не заботятся об интерфейсе, откуда был получен пакет - если вы не используете такие вещи, как source- роутинг но тут дело не в этом).
Таблица, которую вы опубликовали, не показывает, используется ли статическая или динамическая маршрутизация (она также пропускает подсеть этих сетей), но если это не конкретное теоретическое упражнение, вам нужна динамическая маршрутизация.
Динамическая маршрутизация может определять наилучший путь от маршрутизатора до сети назначения, используя различные параметры, такие как количество переходов, пропускная способность, задержка и т.д. (В зависимости от конкретного протокола динамической маршрутизации). Кроме того, они могут правильно управлять сбоями избыточных каналов.
В качестве другого примера, если вы решите поместить статическое значение для 12.0.0.0, указывающее на сбои маршрутизатора R3 и R3, вы продолжите пересылать пакеты, предназначенные для 12.0.0.5 (например), в черную дыру.
Если вы решите сбалансировать нагрузку до 12.0.0.0 с 2 маршрутами (с одинаковой метрикой) через R3 и R4, если R4 выйдет из строя (или один из его интерфейсов не работает), R8 продолжит пересылку пакета 1 в R3, пакет С 2 по R4, пакет с 3 по R3 и так далее. Это вызовет, по-видимому, случайные вещи, потому что, если пакеты используют TCP, пропущенные будут повторно переданы, что сделает менее очевидным, что половина вашего трафика будет перегружена (например, прерывистая потеря линии некоторых служб, медлительность и т.д.).
Если вы используете Linux, Quagga может быть программным обеспечением для динамической маршрутизации, но предполагается, что другие маршрутизаторы используют протокол динамической маршрутизации.
Однако, если ваша цель - установить статический маршрут, эти команды должны работать (я предполагаю, что /24, но если это классно, то это может быть /8):
ip route add 14.0.0.0/24 dev eth3
то же самое из:
ip route add 14.0.0.0/24 via 13.0.0.2
В любом случае, второй предпочтительнее в сети с множественным доступом (не требуется многоадресный / широковещательный трафик, тонны ARP-запросов и т.д.).