EIGRP komşuları DMVPN kaplamasında ayağa kalkmıyor

Kaplama üzerinden unicast çalışıyor ve komşuluk yine de kurulmuyor; bu yüzden NHRP multicast çoğaltmasını, tünelin EIGRP politikasını ve IPsec’i üç ayrı katman olarak denetleyin.

Tünel ayakta, bir spoke diğerine ping atabiliyor ve EIGRP hâlâ hub üzerinde hiç komşu göstermiyor. Bu bileşim gizemli değil, normal: ping NHRP üzerinden unicast erişilebilirliği kanıtlar, EIGRP hello’ları ise multicast’tir. DMVPN kaplamasında yönlendirme protokolünün teslim modeli ikinci bir yapılandırma yüzeyidir ve insanların atladığı tam da bu yüzeydir, çünkü ilk yüzey zaten sağlıklı görünür. Aşağıdaki her katman kendi komutuyla denetlenir, dolayısıyla bir katmandaki arıza sizi listenin başına geri göndermez.

Beklediğiniz komşulukları yazın

Herhangi bir show komutundan önce kısa bir liste yapın: hangi spoke hangi hub ile, hangi tünel arayüzü üzerinden ve hangi EIGRP özerk sisteminde eşleşmeli. Çok hub’lı tasarımlar hub’lar arasındaki boşluklarda çöker, ve bir liste «EIGRP bozuk» ifadesini «spoke 3, hub 2’ye kaydolmuyor» ifadesine dönüştürür. Her bağlantıda beklediğiniz tünel alt ağlarını da ekleyin, çünkü iki uç arasındaki adres uyuşmazlığı tam olarak bir protokol arızası gibi görünür. Listeyi kayda yazın, böylece bir sonraki vardiya son ekran görüntüsüyle değil tasarımla karşılaştırır.

Önce NHRP’yi, sonra multicast yolunu denetleyin

Kayıt durumu ve hub’ın gerçekten tuttuğu eşlemelerle başlayın. Hub üzerinde dinamik girdisi olmayan bir spoke kaydolmamıştır ve hiçbir yönlendirme protokolü bunu düzeltmez. Ardından spoke’un multicast’i hub’ın NBMA adresinden kabul ettiğini doğrulayın; bu, NHS girdisinden ayrı bir satırdır.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

Tam da ip nhrp map multicast satırı, spoke’un hello’larını kaplama üzerinden çoğaltılmış multicast olarak hub’a göndermesini ve hub’ın multicast’inin kayıtlı spoke’lara ulaşmasını sağlar. O olmadan NHRP üzerinden unicast çalışır, multicast çalışmaz ve ping’i kanıt gibi gösteren tam olarak bu ayrımdır. Cisco’nun IOS XE DMVPN kılavuzu her faz için hub ve spoke multicast davranışını belgeler; bu yüzden yapılandırmanızı başka bir topolojiden parça kopyalamak yerine gerçekten devreye aldığınız faza uyarlayın.

EIGRP’nin kendi arayüz politikasını denetleyin

EIGRP sürecinde olmayan veya passive olan bir tünel, kaplama ne kadar sağlıklı olursa olsun asla komşuluk kurmaz. Arayüzün katılımını ve komşu tablosunu birlikte okuyun, çünkü birincisi ikincisini açıklar.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

Kimlik doğrulama ve metrik ağırlıkları iki uçta da eşleşmelidir. Yanlış moddaki bir anahtar zinciri veya K değerindeki uyuşmazlık, alıcıda belirgin bir syslog satırı olmadan hello’ları düşürür. Tasarım açıkça yapılandırılmış unicast komşular kullanıyorsa, bir şey ayağa kalkana kadar multicast ayarlarının üstüne yığmak yerine o modeli tamamen izleyin.

GRE taşımasını ve IPsec korumasını ayrı tutun

DMVPN multicast’i GRE içinde taşır ve IPsec iç multicast’i değil GRE paketlerini korur. Bu yüzden «IPsec multicast taşıyamaz» genel iddiası bu tasarım için yanlıştır ve tanı olarak işe yaramaz. Tüneldeki IPsec profilini, her peer için güvenlik ilişkilerini ve tünel arayüzünün durumunu üç ayrı olgu olarak denetleyin.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

EIGRP aşağıdayken sayaçları ilerleyen ve ayakta olan bir SA, soruşturmanızı yığının yukarısına geri taşır: paketler korunuyor ve teslim ediliyor, demek ki sorun protokolün hangi paketleri göndermeyi seçtiğidir.

Yalnızca komşu sayısını değil rotaları doğrulayın

Komşuluk kurulduktan sonra ne duyurduğunu ve ne kurduğunu okuyun. Çok noktalı bir tünelde split horizon ve next-hop davranışı, bir spoke’un hub üzerinden başka bir spoke’a ulaşıp ulaşamayacağını belirler ve özetleme, komşuluk ilişkisi kusursuz olsa bile bir öneki gizleyebilir.

İki site arasında izin verilen bir uygulamayla bitirin ve izlediği yolu doğrulayın. Doğrudan spoke’tan spoke’a kısayollar kendi NHRP ve güvenlik durumuyla bir yönlendirme gereksinimidir ve komşu sayısı daha iyi görünsün diye eklemek genellikle ikinci bir sorun yaratır.

Fazlı tasarımı, multicast eşlemesini ve EIGRP politikasını tek bir yerde kaydedin. Bir sonraki mühendisin tasarıma ihtiyacı olacak, döküme değil.

İlgili makaleler