Cymydog EIGRP neu drawsnewid DMVPN? Gwiriwch y rôl gyntaf

Mae’r cyfosod ar goll, ac mae’r llwybrydd yn y canol yn edrych fel y sawl sydd dan amheuaeth amlwg. Efallai ei fod yn ddieuog. Mae anfon pecynnau allanol y tiwnel a chymryd rhan yn y protocol llwybro overlay yn ddau dasg wahanol, a gall dyfais wneud y cyntaf heb wneud yr ail. Ewch drwy’r pum gwiriad isod yn eu trefn a stopiwch wrth y cyntaf sy’n methu.

Cam 1: tynnwch y ddwy rôl

Tynnwch y cyfosod EIGRP arfaethedig fel cysylltiad rhesymegol rhwng dau lwybrydd, yna tynnwch y llwybryddion underlay sy’n cario ei becynnau tiwnel. Nid oes rhaid i’r un ddyfais ymddangos yn y ddwy restr, a drysu’r rhestrau yw’r rheswm mwyaf cyffredin pam y cyhuddir llwybrydd trawsnewid iach o dorri’r cyfosod.

Mae llwybrydd trawsnewid yn anfon y pecynnau allanol gan ddefnyddio ei lwybro IP a’i bolisi arferol. Nid oes angen iddo redeg y protocol a gludir y tu mewn i’r tiwnel gwarchodedig, ac nid oes angen proses EIGRP arno i basio’r pecynnau hynny ymlaen.

Cam 2: gwiriwch beth mae’r ddyfais ganol yn ei derfynu

Os yw’r llwybrydd canol yn terfynu’r tiwnel ac i fod i ffurfio cyfosodiadau EIGRP â spoke, mae’r ateb yn newid yn llwyr. Mae angen yr ymddygiad llwybro overlay a gefnogir ar y ddyfais honno, ac nid yw galw hynny’n drawsnewid yn dileu’r gofyniad cymydog. Darllenwch gyfluniad y tiwnel cyn cyfluniad y llwybro. Mae’r ateb hwnnw’n penderfynu pob gwiriad sy’n dilyn.

Felly nid y cwestiwn gwirioneddol gyntaf yw pa brotocol i’w diwnio. Y cwestiwn yw ai hub, spoke, naid underlay bur, neu wasanaeth Layer 2 sy’n cario fframiau rhwng penau yw’r blwch.

Cam 3: gwiriwch awyren reoli’r cymydog

Ar bob dyfais y dylai fod yn gymydog, cadarnhewch bedair peth: enghraifft EIGRP a rhif y system ymreolaethol, y paramedrau dilysu, y rhyngwyneb sy’n cymryd rhan yn y broses, a’r datganiad rhwydwaith sy’n cynnwys y rhyngwyneb hwnnw. Mae anghysondeb yn unrhyw un ohonynt yn cadw’r cyfosod i lawr tra bod y rhyngwyneb yn aros i fyny a’r ping yn dal i weithio.

Mae RFC 7868 yn disgrifio EIGRP fel protocol IP gyda chyfnewid rheoli multicast, a dyna pam nad yw perthynas cymydog yn rhywbeth y gall llwybrydd canolradd ei ddirprwyo drwy lwybro pecynnau tuag at gyrchfan. Naill ai mae’r cyfnewid rheoli yn cyrraedd y partner neu nid yw’r cyfosod yn ffurfio.

Cam 4: gwiriwch fod y cludiant yn danfon y cyfnewid rheoli

Nesaf, gwiriwch fod yr overlay yn cario’r traffig rheoli rhwng y penau bwriadedig. Archwiliwch fapio NHRP ar gyfer y partner a’r llwybr allanol sy’n ei gyrraedd, yna cadarnhewch fod y rhyngwyneb tiwnel i fyny ac yn pasio traffig. Mae ping underlay llwyddiannus yn profi bod y llwybr allanol yn bodoli; nid yw’n profi bod cyfnewid rheoli’r overlay wedi’i ddanfon.

Mae gwasanaeth Layer 2 tryloyw, tiwnel pwynt-i-bwynt a chwmwl DMVPN amlbwynt yn danfon multicast yn wahanol. Dilynwch y model rhyngwyneb, NHRP a multicast a gefnogir ar gyfer yr hyn sydd wedi’i ddefnyddio mewn gwirionedd yn hytrach na chymryd yn ganiataol fod y tri yn ymddwyn yr un fath.

Cam 5: ailgynlluniwch y ffin os na all gymryd rhan

Os na all dyfais overlay ofynnol redeg y protocol, newidiwch y dyluniad yn benodol. Defnyddiwch brotocol neu fodel cyfnewid a gefnogir ar y ffin honno, neu drefnwch diwnel pen-i-ben addas fel bod y cymdogion yn y penau sy’n siarad â’i gilydd mewn gwirionedd. Peidiwch â chymryd yn ganiataol bod llwybr statig yn troi anghyfranogwr yn rasglwr ar gyfer pob pecyn rheoli.

Cofnodwch rôl pob dyfais yn y diagram a’i chadw gyda’r cyfluniad. Mae RFC 7868 yn diffinio’r cyfnewid protocol, a’r diffiniad hwnnw yw’r cyfeiriad at ba reswm na ellir efelychu’r berthynas cymydog drwy lwybro trawsnewid.

Pan fydd y cyfosod yn dal i fethu ar ôl y pum gwiriad, yr amheuwyr sy’n weddill yw nodweddion platfform fel trin multicast ar y rhyngwyneb tiwnel a pholisi sy’n hidlo protocol 88. Achosion penodol y gellir eu profi yw’r rhain, ac maent yn werth mwy na rownd arall o feio’r llwybrydd yn y canol.