ದೊಡ್ಡ ನಕ್ಷತ್ರ-ಆಕಾರದ VPN ಗಾತ್ರ ನಿರ್ಧಾರ: BGP ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಎಣಿಸಿ
ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಸುಲಭ ಸಂಖ್ಯೆ. ಸೆಷನ್‌ಗಳು, ಅಪ್‌ಡೇಟ್ ಪ್ರವಾಹ ಮತ್ತು ಹಬ್ ವೈಫಲ್ಯದ ನಂತರದ ಚೇತರಿಕೆ ಕೆಲವು ಸಾವಿರ ಶಾಖೆಗಳಲ್ಲಿ ವಿನ್ಯಾಸ ನಿಲ್ಲುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ.
ಮೂರು ಸಾವಿರ ಶಾಖೆಗಳು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯಂತೆ ಕೇಳಿಸುತ್ತವೆ, ಆದರೆ ಲೆಕ್ಕಪತ್ರದ ಸಮಸ್ಯೆಯಂತೆ ವರ್ತಿಸುತ್ತವೆ. ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ಒಟ್ಟು ಮೊತ್ತ ಹತ್ತು ನಿಮಿಷಗಳಲ್ಲಿ ಲೆಕ್ಕಕ್ಕೆ ಬರುತ್ತದೆ, ಮತ್ತು ನೋವು ಕೊಡುವ ಸಂಖ್ಯೆ ಅದು ಅಪರೂಪ. ನೋವು ಕೊಡುವುದು ಪ್ರತಿ ಸೆಷನ್ ಕೆಲಸ, ಹಂಚಿಕೆಯ ಘಟಕ ವಿಫಲವಾದಾಗ ಅಪ್‌ಡೇಟ್‌ಗಳ ಪ್ರವಾಹ, ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಹೊಸ ಟೋಪಾಲಜಿಗೆ ಮತ್ತೆ ಹೊಂದಿಕೆಯಾಗಲು ಬೇಕಾಗುವ ಸಮಯ.
ಆದ್ದರಿಂದ ಅಂಕಗಣಿತವನ್ನು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ನಡೆಸಿ. ಸಂಬಂಧಗಳನ್ನು ಎಣಿಸಿ, ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಮತ್ತು ಪರ್ಯಾಯಗಳನ್ನು ಎಣಿಸಿ, ನಂತರ ಕೆಟ್ಟ ಗಂಟೆಯಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂದು ಎಣಿಸಿ, ಮತ್ತು ಅದರ ನಂತರವೇ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳನ್ನು ಹೋಲಿಸಿ. ಬೇರೆ ಕ್ರಮದಲ್ಲಿ ಈ ಅಭ್ಯಾಸ ರೂಟ್ ಮಿತಿಗಳ ಬಗ್ಗೆ ಚರ್ಚೆಯಾಗುತ್ತದೆ, ಮೇಜಿನ ಮೇಲಿನ ಮಾಹಿತಿಯಿಂದ ಯಾರೂ ಪರಿಹರಿಸಲಾಗದು.
ನಾಲ್ಕು ಬಜೆಟ್‌ಗಳು, ಒಂದಲ್ಲ
ಪ್ರತಿ ಬಜೆಟ್ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ನಿರ್ಬಂಧಕವಾಗಬಹುದು. ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬರೆಯುವುದು ಒಂದು ದೊಡ್ಡ ಪ್ರಿಫಿಕ್ಸ್ ಸಂಖ್ಯೆ ಇಡೀ ವಿನ್ಯಾಸದ ಸ್ಥಾನ ತೆಗೆದುಕೊಳ್ಳದಂತೆ ತಡೆಯುತ್ತದೆ.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
ಕೊನೆಯ ಎರಡು ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಬಿಟ್ಟುಬಿಡುವಂಥವು. ಸ್ಥಿರ ಸ್ಥಿತಿಯಲ್ಲಿ ಮೆಮೊರಿಯಲ್ಲಿ ಆರಾಮವಾಗಿ ಕೂರುವ ನೆಟ್‌ವರ್ಕ್ ಕೂಡ ನಾನೂರು ಶಾಖೆಗಳು ಎರಡು ನಿಮಿಷಗಳಲ್ಲಿ ಮತ್ತೆ ಸೇರಿಕೊಂಡಾಗ ಕೆಟ್ಟದಾಗಿ ವರ್ತಿಸಬಹುದು, ಏಕೆಂದರೆ ಕೆಲಸ ನಿಯಂತ್ರಣ-ತಲ ಮತ್ತು ಖಾಲಿ ಮಾಡಬಲ್ಲದಕ್ಕಿಂತ ವೇಗವಾಗಿ ಬರುತ್ತದೆ. ಪ್ರವಾಹದ ಗಾತ್ರವನ್ನು ಸಂಖ್ಯೆಯಾಗಿ ಬರೆಯಿರಿ, ಸೇವೆ ಎಷ್ಟು ಕಾಲ ಕ್ಷೀಣಿಸಿರಬಹುದು ಎಂಬುದರೊಂದಿಗೆ. ಇದು ಅಸ್ಪಷ್ಟ ಆತಂಕವನ್ನು ಯಾರಾದರೂ ನಿಜವಾಗಿ ನಡೆಸಬಹುದಾದ ಪರೀಕ್ಷೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.
ನಾಲ್ಕರೊಳಗೂ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪ್ರಶ್ನೆ ಅಡಗಿದೆ: ಎನ್‌ಕ್ರಿಪ್ಷನ್, ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ರೂಟಿಂಗ್ ಒಂದೇ CPU ಹಂಚಿಕೊಳ್ಳುತ್ತವೆಯೇ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಮಾರ್ಗಗಳಿವೆಯೇ. ಒಂದೇ ರೂಟ್ ಸಾಮರ್ಥ್ಯವಿರುವ ಎರಡು ಸಾಧನಗಳು ಪ್ರವಾಹದಲ್ಲಿ ಬಹಳ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸಬಹುದು, ಮತ್ತು ಡೇಟಾಶೀಟ್ ನೀವು ಯಾವುದನ್ನು ಖರೀದಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಅಪರೂಪವಾಗಿ ಹೇಳುತ್ತದೆ.
ನಿಮ್ಮದೇ ಸಂಖ್ಯೆಗಳಿಂದ ಅಂಕಗಣಿತ ಮಾಡಿ
ಒಂದು ಕಾಲ್ಪನಿಕ ವಿನ್ಯಾಸ ತೆಗೆದುಕೊಳ್ಳಿ: 3,000 ಶಾಖೆಗಳು, ಒಟ್ಟುಗೂಡಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಮೂರು ಪ್ರಿಫಿಕ್ಸ್, ಮತ್ತು ಪುನರಾವರ್ತನೆಗಾಗಿ ಪ್ರತಿ ಶಾಖೆಗೆ ಎರಡು ಹಬ್‌ಗಳು. ಹಬ್ ಜೋಡಿ ಸಾರಾಂಶದ ಮೊದಲು ಸುಮಾರು 9,000 ಶಾಖಾ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಹಿಡಿಯಬೇಕು, ಮತ್ತು ಪ್ರತಿ ಶಾಖೆ ಎರಡರೊಂದಿಗೂ ಪೀರ್ ಆದರೆ ವಿನ್ಯಾಸ 6,000 ಶಾಖೆ-ಹಬ್ ಸೆಷನ್‌ಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಈಗ ಪ್ರಿಫಿಕ್ಸ್ ಅಲ್ಲದ ಭಾಗಗಳನ್ನು ಸೇರಿಸಿ. ಪ್ರತಿ ಸೆಷನ್ ಏನೂ ಬದಲಾಗದಿದ್ದರೂ ಸ್ಥಿತಿ ಮತ್ತು ಆವರ್ತಕ ಸಂದೇಶಗಳನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ. ವೇಗದ ಬದಲಾವಣೆ ನಿರೀಕ್ಷಿಸಿದರೆ ಪ್ರತಿ ಹಬ್ ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾರ್ಗ ಇಟ್ಟುಕೊಳ್ಳಬಹುದು, ಆದ್ದರಿಂದ ಪರ್ಯಾಯಗಳ ಸಂಖ್ಯೆ ಆಯ್ಕೆಯಾದ ಸಂಖ್ಯೆಯನ್ನು ಮೀರಬಹುದು. ಮತ್ತು ಪ್ರತಿ ಸ್ಪೋಕ್‌ನ ನೋಟ ಪ್ರತ್ಯೇಕ ನೀತಿ ನಿರ್ಣಯ: ಪ್ರತಿ ಶಾಖೆಗೆ ಉಳಿದೆಲ್ಲರ ರೂಟ್‌ಗಳನ್ನು ನೀಡುವುದು ಹಬ್-ಬದಿಯ ಎಣಿಕೆ ಬಯಲು ಮಾಡದ ರೀತಿಯಲ್ಲಿ ಕೆಲಸವನ್ನು ಗುಣಿಸುತ್ತದೆ.
ಇವು ವಿನ್ಯಾಸ ಸಂಭಾಷಣೆಗೆ ಯೋಜನಾ ಸಂಖ್ಯೆಗಳು, ಯಾವುದೇ ಉತ್ಪನ್ನದ ಅಳತೆ ಅಲ್ಲ. ಅಭ್ಯಾಸದ ಉಪಯುಕ್ತ ಫಲಿತಾಂಶ ವಕ್ರದ ಆಕಾರ, ನಿರ್ದಿಷ್ಟ ರೌಟರ್ ಎಲ್ಲಿ ಶರಣಾಗುತ್ತದೆ ಎಂಬ ಹೇಳಿಕೆ ಅಲ್ಲ.
BGP ನಿಮಗೆ ಏನು ಕೊಡುತ್ತದೆ, IGP ನಿಮಗೆ ಏನು ಕೊಡುತ್ತದೆ
BGP ರೌಟರ್ ಏನು ಸ್ವೀಕರಿಸಿತು, ಏನು ಆಯ್ಕೆ ಮಾಡಿತು ಮತ್ತು ಏನು ಘೋಷಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ನೀತಿಯಿಂದ ನಿಯಂತ್ರಿತ. ಶಾಖಾ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಅಗತ್ಯವಿರುವುದು ನಿಖರವಾಗಿ ಅದೇ, ಏಕೆಂದರೆ ಸ್ಪೋಕ್ ಸಾಮಾನ್ಯವಾಗಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ, ಕೇಂದ್ರ ಸೇವೆಗಳು ಮತ್ತು ಬಹಳ ಕಡಿಮೆ ಬೇರೆ ಏನನ್ನೋ ನೋಡಬೇಕು. ಕೇವಲ ಅಂತಿಮ ಕೋಷ್ಟಕವನ್ನು ಎಣಿಸುವುದು ಪರ್ಯಾಯಗಳನ್ನೂ ಘೋಷಣೆಗಳನ್ನೂ ಮುಚ್ಚಿಡುತ್ತದೆ, ಮತ್ತು ಪುನರಾವರ್ತನೆ ಸೇರಿಸಿದಾಗ ಬೆಳೆಯುವ ಭಾಗಗಳು ನಿಖರವಾಗಿ ಅವೇ.
IGP ತಾನಾಗಿಯೇ ತಪ್ಪಲ್ಲ. ಟೋಪಾಲಜಿ, ವಲಯ ರಚನೆ ಮತ್ತು ನೆರೆಹೊರೆ ಮಾದರಿ ಸೇವೆಗೆ ಹೊಂದಿಕೆಯಾದಾಗ, ಲಿಂಕ್-ಸ್ಟೇಟ್ ಪ್ರೋಟೋಕಾಲ್ ಬೇಗ ಒಮ್ಮುಖವಾಗುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ನೀತಿ ಆಧಾರ ಬೇಕಾಗುತ್ತದೆ. ಬಲೆ ಎಂದರೆ ಅದು BGP ಯಂತೆಯೇ ಪ್ರತಿ ನೆರೆಹೊರೆಯವರಿಗೆ ರಫ್ತು ನಿಯಂತ್ರಣವನ್ನು ವ್ಯಕ್ತಪಡಿಸಬಲ್ಲದು ಎಂದು ಭಾವಿಸುವುದು: OSPF ವಲಯವು ಪ್ರವಾಹದ ಗಡಿ, ಒಂದು ಶಾಖೆಗೆ ನೇತುಹಾಕಬಹುದಾದ ಫಿಲ್ಟರ್ ಅಲ್ಲ.
ಹೇಗಾದರೂ, ಮೊದಲು ಗೋಚರತೆ ಮಾದರಿಯನ್ನು ನಿರ್ಧರಿಸಿ. ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳು, ಕೇಂದ್ರ ಸೇವೆಗಳಿಗೆ ಸಾರಾಂಶಗಳು ಅಥವಾ ಪೂರ್ಣ ಶಾಖಾ ವಿವರಗಳು ಮೂರು ವಿಭಿನ್ನ ಉತ್ಪನ್ನಗಳು, ಮತ್ತು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ವೈಫಲ್ಯವನ್ನು ಮುಚ್ಚಿಡುವ ಸಾರಾಂಶವು ಬರೆಯಬೇಕಾದ ವಿನ್ಯಾಸ ನಿರ್ಣಯ, ಸ್ಥಗಿತದ ವೇಳೆ ಕಂಡುಕೊಳ್ಳಬೇಕಾದದ್ದಲ್ಲ.
ಪ್ರವಾಹವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಸ್ಥಿರ ಸ್ಥಿತಿಯನ್ನಲ್ಲ
ನೀವು ನಿಜವಾಗಿ ನಿರೀಕ್ಷಿಸುವ ವೈಫಲ್ಯದ ಸುತ್ತ ಹೋಲಿಕೆಯನ್ನು ಕಟ್ಟಿ: ಹಬ್ ಡೌನ್, ಪ್ರಾದೇಶಿಕ WAN ಘಟನೆ, ಅಥವಾ ಅರ್ಧ ಸೈಟ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಆಫ್‌ಲೈನ್ ಮಾಡುವ ನಿರ್ವಹಣಾ ಕಿಟಕಿ. ಶಾಖೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ಚೇತರಿಕೆಯನ್ನು ಅಳೆಯಿರಿ, ಅಪ್ಲಿಕೇಶನ್ ಸಹಿತ, ಏಕೆಂದರೆ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಒಮ್ಮುಖವಾಗುವ ನಿಯಂತ್ರಣ-ತಲವು ಸೆಷನ್ ಮತ್ತೆ ಸ್ಥಾಪನೆಗೆ ನಿಮಿಷಗಳು ಬೇಕಾದರೆ ಕಡಿಮೆ ಅರ್ಥ.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವಿಶ್ರಾಂತಿಯಲ್ಲಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದಲ್ಲ, ಪ್ರವಾಹದ ಶಿಖರದಲ್ಲಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ, ಮತ್ತು ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಆನ್ ಮಾಡಿ ಪುನರಾವರ್ತಿಸಿ. ಕೇವಲ ಶಾಂತ ಕೋಷ್ಟಕ ತೋರಿಸುವ ಪರಿಕಲ್ಪನಾ ಸಾಕ್ಷ್ಯವು ಮೆಮೊರಿ ಪರೀಕ್ಷೆ, ಮತ್ತು ಮೆಮೊರಿ ಎಂದೂ ಆಸಕ್ತಿಕರ ಸಂಖ್ಯೆಯಾಗಿರಲಿಲ್ಲ.