RADIUS

What this chapter covers

The RADIUS chapter explains how routers hand user authentication and accounting to a central server.

Instead of keeping accounts on every router, you keep them in one place. The router asks the server whether a user may log in, and it reports the session afterwards. The server can even reach back and end or change a session that is already running.

This ties together the earlier chapters, because PPP services and the HotSpot can both use RADIUS.

How the topics fit together

The three pages cover the two ends of the conversation and the reverse channel.

The pages follow the order of a real deployment:

• The client is configured on the router. You add the server, set the shared secret and switch RADIUS on for each service.
• The server and User Manager hold the accounts, profiles and limits, and they must know each router.
• Incoming lets the server disconnect a user or change a limit while the session runs.

Every part depends on the same shared secret and on the right addresses. When something fails, those two checks solve most problems.

How to use these pages

Each topic page has the same shape, so you can skim for what you need.

• What it is: the idea in plain words.
• How it works: the mechanism, with diagrams and example commands.
• What to remember for the exam: the facts to memorise.
• Common mistakes: the classic traps.
• Check yourself: three questions to test your understanding.

The easiest lab uses two routers. One acts as the RADIUS client with a HotSpot or PPP service, and one runs User Manager as the server. Watch the counters in /radius monitor 0 while a test user logs in, and then try a wrong secret to see what a failure looks like.

Be careful when you enable RADIUS for router login. Always keep a local administrator account while you test.