ಪ್ರತಿ VRF ಗೆ ಒಂದು ಲೇಬಲ್ ಅಥವಾ ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದು? ನಿಜವಾದ ಸಾಮರ್ಥ್ಯದ ಬಿಲ್
ಪ್ರತಿ VRF ಗೆ ಒಂದು ಲೇಬಲ್ ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದಕ್ಕಿಂತ ಅಗ್ಗವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಬಜೆಟ್ನಲ್ಲಿ ಲೇಬಲ್ಗಳ ಸಂಖ್ಯೆ ಅತಿ ಚಿಕ್ಕ ಸಾಲು. ನಿಜವಾಗಿ ಮೊದಲು ಏನು ಖಾಲಿಯಾಗುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.
ಎರಡು ವಿನ್ಯಾಸಗಳು ಒಂದೇ ಪ್ರೊವೈಡರ್ ಕೋರ್ನಲ್ಲಿ ಒಂದೇ ಗ್ರಾಹಕ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಜಾಹೀರಾತು ಮಾಡುತ್ತವೆ. ಒಂದು ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದು ಲೇಬಲ್ ಹಂಚುತ್ತದೆ, ಇನ್ನೊಂದು ಇಡೀ VRF ಗೆ ಒಂದೇ ಲೇಬಲ್ ಹಂಚುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಪ್ರತಿ ಸ್ಲೈಡ್ನಲ್ಲೂ ಅಗ್ಗವಾಗಿ ಕಾಣುತ್ತದೆ. ಲೇಬಲ್ಗಳ ಸಂಖ್ಯೆ ನಿಜವಾದದ್ದು, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲು ಖಾಲಿಯಾಗುವ ಬಜೆಟ್ ಅದಲ್ಲ. ಎರಡರ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಎಂದರೆ ನಾಲ್ಕು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಎಣಿಸುವುದು, ಒಂದಲ್ಲ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಲೇಬಲ್ಗಳು ಅತಿ ಚಿಕ್ಕವು.
ಲೇಬಲ್ ತೆಗೆದ ನಂತರ ನಿರ್ಗಮನ ರೌಟರ್ ಪ್ಯಾಕೆಟ್ನೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು ಎಂಬುದರ ಮೇಲೂ ಆಯ್ಕೆ ಅವಲಂಬಿತವಾಗಿದೆ. ನಿರ್ಧಾರವನ್ನು ಆ ಕ್ರಿಯಾತ್ಮಕ ವ್ಯತ್ಯಾಸವೇ ಮುನ್ನಡೆಸಬೇಕು, ಲೇಬಲ್ಗಳ ಅಂಕಗಣಿತವಲ್ಲ.
ಪ್ರತಿ ಹಂಚಿಕೆ ನಿಜವಾಗಿ ಏನನ್ನು ಉಳಿಸುತ್ತದೆ
ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಇರುವ ಹಂಚಿಕೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಲೇಬಲ್ನಲ್ಲಿ ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ. ನಿರ್ಗಮನ ರೌಟರ್ ಗಮ್ಯಸ್ಥಾನದ ಹುಡುಕಾಟವಿಲ್ಲದೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನೇರವಾಗಿ ಸರಿಯಾದ ನೆರೆಹೊರೆಗೆ ಕಳುಹಿಸಬಹುದು, ಆದ್ದರಿಂದ ಅದು ದೊಡ್ಡ VRF ರೂಟ್ ಸೆಟ್ಗಳಿಗೆ ಚೆನ್ನಾಗಿ ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಪ್ರತಿ VRF ನಲ್ಲಿ ಪ್ರತಿ ಜಾಹೀರಾತು ಮಾಡಿದ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದು ಲೇಬಲ್ ಖರ್ಚು ಮಾಡುತ್ತದೆ. ಪ್ರತಿ VRF ಗೆ ಇರುವ ಹಂಚಿಕೆ, ಉದಾಹರಣೆಗೆ Junos vrf-table-label, ಪ್ರತಿ ರೂಟಿಂಗ್ ಇನ್ಸ್ಟೆನ್ಸ್ಗೆ ಒಂದು ಲೇಬಲ್ ಜಾಹೀರಾತು ಮಾಡುತ್ತದೆ ಮತ್ತು VRF ಟೇಬಲ್ ಆಯ್ಕೆ ಮಾಡಲು ಆ ಲೇಬಲ್ ಬಳಸುತ್ತದೆ; ನಂತರ ರೌಟರ್ ಟೇಬಲ್ ಒಳಗೆ IP ಹುಡುಕಾಟ ಮಾಡುತ್ತದೆ.
ಅದು ಟ್ಯೂನಿಂಗ್ ನಾಬ್ ಅಲ್ಲ, ನಿಜವಾದ ವಾಸ್ತುಶಿಲ್ಪದ ವ್ಯತ್ಯಾಸ. ಪ್ರತಿ VRF ಗೆ ಲೇಬಲಿಂಗ್ ನಿಮಗೆ ಚಿಕ್ಕ ಲೇಬಲ್ ಸ್ಥಳ ಮತ್ತು ಸರಳ ಲೇಬಲ್ ಜಾಹೀರಾತು ನೀಡುತ್ತದೆ, ಒಂದು ಹುಡುಕಾಟ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳದ ಲೇಬಲ್ನ ಬೆಲೆಗೆ. ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಲೇಬಲಿಂಗ್ ನಿರ್ಗಮನ ಲೈನ್ ಕಾರ್ಡ್ಗೆ ಮೊದಲೇ ಹೆಚ್ಚು ಮಾಹಿತಿ ನೀಡುತ್ತದೆ ಮತ್ತು ನೀವು ಹೊತ್ತುಕೊಳ್ಳುವ ರೂಟ್ಗಳ ಅನುಪಾತದಲ್ಲಿ ಲೇಬಲ್ಗಳನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ.
ಲೇಬಲ್ ಖಾತೆ ಪುಸ್ತಕ ಚಿಕ್ಕದು
MPLS ಲೇಬಲ್ಗಳು ಸೀಮಿತ, ಆದರೆ ಲೇಬಲ್ ಸ್ಥಳವು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ ಎಂದರೆ ಸಾಮಾನ್ಯ ಸೇವಾ ಪೂರೈಕೆದಾರರು ಕೆಲವು ಸಾವಿರ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಂದ ಅದನ್ನು ಖಾಲಿ ಮಾಡುವುದಿಲ್ಲ. ಪ್ರತಿ VRF ಗೆ ಲೇಬಲಿಂಗ್ ನಿಜವಾಗಿ ಸಹಾಯ ಮಾಡುವ ಸ್ಥಳ ಎಂದರೆ ಚಿಕ್ಕ ಹಾರ್ಡ್ವೇರ್ ಲೇಬಲ್ ಟೇಬಲ್ಗಳಿರುವ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು, ಅಥವಾ ಒಂದು VRF ಇಡೀ ಇಂಟರ್ನೆಟ್ ಫೀಡ್ ಹೊತ್ತುಕೊಳ್ಳುವ ಮತ್ತು ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಲೇಬಲ್ಗಳು ಲೇಬಲ್ ಬೇಡಿಕೆಯನ್ನು ರೂಟ್ ಸಂಖ್ಯೆಯಿಂದ ಗುಣಿಸುವ ವಿನ್ಯಾಸಗಳು. ಇವು ನಿಜವಾದ ಮಿತಿಗಳು, ಮತ್ತು ಈ ವೈಶಿಷ್ಟ್ಯ ಇರುವುದಕ್ಕೆ ಅವೇ ಕಾರಣ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಟೇಬಲ್ನಲ್ಲಿರುವ ಪ್ರಿಫಿಕ್ಸ್ಗಳ ಸಂಖ್ಯೆಯ ಬಗ್ಗೆ ಅಲ್ಲ.
ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಸೇವೆ ಮತ್ತು ಸಾಗಣೆ ಎರಡಕ್ಕೂ ಲೇಬಲ್ಗಳನ್ನು ಎಣಿಸಿ. ಪ್ರತಿ VRF ಗೆ ಇರುವ ವಿನ್ಯಾಸಕ್ಕೆ loopback ಗಳಿಗೆ ಮತ್ತು ಮಾರ್ಗದ ಪ್ರತಿ ಹಾಪ್ಗೆ ಸಾಗಣೆ ಲೇಬಲ್ಗಳು ಇನ್ನೂ ಬೇಕು, ಮತ್ತು ಅದಕ್ಕೆ ನೆರೆಹೊರೆ ಸ್ಥಿತಿ ಇನ್ನೂ ಬೇಕು. ವಿನ್ಯಾಸದ ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆ ಸೇವಾ ಲೇಬಲ್ಗಳನ್ನು ಮಾತ್ರ ಎಣಿಸಿದರೆ, ಉಳಿತಾಯವನ್ನು ತಪ್ಪು ಖಾತೆ ಪುಸ್ತಕದಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತಿದೆ.
ರೂಟ್ ಫೀಡ್ಗಳು ಲೇಬಲ್ಗಳ ಮೊದಲು ಮೆಮೊರಿ ಖರ್ಚು ಮಾಡುತ್ತವೆ
ಸ್ವೀಕರಿಸಿದ ಪ್ರತಿ ಮಾರ್ಗವೂ ನಿಯಂತ್ರಣ ಸಮತಲದ ಮೆಮೊರಿ, ನವೀಕರಣ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಒಮ್ಮುಖ ಸಮಯವನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ, VRF ಒಂದು ಲೇಬಲ್ ಬಳಸಲಿ ಅಥವಾ ಹತ್ತು ಸಾವಿರ. VRF ಒಳಗಿನ ಪೂರ್ಣ ಇಂಟರ್ನೆಟ್ ಫೀಡ್ BGP ಮಾರ್ಗಗಳು, RIB, FIB ನಮೂದುಗಳು ಮತ್ತು ಅವುಗಳ ಹಿಂದಿನ ಚಡಪಡಿಕೆಯಿಂದ ದುಬಾರಿ, ಟೇಬಲ್ನ ಮುಂದೆ ಇರುವ ಲೇಬಲ್ನಿಂದ ಅಲ್ಲ. ಅದೇ ಫೀಡ್ ಆ ಬಾಡಿಗೆದಾರನ ಒಳಗೆ ರೂಟ್ ಸೋರಿಕೆ ಅಥವಾ ನೀತಿ ತಪ್ಪಿನ ಪ್ರಭಾವದ ವ್ಯಾಪ್ತಿಯನ್ನೂ ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಆದ್ದರಿಂದ ಗ್ರಾಹಕನಿಗೆ ನಿಜವಾಗಿ ಏನು ಬೇಕು ಎಂದು ಕೇಳಿ. ಒಪ್ಪಂದವು ಖಾಸಗಿ ಸೈಟ್ಗಳು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ನಿರ್ಗಮನವಾಗಿದ್ದರೆ, ಪೂರ್ಣ ಟೇಬಲ್ ಅಗತ್ಯವನ್ನು ಸೇರಿಸದೆ ವೆಚ್ಚವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅದು ವಾಣಿಜ್ಯ ಪ್ರಶ್ನೆ, ಮತ್ತು ಅದು ಹಿಂದಿನ ವಿನ್ಯಾಸದಿಂದ ಬಂದ ಊಹೆಗಿಂತ ಬರೆಯಲಾದ ಉತ್ತರಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ. ಸೇವೆಗೆ ನೀತಿಗಾಗಿ ಅಥವಾ ಸ್ಥಳೀಯ ನಿರ್ಗಮನ ಆಯ್ಕೆಗಾಗಿ ಫೀಡ್ ನಿಜವಾಗಿ ಬೇಕಿದ್ದರೆ, ಅದನ್ನು ತನ್ನದೇ ಸಾಮರ್ಥ್ಯ ಕಾಯ್ದಿರಿಸುವಿಕೆ ಮತ್ತು ತನ್ನದೇ ವೈಫಲ್ಯ ವರ್ತನೆಯೊಂದಿಗೆ ಸ್ಪಷ್ಟ ಸಾಲಿನ ಐಟಂ ಮಾಡಿ.
ಪ್ರತಿ VRF ಗೆ ಲೇಬಲಿಂಗ್ ಯಾವಾಗ ಸರಿಯಾದ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ
ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಅದನ್ನು ಬೆಂಬಲಿತ ಎಂದು ದಾಖಲಿಸಿದಾಗ, VRF ರೂಟ್ಗಳ ಸಂಖ್ಯೆ ದೊಡ್ಡದಾದಾಗ ಮತ್ತು ನಿರ್ಗಮನದ ಹುಡುಕಾಟ ವೆಚ್ಚ ಟ್ರಾಫಿಕ್ ಪ್ರೊಫೈಲ್ಗೆ ಸ್ವೀಕಾರಾರ್ಹವಾದಾಗ ಅದು ಉತ್ತಮ ಡೀಫಾಲ್ಟ್. ಫಾರ್ವರ್ಡಿಂಗ್ನಿಂದ ಕೊನೆಯ ಮೈಕ್ರೋಸೆಕೆಂಡ್ ಹಿಂಡುವುದಕ್ಕಿಂತ ಕಾರ್ಯಾಚರಣೆಯ ಸರಳತೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾದಾಗಲೂ ಅದು ಸ್ವಾಭಾವಿಕ ಆಯ್ಕೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಬಾಡಿಗೆದಾರನಿಗೆ ಒಂದು ಲೇಬಲ್ ಅನ್ನು ವಿವರಿಸಲು ಮತ್ತು ಪರಿಶೀಲಿಸಲು ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದು ಲೇಬಲ್ಗಿಂತ ಸುಲಭ.
ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ದಾಖಲೆ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟ ಹಾರ್ಡ್ವೇರ್ ಅಥವಾ ಬಿಡುಗಡೆ ಮಿತಿಗಳಿಗೆ ಕಟ್ಟಿದಾಗ, ಅಥವಾ ವಿನ್ಯಾಸವು ನಿರ್ಗಮನದಲ್ಲಿ ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಧಾರಗಳನ್ನು ಅವಲಂಬಿಸಿದಾಗ ಅದು ತಪ್ಪು ಡೀಫಾಲ್ಟ್. ವರ್ತನೆಯನ್ನು ಊಹಿಸುವ ಮೊದಲು ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಸ್ವಂತ statement ಉಲ್ಲೇಖವನ್ನು ಓದಿ; Junos ಆಜ್ಞೆ ದಾಖಲಾಗಿದೆ, ಆದರೆ ಅದರ ಸುತ್ತಲಿನ ಹಾರ್ಡ್ವೇರ್ ಮತ್ತು ಬಿಡುಗಡೆ ಮಿತಿಗಳೇ ನಿಯೋಜನೆಯನ್ನು ನಿಜವಾಗಿ ನಿರ್ಧರಿಸುತ್ತವೆ.
ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಬಜೆಟ್
ಸಾಮರ್ಥ್ಯದ ಪ್ರಕರಣವನ್ನು ಐದು ಪ್ರತ್ಯೇಕ ಸಂಖ್ಯೆಗಳಾಗಿ ನಿರ್ಮಿಸಿ: ಸ್ವೀಕರಿಸಿದ ಮಾರ್ಗಗಳು, ಆಯ್ದ ರೂಟ್ಗಳು, ಸ್ಥಾಪಿಸಿದ ಫಾರ್ವರ್ಡಿಂಗ್ ನಮೂದುಗಳು, ಸೇವಾ ಲೇಬಲ್ಗಳು ಮತ್ತು ಸಾಗಣೆ ಲೇಬಲ್ಗಳು. next-hop ಮತ್ತು ನೆರೆಹೊರೆ ಸ್ಥಿತಿ, ಬಾಡಿಗೆದಾರರ ಸಂಖ್ಯೆ ಮತ್ತು ಪುನರಾವರ್ತನ ಮಾದರಿಯನ್ನು ಸೇರಿಸಿ. ಒಂದು VRF ನ ಸುಗಮ ಮಾರ್ಗದ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಸ್ಕೇಲ್ ಅಂಕಿ ಅಲ್ಲ, ಮತ್ತು ಲೇಬಲ್ ಸ್ಥಳದ ನಾಮಮಾತ್ರ ಗಾತ್ರ ಲಭ್ಯವಿರುವ ಹಾರ್ಡ್ವೇರ್ ಟೇಬಲ್ ಅಲ್ಲ.
ನಂತರ ಸ್ಥಿರ ಸ್ಥಿತಿಯೊಂದಿಗೆ ವೈಫಲ್ಯ ಮೋಡ್ ಬಗ್ಗೆಯೂ ಒಪ್ಪಿಗೆ ತಲುಪಿ. ಫೀಡ್ ಅರ್ಧದಷ್ಟು ಬೆಳೆದಾಗ, ಬಾಡಿಗೆದಾರ ಎರಡನೇ VRF ಸೇರಿಸಿದಾಗ, ಅಥವಾ ಟೇಬಲ್ನ ಗಾತ್ರ ಬದಲಿಸಲು ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗೆ ರೀಬೂಟ್ ಬೇಕಾದಾಗ ಏನಾಗುತ್ತದೆ? ಆ ಪ್ರಶ್ನೆಗಳನ್ನು ತಾಳಿಕೊಳ್ಳುವ ಬಜೆಟ್ ಕಾಗದದ ಮೇಲೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಲೇಬಲ್ ಎಣಿಕೆಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದ್ದು.
ನಿರ್ಗಮನ ಕ್ರಿಯೆ ಮತ್ತು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮಿತಿಗಳಿಂದ ಹಂಚಿಕೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ನಂತರ ರೂಟ್ ಫೀಡ್ ಅನ್ನು ಸ್ಪಷ್ಟ ಸೇವಾ ನಿರ್ಧಾರವಾಗಿ ಮಾಡಿ. ಲೇಬಲ್ ವಿನ್ಯಾಸದ ಗೋಚರ ಭಾಗ; ರೂಟ್ಗಳು ಪ್ರತಿದಿನ ಪಾವತಿಸಬೇಕಾದ ಭಾಗ.