ಈ ಲೇಖನವು "ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೇಗೆ ನಿಯಂತ್ರಿಸುವುದು" ಎಂಬ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ ಮೂರನೆಯದು. ಸರಣಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಲೇಖನಗಳ ವಿಷಯಗಳನ್ನು ಮತ್ತು ಲಿಂಕ್‌ಗಳನ್ನು ಕಾಣಬಹುದು ಇಲ್ಲಿ.

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

ಸಹಜವಾಗಿ, ಭದ್ರತಾ ವಿನ್ಯಾಸವನ್ನು ಒಟ್ಟಾರೆ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಸಾವಯವವಾಗಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಬಳಸಿದ ಭದ್ರತಾ ಪರಿಹಾರಗಳು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯದ ಸ್ಕೇಲೆಬಿಲಿಟಿ, ವಿಶ್ವಾಸಾರ್ಹತೆ, ನಿರ್ವಹಣೆ, ... ಇವುಗಳನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

ಆದರೆ ಈಗ ನಾವು ನೆಟ್‌ವರ್ಕ್ ರಚಿಸುವ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿಲ್ಲ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ. ನಮ್ಮ ಪ್ರಕಾರ ಆರಂಭಿಕ ಪರಿಸ್ಥಿತಿಗಳು ನಾವು ಈಗಾಗಲೇ ವಿನ್ಯಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಉಪಕರಣಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯವನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಈ ಹಂತದಲ್ಲಿ, ಸಾಧ್ಯವಾದರೆ, ನಾವು "ಬದುಕಬೇಕು" ಮತ್ತು ಹಿಂದೆ ಆಯ್ಕೆಮಾಡಿದ ವಿಧಾನದ ಸಂದರ್ಭದಲ್ಲಿ ಪರಿಹಾರಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು.

ನೆಟ್‌ವರ್ಕ್ ಮಟ್ಟದಲ್ಲಿ ಭದ್ರತೆಗೆ ಸಂಬಂಧಿಸಿದ ಅಪಾಯಗಳನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಸಮಂಜಸವಾದ ಮಟ್ಟಕ್ಕೆ ತಗ್ಗಿಸುವುದು ಈಗ ನಮ್ಮ ಕಾರ್ಯವಾಗಿದೆ.

ನೆಟ್ವರ್ಕ್ ಭದ್ರತಾ ಆಡಿಟ್

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

ನಾನು ಹಲವಾರು ಸಂಭಾವ್ಯ ನೆಟ್‌ವರ್ಕ್ ಭದ್ರತಾ ಲೆಕ್ಕಪರಿಶೋಧನೆಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇನೆ:

• ಸಲಕರಣೆ ಸಂರಚನಾ ಆಡಿಟ್ (ಗಟ್ಟಿಯಾಗುವುದು)
• ಭದ್ರತಾ ವಿನ್ಯಾಸ ಆಡಿಟ್
• ಪ್ರವೇಶ ಆಡಿಟ್
• ಪ್ರಕ್ರಿಯೆ ಆಡಿಟ್

ಸಲಕರಣೆ ಕಾನ್ಫಿಗರೇಶನ್ ಆಡಿಟ್ (ಗಟ್ಟಿಯಾಗುವುದು)

ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನ ಸುರಕ್ಷತೆಯನ್ನು ಲೆಕ್ಕಪರಿಶೋಧನೆ ಮತ್ತು ಸುಧಾರಿಸಲು ಉತ್ತಮ ಆರಂಭಿಕ ಹಂತವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. IMHO, ಇದು ಪಾರೆಟೊ ನಿಯಮದ ಉತ್ತಮ ಪ್ರದರ್ಶನವಾಗಿದೆ (20% ಪ್ರಯತ್ನವು 80% ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಉಳಿದ 80% ಪ್ರಯತ್ನವು ಕೇವಲ 20% ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ).

ಸಾಧನವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ ಸುರಕ್ಷತೆಗಾಗಿ "ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳು" ಕುರಿತು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಮಾರಾಟಗಾರರಿಂದ ಶಿಫಾರಸುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದು ಬಾಟಮ್ ಲೈನ್. ಇದನ್ನು "ಗಟ್ಟಿಯಾಗುವುದು" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

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

ಕೆಲವು ಸಿಸ್ಕೋ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಹಲವಾರು ಉದಾಹರಣೆಗಳು.

