发布时间：2013-09-25
点击量：3408Radius服务器有三种状态：Ready，Active，Dead
Radius服务器通过CLI或者MIB添加到设备上，Radius服务器的初始化状态是Ready。当设备向服务器发送radius报文时，设备将radius服务器的状态改成Active，当设备收到radius服务器给设备的响应，即设备收到Access-response报文时，设备将radius服务器的状态重新改成Ready。如果设备在发送完报文之后，经过deadtime（分钟）之后，没有收到服务器的响应报文，则设备将radius服务器的状态改成Dead。
一些默认值：(这些参数可以通过命令show radius parameter来查看)
默认的报文超时时间：radius-server timeout 5 （5秒）
默认的报文重传次数：radius-server retransmit 3 （3次）
默认的服务器死亡时间：radius-server deadtime 5 （5分钟）
示例，如下配置：
radius-server host 1.1.1.1 -->服务器A
radius-server host 2.2.2.2 -->服务器B
其他都是默认配置，则整个服务器状态及服务器切换流程如下：
初始化状态服务器A和服务器B都是Ready状态。当用户做认证的时候，报文会先发送到服务器A进行认证，此时设备会将服务器A的状态改成Active。如果服务器A收到报文，并对报文响应，设备会将服务器A的状态改成Ready。如果设备没有收到radius报文(可能是配置的radius服务器地址不存在，也可能路由到不了，还有可能该IP可能没开radius服务器等)，过了5s之后，设备会继续向服务器A发送报文（这个时候称为重传）。服务器还是没响应，设备过5s之后，继续发送报文到服务器A（重传发生了3次）。然后设备就会把报文向服务器B发送。下一次用户做认证的时候还是同样操作，报文先发送到服务器A，服务器A没响应，再发送到服务器B。如果服务器A处于Active状态的时候超过5分钟，这个时候设备会认为服务器A处于Dead状态。这个时候再来一个用户做认证，报文就不发送到服务器A，而是直接发送到服务器B。
假设A已经处于dead状态，后续认证都只发向B，设备与服务器A之间就不会有任何报文交互，如果此时A又恢复了（比如开机或者重启好了），由于设备无法感知到A的这个事件，所以设备上针对A的dead状态不会有任何变化。也就是我们通常讲到的10.4（2）以前的软件版本上无法实现主服务器恢复可用后切换回主设备。除非此时B也dead，当所配置的radius group里面的所有服务器都dead，设备就会强制将所有服务器置为ready状态，循环上述过程。
该版本的切换原理，无法实现主服务器失效后又重新恢复可用的时候，认证可以再次回到主服务器，而是依然以备服务器为准，除非后续备服务器也故障。
文档评价
