A public health clinic network enables the Generic TTL Security Mechanism (GTSM) on OSPF to harden adjacency formation. What is GTSM’s primary purpose in this design?
Select an answer to reveal the explanation.
Short Explanation
GTSM checks the TTL like a bouncer checking whether you walked over from next door—or somehow mailed yourself from across the Internet. Spoofed remote OSPF sessions struggle when only max-TTL neighbors are welcome. It’s hop-distance hardening, not LSA encryption.
Full Explanation
GTSM (TTL security) for OSPF expects packets with an appropriate TTL from a closely connected peer, mitigating certain remote spoofing attacks against session formation. A public-health clinic enabling GTSM on OSPF uses it as an adjacency-hardening control: OSPF packets must arrive with an expected TTL, typically from a directly connected peer, making remote spoofed sessions harder to form. Clinics should deploy it alongside—not instead of—proper authentication and interface filtering on exposed links.
GTSM does not encrypt OSPF LSAs with AES so packet captures cannot show link-state content. It does not replace OSPF authentication keys with RADIUS usernames for every hello. It does not force all OSPF interfaces into passive mode unless TTL is set to 255 outbound only; passive-interface remains a separate adjacency-suppression tool.
Exam caveat: both sides must agree on TTL security hop-count settings; mismatches prevent adjacency similarly to authentication mismatches and can look like mysterious neighbor failures. Operational check: enable matching GTSM on clinic links, confirm adjacency remains up for legitimate direct peers, review that multihop spoofed packets would fail the TTL check, and keep cryptographic OSPF authentication enabled alongside GTSM.