Cisco IOS ಕಾನ್ಫಿಗರೇಶನ್ ಗಟ್ಟಿಯಾಗುವುದು
ಸಿಸ್ಕೋ IOS-XR ಕಾನ್ಫಿಗರೇಶನ್ ಗಟ್ಟಿಯಾಗುವುದು
Cisco NX-OS ಕಾನ್ಫಿಗರೇಶನ್ ಗಟ್ಟಿಯಾಗುವುದು
ಸಿಸ್ಕೋ ಬೇಸ್‌ಲೈನ್ ಭದ್ರತಾ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಈ ದಾಖಲೆಗಳ ಆಧಾರದ ಮೇಲೆ, ಪ್ರತಿಯೊಂದು ರೀತಿಯ ಸಲಕರಣೆಗಳಿಗೆ ಸಂರಚನಾ ಅಗತ್ಯತೆಗಳ ಪಟ್ಟಿಯನ್ನು ರಚಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, Cisco N7K VDC ಗಾಗಿ ಈ ಅವಶ್ಯಕತೆಗಳು ಹಾಗೆ ಕಾಣಿಸಬಹುದು ಆದ್ದರಿಂದ.

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

ಭದ್ರತಾ ವಿನ್ಯಾಸದ ಆಡಿಟ್

ವಿಶಿಷ್ಟವಾಗಿ, ಎಂಟರ್‌ಪ್ರೈಸ್ ನೆಟ್‌ವರ್ಕ್ ಈ ಕೆಳಗಿನ ವಿಭಾಗಗಳನ್ನು ಒಂದು ರೂಪದಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೂಪದಲ್ಲಿ ಒಳಗೊಂಡಿದೆ:

• DC (ಸಾರ್ವಜನಿಕ ಸೇವೆಗಳು DMZ ಮತ್ತು ಇಂಟ್ರಾನೆಟ್ ಡೇಟಾ ಸೆಂಟರ್)
• ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶ
• ರಿಮೋಟ್ ಪ್ರವೇಶ VPN
• WAN ಅಂಚು
• ಶಾಖೆ
• ಕ್ಯಾಂಪಸ್ (ಕಚೇರಿ)
• ಕೋರ್

ಶೀರ್ಷಿಕೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಸಿಸ್ಕೊ ​​ಸೇಫ್ ಮಾದರಿ, ಆದರೆ ಈ ಹೆಸರುಗಳಿಗೆ ಮತ್ತು ಈ ಮಾದರಿಗೆ ನಿಖರವಾಗಿ ಲಗತ್ತಿಸುವುದು ಅನಿವಾರ್ಯವಲ್ಲ. ಇನ್ನೂ, ನಾನು ಸಾರದ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ಔಪಚಾರಿಕತೆಗಳಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ಈ ಪ್ರತಿಯೊಂದು ವಿಭಾಗಗಳಿಗೆ, ಭದ್ರತಾ ಅವಶ್ಯಕತೆಗಳು, ಅಪಾಯಗಳು ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಪರಿಹಾರಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ.

ಭದ್ರತಾ ವಿನ್ಯಾಸದ ದೃಷ್ಟಿಕೋನದಿಂದ ನೀವು ಎದುರಿಸಬಹುದಾದ ಸಮಸ್ಯೆಗಳಿಗಾಗಿ ಪ್ರತಿಯೊಂದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡೋಣ. ಸಹಜವಾಗಿ, ನಾನು ಮತ್ತೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ, ಈ ಲೇಖನವು ಸಂಪೂರ್ಣವಾದಂತೆ ನಟಿಸುವುದಿಲ್ಲ, ಇದು ನಿಜವಾದ ಆಳವಾದ ಮತ್ತು ಬಹುಮುಖಿ ವಿಷಯದಲ್ಲಿ ಸಾಧಿಸಲು ಸುಲಭವಲ್ಲ (ಅಸಾಧ್ಯವಲ್ಲದಿದ್ದರೆ), ಆದರೆ ಇದು ನನ್ನ ವೈಯಕ್ತಿಕ ಅನುಭವವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ.

ಯಾವುದೇ ಪರಿಪೂರ್ಣ ಪರಿಹಾರವಿಲ್ಲ (ಕನಿಷ್ಠ ಇನ್ನೂ ಇಲ್ಲ). ಇದು ಯಾವಾಗಲೂ ರಾಜಿ. ಆದರೆ ಅದರ ಸಾಧಕ-ಬಾಧಕಗಳೆರಡನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ ಒಂದು ವಿಧಾನವನ್ನು ಅಥವಾ ಇನ್ನೊಂದನ್ನು ಬಳಸುವ ನಿರ್ಧಾರವನ್ನು ಪ್ರಜ್ಞಾಪೂರ್ವಕವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಎಂಬುದು ಮುಖ್ಯ.

ಡೇಟಾ ಸೆಂಟರ್

