소개
이 문서에서는 액세스 제한(인증 및 권한 부여)과 RADIUS 서버로 전송되는 어카운팅 레코드를 지원하는 AAA(Throttling of RADIUS) 레코드 기능에 대해 설명합니다.
이 기능을 사용하면 Cisco 라우터에서 RADIUS 서버로 갑작스러운 레코드 버스트를 수용하기에 충분한 대역폭이 없는 경우 네트워크 혼잡 및 불안정을 방지하기 위해 적절한 조절 속도를 구성할 수 있습니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서의 정보는 ASR5k 플랫폼을 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
aaamgr이 RADIUS 서버에 높은 속도로 RADIUS 메시지를 보낼 경우(예: 많은 수의 세션이 동시에 다운될 경우 모든 세션에 대한 계정 중지 메시지가 동시에 생성) RADIUS 서버가 이러한 높은 속도로 메시지를 수신할 수 없을 수 있습니다.이 상황을 처리하려면 aaamgr에서 효과적인 속도 제어 메커니즘이 필요합니다. 이렇게 하면 aaamgr이 메시지를 최적의 속도로 전송하여 RADIUS 서버가 모든 메시지를 수신할 수 있으며 RADIUS 서버에서 과도한 로드 때문에 메시지가 삭제되지 않도록 할 수 있습니다.
작업 메커니즘
aaamgr이 구성된 속도로 RADIUS 서버로 메시지를 전송하면 메시지를 전체에 고르게 보냅니다
모든 메시지를 단일 버스트로 보내는 것보다 1초마다 다릅니다.컨피그레이션에 따라 초당 여러 개의 동일한 시간 슬롯으로 나누어집니다(슬롯당 특정 기간). 슬롯의 최소 기간
50밀리초입니다.
이 비율을 고려하여 구성해야 합니다.
- 수신 통화 비율,
- aaamgr 인스턴스 수
- RADIUS 서버가 메시지를 수신할 수 있는 속도 및
- 간격(어카운팅 컨피그레이션)
- 서버 선택에 사용되는 알고리즘
인증 서버 값에 대해 구성된 값이 너무 낮으면 병 목(Bottle Neck)이
혼잡 - 세션 설정 시간 초과로 인해 통화가 삭제될 수 있습니다.어카운팅 서버에 대해 낮은 값이 구성된 경우 대기열의 오버플로로 인해 많은 어카운팅 메시지 비우기가 관찰됩니다.
이 기능이 구성되면 두 번째 및 두 번째 기간의 시간 슬롯 수가 계산되어 반지름 레벨에 저장됩니다.메시지를 RADIUS 서버로 전송할 준비가 되면 할당량(이 시간 슬롯의 메시지 수)에 도달했는지 여부를 확인합니다.제한에 도달하지 않으면 메시지가 전송되고, 전송되면 메시지가 서버 수준 대기열에서 대기하여 이후 시간 슬롯에 전송됩니다.각 RADIUS 서버는 현재 시간 슬롯에서 전송된 메시지 수 및 시간 슬롯이 만료되는 시간에 대한 세부 정보를 보유합니다.대기 중인 메시지가 서버 수준 대기열에서 선택되면 인스턴스 수준 대기열의 헤드에 배치되므로 이전 메시지에 대한 기본 설정이 다른 새 메시지보다 유지됩니다.서비스를 위해 인스턴스 수준 큐의 메시지를 선택합니다.
AAMGR 큐
AAMGR에는 메시지에 대한 두 가지 유형의 대기열이 있습니다.
- 인스턴스 수준 큐
- 서버 수준 큐
메시지가 생성되면 처음에 서비스를 위해 인스턴스 레벨 대기열에서 대기됩니다.
인스턴스 수준 대기열은 50밀리초마다 25밀리초 동안 처리됩니다.인스턴스 수준 대기열에서 제거된 메시지는 RADIUS 서버로 전송하려고 시도합니다.일부 조건에서는 메시지를 보낼 수 없습니다(사용 가능한 대역폭이 없거나 사용 가능한 ID 없음). 이 경우 시도가 실패한 메시지는 서버 수준 대기열에서 대기됩니다.50밀리초마다 사용 가능한 ID가 있고 대역폭이 사용 가능한 메시지를 몇 개 선택하고 인스턴스 레벨 대기열의 맨 위에 놓습니다(이러한 메시지는 인스턴스 레벨 대기열에 있는 다른 메시지보다 오래됨).
어카운팅 메시지에 대한 속도 제어가 있고 인스턴스 레벨 대기열에 어카운팅 메시지가 많은 경우 새로운 인증 메시지는 인스턴스 레벨 대기열의 맨 끝으로 이동합니다.처리하려면 모든 어카운팅 메시지(새 인증 메시지 이전)가 RADIUS 서버로 전송되거나 서버 수준 큐로 이동될 때까지 기다려야 합니다.기존 동작이며 수정되지 않습니다.따라서 새 인증 메시지가 처리되기까지 약간의 지연이 발생할 수 있습니다.
예
값이 5인 max-rate를 기반으로, 1초 안에 5개의 메시지를 보낼 수 있으며, Radius 인증 서버에 대해 aaamgr당 해결되지 않은(기본 최대 미처리 컨피그레이션) 256개의 radius 인증 메시지를 보낼 수 있습니다.메시지가 5개 이상 있는 경우, AAA 서버가 기존 요청에 응답할 때까지 1초 동안 메시지가 대기열에 추가됩니다.
한 aaamgr에서 서버로 보낸 256개의 Radius 인증 메시지에 도달하면 나머지 요청은 AAA 서버가 기존 요청에 응답할 때까지 대기열에 추가됩니다.다시 max-rate와 동일한 대기열로 이동합니다.사용 가능한 슬롯이 있는 경우에만 메시지가 대기열에서 선택됩니다.메시지에 대한 응답을 받거나 시간이 초과되면 자유 슬롯이 입력됩니다.
제한 사항
Cisco ASR5K는 독립 sessmgr/aaamgr 쌍이 통화를 처리하는 분산 시스템이므로 독립 aamgr 인스턴스에 대해서만 속도 제한을 구현할 수 있습니다.전체 인스턴스 수와 최대 속도를 곱하여 단일 인스턴스의 비율을 전체 Cisco ASR5K 상자로 확장하는 것이 이론적입니다.
있습니다
이 숫자는 화창한 날 시나리오에서 절대 상한값입니다.Cisco ASR5K를 블랙박스로 처리할 수 없으며 시스템에서 표시된 계산된 값이 상한값을 초과하지 않는 경우 모든 통화가 성공한다고 가정할 수 없습니다.
Radius 최대 속도는 시스템과 관련된 다른 내부 및 외부 매개변수와 연결됩니다.조건 중 하나가 충족되지 않을 경우 예상되는 영향을 확인하십시오.
조건 |
Impact if not meet with(이(가) |
demuxmgr에서 모든 sessmgrs로의 통화 균일한 분포 |
통화 분배가 동일하지 않으면 radius 메시지가 일부 인스턴스에 대해 대기됩니다.따라서 이론상 최대 속도 제한에 도달하지 않더라도 메시지가 대기열에 있는 인스턴스에 대한 통화가 삭제됩니다. |
IMSI의 균일한 배포(경우에 따라 다름) Round-Robin 조정 회계) |
중재 회계 라운드 로빈은 IMSI 기반 라우팅을 기반으로 합니다. 이 경우 IMSI 배포를 기준으로 라우팅 로직을 기준으로 일부 서버 집합이 다른 서버보다 선호될 수 있으며, 통화 중단으로 이어지는 서버에 대해 큐가 구축될 수 있습니다. |
갑자기 전화가 폭주하는 일 없음 |
새 통화의 버스트가 있는 경우 새로 생성된 반지름 메시지가 시스템에서 대기열에 추가됩니다.새 RADIUS 요청이 처리될 때까지세션 설정 시간이 만료되어 통화가 끊어질 수 있습니다. |
RADIUS 서버는 적시에 응답해야 함 |
서버 문제로 인해 RADIUS가 시간 초과를 요청할 경우, 시스템에서 응답이 제거될 것으로 예상되는 현재 요청이 제거되지 않는 한 새 요청이 전송되지 않기 때문에 다시 큐 빌드가 발생합니다.시스템에서 시간 초과 메시지가 제거되는 속도는 최대 미처리 및 시간 제한 컨피그레이션에 따라 달라집니다. |
대부분의 경우 모든 활성 aaamgr 작업에서 액세스 요청이 처리되지 않음을 확인할 수 있습니다.즉, sessmgr 작업 내에서 통화 분배가 고르지 않고 모든 aaamgr 인스턴스가 통화 처리에 관여하는 것은 아닙니다.
통화 분배는 엄격한 라운드 로빈 메커니즘에 기반하지 않습니다. 수신 통화가 10개 있을 경우 단조 알고리즘으로 10개의 세스그램으로 이동합니다.
통화 분배는 다음 4가지 주요 요소를 기반으로 합니다.
- active_session_count
- cpu_load
- Round_trip_delay (demuxmgr - sessmgr - demuxmgr)
- outstanding_add_request(sessmgr에 demux)
이것이 현재 구현입니다.최대 속도는 상한에 불과하지만, Cisco 아키텍처의 분산형 특성 때문에 섀시 부하에 직접 적용할 수 없습니다.동작은 지정된 AAAmgr의 로드에 따라 달라집니다.
있습니다
RADIUS 최대 속도 큐를 사용하여 시스템의 상태를 모니터링해야 합니다.대기열 구축이 있는 경우
즉, 이 4(표 참조) 조건 중 하나가 충족되지 않으며 동일한 문제의 근본 원인을 파악해야 합니다.
**max-rate 대기열 임계값을 구현하고 지속적으로 모니터링할 수 있습니다.