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


9

Отказоустойчивая сеть 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

Спасибо.

Ответы:


7

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

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

Исходя из моих тестов, статическая маршрутизация не может использовать этот второй 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

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


5
Хороший ответ. Если он использует bfd, он может сделать аварийное переключение довольно быстро, хотя вы должны быть уверены, что ваши T1 работают нормально, прежде чем вы перейдете сюда ... T1 любят собирать ошибки, которые могут вызывать колебание, если таймеры bfd слишком малы
Майк Пеннингтон

4
@MikePennington +1 для BFD. Тем не менее, я всегда хотел бы отметить (потому что это меня укусило лично), что начиная с эпохи ISR G2 и далее, BFD может потребовать обновления лицензии в зависимости от вашей версии IOS. См. Этот технический документ Cisco для получения дополнительной информации.
Бретт Ликинс,

Ключевым для меня является то, что вы указали, что статические маршруты имеют приоритет над динамическими, поэтому я буду использовать это в своих интересах. Я исследую, будут ли эти блоки поддерживать EIGRP, и реализую его, если они это сделают. Спасибо!
Bote Man

1
Административное расстояние вступает в игру, когда маршрутизатор знает об одном и том же маршруте в своей RIB и ему необходимо выбирать между ними. В вашей изолированной среде вам не понадобится шлюз по умолчанию ни на чем, кроме ваших серверов; Вы маршрутизаторы будете иметь полное знание о том, как добраться до всего остального. В лучшем случае: когда (не если) у вас сбой ссылки, вы даже не осознаёте этого.
Райан Фоули

1
@BoteMan Я не совсем уверен, что находится на другом конце линии DSL. Если он контролируется вашим интернет-провайдером, вам все равно понадобится маршрут по умолчанию на R1, чтобы добраться до внешней стороны. Если вы управляете всем, что находится на другом конце линии DSL, то да, каждый маршрутизатор должен полностью знать все остальные маршруты, и ваши серверы смогут получить доступ к линии DSL.
Райан Фоули
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.