ಸುರಕ್ಷತೆಯ ದೃಷ್ಟಿಯಿಂದ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ವಿಭಾಗ.
ಮತ್ತು, ಎಂದಿನಂತೆ, ಇಲ್ಲಿಯೂ ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರವಿಲ್ಲ. ಇದು ಎಲ್ಲಾ ನೆಟ್ವರ್ಕ್ ಅವಶ್ಯಕತೆಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದೆ.

ಫೈರ್‌ವಾಲ್ ಅಗತ್ಯವಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ?

ಉತ್ತರವು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಎಲ್ಲವೂ ತೋರುವಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಮತ್ತು ನಿಮ್ಮ ಆಯ್ಕೆಯು ಕೇವಲ ಪ್ರಭಾವ ಬೀರಬಹುದು ಬೆಲೆ.

ಉದಾಹರಣೆ 1. ವಿಳಂಬಗಳು.

ಕೆಲವು ನೆಟ್‌ವರ್ಕ್ ವಿಭಾಗಗಳ ನಡುವೆ ಕಡಿಮೆ ಸುಪ್ತತೆಯು ಅತ್ಯಗತ್ಯವಾಗಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ವಿನಿಮಯದ ಸಂದರ್ಭದಲ್ಲಿ ನಿಜ, ಆಗ ನಾವು ಈ ವಿಭಾಗಗಳ ನಡುವೆ ಫೈರ್‌ವಾಲ್‌ಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಫೈರ್‌ವಾಲ್‌ಗಳಲ್ಲಿ ಲೇಟೆನ್ಸಿ ಕುರಿತು ಅಧ್ಯಯನಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ, ಆದರೆ ಕೆಲವು ಸ್ವಿಚ್ ಮಾಡೆಲ್‌ಗಳು 1 mksec ಗಿಂತ ಕಡಿಮೆ ಅಥವಾ ಅದರ ಕ್ರಮದಲ್ಲಿ ಸುಪ್ತತೆಯನ್ನು ಒದಗಿಸಬಹುದು, ಆದ್ದರಿಂದ ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳು ನಿಮಗೆ ಮುಖ್ಯವಾಗಿದ್ದರೆ, ಫೈರ್‌ವಾಲ್‌ಗಳು ನಿಮಗಾಗಿ ಅಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಉದಾಹರಣೆ 2. ಪ್ರದರ್ಶನ.

ಟಾಪ್ L3 ಸ್ವಿಚ್‌ಗಳ ಥ್ರೋಪುಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಶಕ್ತಿಶಾಲಿ ಫೈರ್‌ವಾಲ್‌ಗಳ ಥ್ರೋಪುಟ್‌ಗಿಂತ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಕ್ರಮವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚಿನ ತೀವ್ರತೆಯ ದಟ್ಟಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಫೈರ್‌ವಾಲ್‌ಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಈ ದಟ್ಟಣೆಯನ್ನು ನೀವು ಹೆಚ್ಚಾಗಿ ಅನುಮತಿಸಬೇಕಾಗುತ್ತದೆ.

ಉದಾಹರಣೆ 3. ವಿಶ್ವಾಸಾರ್ಹತೆ

ಫೈರ್‌ವಾಲ್‌ಗಳು, ವಿಶೇಷವಾಗಿ ಆಧುನಿಕ NGFW (ಮುಂದಿನ ಪೀಳಿಗೆಯ FW) ಸಂಕೀರ್ಣ ಸಾಧನಗಳಾಗಿವೆ. ಅವು L3/L2 ಸ್ವಿಚ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿವೆ. ಅವರು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸೇವೆಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಅವರ ವಿಶ್ವಾಸಾರ್ಹತೆ ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ. ಸೇವೆಯ ನಿರಂತರತೆಯು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ನಿರ್ಣಾಯಕವಾಗಿದ್ದರೆ, ಉತ್ತಮ ಲಭ್ಯತೆಗೆ ಕಾರಣವಾಗುವುದನ್ನು ನೀವು ಆರಿಸಬೇಕಾಗಬಹುದು - ಫೈರ್‌ವಾಲ್‌ನೊಂದಿಗೆ ಭದ್ರತೆ ಅಥವಾ ಸಾಮಾನ್ಯ ACL ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ವಿಚ್‌ಗಳಲ್ಲಿ (ಅಥವಾ ವಿವಿಧ ರೀತಿಯ ಬಟ್ಟೆಗಳು) ನಿರ್ಮಿಸಲಾದ ನೆಟ್‌ವರ್ಕ್‌ನ ಸರಳತೆ.

