ಪ್ರತಿ-ಟನೆಲ್ QoS ನಿಮ್ಮ ಹಬ್‌ನ ಒಟ್ಟು ಅಪ್‌ಲಿಂಕ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸುವುದಿಲ್ಲ

ಈ ನಂಬಿಕೆ ಅಂಕಗಣಿತದಂತೆ ಕೇಳಿಸುತ್ತದೆ: ಐದು ಸ್ಪೋಕ್ಗಳು, ಪ್ರತಿಯೊಂದೂ 5 Mbit/s ಗೆ ಆಕಾರ ನೀಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಹಬ್ ಗರಿಷ್ಠ 25 Mbit/s ಸಾಗಿಸುತ್ತದೆ. ಮೊದಲ ಅರ್ಧ ಸರಿ ಮತ್ತು ತೀರ್ಮಾನ ಅಲ್ಲ. ಪ್ರತಿ-ಟನೆಲ್ ನೀತಿಯನ್ನು ಪ್ರತಿ ಟನೆಲ್ಗೆ ಒಮ್ಮೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ, ಪ್ರತಿ ಹಬ್ಗೆ ಒಮ್ಮೆ ಅಲ್ಲ, ಮತ್ತು ಐದೂ ಟನೆಲ್ಗಳು ದಾಟುವ ಹಂಚಿಕೆಯ ಅಪ್ಲಿಂಕ್ ಆ ಲೆಕ್ಕದಲ್ಲಿ ಎಂದೂ ಕಾಣಿಸುವುದಿಲ್ಲ. ಅಪ್ಲಿಂಕ್ನ ದಟ್ಟಣೆ ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಉಳಿಯುತ್ತದೆ.

ಈ ನಂಬಿಕೆ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ

ಗೊಂದಲ ಅರ್ಥವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ NHRP ಗುಂಪು ಮಾಹಿತಿ ಒಂದು ನೀತಿ ವ್ಯಾಖ್ಯಾನವನ್ನು ಸಂಪೂರ್ಣ ಸ್ಪೋಕ್ ಗುಂಪಿಗೆ ಅನ್ವಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಅದು ಸಂರಚನಾ ಕಡತದಲ್ಲಿ ಹಂಚಿಕೆಯ ಬಜೆಟ್ನಂತೆ ಓದುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ ಅದರ ಅರ್ಥ ಪ್ರತಿ ಸ್ಪೋಕ್ ಆ ವ್ಯಾಖ್ಯಾನದ ತನ್ನದೇ ಆದ ನಿದರ್ಶನವನ್ನು ಪಡೆಯುತ್ತದೆ.

ಆದ್ದರಿಂದ ಪ್ರತಿ ಸ್ಪೋಕ್ಗೆ 5 Mbit/s ಎಂಬುದು ಪ್ರತಿ-ಟನೆಲ್ ಮೇಲ್ಮಿತಿ, ಮತ್ತು ಟನೆಲ್ಗಳಷ್ಟೇ ಮೇಲ್ಮಿತಿಗಳಿವೆ.

ಒಂದು ನೀತಿ ನಿದರ್ಶನ ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ

Cisco ನ IOS XE ನಲ್ಲಿ DMVPN ನಲ್ಲಿ ಪ್ರತಿ-ಟನೆಲ್ QoS ಮಾರ್ಗದರ್ಶಿ NHRP ಗುಂಪು ಮಾಹಿತಿಯ ಮೂಲಕ ಆಯ್ಕೆಯಾಗಿ ಪ್ರತಿ ಸ್ಪೋಕ್ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಅನ್ವಯವಾಗುವ ಹಬ್ ನಿರ್ಗಮನ ನೀತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆ ವಾಕ್ಯದಿಂದ ಎರಡು ಮಿತಿಗಳು ಬರುತ್ತವೆ ಮತ್ತು ಎರಡೂ ನಿರ್ಲಕ್ಷಿಸಲ್ಪಡುತ್ತವೆ. ದರವು ಒಂದು ಸ್ಪೋಕ್ಗೆ ಸೇರಿದೆ, ಹಂಚಿಕೆಯ ಬಕೆಟ್ಗೆ ಅಲ್ಲ, ಮತ್ತು ಈ ವೈಶಿಷ್ಟ್ಯವು ಹಬ್ನಿಂದ ಸ್ಪೋಕ್ಗೆ ಇರುವ ಸಂಚಾರವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ತಿರುವುಬದಲಾಗಿ ಅಲ್ಲ.

ಸ್ಪೋಕ್ನ ಕಳುಹಿಸುವ ದಿಕ್ಕನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಯೋಜಿಸಿ. ಹಬ್ ನಿರ್ಗಮನ ನೀತಿಯಲ್ಲಿ ಶಾಖೆಯು ಅಪ್ಲೋಡ್ ಮಾಡುವುದನ್ನು ಮಿತಿಗೊಳಿಸುವ ಯಾವುದೂ ಇಲ್ಲ.

ಒಟ್ಟು ಮಿತಿಯನ್ನು ಹಂಚಿಕೆಯ ಬಾಟಲ್ನೆಕ್ನಲ್ಲಿ ಇರಿಸಿ

ಒಟ್ಟು ಮೊತ್ತವು ಅದು ನಿಜವಾಗಿ ಸ್ಪರ್ಧಿಸುವ ಸ್ಥಳದಲ್ಲಿ ಆಕಾರ ಪಡೆಯಬೇಕು: ಎಲ್ಲಾ ಟನೆಲ್ಗಳು ಹಂಚಿಕೊಳ್ಳುವ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ. Cisco ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿನ class-default ಶೇಪರ್ ಅನ್ನು ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಬೆಂಬಲಿತ ಏಕಕಾಲಿಕ ಭೌತಿಕ ನೀತಿ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ, ಇದು ನೀವು ಟೈಪ್ ಮಾಡಬಹುದಾದ ಯಾವುದೇ ಶ್ರೇಣಿವ್ಯವಸ್ಥೆಗಿಂತ ಸಣ್ಣ ಹೇಳಿಕೆ. ನೀವು ಕಂಡುಹಿಡಿದ ಯಾವುದೇ ಎರಡನೇ ಭೌತಿಕ ನೀತಿಯು ಯಾರಾದರೂ ವಿರುದ್ಧ ಸಾಬೀತುಪಡಿಸುವವರೆಗೆ ಬೆಂಬಲಿತವಲ್ಲ ಎಂದು ಊಹಿಸಿ.

ನಂತರ ಎಲ್ಲಾ ಸ್ಪೋಕ್ಗಳು ಒಟ್ಟಿಗೆ ಕಾರ್ಯನಿರತವಾಗಿರುವಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಯಾವ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ, ಯಾವ ವರ್ಗಕ್ಕೆ ಆದ್ಯತೆ ಸಿಗುತ್ತದೆ, ಮತ್ತು ಯಾವ ಸರದಿ ಸ್ಪರ್ಧೆಯನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ-ಸ್ಪೋಕ್ ಮೇಲ್ಮಿತಿ ಈ ಪ್ರಶ್ನೆಗಳ ಒಂದಕ್ಕೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ರತಿ ಸ್ಪೋಕ್ ಅನ್ನು ಒಂಟಿಯಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಆಕಾರ ನೀಡುವ ಘಟಕಗಳು ಮತ್ತು ಓವರ್ಹೆಡ್ ಲೆಕ್ಕವನ್ನು ನಿಜವಾದ ಹಸ್ತಾಂತರಕ್ಕೆ ಹೊಂದಿಸಿ. ದರ ಲೆಕ್ಕದಿಂದ ಹೊರಗಿಡುವ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಓವರ್ಹೆಡ್ ಸಂರಚಿತ ಸಂಖ್ಯೆಗಿಂತ ಮೊದಲೇ ತುಂಬಿಕೊಳ್ಳುವ ಕೊಂಡಿಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಕೌಂಟರ್ಗಳು ಒಂದು ನಿರ್ದಿಷ್ಟ ರೀತಿಯಲ್ಲಿ ಸುಳ್ಳು ಹೇಳುತ್ತವೆ

ನೀವು ಆಕಾರ ನೀಡುತ್ತಿರುವ ಪದರದಲ್ಲಿ ಕೌಂಟರ್ಗಳನ್ನು ಓದಿ. ಅದೇ Cisco ಮಾರ್ಗದರ್ಶಿ ಮುಖ್ಯ ಇಂಟರ್ಫೇಸ್ ನೀತಿ ಕೌಂಟರ್ಗಳು ಈ ಜೋಡಣೆಯಲ್ಲಿ ನಿಖರವಾಗಿಲ್ಲದಿರಬಹುದು ಎಂದು ಎಚ್ಚರಿಸುತ್ತದೆ. ಅದು ಕೌಂಟರ್ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆ, ವರ್ಗವು ಹೊಂದುತ್ತಿದೆ ಅಥವಾ ಬಿಡುತ್ತಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಫಲಿತಾಂಶದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ ಏಕೈಕ ವಿಷಯ ಅದೇ.

ಹಳೆಯ traffic-shape ಉದಾಹರಣೆಯನ್ನು ಸಂಬಂಧವಿಲ್ಲದ ನೀತಿ ನಕ್ಷೆಯ ಪಕ್ಕದಲ್ಲಿ ನಕಲಿಸುವುದು ಎರಡೂ ದರಗಳು ಒಂದೇ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಒಟ್ಟು ಮೊತ್ತವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಕೇವಲ ಮೇಲ್ಮಿತಿಯನ್ನಲ್ಲ

ಒಂದು ಕಾರ್ಯನಿರತ ಸ್ಪೋಕ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಅದು ತನ್ನ ಮೇಲ್ಮಿತಿಯನ್ನು ತಲುಪುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಅನುಮೋದಿತ ಯೋಜನೆಯ ಅಡಿಯಲ್ಲಿ ಎಲ್ಲರಿಂದಲೂ ಒಟ್ಟಿಗೆ ಸಂಚಾರವನ್ನು ನೀಡಿ, ಮತ್ತು ಪ್ರತಿ-ಟನೆಲ್ ಸಂಖ್ಯೆಗಳ ಪಕ್ಕದಲ್ಲಿ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಗಮನಿಸಿ. ಪ್ರತಿ ಸ್ಪೋಕ್ ತನ್ನ ಮೇಲ್ಮಿತಿಯಲ್ಲಿ ಕುಳಿತಿದ್ದರೆ ಮತ್ತು ಅಪ್ಲಿಂಕ್ ಸ್ತಬ್ಧವಾಗಿ ವಿಳಂಬ ಏರಿದರೆ, ಪ್ರತಿ-ಸ್ಪೋಕ್ ನೀತಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಬಜೆಟ್ ಇನ್ನೂ ತಪ್ಪಾಗಿದೆ.

ಆ ಹಂತದಲ್ಲಿ ಪರಿಹಾರ ಸಾಮರ್ಥ್ಯ ಅಥವಾ ಪ್ರವೇಶದ ನಿರ್ಧಾರ. ಪ್ರತಿ-ಸ್ಪೋಕ್ ಸಂಖ್ಯೆಗಳನ್ನು ಮರುಹೊಂದಿಸುವುದು ಯಾವ ಶಾಖೆ ಮೊದಲು ದೂರು ಹೇಳುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತದೆ.