İki müşteri için aynı /24? VPNv4 bir RD ve etiket ister
İki kiracı aynı /24'ü yalnızca RD her rotaya kendi kimliğini verdiği için duyurabilir. Etiket başka bir soruyu yanıtlar: nasıl iletileceğini.
İki kiracı şubelerini aynı 10.50.0.0/24 ile numaralandırıyor ve bir değişiklikten sonra birinin rotası sağlayıcı kenarından kaybolurken diğeri çalışmaya devam ediyor. Bu biletin arkasındaki basitleştirme genellikle „etiket zaten müşteriyi tanımlıyor“ gerekçesiyle rota ayırt edicisini (RD) bırakmaktır. Bırakmaz. RD ve etiket iki farklı soruyu yanıtlar ve bu boşluk ancak çakışan adresler bunu zorladığında görünür hale gelir.
İki olması gereken yerde tek rota
Sıradan IPv4 unicast aynı öneke giden iki yolu karşılaştırır ve daha iyisini kurar. A kiracısından 10.50.0.0/24 ve B kiracısından 10.50.0.0/24 tek bir anahtardır, bu yüzden biri kazanır ve diğeri yalnızca yedek yol olarak yaşar. Protokol kendisine söyleneni yaptı; kontrol düzleminden iki farklı rotayı tek bir tanımlayıcı altında saklaması istendi.
Sonuç bir hata gibi değil, kayıp bir rota gibi görünür: yarışmayı kaybeden PE kendi kiracısını yerel olarak iletmeye devam eder, bu yüzden saha içi denetim başarılı olur ve sahalar arası test başarısız olur. Herhangi bir politikaya dokunmadan önce VPNv4 tablosunda o önekin girdilerini sayın.
RD tek anahtarı ikiye çevirir
Sekiz baytlık rota ayırt edicisi IPv4 önekinin önüne eklenir ve BGP'nin taşıdığı nesne IPv4 öneki yerine VPN-IPv4 adresi olur. İki kiracı aynı 32 biti tutabilir çünkü öndeki 64 bit farklıdır. AS tabanlı RD ve adres tabanlı RD için biçim türleri vardır ve seçim kaynak PE'ye aittir. PE'ler aynı AS'yi paylaştığında AS tabanlı RD yaygındır, paylaşmadığında adres tabanlı olan.
RD'yi üyelik etiketi olarak okumayın. Rota hedefleri içe ve dışa aktarmayı yönetir ve hangi VRF'lerin rotayı kurabileceğine karar verir; RD yalnızca rotanın kendi kimliği olduğunu garanti eder. Her VRF'ye kendi RD'sini vermek yaygın bir uygulamadır çünkü bu eşlemeyi rota görüntüleyicide okunur tutar.
Etiket yerel bir iletim talimatıdır
Her duyuru ayrıca bir MPLS etiketi taşır ve anlamı onu tahsis eden yönlendiriciyle sınırlıdır. Başka bir PE ilgisiz bir hedef için aynı numarayı verebilir. Etiketin müşteri kimliğinin yerini alamamasının nedeni tam da budur: numara yalnızca sonraki atlama ve onu kuran iletim durumunun yanında doğrudur.
Tahsisin ayrıntı düzeyi uygulamaya ve tasarıma göre değişir: bazı platformlar VRF başına bir etiket atar, diğerleri önek başına, ve etiket müşteri yerine bir iletim eylemini tanımlayabilir. Aynı hedefe ulaşan iki farklı etiket çelişki değildir ve iki PE'de aynı etiket numarası da değildir.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Biri diğerinin yerini neden alamaz
Bir duyuruyu okumak dört şeye birlikte bakmak demektir: RD ile nitelenmiş önek, rota hedefleri, sonraki atlama ve etiket. Bir kullanıcı paketini okumak, o bilgilerden kurulan yığına bakmak demektir. Sağlıklı bir tasarım iki tarafın örtüştüğünü gösterir, bozuk olanda ise genellikle bir taraf doğru, diğeri eskimiştir. Bu karşılaştırma kimlik sorununu iletim sorunundan ayırır.
Kontrol düzlemi ile veri düzlemi arasındaki düzenli karşıtlık bir öğretim aracıdır, kodlamanın tanımı değildir. RFC 8277 etiketi etiketlenmiş NLRI'nin içine yerleştirir, böylece duyurunun kendisi bağı taşır; onu iletim için kullanmak sonraki, ayrı adımdır.
Bir kiracı rotası kaybolduğunda şu sırayla denetleyin: önek için iki VPNv4 girdisi, her birinde doğru rota hedefi, çözülebilir bir sonraki atlama ve alıcı PE'nin durum sahibi olduğu bir etiket. Kimliği bir iletim değeriyle düzeltmek veya tersi, bir denetimi geçer ve sonrakinde başarısız olur.