ಮೇಲಿನ ಉದಾಹರಣೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಹೆಚ್ಚಾಗಿ (ಎಂದಿನಂತೆ) ರಾಜಿ ಕಂಡುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಕೆಳಗಿನ ಪರಿಹಾರಗಳನ್ನು ನೋಡಿ:

• ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಫೈರ್‌ವಾಲ್‌ಗಳನ್ನು ಬಳಸದಿರಲು ನೀವು ನಿರ್ಧರಿಸಿದರೆ, ಪರಿಧಿಯ ಸುತ್ತ ಪ್ರವೇಶವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಮಿತಿಗೊಳಿಸುವುದು ಹೇಗೆ ಎಂದು ನೀವು ಯೋಚಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, ನೀವು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಅಗತ್ಯವಾದ ಪೋರ್ಟ್‌ಗಳನ್ನು ಮಾತ್ರ ತೆರೆಯಬಹುದು (ಕ್ಲೈಂಟ್ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ) ಮತ್ತು ಜಂಪ್ ಹೋಸ್ಟ್‌ಗಳಿಂದ ಮಾತ್ರ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ. ಜಂಪ್ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ, ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡಿ (ದೃಢೀಕರಣ/ಅಧಿಕಾರ, ಆಂಟಿವೈರಸ್, ಲಾಗಿಂಗ್, ...)
• ನೀವು ಡೇಟಾ ಸೆಂಟರ್ ನೆಟ್‌ವರ್ಕ್‌ನ ತಾರ್ಕಿಕ ವಿಭಾಗವನ್ನು ಭಾಗಗಳಾಗಿ ಬಳಸಬಹುದು, PSEFABRIC ನಲ್ಲಿ ವಿವರಿಸಿದ ಯೋಜನೆಯಂತೆಯೇ ಉದಾಹರಣೆ p002. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಳಂಬ-ಸೂಕ್ಷ್ಮ ಅಥವಾ ಹೆಚ್ಚಿನ-ತೀವ್ರತೆಯ ದಟ್ಟಣೆಯು ಒಂದು ವಿಭಾಗದಲ್ಲಿ (p002, VRF ನ ಸಂದರ್ಭದಲ್ಲಿ) "ಒಳಗೆ" ಹೋಗುತ್ತದೆ ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಮೂಲಕ ಹೋಗದ ರೀತಿಯಲ್ಲಿ ರೂಟಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ವಿವಿಧ ವಿಭಾಗಗಳ ನಡುವಿನ ಸಂಚಾರವು ಫೈರ್‌ವಾಲ್ ಮೂಲಕ ಮುಂದುವರಿಯುತ್ತದೆ. ಫೈರ್‌ವಾಲ್ ಮೂಲಕ ದಟ್ಟಣೆಯನ್ನು ಮರುನಿರ್ದೇಶಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ನೀವು ವಿಆರ್‌ಎಫ್‌ಗಳ ನಡುವೆ ಸೋರಿಕೆಯಾಗುವ ಮಾರ್ಗವನ್ನು ಸಹ ಬಳಸಬಹುದು
• ನೀವು ಪಾರದರ್ಶಕ ಮೋಡ್‌ನಲ್ಲಿ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಸಹ ಬಳಸಬಹುದು ಮತ್ತು ಈ ಅಂಶಗಳು (ಸುಪ್ತತೆ/ಕಾರ್ಯಕ್ಷಮತೆ) ಗಮನಾರ್ಹವಲ್ಲದ VLAN ಗಳಿಗೆ ಮಾತ್ರ. ಆದರೆ ಪ್ರತಿ ಮಾರಾಟಗಾರರಿಗೆ ಈ ಮೋಡ್ ಬಳಕೆಗೆ ಸಂಬಂಧಿಸಿದ ನಿರ್ಬಂಧಗಳನ್ನು ನೀವು ಎಚ್ಚರಿಕೆಯಿಂದ ಅಧ್ಯಯನ ಮಾಡಬೇಕಾಗುತ್ತದೆ
• ನೀವು ಸೇವಾ ಸರಪಳಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಲು ಬಯಸಬಹುದು. ಇದು ಫೈರ್‌ವಾಲ್ ಮೂಲಕ ಅಗತ್ಯ ಸಂಚಾರವನ್ನು ಮಾತ್ರ ಹಾದುಹೋಗಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ ಚೆನ್ನಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಾನು ಈ ಪರಿಹಾರವನ್ನು ನೋಡಿಲ್ಲ. ನಾವು ಸುಮಾರು 5 ವರ್ಷಗಳ ಹಿಂದೆ Cisco ACI/Juniper SRX/F3 LTM ಗಾಗಿ ಸೇವಾ ಸರಪಳಿಯನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ, ಆದರೆ ಆ ಸಮಯದಲ್ಲಿ ಈ ಪರಿಹಾರವು ನಮಗೆ "ಕಚ್ಚಾ" ಎಂದು ತೋರುತ್ತದೆ.

ರಕ್ಷಣೆ ಮಟ್ಟ

ಟ್ರಾಫಿಕ್ ಅನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ನೀವು ಯಾವ ಸಾಧನಗಳನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೀರಿ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಈಗ ನೀವು ಉತ್ತರಿಸಬೇಕಾಗಿದೆ. NGFW ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಕಂಡುಬರುವ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳು ಇಲ್ಲಿವೆ (ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ):

• ಸ್ಟೇಟ್‌ಫುಲ್ ಫೈರ್‌ವಾಲಿಂಗ್ (ಡೀಫಾಲ್ಟ್)
• ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್ವಾಲ್ಲಿಂಗ್
• ಬೆದರಿಕೆ ತಡೆಗಟ್ಟುವಿಕೆ (ಆಂಟಿವೈರಸ್, ಆಂಟಿ-ಸ್ಪೈವೇರ್ ಮತ್ತು ದುರ್ಬಲತೆ)
• URL ಫಿಲ್ಟರಿಂಗ್
• ಡೇಟಾ ಫಿಲ್ಟರಿಂಗ್ (ವಿಷಯ ಫಿಲ್ಟರಿಂಗ್)
• ಫೈಲ್ ನಿರ್ಬಂಧಿಸುವುದು (ಫೈಲ್ ಪ್ರಕಾರಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವುದು)
• ಡಾಸ್ ರಕ್ಷಣೆ

ಮತ್ತು ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಹೆಚ್ಚಿನ ಮಟ್ಟದ ರಕ್ಷಣೆ, ಉತ್ತಮ ಎಂದು ತೋರುತ್ತದೆ. ಆದರೆ ನೀವು ಅದನ್ನು ಸಹ ಪರಿಗಣಿಸಬೇಕಾಗಿದೆ

• ಮೇಲಿನ ಹೆಚ್ಚಿನ ಫೈರ್‌ವಾಲ್ ಕಾರ್ಯಗಳನ್ನು ನೀವು ಬಳಸಿದರೆ, ಅದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿರುತ್ತದೆ (ಪರವಾನಗಿಗಳು, ಹೆಚ್ಚುವರಿ ಮಾಡ್ಯೂಲ್‌ಗಳು)
• ಕೆಲವು ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಬಳಕೆಯು ಫೈರ್‌ವಾಲ್ ಥ್ರೋಪುಟ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ವಿಳಂಬವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ನೋಡಿ ಇಲ್ಲಿ
• ಯಾವುದೇ ಸಂಕೀರ್ಣ ಪರಿಹಾರದಂತೆ, ಸಂಕೀರ್ಣ ಸಂರಕ್ಷಣಾ ವಿಧಾನಗಳ ಬಳಕೆಯು ನಿಮ್ಮ ಪರಿಹಾರದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲಿಂಗ್ ಅನ್ನು ಬಳಸುವಾಗ, ನಾನು ಕೆಲವು ಪ್ರಮಾಣಿತ ಕೆಲಸ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವುದನ್ನು ಎದುರಿಸಿದೆ (dns, smb)

ಯಾವಾಗಲೂ ಹಾಗೆ, ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ನೀವು ಉತ್ತಮ ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು.

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

ಆದ್ದರಿಂದ, ನಿರ್ಣಾಯಕ ವಿಭಾಗಗಳಲ್ಲಿ, ವಿವಿಧ ಕಂಪನಿಗಳ ಕೊಡುಗೆಗಳನ್ನು ಬಳಸುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಆಂಟಿವೈರಸ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು, ಆದರೆ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಆಂಟಿವೈರಸ್ ರಕ್ಷಣೆಯನ್ನು (ಇನ್ನೊಂದು ತಯಾರಕರಿಂದ) ಬಳಸಬಹುದು.

ವಿಭಜನೆ

ನಾವು ಡೇಟಾ ಸೆಂಟರ್ ನೆಟ್ವರ್ಕ್ನ ತಾರ್ಕಿಕ ವಿಭಾಗದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ವಿಎಲ್‌ಎಎನ್‌ಗಳು ಮತ್ತು ಸಬ್‌ನೆಟ್‌ಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಸಹ ತಾರ್ಕಿಕ ವಿಭಾಗವಾಗಿದೆ, ಆದರೆ ಅದರ ಸ್ಪಷ್ಟತೆಯಿಂದಾಗಿ ನಾವು ಅದನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ. FW ಭದ್ರತಾ ವಲಯಗಳು, VRF ಗಳು (ಮತ್ತು ವಿವಿಧ ಮಾರಾಟಗಾರರಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅವುಗಳ ಸಾದೃಶ್ಯಗಳು), ತಾರ್ಕಿಕ ಸಾಧನಗಳು (PA VSYS, Cisco N7K VDC, Cisco ACI ಟೆನೆಂಟ್, ...), ...

