Authentication, Security and Area Protection
Authentication, Security and Area Protection
This domain tests how OSPF adjacencies are protected and where the controls sit: per interface, per area, or per protocol version.
Core rules
- OSPFv2 supports null, simple password and MD5. MD5 keys are configured with a key ID and are carried in the packet; the receiver must have the same key ID and key.
- On SR OS,
authentication-typecan be set at area level and inherited by interfaces, or set per interface to override.message-digest-key <id> md5 <key>defines the key. - Authentication must match on both ends. A mismatch keeps the neighbour down; hellos are dropped before the state machine progresses.
- OSPFv3 has no OSPFv2-style authentication field. SR OS protects OSPFv3 with IPsec (AH or ESP) per interface, which also provides integrity.
- Area protection also includes passive interfaces (advertise the prefix without forming adjacencies) and filtering type 3 LSAs at ABRs with area ranges.
Worked example
An interface inherits area-level MD5, but a new key ID 2 is added only on R1. R1 sends with key 2 while R2 still expects key 1. The adjacency drops and stays down until key IDs match. During rollover, add the new key on both sides before switching the active key.
Traps that cost marks
- Assuming area-level authentication applies to OSPFv3 - it does not; OSPFv3 uses IPsec.
- Changing the key on one side only and expecting a graceful renegotiation.
- Using a passive interface where an adjacency is actually required; it will never come up.
- Forgetting that authentication failures show as dropped hellos, not as a specific neighbour state.