Cisco Türkiye Blog
Share

LISP (Locator ID Seperation Protocol)

- February 25, 2017 6:35 pm

Bu yazımda “yeni nesil ağ mimarisi” gibi iddialı bir şekilde tanıtımı yapılan LISP’i ele alacağız. LISP’in amacından ve terminolojisinden bahsedip temel yapılandırmasını ve nasıl çalıştığını inceleyeceğiz. Sonrasında da yeni nesil ağ mimarisi sıfatını yorumlamaya çalışacağız.

Bir arkadaşımıza kargo gönderdiğimizi düşünelim. Bu paketin hedefe başarılı bir şekilde varması için paketin üstüne arkadaşımızın ismini VE adresini yazmamız gerekir. İsim ve adres bilgileri ancak birlikte geçerli bir hedef bilgisi ifade eder. Aynısı ağ dünyasında da geçerlidir. Bir web sunucusuna paket gönderdiğimizde web sunucusu bunun kendisine gönderilmek istendiğini anlar çünkü o IP adresinin kendisine ait olduğunu bilir. Bir başka deyişle IP adresi bir kimlik temsil etmektedir. Öte yandan aradaki yönlendiriciler de bu paketi doğru yere iletmek için paketin üstündeki hedef IP’sine bakıp buna göre karar verirler. Yani aynı IP adresi aynı zamanda bir lokasyon da belirtmektedir.

Diyelim ki kargoyu arkadaşımızın iş adresine gönderdik ama o sırada arkadaşımız evdeymiş. Bu durumda haliyle kargoyu teslim alamayacaktır. Yer değiştirdiğinde arkadaşımızın kimliği (normal olarak) aynı kalsa da, adres bilgisi değişmiş, neticede bu ikisinin birlikte ifade ettiği hedef bilgisi de değişmiştir. Benzer durumlar ağ dünyasında da yaşanmaktadır. Örneğin evde wi-fi üzerinden bir canlı yayın izliyoruz ve bahçede kablosuzun çekmediği bir noktaya geldik. Veri alışverişi hücresel ağ üzerinden devam edecektir. Ancak yayın kesintiye uğrayacaktır. Bunun sebebi cihaz ve kullanan aynı olsa da (kimliği değişmese de) lokasyonu değiştiği için (burda lokasyondan kasıt ağa bağlanma noktası tabi ki 🙂 ) IP adresinin değişmesidir.

Özetleyecek olursak IP adresinin lokasyon veya kimlik temsil etmesinde sorun yok. Ama ikisini AYNI ANDA temsil etmesi sorun yaratıyor. Buna çözüm olarak LISP şunu öneriyor: Kimlik için başka bir IP adresi, Lokasyon için başka bir IP adresi kullanalım. Yani aslında LISP bir tür tünelleme teknolojisidir; Lokasyon temsil eden IP’ler (underlay) üzerinden Kimlik temsil eden IP’ler (overlay) tünellenmiş olur.

Şimdi de LISP’in terminolojisine bir göz atıp sonrasında konuyu daha teknik olarak incelemeye başlayalım:

Terminoloji:

EID (Endpoint IDentifier): kimlik temsil eden IP’ler. IPv4 veya IPv6 olabilir.

RLOC (Routing Locator): Lokasyon temsil eden ve geleneksel yönlendirme mimarisiyle muhattap olan IP’ler. IPv4 veya IPv6 olabilir.

XTR: EID uzaylarını RLOC uzayı üzerinden birbirine bağlayan router. XTR aslında hem ETR (Eggress Tunnel Router) hem de ITR (Ingress Tunnel Router) rollerine sahip cihaz anlamına geliyor ama şimdilik bu kavramların detayına girmeye gerek yok.

MS (Map Server) ve MR (Map Resolver): Bu iki rol de XTR gibi çoğunlukla aynı router’da oluyor. MS/MR’da LISP domain’indeki tüm EID uzayları tanımlanıyor. XTR’lar kendi EID’lerinin RLOC’larını bu router’a kayıt ediyor ve bilmediği EID’lerin RLOC’larını bu router’a soruyor.

1-topology

Aslında bu açıdan LISP’i DNS’e benzetebiliriz. DNS’te URL’i (yani hedefin kimliğini) biliriz ve bunun üzerinden IP’yi (yani bir anlamda hedefin lokasyonunu) çözeriz. LISP’te de EID’yi (yani hedefin kimliğini) biliriz ve bunun üzerinden RLOC’u (yani hedefin lokasyonunu) çözeriz.

Bunlar LISP mimarisinin en temel bileşenlerini oluşturmaktadır. Ayrıca bir router’ın aynı anda hem XTR hem de MS/MR olması da mümkün.

Basit bir lab:

Yukarıdaki topoloji için örnek konfigürasyonlara bakalım:

2-lisp-configs