ಅಂತಹ ತಾರ್ಕಿಕ ವಿಭಜನೆಯ ಉದಾಹರಣೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಬೇಡಿಕೆಯಲ್ಲಿರುವ ಡೇಟಾ ಸೆಂಟರ್ ವಿನ್ಯಾಸವನ್ನು ನೀಡಲಾಗಿದೆ PSEFABRIC ಯೋಜನೆಯ p002.

ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನ ತಾರ್ಕಿಕ ಭಾಗಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದ ನಂತರ, ವಿವಿಧ ವಿಭಾಗಗಳ ನಡುವೆ ಟ್ರಾಫಿಕ್ ಹೇಗೆ ಚಲಿಸುತ್ತದೆ, ಯಾವ ಸಾಧನಗಳಲ್ಲಿ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಯಾವ ವಿಧಾನದಿಂದ ನೀವು ವಿವರಿಸಬಹುದು.

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

ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಜನೆಯು FW ಭದ್ರತಾ ವಲಯಗಳನ್ನು ಆಧರಿಸಿದೆ. ನಂತರ ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕಾಗಿದೆ:

• ನಿಮಗೆ ಯಾವ ಭದ್ರತಾ ವಲಯಗಳು ಬೇಕು
• ಈ ಪ್ರತಿಯೊಂದು ವಲಯಗಳಿಗೆ ನೀವು ಯಾವ ಮಟ್ಟದ ರಕ್ಷಣೆಯನ್ನು ಅನ್ವಯಿಸಲು ಬಯಸುತ್ತೀರಿ
• ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ವಲಯದೊಳಗಿನ ಸಂಚಾರವನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆಯೇ?
• ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರತಿ ವಲಯದಲ್ಲಿ ಯಾವ ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರಿಂಗ್ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ
• ಪ್ರತಿ ಜೋಡಿ ವಲಯಗಳಿಗೆ ಯಾವ ಸಂಚಾರ ಫಿಲ್ಟರಿಂಗ್ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ (ಮೂಲ/ಗಮ್ಯಸ್ಥಾನ)

ಟಿಸಿಎಎಂ

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

ಉದಾಹರಣೆ 1. ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಟೇಬಲ್ TCAM.

ಪರಿಗಣಿಸೋಣ ಪಾಲೊ ಆಲ್ಟೊ 7 ಕೆ ಫೈರ್ವಾಲ್
IPv4 ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಟೇಬಲ್ ಗಾತ್ರ* = 32K ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ
ಇದಲ್ಲದೆ, ಎಲ್ಲಾ VSYS ಗಳಿಗೆ ಈ ಸಂಖ್ಯೆಯ ಮಾರ್ಗಗಳು ಸಾಮಾನ್ಯವಾಗಿದೆ.

ನಿಮ್ಮ ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ನೀವು 4 VSYS ಅನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸುತ್ತೀರಿ ಎಂದು ಭಾವಿಸೋಣ.
ಈ ಪ್ರತಿಯೊಂದು VSYS ಗಳನ್ನು BGP ಮೂಲಕ ನೀವು BB ಆಗಿ ಬಳಸುವ ಕ್ಲೌಡ್‌ನ ಎರಡು MPLS PE ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ. ಹೀಗಾಗಿ, 4 VSYS ಎಲ್ಲಾ ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗಗಳನ್ನು ಪರಸ್ಪರ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸರಿಸುಮಾರು ಒಂದೇ ರೀತಿಯ ಮಾರ್ಗಗಳೊಂದಿಗೆ (ಆದರೆ ವಿಭಿನ್ನ NH ಗಳು) ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಕೋಷ್ಟಕವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಏಕೆಂದರೆ ಪ್ರತಿ VSYS 2 BGP ಸೆಷನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ (ಅದೇ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ), ನಂತರ MPLS ಮೂಲಕ ಸ್ವೀಕರಿಸಿದ ಪ್ರತಿಯೊಂದು ಮಾರ್ಗವು 2 NH ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಕೋಷ್ಟಕದಲ್ಲಿ 2 FIB ನಮೂದುಗಳು. ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿರುವ ಏಕೈಕ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಇದು ಎಲ್ಲಾ ಮಾರ್ಗಗಳ ಬಗ್ಗೆ ತಿಳಿದಿರಬೇಕು ಎಂದು ನಾವು ಭಾವಿಸಿದರೆ, ಇದರರ್ಥ ನಮ್ಮ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿನ ಒಟ್ಟು ಮಾರ್ಗಗಳ ಸಂಖ್ಯೆ 32K/(4 * 2) = 4K ಗಿಂತ ಹೆಚ್ಚಿರಬಾರದು.

