PIM-SM dros VPN: gwirio BSR, mapio RP a llwybrau RPF

Mae'r twnnel i fyny, mae pingau unicast yn ei groesi, ac mae'r derbynnydd yn dal i ddangos sgrin ddu. Mewn gosodiad PIM-SM mae'r symptom hwnnw bron bob amser yn golygu bod un o bedwar llwybr rheoli wedi torri, ac nad y llwybr data oedd y broblem erioed. Ewch drwy'r rhestr isod yn ei thro ac arhoswch ar y cam cyntaf sy'n methu, oherwydd mae pob cam diweddarach yn dibynnu ar yr un o'i flaen. Rwy'n cadw'r pum prawf hyn mewn ffeil fraslun ac yn eu gludo i derfynell pan ddaw cwyn multicast i mewn, sy'n cadw'r diagnosis rhag troi'n ddyfalu.

Dechreuwch gyda'r derbynnydd, nid y twnnel

Nid yw derbynnydd na ofynnodd am y grŵp erioed yn cynhyrchu unrhyw gyflwr ar unrhyw lwybrydd, felly cadarnhewch fod yr ymuniad yn bodoli ar y segment sy'n wynebu'r derbynnydd cyn i chi archwilio unrhyw beth arall. Ar lwyfannau tebyg i Cisco, mae show ip igmp groups ar y llwybrydd hop olaf yn argraffu'r grwpiau a ymunwyd wrth ymyl y rhyngwyneb a'u clywodd. Pan fo'r grŵp ar goll o'r allbwn hwnnw, mae'r twnnel yn tynnu sylw: bu farw'r cais yn y switsh mynediad, yn soced y gwesteiwr, neu mewn VLAN heb ymholydd.

Mae dau achos cyffredin yn cyfrif am y rhan fwyaf o'r ymuniadau sy'n eisiau a welais: anghysondeb fersiwn IGMP rhwng gwesteiwr a llwybrydd, ac etholiad ymholydd a laniodd ar switsh nad yw'n llwybro. Mae'r trydydd yn fwy cynnil: mae'r grŵp wedi ymuno ond ar y VLAN anghywir, oherwydd bod gan y gwesteiwr ddwy gerdyn rhwydwaith a bod y rhaglen wedi rhwymo i'r un anghywir. Mae gan dderbynyddion IPv6 yr un broblem gyda MLD, lle mae show ipv6 mld groups yn ateb yr un cwestiwn. Nid oes unrhyw un o'r rhain yn cael ei drwsio drwy gyffwrdd â'r twnnel, ac yn union dyna pam mae'r drefn yn bwysig.

Unwaith y mae'r ymuniad yn weladwy, cadarnhewch fod PIM wedi'i alluogi ar y rhyngwyneb sy'n wynebu'r derbynnydd ac ar y rhyngwyneb sy'n arwain tua'r man cwrdd. Bydd llwybrydd ag aelodaeth IGMP ond heb PIM ar ei ryngwyneb uwch yn dal y grŵp mewn tabl lleol ac yn anfon dim byd i unman.

A yw'r set BSR yn cyrraedd yr ochr bell?

Mae negeseuon Bootstrap Router yn symud hop wrth hop o fewn un parth PIM, a dyna'r cyfeiriad sy'n torri ar draws twnnel. Mae RPau ymgeisiol yn anfon eu hysbysebion i'r BSR etholedig drwy unicast, felly mae'r rhan RP-i-BSR fel arfer yn goroesi twnnel gweithredol heb newid. Mae llifogydd negeseuon Bootstrap yn y cyfeiriad arall yn dibynnu ar fod PIM wedi'i alluogi ar bob rhyngwyneb canolradd, ac ar i ddim atal y negeseuon ar ffin. Mae RFC 5059 yn diffinio'r dosbarthiad hwnnw a'r ffiniau cwmpas gweinyddol y caniateir eu torri'n fyr.

Bydd datganiad ip pim bsr-border, ACL sy'n hidlo protocol 103, neu dwnnel IPsec seiliedig ar bolisi na all gario multicast, pob un yn torri'r llifogydd tra'n gadael unicast yn gyfan. Y cyfuniad hwnnw sy'n gwneud i'r methiant edrych fel problem RP pan fo'n broblem gyrraedd mewn gwirionedd, a dyna pam rwy'n darllen cyflwr BSR cyn darllen cyfluniad RP.

Ar y llwybrydd ochr bell, mae show ip pim bsr-router yn enwi'r BSR etholedig a'r set RP a ddysgodd; os yw'r allbwn yn wag, mae'r ochr bell yn ei pharth ei hun ac ni fydd unrhyw faint o ffurfweddu RP yn cymodi'r ddau. Cymharwch yr ystodau grŵp a'r cyfeiriadau RP yn show ip pim rp mapping ar ddwy ochr y twnnel. Mae mapio sy'n bodoli'n lleol yn unig yn cynhyrchu coeden a rennir sy'n gorffen yn y lle anghywir, ac mae'r derbynnydd yn aros am byth.

Cydweddwch y mapio RP ar ddwy ochr y twnnel

Mae RP statig, BSR ac anycast-RP yn dair ffordd o ateb yr un cwestiwn, ac mae eu cymysgu ar draws twnnel yn ffordd ddibynadwy o adeiladu parth nad yw byth yn cydgyfeirio. Os yw'r pen uchaf yn defnyddio BSR a'r gangen yn defnyddio ip pim rp-address statig sy'n pwyntio at gyfeiriad gwahanol, mae'r gangen yn adeiladu ei choeden a rennir tuag at RP nad oes ganddo syniad bod y derbynnydd yn bodoli. Rhaid i'r mapio gytuno ar yr ystod grŵp yn ogystal ag ar y cyfeiriad, gan fod ystod mwy penodol yn ennill dros un ehangach.

Mae anycast-RP yn bodoli'n union er mwyn i ddau safle rannu un cyfeiriad RP, ac mae'n werth ei enwi yma oherwydd mae'n newid beth mae «yr un RP» yn ei olygu. Mae dau RP yn hysbysebu un cyfeiriad yn gyson yn ôl y cynllun; nid yw dau RP yn hysbysebu cyfeiriadau gwahanol ar gyfer yr un ystod felly, waeth pa mor iach y mae pob safle yn edrych ar ei ben ei hun.

Ar gyfer multicast a bennir gan y ffynhonnell o fewn 232.0.0.0/8, ni ymgynghorir â'r RP byth, felly nid yw mapio RP gwag yn nam awtomatig. Penderfynwch pa fodel gwasanaeth y mae'r rhaglen yn ei ddefnyddio cyn mynd ar drywydd RP na fu ei angen erioed.

Darllenwch yr edrychiad RPF tuag at y ffynhonnell

Mae PIM yn adeiladu coeden drwy wrthdroi'r llwybr unicast, felly'r gwiriad sy'n bwysig yw'r llwybr yn ôl at y ffynhonnell, neu'n ôl at yr RP ar gyfer coeden a rennir. Mae ymuniad sy'n cyrraedd ar ryngwyneb nad yw'r llwybrydd yn ei ystyried yn uwch yn cael ei ollwng, ac mae'r rheswm yn cael ei gofnodi fel methiant RPF yn hytrach nag fel methiant twnnel. Ar lwybrydd cangen â llwybr diofyn dros y twnnel a llwybr mwy penodol dros y WAN, gall y rhyngwyneb RPF fod y WAN yn hawdd er mai drwy'r twnnel yn unig y gellir cyrraedd y ffynhonnell. Dyma'r un rheswm mwyaf cyffredin pam mae ymuniad yn cael ei daflu'n dawel.

Mae show ip rpf 192.0.2.10 yn argraffu'r rhyngwyneb a ddewiswyd, y cam nesaf a'r llwybr a gynhyrchodd y penderfyniad, sy'n ddigon fel arfer i weld yr anghysondeb. Mae llwybr multicast statig fel ip mroute 192.0.2.0 255.255.255.0 tunnel0 yn diystyru'r edrychiad unicast ar gyfer y rhagddodiad hwnnw, ac mae'n ateb cyfreithlon pan fo'r topoleg multicast yn wirioneddol wahanol i'r topoleg unicast. Triniwch ef fel ffurfweddiad y dylid ei ddogfennu, nid fel clwt a roddwyd yn ystod digwyddiad ac yna ei anghofio.

Cadarnhewch yr ymuniad gyda gorchmynion, nid gyda phing

Mae ping yn profi bod unicast yn gweithio, rhywbeth a wyddech yn barod. Y cadarnhad o ben bwy gilydd yw dilyniant sy'n dangos yr ymuniad, y mapio, y cymydog a'r goeden yn y drefn honno, ac mae pob gorchymyn yn ateb cwestiwn gwahanol.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Mae cofnod (S,G) poblog gyda rhyngwyneb dod i mewn go iawn a rhestr allan nad yw'n wag yn golygu bod yr awyren reoli wedi gorffen ei gwaith. Mae cofnod y mae ei ryngwyneb dod i mewn yn darllen Null, neu gownter wedi'i labelu RPF failed sy'n dal i ddringo, yn pwyntio'n ôl at yr adran flaenorol yn hytrach nag at y twnnel.

Os yw'r pum gorchymyn i gyd yn edrych yn iawn ac mae'r derbynnydd yn dal i weld dim, y drwgdybiaeth sy'n weddill yw polisi'r twnnel ei hun: ACL crypto neu reol wal dân sy'n caniatáu'r protocol llwybro unicast ond nid PIM, IGMP, na thraffig y grŵp ei hun. Ar dwnnel IPsec seiliedig ar bolisi, ni chedwir multicast o gwbl, felly'r ateb yw dyluniad GRE neu VTI yn hytrach nag esgusodiddeb hidlydd arall. Nodwch pa un o'r pum prawf a fethodd cyn i chi newid unrhyw beth, ac yna newidiwch y haen honno yn unig.