OSPF vai EIGRP pār ASA VTI: kuru atbalsta jūsu versija

Lielākā daļa OSPF pret EIGRP diskusiju pieņem, ka tunelis jau spēj pārnest protokolu, un ASA gadījumā tieši šis pieņēmums ir tā daļa, ko ir vērts pārbaudīt vispirms. Salīdzinājums kļūst interesants tikai pēc tam, kad ir apstiprināts image, VTI tips un multicast ceļš. Kļūdoties ar šo secību, jūs pavadīsiet pēcpusdienu, regulējot taimerus tunelī, kurš nekad neveidos kaimiņattiecības. Es katru šādu projektu sāku ar laidiena piezīmēm un darbojošos konfigurāciju, nevis ar protokola izvēli.

Versija izlemj pirms protokola

Cisco VTI rokasgrāmata ASA 9.24 ir izmantojama dokumentācijas bāze: tajā aprakstīti statiskie un dinamiskie VTI un uzskaitīta statiskā maršrutēšana, BGP, OSPF un EIGRP. Tās funkciju vēsturē OSPFv2 un EIGRP atbalsts VTI ir piesaistīts 9.19(1). Viss vecākais ir cita saruna.

Tātad pirmie divi jautājumi ir garlaicīgi un izšķiroši:

Apgalvojums, ka ASA nevar izmantot VTI vai nevar pārnest IGP, bija patiess dažiem vecākiem image un nav pašreizējā atbalsta matrica. Tāpat 9.24 rokasgrāmata nav norādījums jaunināt katru ierīci. Tā norāda, ko atbalsta šī versija, un jūsu izvietotajai versijai pašai par sevi jāatbild.

Unicast pāreja nenozīmē, ka IGP izveidosies

Tā pati rokasgrāmata norāda, ka unicast pāriet pēc noklusējuma un multicast ir jāieslēdz OSPFv2 vai EIGRP VTI, ar dokumentētiem multicast grupu ierobežojumiem. Šis viens teikums izskaidro lielāko daļu neizdevušos kaimiņattiecību, ko esmu redzējis šajā projektā. Strādājošs ping caur tuneli vai zaļš IPsec statuss pierāda tikai unicast ceļu. Protokola atklāšanai vajadzīgs multicast ceļš, un abi tiek konfigurēti atsevišķi.

Pārbaudiet tuneļa interfeisa konfigurācijā šo multicast iestatījumu, pirms aiztiekat hello vai hold taimerus. Ja iestatījuma nav, kaimiņattiecības nav lēnas, tās nav iespējamas.

OSPF un EIGRP līdzās vienā tunelī

Pašā tunelī abi protokoli izskatās tāpat kā citur. OSPF nepieciešams atbilstošs tīkla tips, apgabals, autentifikācija un kaimiņa parametri; EIGRP nepieciešams tā AS numurs un ar to saistītie interfeisa līmeņa iestatījumi.

Slazds ir kaimiņa paziņojumu kopēšana no cita tuneļa modeļa. Padomi par statiskiem kaimiņiem projektā bez VTI pastāvēja, lai izvairītos no multicast, un tie neattiecas uz VTI, kam protokols jāpārnes dabiski. Konfigurējiet atbalstīto interfeisa uzvedību un pēc tam ļaujiet protokolam veidot savas kaimiņattiecības.

Pēc tam salīdziniet asīs, kas jūsu topoloģijā patiešām atšķiras: savietojamība ar otru pusi, pārbaudāma konverģences uzvedība un jūsu komandas operatīvās zināšanas. Vēsturisks stāsts par to, ka viens protokols ir ātrāks vai vieglāks, nav jūsu tīkla mērījums.

Kaimiņi nav vienādi ar instalētiem maršrutiem

Kad kaimiņattiecības ir paceltas, atdaliet to, kas tiek ģenerēts, no tā, kas tiek pieņemts. Apskatiet, kādus filiāles prefiksus katra puse reklamē, kuri tiek saņemti, kuri tiek atlasīti un kuri patiešām nonāk maršrutēšanas tabulā. Importa, eksporta un pārdales apjomam jābūt apzinātam, nevis visaptverošai reklāmai par visu, ko ierīce zina.

show ospf neighbor un show eigrp neighbors paziņo, ka sesija ir dzīva. show route paziņo, vai filiāles prefikss ir ieradies, un tie ir dažādi jautājumi.

Lietojumprogrammas ceļš atkal ir trešais jautājums. Kaimiņattiecības izplata sasniedzamību; tās nedod atļauju caur ugunsmūri un nepierāda, ka trafika selektori un filtrēšanas noteikumi saskan. Pārbaudiet atļauto plūsmu un tās atbildes ceļu ar apstiprinātu testu, nevis pieņemot, ka maršruts nozīmē politiku.

Kas pabeigtajam salīdzinājumam jāreģistrē

Pierakstiet tuneļa interfeisu, to atbalstošo versiju, pārbaudīto vadības apmaiņu un ierobežoto maršruta politiku. Pievienojiet multicast iestatījumu, jo tieši šī detaļa klusi izlemj, vai pārējais darbojas. Glabājiet šo ierakstu blakus izvietotajai versijai, lai vēlāku funkcijas izmaiņu varētu izskatīt, nesākot no jauna ar pieņēmumu, kas jau ir beidzies.

Ja kāda no šīm četrām trūkst, jums ir izvēle, nevis projekts. Vispirms izlabojiet trūkstošo faktu; protokola izvēle ir vieglā daļa.