C3850-24XU-L - Access to Radius from Management interface

[nicolas-madec]

Hello

I have five C3850. they have all the same configuration (except port configuration). 

I manage them trough the management interface gi0/0

I authenticate with a Radius

On all the switches, i have configured Radius authentication . The authentication configuration is excactly the same on all the switches (see below the configuration).

HOWEVER, on two of them, they can't contact the radius server when i autheticate, and i wonder why !!!!

Of course i have tested that the switches can contact the radius server with this command : ping vrf Mgmt-vrf 10.10.0.111

I have also test that there is no issue with firewall an this test is not rejected : telnet 10.10.0.111 1812 /vrf Mgmt-vrf

End, i have monitored the traffic on gi0/0 of failed switches and i note that when i try to authenticate there is no traffic going out the gi0/0 to reach the radius server (wheras on non failed switch the traffic is gouing ou the interface)

To resume : i have the feeling that event if they have the same configuration that the others, two switches don't send radius traffic trough the gi0/0 interface

Thank you for your help or suggestions

------ CONFIGURATION -------

aaa new-model
!
aaa authentication login default group radius local
aaa authorization exec default group radius local if-authenticated
aaa session-id common

interface GigabitEthernet0/0
description management
vrf forwarding Mgmt-vrf
ip address 10.11.87.24 255.255.0.0
speed 1000
negotiation auto

ip route vrf Mgmt-vrf 10.10.0.0 255.255.0.0 10.11.0.254
ip route vrf Mgmt-vrf 10.16.0.0 255.255.0.0 10.11.0.254

radius server XXXX
address ipv4 10.10.0.111 auth-port 1812 acct-port 1813
key 7 zzzzzzzzzz

[Seb Rupik]

Hi there,

Have you tried specifying the source interface:

!
ip radius source-interface gi0/0 vrf Mgmt-vrf
!

cheers,

Seb.

[nicolas-madec]

Does not work better. And moreover here is what is said about this "ip radius source address" :

#ip radius ?
source-interface Specify interface for source address in RADIUS packets

so i think it is just to specify the source ip address in the packet, but not influence the outgoing interface

thank you anyway :-)

[Mark Malone]

You could use ACLs and prevent radius traffic from talking out any other port than the G0/0 mgmt , thats how we did it for our MGMT protocols to lock them down to 1 port

Theres is feature called MPP too that forces certain MGMT traffic out its port this in IOS-XE but i dont think its available in 38s only ISRs IOS-XE ,i dont see any option for radius/tacacs either even in that so maybe the option to get it work

(config-cp-host)#management-interface gigabitEthernet 0 allow ?
beep Beep Protocol
ftp File Transfer Protocol
http HTTP Protocol
https HTTPS Protocol
snmp Simple Network Management Protocol
ssh Secure Shell Protocol
telnet Telnet Protocol
tftp Trivial File Transfer Protocol
tl1 Transaction Language Session Protocol

sounds like something else could be causing it though , are these switches in same policy grouping as the working ones in your ISE or Radius server whatever your using to authenticate , authenticating should have no effect on routing to an already reachable server , unless something is being pushed from the radius to the switch and causing it ?

[nicolas-madec]

thank you for your reply.
As said , i have monitored the management port with wireshark. And when i log to the switch and try to authenticate , i do not see any traffic going out the gi0/0 interface to the Radius IP. It means that when i try to authenticate,the switch does not try to reach the radius trough gi0/0. But i know the switch try something because i have this log :
Warning (4) RADIUS-4-RADIUS_ALIVERADIUS server 10.10.0.111:1812,1813 is being marked alive.
Warning (4) RADIUS-4-RADIUS_DEADRADIUS server 10.10.0.111:1812,1813 is not responding.

[marce1000]

 - If not yet find you may follow the test/debugging sequences from the document below :

   https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/113666-tg-ios-per-vrf-00.html

M.

[nicolas-madec]

Thank you for your suggestion
having changed my configuration, as suggested in the document

aaa new-model
!
!
aaa group server radius management
server-private 10.10.0.111 key HC4QwCMf
ip vrf forwarding Mgmt-vrf
ip radius source-interface GigabitEthernet0/0
!
aaa authentication login default group management local
aaa authorization exec default group management if-authenticated

But does not work better :-(