Tag: mpls

Unified veya Seamless MPLS üzerine

~ dnzydn ~ Leave a comment

Unified veya Seamless MPLS

İlk olarak aşağıdaki dökümanları okuyunuz;

draft-ietf-mpls-seamless-mpls-01

Scaling the Service Provider NGN with unified MPLS

Scaling the IP NGN with Unified MPLS

Seamless MPLS – Juniper White Paper

Scaling Mpls – Seamlessly Resilient Service Enablement At Massive Scale Using Standard Protocols

Unified MPLS veya Seamless MPLS, giderek büyüten networklerde, IGP ve MPLS noktlarının artması sonucunda oluşan gereksinimlere cevap olarak sunulan tasarımlardır. Çok ufak farklar ile birlikte genel olarak benzer tasarımlardır. Unified MPLS Cisco’nun kullandığı bir isim olmak ile beraber Seamless MPLS tasarımın genel adıdır.

Networklerin genel olarak büyümesi ve yeni servislerin yer alması ile birlikte (Carier Ethernet, Metro Ethernet, TDMoMPLS ), MPLS desteğinin core’dan uç cihazlara (access) doğru kaymıştır. Bunun sonucunda  ile birlikte network içerisinde kullanılan mpls node sayısı artmıştır. MPLS destekli access/aggeration switchler, mpls destekli DSLAM’lar, ve en önemlisi  Mobil operatörlerde yaşanan gelişmelerden dolayı MPLS node sayısında ciddi artışlar olmuştur (LTE, mobie, wireless vb konulardaki gelişmeler). Tüm bunlar bir arada düşünüldüğünde MPLS tabanlı networklerinde buna uyum sağlaması gerekmektedir. Burada istenen özellikler genel olarak ;

  • Yeni hizmet kurulumunda basitlik ve operasyon noktlarının az olması.
  • Uçdan uca MPLS kullanımı.
  • Hızlı yakınsama dolayısı ile IGP tablolarının küçük olması.
  • Yeni servislerin hızla uygulanabilir olması.
  • Hata bulma ve gidermede hızlılık ve kolaylık.

Network açısından dikkat edilmesi gerekenler ise;

  • IGP Sorunları : Hızlı yakınsama için küçük IGP tabloları. Kararlı IGP domainleri.
  • LDP Sorunları : Kullanılan etiket sayısı, MPLS tablo büyüklüğü. MPLS tabanlı servisler için kolay hizmet tanımı.

Bu noktada bilinmesi gereken bazı konular vardır.

  • Kullanıcı prefixleri veya servisler için (L3 VPN, L2 VPLS) IBGP kullanılmaktadır. BGP’nin çok sayıda route’u kararlı bir şekilde etme ve hesaplama yeteneği vardır. Çok sayıda networku OSPF veya IS-IS taşımak hem kararlılık hemde hızlı yakınsama için sorun olur.
  • OSPF veya ISIS sadece BGP Next-Hop, NH taşımak için kullanılır.
  • MPLS için etiket dağıtımı LDP kullanılarak yapılır.

Genel olarak önerilen çözüm;

Network’ü IGP domainlerine bölmektir. IGP sadece BGP NH taşınıyor olsa bile, çok fazla node’un olduğu networklerde (1000’lerce), sadece BGP NH taşımak bile IGP için sorun olmaktadır. Aynı zamanda her bir domain arasındaki prefix anonsu kısıtlanmış veya filtrelenmiştir. Her bir domain kendi içerisindehi BGP NH’ları ve diğer domainlere erişmel için kendi çıkış noktası Area Border Router, ABR bilmesi yeterlidir. Aslında kısmen OSPF stub area tasarımına benzetilebilir. Ayrıca network IBGP içinde aynı domain yapsına böünmüştür. Her domain’in ABR’ı aynı zamanda söz konusu domain’in IBGP RR görevini görmektedir. Etiket dağıtımı ise IBGP ile yapılmaktadır.

Unified MPLS :

Cisco’nun önerdiği son UMMT versiyonudur. Genel olarak bakıldığında, IGP tablolarını küçük tutmak, yönetim alanlarını belirlemek amacı ile network, core ve access domainlerine ayrılmıştır. Her domain kendi IGP’sini çalıştırmaktadır ve sadece kendi domain’i içerisindeki IBGP NH’ları ve diğer domainlere erişim için ABR’ın NH bilmesi yeterlidir (OSPF için farklı processler veya alanlar,IS-IS için level1/2 kullanımı, ABR içinde IBGP Next-Hop Self kullanımı). IGP için kullanılan OSPF/IS-IS çok daha az sayıda node ile çalışması, dolayısı ile kararlılık ve hızlı yakınsama sağlanmış olur. Zaten core’un access domain’i içerisindeki routing bilmesine gerek yoktur, aynı şekilde access domain’ninde core’un IGP yapısını. Tek bilinmesi gereken söz konusu domain’e nasıl erişeceğidir (OSPF stub area gibi).

IGP  :

  • Birden fazla mantıksal alan : Her domain için farklı OSPF process veya alan (ben farklı process tercih ediyorum, OSPF alanlarının kullanımı zaman zaman MPLS üzerinde ve route filtrelemede sorunlar yaşatıyor).
  • Her Node kendi IBGP NH adresini (genellikle loopback adresi) kendi IGP process’i içerisine anons etmelidir (IBGP komşuluğu için, IBGP genellikle loopback adresi kullanılır). ABR için ise IBGP NH adresi esas olarak core domain’e aittir.
  • ABR üzerinde filterleme : Farklı OSPF process’leri kullanılıyor ise, ABR BGP NH adresinin (genelde loopback adresi olur) içerisinde bulunduğu her iki domain’de de (access + core) biliniyor olması gerekir. Bunun için core domain üzerinde çalışan process’i diğerine redistribute etmek gerekir (loopback interface’in core process içerisinde olduğu kabul ediliyor). Bunun tersi bir method kullanımı tehlikeli olabilir, zira access domain üzerindeki process core process redistribute edilmesi gerekir ve bir hata durumunda tüm core bundan etkilenecekdir. Bu redistribution sadece ABR’ın loopback adresini kapsıyacak şekilde yapılası gerekir (route-map+prefix filter vb kullanımı ile). Böylece IGP her domain için sadece o domain’in iç routelarını taşıyacak şekilde düzenlenmiş olur. Her domain kendi yakınsamasından sorumlu olur, diğer domainlerdeki IGP uptadeleri (link up/down/prefix up/down vb) kendi içerisinde kalmış olur (ABR ile ilgili olanlarlar hariç).

IBGP :

  • IBGP için full-mesh bir yapı kurulması gerekir. Bunu basitleştirmek için her ABR aynı zamanda, kendi access domain’inin RR olarak kullanılır. Core içerisinde istenirse ABR’lar arası full-mesh IBGP komşuluğu veya Core için’de bir RR kullanımı seçilebilir. Her adress ailesi için (IPv4,VPN4,VPN6 vb) RR performansını artırmak, service yedekliliği sağlamak amacı ile farklı RR’lar kullanılabilir. Core için kullanılacak RR için özellikle yedeklilik ve bu konular önemlidir. BGP looplarına önlemek için cluster-id kullanımıda unutulmalıdır.
  • IBGP NH adreslerinin IBGP içerisinde diğer domain’lere anons edilmesi gerekir. Bunun için IBGP NH adresleri IBGP içerisine etiketleri ile birlikte redistribute edilir. Bu redistribute işlemi her PE tarafından kendi IBGP NH adresini redistribute edecek şekilde yapılabilir. Fakat tercih edilen yöntem bu işlemin ABR tarafından yapılmasıdır. Böylece PE kurulumuda daha basit hale getirilmiş olur. Bu redistribute işlemi sırasında, her PE IBGP NH için hangi etiketin kullanılacağıda diğer domain’lere ABR’lara bildirilmedilir. Bunun için redistribution sırasında MPLS etiketlemeside yapılmalıdır. Hem etiketleme hemde redistribute ve etiketleme işleminin kontrol bir biçimde route-map+prefix-list’ler kullanılarak yapılması önerilir.
  • ABR’lar diğer ABR’lardan IBGP aldıkları routeların IBGP NH’larını kendi IBGP NH adresleri ile değiştiriler. Bunun nedeni, diğer domainlerin IBGP NH sadece kendi içlerinde IGP ile taşınıyor olması. Bir access domain’in IGP’si diğer domainlerdeki PE’lerin IBGP NH’larını bilemez dolayısı ile her ne kadar IBGP ile öğrenmiş olsa bile MPLS ile diğer domain’lerin IBGP NH’ları için etiket ataması yapamaz (Inter-AS MPLS VPN’de benzer sorun ve çözüm vardır, option 10B/C).

Bu şekilde MPLS tabanlı servislerde uçdan uca MPLS LSP kurulumda yapılabilir olur.

Tüm bunlara bakıldığında konfigurasyonun çoğunlu ABR’lar üzerinde yapılmaktadır. Buda PE nodeların kurulumunu oldukça kolaylaştırmaktadır. Dolayısı redistribution/filtreleme gibi işlemlerde ABR tabanlı methodlar tercih edilmesi PE kurulumunu standart hale getirir.

Seamless MPLS ise ek olarak MPLS en uç noktaya taşır,Access Domain via LDP DOD. Örnek olarak DSLAM bir servisi kurmak için PE’den NH için bir etiket ister, PE söz konusu NH için etiket bilgisini DSLAM’a iletir (aynı domainde veya farklı bir domainde). Bu şekilde en uç erişim noktası bir nevi Light MPLS kullanarak, IGP veya IBGP dahil olmadan, uçdan uca MPLS LSP kurabilir.

Not : Segment routing kullanımıda ayrıca bir alternatif olabilir.

label allocation modes

~ dnzydn ~ Leave a comment

Label allocation is one of the main topics of MPLS VPN. There are 3 major label allocation mode.

  • per-vrf : All local, redistributed, aggregated e.t.c prefixes into bgp will have the same label which cause PE to make a second lookup to find the next hop. If you need a feature based on IP header on the egress interface to the CE you should use this mode although you may loose a lot of feature like per prefix counters, CSC.
  • per-prefix : Each remote learned routes will have a different label and all local prefixes will have the same local aggregate label which causes PE to have second lookup to find next hop of the packet. This will effect the resources of the PE as the number of prefixes per vrf increases.
  • per-ce/per-nexthop : This is like per-vrf but a little bit different. If you have configured a single vrf for a multi access network inteface like ethernet and have EBGP sessions for different CPE’s under this interface, you can not use a single label for that vrf. A second lookup required on the PE to find the CPE. You may use per-prefix which will cause a lot of labels to be used. per-ce / per-nexthop helps to solve these problems. PE should assign the same label for the prefixes coming from the same layer 2 next-hop, same EBGP session. This will dramatically effect the PE performance with avoiding a second lookup.

Cisco and Juniper approach is a little bit different for per-vrf. Default value for Cisco is per-prefix and Juniper is per-next hop. Vendors may have different implementations for each mode like using different label or mode for different address families.

Some external links :