A cooperative centralizes administrator authentication through a RADIUS server at its main office, but POP routers in outlying towns sometimes lose connectivity to that office during fiber cuts. What should the authentication-order configuration include to keep local technicians able to log in during an outage?
Select an answer to reveal the explanation.
Short Explanation
A fiber cut that takes out the link to the main office shouldn't also lock every local technician out of the router sitting right in front of them. Adding the password method after radius in the authentication order gives Junos a local fallback the moment the remote server stops answering.
Full Explanation
Because authentication-order tries methods in sequence and falls through when one is unreachable, listing the password method after radius gives Junos a working local-account fallback the instant the RADIUS server becomes unreachable — exactly the scenario a fiber cut to the main office creates for an outlying POP. Configuring only radius removes that safety net: if the link is down, no administrator can authenticate at all, even standing in front of the device with correct local credentials, which turns a fiber outage into a total lockout. A syslog host isn't an authentication method at all — it's strictly a log destination and has no participation in verifying credentials. A second RADIUS server can be added to authentication-order as an additional entry, but it cannot be configured 'as the device's host-name' — those are entirely unrelated statements, one a list of authentication sources, the other a simple identification label. The broader design principle is that any centralized authentication scheme for a geographically distributed network needs a local fallback, or a single point of failure at the main office becomes a single point of failure for every remote site simultaneously. A good field check is to periodically test login with the RADIUS path deliberately blocked to confirm the fallback still works.