Как обеспечить отказоустойчивость для пространственного разнесения T1

Я унаследовал небольшую, изолированную, выделенную сеть, которая по существу безотказна, поэтому, естественно, я хочу улучшить ее :-) Я снизил свои знания сети и подкованный до уровня где-то от 2 до 3 в масштабе 1-10 после прочтения сетевые посты здесь. Я только включил соответствующие маршрутизаторы в свою диаграмму для ясности.

В настоящее время в каждом кампусе примерно 6-8 Cisco 2800 и 2900 с голосовыми картами для выделенного доморощенного приложения, использующего статические маршруты для получения пакетов между двумя кампусами. Они работают c2801-spservicesk9-mz.124-3g на R1 и R2 и c2800nm-adventerprisek9-mz.124-15.t3 на R3 и R4.

Это фиксированная, неизменная сеть, которая обслуживает только это выделенное приложение. Никакие настольные компьютеры или ноутбуки не приходят и не уходят, только маршрутизаторы Cisco, подключенные через сторонние оптоволоконные мультиплексоры в кольцевой топологии в каждом кампусе с подключенным парой серверных компьютеров (часть «других узлов»).

Когда-нибудь по пути заказчик решил, что будет хорошей идеей установить второй T1 между R2 и R3 для резервирования. Исходя из моих тестов, статическая маршрутизация не может использовать этот второй T1. Даже с AD / метрикой на вторичном маршруте к новому T1 только маршрутизатор, у которого T1 отказал, знает это, но другие маршрутизаторы в этом университетском городке не знают.

Я рассмотрел возможность использования объектов ip tracking после прочтения таких решений, чтобы упростить процесс и свести к минимуму нагрузку на сеть. Затем я прочитал, где EIGRP является предпочтительным способом справиться с этим.

Но если динамическая маршрутизация - это путь, он должен быть реализован таким образом, чтобы не нарушать обслуживание. Все это для меня далеко и потребовало бы от меня организации местного технического специалиста, который будет стоять на случай, если я потеряю связь во время перенастройки. Надеемся, что с такой маленькой, неизменной сетью это нарушение может быть сведено к минимуму.

Так должен ли я исследовать, как использовать объекты отслеживания ip или EIGRP для выполнения этой аварийной маршрутизации T1?

РЕДАКТИРОВАТЬ: Вот в настоящее время настроенные маршруты для R4. Я довольно уверен, что здесь есть какая-то путаница, но я попытался ровно один раз упростить его и отступил, когда допустил одну крошечную ошибку и потерял связь с Кампусом Б. Отключения - это большое нет-нет. Я решил оставить достаточно хорошо один, пока я не разработал лучший подход.

ip route 10.0.0.0 255.0.0.0 10.1.1.8
ip route 10.1.1.8 255.255.255.252 Serial0/3/0
ip route 192.168.30.0 255.255.255.0 Serial0/3/0
ip route 192.168.6.0 255.255.255.0 Serial0/3/0
ip route 192.168.8.0 255.255.255.0 FastEthernet0/0
ip route 10.0.2.128 255.255.255.192 192.168.31.2
ip route 10.2.160.0 255.255.255.0 192.168.31.2
ip route 192.168.254.0 255.255.255.0 192.168.31.2
ip route 192.168.6.0 255.255.255.0 192.168.8.11 110 name fallback
ip route 0.0.0.0 0.0.0.0 10.1.1.9
ip route 0.0.0.0 0.0.0.0 192.168.8.11 110 name fallback

Конфигурация маршрута для R3 проста:

ip route 0.0.0.0 0.0.0.0 192.168.8.15
ip route 0.0.0.0 0.0.0.0 10.1.1.5 110

Спасибо.

Это фиксированная, неизменная сеть, которая обслуживает только это выделенное приложение.

Я думаю, вы обнаружите, что это редко является нормой для сетей, даже при неизменных сетях; следовательно, почему вы здесь спрашиваете, как это автоматизировать. В конце концов, появляется другая ссылка, которая требует от вас реинжиниринга всех ваших предыдущих усилий. Это, по определению, какова цель протокола маршрутизации. Это чтобы убедиться, что вам не нужно использовать статические маршруты везде!

Исходя из моих тестов, статическая маршрутизация не может использовать этот второй T1.

Вы можете настроить своего рода IP SLA, который может поддерживать вашу систему в рабочем состоянии и в то же время разрешать переход на другой ресурс в случае сбоя Old T1.

Примером конфигурации этого типа для R4 будет что-то вроде этого.

R4(config)# ip sla 1
R4(config)# icmp-echo 10.1.1.9 source-interface Serial0/3/0
R4(config)# timeout 1000
R4(config)# threshold 2
R4(config)# frequency 3
R4(config)# ip sla schedule 1 life forever start-time now
R4(config)# track 1 ip sla 1 reachability
R4(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.9 track 1
R4(config)# ip route 0.0.0.0 0.0.0.0 192.168.8.11 100

_{измененная версия примера конфигурации firewall.cx .}

Но, как вы быстро выясните, это далеко не идеальный способ сделать это. Автоматизация этого с EIGRP, вероятно, является лучшим выбором, поскольку у вас есть все оборудование Cisco.

Но если динамическая маршрутизация - это путь, он должен быть реализован таким образом, чтобы не нарушать обслуживание.

Если вы настраиваете EIGRP в сочетании со своими статическими маршрутами. Будут построены отношения соседей EIGRP, и ваши таблицы маршрутизации будут заполнены маршрутами в разные места. На самом деле не должно происходить сбоев, потому что ваши маршрутизаторы будут иметь полностью заполненную таблицу маршрутизации со знанием того, как добраться до других подсетей.

Просто помните, что когда все настроено и работает гладко с EIGRP и статической маршрутизацией, вы все равно будете использовать ваши статические маршруты, пока вы не удалите их. Если все сделано правильно, вы даже не заметите проблески трафика.

Сравните ваши предыдущие конфигурации с примером конфигурации EIGRP для R4.

R4(config)#router eigrp 1
R4(config-router)#no auto-summary
R4(config-router)#network 10.1.1.8
R4(config-router)#network 192.168.8.0

Обычно это так просто для такой маленькой сети.