1、交换机上如何配置一级权限的用户授权创建vlan及划分vlan

参考命令如下:

privilege interface level 1 switchport access vlan//授权划分vlan

privilege interface level 1 switchport mode access //授权在接口模式划分端口为access模式

privilege config level 1 interface //授权在config模式进入接口

privilege config all level 1 vlan //授权在config模式创建vlan

privilege exec level 1 configure  //授权进入config模式

 

 

2、S21交换机如何设置用radius服务器做telnet登入认证

radius-server host 192.168.33.244

enable secret level 15 0 ruijie

!

interface vlan 1

 no shutdown 

 ip address 172.18.10.72 255.255.255.0

!

radius-server key ruijie

ip default-gateway 172.18.10.1

snmp-server community ruijie rw

line vty

login authentication radius

 

3、radius协议是否支持对命令进行授权

不支持,只有tacacs+协议才支持。

 

4、交换机开启AAA,用户telnet认证才输入用户名就提示认证失败

可能遇到开启AAA认证登入的设备,某个用户尝试几次登入失败后,再输入用户名就直接弹出认证失败的log,此时并没有要求输入密码的提示。

碰到该种情况,可能是该账户用户此前多次登入失败,尝试次数超限,账户直接被锁定的原因。可以先通过console口或者其他账户登入交换机后,用如下命令恢复。

ruijie#clear aaa local user lockout all

推荐增加配置

aaa local authentication attempts 10//配置尝试10次,默认是3次

aaa local authentication lockout-time 1     //配置锁定时间1小时,默认是15小时

username xxx password xxx

aaa authentication enable default group radius local// 定义AAA的enable认证策略,group组可以自行定义,在radius不通的时候,本地用户名密码作为备份,

                                       否则无法登陆,建议提前配置本地用户名、密码

 

5、交换机如何设置登录失败次数,被锁定的时间长度

配置 login 登录用户尝试超过配置登录失败次数,被锁定的时间长度

Ruijie(config)#aaa local authentication ?

attemptsAttempts for local user

lockout-time  Lockout time span

Ruijie(config)#aaa local authentication attempts ?

<1-2147483647>  Max attempts for local authen user

Ruijie(config)#aaa local authentication attempts 10

Ruijie(config)#aaa local authentication lockout-time ?

<1-2147483647>  Local authen lockout-time span (hour)

Ruijie(config)#aaa local authentication lockout-time 20

按照上面配置后实现可以尝试10次,如果10次没有输入对密码,那么会被锁住20小时,才能再次登入。

 

6、交换机如何指定认证的源接口地址

使用如下命令来指定认证的源接口地址:

Ruijie(config)#ip radius source-interface ?

AggregateportAggregate port interface

Dialer            Dialer interface

GigabitEthernet   Gbyte Ethernet interface

LoopbackLoopback interface

MultilinkMultilink-group  interface

NullNull interface

TunnelTunnel interface

Virtual-ppp       Virtual PPP interface

Virtual-template  Virtual Template interface

VlanVlan interface

Ruijie(config)#ip radius source-interface vlan 1

 

7、关于radius-server 各类dead时间参数说明

radius-server后面主要有如下几个超时时间的设置:

Ruijie(config)#radius-server ?

attributeCustomize selected radius attributes

dead-criteria  Dead-criteria

deadtime       Deadtime

hostHost address

keyKey to rds server

retransmitRetransmit

timeout        Timeout

1)radius-server dead-criteria time xx tries yy

交换机维护着每台radius服务器的状态,即服务器的状态是active还是dead,该条命令就是判断radius服务器是否dead的标准。默认情况60s(距离上次radius成功响应的时间),10次(设备向服务器发送报文而没有相应的次数)。也就是说交换机发给radius服务器的radius报文,60s*10次都没有响应,就认为radius挂了,那么如果有其他备用radius服务器,就切换到备用服务器认证,如果没有备用radius服务器那么就直接置为dead状态。如下:

Ruijie#show radius group

==========Radius group radius==========

Vrf:not-set

Server:192.168.33.238

Authentication port:1812

Accounting port:1813

State:Dead

2)radius-server deadtime xx

交换机认为服务器dead仍会向该服务器发送请求报文。我们可以通过配置命令radius-server deadtime使得设备在一段时间内停止往dead服务器发送报文。过了这段时间,设备会自动认为服务器是active。而默认值为0表示,设备还是一直会往该dead服务器发送报文。另外设备支持对指定服务器进行主动探测,默认是关闭。(可以通过配置测试用户来开启)

