OSPF apo EIGRP mbi një VTI të ASA: cilin mbështet versioni juaj

Shumica e debateve OSPF kundër EIGRP supozojnë se tuneli tashmë mund ta mbajë protokollin, dhe në një ASA pikërisht ky supozim është pjesa që ia vlen të kontrollohet e para. Krahasimi bëhet interesant vetëm pasi konfirmohen imazhi, lloji i VTI dhe rruga multicast. Nëse e gaboni këtë rend, humbisni një pasdite duke rregulluar kohëmatësit në një tunel që nuk do të formojë kurrë fqinjësi. Unë çdo projekt të tillë e nis me shënimet e versionit dhe konfigurimin në punë, jo me preferencën e protokollit.

Versioni vendos përpara protokollit

Udhëzuesi VTI i Cisco për ASA 9.24 është një bazë dokumentacioni e përdorshme: përshkruan VTI statike dhe dinamike dhe liston routing statik, BGP, OSPF dhe EIGRP. Historiku i funksioneve e vendos mbështetjen për OSPFv2 dhe EIGRP mbi VTI në 9.19(1). Çdo gjë më e vjetër është bisedë tjetër.

Pra dy pyetjet e para janë të mërzitshme dhe vendimtare:

Deklarata se një ASA nuk mund të përdorë VTI, ose nuk mund të mbajë një IGP, ishte e vërtetë për disa imazhe më të vjetra dhe nuk është matricë aktuale mbështetjeje. Po ashtu, udhëzuesi 9.24 nuk është udhëzim për të përmirësuar çdo pajisje. Ai thotë çfarë mbështet ai version, dhe versioni juaj i vendosur duhet të përgjigjet vetë.

Kalimi i unicast nuk do të thotë që IGP do të formohet

I njëjti udhëzues vëren se unicast kalon si parazgjedhje dhe se multicast duhet të aktivizohet për OSPFv2 ose EIGRP mbi VTI, me kufij të dokumentuar për grupet multicast. Ajo fjali e vetme shpjegon shumicën e fqinjësive të dështuara që kam parë në këtë projekt. Një ping që funksionon përmes tunelit, ose një status IPsec i gjelbër, provon vetëm rrugën unicast. Zbulimi i protokollit kërkon rrugën multicast, dhe të dyja konfigurohen veçmas.

Kontrolloni konfigurimin e ndërfaqes së tunelit për atë cilësim multicast përpara se të prekni kohëmatësit hello ose hold. Nëse cilësimi mungon, fqinjësia nuk është e ngadaltë, është e pamundur.

OSPF dhe EIGRP krah për krah në të njëjtin tunel

Mbi tunelin vetë dy protokollet duken si kudo tjetër. OSPF ka nevojë për një lloj rrjeti që përputhet, zonë, vërtetim dhe parametra fqinji; EIGRP ka nevojë për numrin e vet AS dhe cilësimet në nivel ndërfaqeje që shkojnë me të.

Kurthi është kopjimi i deklaratave të fqinjit nga një model tjetër tuneli. Këshillat për fqinjë statikë në një projekt pa VTI ekzistonin për të shmangur multicast, dhe ato nuk transferohen në një VTI që pritet ta mbajë protokollin në mënyrë amtare. Konfiguroni sjelljen e mbështetur të ndërfaqes, pastaj lërini protokollin të formojë vetë fqinjësinë.

Pastaj krahasoni në boshtet që vërtet ndryshojnë për topologjinë tuaj: ndërveprimi me palën tjetër, sjellja e konvergjencës që mund të provoni, dhe njohuritë operative në ekipin tuaj. Një anekdotë historike për një protokoll më të shpejtë ose më të lehtë nuk është matje e rrjetit tuaj.

Fqinjët nuk janë të barabartë me rrugët e instaluara

Pasi fqinjësia ngrihet, ndani atë që origjinohet nga ajo që pranohet. Shikoni cilat prefikse dege shpall secila palë, cilat pranohen, cilat zgjidhen dhe cilat arrijnë vërtet në tabelën e routing-ut. Shtrirja e importit, eksportit dhe rishpërndarjes duhet të jetë e qëllimshme dhe jo një shpallje gjithëpërfshirëse e gjithçkaje që pajisja di.

show ospf neighbor dhe show eigrp neighbors ju thonë se sesioni është i gjallë. show route ju thotë nëse prefiksi i degës mbërriti, dhe këto janë pyetje të ndryshme.

Rruga e aplikacionit është përsëri pyetja e tretë. Një marrëdhënie fqinjësie shpërndan arritshmërinë; ajo nuk jep leje përmes firewall-it dhe nuk provon se përzgjedhësit e trafikut dhe rregullat e filtrimit bien dakord. Verifikoni rrjedhën e lejuar dhe rrugën e përgjigjes me një test të miratuar në vend që të supozoni se rruga nënkupton politikën.

Çfarë duhet të regjistrojë krahasimi i përfunduar

Shkruani ndërfaqen e tunelit, versionin që e mbështet, shkëmbimin e kontrollit që verifikuat dhe politikën e rrugëve që kufizuat. Shtoni cilësimin multicast, sepse është detaji që vendos në heshtje nëse pjesa tjetër funksionon. Mbani atë regjistrim pranë versionit të vendosur, që një ndryshim i mëvonshëm funksioni të mund të rishikohet pa nisur nga një supozim që ka skaduar ndërkohë.

Nëse mungon ndonjë nga ata katër, keni një preferencë dhe jo një projekt. Së pari rregulloni faktin që mungon; zgjedhja e protokollit është pjesa e lehtë.