Bugün OSPF yönlendirmesini öğrenmeye başlayacağız. Bu konu, EIGRP protokolü gibi, CCNA kursunun tamamındaki en önemli konudur. Gördüğünüz gibi Bölüm 2.4, “IPv2 için OSPFv4 Tek Bölgeli ve Çoklu Bölgeyi Yapılandırma, Test Etme ve Sorun Giderme (Kimlik Doğrulama, Filtreleme, Manuel Rota Özetleme, Yeniden Dağıtım, Saplama Alanı, VNet ve LSA Hariç)” başlığını taşımaktadır.
OSPF konusu oldukça kapsamlı olduğundan 2, belki 3 video dersi alacaktır. Bugünkü dersimiz konunun teorik yönüne ayrılacak, size bu protokolün genel anlamda ne olduğunu ve nasıl çalıştığını anlatacağım. Bir sonraki videoda Packet Tracer kullanarak OSPF yapılandırma moduna geçeceğiz.
Bu derste üç konuyu ele alacağız: OSPF nedir, nasıl çalışır ve OSPF bölgeleri nelerdir. Önceki dersimizde OSPF'nin, yönlendiriciler arasındaki iletişim bağlantılarını inceleyen ve bu bağlantıların hızına göre kararlar veren bir Bağlantı Durumu yönlendirme protokolü olduğunu söylemiştik. Daha yüksek hıza sahip, yani daha fazla iş hacmine sahip uzun bir kanala, daha az iş hacmine sahip kısa bir kanala göre öncelik verilecektir.
Bir uzaklık vektör protokolü olan RIP protokolü, bu bağlantının hızı düşük olsa bile tek atlamalı bir yol seçecektir ve OSPF protokolü, bu yoldaki toplam hızın, bu yoldaki toplam hızdan daha yüksek olması durumunda birkaç atlamadan oluşan uzun bir yol seçecektir. Kısa rotadaki trafik hızı.
Karar algoritmasına daha sonra bakacağız ancak şimdilik OSPF'nin bir Bağlantı Durumu Protokolü olduğunu unutmamalısınız. Bu açık standart, her ağ ekipmanı üreticisinin ve her ağ sağlayıcısının kullanabilmesi için 1988 yılında oluşturuldu. Bu nedenle OSPF, EIGRP'den çok daha popülerdir.
OSPF sürüm 2 yalnızca IPv4'ü destekledi ve bir yıl sonra, 1989'da geliştiriciler, IPv3'yı destekleyen sürüm 6'ü duyurdu. Ancak IPv6 için OSPF'nin tamamen işlevsel üçüncü sürümü yalnızca 2008'de ortaya çıktı. Neden OSPF'yi seçtiniz? Son derste bu dahili ağ geçidi protokolünün rota yakınsamasını RIP'ten çok daha hızlı gerçekleştirdiğini öğrendik. Bu sınıfsız bir protokoldür.
Hatırlarsanız RIP classful bir protokol yani subnet mask bilgisi göndermiyor, A/24 sınıfı IP adresiyle karşılaştığında kabul etmiyor. Örneğin 10.1.1.0/24 gibi bir IP adresi ile sunarsanız, bir ağın birden fazla alt ağ maskesi kullanılarak alt ağa bağlandığını anlamadığından ağ 10.0.0.0 olarak algılayacaktır.
OSPF güvenli bir protokoldür. Örneğin, iki yönlendirici OSPF bilgilerini paylaşıyorsa kimlik doğrulamayı, bilgileri yalnızca bir parola girdikten sonra komşu yönlendiriciyle paylaşabilecek şekilde yapılandırabilirsiniz. Daha önce de söylediğimiz gibi bu açık bir standarttır, dolayısıyla OSPF birçok ağ ekipmanı üreticisi tarafından kullanılmaktadır.
Küresel anlamda OSPF, Bağlantı Durumu Reklamlarının veya LSA'ların değişimine yönelik bir mekanizmadır. LSA mesajları yönlendirici tarafından oluşturulur ve birçok bilgi içerir: yönlendiricinin benzersiz tanımlayıcı yönlendirici kimliği, yönlendiricinin bildiği ağlarla ilgili veriler, maliyetleriyle ilgili veriler vb. Yönlendirici, yönlendirme kararları verebilmek için tüm bu bilgilere ihtiyaç duyar.
Yönlendirici R3, LSA bilgilerini yönlendirici R5'e gönderir ve yönlendirici R5, LSA bilgilerini R3 ile paylaşır. Bu LSA'lar Bağlantı Durumu Veri Tabanını veya LSDB'yi oluşturan veri yapısını temsil eder. Yönlendirici alınan tüm LSA'ları toplar ve bunları LSDB'sine yerleştirir. Her iki yönlendirici de veritabanlarını oluşturduktan sonra, komşuları keşfetmeye yarayan Merhaba mesajları alışverişinde bulunurlar ve LSDB'lerini karşılaştırma prosedürünü başlatırlar.
Yönlendirici R3, yönlendirici R5'e bir DBD veya "veritabanı açıklaması" mesajı gönderir ve R5, DBD'sini yönlendirici R3'e gönderir. Bu mesajlar, her yönlendiricinin veritabanlarında bulunan LSA dizinlerini içerir. DBD'yi aldıktan sonra R3, R5'e "Zaten 3,4 ve 9 numaralı mesajlarım var, bu yüzden bana yalnızca 5 ve 7'yi gönder" diyen bir LSR ağ durumu isteği gönderir.
R5 de aynısını yaparak üçüncü yönlendiriciye şunu söyler: "Elimde 3,4 ve 9 bilgileri var, bu yüzden bana 1 ve 2'yi gönder." LSR taleplerini alan yönlendiriciler, LSU ağ durumu güncelleme paketlerini geri gönderir, yani LSR'sine yanıt olarak üçüncü yönlendirici, yönlendirici R5'ten bir LSU alır. Yönlendiriciler veritabanlarını güncelledikten sonra, 100 yönlendiriciniz olsa bile hepsi aynı LSDB'lere sahip olacaktır. Yönlendiricilerde LSDB veritabanları oluşturulduktan sonra, her biri bir bütün olarak ağın tamamı hakkında bilgi sahibi olacaktır. OSPF protokolü, yönlendirme tablosunu oluşturmak için Önce En Kısa Yol algoritmasını kullanır, bu nedenle doğru çalışması için en önemli koşul, ağdaki tüm cihazların LSDB'lerinin senkronize olmasıdır.
Yukarıdaki şemada her biri komşularıyla LSR, LSU vb. mesaj alışverişi yapan 9 yönlendirici bulunmaktadır. Hepsi birbirine OSPF protokolü üzerinden çalışmayı destekleyen p2p veya "noktadan noktaya" arayüzler aracılığıyla bağlanır ve aynı LSDB'yi oluşturmak için birbirleriyle etkileşime girer.
Bazlar senkronize edilir edilmez, her yönlendirici en kısa yol algoritmasını kullanarak kendi yönlendirme tablosunu oluşturur. Bu tablolar farklı yönlendiriciler için farklı olacaktır. Yani, tüm yönlendiriciler aynı LSDB'yi kullanır, ancak en kısa rotalarla ilgili kendi değerlendirmelerine göre yönlendirme tabloları oluştururlar. Bu algoritmayı kullanmak için OSPF'nin LSDB'yi düzenli olarak güncellemesi gerekir.
Dolayısıyla, OSPF'nin kendi kendine çalışabilmesi için öncelikle 3 koşulu sağlaması gerekir: komşuları bulmak, LSDB'yi oluşturup güncellemek ve bir yönlendirme tablosu oluşturmak. İlk koşulu yerine getirmek için ağ yöneticisinin yönlendirici kimliğini, zamanlamaları veya joker karakter maskesini manuel olarak yapılandırması gerekebilir. Bir sonraki videoda OSPF ile çalışacak cihaz kurulumuna bakacağız, şimdilik bu protokolün ters maske kullandığını ve eğer eşleşmiyorsa, alt ağlarınız eşleşmiyorsa veya kimlik doğrulaması eşleşmiyorsa bilmelisiniz. , yönlendiricilerden oluşan bir mahalle oluşamayacaktır. Bu nedenle, OSPF'de sorun giderirken, bu mahallenin neden oluşmadığını bulmanız, yani yukarıdaki parametrelerin eşleşip eşleşmediğini kontrol etmeniz gerekir.
Bir ağ yöneticisi olarak LSDB oluşturma sürecine dahil olmazsınız. Veritabanları, yönlendirme tablolarının oluşturulmasında olduğu gibi, bir yönlendirici mahallesi oluşturulduktan sonra otomatik olarak güncellenir. Tüm bunlar, OSPF protokolüyle çalışacak şekilde yapılandırılmış cihazın kendisi tarafından gerçekleştirilir.
Bir örneğe bakalım. Basitlik açısından RID'leri 2 ve 1.1.1.1 olarak atadığım 2.2.2.2 yönlendiricimiz var. Bunları bağladığımız anda bağlantı kanalı hemen yukarı duruma geçecektir çünkü bu yönlendiricileri ilk önce OSPF ile çalışacak şekilde yapılandırdım. Bir iletişim kanalı oluşur oluşmaz A yönlendiricisi, A yönlendiricisine hemen bir Merhaba paketi gönderecektir. Bu paket, bu yönlendiricinin ilk kez Merhaba gönderdiği için bu kanalda henüz kimseyi "görmediği" bilgisini, kendi tanımlayıcısını, kendisine bağlı ağ hakkındaki verileri ve görebileceği diğer bilgileri içerecektir. bir komşuyla paylaşmak.
Bu paketi alan yönlendirici B, "Bu iletişim kanalında OSPF komşusu için potansiyel bir aday olduğunu görüyorum" diyecek ve Başlatma durumuna geçecektir. Merhaba paketi bir tek noktaya yayın veya genel yayın mesajı değildir, çok noktaya yayın OSPF IP adresi 224.0.0.5'e gönderilen çok noktaya yayın paketidir. Bazı insanlar çok noktaya yayın için alt ağ maskesinin ne olduğunu soruyor. Gerçek şu ki, çok noktaya yayının bir alt ağ maskesi yoktur; frekansına ayarlanmış tüm cihazlar tarafından duyulan bir radyo sinyali olarak yayılır. Örneğin 91,0 frekansında yayın yapan bir FM radyoyu dinlemek istiyorsanız radyonuzu o frekansa ayarlarsınız.
Aynı şekilde, yönlendirici B, 224.0.0.5 çoklu yayın adresi için mesajları alacak şekilde yapılandırılmıştır. Bu kanalı dinlerken Yönlendirici A'nın gönderdiği Merhaba paketini alır ve kendi mesajıyla yanıt verir.
Bu durumda bir mahalle ancak B cevabının bir dizi kriteri karşılaması durumunda kurulabilir. İlk kriter, Hello mesajlarının gönderilme sıklığı ve bu mesaja yanıt için bekleme aralığının her iki yönlendirici için de Ölü Aralığın aynı olması gerektiğidir. Tipik olarak Ölü Aralık birkaç Merhaba zamanlayıcı değerine eşittir. Yani A yönlendiricisinin Merhaba Zamanlayıcısı 10 s ise ve B yönlendiricisi 30 s sonra mesaj gönderirse, Ölü Aralık 20 s ise bitişiklik gerçekleşmeyecektir.
İkinci kriter, her iki yönlendiricinin de aynı tür kimlik doğrulamayı kullanması gerektiğidir. Buna göre kimlik doğrulama şifrelerinin de eşleşmesi gerekir.
Üçüncü kriter Arial ID bölge tanımlayıcılarının eşleşmesi, dördüncüsü ise ağ önekinin uzunluğunun eşleşmesidir. Yönlendirici A bir /24 öneki rapor ediyorsa, Yönlendirici B'nin de bir /24 ağ önekine sahip olması gerekir. Bir sonraki videoda buna daha detaylı bakacağız, şimdilik bunun bir alt ağ maskesi olmadığını belirteceğim, burada yönlendiriciler ters Wildcard maskesi kullanıyor. Ve elbette, yönlendiriciler bu bölgedeyse Stub alanı bayraklarının da eşleşmesi gerekir.
Bu kriterleri kontrol ettikten sonra eğer eşleşiyorsa yönlendirici B, Hello paketini A yönlendiricisine gönderir. A'nın mesajının aksine Yönlendirici B, Yönlendirici A'yı gördüğünü bildirir ve kendisini tanıtır.
Bu mesaja yanıt olarak A yönlendiricisi, B yönlendiricisine tekrar Merhaba gönderir ve burada B yönlendiricisini de gördüğünü, aralarındaki iletişim kanalının 1.1.1.1 ve 2.2.2.2 cihazlarından oluştuğunu ve kendisinin 1.1.1.1 cihazı olduğunu onaylar. . Bu mahalle kurmanın çok önemli bir aşamasıdır. Bu durumda, iki yönlü 2 YÖNLÜ bağlantı kullanılır, ancak 4 yönlendiriciden oluşan dağıtılmış bir ağa sahip bir anahtarımız varsa ne olur? Böyle bir "paylaşılan" ortamda, yönlendiricilerden biri Atanmış yönlendirici DR rolünü oynamalı ve ikincisi Yedek atanmış yönlendirici BDR rolünü oynamalıdır.
Bu cihazların her biri bir Tam bağlantı veya tam bir bitişiklik durumu oluşturacaktır, bunun ne olduğuna daha sonra bakacağız, ancak bu tür bir bağlantı yalnızca DR ve BDR ile kurulacaktır; iki alt yönlendirici D ve B, hala "noktadan noktaya" iki yönlü bir bağlantı şeması kullanarak birbirleriyle iletişim kuruyorlar.
Yani, DR ve BDR ile tüm yönlendiriciler tam bir komşuluk ilişkisi ve birbirleriyle noktadan noktaya bir bağlantı kurar. Bu çok önemlidir çünkü bitişik cihazlar arasındaki iki yönlü bağlantı sırasında tüm Hello paketi parametrelerinin eşleşmesi gerekir. Bizim durumumuzda her şey eşleşiyor, dolayısıyla cihazlar sorunsuz bir mahalle oluşturuyor.
İki yönlü iletişim kurulur kurulmaz, A yönlendiricisi, B yönlendiricisine bir Veritabanı Açıklama paketi veya "veritabanı açıklaması" gönderir ve ExStart durumuna - değişimin başlangıcına veya yüklemeyi beklemeye - girer. Veritabanı Tanımlayıcısı, bir kitabın içindekiler tablosuna benzer bilgilerdir; yönlendirme veritabanındaki her şeyin bir listesidir. Yanıt olarak Yönlendirici B, veritabanı açıklamasını Yönlendirici A'ya gönderir ve Exchange kanalı iletişim durumuna girer. Exchange durumunda, yönlendirici veritabanında bazı bilgilerin eksik olduğunu tespit ederse, LOADING yükleme durumuna geçecek ve komşusuyla LSR, LSU ve LSA mesajlarını alışverişine başlayacaktır.
Yani, A yönlendiricisi komşusuna bir LSR gönderecek ve komşusu bir LSU paketiyle yanıt verecek ve A yönlendiricisi B yönlendiricisine bir LSA mesajıyla yanıt verecek. Bu değişim, cihazların LSA mesajları alışverişi yapmak istediği sayıda gerçekleşecektir. LOADING durumu, LSA veritabanının tam güncellemesinin henüz gerçekleşmediği anlamına gelir. Tüm veriler indirildikten sonra her iki cihaz da TAM bitişiklik durumuna girecektir.
İki yönlü bağlantıda cihazların yalnızca bitişik durumda olduğunu ve tam bitişiklik durumunun yalnızca yönlendiriciler, DR ve BDR arasında mümkün olduğunu unutmayın. Bu, her yönlendiricinin DR'yi ağdaki ve tüm yönlendiricilerdeki değişiklikler hakkında bilgilendirdiği anlamına gelir DR'den bu değişiklikler hakkında bilgi edinin
DR ve BDR seçimi önemli bir konudur. Genel ortamda DR'nin nasıl seçildiğine bakalım. Şemamızın üç yönlendiricisi ve bir anahtarı olduğunu varsayalım. OSPF cihazları önce Merhaba mesajlarındaki önceliği karşılaştırır, ardından Yönlendirici Kimliğini karşılaştırır.
En yüksek önceliğe sahip cihaz DR olur. İki cihazın öncelikleri çakışırsa, en yüksek Yönlendirici Kimliğine sahip cihaz ikisinden seçilir ve DR olur.
İkinci en yüksek önceliğe veya ikinci en yüksek Yönlendirici Kimliğine sahip cihaz, yedek özel yönlendirici BDR olur. DR başarısız olursa, hemen BDR ile değiştirilecektir. DR rolünü oynamaya başlayacak ve sistem başka bir tane seçecektir. BDR
Umarım DR ve BDR seçimini çözmüşsünüzdür, eğer anlamadıysanız aşağıdaki videolardan birinde bu konuya dönüp bu süreci anlatacağım.
Şu ana kadar Hello'nun ne olduğuna, Veritabanı Tanımlayıcısına ve LSR, LSU ve LSA mesajlarına baktık. Bir sonraki konuya geçmeden önce OSPF'nin maliyetinden biraz bahsedelim.
Cisco'da rotanın maliyeti, varsayılan olarak 100 Mbit/s olarak ayarlanan Referans bant genişliğinin kanal maliyetine oranı formülü kullanılarak hesaplanır. Örneğin cihazları seri port üzerinden bağlarken hız 1.544 Mbps, maliyeti 64 olacaktır. 10 Mbps hızında Ethernet bağlantısı kullanıldığında maliyet 10, FastEthernet bağlantısının maliyeti ise 100 olacaktır. 1 Mbps hız XNUMX olacaktır.
Gigabit Ethernet kullanırken 1000 Mbps hızımız vardır ancak bu durumda hızın her zaman 1 olduğu varsayılır. Yani ağınızda Gigabit Ethernet varsa varsayılan Ref değerini değiştirmeniz gerekir. BW 1000. Bu durumda maliyet 1 olacak ve tablonun tamamı 10 kat artan maliyet değerleri ile yeniden hesaplanacaktır. Bitişikliği oluşturduktan ve LSDB'yi oluşturduktan sonra yönlendirme tablosunu oluşturmaya geçiyoruz.
LSDB'yi aldıktan sonra, her yönlendirici bağımsız olarak SPF algoritmasını kullanarak bir rota listesi oluşturmaya başlar. Bizim şemamızda A yönlendiricisi kendisi için böyle bir tablo oluşturacaktır. Örneğin, A-R1 güzergahının maliyetini hesaplar ve 10 olarak belirler. Diyagramın anlaşılmasını kolaylaştırmak için, A yönlendiricisinin, B yönlendiricisine giden en uygun rotayı belirlediğini varsayalım. A-R1 bağlantısının maliyeti 10'dur. A-R2 bağlantısı 100'dür ve A-R3 yolunun maliyeti 11'e, yani A-R1(10) ve R1-R3(1) yollarının toplamına eşittir.
A yönlendiricisi, R4 yönlendiricisine ulaşmak istiyorsa, bunu ya A-R1-R4 yolu üzerinden ya da A-R2-R4 yolu üzerinden yapabilir ve her iki durumda da yolların maliyeti aynı olacaktır: 10+100 =100+10=110. A-R6 rotası 100+1= 101'e mal olacak ki bu zaten daha iyi. Daha sonra, maliyeti 5+1+3 = 5 olacak olan A-R10-R1-R100 yolu boyunca R111 yönlendiricisine giden yolu ele alıyoruz.
R7 yönlendiricisine giden yol iki yol boyunca döşenebilir: A-R1-R4-R7 veya A-R2-R6-R7. İlkinin maliyeti 210, ikincisi - 201 olacak, bu da 201'i seçmeniz gerektiği anlamına geliyor. Yani, B yönlendiricisine ulaşmak için A yönlendiricisi 4 rota kullanabilir.
A-R1-R3-R5-B güzergahının ücreti 121, A-R1-R4-R7-B güzergahının ücreti 220, A-R2-R4-R7-B güzergahının ücreti 210, A-R2- güzergahının maliyeti olacak. R6-R7-B'nin maliyeti 211'dir. Buna göre A yönlendiricisi 121'e eşit en düşük maliyetli rotayı seçip yönlendirme tablosuna yerleştirecektir. Bu, SPF algoritmasının nasıl çalıştığını gösteren çok basitleştirilmiş bir diyagramdır. Aslında, tablo yalnızca optimum rotanın geçtiği yönlendiricilerin tanımlarını değil, aynı zamanda bunları bağlayan bağlantı noktalarının tanımlarını ve diğer tüm gerekli bilgileri de içerir.
Yönlendirme bölgeleriyle ilgili başka bir konuya bakalım. Genellikle bir şirketin OSPF cihazlarını kurarken hepsi tek bir ortak bölgede bulunur.
R3 yönlendiricisine bağlanan cihaz aniden arızalanırsa ne olur? Yönlendirici R3, R5 ve R1 yönlendiricilerine, bu cihazdaki kanalın artık çalışmadığını belirten bir mesaj göndermeye hemen başlayacak ve tüm yönlendiriciler bu olayla ilgili güncelleme alışverişinde bulunmaya başlayacaktır.
100 yönlendiriciniz varsa hepsi aynı ortak bölgede olduklarından bağlantı durumu bilgilerini güncellerler. Komşu yönlendiricilerden biri arızalanırsa aynı şey olacaktır; bölgedeki tüm cihazlar LSA güncellemelerini değiştirecektir. Bu tür mesajların alışverişinden sonra ağ topolojisinin kendisi değişecektir. Bu gerçekleştiğinde SPF, yönlendirme tablolarını değişen koşullara göre yeniden hesaplayacaktır. Bu çok büyük bir işlemdir ve bir bölgede bin cihazınız varsa, yönlendiricilerin bellek boyutunu, tüm LSA'ları ve büyük LSDB bağlantı durumu veritabanını depolamak için yeterli olacak şekilde kontrol etmeniz gerekir. Bölgenin bir kısmında değişiklik meydana gelir gelmez SPF algoritması rotaları hemen yeniden hesaplar. Varsayılan olarak LSA her 30 dakikada bir güncellenir. Bu işlem tüm cihazlarda aynı anda gerçekleşmez, ancak her durumda güncellemeler her yönlendirici tarafından 30 dakikada bir gerçekleştirilir. Daha fazla ağ cihazı. LSDB'yi güncellemek için daha fazla bellek ve zaman gerekir.
Bu sorun, bir ortak bölgenin birkaç ayrı bölgeye bölünmesiyle, yani çoklu bölgelendirmenin kullanılmasıyla çözülebilir. Bunu yapmak için yönettiğiniz tüm ağın bir planına veya diyagramına sahip olmanız gerekir. ALAN 0 Ana alandır. Burası, örneğin internete erişim gibi harici ağa bağlantının yapıldığı yerdir. Yeni bölgeler oluştururken şu kurala uymalısınız: her bölgenin bir ABR'si, Alan Sınır Yönlendiricisi olmalıdır. Bir uç yönlendiricinin bir bölgede bir arayüzü ve diğer bölgede ikinci bir arayüzü vardır. Örneğin R5 yönlendiricinin bölge 1 ve bölge 0'da arayüzleri vardır. Dediğim gibi bölgelerin her birinin sıfır bölgesine bağlanması yani arayüzlerinden biri AREA 0'a bağlı olan bir kenar yönlendiriciye sahip olması gerekir.
R6-R7 bağlantısının başarısız olduğunu varsayalım. Bu durumda, LSA güncellemesi yalnızca ALAN 1 üzerinden yayılacak ve yalnızca bu bölgeyi etkileyecektir. Bölge 2 ve Bölge 0'daki cihazların bundan haberi bile olmayacak. Kenar yönlendirici R5, kendi bölgesinde olup bitenlerle ilgili bilgileri özetler ve ağın durumu hakkında özet bilgileri AREA 0 ana bölgesine gönderir. ABR yönlendirici özet rota bilgilerini bir bölgeden diğerine ileteceğinden, bir bölgedeki cihazların diğer bölgelerdeki tüm LSA değişikliklerinden haberdar olması gerekmez.
Bölge kavramı konusunda tam olarak bilgi sahibi değilseniz, sonraki derslerde OSPF yönlendirmesini yapılandırmaya başladığımızda ve bazı örneklere baktığımızda daha fazla bilgi edinebilirsiniz.
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, Habr kullanıcıları için, bizim tarafımızdan sizin için icat ettiğimiz benzersiz bir giriş seviyesi sunucu analogunda %30 indirim:
Dell R730xd 2 kat daha mı ucuz? Sadece burada
Kaynak: habr.com