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

ನಿರ್ಧಾರ ಸೇವೆಯ ಮಾಲೀಕರದ್ದು; ಹೈಪರ್ವೈಸರ್ ಸಂರಚನೆ ಅದನ್ನು ಜಾರಿಗೊಳಿಸಬೇಕು, ಆಕಸ್ಮಿಕವಾಗಿ ನಿರ್ಧರಿಸಬಾರದು.

ದೂರದ ತುದಿಗೆ ನಿಜವಾಗಿ ಏನು ಬೇಕು ಎಂದು ಪರಿಶೀಲಿಸಿ

ದೂರದ ಕ್ಲೈಂಟ್‌ಗಳು ತಲುಪಬೇಕಾದ ಸೇವೆಗಳು ಮತ್ತು ಅವರು ಬಳಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಪಟ್ಟಿ ತಿಳಿದಿರುವ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ಮೇಲಿನ ಕೆಲವು TCP ಸೇವೆಗಳಾಗಿದ್ದರೆ, ರೂಟಿಂಗ್ ಸಾಕು. ಯಾವುದಾದರೂ ನಿಜವಾಗಿ ಲೇಯರ್ 2 ನೆರೆಹೊರೆ ಬೇಕಾದರೆ — ಬ್ರಾಡ್‌ಕಾಸ್ಟ್-ಅವಲಂಬಿತ ಅನ್ವೇಷಣೆ, ಐಪಿ-ಅಲ್ಲದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು, ಗೇಟ್‌ವೇಯನ್ನು ಸ್ವೀಕರಿಸದ ಸಾಧನ — ರೂಟಿಂಗ್ ಅದನ್ನು ಅನುಕರಿಸಲಾರದು ಮತ್ತು ಅದನ್ನು ಬೇಗ ಹೇಳಬೇಕು. ಆ ಪಟ್ಟಿಯ ಐಪಿ-ಅಲ್ಲದ ನಮೂದುಗಳ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕರಾಗಿರಿ, ಏಕೆಂದರೆ ಅಲ್ಲಿಯೇ ರೂಟೆಡ್ ವಿನ್ಯಾಸ ಒಂದು ವಾರದ ನಂತರ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ.

ನಂತರ ಕ್ಲೈಂಟ್ ಪೂಲ್ ಪರಿಶೀಲಿಸಿ. ರೂಟೆಡ್ ವಿನ್ಯಾಸಕ್ಕೆ ವಿಳಾಸ ಶ್ರೇಣಿ ಮತ್ತು ದೂರದ ಬದಿಯಲ್ಲಿ ಸ್ಪಷ್ಟ ಹಿಂತಿರುಗುವ ರೂಟ್ ಬೇಕು; ಬ್ರಿಡ್ಜ್‌ಡ್ ವಿನ್ಯಾಸಕ್ಕೆ ವಿಸ್ತರಿತ Ethernet ಡೊಮೇನ್ ವಿಳಾಸ ಹಂಚಿಕೆ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಹೊಂದಿರಬೇಕು. ನೀವು ಯಾವುದನ್ನು ಆರಿಸಿದರೂ, ಈ VM ಹೊರಗಿನ ಯಾರಾದರೂ ಅದಕ್ಕೆ ಒಪ್ಪಬೇಕು.

ಪ್ರತಿ ವಿನ್ಯಾಸ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಏನು ಕೇಳುತ್ತದೆ

ಎರಡು ವಿನ್ಯಾಸಗಳು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಏನನ್ನು ಸಹಿಸಬೇಕು ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ, ಮತ್ತು ಕೋಷ್ಟಕ ಅದನ್ನು ನೋಡುವ ಚಿಕ್ಕ ದಾರಿ:

ವಿನ್ಯಾಸಅತಿಥಿ ಬದಿಯ ಪಾತ್ರವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಏನನ್ನು ಇರಿಸಿಕೊಳ್ಳಬೇಕುತಪ್ಪಾಗಿ ಆರಿಸಿದರೆ ವೈಫಲ್ಯದ ಮಾದರಿ
ರೂಟೆಡ್ TUNಪ್ರತ್ಯೇಕ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ನಡುವಿನ ರೂಟರ್ರೂಟೆಡ್ ಕ್ಲೈಂಟ್ ಪೂಲ್ ಮತ್ತು ದೂರದ ಬದಿಯಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗಗಳುಕ್ಲೈಂಟ್‌ಗಳು ಗೇಟ್‌ವೇ ತಲುಪುತ್ತಾರೆ ಮತ್ತು ಅದರ ಹಿಂದಿನ ಸೇವೆಯನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ
ಬ್ರಿಡ್ಜ್‌ಡ್ TAPಸೇರುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಲೇಯರ್ 2 ಬ್ರಿಡ್ಜ್ಹೆಚ್ಚುವರಿ Ethernet ಗುರುತುಗಳು, ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಸಂಚಾರ ಮತ್ತು VLAN ನಿಯಮಗಳುvSwitch ಫ್ರೇಮ್‌ಗಳನ್ನು ಬಿಡುತ್ತದೆ, ಅಥವಾ ವಿನ್ಯಾಸಕ್ಕೆ ಯಾರೂ ಅನುಮೋದಿಸದ promiscuous ಮೋಡ್ ಬೇಕು

ರೂಟಿಂಗ್ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್ ಅನ್ನು ಅದರ ಜಾಗದಲ್ಲೇ ಬಿಡುತ್ತದೆ ಮತ್ತು ಗೇಟ್‌ವೇ ದಾಟುವ ಸೇವೆಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಲು ಸಹಜ ಜಾಗ ನೀಡುತ್ತದೆ. ಬ್ರಿಡ್ಜಿಂಗ್ ಗಡಿಯನ್ನು ಸರಿಸುತ್ತದೆ: ಕ್ಲೈಂಟ್‌ಗಳು ವಿಸ್ತರಿತ Ethernet ಡೊಮೇನ್‌ನ ಭಾಗಿಗಳಾಗುತ್ತಾರೆ, ಮತ್ತು ವಿಳಾಸ ಹಂಚಿಕೆ, ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ಯಾವುದೇ ಲೇಯರ್ 2 ನೀತಿ ಈಗ ಅವರಿಗೆ ಅನ್ವಯವಾಗುತ್ತದೆ. ಆಯ್ಕೆ ಮಾಡಿದ ಸಾಲನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಗೆ ಬರೆಯಿರಿ. “ರೂಟೆಡ್ TUN, ಕ್ಲೈಂಟ್ ಪೂಲ್ 10.90.0.0/24, ಕೋರ್‌ನಲ್ಲಿ ಹಿಂತಿರುಗುವ ರೂಟ್” ಎಂಬ ವಾಕ್ಯ ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಪೋರ್ಟ್-ಗುಂಪು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಂದ ವಿನ್ಯಾಸವನ್ನು ಮತ್ತೆ ಚರ್ಚಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಯಾರ ಫ್ರೇಮ್‌ಗಳನ್ನು ಯಾರು ನೋಡಬಹುದು