Aslında konfigürasyonlar gayet anlaşılır. database-mapping komutunda RLOC olarak IP belirtilebileceği gibi interface de belirtilebilir. Bu durumda XTR o interface’in IP’sini RLOC olarak kullanır. Bu seçenek çıkış interface’inde dinamik IP olması gibi durumlarda oldukça kullanışlıdır.

MS/MR’da oluşan LISP database’i aşağıdaki komut ile görebiliriz:

3-sh-lisp-site

Sistemin nasıl çalıştığını anlamak için XTR1’in CEF tablosuna bakalım:

4-cef

Router’da herhangi bir default route bulunmadığı için bu çıktıyı beklememiz normal. Ancak detaylı bakacak olursak:

5-cef-detail

“Attached to LISP0” ifadesinden bu entry’nin LISP sorgusunu tetiklediğini anlayabiliriz. Hatta router’da bir default route bulunsa bile bu durum değişmiyor:

6-cef-detail-default

Yani XTR bir trafiğin hedef IP’si routing table’da hiç bir rota ile eşleşmezse veya sadece default rota ile eşleşirse LISP sorgusu yapar. Ancak LISP sorgusu yapılması için bir şart var: Paketin kaynak IP’si XTR’da tanımlı bir EID uzayına ait olmalı. Aksi takdirde LISP sorgusu tetiklenmez ve XTR normal routing yapmaya çalışır. O yüzden XTR1’in loopback’inden XTR2’nin loopback’ine bir ping atıyoruz. XTR1 LISP sorgusu yapıyor ve sorgu MS/MR’a ulaşıyor. Bu noktada eğer sorgulanan IP tanımlı bir EID ile eşleşmezse MS/MR XTR’a “natively-forward” cevabı döner ve XTR yine normal routing yapmaya çalışır. Ancak sorgulanan IP database’de mevcut. Bu noktadan sonra işlem şu şekilde gerçekleşiyor: MS/MR isteği kendisi cevaplamak yerine XTR2’ye gönderiyor, XTR2 de cevabı doğrudan XTR1’e gönderiyor. Bu aşamadan sonra XTR1’deki LISP cache’ini aşağıdaki komutla görebiliriz:

7-sh-ip-lisp-map-cache

Tabii bu cache CEF’e de yansır:

8-cef-detail-2

Sonrasında da ICMP mesajları LISP encapsulation ile hedefe gönderiliyor. LISP Data Plane (yani router’ın üzerinden geçerken encapsulation uygulanan paketler) UDP 4341, Control Plane (yani router’ın kendisinin oluşturduğu LISP register, query, reply gibi mesajlar) ise UDP 4342 üzerinden taşınıyor. Aşağıda XTR1’den XTR2’ye atılan ping’in LISP encapsulation uygulanmış halini görebilirsiniz:

9

LISP konfigürasyonu tamamlandıktan sonra XTR’larda bir LISP interface’i oluşur. Bu interface sh interface ve türevi komutlarla görülebileceği gibi, sh run komutuyla da gözükür ve içine girilip yapılandırılabilir de. Bu interface üzerinden trafiğin LISP encapsulation’ına uğramadan hemen önceki hali akar.

PXTR (Proxy XTR) kavramı:

Yukarıda da bahsettiğimiz gibi MS/MR’dan “natively-forward” cevabı alan bir XTR o trafik için normal routing yapar. Yukarıdaki topolojide XTR’ların bir şubenin çıkış router’ı olduğunu düşünürsek, “natively-forward” cevabı alan bir XTR muhtemelen trafiği internete yönlendirecektir. Ancak bazı senaryolarda şubelerin merkez üzerinden geçerek internete çıkması istenir. Bir başka deyişle “natively-forward” cevabı alan XTR’ın, LISP encapsulation uygulayıp, o trafiği özel bir XTR’a göndermesini isteyebiliriz. Böylece XTR’lar bilmediği trafik için normal routing yapmak yerine o trafiği bizim belirlediğimiz özel bir XTR’a gönderir. İşte bu özel XTR’a PXTR denir. PXTR’lar bir anlamda LISP ağlarını non-LISP ağlara bağlamakla görevlidir.

XTR’ların PXTR kullanmasını sağlamak için tek yapmamız gereken LISP altında ip lisp use-petr <PXTR_IP_ADDR> komutunu girip PXTR’ın IP’sini belirtmek. PXTR konfigürasyonunu ise aşağıdaki örnek üzerinden inceleyebiliriz (Yukarıdaki topolojiye bir PXTR eklediğimizi düşünebiliriz):

PXTR konfigürasyonu da oldukça basit. map-cache komutuyla belirttiğimiz subnet’ler CEF’te LISP0 interface’ine attached olarak gözükür. Böylece bu subnet’lere giden trafik için LISP sorgusu tetiklenir.

Not: Bir loop prevention mekanizması olarak PXTR “natively-forward” cevabı alırsa ilgili IP’yi CEF’e drop olarak ekler. Bu sebepten ötürü bir cihaz aynı VRF için hem XTR hem de PXTR olarak çalışamaz.

Ayrıca PXTR’da LISP konfigürasyonuna ek olarak, geleneksel routing konfigürasyonu yapmayı da unutulmamalıyız. PXTR LISP ve non-LISP ağları birbirine bağladığı için, non-LISP ağlara EID uzaylarını anons etmeli, böylece non-LISP ağlardan EID uzaylarına gidecek olan trafiği üstüne çekmelidir.

“Yeni Nesil Ağ Mimarisi”:

Gelelim LISP’in neden yeni nesil ağ mimarisi olarak lanse edildiğine. Bunun sebebi LISP’in hem çok basit hem de oldukça ölçeklenebilir olması diyebiliriz. Ayrıca LISP’in yetenekleri bu yazıda bahsettiklerimle sınırlı da değil. LISP’in ölçeklenebilir kabul edilmesinin nedeni ise bir “pull model” olarak çalışıyor olması. Geleneksel routing ise “push model” olarak kabul edilir. Genel bir tanımlama yapacak olursak push model erişim bilgisine sahip router’ların kendisiyle komşuluğu bulunan tüm router’larla bu bilgiyi hemen paylaşması (itmesi) olarak tanımlanabilir. Pull model ise bir router’ın bir bilgiyi sadece ihtiyacı olduğu zaman sorgulaması (çekmesi) anlamına gelir. DNS sistemi de aslında bir pull model’a çok güzel bir örnektir (Ne kadar ölçeklenebilir olduğu da aşikar 🙂 ).

Pull modelin genellikle daha ölçeklenebilir kabul edilmesi temel olarak iki sebebe bağlanabilir: Birincisi push model’ın verimli bir şekilde çalışabilmesi için her router’ın her rotayı öğrenmesi gerekirken, bir pull model olarak LISP’te ise yukarıdaki örnekte de gördüğümüz gibi sadece bir EID’ye trafik gönderilecek olduğu zaman router’ın ilgili RLOC’u öğrenme durumu ortaya çıkar. Bu da router’lardaki yönlendirme girdilerinin daha az yer tutmasını sağlar.

İkinci sebebi de yazımın başında verdiğim örnekteki bir cihazın ağa bağlanma noktasının değişmesi durumu üzerinden açıklayayım: Kimliği aynı kalan fakat lokasyonu değişen bir cihaza optimum yönlendirmeyi sağlayabilmek için, push model yani geleneksel routing cihazın lokasyonu her değiştiğinde routing domain’ine bunu bildirecektir. Bu, yer değiştiren her bir cihaz için routing domain’ine sürekli /32 rotaların enjekte edilmesi anlamına gelecektir. Bu durum da routing algoritmalarının daha sık çalışmasına sebep olup kaynak ihtiyacını arttıracaktır. LISP’te ise yine ancak bu cihaza gidecek bir trafik varsa cihazın lokasyonu sorgulanacaktır.

Pull model’ın push model’a göre önemli bir eksiği ise başlangıç gecikmesi. Pull model’da trafik gönderilmeden önce o trafiği nereye yönlendirmesi gerektiğini bilmediği için, router öncelikle bir sorgu yapacaktır. Bu sorgu süresince trafik iletilmeyecektir. Push model’da ise her router başlangıçtan itibaren her rotayı bildiği için doğrudan trafiği iletecektir.

Bu noktada LISP’in aslında DMVPN faz 3’e oldukça benzer olduğu dikkat çekebilir. İki teknolojide de yeni bir yönlendirme alt yapısı oluşturuluyor. DMVPN’de GRE ile tünelleme yapılıyor, LISP’te ise UDP ile. DMVPN’de tunnel interface mevcut, LISP’te ise LISP interface. DMVPN’de spoke’lar bilmediği source IP’yi NHRP sunucusuna sorar, LISP’te ise XTR’lar bilmediği RLOC’u MS/MR’a sorar. Bu örnekler arttırılabilir. DMVPN’in kendini ispatlamış bir teknoloji olduğunu zaten biliyoruz. Bir karşılaştırma yapacak olduğumuzda ise LISP basitliği ile ön plana çıkıyor. DMVPN’de GRE, EIGRP (veya BGP vs.), NHRP, birden fazla VRF taşınacaksa MPLS teknolojileri kullanılırken LISP tüm bu işlevselliği basit bir şekilde bir araya getiriyor.

Sonraki yazılarda LISP’in diğer işlevselliği ve kullanım alanlarından bahsediyor olacağım.

Leave a comment

1 Comments

  1. Çok güzel olmuş. Sonraki yazını merakla bekliyoruz…

Share