The RADIUS route download mechanism periodically polls a RADIUS server for routes to download. The main objective of this feature is to download, in advance, customer-assigned subnets so that they can be re-advertised to the corresponding routing protocols. In this way, subscriber bring up can potentially be done faster (as the routes are already in place and advertised) and, most importantly, reduce the routing protocol churn as subscribers connect and disconnect. The routes being learned through this mechanism could be both managed routes/delegated prefixes as well as the WAN IP assigned to the subscriber in the case PPPoE and un-numbered interfaces are being used.
The route download process requests the routes to a configured RADIUS server by triggering an access-request message. The key identifier for this message is the username, which is a combination of the system’s name (or an optionally configured value), appended by a dash ( ‟-”) and then a monotonically increasing integer. The download process sends an access request starting with 1 (such as ‟hostname-1”) and the RADIUS server replies with an access-accept message and a number of routes embedded within the message. The system then increases the counter and sends another access request (this time being hostname-2) and receive a reply with the next batch of routes to download. The process continues, incrementing the counter by 1 each time until the system gets an access-reject or the maximum number of routes that can be downloaded is reached.
The routes to be accepted are in the following format:
[vrf {vprn-name | vprn-service-id}] prefix-mask {null0 | null 0 | black-hole} [metric] [tag tag-value]
The prefix-mask could be in any form as ‛prefix/length’, ‛prefix mask’ or ‛prefix’ (in the latter case, for IPv4 routes, the mask shall be derived from the IP class of the prefix).
The route formats are supported:
Framed-Route (RADIUS attribute 22)
Framed-Route = "192.168.3.0 255.255.255.0 null0"
Framed-Route = "vrf vrfboston 192.168.1.0/24 null 0 0 tag 6"
Framed-Route = "vrf 2001 192.168.10.0/24 black-hole 0 tag 8"
Cisco-AVPair (Cisco VSA 26-1)
cisco-avpair = "ip:route = 192.168.3.0 255.255.255.0 null0"
cisco-avpair = "ip:route = vrf vrfboston 192.168.1.0/24 null 0 0 tag 6"
IPv6 routes are also supported. The format is based on using the IETF-defined IPv6 Framed-IPv6-Route (attribute 99). The following text shows the supported formats.
Framed-IPv6-Route (RADIUS attribute 99)
Framed-Route = "vrf vrfboston 2100:5aaa:dead:beaf::/96 null 0 0 tag 6"
Framed-Route = "2001:100:bad:cafe::/64 null0"
All the routes downloaded are a new protocol type ‟periodic”. The download process re-starts the AAA requests after a specific interval (a configurable value but target refresh rate is 15 minutes) and routes shall be updated according to the following process:
When the router initiates a new download process, the routes are kept in a temporary table until the download process completes (receives an access-reject from the AAA). The temporary download table is then checked for errors and finally, any changes reflected to the actual routing table.
Routes no longer present in the download are removed from the routing table.
If the AAA server responds with an access-reject for the first username (that is, an implicit empty route-download table), all routes are removed from the routing table.
If there are any protocol errors (at the RADIUS level), such as time-out, no response, bad record format, too many records, and so on, the download process is suspended and retried after a configurable timer. The minimum retry timer is at least 1 minute and the light load this represents control-plane-wise (concurrent downloads are not supported) the retries can continue infinitely until the next refresh period occurs, where the download restarts from the beginning. An exponential backoff algorithm with a configured minimum and maximum delay is used to determine the retry timer.
The routes are only purged from the routing table after a complete download process was achieved (properly terminated with an access-reject message). Under any other failure condition, the routes shall remain active. Shutting down the download process should not remove the downloaded routes. A clear command clears the periodic routes.
All the imported routes (blackholes) are imported into the line-card FIBs to avoid the routing loops caused by announcing the prefixes but not installing the actual blackholes.