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 ಕಡೆಗೆ ಕಟ್ಟುತ್ತದೆ. ಮ್ಯಾಪಿಂಗ್ ಗುಂಪು ಶ್ರೇಣಿ ಮತ್ತು ವಿಳಾಸ ಎರಡರಲ್ಲೂ ಒಪ್ಪಬೇಕು, ಏಕೆಂದರೆ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಶ್ರೇಣಿ ಅಗಲವಾದದ್ದನ್ನು ಸೋಲಿಸುತ್ತದೆ.

Anycast-RP ಎರಡು ಸೈಟ್‌ಗಳು ಒಂದೇ 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 ವಿನ್ಯಾಸ, ಇನ್ನೊಂದು ಫಿಲ್ಟರ್ ಅಪವಾದವಲ್ಲ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಐದು ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ಯಾವುದು ವಿಫಲವಾಯಿತು ಎಂದು ಬರೆಯಿರಿ, ನಂತರ ಆ ಪದರವನ್ನು ಮಾತ್ರ ಬದಲಿಸಿ.