Alan çeşitliliği T1 için yük devretme nasıl sağlanır

Aslında sorunsuz bir şekilde küçük, insular, adanmış bir ağ miras aldım, bu yüzden doğal olarak geliştirmek istiyorum :-) Ağ bilgimi düşürdüm ve okuduktan sonra 1-10 arası bir ölçekte 2-3 arası bir yere kavuştum ağ paylaşımları burada. Netlik için sadece ilgili yönlendiricileri diyagramıma ekledim.

Şu anda, her kampüste özel bir ev uygulaması için ses kartlarıyla kabaca 6-8 Cisco 2800 ve 2900'ün bir karışımı var ve 2 kampüs arasında paketleri almak için statik yollar kullanıyor. R1 ve R2'de c2801-spservicesk9-mz.124-3g ve R3 ve R4'te c2800nm-adventerprisek9-mz.124-15.t3 çalıştırıyorlar.

Bu, yalnızca bu özel uygulamaya hizmet eden sabit, değişmeyen bir ağdır. Masaüstü ya da dizüstü bilgisayar gelmiyor ve gitmiyor, sadece üçüncü sunucu fiber muxes aracılığıyla her kampüsteki bir halka topolojisinde bağlı birkaç sunucu makinesi ("diğer düğümlerin" parçası) ile bağlı Cisco yönlendiricileri.

Müşteri, karar verdiğinde, yedeklilik için R2 ve R3 arasına ikinci bir T1 kurmanın harika bir fikir olacağını düşündü. Testlerime dayanarak, statik yönlendirmenin bu ikinci T1'i kullanmanın bir yolu yoktur. Yeni T1'e ikincil bir rotada AD / metrik olsa bile, yalnızca T1'i başarısız olan yönlendirici bunu bilir, ancak o kampüsteki diğer yönlendiriciler bilmez.

Ben işleri basit tutmak ve ağa üzgün en aza indirmek için bu tür çözümleri okuduktan sonra ip izleme nesneleri kullanmayı düşünüyorum. Sonra EIGRP'nin bununla başa çıkmak için tercih edilen yol olduğunu okudum.

Ancak dinamik yönlendirme gitmek için bir yolsa, hizmeti kesintiye uğratmayacak şekilde uygulanmalıdır. Bunların hepsi benim için uzak ve yeniden yapılandırma sırasında bağlantımı kaybetmem durumunda yerel bir teknisyenin beklemesini ayarlamam gerekiyor. Umarım bu kadar küçük, değişmeyen bir ağ ile bu aksama en aza indirilebilir.

Peki, bu T1 yük devretme yönlendirmesini gerçekleştirmek için ip izleme nesnelerini veya EIGRP'yi nasıl kullanacağımı araştırmalı mıyım?

EDIT: İşte R4 için şu anda yapılandırılmış yollar. Burada biraz sadakat olduğundan eminim, ama basitleştirmek için tam olarak bir kez denedim ve küçük bir hata yaptığımda ve Kampüs B ile bağlantıyı kaybettiğimde geri çekildim. Kesintiler büyük bir hayır. Daha iyi bir yaklaşım geliştirene kadar yeterince yalnız bırakmaya karar verdim.

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 için rota yapılandırması basittir:

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

Teşekkürler.

Bu, yalnızca bu özel uygulamaya hizmet eden sabit, değişmeyen bir ağdır.

Bence bu, değişmeyen ağlarda bile nadiren ağ iletişimi ile ilgili bir normdur; bu yüzden neden burada bunu otomatikleştireceğinizi soruyorsunuz. Sonunda, önceki tüm çabalarınızı yeniden yapılandırmanızı gerektiren başka bir bağlantı çevrimiçi olur. Tanım olarak, bir yönlendirme protokolünün amacı budur. Her yerde statik yollar kullanmak zorunda olmadığınızdan emin olmak içindir!

Testlerime dayanarak, statik yönlendirmenin bu ikinci T1'i kullanmanın bir yolu yoktur.

Sisteminizin nasıl çalıştığını koruyabilecek bir tür IP SLA kurabilirsiniz, ancak çökme durumunda yük devretmeye izin verirsiniz Old T1.

R4 için bu tür bir yapılandırmaya bir örnek böyle bir şey olacaktır.

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 örnek yapılandırmasının değiştirilmiş sürümü .}

Ancak, hızlı bir şekilde öğrendiğiniz gibi, bunu yapmanın ideal yolu daha azdır. Tüm Cisco donanımına sahip olduğunuz için EIGRP ile bunu otomatikleştirmek muhtemelen en iyi seçenektir.

Ancak dinamik yönlendirme gitmek için bir yolsa, hizmeti kesintiye uğratmayacak şekilde uygulanmalıdır.

EIGRP'yi statik rotalarınızla birlikte kurarsanız. EIGRP komşu ilişkileri kurulacak ve yönlendirme tablolarınız farklı konumlara giden yollarla doldurulacak. Gerçekten hiçbir kesinti olmamalıdır, çünkü yönlendiricileriniz diğer alt ağlara nasıl ulaşılacağına dair bilgi içeren tamamen doldurulmuş bir yönlendirme tablosuna sahip olacaktır.

Unutmayın, her şey kurulduktan ve hem EIGRP hem de statik yönlendirme ile sorunsuz bir şekilde çalıştığında, siz onları kaldırana kadar statik yollarınızı kullanmaya devam edersiniz. Düzgün yapıldığında, trafik akışında bir düşüş fark etmemelisiniz.

Önceki yapılandırmalarınızı R4 için örnek bir EIGRP yapılandırmasıyla karşılaştırın.

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

Böyle küçük bir ağ için genellikle bu kadar basittir.