如果设备开启对服务器进行主动探测,deadtime的配置相当于没有作用。

3)radius-server timeout xx 及  radius-server retransmit yy

a、这个主要用来设置radius方法列表切换的。

假若你配置了如下设置:

aaa authentication dot1x ruijie group radius local

radius-server timeout 2

radius-server retransmit 2

b、也就是说正常情况下设备使用radius进行认证,假若radius服务器在2+2*2=6S内没有回应radius报文,那么认为服务器已经挂了,那么将切换到另外一个方法认证列表,使用本地local认证。如果本地还没有找到相应用户名和密码,那么就认证失败。

c、在radius服务器的逃生功能中可以通过如下设置来实现radius服务器的逃生功能

aaa authentication dot1x ruijie group radius none

radius-server timeout 2

radius-server retransmit 2

d、这里有一点非常需要注意的是dot1x timeout server-timeout 这个时间一定要大于timeout*(retransmit+1)这个值,dot1x timeout server-timeout值默认是5S。(why? dot1x timeout server-timeout是设置服务器最大响应时间,默认时间为5S,下联用户pc发给交换机eap报文,需要等待5s才认为服务器认证失败,那么如果设置timeout*(retransmit+1)值小于5s,如4s,那么在第4s后就进行认证切换,使用none认证方式,也即不认证,并返回客户端认证成功的报文。这样就ok了。否则就认证失败。)

e、另外这个与radius-server deadtime xx没有关系。

 

8、10.4(2)及以前版本的Radius服务器状态和服务器切换原理

Radius服务器有三种状态: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状态,循环上述过程。

       该版本的切换原理,无法实现主服务器失效后又重新恢复可用的时候,认证可以再次回到主服务器,而是依然以备服务器为准,除非后续备服务器也故障。

 

9、10.4(2)及以前版本在dot1x应用中主备radius切换的推荐配置

aaa new-model

aaa group server radius test

 server 1.1.1.1

 server 1.1.1.2

radius-server host 1.1.1.1 key admin

radius-server host 1.1.1.2 key ruijie

radius-server timeout 2     //向radius重传请求之前的等待时间(秒)

radius-server deadtime 5      //停止向不可达radius发送请求的时间(分)

radius-server retransmit 2//radius报文重传的次数

dot1x timeout server-timeout 15     //交换机端设置的服务器最大响应时间限制

aaa accounting update periodic 15

aaa accounting update

aaa accounting network ruijie start-stop group test

aaa authentication dot1x ruijie group test 

dot1x accounting ruijie

dot1x authentication ruijie

注意:

1)timeout*(retransmit+1)这个时间一定要小于客户端(比如我司的SU)本身默认的超时时间(不可修改),最小是9S,这样才能认证成功,否则客户端认证失败。软件不会自动继续尝试,当然你可以手动重新运行SU,再开始一次认证。

2)dot1xtimeout server-timeout 5 (单位是s,默认是5s)这个值必须大于timeout*(retransmit+1),否则交换机会判断此次认证失败。

3)总结下,timeout*(retransmit+1)< server-timeout < SU(9s)

4)以上两种参数设定的不合理,不会导致认证永远不成功,或者是服务器切换不成功,只会影响用户端可能需要尝试认证多次而已,切换时间慢(当然这里忽略设备对于1x重认证的次数与间隔时间的限制)。

 

10、10.4(3)及以后版本的Radius服务器状态和服务器切换原理

Radius服务器的状态只有两种:Active,Dead。

Active->Dead

radius服务器的死亡判断条件是(即从Active->Dead),同时满足两个条件:

1)距离上次收到该RADIUS服务器的正确响应超过radius-server dead-criteria time seconds设定的时间。

2)在上次收到该RADIUS服务器的正确响应之后,设备发往该RADIUS服务器的请求而未收到正确响应的次数(包括重传),达到radius-server dead-criteria tries number设定的次数。

这边有一个需要注意的是由于配置了radius-server timeout,radius-server retransmit(有默认值),当timeout*(retransmit+1)的总时长小于dead-criteria time,或者是retransmit+1小于dead-criteria tries number的时候,也就是此时设备已经检测到主服务器不可用了,需要切换到下一个服务器,但是主服务器由于还没有达到Active->Dead的两个条件,所以主服务器的状态还是Active的,而不是dead,只有当后续的其他用户继续认证,累计dead-criteria time以及dead-criteria tries number到配置值的时候才会变到dead状态。