ಪೋರ್ಟ್ ಗುಂಪನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಾಲೀಕರನ್ನು ಒಂದು ಪ್ರಶ್ನೆ ಕೇಳಿ: ಈ VM ಇತರ ಭಾಗಿಗಳಿಗೆ ಉದ್ದೇಶಿಸಿದ ಫ್ರೇಮ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕೆಂದು ವಿನ್ಯಾಸ ಬಯಸುತ್ತದೆಯೇ? ಉತ್ತರ ಇಲ್ಲ ಎಂದಾದರೆ, ಈ ವಿಭಾಗದಲ್ಲಿ ಏನೂ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ರೂಟೆಡ್ TUN ಗೆ ಆ ಗೋಚರತೆ ಎಂದಿಗೂ ಬೇಕಿಲ್ಲ. ಉತ್ತರ ಹೌದು ಎಂದಾದರೆ, promiscuous ಮೋಡ್ ಬಗ್ಗೆ Broadcom ಮಾರ್ಗದರ್ಶನ ಮುಖ್ಯ ಓದು: VM vSwitch ನಿಂದ ಎಷ್ಟು ಹೆಚ್ಚು ನೋಡಬಹುದು ಎಂದು ಅದು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಆ ನೀತಿಯನ್ನು ಒಂದು ಪೋರ್ಟ್ ಗುಂಪಿಗೆ ಸೀಮಿತಗೊಳಿಸಲು ಸೂಚಿಸುತ್ತದೆ.

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

ಯಾವ ಪೋರ್ಟ್ ಗುಂಪು ಬದಲಾಯಿತು ಮತ್ತು ಏಕೆ ಎಂದು ವಿನ್ಯಾಸ ಸಾಲನ್ನು ಬರೆದ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸಿ. ಆ ಜೋಡಿಯೇ ಮುಂದಿನ ಆಡಿಟ್ ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ಅತಿಥಿಯ ವಸ್ತುಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ

Linux ಒಳಗೆ, ಬ್ರಿಡ್ಜ್ ಸದಸ್ಯತ್ವ ಮತ್ತು ವಿಳಾಸ ಮಾಲೀಕತ್ವ ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳು, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ಗೊಂದಲಮಯ ಅರ್ಧ-ಕೆಲಸ ಮಾಡುವ ಸ್ಥಿತಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ವಿಳಾಸಗಳನ್ನು ಬ್ರಿಡ್ಜ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಅಥವಾ ರೂಟೆಡ್ ಟನೆಲ್‌ಗೆ ನೀಡಿ, ಒಂದೇ ಮಾರ್ಗದ ಎರಡೂ ಬದಿಗಳಿಗೆ ಅಲ್ಲ, ಮತ್ತು ಸದಸ್ಯ ಪೋರ್ಟ್‌ಗಳನ್ನು IP ಸಂರಚನೆಯಿಂದ ಮುಕ್ತವಾಗಿರಿಸಿ.

ಒಂದು ಸಬ್‌ನೆಟ್ ಅನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ರೂಟೆಡ್ TUN ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ Ethernet ಇಂಟರ್‌ಫೇಸ್ ಎರಡರ ಮೇಲೂ ಇಡುವುದನ್ನು ತಪ್ಪಿಸಿ. ಆ ಸಂರಚನೆ ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಎರಡು ಮಾರ್ಗಗಳು ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅಸಮಮಿತಿ ಉತ್ತರಗಳು ಮತ್ತು flapping ಬಗ್ಗೆ ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಉಲ್ಲೇಖಿಸದ ಬೆಂಬಲ ಥ್ರೆಡ್. ಅತಿಥಿ ಕಂಟೇನರ್‌ಗಳು ಅಥವಾ ಸ್ಥಳೀಯ ಹೈಪರ್ವೈಸರ್ ಅನ್ನು ಸಹ ಹೋಸ್ಟ್ ಮಾಡಿದರೆ, ಅವು ಈಗಾಗಲೇ ಅದೇ uplink ಗೆ ಬ್ರಿಡ್ಜ್ ಆಗುತ್ತಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಒಂದು NIC ಮೇಲೆ ಎರಡು ಬ್ರಿಡ್ಜ್‌ಗಳು ವಿನ್ಯಾಸ, ಬದಲಾವಣೆ ವಿಂಡೋದಲ್ಲಿ ಕಂಡುಹಿಡಿಯಲು ಬಯಸದ ಅಪಘಾತವಲ್ಲ.

ping ಅಲ್ಲ, ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗದಿಂದ ದೃಢೀಕರಿಸಿ

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

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು