Як забезпечити відмову від просторового різноманіття 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 / metric на вторинному маршруті до нового T1 знає це лише маршрутизатор, T1 якого вийшов з ладу, але інші маршрутизатори в цьому кампусі цього не роблять.

Я розглядав можливість використання об’єктів відстеження ip після читання таких рішень тут, щоб зробити прості речі і мінімізувати засмучення в мережі. Потім я прочитав, де EIGRP є кращим способом впоратися з цим.

Але якщо динамічна маршрутизація - це шлях, вона повинна бути реалізована таким чином, що не порушує обслуговування. Це все для мене віддалено, і мені потрібно буде влаштувати місцевого техніку, щоб він був готовим, якщо я втрачу зв'язок під час переналаштування. Сподіваємось, що при такій невеликій, незмінній мережі, це порушення може бути зведено до мінімуму.

Тож чи варто мені досліджувати, як використовувати об'єкти відстеження ip або EIGRP, щоб виконати цю маршрутизацію відмови від T1?

EDIT: Ось поточно налаштовані маршрути для R4. Я досить впевнений, що тут є якась сувора, але я спробував рівно один раз спростити це і відступив, коли допустив одну крихітну помилку і втратив зв’язок з Campus B. Недоліки - це велика ні-ні. Я вирішив залишити достатньо добре в спокої, поки не придумав кращого підходу.

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

Зазвичай це так просто для такої невеликої мережі.