VPN ಗೇಟ್‌ವೇ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಹೊಂದಿಕೆಯಾಗದಿರುವಿಕೆ: ಎರಡೂ ತುದಿಗಳನ್ನು ಓದಿ

ಟನೆಲ್ ಮೂಲಕ ಫೈಲ್ ನಕಲು ಒಂದು ಸೆಕೆಂಡು ನಿಲ್ಲುತ್ತದೆ, ಮತ್ತೆ ಮುಂದುವರಿಯುತ್ತದೆ, ಮತ್ತು VPN ಲಾಗ್‌ಗಳು ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ನೆಟ್‌ವರ್ಕ್‌ನ್ನು ದೂಷಿಸುತ್ತದೆ, ನೆಟ್‌ವರ್ಕ್ ಅಪ್ಲಿಕೇಶನ್‌ನ್ನು ದೂಷಿಸುತ್ತದೆ, ಮತ್ತು ಸ್ವಿಚ್ ಪೋರ್ಟ್ ಹನ್ನೊಂದು ತಿಂಗಳಿನಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಈ ಮಾರ್ಗದರ್ಶಿ ನಿಲುಗಡೆಯಿಂದ ಪ್ರಾರಂಭವಾಗಿ ಭೌತಿಕ ಲಿಂಕ್‌ವರೆಗೆ ಹೊರಮುಖವಾಗಿ ಸಾಗುತ್ತದೆ: ಪೋರ್ಟ್ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತಿದೆ, ದೂರದ ತುದಿ ಏನು ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ನೀವು ನೋಡುತ್ತಿದ್ದಾಗ ಕೌಂಟರ್‌ಗಳು ಏನು ಮಾಡಿದವು. ಯಾರಾದರೂ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಸೆಟ್ಟಿಂಗ್ ಮುಟ್ಟುವ ಮೊದಲು ಇದನ್ನು ಮಾಡುವುದು ಯೋಗ್ಯ.

ಪೋರ್ಟ್‌ನಿಂದಲ್ಲ, ನಿಲುಗಡೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಲಕ್ಷಣವನ್ನು ಪರೀಕ್ಷಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ವಿವರಿಸಿ. ದೊಡ್ಡ ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಸುಮಾರು ಒಂದು ಸೆಕೆಂಡಿನ ನಿಲುಗಡೆ ಮರುಹೊಂದಿಸುವ ಸಂಪರ್ಕಕ್ಕಿಂತ ಬೇರೆ ಸಮಸ್ಯೆ, ಮತ್ತು ಗಂಟೆಗೆ ಒಮ್ಮೆ ಸಂಭವಿಸುವ ವಿರಾಮ ಪ್ರತಿ ಕೆಲವು ಸೆಕೆಂಡಿಗೆ ಸಂಭವಿಸುವ ವಿರಾಮಕ್ಕಿಂತ ಭಿನ್ನ. ಕೆಲಸದ ಹೊರೆ, ದಿಕ್ಕು ಮತ್ತು ಅಂದಾಜು ಮಧ್ಯಂತರವನ್ನು ಬರೆಯಿರಿ.

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

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

ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಕಾರ್ಯಾಚರಣಾ ಮೋಡ್ ಓದಿ

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

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

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

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

10/100 ಅರ್ಧ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಪ್ರಕರಣ ಹೇಗೆ ಕಾಣುತ್ತದೆ

10/100 ತಾಮ್ರದ ಲಿಂಕ್‌ಗಳಲ್ಲಿ, ಸ್ವಯಂ ಮಾತುಕತೆ ಮಾಡುವ ತುದಿ ಬಲವಂತವಾಗಿ ಹೊಂದಿಸಿದ ಸಹಭಾಗಿಯ ವೇಗವನ್ನು ಅದರ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಸೆಟ್ಟಿಂಗ್ ತಿಳಿಯದೆ ಪತ್ತೆಹಚ್ಚಬಹುದು. ಸಮಾನಾಂತರ ಪತ್ತೆ ಸಿಗ್ನಲ್‌ನಿಂದ ವೇಗವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಮಾತುಕತೆಯ ಬದಲು ಊಹಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ಬದಿ ಅರ್ಧ ಡ್ಯುಪ್ಲೆಕ್ಸ್‌ನಲ್ಲಿ ಉಳಿಯಬಹುದು ಮತ್ತು ಇನ್ನೊಂದು ಪೂರ್ಣದಲ್ಲಿ ನಡೆಯುತ್ತದೆ.

Cisco ನ ಸ್ವಯಂ ಮಾತುಕತೆ ಮಾರ್ಗಸೂಚಿ ಆ ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲೆಡೆ ಮಾತುಕತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ವಾದವಲ್ಲ, ಮತ್ತು ಗಿಗಾಬಿಟ್ ತಾಮ್ರದ ಬಗ್ಗೆ ಉಪಯುಕ್ತವಾದ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಅಲ್ಲಿ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು ಲಿಂಕ್ ಎದ್ದೇಳಲು ಸ್ವಯಂ ಮಾತುಕತೆ ಅಗತ್ಯ.

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

ಎರಡೂ ತುದಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಬದಲಾಯಿಸಿ, ಹಿಂತಿರುಗುವ ದಾರಿಯೊಂದಿಗೆ

ಡ್ಯುಪ್ಲೆಕ್ಸ್ ತಿದ್ದುಪಡಿ ಸಂಯೋಜಿತ ಬದಲಾವಣೆ, ಸ್ಥಳೀಯವಲ್ಲ. ದೂರದ ತುದಿಯ ಒಪ್ಪಿಗೆಯಿಲ್ಲದೆ ನಿಮ್ಮ ಬದಿಯನ್ನು ಬಲವಂತಪಡಿಸುವುದು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಲಿಂಕ್ ಮುರಿದ ಲಿಂಕ್ ಆಗುವ ದಾರಿ, ಮತ್ತು CLI ಆಜ್ಞೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದು ಸಿಂಟ್ಯಾಕ್ಸ್ ಮಾನ್ಯವಾಗಿತ್ತು ಎಂದಷ್ಟೇ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

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

ಅನೇಕ ಆಧುನಿಕ ಲಿಂಕ್‌ಗಳಲ್ಲಿ ಸರಿಯಾದ ಉತ್ತರವೆಂದರೆ ಏನನ್ನೂ ಬಲವಂತಪಡಿಸುವ ಬದಲು ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಸ್ವಯಂ ಮಾತುಕತೆಯನ್ನು ಆನ್ ಆಗಿರಲು ಬಿಡುವುದು. ಬಲವಂತಪಡಿಸುವುದು ನಿರ್ದಿಷ್ಟ ತಂತ್ರಜ್ಞಾನದ ನಿರ್ದಿಷ್ಟ ಹೊಂದಿಕೆಯಾಗದಿರುವಿಕೆಗೆ ಒಂದು ಪರಿಹಾರ, ಸಾಮಾನ್ಯ ಸುಧಾರಣೆಯಲ್ಲ. ವಿಶೇಷವಾಗಿ ಗಿಗಾಬಿಟ್ ತಾಮ್ರ ಲಿಂಕ್ ಎದ್ದೇಳಲು ಸ್ವಯಂ ಮಾತುಕತೆ ಬೇಕು, ಆದ್ದರಿಂದ 10/100 ಸಲಹೆ ಅಲ್ಲಿಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.

ಕೌಂಟರ್‌ಗಳು ಉತ್ತಮ ದಿಕ್ಕಿನಲ್ಲಿ ಚಲಿಸಿದವೆಂದು ಖಚಿತಪಡಿಸಿ

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

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

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

ಬದಲಾವಣೆಗೆ ಮೊದಲು ಮತ್ತು ನಂತರದ ಸಂಖ್ಯೆಗಳನ್ನು ಸಮಯ ಮುದ್ರೆಗಳೊಂದಿಗೆ ಟಿಕೆಟ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ. ಆ ದಾಖಲೆಯೇ «VPN ಉತ್ತಮವಾಗಿ ಅನಿಸುತ್ತಿದೆ» ಎಂಬುದನ್ನು ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ನಿರ್ಮಿಸಬಹುದಾದ ಯಾವುದೋ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.