Bir site içinde aynı iESI, siteler arasında benzersiz: Junos dikişi

İki ağ geçidi çifti iki veri merkezine hizmet eder ve birinin tasarımın kaç interconnect ESI değerine ihtiyaç duyduğuna karar vermesi gerekir. Cevap her ağ geçidi grubu için birdir, fabric başına bir değil ve ağ geçidi başına bir değil. Bunu yanlış yapmak, yapılandırılmış görünen ama yanlış forwarder seçen bir fabric üretir ya da ayrı kalması gereken iki siteyi birleştirir. Kural ve istisnaları ağ geçidi listesinin yanına yazılmaya değer.

İki kapsam, iki kural

Site içinde, yedek interconnect ağ geçitleri tek bir multihomed uç nokta olarak davranır, bu yüzden tek bir interconnect ESI paylaşırlar. Peer'ları iki bağımsız üye yerine tek bir mantıksal üye görmelidir. Paylaşılan değerin bütün amacı budur.

Siteler arasında her ağ geçidi grubu kendi değerini alır. Aynı tanımlayıcıyı paylaşan iki veri merkezi kontrol düzleminde tek bir multihomed grup olur; bu genellikle WAN üzerinden dikiş tasarımının amaçladığı şey değildir. Tek gruptaki iki site birbirinin arıza modlarını da devralır.

Site içinde: grup için tek kimlik

Çifte iki peer'da aynı değeri, aynı hizmet bağlamında verin ve bunu sohbet dizisinde değil ağın tanımlayıcı envanterinde kaydedin. İki üye arasındaki uyumsuzluk, tek üyeli bir grup ve belirgin bir alarm olmayan arıza modudur. Çalışan bir oturuma inanmadan önce iki üyeyi karşılaştırın.

Desteklenen model all-active'tir. Aynı referans bu dikiş kimliği için single-active çalışmayı, otomatik türetilen LACP tanımlayıcılarını ve source-bmac seçeneklerini dışlar, bu yüzden bunlardan birini varsayan bir tasarım tanımlayıcı seçilmeden önce gözden geçirilmelidir. Bu kısıt bir tasarım girdisidir, dipnot değildir.

Siteler arasında: farklı değerler veya bilinçli bir birleştirme

Site başına benzersiz değer iki ağ geçidi grubunu ayrı tutar. Amaç gerçekten bir multihomed grubu siteler arasında genişletmekse, bu kendi gecikme, arıza ve yönlendirme sonuçları olan başka bir mimaridir ve tanımlayıcı seçimi olarak değil mimari olarak kararlaştırılmalıdır. Bu kararı bakım penceresinden önce yazılı olarak isteyin.

Amaçlanan farkı plana yazın, böylece çalışan bir site şablonunu kopyalayan sonraki mühendis onun tanımlayıcısını da birlikte içe aktarmaz.

Peer ifadesi kimliğin bir parçasıdır

Gruptaki her ağ geçidi yerel peer'larını loopback adresine göre listeler ve bu ilişki tek bir MAC-VRF içinde değil, küresel EVPN düzeyinde yaşar. Bunu yanlış hiyerarşiye koymak, commit olan ama grubu asla oluşturmayan bir yapılandırma üretmenin yaygın bir yoludur. Referans hiyerarşisini bir kez okuyun, sonra ona bağlı kalın.

İfadenin adı da yer değiştirdi. Juniper, interconnect peer-gateways ifadesini 24.2R1'de yeniden adlandırdı ve 24.4R1'de veri merkezi interconnect için interconnect'e özgü biçimi geri getirdi. Bu nedenle ara sürümden alınan bir snippet, dağıtılan sürümün kabul etmediği bir ad kullanabilir ya da tam tersi. Snippet'in hangi sürümden geldiğini snippet'in yanına kaydedin.

Bir iESI'yi paylaşmanın yapmadığı şeyler

Sizin için route target'ları, VNI'ları veya yerel EVPN örneğini tanımlamaz. Bunlar iki tarafta da uyuşması gereken ayrı yapılandırma olarak kalır ve eşleşen ama route target'ı eşleşmeyen bir tanımlayıcı, oluşan ve hiçbir şey taşımayan bir grup üretir. Bu ayarların iki tarafını da aynı geçişte karşılaştırın.

Peer'lara ulaşılabilirliği veya designated forwarder seçimini de kanıtlamaz. Normal durumda unicast ile gerekli broadcast ve multicast davranışını test edin, sonra bir ağ geçidini kaldırarak yineleyin; böylece geriye kalan üye grubu tek başına taşısın.

Grubun gerçek olduğunu kanıtlayan tam da o ikinci çalıştırmadır.

Gözlenen üyeliği ve hizmet bağlamını test sonuçlarıyla birlikte saklayın. Daha sonraki bir tanımlayıcı değişikliği o zaman bir dizenin kozmetik düzenlemesi olarak değil, gerçekte olduğu gibi multihoming değişikliği olarak incelenebilir. Sonuçlar, tanımlayıcının çizimin söylediğini yaptığının tek kanıtıdır.