Jak zapewnić przełączanie awaryjne dla różnorodności przestrzeni T1

Odziedziczyłem małą, wyspiarską, dedykowaną sieć, która jest zasadniczo bezproblemowa, więc naturalnie chcę ją ulepszyć :-) Po przeczytaniu obniżyłem swoją wiedzę o sieci i jestem doświadczony do około 2 do 3 w skali 1-10. posty sieciowe. Dla jasności umieściłem tylko odpowiednie routery na moim schemacie.

Obecnie w każdym kampusie znajduje się około 6-8 Cisco 2800 i 2900 z kartami głosowymi do dedykowanej aplikacji domowej, wykorzystując trasy statyczne, aby uzyskać pakiety między 2 kampusami. Działają c2801-spservicesk9-mz.124-3g na R1 i R2 oraz c2800nm-adventerprisek9-mz.124-15.t3 na R3 i R4.

Jest to stała, niezmienna sieć, która obsługuje tylko tę dedykowaną aplikację. Bez komputerów stacjonarnych i laptopów, tylko routery Cisco połączone przez multipleksy światłowodowe firm trzecich w topologii pierścieniowej na każdym kampusie z kilkoma podłączonymi serwerami (część „innych węzłów”).

W pewnym momencie klient zdecydował, że dobrym pomysłem byłoby zainstalowanie drugiego T1 między R2 i R3 w celu zapewnienia redundancji. Na podstawie moich testów statyczny routing nie ma możliwości wykorzystania drugiego T1. Nawet z AD / metryką na dodatkowej trasie do nowego T1 wie o tym tylko router, którego T1 uległo awarii, ale inne routery w tym kampusie nie wiedzą.

Zastanawiałem się nad użyciem obiektów śledzących ip po przeczytaniu tutaj takich rozwiązań, aby uprościć sprawę i zminimalizować problemy z siecią. Potem przeczytałem, gdzie EIGRP jest preferowanym sposobem radzenia sobie z tym.

Ale jeśli routing dynamiczny jest dobrym rozwiązaniem, musi zostać zaimplementowany w sposób, który nie zakłóca usługi. To wszystko jest dla mnie zdalne i wymagałoby ode mnie, aby lokalny technik był w pobliżu, na wypadek utraty połączenia podczas rekonfiguracji. Mamy nadzieję, że przy tak małej, niezmiennej sieci zakłócenia te można zminimalizować.

Czy powinienem więc badać, w jaki sposób wykorzystać obiekty śledzenia IP lub EIGRP, aby zrealizować routing przełączania awaryjnego T1?

EDYCJA: Oto aktualnie skonfigurowane trasy dla R4. Jestem całkiem pewien, że jest tu trochę cruft, ale próbowałem dokładnie to uprościć i wycofałem się, kiedy popełniłem jeden drobny błąd i straciłem łączność z Campus B. Awarie są wielkim nie-nie. Postanowiłem odejść wystarczająco dobrze, dopóki nie wymyśliłem lepszego podejścia.

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

Konfiguracja trasy dla R3 jest prosta:

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

Dzięki.

Jest to stała, niezmienna sieć, która obsługuje tylko tę dedykowaną aplikację.

Myślę, że okazuje się, że rzadko jest to normą w sieci, nawet w niezmiennych sieciach; dlatego pytasz, jak to zautomatyzować. W końcu pojawia się kolejny link, który wymaga ponownego zaprojektowania wszystkich poprzednich działań. Z definicji taki jest cel protokołu routingu. Ma to na celu upewnienie się, że nie musisz wszędzie korzystać z tras statycznych!

Na podstawie moich testów statyczny routing nie ma możliwości wykorzystania drugiego T1.

Możesz skonfigurować rodzaj umowy SLA IP, która może utrzymywać twój system działający tak, jak jest, jednocześnie pozwalając na przełączenie awaryjne na wypadek Old T1awarii.

Przykładem tego typu konfiguracji dla R4 może być coś takiego.

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

_{zmodyfikowana wersja przykładowej konfiguracji firewall.cx .}

Ale, jak szybko się dowiadujesz, jest to mniej niż idealny sposób na zrobienie tego. Zautomatyzowanie tego za pomocą EIGRP jest prawdopodobnie najlepszym rozwiązaniem, ponieważ masz cały sprzęt Cisco.

Ale jeśli routing dynamiczny jest dobrym rozwiązaniem, musi zostać zaimplementowany w sposób, który nie zakłóca usługi.

Jeśli skonfigurujesz EIGRP w połączeniu ze swoimi trasami statycznymi. Zostaną zbudowane relacje EIGRP z sąsiadami, a tabele routingu zostaną wypełnione trasami do różnych lokalizacji. Naprawdę nie powinno wystąpić żadne wyłączenie, ponieważ routery będą miały w pełni zapełnioną tabelę routingu ze znajomością sposobu dostępu do innych podsieci.

Pamiętaj tylko, że gdy wszystko zostanie skonfigurowane i będzie działać płynnie zarówno z EIGRP, jak i routingiem statycznym, nadal będziesz używać tras statycznych, dopóki ich nie usuniesz. Wykonane poprawnie, nie powinieneś nawet zauważać załamania ruchu.

Porównaj swoje poprzednie konfiguracje z przykładową konfiguracją EIGRP dla 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

Jest to zwykle takie proste w przypadku tak małej sieci.