DMVPN (4): Faz 2

Önceki yazımda DMVPN’de spoke’ların tüm rotaları hub üzerinde bildiği ve tüm trafiğin hub üzerinden döndüğü Faz 1’den bahsetmiştik. Bu yazımda da tüm router’ların tüm rotaları bildiği ve birbirlerine doğrudan eriştikleri Faz 2’den bahsedeceğiz.

Faz 1’den sonra Faz 2’den bahsederken dikkat çekmek istediğim nokta şu: Çalışma şekli perspektifinden baktığımızda Faz 2’de bir spoke diğer spoke’a trafik gönderecek olduğunda NHRP sorgusu (bkz: DMVPN (2): NHRP operasyonu) yapması gerekecektir. Faz 1’de ise NHRP sorguları olmuyordu. mGRE ve NHRP yapılandırması perspektifinden baktığımızda ise iki faz arasında hiç bir fark yoktur. Yani İki fazda da DMVPN yapısının çalışma şekli aynıdır diyebiliriz.

Peki Faz 1 ile Faz 2 arasındaki fark ne? İki faz arasındaki fark aslında DMVPN yapısından değil bu yapı üzerinde çalışan dinamik yönlendirme protokollerinin çalışma mantığının farklı olmasından kaynaklanmaktadır. Faz 1’de yönlendirme tasarımını tüm trafik merkez üzerinden dönecek şekilde yapmak gerekiyordu. Faz 2‘de ise herkes birbiriyle doğrudan haberleşebilecek şekilde yapmak gerekiyor.

Dolayısıyla DMVPN faz 2’yi yönlendirme protokolü bazlı incelemekte fayda var. EGIRP ile başlayalım:

Hatırlarsak ip nhrp map multicast 20.0.0.1 komutu ile spoke’ların tüm multicast trafiğini hub’a yönlendirmesini sağlamıştık. Spoke’lar arasında bir multicast trafiği gidip gelmediğinden birbirlerine komşu olamazlar. Peki birbirleriyle EIGRP komşuluğu olmayan iki router’ın doğrudan haberleşmesini nasıl sağlayacağız?

Bunun çözümü EIGRP’nin çalışma mantığını biraz değiştirmekten geçiyor. Hub’da tunnel interface altına yazacağımız no ip next-hop-self eigrp 10 komutu sayesinde hub’ın bir spoke’tan aldığı routing update’i diğer bir spoke’a gönderirken o rota(lar) için next hop’u değiştirmemesini sağlayacağız. Yani 20.0.0.3’ten 10.0.3.0/24 için gönderilen update hub (20.0.0.1) üzerinden 20.0.0.2’ye gönderildiğinde, 20.0.0.2 router’ı 10.0.3.0/24’ü hub’ın değil 20.0.0.3’ün arkasında görecek.

Gelelim OSPF’e. OSPF bir link-state protokolü olarak aslında tüm router’ların tüm topolojiyi bilmesi mantığındadır. Fakat Faz 1’de OSPF’i point-to-multipoint network-type’ta çalıştırarak sanki gerçekten bir hub&spoke topolojiymiş gibi çalışmasını sağlamıştık. Böylece spoke’lar tüm rotaları hub’ın üzerindeymiş gibi öğrenebilmişti. Faz 2’de ise OSPF’i gerçek doğasına geri döndürüyoruz diyebiliriz. Tüm router’larda tunnel interface altında ip ospf network broadcast komutunu girerek sanki bir broadcast network’teymiş gibi tüm router’ların tüm rotaları gerçek next-hop adresleriyle öğrenmesini sağlıyoruz.

Faz 2’de OSPF kullanırken dikkat edilmesi gereken bazı noktalar var. Birinicisi broadcast network’te DR ve BDR seçimi olur ve tüm komşuluklar hub ile kurulduğu için hub’ın mutlaka DR olması gerekir. Bunu hub’da tunnel interface altında ip ospf priority 255 komutuyla en yüksek öncelik değerini vererek sağlayabiliriz. Spoke’larda ise ip ospf priority 0 komutuyla router’ın asla DR veya BDR olmamasını sağlayabiliriz.Yedek bir hub’ımız varsa bu hub’ın da BDR olmasını isteriz ve ip ospf priority 254 komutuyla bunu yapabiliriz. Burda aynı zamanda OSPF’in DMVPN Faz 2 topolojilerindeki bir kısıtlamasıyla karşılaşıyoruz: Çok büyük topolojiler söz konusu olduğunda ve yedeklilik amaçlı 3 veya daha fazla hub istendiğinde OSPF’le bu mümkün olmuyor çünkü üçüncü hub DR veya BDR olamadığı için ölçeklenebilir bir yapı elde edilemiyor. Bunun yerine EIGRP kullanılması çoğu zaman tercih ediliyor.

Bir sonraki yazıda spoke’ların tüm rotaları hub üzerinde bildiği ama birbirleriyle de doğrudan haberleşebildiği model olan DMVPN Faz 3’ten bahsedeceğim.

Aşağıda önceki yazılarda kullandığımız topolojiyi ve EIGRP ile OSPF için hub’da ve spoke’lardan bir tanesinde interface konfigürasonlarını bulabilirisiniz.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Bir sonraki yazıda görüşmek üzere.

 

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir