DSCP ಗುರುತು ಅಥವಾ ಒದಗಿಸುವವರ QoS ಭರವಸೆ? ಎರಡೂ ಒಪ್ಪಂದವಲ್ಲ

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

local match → queue and marking → provider classifier
  → provider treatment → destination

ಸರಿಯಾದ ಗುರುತು ಎಲ್ಲಿ ಮೌನವಾಗಿ ಸಾಯಬಹುದು

ಪ್ರತಿ ಕೆಲಸದ ಭಾರಕ್ಕೂ ಸ್ಥಳೀಯ ಹೊಂದಾಣಿಕೆ ಷರತ್ತು, ಸುರಂಗದ ಒಳಗೆ ಸಂಭವಿಸುವ ಯಾವುದೇ ಗುರುತು, ಒದಗಿಸುವವರು ಸ್ವೀಕರಿಸುವ ಮೌಲ್ಯ ಮತ್ತು ಆ ಮೌಲ್ಯ ಆಯ್ಕೆಮಾಡುವ ಸೇವಾ ವರ್ಗವನ್ನು ಬರೆಯುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ನಾಲ್ಕು ಕಾಲಂಗಳು, ಮತ್ತು ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನೇ ಮತ್ತು ಮೂರನೆಯ ನಡುವೆ ವಾಸಿಸುತ್ತವೆ.

ಒಳಗಿನಿಂದ ಹೊರಗಿನ ಶೀರ್ಷಿಕೆಗೆ ಗುರುತಿಸುವ ನಡವಳಿಕೆ ಶಾಸ್ತ್ರೀಯ ಸಮಸ್ಯೆ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಅಥವಾ ಸುರಂಗ ಮಾರ್ಗದಲ್ಲಿರುವ ಪ್ಯಾಕೆಟ್ ನಿಮ್ಮ ವರ್ಗೀಕರಣಕಾರರು ನೋಡಬಹುದಾದ ಒಳಗಿನ ಶೀರ್ಷಿಕೆ ಮತ್ತು ಒದಗಿಸುವವರ ಸಾಧನಗಳು ನೋಡಬಹುದಾದ ಹೊರಗಿನ ಶೀರ್ಷಿಕೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಒಂದನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ನಕಲಿಸುವುದು ಸಂರಚನೆಯ ನಿರ್ಣಯ, ಸ್ವಯಂಚಾಲಿತ ಗುಣವಲ್ಲ. ಒಳಗಿನ ಶೀರ್ಷಿಕೆಯನ್ನು ಮಾತ್ರ ಗುರುತಿಸಿ ಮತ್ತು ಒದಗಿಸುವವರು ಹೊರಗಿನದನ್ನು ವರ್ಗೀಕರಿಸುತ್ತಾರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಡೀಫಾಲ್ಟ್ ಆಗಿ, ಆದ್ದರಿಂದ ಸರಿಯಾಗಿ ಗುರುತಿಸಿದ ಹರಿವು ನಿಮ್ಮ ಕಡೆ ಒಂದೇ ತಪ್ಪು ಸಂರಚಿತ ಸಾಲಿಲ್ಲದೆ ತಪ್ಪು ವರ್ಗಕ್ಕೆ ಬರಬಹುದು.

ಸ್ಥಳೀಯವಾಗಿ ಹೆಸರಿಸಿದ ವರ್ಗವೂ ಖಾಲಿ ಉಳಿಯಬಹುದು ಏಕೆಂದರೆ ಅದರ ಹೊಂದಾಣಿಕೆ ಷರತ್ತು ನಿಜವಾದ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ ಎಂದಿಗೂ ಸಕ್ರಿಯವಾಗುವುದಿಲ್ಲ. ಪೋರ್ಟ್‌ಗಳು ಚಲಿಸುತ್ತವೆ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹಲವು ಹರಿವುಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಮತ್ತು ಮಾರಾಟಗಾರರು ಎರಡು ಬಿಡುಗಡೆಗಳ ಹಿಂದೆ ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಪ್ರಸಿದ್ಧ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಹೊಂದಾಣಿಕೆ ಶೂನ್ಯ ಕೌಂಟರ್‌ಗಳ ಸರದಿ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಸಂರಚನೆಯಲ್ಲಿ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುವ ನೀತಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಗುರುತುಗಳನ್ನು ಎಲ್ಲಿ ನಂಬಲಾಗುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ಧರಿಸಿ. ಸುರಂಗವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಎಲ್ಲವನ್ನೂ ಉತ್ತೇಜಿಸುವುದು ಕರೆಗಳ ಜೊತೆಗೆ ಬೃಹತ್ ವರ್ಗಾವಣೆಗಳನ್ನೂ ಉತ್ತೇಜಿಸುತ್ತದೆ, ಮತ್ತು ಪರಿಶೀಲನೆ ಇಲ್ಲದೆ ನಿಮ್ಮ ಗುರುತನ್ನು ಸ್ವೀಕರಿಸುವ ಒದಗಿಸುವವರು ನಿಮಗೆ ನೀವೇ ಹಾನಿ ಮಾಡಿಕೊಳ್ಳುವ ದಾರಿಯನ್ನು ನೀಡುತ್ತಾರೆ. ಒಪ್ಪಂದವು ಗೇಟ್‌ವೇಗೆ ಹಸ್ತಾಂತರದಲ್ಲಿ ಮರುಗುರುತು ಮಾಡಲು ಅನುಮತಿಸಿದರೆ, ಅದನ್ನು ಲಿಖಿತವಾಗಿ ಹೇಳಿ, ಏಕೆಂದರೆ ಎರಡು ತಂಡಗಳ ಊಹೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಹಂತದಲ್ಲಿ ಭಿನ್ನವಾಗುತ್ತವೆ.

