This turned out to be that stopping the IAS service (as I was doing to test) is not enough to cause a failover- the server must actually be non-pingable or truly down. When I shut it down completely it failed over.
This means that if the IAS service stops or is stopped inadvertently- no fail over and no access. To protect against this we setup our monitoring software to check the two IAS servers IAS service is running
I don’t know that it played a role but the settings I used were:
Default Retries (1-10) 4
Default Timeout for Reply (1-30) (Sec) 1
Default Dead Time (0-2000) (Min) 10 (to allow reboots for updates etc)
I had read the help links associated with those settings, but with so many variables it seems very hit and miss to test with.I'm only piloting 3 ports with .1x but it is my production network at this time after working out the other settings in a lab environment. I’ll forge ahead but if anyone has some starting point suggested settings for two Radius serves on a fast LAN connection I’d love to know what worked- either in a round robin fashion or just fault tolerant. I’ll update any progress I make. Thanks
puckstopper
4 Posts
1
May 14th, 2012 09:00
This turned out to be that stopping the IAS service (as I was doing to test) is not enough to cause a failover- the server must actually be non-pingable or truly down. When I shut it down completely it failed over.
This means that if the IAS service stops or is stopped inadvertently- no fail over and no access. To protect against this we setup our monitoring software to check the two IAS servers IAS service is running
I don’t know that it played a role but the settings I used were:
Default Retries (1-10) 4
Default Timeout for Reply (1-30) (Sec) 1
Default Dead Time (0-2000) (Min) 10 (to allow reboots for updates etc)
Default Key String (0-128 Characters)
Source IPv4 Address
Source IPv6 Address (X:X:X:X::X)
DELL-Willy M
802 Posts
0
May 7th, 2012 19:00
Have you tried implementing any of these features?
– Number of Retries (1-10) — Enter the number of requests sent to the
RADIUS server before a failure occurs.
radius-server timeout
Use the radius-server timeout Global Configuration mode command to set
the time interval during which the device waits for a server host to reply. Use
the no form of this command to restore the default configuration.
– Timeout for Reply (1-30) — The amount of the time in seconds that
the device waits for an answer from the RADIUS server before retrying
the query, or switching to the next server.
radius-server deadtime
Use the radius-server deadtime Global Configuration mode command to
configure the time interval during which unavailable RADIUS servers are
skipped over by transaction requests. This improves RADIUS response time
when servers are unavailable. Use the no form of this command to restore the
default configuration.
– Dead Time (0-2000) — The amount of time (in minutes) that a
RADIUS server is bypassed for service requests.
They are discussed with CLI examples starting on page 252 of the CLI User Guide.
55xx CLI User Guide:
http://support.dell.com/support/edocs/network/pc5524/en/CLI/PDF/en_cli.pdf
Hope this helps,
puckstopper
4 Posts
0
May 8th, 2012 07:00
Thanks for your input Willy M-
I had read the help links associated with those settings, but with so many variables it seems very hit and miss to test with.I'm only piloting 3 ports with .1x but it is my production network at this time after working out the other settings in a lab environment. I’ll forge ahead but if anyone has some starting point suggested settings for two Radius serves on a fast LAN connection I’d love to know what worked- either in a round robin fashion or just fault tolerant. I’ll update any progress I make. Thanks