EVPN běží, ale služba ne: čtyři kontrolní body

Dosažení vzdálené adresy VTEP dokazuje, že podkladová síť přenáší pakety, a to je vše, co dokazuje. Služba nájemce potřebuje relaci BGP EVPN se správnou adresní rodinou, místní VNI připojený a funkční, vzniklou trasu a import na vzdáleném konci. To jsou čtyři samostatné kontrolní body, každý s jinou opravou. Považovat zelenou podkladovou síť za připravenost služby je nejčastější způsob, jak se zprovoznění EVPN zasekne.

Čtěte je v pořadí a zastavte se u prvního, který neodpovídá tomu, co návrh očekává. Pozdější kontrolní body nemohou nahradit dřívější selhání.

Kontrolní bod 1: přenos k VTEP

Začněte dosažitelností mezi adresami loopback používanými jako zdroje VTEP. Trasa musí existovat v podkladové síti, cesta musí být povolena včetně případného požadavku na zapouzdření a zpětná cesta musí fungovat. Trasa, která existuje, ale je filtrována v jednom směru, vytváří asymetrické selhání, které vypadá přerušovaně. Před pokračováním potvrďte oba směry.

Zapište zdrojovou a cílovou adresu, které jste zkontrolovali. Pozdější krok, který řeší další skok přes jinou adresu, je jiný test, a jejich zaměňování je způsob, jak se vyřešený další skok obviňuje z poruchy přenosu.

Kontrolní bod 2: rodina EVPN, ne počet relací

Navázaná relace BGP neznamená, že byla vyjednána adresní rodina EVPN. Podívejte se na stav specifický pro rodinu u souseda: zda je rodina povolena, zda byla vyjednána s protějškem a zda ji relace vůbec nese. Relace, která je aktivní pro IPv4 unicast a nikdy nevyjednala EVPN, neukazuje v obecném přehledu sousedů nic špatného, a specifikace překryvu EVPN považuje postupy služby a řízení za záležitosti oddělené od přenosu.

Zkontrolujte také zdrojovou adresu relace. Peering postavený na adrese, která není zdrojem VTEP, je nesoulad v návrhu, který čeká, až vysvětlí poruchu předávání.

Kontrolní bod 3: místní služba je připojena

Místní VNI musí být připojen k mostu nebo VRF, který představuje nájemce, a platforma jej musí hlásit jako funkční. Stav členství, který používá model replikace, může být důležitý dříve, než se naučí jakákoli MAC hostitele, takže prázdná tabulka koncových bodů není důkazem, že služba nefunguje.

Poté potvrďte, co zařízení skutečně vytváří: místní trasu pro daný VNI s route targety, které návrh určuje. VNI, který je připojen, ale není inzerován, vytváří službu, která existuje lokálně a nikde jinde.

Kontrolní bod 4: import u příjemce

Na přijímajícím zařízení porovnávejte exportované a importované route targety, nikoli číselné VNI. Shodné číslo VNI nedokazuje, že přijímající instance importuje inzerci, a neshodný route target je v seznamu VNI neviditelný. Vyřešte inzerovaný další skok přes podkladovou síť, než uvěříte záznamu předávání. Poté čtěte stav předávání v překryvu pro službu, nikoli pro zařízení jako celek.

Tabulka protějšíků může také odrážet dataplán nebo učení členství specifické pro implementaci. Čtěte její původ a kontext služby spolu s trasou EVPN, místo abyste počet řádků považovali za důkaz.

Jeden záznam, který projde cestu

Veďte jeden záznam na službu: místní stav VNI, souseda EVPN a rodinu, vzniklou trasu a přijatý a importovaný výsledek. Projděte tento záznam od vzniku k instalaci. Když něco selže, záznam říká, který ze čtyř kontrolních bodů opravit, a ne který příkaz zkusit.

Připojujte časová razítka, když to děláte. Import, který se objeví minuty po inzerci, je otázkou politiky nebo konvergence, zatímco ten, který se neobjeví nikdy, je otázkou konfigurace, a tento rozdíl je vidět jen tehdy, když jste si zapsali, kdy jste se dívali.

Kdy je statický VXLAN správnou odpovědí

Staticky nakonfigurovaná datová cesta VXLAN může fungovat s ručně zadanými protějšky, zatímco tabulka EVPN zůstává prázdná. To není rozbité nasazení EVPN, je to jiný model řízení. Rozhodněte, který návrh zamýšlí, než prázdnou tabulku diagnostikujete jako závadu.

Soused IGP v podkladové síti poskytuje přenos a nic víc. Stav služby v překryvu je samostatná věc k vybudování a samostatná věc k ověření.