ಈಗ, ನಾವು 2 ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಭಾವಿಸಿದರೆ (ಅದೇ ವಿನ್ಯಾಸದೊಂದಿಗೆ), ಮತ್ತು ನಾವು ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವೆ "ವಿಸ್ತರಿಸಿದ" VLAN ಗಳನ್ನು ಬಳಸಲು ಬಯಸಿದರೆ (ಉದಾಹರಣೆಗೆ, vMotion ಗಾಗಿ), ನಂತರ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಹೋಸ್ಟ್ ಮಾರ್ಗಗಳನ್ನು ಬಳಸಬೇಕು . ಆದರೆ ಇದರರ್ಥ 2 ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ನಾವು 4096 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೋಸ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಮತ್ತು ಸಹಜವಾಗಿ, ಇದು ಸಾಕಾಗುವುದಿಲ್ಲ.

ಉದಾಹರಣೆ 2. ACL TCAM.

ನೀವು L3 ಸ್ವಿಚ್‌ಗಳಲ್ಲಿ ದಟ್ಟಣೆಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಯೋಜಿಸಿದರೆ (ಅಥವಾ L3 ಸ್ವಿಚ್‌ಗಳನ್ನು ಬಳಸುವ ಇತರ ಪರಿಹಾರಗಳು, ಉದಾಹರಣೆಗೆ, ಸಿಸ್ಕೊ ​​ACI), ನಂತರ ಉಪಕರಣಗಳನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ನೀವು TCAM ACL ಗೆ ಗಮನ ಕೊಡಬೇಕು.

ನೀವು ಸಿಸ್ಕೋ ಕ್ಯಾಟಲಿಸ್ಟ್ 4500 ನ SVI ಇಂಟರ್ಫೇಸ್‌ಗಳಲ್ಲಿ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ಭಾವಿಸೋಣ. ನಂತರ, ಇದನ್ನು ನೋಡಬಹುದು ಈ ಲೇಖನದ, ಇಂಟರ್‌ಫೇಸ್‌ಗಳಲ್ಲಿ ಹೊರಹೋಗುವ (ಹಾಗೆಯೇ ಒಳಬರುವ) ದಟ್ಟಣೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು, ನೀವು ಕೇವಲ 4096 TCAM ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ಬಳಸಬಹುದು. TCAM3 ಅನ್ನು ಬಳಸುವಾಗ ನಿಮಗೆ ಸುಮಾರು 4000 ಸಾವಿರ ACE ಗಳನ್ನು (ACL ಲೈನ್‌ಗಳು) ನೀಡುತ್ತದೆ.

ನೀವು ಸಾಕಷ್ಟು TCAM ನ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದರೆ, ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಆಪ್ಟಿಮೈಸೇಶನ್ ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಗಣಿಸಬೇಕು. ಆದ್ದರಿಂದ, ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಕೋಷ್ಟಕದ ಗಾತ್ರದೊಂದಿಗೆ ಸಮಸ್ಯೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಮಾರ್ಗಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಗಣಿಸಬೇಕು. ಪ್ರವೇಶಗಳಿಗೆ TCAM ಗಾತ್ರದಲ್ಲಿ ಸಮಸ್ಯೆಯಿದ್ದಲ್ಲಿ, ಆಡಿಟ್ ಪ್ರವೇಶಗಳು, ಹಳತಾದ ಮತ್ತು ಅತಿಕ್ರಮಿಸುವ ದಾಖಲೆಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ಮತ್ತು ಪ್ರವೇಶಗಳನ್ನು ತೆರೆಯುವ ವಿಧಾನವನ್ನು ಪ್ರಾಯಶಃ ಪರಿಷ್ಕರಿಸಿ (ಆಡಿಟಿಂಗ್ ಪ್ರವೇಶಗಳ ಅಧ್ಯಾಯದಲ್ಲಿ ವಿವರವಾಗಿ ಚರ್ಚಿಸಲಾಗುವುದು).

ಹೈ ಅವೈಲೆಬಿಲಿಟಿ

