...
CONFIG-RADIUS-UPSTREAM-SERVER
Пример
| Блок кода |
|---|
wlc-30(config-radius-upstream-server)# check-interval 10 |
...
Данная команда задаёт кол-во проверок статуса, на которые upstream RADIUS-сервер должен ответить подряд, прежде чем контроллер будет считать его активным (статус Up) .после
Если для сервера включен параметр check-status-force, то текущий параметр check-responses-count будет дополнительно отвечать за кол-во проверок статуса на которые upstream RADIUS-сервер должен не ответить подряд, прежде чем контроллер будет считать его недоступным (статус Down)
Параметр работает только если check-type имеет значение "request" или "status-server".
...
| Блок кода |
|---|
wlc-30(config-radius-upstream-server)# check-responses-count 5 |
| Якорь | ||
|---|---|---|
|
...
|
...
|
...
|
...
|
Данная команда включает принудительную проверку статуса upstream RADIUS-сервер в статусах "Up" и "Unknown"
...
После активации данного параметра контроллер начинает циклично проверять статус upstream RADIUS-сервера, отправляя запросы проверки статуса со своего адреса с интервалом check-interval и ожидать ответа в течении check-timeout.
Если upstream RADIUS-сервер, не отвечает на кол-во запросов подряд равное параметру check-responses-count, то такой сервер считается недоступным, статус "Down"
...
| Примечание |
|---|
|
...
CONFIG-RADIUS-UPSTREAM-SERVER
Пример
| Блок кода |
|---|
wlc-30(config-radius-upstream-server)# check-status-force |
...
none – отсутствует фоновая проверка статуса upstream RADIUS-сервера. Статус upstream RADIUS-сервера определяется при наличии фактических RADIUS-запросов.
request – по умолчанию фоновая проверка статуса начинает выполняться, когда upstream RADIUS-сервер находится в статусе "Detection" или "Down".
Если сконфигурирован параметр check-status-force проверки статуса будут выполняться, когда сервер находится в статусе "Up". Проверка выполняется через RADIUS-запрос с типом Access-Request или Accounting-Request (тип зависит от параметра параметра server-type), используется протокол PAP.
В запрос подставляются значения RADIUS атрибутов User-Name и User-Password, сконфигурированные через параметры check-type request username и check-type request password.
В целях безопасности рекомендуется, чтобы заранее сконфигурованная учетная запись пользователя отсутствовала на upstream RADIUS-сервере, т.к в рамках запроса статуса необходим фактический ответ, даже Access-Reject.. Результатом успешной проверки статуса является фактический ответ от сервера, независимо от того это Access-Accept или Acess-Reject
status-server – – по умолчанию фоновая проверка статуса начинает выполняться, когда upstream RADIUS-сервер находится в статусе "Detection" или "Down".
Если сконфигурирован параметр check-status-force проверки статуса будут выполняться, когда сервер находится в статусе "Up".
Проверка выполняется через RADIUS-запрос с типом Status-Server. В рамках запроса статуса с типом status-server необходим фактический ответ, даже Access-Reject.Результатом успешной проверки статуса является фактический ответ от сервера, независимо от того это Access-Accept или Acess-Reject
Значение по умолчанию
none
...
Описание методов проверки :статуса RADIUS-сервера
none – без фоновой проверки. Статус определяется только в момент запроса на серверепроксирования клиентского и получение успешного ответа от RADIUS-сервера;
status-server – отправка специальных пакетов формата пакетов "Status-Server" для подтверждения проверки статуса RADIUS-сервера; Результатом успешной проверки статуса является ответ на запрос, независимо от того, Access-Accept или Acess-Reject
request – отправка запроса используя протокол PAP с заранее сконфигурированными логином и паролем для подтверждения проверки статуса RADIUS-сервера. Результатом успешной проверки статуса является ответ на запрос от сервера, независимо от того, Access-Accept или Acess-Reject
Синтаксис
show radius-servers
...