Working with BT platform RADIUS

One of the features of BT WBMC is the use of platform RADIUS which is a pre-connection RADIUS authentication request from BT before L2TP connects. Specifically, it allows the L2TP endpoint to be specified.

The FB6000 goes one step further and handles the specific way that BT handle platform RADIUS for both 20CN and 21CN broadband lines making it easy to manage connections.

How BT handle platform RADIUS

Normally a WBMC link has two WES circuits each with a /30 IPv4 address block. Typical installation is to have two FB6202 L2TP servers, one on each, with an interface facing BT on the /30 block and an interface facing the ISPs core network.

The BT side can be done as a separate routing table, but this is not that useful. So typically the FB6202 has BGP to BT and BGP to the ISPs network.

BT allow two (or, theoretically, more) platform RADIUS IPs. The traffic to these is master and slave, i.e. secondary is only used if first does not respond.

By default these come in on either WES link, even if the IPs are announced by BGP only one one of the WES links!

Also, they typically alternate links and alternate IPs. This means you cannot, for example, sensibly use the /30 address as a platform RADIUS as you could find consistent wrong IP on wrong link which in the event of a link failure can mean 100% platform RADIUS failure.

What BT actually do is have an internal IP block (typically a /30 allowing 4 addresses) and route the RADIUS to two of these. These then NAT to your chosen IPs.

Routing to right RADIUS server

The way to direct the platform RADIUS is to announce BTs own NAT IP to BT. The recommendation is to pick two separate IPs for platform RADIUS, typically from your LAN side. One of the FB6202s considered as master and announces the primary NAT IP /32 from that to BT. The other announces the secondary NAT IP /32 to BT. Both FB6202s have both platform RADIUS IPs as loopback addresses. They answer platform RADIUS with their own IP for L2TP.

This means you can change which is master and which is secondary by changing which announces which /32 BT NAT IP. This works on-the-fly ans is very useful if you want to change which is master, and then systematically ppp kill all lines to flip them to the new master LNS, perhaps over night.

You may want to announce the /30 covering all NAT IPs from both. If one fails then both platform RADIUS then go to the other.

Note that you will also need to define IPs for the L2TP endpoints, probably from your LAN, and announce these as /32 from the corresponding FB6202 to BT as well. This ensures the L2TP traffic goes direct to the right LNS FB6202. You cannot use the /30 endpoint for L2TP for some reason (BT!)

BT 21CN Platform RADIUS

The above system simply means that the current master LNS gets the platform RADIUS and responds directing L2TP traffic to itself. As such all traffic goes to the master LNS. This is important for traffic shaping aggregate 20CN and 21CN links to BT to avoid nasty 100th percentile burst charging.

In the event of failure the platform RADIUS goes to the secondary LNS. This is either because BT fall back to the secondary IP, or if BGP fails (e.g. WES link fails) then the primary platform RADIUS IP effectively moves to the secondary LNS.

For 21CN you can also direct sessions to any other LNS which BT can access directly, using simple pattern matching on logins.

BT 20CN Platform RADIUS

The platform RADIUS works the same for 20CN except that BT ignore the response and then connect at random to one of the two LNSs. This is a problem as you want all sessions on the primary LNS.

To avoid this the l2tp tunnel config for 20CN connections can have require-platform set to true. This then rejects tunnels and sessions that are sent where no platform RADIUS has been received on that LNS. Normally there is no platform RADIUS cached at all, so the tunnel can be rejected. In this case BT will immediately try the other LNS without dropping the end user connect (or so it seems). If there is a cached platform RADIUS then the tunnel is allowed and the session, but the session will be closed once the connection details are received and they do not match any cached platform RADIUS. This causes the connection to the end user to drop and retry with a 50/50 chance of hitting the other LNS. Either way the wrong-LNS session is not accepted.

BT circuit IDs

In addition to steering the sessions as you wish, the platform RADIUS system in the FB6202 also ties the calling number (circuit ID) sent on the platform RADIUS to the L2TP connection. If there is no circuit ID on the L2TP connection (as is usually the case within BT) then the connection is treated as if the calling number from platform RADIUS was sent. This means you can see circuit IDs on your RADIUS authentication without having to correlate platform RADIUS from BT.

Stray connections

Occasionally BT will not see a platform RADIUS response, though this is being improved within BT. This can also happen when there are a lot of connections at once. This means the occasional connection can get to the wrong LNS. This is something you may wish to mop up yourself by killing these tray connections from time to time.

FireBrick 6000 series