ಶೆಡ್ಯೂಲರ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ವಿಭಜಿಸುತ್ತದೆ

ಸ್ಥಳೀಯ ನೀತಿಗೆ ತನ್ನದೇ ಆದ ಅರ್ಥಶಾಸ್ತ್ರವಿದೆ, ಮತ್ತು ಅತಿ ಹೆಚ್ಚು ತಪ್ಪುಗ್ರಹಿಕೆಯನ್ನು “remaining” ಪದ ಸೃಷ್ಟಿಸುತ್ತದೆ. IOS XE ಶೆಡ್ಯೂಲಿಂಗ್ ಮಾರ್ಗದರ್ಶಿಯು ವಿವರಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ bandwidth remaining percent ಹೆಚ್ಚುವರಿ ತೂಕವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ, ಪ್ರತಿ ವರ್ಗವು ಹಿಂದಿನ ವರ್ಗ ಬಿಟ್ಟದ್ದರಿಂದ ಪಾಲನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಅನುಕ್ರಮದ ಹಂತವಲ್ಲ. ಹಂಚಿಕೆಯಾಗದ ಶೇಕಡಾವಾರುಗಳು ಕಡತದ ಕೊನೆಯ ವರ್ಗಕ್ಕೆ ಕಾಯ್ದಿರಿಸಲ್ಪಡುವ ಬದಲು ಅರ್ಹವಾದ ಸಂರಚಿಸದ ಸರದಿಗಳಲ್ಲಿ ಹರಡುತ್ತವೆ.

ಆ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ ಏಕೆಂದರೆ ಅನುಕ್ರಮ ಮಾನಸಿಕ ಮಾದರಿ ಕೌಂಟರ್‌ಗಳಿಗೆ ಎಂದಿಗೂ ಹೊಂದದ ಮುನ್ಸೂಚನೆಗಳನ್ನು ನೀಡುತ್ತದೆ. ಇಂಜಿನಿಯರ್‌ಗಳು ಫಲಿತಾಂಶವನ್ನು ಬದಲಿಸಲು ವರ್ಗಗಳನ್ನು ಮರುಕ್ರಮಗೊಳಿಸುತ್ತಾರೆ, ವ್ಯತ್ಯಾಸ ಕಾಣುವುದಿಲ್ಲ ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಕೆಟ್ಟಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತಾರೆ, ಆದರೆ ಸಂರಚನೆ ಅವರು ಊಹಿಸಿದ ಅರ್ಥವನ್ನು ಎಂದಿಗೂ ಹೊಂದಿರಲಿಲ್ಲ.

ಪೋಷಕ ಆಕಾರಕವು ಇನ್ನೊಂದು ಸಾಮಾನ್ಯ ಆಶ್ಚರ್ಯ. ನಿಯಂತ್ರಿತ ಸರದಿಯನ್ನು ಬಳಸಬಹುದಾದ ಸೇವಾ ದರಕ್ಕೆ ಆಕಾರ ಮಾಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ದೇಶಪೂರ್ವಕ, ಏಕೆಂದರೆ ಅದು ದಟ್ಟಣೆಯ ಬಿಂದುವನ್ನು ನೀವು ನಿರ್ವಹಿಸುವ ಸಾಧನಕ್ಕೆ ಸರಿಸುತ್ತದೆ, ನೀವು ನಿರ್ವಹಿಸದ ಮೇಲ್ಮುಖ ಸರದಿಗೆ ಅಲ್ಲ. ಆಕಾರವು ವಿಳಂಬ ಸೇರಿಸುತ್ತದೆ ಎಂದು ಆಕಾರಕವನ್ನು ತೆಗೆದರೆ ನಷ್ಟವನ್ನು ತೆಗೆಯುವ ಬದಲು ಸ್ಥಳಾಂತರಿಸಬಹುದು, ಮತ್ತು ಓವರ್‌ಹೆಡ್ ಲೆಕ್ಕಪತ್ರ ಅಥವಾ ಒದಗಿಸುವವರ ಪೊಲೀಸರ್ ಪರಿಣಾಮಕಾರಿ ದರವನ್ನು ಇಂಟರ್ಫೇಸ್ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಕೌಂಟರ್‌ಗಳು ಯಾವ ಅರ್ಧ ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳುತ್ತವೆ

