VPN வழியாக PIM-SM: BSR, RP மேப்பிங் மற்றும் RPF பாதைகளைச் சரிபார்க்கவும்

சுரங்கப்பாதை இயங்குகிறது, யூனிகாஸ்ட் பிங்குகள் அதன் வழியாகச் செல்கின்றன, இருந்தும் பெறுபவர் இன்னும் கருப்புத் திரையைக் காட்டுகிறார். PIM-SM பயன்பாட்டில் இந்த அறிகுறி கிட்டத்தட்ட எப்போதும் நான்கு கட்டுப்பாட்டுப் பாதைகளில் ஒன்று உடைந்துள்ளது என்பதையும், தரவுப் பாதை ஒருபோதும் சிக்கலாக இருந்ததில்லை என்பதையும் குறிக்கிறது. கீழே உள்ள பட்டியலை வரிசையாகச் செய்து, தோல்வியடையும் முதல் படியில் நிறுத்துங்கள், ஏனெனில் அடுத்த ஒவ்வொரு படியும் முந்தையதைச் சார்ந்தது. இந்த ஐந்து சரிபார்ப்புகளையும் ஒரு வரைவுக் கோப்பில் வைத்து, மல்டிகாஸ்ட் புகார் வரும்போது முனையத்தில் ஒட்டுகிறேன், இது கண்டறிதல் ஊகமாக மாறுவதைத் தடுக்கிறது.

சுரங்கப்பாதையிலிருந்து அல்ல, பெறுபவரிலிருந்து தொடங்குங்கள்

குழுவை ஒருபோதும் கோராத பெறுபவர் எந்த ரௌட்டரிலும் எந்த நிலையையும் உருவாக்குவதில்லை, எனவே வேறு எதையும் பரிசோதிக்கும் முன் பெறுபவர் பக்கப் பிரிவில் இணைப்பு உள்ளதை உறுதிப்படுத்துங்கள். Cisco பாணி தளங்களில், கடைசி ஹாப்பின் ரௌட்டரில் show ip igmp groups இணைந்த குழுக்களை அவற்றைக் கேட்ட இடைமுகத்தின் அருகில் அச்சிடுகிறது. அந்த வெளியீட்டில் குழு இல்லாதபோது, சுரங்கப்பாதை கவனத்தைத் திசைதிருப்புவதாகும்: கோரிக்கை அணுகல் சுவிட்சில், ஹோஸ்ட் சாக்கெட்டில் அல்லது querier இல்லாத VLAN-இல் இறந்தது.

நான் கண்ட பெரும்பாலான காணாமல் போன இணைப்புகளுக்கு இரண்டு சாதாரண காரணங்கள் உள்ளன: ஹோஸ்ட் மற்றும் ரௌட்டருக்கு இடையேயான IGMP பதிப்பு முரண்பாடு, மற்றும் ரூட்டிங் செய்யாத சுவிட்சில் விழுந்த querier தேர்வு. மூன்றாவது மிகவும் நுட்பமானது: குழுவில் இணைந்துள்ளது ஆனால் தவறான VLAN-இல், ஏனெனில் ஹோஸ்ட்டில் இரண்டு நெட்வொர்க் கார்டுகள் உள்ளன, பயன்பாடு தவறான கார்டில் பிணைந்துள்ளது. IPv6 பெறுபவர்களுக்கு MLD-இல் அதே சிக்கல் உள்ளது, அங்கு show ipv6 mld groups அதே கேள்விக்குப் பதிலளிக்கிறது. இவை எதுவும் சுரங்கப்பாதையைத் தொட்டு சரிசெய்யப்படுவதில்லை, அதனால்தான் வரிசை முக்கியமானது.

இணைப்பு தெரிந்ததும், பெறுபவர் பக்க இடைமுகத்திலும் சந்திப்புப் புள்ளியை நோக்கிச் செல்லும் இடைமுகத்திலும் PIM இயக்கப்பட்டுள்ளதை உறுதிப்படுத்துங்கள். IGMP உறுப்பினர் நிலை உள்ள ஆனால் மேல்நோக்கு இடைமுகத்தில் PIM இல்லாத ரௌட்டர் குழுவை உள்ளூர் அட்டவணையில் வைத்திருக்கும், எங்கும் எதையும் அனுப்பாது.

BSR தொகுப்பு மறுபக்கத்தை அடையுமா?

Bootstrap Router செய்திகள் ஒரு PIM டொமைனுக்குள் ஹாப் விட்டு ஹாப் நகர்கின்றன, சுரங்கப்பாதை வழியாக உடையும் திசை அதுவே. வேட்பாளர் RP-கள் தங்கள் அறிவிப்புகளை தேர்ந்தெடுக்கப்பட்ட BSR-க்கு யூனிகாஸ்ட் வழியாக அனுப்புகின்றன, எனவே RP-முதல்-BSR பகுதி இயங்கும் சுரங்கப்பாதையில் வழக்கமாக மாற்றமின்றி நீடிக்கும். மறுதிசையில் Bootstrap செய்திகளின் வெள்ளம், ஒவ்வொரு இடைநிலை இடைமுகத்திலும் PIM இயக்கப்பட்டிருப்பதையும், எல்லையில் செய்திகளை நிறுத்துவது எதுவும் இல்லாததையும் பொறுத்தது. RFC 5059 அந்தப் பகிர்வையும் அதைச் சுருக்க அனுமதிக்கப்படும் நிர்வாக வரம்பு எல்லைகளையும் வரையறுக்கிறது.

ip pim bsr-border கூற்று, நெறிமுறை 103-ஐ வடிகட்டும் ACL, அல்லது மல்டிகாஸ்ட் சுமக்க முடியாத கொள்கை அடிப்படையிலான IPsec சுரங்கப்பாதை, ஒவ்வொன்றும் வெள்ளத்தை வெட்டி யூனிகாஸ்ட் பாதுகாப்பாக இருக்கும். உண்மையில் அடையக்கூடிய தன்மையின் சிக்கலாக இருக்கும்போது தோல்வியை RP சிக்கலாகத் தோற்றமளிக்கச் செய்வது இந்தக் கலவையே, அதனால்தான் RP உள்ளமைவுக்கு முன் BSR நிலையைப் படிக்கிறேன்.

தொலைப் பக்க ரௌட்டரில் show ip pim bsr-router தேர்ந்தெடுக்கப்பட்ட BSR-ஐயும் கற்ற RP தொகுப்பையும் பெயரிடுகிறது; வெளியீடு காலியாக இருந்தால், தொலைப் பக்கம் அதன் சொந்த டொமைனில் அமர்ந்துள்ளது, எந்த RP உள்ளமைவும் இரண்டையும் ஒப்புரவாக்காது. சுரங்கப்பாதையின் இரு பக்கங்களிலும் show ip pim rp mapping-இல் குழு வரம்புகளையும் RP முகவரிகளையும் ஒப்பிடுங்கள். உள்ளூரில் மட்டுமே உள்ள மேப்பிங் தவறான இடத்தில் முடியும் பங்கிடப்பட்ட மரத்தை உருவாக்குகிறது, பெறுபவர் எப்போதும் காத்திருக்கிறார்.

சுரங்கப்பாதையின் இரு பக்கங்களிலும் RP மேப்பிங்கைப் பொருத்துங்கள்

நிலையான RP, BSR மற்றும் anycast-RP ஆகியவை ஒரே கேள்விக்கான மூன்று பதில்கள், அவற்றைச் சுரங்கப்பாதை வழியாகக் கலப்பது ஒருபோதும் ஒன்றிணையாத டொமைனை உருவாக்கும் நம்பகமான வழி. முன்னணி முனை BSR-ஐப் பயன்படுத்தி, கிளை வேறு முகவரியைச் சுட்டும் நிலையான ip pim rp-address-ஐப் பயன்படுத்தினால், கிளை தன் பங்கிடப்பட்ட மரத்தைப் பெறுபவர் இருப்பதை அறியாத RP நோக்கிக் கட்டுகிறது. மேப்பிங் குழு வரம்பிலும் முகவரியிலும் ஒத்துப்போக வேண்டும், ஏனெனில் மிகக் குறிப்பிட்ட வரம்பு பரந்த வரம்பை வெல்கிறது.

இரு தளங்கள் ஒரு RP முகவரியைப் பங்கிட முடிவதற்காகவே anycast-RP உள்ளது, அதை இங்கு பெயரிடுவது மதிப்புள்ளது, ஏனெனில் அது «அதே RP» என்பதன் பொருளை மாற்றுகிறது. ஒரு முகவரியை அறிவிக்கும் இரு RP-கள் வடிவமைப்பின்படி ஒத்திசைவானவை; ஒரே வரம்புக்கு வெவ்வேறு முகவரிகளை அறிவிக்கும் இரு RP-கள் அல்ல, ஒவ்வொரு தளமும் தனித்து எவ்வளவு ஆரோக்கியமாகத் தோன்றினாலும்.

232.0.0.0/8-க்குள் மூலம்-குறிப்பிட்ட மல்டிகாஸ்டுக்கு RP-யிடம் ஒருபோதும் கேட்கப்படுவதில்லை, எனவே காலியான RP மேப்பிங் தானாகவே குறைபாடு அல்ல. ஒருபோதும் தேவைப்படாத RP-ஐத் துரத்தும் முன், பயன்பாடு எந்தச் சேவை மாதிரியைப் பயன்படுத்துகிறது என்பதை முடிவு செய்யுங்கள்.

மூலத்தை நோக்கிய RPF தேடலைப் படியுங்கள்

PIM யூனிகாஸ்ட் பாதையைத் திருப்பி மரத்தைக் கட்டுகிறது, எனவே முக்கியச் சரிபார்ப்பு மூலத்திற்குத் திரும்பிச் செல்லும் வழி, அல்லது பங்கிடப்பட்ட மரத்திற்கு RP-க்குத் திரும்பிச் செல்லும் வழி. ரௌட்டர் மேல்நிலை எனக் கருதாத இடைமுகத்தில் வரும் இணைப்பு நிராகரிக்கப்படுகிறது, காரணம் சுரங்கப்பாதைத் தோல்வியாக அல்ல, RPF தோல்வியாகப் பதிவாகிறது. சுரங்கப்பாதை மீது இயல்புநிலை வழியும் WAN மீது மிகக் குறிப்பிட்ட வழியும் உள்ள கிளை ரௌட்டரில், மூலத்தைச் சுரங்கப்பாதை வழியாக மட்டுமே அடைய முடிந்தாலும் RPF இடைமுகம் எளிதாக WAN ஆக இருக்கலாம். இணைப்பு அமைதியாக நிராகரிக்கப்படுவதற்கான ஒரே பொதுவான காரணம் இதுவே.

show ip rpf 192.0.2.10 தேர்ந்தெடுக்கப்பட்ட இடைமுகம், அடுத்த ஹாப் மற்றும் முடிவை உருவாக்கிய வழியை அச்சிடுகிறது, பொதுவாக முரண்பாட்டைக் காண இது போதும். ip mroute 192.0.2.0 255.255.255.0 tunnel0 போன்ற நிலையான மல்டிகாஸ்ட் வழி அந்த முன்னொட்டுக்கான யூனிகாஸ்ட் தேடலை மீறுகிறது, மல்டிகாஸ்ட் இடவியல் யூனிகாஸ்ட் இடவியலிலிருந்து உண்மையில் வேறுபடும்போது இது செல்லுபடியாகும் திருத்தம். அதை ஆவணப்படுத்த வேண்டிய உள்ளமைவாகக் கருதுங்கள், சம்பவத்தின்போது பயன்படுத்திவிட்டு மறந்துவிடும் திட்டாக அல்ல.

பிங்கால் அல்ல, கட்டளைகளால் இணைப்பை உறுதிப்படுத்துங்கள்

பிங் யூனிகாஸ்ட் இயங்குகிறது என்பதை நிரூபிக்கிறது, அது உங்களுக்கு ஏற்கனவே தெரியும். முனை முதல் முனை வரையிலான உறுதிப்படுத்தல் என்பது இணைப்பு, மேப்பிங், அண்டை மற்றும் மரத்தை அதே வரிசையில் காட்டும் தொடர், ஒவ்வொரு கட்டளையும் வெவ்வேறு கேள்விக்குப் பதிலளிக்கிறது.

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

உண்மையான உள்வரும் இடைமுகமும் காலியாக இல்லாத வெளிச்செல்லும் பட்டியலும் கொண்ட நிரப்பப்பட்ட (S,G) உள்ளீடு கட்டுப்பாட்டுத் தளம் தன் வேலையை முடித்ததைக் குறிக்கிறது. உள்வரும் இடைமுகம் Null எனப் படிக்கப்படும் உள்ளீடு, அல்லது தொடர்ந்து ஏறும் RPF failed லேபிளிட்ட கவுண்டர், சுரங்கப்பாதையை நோக்கி அல்ல, முந்தைய பகுதியை நோக்கிக் காட்டுகிறது.

ஐந்து கட்டளைகளும் சரியாகத் தோன்றினாலும் பெறுபவர் இன்னும் எதையும் காணவில்லை என்றால், மீதமுள்ள சந்தேகத்திற்குரியது சுரங்கப்பாதையின் சொந்தக் கொள்கையே: யூனிகாஸ்ட் ரூட்டிங் நெறிமுறையை அனுமதித்து PIM, IGMP அல்லது குழுப் போக்குவரத்தை அனுமதிக்காத கிரிப்டோ ACL அல்லது ஃபயர்வால் விதி. கொள்கை அடிப்படையிலான IPsec சுரங்கப்பாதையில் மல்டிகாஸ்ட் அறவே சுமக்கப்படுவதில்லை, எனவே பதில் இன்னொரு வடிகட்டி விதிவிலக்கு அல்ல, GRE அல்லது VTI வடிவமைப்பு. எதையும் மாற்றும் முன் ஐந்தில் எந்தச் சரிபார்ப்பு தோல்வியடைந்தது என்பதை எழுதுங்கள், பின்னர் அந்த அடுக்கை மட்டும் மாற்றுங்கள்.