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 రూపకల్పన. ఏదైనా మార్చే ముందు ఐదు తనిఖీలలో ఏది విఫలమైందో రాయండి, ఆపై ఆ పొరను మాత్రమే మార్చండి.