On an airport's baggage-handling network, why do RADIUS and TACACS+ usually both run rather than one replacing the other?

## Two problems on the same switches Picture the network behind an airport's baggage handling: a few hundred switches in plant rooms and along the belt lines, with handheld scanners and access points hanging off them, and a small team of network engineers who maintain them. Two completely different access questions land on the same hardware. - **Network access.** A scanner powers up and needs to be on the network. The decision is per device, taken once, at high volume, and the answer is a description of the session — which segment, which filter, how long. - **Device administration.** An engineer opens the switch's command-line interface at three in the morning to change a port. The decision is per person, low volume, long-lived, and the interesting questions are which actions are permitted and what is recorded. They share nothing but the box they happen on. ## Why the axes point different ways Each axis in the comparison is decided by the shape of the decision, not by a preference: | Axis | Admission of a device | Administration of the device | |---|---|---| | Volume and duration | very many, very short | few, long and interactive | | Number of decisions | one per device | potentially one per command | | What the answer is | attributes describing a session | permit or refuse this action | | What must be recorded | that a session happened, and its usage | what was typed, by whom, when | | Natural transport | a datagram and a retry | a connection carrying a conversation | | Protection needed on the wire | the credential | the credential and what was typed | Read down the two columns and the protocol choice writes itself, which is the real content of this comparison. ## What collapsing onto one protocol costs **Device administration on the admission protocol.** You keep central authentication — that part works — but authorization arrives once, as attributes on the accept. What happens after login is then decided by the device's own mapping of that attribute onto what it will run, with no central per-action decision; and the audit trail records that a session occurred rather than what was done inside it. For an estate whose regulator asks 'who changed this switch, and to what', that is the whole requirement missing. **Admission on the device-administration protocol.** You would be opening a connection-oriented exchange for every supplicant on the network, on a protocol with no equivalent of the network-access side's carriage of authentication methods and no server-initiated way to change a live session. The volume is wrong, the mechanisms are absent, and the thing you gain — per-action decisions — has no meaning for a scanner that makes no commands. ## What running both actually costs This is the half candidates skip, and it is the half a senior interviewer is listening for: - **Two shared secrets on every device**, and two rotation exercises, on a fleet where touching every box is a project. - **Two server estates** to keep reachable, each with its own timeouts, its own ordering of servers and its own behaviour when nothing answers. - **Two failure modes.** A reachability failure on the admission side keeps scanners off the network; one on the administration side can keep the engineers off the switches, which is why local fallback is designed before the rollout rather than after the outage. - **Two record streams** to correlate when an investigation asks what happened on a device and who was on the network at the time. - **Two policy surfaces** that drift apart, maintained by people who often are not the same people. ## What actually decides it Start from the questions you must be able to answer, not from the protocols: 1. Do humans reach a device's command line at all? If every change goes through an automated configuration pipeline, the device-administration case shrinks to that pipeline's own credential and the record of what it pushed. 2. Must you show *what* was done, or only *that* access occurred? An audit obligation about actions is the single strongest argument for the per-command protocol, and it is usually the one that settles it. 3. How many devices, and how often do they join? Volume is what makes the one-decision protocol right on the access side and would make the other one wrong there. 4. What happens when the server is unreachable? Answer it separately for each plane, because the acceptable answers differ: refusing admission to a scanner and locking every engineer out of every switch are not comparable outcomes. The honest conclusion is the one the question is fishing for: an estate runs both, deliberately, and the skill is knowing which decision belongs in which and what the second protocol costs to operate.