ಸೈಟ್-ಟು-ಸೈಟ್ VPN ಮೇಲೆ ಸ್ಟ್ಯಾಟಿಕ್ ರೂಟ್ಗಳೇ ಅಥವಾ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್?

ಎರಡೂ ಆಯ್ಕೆಗಳು ಸೈಟ್ಗಳ ನಡುವೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿರ್ಧಾರವು ಯಾವ ಪ್ರೋಟೋಕಾಲ್ ಹೊಸದು ಎಂಬುದರ ಬಗ್ಗೆ ಅಲ್ಲ, ಮತ್ತು ಟನೆಲ್ನ ಗಾತ್ರವೂ ಅದನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಮೂರು ಷರತ್ತುಗಳು ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಎಷ್ಟು ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಎಷ್ಟು ಬಾರಿ, ವಿನ್ಯಾಸಕ್ಕೆ ಮಾರ್ಗಗಳ ನಡುವೆ ಸ್ವಯಂಚಾಲಿತ ಫೇಲ್ಓವರ್ ಬೇಕೇ, ಮತ್ತು ತಂಡವು ರಾತ್ರಿ ಮೂರು ಗಂಟೆಗೆ ಎಷ್ಟು ನಿಯಂತ್ರಣ-ಸ್ತರ ಯಂತ್ರೋಪಕರಣವನ್ನು ನಿರ್ವಹಿಸಬಲ್ಲದು. ಇವಕ್ಕೆ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಉತ್ತರಿಸಿ, ಆಯ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ತಾನೇ ಆಗುತ್ತದೆ. ಈ ಬರಹದ ಉಳಿದ ಭಾಗ ಪ್ರತಿ ಉತ್ತರದ ಬೆಲೆ.

ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ

ಮೊದಲ ಷರತ್ತು ಬದಲಾವಣೆ. ಸ್ಪಷ್ಟ ಮಾಲೀಕತ್ವವಿರುವ ಕೆಲವು ಸ್ಥಿರ ಸಬ್ನೆಟ್ಗಳನ್ನು ವರ್ಷಗಳ ಕಾಲ ಕೈಯಿಂದ ನಿರ್ವಹಿಸಬಹುದು, ಮತ್ತು ಪ್ರತಿ ರೂಟ್ ಯಾರಾದರೂ ಓದಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸಾಲಿನಂತೆ ಉಳಿಯುತ್ತದೆ. ಯೋಜನೆಗಳು ಬಂದು ಹೋಗುವಂತೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುವ ಡಜನ್ಗಟ್ಟಲೆ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಬೇರೆ ಸಮಸ್ಯೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಸ್ಥಳಾಂತರವೂ ಹಳೆಯ ಮಾರ್ಗವನ್ನು ಇನ್ನೂ ನೆನಪಿಟ್ಟುಕೊಂಡಿರುವ ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ತಲುಪಬೇಕು.

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

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

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

ಸ್ಟ್ಯಾಟಿಕ್ ರೂಟಿಂಗ್ ನಿಜವಾಗಿ ಎಷ್ಟು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ

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

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

ಪ್ರತಿ ರೂಟ್ನ ಪಕ್ಕದಲ್ಲಿ ಟ್ರ್ಯಾಕಿಂಗ್ ವಿಧಾನವನ್ನು ಬರೆಯಿರಿ, ಅದು ಯಾವ ವೈಫಲ್ಯಗಳನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ, ಮತ್ತು ಪಟ್ಟಿಯನ್ನು ಟನೆಲ್ ಸಂರಚನೆಯೊಂದಿಗೆ ಇರಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಅಡಚಣೆಯನ್ನು ನೆಟ್ವರ್ಕ್ ಅಲ್ಲ, ಬಳಕೆದಾರ ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ, ಮತ್ತು ಅದು ಯಾವಾಗಲೂ ಹೆಚ್ಚು ದುಬಾರಿ ಕಂಡುಹಿಡಿಯುವಿಕೆ.

ಡೈನಾಮಿಕ್ ರೂಟಿಂಗ್ ನಿಜವಾಗಿ ಎಷ್ಟು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ

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

ಅದು ಒಪ್ಪದಿರಬಹುದಾದ ಎರಡು ಸ್ಥಿತಿಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಟನೆಲ್ ಮೇಲಿರುವಾಗ ರೂಟಿಂಗ್ ಸೆಷನ್ ಕೆಳಗಿರಬಹುದು, ಮತ್ತು ಸೆಷನ್ ಮೇಲಿರುವಾಗ ಅದರ ಘೋಷಣೆಗಳು ಅಪ್ಲಿಕೇಶನ್ಗೆ ಬೇಕಾದ ಸಬ್ನೆಟ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಎರಡೂ ಅರ್ಧ ಕೆಲಸ ಮಾಡುವ ನೆಟ್ವರ್ಕ್ನಂತೆ ಕಾಣುತ್ತವೆ, ಮತ್ತು ಯಾವುದೂ ಟನೆಲ್ ಸ್ಥಿತಿ ಪುಟದಿಂದ ಕಾಣುವುದಿಲ್ಲ.

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

ರೂಟಿಂಗ್ ಸೆಷನ್ ಏನು ಹೇಳಬಹುದು ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸಿ

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

ಮೊದಲ ಸೆಷನ್ ಏಳುವ ಮೊದಲೇ ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ನ ಪಕ್ಕದಲ್ಲಿ ಮಾಲೀಕ ಸೈಟ್ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಆ ಮ್ಯಾಪಿಂಗ್ ಫಿಲ್ಟರ್ ಪಟ್ಟಿಯ ಮೂಲ, ದಸ್ತಾವೇಜಿನ ಅಲಂಕಾರವಲ್ಲ. ಅದಿಲ್ಲದಿದ್ದರೆ ಫಿಲ್ಟರ್ ಸಂಪಾದಿಸುವವರು ಯಾವ ಸೈಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸಬೇಕು ಎಂದು ಊಹಿಸಬೇಕು.

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

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

ವೈಫಲ್ಯದ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಸಂತೋಷದ ಮಾರ್ಗವನ್ನಲ್ಲ

ನೀವು ಏನೇ ಆರಿಸಿದರೂ, ಒಂದು ಅಪ್ಲಿಂಕ್ ಅನ್ನು ಕೆಳಗಿಳಿಸಿ ಮತ್ತು ಸಂಚಾರವು ಚಲಿಸುತ್ತದೆ ಅಥವಾ ನೀವು ದಾಖಲಿಸಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಎರಡೂ ಮಾರ್ಗಗಳು ಆರೋಗ್ಯಕರವಾಗಿರುವಾಗ ಮಾತ್ರ ಪರೀಕ್ಷಿಸಿದ ವಿನ್ಯಾಸವು ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸದ ವಿನ್ಯಾಸ. ಅಲ್ಲಿಯೇ ಇದ್ದಾಗ ಪತ್ತೆ ಸಮಯವನ್ನು ಅಳೆಯಿರಿ, ಏಕೆಂದರೆ ನೀವು ಅಳೆದ ಸಂಖ್ಯೆಯೇ ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ ಸಂಖ್ಯೆ.

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

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