ಬಾಧಿತ ದಿಕ್ಕಿನಲ್ಲಿ ನಾಲ್ಕು ಸಂಖ್ಯೆಗಳನ್ನು ಹೋಲಿಸಿ: ಏನು ನೀಡಲಾಯಿತು, ವರ್ಗ ಯಾವುದಕ್ಕೆ ಹೊಂದಿತು, ಏನು ಸರದಿಗೆ ಸೇರಿತು ಅಥವಾ ಬಿಡಲಾಯಿತು, ಮತ್ತು ಸೇವೆ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ತಲುಪಿಸಿತು. ಕೆಲಸದ ಭಾರದ ವಿವರಣೆ ಮತ್ತು ನೀತಿಯ ಆವೃತ್ತಿಯನ್ನು ವೀಕ್ಷಣೆಯ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಅವುಗಳಿಲ್ಲದೆ ಕೌಂಟರ್‌ಗಳ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಮರುಸೃಷ್ಟಿಸಲಾಗದು.

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

RFC 2475 ವರ್ಗೀಕರಣ ಮತ್ತು ಕಂಡೀಷನಿಂಗ್ ಅನ್ನು ಆಡಳಿತಾತ್ಮಕ ಡೊಮೇನ್‌ಗಳ ಒಳಗೆ ಮಾಡುವ ಕೆಲಸವಾಗಿ ರೂಪಿಸುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಗುರುತು ಸರದಿಗಳನ್ನು ತುದಿಯಿಂದ ತುದಿಗೆ ಕಾಯ್ದಿರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. IOS XE ಶೆಡ್ಯೂಲಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ಮೇಲೆ ವಿವರಿಸಿದ ಹೆಚ್ಚುವರಿ-ತೂಕದ ನಡವಳಿಕೆಗೆ ಉಲ್ಲೇಖವಾಗಿದೆ, ಮತ್ತು ಮಾದರಿಗಳ ನಡುವೆ ಲೆಕ್ಕಹಾಕಿದ ದರವನ್ನು ಸರಿಸುವ ಮೊದಲು ಅದರ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಹೋಲಿಕೆಗಳನ್ನು ಓದುವುದು ಯೋಗ್ಯ.

ಒಪ್ಪಂದವನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಬರೆಯಿರಿ

ಸ್ಥಳೀಯ ಹೊಂದಾಣಿಕೆ, ನಂಬಿಕೆಯ ಗಡಿ, ಒದಗಿಸುವವರ ವರ್ಗ ಮತ್ತು ಅಳೆಯಲಾದ ಸೇವಾ ಮಟ್ಟವನ್ನು ಎರಡೂ ಪಕ್ಷಗಳು ಸಹಿ ಮಾಡುವ ಒಂದೇ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ. ಆಗ ಶೇಕಡಾವಾರು ಬದಲಾವಣೆಗೆ ಸಂದರ್ಭವಿದೆ, ಮತ್ತು ಗುಣಮಟ್ಟದ ದೂರಿಗೆ ಮಾಲೀಕನಿದ್ದಾನೆ.

ಸ್ಥಳೀಯ ಶೇಕಡಾವಾರನ್ನು ಬದಲಿಸುವುದು ಇನ್ನೊಂದು ಸರದಿಯ ಖಾತರಿಯನ್ನು ಸರಿಪಡಿಸಲಾರದು, ಮತ್ತು ಒದಗಿಸುವವರು ಗೌರವಿಸದ ಮ್ಯಾಪಿಂಗ್‌ನಿಂದ ಯಾವುದೇ ಗುರುತು ಯೋಜನೆ ಉಳಿಯುವುದಿಲ್ಲ. ಎರಡು ಅರ್ಧಗಳನ್ನು ಹೋಲಿಸಿ, ಗಡಿಗೆ ಹೆಸರಿಸಿ, ಮತ್ತು ಆಮೇಲೆ ಮಾತ್ರ ಸಂಖ್ಯೆಯನ್ನು ಉಲ್ಲೇಖಿಸಿ.