DMVPN (3): Faz 1

Önceki yazımda NHRP kullanarak bir router’ın mGRE tünelindeki diğer routerların tunnel source IP’lerini – her birini statik olarak girmektense – nasıl dinamik olarak keşfedebildiğinden bahsetmiştim. Bunun yanı sıra ilk yazımda da bahsettiğim gibi DMVPN’in en verimli şekilde çalışabilmesi için hem tünel source IP’si keşfinin hem de routing’in dinamik olarak yapılması gerekmektedir. Önceki yazılarımda ise mGRE’nin çalışma mantığını anlatırken basitlik adına routing’i hep statik yapmıştım. Bu yazıdan itibaren routing’i de dinamik yapacağız.

DMVPN’de dinamik routing yapıldığında routing’in çalışma mekanizmasına göre DMVPN yapılandırmaları üç ayrı fazda incelenir. Biz bu yazıda birinci fazdan bahsedeceğiz.

Diğer fazları önümüzdeki yazılarda inceleyecek olsak da yazının girişinde tüm fazlarla ilgili temel bir bilgilendirme yapayım. Faz 1’de spoke’lar birbirleriyle doğrudan değil merkez üzerinden haberleşirler. Faz 2’de merkez ve tüm spoke’lar tüm rotaları bilir ve birbirleriyle doğrudan haberleşebilir. Faz 3’te ise tüm spoke’lar tüm rotalara merkez üzerinden gidilyor şeklinde bilir ama spoke’lar arasında iletişim yine doğrudan gerçekleşir.

Faz 1’de tüm trafik merkezden döndüğü için temel avantajı merkezde her spoke’a bir GRE tüneli kurmadan tek bir mGRE tüneliyle karmaşıklığı azaltmak ve yönetimi kolaylaştırmaktır. Daha küçük ölçekli topolojilerde spoke’larda mGRE tüneli yerine klasik GRE tünelleri de kullanılabilir ama bu durumda spoke’larda NHRP çalışmayacağı için hub’da her spoke için bir NHRP girdisi girmek gerekecektir.

Bildiğimiz gibi dinamik yönlendirme protokolleri multicast kullanır. Bir multicast paket tünele girdiğinde yani GRE ile kapsüllendiğinde yeni eklenen IP başlığındaki hedef IP ise unicast olacaktır. Dolayısıyla mGRE tüneline giren multicast bir paketin tünelin hangi ucuna gideceğini belirtmek gerekiyor. Bu amaçla spoke’lara tunnel interface altında ip nhrp map multicast 20.0.0.1 yazacağız. Hub’da ise multicast paketleri dinamik olarak register olan spoke’lara göndermesini sağlayan ip nhrp map multicast dynamic yazacağız.

Ayrıca kullandığımız dinamik yönlendirme protokolünde de bazı ayarlar yapmamız gerekecektir. Distance vector protokollerde Hub’ın tünel interface’inden öğrendiği rotayı yine tünel interface’inden öğretebilmesi için split-horizon kuralını devre dışı bırakmalıyız. Bunu no ip split-horizon komutuyla RIP için, sonuna eigrp 10 şeklinde AS numarasını ekleyerek belirli bir EIGRP prosesi için yapabiliriz.

OSPF’te ise network-type belirlenmelidir. Multi-access bir topoloji söz konusu olduğu için point-to-point kullanılmaz. Non-broadcast bir network-type kullanılacak olursa da komşulukların statik olarak tanımlanması gerekir ki bu da yapının dinamikliğiyle uyuşmaz. Faz 1’de tüm trafik hub üzerinden döndüğü için OSPF sanki tüm spoke’lar sadece hub’a bağlıymış gibi çalıştırılır. Bunun için de tüm router’larda tunnel interface altında ip ospf network point-to-multipoint komutu girilir.

Faz 1’de tüm spoke’lar tüm rotaları hub üzerinde bildiği için hub’dan gönderilen routing update’lerinde özetleme yapılması sıklıkla kullanılır.Hatta hub’dan spoke’lara sadece default rota gönderilmesi veya spoke’larda default rota yazılması da söz konusu olabilir. Bu sayede spoke’larda routing table’lar küçük tutulmuş olur.

Ayrıca Faz 1’de NRHP sorguları olmaz. Çünkü tüm spoke’lar sadece hub’a trafik yollar ve onun tünel source IP’sini de zaten statik olarak bilir.

Bir sonraki yazıda tüm router’ların tüm rotaları bildiği ve birbirleriyle doğrudan haberleştikleri model olan DMVPN Faz 2’den 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