AFI ಮತ್ತು SAFI: ಸೇವೆಯ ಹೆಸರಿಗಿಂತ ಮೊದಲು ಜೋಡಿಯನ್ನು ಓದಿ
AFI 25 ಜೊತೆ SAFI 65 ಎಂಬುದು AFI 25 ಜೊತೆ SAFI 70 ನಂತೆಯೇ ಅಲ್ಲ. ಜೋಡಿಯನ್ನು ಓದಿ, ನಂತರ ಕುಟುಂಬ ವಿನಿಮಯ, ಮಾರ್ಗ ಮತ್ತು ಮುಂದೆ ಸಾಗಿಸುವ ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಸೆಷನ್ ಏರುವುದನ್ನು ನೋಡಬಹುದು, ಮಾರ್ಗ ಕಾಣಿಸಿಕೊಳ್ಳುವುದನ್ನು ನೋಡಬಹುದು, ಆದರೂ ತಪ್ಪು ಸೇವೆಯನ್ನು ಓದುತ್ತಿರಬಹುದು. ಪ್ರತಿ ಪ್ರಕಟಣೆಯ ಆರಂಭದಲ್ಲಿನ ಸಂಖ್ಯೆಗಳ ಜೋಡಿ, ವಿಳಾಸ ಕುಟುಂಬ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಮುಂದಿನ ವಿಳಾಸ ಕುಟುಂಬ ಗುರುತಿಸುವಿಕೆ, ಯಾವ ಪಾರ್ಸರ್ ಪೇಲೋಡ್ ಓದುತ್ತದೆ ಮತ್ತು ಯಾವ ಕೋಷ್ಟಕ ಫಲಿತಾಂಶವನ್ನು ಹಿಡಿದಿಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಜೋಡಿಯನ್ನು ತಪ್ಪಿಸಿಕೊಂಡರೆ ಆಮದು ನೀತಿ, ಮಾರ್ಗ-ಗುರಿ ಹೊಂದಾಣಿಕೆ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಹುಡುಕಾಟ ಎಲ್ಲವೂ ಯಾರೂ ಪ್ರಕಟಿಸದ ರಚನೆಯ ವಿರುದ್ಧ ಚಲಿಸುತ್ತವೆ. ಕೆಳಗಿನ ಪ್ರಯಾಣ ಆ ಜೋಡಿಯಿಂದ ಪ್ರಾರಂಭವಾಗಿ ಮುಂದೆ ಸಾಗಿಸುವ ಫಲಿತಾಂಶದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
ಮಾರ್ಗ ಯಾವ ಕೋಷ್ಟಕಕ್ಕೆ ಸೇರುತ್ತದೆ ಎಂಬುದನ್ನು ಎರಡು ಸಂಖ್ಯೆಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ
ಜೋಡಿ ಎರಡು ಬಾರಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ: ಬಹುಪ್ರೋಟೋಕಾಲ್ ಸಾಮರ್ಥ್ಯದ ಒಳಗೆ, ಅಲ್ಲಿ ಮಾತನಾಡುವವನು ಕುಟುಂಬವನ್ನು ಪ್ರಕಟಿಸುತ್ತಾನೆ, ಮತ್ತು ಆ ಕುಟುಂಬ ಒಯ್ಯುವ ಪ್ರತಿ NLRIಯ ಮುಂದೆ. ಇದು ಅದನ್ನು ಮೂಲ ಪೆಟ್ಟಿಗೆಯ ಸೆಟ್ಟಿಂಗ್ ಬದಲು ಮಾರ್ಗದ ಗುಣವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ತಯಾರಕರು ಅದನ್ನು Address family VPNv4 Unicast ನಂತಹ ಹೆಸರಾಗಿ ಮುದ್ರಿಸುತ್ತಾರೆ, ಮತ್ತು ಸಂಖ್ಯೆಗಳು ಸ್ಥಿರವಾಗಿರುವಾಗ ಪದಪ್ರಯೋಗ ಆವೃತ್ತಿಗಳ ನಡುವೆ ಬದಲಾಗುತ್ತದೆ.
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
ನಾಲ್ಕು ಎನ್ಕೋಡಿಂಗ್‌ಗಳು ಬಹುತೇಕ ಎಲ್ಲಾ ಉದ್ಯಮ ಪ್ರಕರಣಗಳನ್ನು ಆವರಿಸುತ್ತವೆ: MPLS ಲೇಬಲ್ ಇರುವ VPN-IPv4ಗೆ 1 ಜೊತೆ 128, IPv6 ಸಮಾನಕ್ಕೆ 2 ಜೊತೆ 128, BGP ಸಂಕೇತಿತ VPLSಗೆ 25 ಜೊತೆ 65, ಮತ್ತು EVPNಗೆ 25 ಜೊತೆ 70. ಮೊದಲ ತಪ್ಪು ಎಂದರೆ ಪ್ರತಿ Layer 2 ಸೇವೆಯೂ 25 ಜೊತೆ 65ರ ಹಿಂದೆ ಇದೆ ಎಂದು ಭಾವಿಸುವುದು, ಇದು EVPN ಅನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಎರಡನೆಯದು ಎರಡು IP ಕುಟುಂಬಗಳನ್ನು ಉದ್ದವಾದ ವಿಳಾಸವಿರುವ ಒಂದು ಕುಟುಂಬವಾಗಿ ಪರಿಗಣಿಸುವುದು, ಆದರೆ ಅವು ಪ್ರತ್ಯೇಕವಾಗಿ ಚರ್ಚಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು ವಿವಿಧ ಪೀರ್‌ಗಳಲ್ಲಿ ಸ್ವೀಕರಿಸಬಹುದು. ಮೂರನೆಯದು ಒಂದನ್ನು ಮಾತ್ರ ತಿಳಿದ ಆವೃತ್ತಿಯಿಂದ ಟೆಂಪ್ಲೇಟ್ ನಕಲಿಸಿದಾಗ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನೋಂದಣಿಯಲ್ಲಿ ಹುಡುಕುವುದು ಸೇವೆಯ ಹೆಸರಿನ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಊಹೆಗಿಂತ ಮೂರನ್ನೂ ವೇಗವಾಗಿ ಬಗೆಹರಿಸುತ್ತದೆ.
ನಾಲ್ಕು ಸಾಲುಗಳನ್ನು IANA ನೋಂದಣಿಯ ಉದಾಹರಣೆಗಳಾಗಿ ಪರಿಗಣಿಸಿ, ನೋಂದಣಿಯನ್ನೇ ಅಲ್ಲ. ಯಾವುದೇ ಸಂಖ್ಯೆ ನಿಮಗೆ ತಿಳಿದ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಅದರ ಸುತ್ತ ನೀತಿ ನಿರ್ಮಿಸುವ ಮೊದಲು ಅದನ್ನು ನೋಡಿ.
AFI 25 ಎರಡು ಸಂಬಂಧವಿಲ್ಲದ NLRI ಸ್ವರೂಪಗಳನ್ನು ಒಯ್ಯುತ್ತದೆ
ಎರಡೂ Layer 2 ಕುಟುಂಬಗಳು AFI 25 ಅಡಿಯಲ್ಲಿ ಕುಳಿತಿವೆ, ಮತ್ತು ಹೋಲಿಕೆ ಅಲ್ಲಿಯೇ ನಿಲ್ಲುತ್ತದೆ. RFC 4761 section 3.2.2 ನಲ್ಲಿನ VPLS NLRI ಉದ್ದ, ಮಾರ್ಗ ವಿಭೇದಕ, VE ID, VE ಬ್ಲಾಕ್ ಆಫ್‌ಸೆಟ್, VE ಬ್ಲಾಕ್ ಗಾತ್ರ ಮತ್ತು ಲೇಬಲ್ ಆಧಾರವನ್ನು ಒಯ್ಯುತ್ತದೆ, ಅವು ಒಟ್ಟಾಗಿ pseudowire ತುದಿ ಬಿಂದು ಮತ್ತು ಅದರ ಲೇಬಲ್‌ಗೆ ಹೆಸರಿಡುತ್ತವೆ. EVPN AFI 25 ಅನ್ನು ಉಳಿಸಿಕೊಂಡು SAFI 70ಗೆ ಹೋಗುತ್ತದೆ, ಅಲ್ಲಿ ಪೇಲೋಡ್ ಮಾರ್ಗ ಪ್ರಕಾರ: ಈಥರ್ನೆಟ್ ಸ್ವಯಂ-ಶೋಧನೆ, MAC/IP ಪ್ರಕಟಣೆ, ಒಳಗೊಳ್ಳುವ ಮಲ್ಟಿಕಾಸ್ಟ್, ಈಥರ್ನೆಟ್ ಖಂಡ, IP ಪೂರ್ವಪ್ರತ್ಯಯ. ಆದ್ದರಿಂದ ಅದೇ ಬೈಟ್ ಆಫ್‌ಸೆಟ್ ಎರಡು ಕುಟುಂಬಗಳಲ್ಲಿ ಬೇರೆ ಅರ್ಥ ನೀಡುತ್ತದೆ. ಒಂದಕ್ಕೆ ಬರೆದ ಪಾರ್ಸರ್ ಇನ್ನೊಂದನ್ನು ದೂರದೆ ಓದಿ ಅರ್ಥಹೀನತೆ ಉತ್ಪಾದಿಸುತ್ತದೆ. ಜೋಡಿಯೇ ವ್ಯಾಖ್ಯಾನ ತಪ್ಪು ಎಂಬ ಏಕೈಕ ಎಚ್ಚರಿಕೆ.
ಒಂದು ಕುಟುಂಬದಲ್ಲಿ VE ಬ್ಲಾಕ್ ಆಫ್‌ಸೆಟ್ ಎಂದು ಅರ್ಥವಾಗುವ ಕ್ಷೇತ್ರಕ್ಕೆ ಇನ್ನೊಂದರಲ್ಲಿ ಸಮಾನವಿಲ್ಲ, ಮತ್ತು MAC/IP ಪ್ರಕಟಣೆ ಮಾರ್ಗ EVPN ನಲ್ಲಿ ಮಾತ್ರ ಇದೆ. ಗುಣಲಕ್ಷಣವನ್ನು ಎರಡಕ್ಕೂ ಅನ್ವಯಿಸುವಂತೆ ಉಲ್ಲೇಖಿಸುವುದೇ ಕ್ಯಾಪ್ಚರ್ ಪರಿಶೀಲನೆ ತಪ್ಪಾಗುವ ದಾರಿ.
ಯಾರಾದರೂ ನಿಮಗೆ ಕ್ಯಾಪ್ಚರ್ ಅಥವಾ ತಯಾರಕರ ಕೋಷ್ಟಕ ಕೊಟ್ಟಾಗ, ಗುಣಲಕ್ಷಣ ಯಾವ ಕುಟುಂಬಕ್ಕೆ ಸೇರಿದೆ ಎಂದು ಕೇಳಿ. ನಂತರ ಸ್ವೀಕರಿಸುವ ಅನುಷ್ಠಾನ ಆ ಕುಟುಂಬವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಡೇಟಾಶೀಟ್‌ನ ಸೇವಾ ಹೆಸರನ್ನಲ್ಲ. ಎರಡು ವೇದಿಕೆಗಳು VPLS ಬೆಂಬಲವನ್ನು ಪ್ರತಿಪಾದಿಸಬಹುದು ಆದರೆ ವಿಭಿನ್ನ ಸಿಗ್ನಲಿಂಗ್ ಕುಟುಂಬಗಳನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತವೆ. ಜೋಡಿ ಅವನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ; ಉತ್ಪನ್ನ ಲೇಬಲ್ ಇಲ್ಲ.
ಸೆಷನ್‌ನ ಸ್ವಂತ ವಿಳಾಸ ಕುಟುಂಬ ಬೇರೆ ಪ್ರಶ್ನೆ
VPN-IPv6 ಸಾಮಾನ್ಯವಾಗಿ TCP ಸಂಪರ್ಕ IPv4 ಮೇಲೆ ಚಲಿಸುವ ಸೆಷನ್ ಮೂಲಕ ಪ್ರಕಟವಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ಬೆಂಬಲಿತ ವಿನ್ಯಾಸ, ದೋಷವಲ್ಲ. ಆದ್ದರಿಂದ ಸೆಷನ್ ಸಾರಾಂಶವನ್ನು ಮಾತ್ರ ಓದುವುದು ಪೀರ್‌ಗಳು ಯಾವ VPN ಕುಟುಂಬಗಳನ್ನು ವಿನಿಮಯ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ಏನೂ ಹೇಳುವುದಿಲ್ಲ.
NLRI ಕುಟುಂಬ, ಸಾಗಣೆ ಕುಟುಂಬ ಮತ್ತು ಮುಂದೆ ಸಾಗಿಸುವ ಕುಟುಂಬ ಮೂರು ಸ್ವತಂತ್ರ ನಿರ್ಧಾರಗಳು. ರೌಟರ್ ತನ್ನ ಪೀರ್ ಜೊತೆ IPv4 ಮಾತನಾಡಬಹುದು, VPN-IPv6 ತಲುಪುವಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ನೀವು ಉದ್ದೇಶಿಸದ ಮಾರ್ಗದಿಂದ ತಲುಪಬಹುದಾದ IPv6 ವಿಳಾಸವಾಗಿರುವ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಬಹುದು. ಪ್ರತಿ ಪದರಕ್ಕೂ ತನ್ನದೇ ದೃಢೀಕರಣ ಬೇಕು. ಪ್ರಕಟಣೆಗಳು ಸರಿಯಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ IPv6 ಗಮ್ಯಸ್ಥಾನಗಳು ತಲುಪದಿರುವುದಾಗಿ ವರದಿ ಮಾಡುವ ಸೈಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮುಂದಿನ ಹಾಪ್ ಪರಿಹಾರವನ್ನು ಕಳೆದುಕೊಂಡಿವೆ, ಕುಟುಂಬ ಮಾತುಕತೆಯನ್ನಲ್ಲ.
ಸೆಷನ್‌ನ ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಅದು ಒಯ್ಯುವ ಕುಟುಂಬಗಳನ್ನು, ನಂತರ ಕೋರ್ ಮುಂದೆ ಸಾಗಿಸಬಲ್ಲದನ್ನು. ಮೂರನ್ನೂ ಬೇರೆಯಾಗಿ ಇಡುವುದು ಸಾಮಾನ್ಯ ತಪ್ಪು ನಿರ್ಣಯವನ್ನು ತಡೆಯುತ್ತದೆ: ಸರಿಯಾದ ಪ್ರಕಟಣೆಯನ್ನು IPv6 ತುದಿಯಿಂದ ತುದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ಸಾಕ್ಷಿಯಾಗಿ ಓದುವುದು. ಅದು ಒಬ್ಬ ಪೀರ್ ಇನ್ನೊಬ್ಬನಿಗೆ ಪೂರ್ವಪ್ರತ್ಯಯದ ಬಗ್ಗೆ ಹೇಳಿದುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
ಮಾತುಕತೆ ನಡೆದ, ಸ್ವೀಕರಿಸಿದ, ಆಮದು ಮಾಡಿದ, ಸ್ಥಾಪಿಸಿದ
ಒಂದು ನಿರೀಕ್ಷಿತ ಮಾರ್ಗಕ್ಕೆ ನಾಲ್ಕು ಸ್ಥಿತಿಗಳು ಕ್ರಮವಾಗಿ ಇರಬೇಕು, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಗಮನಿಸಬಹುದಾದುದು. ಕುಟುಂಬವು ಆ ಪೀರ್ ಜೊತೆ ಮಾತುಕತೆ ನಡೆಸಿರಬೇಕು, ಮಾರ್ಗ ಬರಬೇಕು, ಮಾರ್ಗ ಗುರಿಯೊಂದು ಅದನ್ನು ಉದ್ದೇಶಿತ ಸಂದರ್ಭಕ್ಕೆ ಆಮದು ಮಾಡಬೇಕು, ಮತ್ತು ಮಾರ್ಗ ಸ್ಥಾಪನೆಯಾಗಲು ಮುಂದಿನ ಹಾಪ್ ಪರಿಹಾರವಾಗಬೇಕು. ಮೊದಲ ಸ್ಥಿತಿಯನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ ಉಳಿದ ಮೂರು ಉತ್ತರವಿಲ್ಲದಂತಾಗುತ್ತವೆ, ಏಕೆಂದರೆ ಮಾತುಕತೆ ನಡೆಯದ ಕುಟುಂಬ ಪರಿಶೀಲಿಸಲು ಮಾರ್ಗಗಳನ್ನು ಉತ್ಪಾದಿಸುವುದಿಲ್ಲ. Cisco ಶೈಲಿಯ ವೇದಿಕೆಗಳಲ್ಲಿ ಕುಟುಂಬ ಸಾರಾಂಶಗಳು ಮತ್ತು ಪ್ರತಿ-ಪೀರ್ ಸಾಮರ್ಥ್ಯಗಳು ಪ್ರತ್ಯೇಕ ಆದೇಶಗಳು.
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address familyಮಾತುಕತೆ ಪ್ರತಿ ಪೀರ್‌ಗೆ ಮುದ್ರಿತ ಸಾಮರ್ಥ್ಯ ವಿನಿಮಯದಲ್ಲಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಕುಟುಂಬ ಪಟ್ಟಿ ಮಾಡದ ಸ್ಥಾಪಿತ ಸೆಷನ್ ನೀವು ಕೇಳಿದ ಯಾವುದನ್ನೂ ಒಯ್ಯುವುದಿಲ್ಲ. ಆಮದನ್ನು ವಿಸ್ತೃತ ಸಮುದಾಯಗಳಾಗಿ ಒಯ್ಯುವ ಮಾರ್ಗ ಗುರಿಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸರಿಯಾದ ಜೋಡಿ ತಪ್ಪಾಗಿ ಟೈಪ್ ಮಾಡಿದ ಗುರಿಯೊಂದಿಗೆ ಕೋಷ್ಟಕವನ್ನು ಖಾಲಿ ಬಿಡುತ್ತದೆ. ನಂತರ ಸ್ಥಾಪನೆ ಸ್ವೀಕರಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ ಮುಂದಿನ ಹಾಪ್ ಪರಿಹಾರವಾಗುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಪ್ರತಿ ಪ್ರಕಟಣೆಯೂ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ ಅದು ವಿಫಲವಾಗಬಹುದು.
ಡೇಟಾ ಪ್ಲೇನ್ ಅನ್ನು ಕೊನೆಯಲ್ಲಿ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಕೋಷ್ಟಕದಲ್ಲಿನ ಮಾರ್ಗವು ಪ್ರತಿಪಾದನೆ, ವಿತರಣೆಯಲ್ಲ. ಅದೇ ನಾಲ್ಕು ಸ್ಥಿತಿಗಳು ಪ್ರತಿ ಕುಟುಂಬಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತವೆ; ಆದೇಶಗಳು ಮತ್ತು ಕೋಷ್ಟಕ ಹೆಸರುಗಳು ಮಾತ್ರ ಬದಲಾಗುತ್ತವೆ.
ಕುಟುಂಬ-ಜೋಡಿ ಎಂದಿಗೂ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ
ಜೋಡಿಯನ್ನು ಸರಿಯಾಗಿ ಓದುವುದು ನಂತರ ಬರುವ ಮಾರ್ಗ ಮಾಹಿತಿಯನ್ನು ಹೇಗೆ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಅದೇ ಸಂಪೂರ್ಣ ಪ್ರತಿಪಾದನೆ. ಅದು ತಲುಪುವಿಕೆ, ನೀತಿ ಅಥವಾ ಡೇಟಾ ಪ್ಲೇನ್‌ನ ಆರೋಗ್ಯದ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ಗೊಂದಲಮಾಡಿಕೊಳ್ಳುವುದು ಯಾರೂ ಪರಿಶೀಲಿಸದ ಜಾಲದ ಬಗ್ಗೆ ಆತ್ಮವಿಶ್ವಾಸದ ಹೇಳಿಕೆಗಳನ್ನು ಹುಟ್ಟಿಸುತ್ತದೆ. ಮಾರ್ಗ-ಗುರಿ ಅಸಾಮರಸ್ಯ ಮತ್ತು ಮುರಿದ ಮುಂದಿನ ಹಾಪ್ ಜೋಡಿಯಿಂದ ಮಾತ್ರ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಜೋಡಿ ಓದುವ ಸೂಚನೆ, ಎಂದಿಗೂ ತೀರ್ಪಲ್ಲ.
ನೀವು ಎಸ್ಕಲೇಟ್ ಮಾಡುವಾಗ ಜೋಡಿ, ಮಾರ್ಗ ಗುರಿ ಮತ್ತು ಪರಿಹಾರವಾದ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಒಂದೇ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಇಡಿ. ಆಗ ಮುಂದಿನ ಇಂಜಿನಿಯರ್‌ಗೆ ಸೇವಾ ಹೆಸರನ್ನು ಮತ್ತೆ ವ್ಯಾಖ್ಯಾನಿಸುವ ಬದಲು ಪರೀಕ್ಷಿಸಲು ಮೂರು ಸ್ವತಂತ್ರ ವಿಷಯಗಳಿರುತ್ತವೆ. ಮಾತುಕತೆ ಇಲ್ಲದಿದ್ದರೆ ಅವರು ತಕ್ಷಣ ಕಾಣುತ್ತಾರೆ, ತಪ್ಪು ಗುರಿ ಆಮದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಗೈರುಹಾಜರಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಪರಿಹಾರವಾಗದ ಮುಂದಿನ ಹಾಪ್ ಮಾರ್ಗವನ್ನು ಇರುವಂತೆ ಆದರೆ ನಿರುಪಯುಕ್ತವಾಗಿ ಬಿಡುತ್ತದೆ.