ಪ್ರಶ್ನೆಯೆಂದರೆ: ನಾನು ಫೈರ್‌ವಾಲ್‌ಗಳಿಗಾಗಿ HA ಅನ್ನು ಬಳಸಬೇಕೇ ಅಥವಾ ಎರಡು ಸ್ವತಂತ್ರ ಪೆಟ್ಟಿಗೆಗಳನ್ನು "ಸಮಾನಾಂತರವಾಗಿ" ಸ್ಥಾಪಿಸಬೇಕೇ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ, ಎರಡನೆಯ ಮೂಲಕ ಸಂಚಾರವನ್ನು ಮಾರ್ಗಗೊಳಿಸಬೇಕೇ?

ಉತ್ತರವು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ - HA ಬಳಸಿ. ಈ ಪ್ರಶ್ನೆಯು ಇನ್ನೂ ಉದ್ಭವಿಸಲು ಕಾರಣವೆಂದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಸೈದ್ಧಾಂತಿಕ ಮತ್ತು ಜಾಹೀರಾತು 99 ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪ್ರವೇಶಿಸುವಿಕೆಯ ಹಲವಾರು ದಶಮಾಂಶ ಶೇಕಡಾವಾರು ತುಂಬಾ ಗುಲಾಬಿಯಿಂದ ದೂರವಿದೆ. HA ತಾರ್ಕಿಕವಾಗಿ ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣ ವಿಷಯವಾಗಿದೆ, ಮತ್ತು ವಿವಿಧ ಸಾಧನಗಳಲ್ಲಿ, ಮತ್ತು ವಿವಿಧ ಮಾರಾಟಗಾರರೊಂದಿಗೆ (ಯಾವುದೇ ವಿನಾಯಿತಿಗಳಿಲ್ಲ), ನಾವು ಸಮಸ್ಯೆಗಳು ಮತ್ತು ದೋಷಗಳು ಮತ್ತು ಸೇವಾ ನಿಲುಗಡೆಗಳನ್ನು ಹಿಡಿದಿದ್ದೇವೆ.

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

ನೀವು HA ಅನ್ನು ಬಳಸದಿದ್ದರೆ, ಡಬಲ್ ವೈಫಲ್ಯದ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿಮ್ಮ ಅಪಾಯಗಳು ತುಂಬಾ ಕಡಿಮೆ (ನೀವು 2 ಸ್ವತಂತ್ರ ಫೈರ್‌ವಾಲ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ), ಆದರೆ... ಸೆಷನ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿಲ್ಲ, ನಂತರ ನೀವು ಪ್ರತಿ ಬಾರಿ ಈ ಫೈರ್‌ವಾಲ್‌ಗಳ ನಡುವೆ ಬದಲಾಯಿಸಿದಾಗ ನೀವು ದಟ್ಟಣೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನೀವು ಸಹಜವಾಗಿ, ಸ್ಥಿತಿಯಿಲ್ಲದ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ನಂತರ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಬಳಸುವ ಹಂತವು ಹೆಚ್ಚಾಗಿ ಕಳೆದುಹೋಗುತ್ತದೆ.

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

ನಿರ್ವಹಣೆ

ತಾತ್ವಿಕವಾಗಿ, HA ಸಹ ನಿಯಂತ್ರಣದ ಬಗ್ಗೆ. 2 ಬಾಕ್ಸ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಬದಲು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಸಿಂಕ್‌ನಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳುವ ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸುವ ಬದಲು, ನೀವು ಒಂದು ಸಾಧನವನ್ನು ಹೊಂದಿರುವಂತೆ ನೀವು ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೀರಿ.

ಆದರೆ ಬಹುಶಃ ನೀವು ಅನೇಕ ಡೇಟಾ ಕೇಂದ್ರಗಳು ಮತ್ತು ಅನೇಕ ಫೈರ್ವಾಲ್ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನಂತರ ಈ ಪ್ರಶ್ನೆಯು ಹೊಸ ಮಟ್ಟದಲ್ಲಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಮತ್ತು ಪ್ರಶ್ನೆಯು ಸಂರಚನೆಯ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ, ಅದರ ಬಗ್ಗೆಯೂ ಸಹ

• ಬ್ಯಾಕ್ಅಪ್ ಸಂರಚನೆಗಳು
• ನವೀಕರಣಗಳು
• ನವೀಕರಣಗಳು
• ಉಸ್ತುವಾರಿ
• ಲಾಗಿಂಗ್

ಮತ್ತು ಕೇಂದ್ರೀಕೃತ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಇದನ್ನು ಪರಿಹರಿಸಬಹುದು.

ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, ನೀವು ಪಾಲೊ ಆಲ್ಟೊ ಫೈರ್‌ವಾಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನಂತರ ಪನೋರಮಾ ಅಂತಹ ಪರಿಹಾರವಾಗಿದೆ.

ಮುಂದುವರೆಯಲು.

ಮೂಲ: www.habr.com