Dead->Active

1)设备接收到正确的radius响应报文,比如开启了radius主动探测功能。

2)在未配置主动探测的情况下,处于Dead状态的时间比deadtime还长。

一些默认值:

radius-server deadtime 0   //该配置导致的结果就是主服务器永远不会dead,也就是所有的认证都需要先经过主服务器判断,这样每个用户都需要经历timeout*(retransmit+1),切换时间比较长

radius-server timeout 5    //5s

radius-server retransmit 3 //3次

radius-server dead-criteria time 60 tries 10   //60s,10次

示例,如下配置:

radius-server host 1.1.1.1   -à服务器A

radius-server host 2.2.2.2   -à服务器B

radius-server deadtime 5

radius-server timeout 5

radius-server retransmit 3

radius-server dead-criteria time 30 tries 5

            刚开始的时候,服务器A和服务器B的状态都是Active。用户做radius认证,设备先将报文发送到服务器A,若服务器A对该报文有响应,则服务器A的状态仍然是Active。该用户后续再做认证,记账等请求时,设备先查看上一次认证的服务器,如果该服务器仍旧处于Active状态的话,则设备直接发送报文到该服务器做认证,否则,查找用户属于的服务器组的第一个处于Active状态的服务器。若服务器A对报文没有响应,则做重传操作。默认情况下deadtime = 0,如果没有配置主动探测的话,服务器的状态是永远处于Active状态。也就是说下一个用户来做认证,还得先跑到服务器A做认证,然后才能在服务器B 上认证成功。如果这个时候配置radius-server deadtime 5 ,这样如果服务器A满足死亡条件,则服务器A的状态变成Dead,过了五分钟才会重新变成Active。

==》未开启主动探测功能

按照上面的示例配置来说就是第一个用户认证,经过timeout*(retransmit+1)=5*(3+1)=20s时间还没有得到服务器响应,那么该用户就切换到B认证,但是此时A服务器并不会dead,第二个来认证的用户与第一个用户类似,经历20s后切换到B,第三个来认证的用户经历20s,这样经过前三个用户的认证,总共尝试了60s,12次,达到了active-dead的条件,radius-server dead-criteria time 60 tries 10,这样服务器A就切换到dead状态,不可用。第四个用户认证的时候就直接送到B服务器认证,这样后续用户的认证时间就会比较快速。当然A服务器处于dead的时间达到radius-server deadtime 5min的时候,又重新变到active状态,这样A,B服务器回到最初的状态,循环上述的过程。当然上述过程还有一个需要说明的情况就是这里举的三个用户是依次来的,时间做累计60s,实际情况也可能是并发的,或者是每个用户认证间隔很长时间,但是这些没关系,因为Active->dead是需要同时满足两个条件的,所以当两者都达到后才会切换状态。

==》开启主动探测功能

radius-server host 1.1.1.1 test username TEST idle-time 1 key ruijie//1代表1min

radius-server host 2.2.2.2 test username TEST idle-time 1 key ruijie

no radius-server deadtime

a)该功能就是需要交换机模拟一个用户,采用TEST,ruijie账号与radius-server主动完成一次认证过程,来检测server是否active。这个功能的认证过程与上述不开启主动探测的过程是一样的,所有的测试,切换原理都不发生变化,只是交换机模拟了一个用户,加快,或者说是定期的检测一下server的可达性,与普通的用户认证无差别。

b)开启这个主动探测功能的主要用途是1、防止当server已经宕机的时候,但是由于没有用户来认证,无法马上感知到server不可用,当后续有真正的用户要认证的时候,需要经历比较长的等待;2、就是当某台服务器dead的时候,可以通过主动探测的机制,及时的发现服务器恢复可用,避免等待radius-server deadtime时间。

c)开启这个主动探测由于是每个idle-time都会往所有的服务器去发起这个认证请求,所以需要考虑交换机设备本身的负载,以及radius-server设备本身的性能,来选定一个合适的idle-time,避免设备过载而误检测,特别是在网络设备特别多的环境下。

 

 

11、10.4(3)及以后版本在dot1x应用中主备radius切换的推荐配置

aaa new-model

aaa group server radius test

 server 1.1.1.1

 server 1.1.1.2

radius-server host 1.1.1.1 key admin

radius-server host 1.1.1.2 key ruijie

radius-server timeout 2//向radius重传请求之前的等待时间(秒)

radius-server deadtime 10      //停止向不可达radius发送请求的时间(分)

radius-server retransmit 2//radius报文重传的次数

radius-server dead-criteria times 30 tries 5   //判定服务器为dead的条件,30s内尝试5次都无响应则判定为dead状态,后续认证请求直接发送给备份服务器,

dot1x timeout server-timeout 15     //交换机端设置的服务器最大响应时间限制

aaa accounting update periodic 15

aaa accounting update

aaa accounting network ruijie start-stop group test

aaa authentication dot1x ruijie group test 

dot1x accounting ruijie

dot1x authentication ruijie

注意:

1)timeout*(retransmit+1)这个时间一定要小于客户端(比如我司的SU)本身默认的超时时间(不可修改),最小是9S,这样才能认证成功,否则客户端认证失败。软件不会自动继续尝试,当然你可以手动重新运行SU,再开始一次认证。

2)dot1xtimeout server-timeout 5 (单位是s,默认是5s)这个值必须大于timeout*(retransmit+1),否则交换机会判断此次认证失败。

3)总结下,timeout*(retransmit+1)< server-timeout < SU(9s)

4)以上两种参数设定的不合理,不会导致认证永远不成功,或者是服务器切换不成功,只会影响用户端可能需要尝试认证多次而已,切换时间慢(当然这里忽略设备对于1x重认证的次数与间隔时间的限制)。

 

12、配置RADIUS 动态授权扩展的技术介绍

1)RADIUS动态授权扩展协议(Dynamic Authorization Extensions to RemoteAuthentication Dial In User Service),在IETF的RFC3576中进行定义。该协议定义了一种针对用户下线管理方法。设备和RADIUS服务器之间通过Disconnect-Messages(简称DM)消息,将已认证通过的用户下线。该协议使得不同厂商间的设备和RADIUS服务器,在用户下线的处理上能够兼容。

2)DM消息机制,由RADIUS服务器主动向设备发起用户下线请求,设备依据请求报文中携带的用户会话、用户名等信息来匹配用户并对其进行下线处理,然后将处理结果以回应报文形式返回给RADIUS服务器,以实现服务器对用户的下线管理功能。

3)DM功能采用的是UDP端口号3799来通信,默认关闭,所以如果需要采用该功能做 踢用户下线的情况,需要配置开启功能命令

radius dynamic-authorization-extension enable

4)目前比较常见的是与城市热点的认证服务器对接的时候,该认证服务器当检测到用户不在线,或者异常下线后,就主动发起这样的扩展协议,告知交换机,清用户在线表(show dot1x summary的表),这样保证该用户后续可以再次认证。

5)DM功能,目前只有2900G-E系列交换机的10.4_2b12版本,5750-S的10.4_3T86(大连理工用的版本)两个版本支持,其他型号及其他版本还未支持

----截止2013年5月30日

 

13、10.X交换机配置radius-server key密文显示后,show run发现密文不同时间会显示不一样 ?

首次show run显示结果:
service password-encryption

radius-server key 7 06142b0a251c17

 

隔几分钟再次show run显示结果:

service password-encryption

radius-server key 7 13170743072817

 

这个是早期10.X软件设计方式导致的正常效果,原先的软件设计加入了时间随机数参与密文的显示,主要是防止show run的时候密文一直保持不变,可能会被穷举破解,安全性不高,而每次show run显示的密文不同的话,可以降低被破解的可能性。

如果碰到该类问题,需要同客户解释下不会引起密码改变,只是显示效果不同。当然如果对于银行,政府等部分网管软件可能会定期的检测设备running-config文件是否有变化而言,这个密文的不定期改变是会引起网管软件的误报。

目前已知的10.4(3),10.4(2),10.4(2b2)及以前的软件存在此类问题(由于软件版本分支较多,目前无法统计完全确切的存在问题的所有版本,所以以实际设备运行效果为准),此时可以考虑升级各产品对应的最新的软件版本来尝试解决,比如10.4(3b16)p1,10.4(3b17)p3,10.4(2b12)p1及以后解决,如果部分停产产品无更新的软件的话,目前无法解决,需要让软件厂商进行特殊处理下。

 

14、login 是否可以调用AAA 域认证

10.X设备只有1X认证支持域认证,其他的都不支持。