BQN 문서 - 문제 해결

설치 문제

다음을 확인하세요:

ISO는 MBR 파티션과 DD 모드가 있는 USB 드라이브에 복사되어 있어야 합니다.
서버 BIOS는 공장 출하 시 기본 부팅 모드(예: 듀얼)로 설정되어 있어야 합니다.
RAID 컨트롤러가 있는 경우 논리 드라이브를 구성하고 부팅 가능한 것으로 표시해야 합니다.
설치에 사용된 서버가 BQN 하드웨어 요구 사항을 충족하는지 확인합니다.
하드 디스크에 설치가 완료되었는지, USB 드라이브를 덮어쓰지 않았는지 확인합니다.

‍

관리 IP 주소에 액세스할 수 없음

BQN은 관리를 위해 전용 네트워크 인터페이스를 사용합니다. 관리 인터페이스는 SSH와 WEB(HTTP) 서비스를 모두 지원합니다. 구성된 관리 IP에 액세스하는 데 문제가 있는 경우 다음을 확인하세요:

관리 네트워크 인터페이스 포트가 적절한 네트워크에 연결되어 있는지 확인합니다.
관리 네트워크 인터페이스의 링크 상태가 켜져 있는지 확인합니다. 관리 인터페이스가 네트워크 스위치에 연결되어 있는 경우 스위치의 포트가 켜져 있고 해당 속성이 show interface 명령에 표시된 속성과 일치하는지 확인합니다.
다른 네트워크에서 관리 IP 주소에 액세스하는 경우 사용자 가이드의 네트워크 인터페이스 섹션에 설명된 대로 액세스 네트워크에 정적 라우팅이 구성되어 있는지 확인하세요.
관리 네트워크에 방화벽이 있는 경우 SSH 서비스의 경우 TCP 포트 22에, WEB 서비스의 경우 TCP 포트 443에 대한 액세스를 허용합니다.
시스템 콘솔을 사용하여 관리 IP 주소와 네트워크 접두사가 올바른지 확인합니다. 모니터와 키보드를 서버에 연결하고 루트로 로그인합니다:

 
bqn0:˜# bqnsh
root@bqn0# show interface management detail
Interface: en0o1
IP address: 192.168.0.121/24 
Default gateway: 192.168.0.1
Nameserver: n/a

OAM IP 설정이 잘못되었거나 알 수 없는 경우, 모니터와 키보드를 서버에 연결하고 루트로 로그인하여 대화형 모드에서 bta 마법사를 사용하여 변경합니다. 예를 들어, 관리 인터페이스를 IP 주소 10.10.10.12/24의 en0o1로 변경하려면 Enter 키를 누릅니다(제안된 응답을 수락하려면):

 
bqn0:˜# bqnsh
root@bqn0# wizard bta interactive
Available network interfaces:
  en0o1
  en0p0s0
  en0p0s1
Enter management interface [en0p0s0]: en0o1
Enable VLAN on management interface? (yes/no) [no]:
Enter management IP address and prefix [192.168.0.120/24]: 10.10.10.12/24
Enter default gateway IP address [192.168.0.1]: 10.10.10.1
Configure a nameserver? (yes/no) [no]:

Available network interfaces:
  en0p0s0
  en0p0s1
Select access-side interface for wire:  en0p0s0
Select internet-side interface for wire: en0p0s1
Enable SDR generation? (yes/no) [yes]:
Enter random optimization percentage [99]:
Enter random udr generation percentage [2]:
System vendor: Dell
System name: bqn
System serial: 0
System supported: yes
CPU model: 12th Gen Intel(R) Core(TM) i7-12700H
CPU cores: 4

Management interface:  en0o1
Management IP:         10.10.10.12/24
Management gateway:    10.10.10.1

Wire 1: en0p0s0(access)-en0p0s1(internet)

SDR generation: enabled

BTA random optimization: 99%
UDR random generation:   2%

If the proposed configuration is not valid execute the command
     wizard bta interactive
to manually enter the configuration.

Proceed with configuration? (yes/no) [yes]: yes


root@bqn0# show interface management detail
Interface: en0o1
IP address: 10.10.10.12/24
Default gateway: 10.10.10.1
Nameserver: n/a

root@bqn0# show interface management detail
Interface: en0o1
IP address: 10.10.10.12/24
Default gateway: 10.10.10.1
Nameserver: n/a

‍

변경 시 인터페이스를 사용할 수 없는 경우(예: wire)에는 재부팅을 요청하는 메시지가 표시됩니다. 재부팅 후 BQN에 새 IP 및 관리 네트워크 인터페이스가 있어야 합니다.

 
Management interface en0o1 seems not to be set. A process reboot may fix the problem. 
Proceeed with the process reboot? (yes/now) [yes]: yes

BQN 관리 인터페이스는 자체 방화벽으로 보호될 수 있습니다. 소스 IP 주소가 해당 방화벽 화이트리스트에 포함되어 있지 않은 것이 문제일 수 있습니다. 서브넷이 방화벽 규칙에 포함되지 않은 경우 BQN 관리 IP와 동일한 서브넷의 주소에서도 이러한 문제가 발생할 수 있습니다. 관리 포트에 대한 연결이 복원될 때까지 방화벽을 일시적으로 비활성화할 수 있습니다. 모니터와 키보드를 서버에 연결하고 루트로 로그인합니다:

bqn0:˜# bqnsh
root@bqn0# show interface firewall 
IFACE CHAIN RANGE
en0o1 input 10.0.0.0/8
en0o1 input 172.16.0.0/12
en0o1 input 192.168.0.0/16 
root@bqn0# clear interface en0o1 firewall input 
root@bqn0# show interface firewall 
IFACE CHAIN RANGE 
root@bqn0#

관리 IP에 연결할 수 있게 되면 허용된 소스 IP 범위의 새 화이트리스트를 정의할 수 있습니다.

If the command <span class="character-highlight">wizard bta interactive</span> fails, connect with a console and a keyboard and try changing the configuration directly. In the following example, the management interface is in en0o2 and we will move it to interface en0o1 and from IP address 192.168.0.121 to IP address 10.0.0.121, with default gateway 10.0.0.1:

bqn0:˜# bqnsh
root@bqn0# show interface management detail
Interface: en0o2
IP address: 192.168.0.121/24
Default gateway: 192.168.0.1
Nameserver: 8.8.8.8
root@bqn0# show interface
IFACE                TYPE       MAC                STATE LINK
lo0                  loopback   00:00:00:00:00:00  up    yes
en0o1                ethernet   ff:2f:6b:72:12:01  up    no
en0o2                ethernet   ff:2f:6b:72:12:02  up    yes
en0o3                ethernet   ff:2f:6b:72:12:03  up    no
en0o4                ethernet   ff:2f:6b:72:12:04  up    no
root@bqn0# configure
root@bqn0(config)# interface en0o2
root@bqn0(config-iface)# no ip address 192.168.0.121/24
root@bqn0(config-iface)# no management
root@bqn0(config-iface)# root
root@bqn0(config)# interface en0o1
root@bqn0(config-iface)# ip address 10.0.0.121/24
root@bqn0(config-iface)# management
root@bqn0(config-iface)# root
root@bqn0(config)# router static
root@bqn0(config-static)# route 0.0.0.0/0 via 10.0.0.1
root@bqn0(config-static)# root
root@bqn0(config)# commit
root@bqn0(config)# end
root@bqn0# exit
bqn0:˜#

‍

웹에 액세스할 수 없음

SSH를 사용하여 관리 IP 주소에 액세스할 수 있는지 확인합니다,
액세스에서 HTTPS를 사용하고 있는지 확인합니다(HTTP는 지원되지 않음). URL 예시: https://192.168.0.121
bqnadm 사용자를 사용하고 있는지 확인합니다(GUI 액세스에서 루트는 사용할 수 없음).
처음부터 설치하는 경우 명령 마법사 bta가 실행되었는지 확인하세요(그렇지 않으면 사용자가 생성한 bqnadm이 없는 GUI 웹 서비스가 활성화되지 않습니다).
BQN 서버의 SSH 포트가 변경되지 않았는지 확인합니다. 22번 포트가 아닌 다른 포트로 BQN에 접속하려면 접속 경로의 라우터에서 포트 포워딩 규칙을 정의할 수 있지만, BQN SSH 포트는 변경할 수 없습니다. 서버에 루트로 로그인하면 다음과 같이 SSH 포트가 22번인지 확인할 수 있습니다:

‍


bqn:~ # grep Port/etc/ssh/sshd_config
#Port 22
#GatewayPorts no

‍

필요한 경우 22 이외의 포트를 지정하는 줄에 댓글을 달면 됩니다.

사용 중인 브라우저가 지원되는지 확인합니다(엣지, 파이어폭스, 크롬). 예를 들어 MS Explorer는 지원되지 않습니다.

‍

네트워크 인터페이스 다운

대시보드의 네트워크 인터페이스 아이콘이 녹색이 아닌 경우.

구성-> 인터페이스-> 데이터로 이동합니다. Wires

‍

빨간색(위험)

wire 가 구성되어 있지 않으면 생성합니다.
wires 이 구성되어 있지만 인터페이스가 UP 상태가 아닌 경우, 이는 해당 인터페이스가 인텔과 호환되지 않는다는 의미일 가능성이 높습니다. 구성->인터페이스->데이터 Wires 로 이동하여 아래쪽 인터페이스를 클릭하여 모델(PCI 공급업체 ID)을 확인한 후 인텔이 아닌지 확인합니다. wire 을 제거하고 두 인터페이스를 모두 pcap 모드로 사용하여 새 인터페이스를 생성합니다. 이렇게 하면 인터페이스가 UP 상태가 되지만 처리량 용량이 훨씬 낮습니다(1Gbps 미만).
wires 구성이 되어 있고 인터페이스는 UP 상태이지만 LINK가 다운된 경우 다른 장비와의 연결에 문제가 있는 것입니다. 적절한 케이블/파이버를 사용하여 두 인터페이스 포트를 루프 형태로 서로 연결합니다. 두 인터페이스가 모두 UP 상태이면 다른 장비에 문제가 있는 것입니다.

링크가 여전히 다운되어 있고 광 포트가 사용되는 경우 트랜시버를 확인합니다:

인텔 호환 가능
가 지원됩니다(지원되는 네트워크 카드 목록은 지원되는 네트워크 카드 참조).
설치에 필요한 유형(예: 모노모드 광케이블이 있고 다른 쪽에 SFP+-LR이 있는 설치의 경우 SFP+-LR).

‍

노란색(알림)

다운된 것으로 표시된 wires 에 트래픽이 있는 경우 이전 섹션(심각)의 단계를 따르세요.
다운으로 표시되는 wires 을 사용하지 않고 알림 신호를 제거하려는 경우 사용하지 않는 wires 을 삭제할 수 있습니다. wire 구성을 변경하면 몇 초 동안 트래픽이 중지된다는 점을 고려하세요.

‍

역방향 트래픽

대시보드의 트래픽 역 전 아이콘이 주황색(경고)인 경우 업링크 방향의 트래픽 처리량이 다운링크 방향보다 많다는 것을 나타냅니다. 이는 소규모 배포(예: 실험실의 BQN처럼 100개 미만의 사용자)에서는 정상일 수 있지만 네트워크 배포에서는 액세스 포트가 인터넷 쪽에 연결되고 그 반대의 경우 wires 중 일부가 잘못 연결되었음을 나타냅니다.

이 사실을 확인하려면 통계->처리량->인터페이스로 이동하여 액세스 측에 구성된 wire 인터페이스를 선택합니다. 전송 처리량보다 수신 처리량이 더 많이 표시되면 wire 이 반전된 것입니다. 인터넷 측 인터페이스의 처리량을 선택하면 전송된 트래픽이 수신된 트래픽보다 큰 것을 확인할 수 있습니다.

문제를 해결하려면 구성->인터페이스->데이터 Wires 로 이동한 후 거꾸로 된 wire 에서 인터페이스 교체 아이콘을 누릅니다.

‍

낮은 트래픽

‍

대시보드의 트래픽 부족 아이콘이 녹색이 아닌 경우.

노란색(알림)

아이콘 위로 마우스를 가져가 트래픽 부족 알림이 표시되는지 확인합니다. 이는 BQN 서버를 통과하는 트래픽이 거의 없음을 나타냅니다. 시스템이 여전히 트래픽이 라우팅되기를 기다리고 있는 경우 이는 정상입니다. 그러나 운영 중인 시스템에서는 네트워크의 다른 곳에서 장애가 발생하여 트래픽이 BQN 서버에 도달하지 못하고 있음을 나타낼 수 있습니다.

‍

주황색(경고)

아이콘 위로 마우스를 가져갑니다. 트래픽 업링크 또는 트래픽 다운링크 중 하나가 경고 상태여야 합니다. 이는 해당 방향으로 BQN을 통과하는 트래픽이 없으므로 트래픽이 비대칭이기 때문입니다. 문제가 해결되는 동안 구성->TCPO/ACM 설정으로 이동하여 전체 TCP 최적화를 꺼짐으로 설정해야 합니다.

BQN이 양방향(업링크 및 다운링크)을 모두 볼 수 있도록 트래픽 라우팅을 수정합니다. 완료되고 아이콘이 녹색으로 돌아오면 구성->TCPO/ACM 설정으로 이동하여 전체 TCP 최적화를 활성화합니다.

‍

라이선스 관리자

대시보드의 라이선스 관리자 아이콘이 노란색이고 텍스트에 "license-mgr-connection:notice"라고 표시된 경우, BQN 서버가 라이선스 관리자와 연결할 수 없기 때문입니다. 라이선스 매니저는 BQN SW 라이선스 검증을 담당하며, Bequant 에 서버 문제를 보고하여 보다 적극적인 지원을 제공할 수 있도록 도와줍니다.

BQN 서버가 라이선스 관리자 IP에 대한 발신 연결을 시작할 수 있는지 확인합니다(자세한 내용은 Bequant 지원팀에 문의).

발신 연결이 가능한지 확인하려면 루트로 로그인하고 제공된 IP와 포트에 텔넷이 작동해야 합니다:


bqn0:˜# telnet ip port
Trying ip...
Connected to ip.
Escape character is '^]'.

‍

라이선스 확인 불가

대시보드의 라이선스 아이콘이 빨간색이고 텍스트에 "라이선스 사용 가능: 위험" 또는"라이선스 만료: 위험"이라고 표시되면 유효한 라이선스가 없는 것입니다. 이는 여러 가지 이유 때문일 수 있습니다:

노드에 정의된 라이선스가 없습니다.
라이선스가 유효하지 않습니다.
라이선스가 더 이상 유효하지 않습니다(최종 날짜가 만료됨).

유효한 라이선스는 대리점에 문의하세요.

라이선스 상태는 관리-> 라이선스에서 확인할 수 있습니다.

유효한 라이선스가 없는 경우, BQN은 모든 트래픽을 투명하게 전달합니다. 서비스에는 영향을 미치지 않지만 트래픽에 BQN 고급 처리가 적용되지 않습니다.

‍

라이선스 한도 초과

대시보드의 라이선스 아이콘이 주황색이고 텍스트에 "라이선스 사용: 경고"라고 표시되면 라이선스의 최대 용량이 초과된 것입니다(BQN 서버 전체 트래픽이 라이선스 한도를 초과함).

‍

라이선스 업그레이드는 총판에게 문의하세요.

라이선스 용량은 관리->라이선스에서 확인할 수 있습니다.

통계->처리량->개요에서 최근 처리량 수준과 함께 라이선스 제한이 빨간색 선으로 표시됩니다.

라이선스 한도를 초과하는 것은 일시적이어야 하며 라이선스는 적절한 용량으로 업그레이드됩니다.

라이선스 제한이 초과되면 QoE는 패킷을 삭제하지 않고 단순히 패킷을 연결합니다.

트래픽에 미치는 영향은 흐름과 사용자 세션 수준에서 다릅니다.

유량 수준에서의 효과:

라이선스 한도를 초과하는 동안에는 새 플로우에 라이선스가 없습니다.
라이선스를 초과하기 전의 기존 흐름은 영향을 받지 않습니다. 최적화 중이었다면 그대로 유지되며, 라이선스가 없는 경우에도 마찬가지입니다.
최적화된 트래픽이 한도 아래로 떨어지면 새로운 흐름이 다시 최적화됩니다.
라이선스가 한도 이하로 내려가기 전의 기존 흐름은 영향을 받지 않습니다. 라이선스가 없는 경우 그대로 유지되며, 최적화 중인 경우에도 마찬가지입니다.
라이선스가 없는 플로우에는 TCPO, 셰이핑이 없으며 메트릭(재전송, 지연 시간, DPI 등)을 생성하지 않습니다.

사용자 세션 수준에서 효과:

라이선스 한도를 초과하는 동안 새 사용자 세션에는 라이선스가 없습니다.
라이선스가 초과되기 전의 기존 사용자 세션은 처음에 현재 상태로 유지됩니다. 최적화 중이었다면 그대로 유지되며, 라이선스가 없는 경우에도 마찬가지입니다.
라이선스가 한도 이상으로 유지되는 경우, 최적화 중인 사용자 세션에 최적화되지 않은 흐름이 많이 누적되면 라이선스 없음으로 전환될 수 있습니다.
최적화된 트래픽이 한도 아래로 떨어지면 새로운 사용자 세션이 다시 최적화됩니다.
라이선스가 한도 이하로 떨어지기 전에 종료하는 사용자 세션은 처음에 라이선스가 없는 경우 현재 상태로 유지되며, 최적화 중인 경우에도 마찬가지로 유지됩니다.
라이선스가 한도 이하로 유지되는 경우, 라이선스가 없는 사용자 세션이 소수의 최적화된 플로우를 축적하는 경우 최적화 세션으로 전환될 수 있습니다.
라이선스가 없는 사용자 세션에는 ACM, 속도 제한이 없으며 트래픽 볼륨 합계가 계속 생성됩니다. 할당량 볼륨 보고가 일시 중단됩니다. 할당량 소진 시 차단이 수행되지 않습니다. 재전송, 지연 시간 등과 같은 다른 지표는 최적화 중인 플로우의 지표로 축소됩니다.
최적화 중인 사용자 세션은 일부 플로우에 라이선스가 없을 수 있다는 사실의 영향을 받게 되며, 따라서 사용자 은 정상 작동에 비해 측정값이 줄어들 수 있습니다. 이는 ACM과 해당 사용자 에 대해 생성된 지표에도 영향을 미칩니다.

라이선스 한도를 초과하면 점점 더 많은 트래픽이 더 이상 QoE 기능을 사용하지 못하게 되며, 반대로 QoE 기능을 사용하는 트래픽의 양이 줄어듭니다. QoE 기능을 받는 트래픽의 양이 라이선스 한도 미만이 되면 새 플로우와 사용자 세션이 QoE 기능을 다시 얻게 됩니다. 이 동작은 라이선스 한도를 초과할 때까지 계속되며, 그 이후에는 효과가 다시 반복됩니다. 이러한 진동 동작을 통해 QoE는 라이선스 한도까지 트래픽에 기능을 계속 제공합니다. BQN은 처리량 수준과 라이선스 한도를 지속적으로 확인하므로(매 1분 이내) 적응이 매우 빠릅니다.

‍

높은 CPU 부하

대시보드의 CPU 아이콘이 녹색이 아니라면 일부 CPU가 비정상적으로 높은 수준에서 실행되고 있는 것입니다. 이는 일반적으로 트래픽의 불균형( 사용자 IP 몇 개에 집중됨) 또는 BQN 서버에서 처리하는 트래픽이 너무 많기 때문입니다.

BQN은 이러한 상황을 완화하기 위한 내부 메커니즘을 갖추고 있으며, 최적화된 트래픽 양을 줄여 트래픽 손실을 방지하기 위해 노력하고 있습니다.

처리량 수준은 통계->처리량->개요에서, CPU 수준은 통계->시스템->CPU에서 확인할 수 있습니다.

CPU 부하 수준에 따라 두 가지 알람 유형이 있습니다:

일부 CPU 코어의 부하가 높으면(80% 이상 사용) 주황색입니다.
일부 CPU 코어의 부하가 매우 높은 경우(사용률 90% 이상) 빨간색으로 표시됩니다.

다음 단계를 따르세요:

BQN과 끝 사용자 사이에 NAT를 사용하는 경우 NAT에서 사용하는 IP 수를 늘려서 BQN이 더 많은 주소에 트래픽을 분산할 수 있도록 합니다. 통계->사용자->시간별 상위에서 트래픽이 IP 간에 어떻게 분산되는지 확인할 수 있습니다.
바이패스 경로를 활성화하거나, 가능하지 않은 경우 BQN을 통해 라우팅되는 트래픽의 양을 줄입니다.
구성->TCPO/ACM 설정에서 TCP 최적화를 비활성화합니다.
하드웨어 업그레이드가 필요할 수 있습니다. Bequant 지원팀에 문의하세요.

BQN 서버를 TCPO 및/또는 흐름별 속도 제한에만 사용하는 경우, CPU 부하 분산을 개선하여 흐름별 스티어링을 활성화할 수 있습니다. 플로우별 조정을 사용하면 기본사용자 트래픽 분산 대신 개별 플로우별로 CPU 코어에 트래픽 부하를 분산합니다. 이렇게 하면 CPU 부하 균형이 개선되지만사용자 제어는 코어별로 수행되므로 ACM, 정책 비율 또는 사용자 흐름 제한과 같은 사용자 수준 제어는 허용되지 않습니다.

‍

높은 메모리 부하

대시보드의 메모리 아이콘이 녹색이 아니라면 일부 프로세스의 메모리가 부족한 것입니다. 이는 일반적으로 트래픽의 불균형(트래픽이 몇 개의 사용자 IP에 집중됨) 또는 BQN 서버에서 처리하는 트래픽이 너무 많기 때문입니다.

BQN은 이러한 상황을 완화하기 위한 내부 메커니즘을 갖추고 있으며, 최적화된 트래픽 양을 줄여 트래픽 손실을 방지하기 위해 노력하고 있습니다.

처리량 수준은 통계->처리량->개요에서 , 메모리 수준은 통계->시스템->메모리에서 확인할 수 있습니다.

메모리 로드 수준에 따라 두 가지 알람 유형이 있습니다:

일부 프로세스가 높은 사용량(사용률 90% 이상)에 도달하면 주황색입니다.
일부 프로세스가 매우 높은 사용량(사용량 95% 이상)에 도달하면 빨간색으로 표시됩니다.

다음 단계를 따르세요:

BQN과 끝 사용자 사이에 NAT를 사용하는 경우 NAT에서 사용하는 IP 수를 늘려서 BQN이 더 많은 주소에 트래픽을 분산할 수 있도록 합니다. 통계->사용자->시간별 상위에서 트래픽이 IP 간에 어떻게 분산되는지 확인할 수 있습니다.
바이패스 경로를 활성화하거나, 가능하지 않은 경우 BQN을 통해 라우팅되는 트래픽의 양을 줄이세요.
구성->TCPO/ACM 설정에서 TCP 최적화를 비활성화합니다.
하드웨어 업그레이드가 필요할 수 있습니다. Bequant 지원팀에 문의하세요.

수신된 RADIUS 메시지가 없습니다.

BQN GUI에 RADIUS 정보가 표시되지 않는 경우, RADIUS 메시지가 수신되는지 확인하려면 BQN 셸에 로그인하여 다음 명령을 실행합니다:


$ ssh bqnadm@192.168.0.121
bqnadm@bqn# system interface en0o1 capture filter 'udp and port 1813'
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes

이 예제에서 관리 인터페이스는 eno1입니다. 구성->인터페이스->관리에서 BQN 서버 중 하나를 확인합니다(예: BQN GUI의 en0s1f0은 Linux에서는 ens1f0입니다).

BQN 방화벽이 구성된 경우(구성->인터페이스->관리 방화벽), 모든 RADIUS 클라이언트 IP를 추가해야 합니다(이 예에서는 10.10.10.10 및 10.10.10.11).

‍

이제 RADIUS 메시지가 수신되어야 합니다:


bqnadm@bqn# system interface en0o1 capture filter 'udp and port 1813'
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:21:20.177347 IP 10.10.10.10.60072 > 192.168.0.121.radius-acct: RADIUS, Accounting Request (4), id: 0xf0 length: 222
14:21:20.177424 IP 192.168.0.121.radius-acct > 10.10.10.10.60072: RADIUS, Accounting Response (5), id: 0xf0 length: 20
. . .

‍

RADIUS 메시지가 여전히 수신되지 않으면 나머지 트래픽 점프에 대한 확인이 필요합니다. 이 예제에서 RADIUS 클라이언트는 서브넷 10.10.10.0/24에 있고 BQN은 서브넷 192.168.0.0/24에 있습니다. 두 서브넷 사이에 유효한 경로가 있는지, 중간 방화벽이 UDP 포트 1813(RADIUS 계정)을 차단하고 있지 않은지 확인해야 합니다. RADIUS 클라이언트에서 확인을 시작할 수 있습니다. 예를 들어, Mikrotik인 경우 도구->투어에서 포트 radius-acct를 사용합니다.

RADIUS 메시지를 수신했지만 정보가 예상대로 반영되지 않으면 ssh를 통해 BQN 서버 셸에 들어가는 이벤트 로그를 활성화합니다:

bqnadm@bqn# configure
bqnadm@bqn(config)# api common
bqnadm@bqn(config-api)# event level general
bqnadm@bqn(config-api)# event level radius
bqnadm@bqn(config-api)# event level policy
bqnadm@bqn(config-api)# event level subscriber
bqnadm@bqn(config-api)# root
bqnadm@bqn(config)# commit
bqnadm@bqn(config)# end
bqnadm@bqn#

GUI에서 상태->인터페이스->링크 상태에서 관리 인터페이스를 선택하고 "udp 1812 및 udp 1813"을 필터로 사용하여 트래픽을 캡처할 수도 있습니다:

‍

이제 수신된 RADIUS 요청의 이벤트 로그를 확인할 수 있습니다:

bqnadm@bqn# show api event log
2023-05-24T18:16:32.138 [radius] Sent Accounting-Response message to 172.27.1.194:42043: id(134)
2023-05-24T18:16:32.138 [radius] Received Accounting-Request message from 172.27.1.194:42043: id(134) statusType(start) framedIpAddress(10.0.0.11) mikrotikAddressList() mikrotikRateLimit(45M/90M 90M/100M 45M/90M 5/5)
2023-05-24T18:16:32.138 [policy] Created "RA-45M/90M-90M/100M-45M/90M-5" policy: rate(45000/90000) burstRate(90000/100000) burstDurationMs(5000/5000) burstThreshold(45000/90000) burstThresholdWindow(-1/-1) burstTransitionDurationMs(-1/-1) autoCongestionManagement(yes/yes)
2023-05-24T18:16:32.138 [subscriber] Updated "10.0.0.11" subscriber: policy(RA-45M/90M-90M/100M-45M/90M-5) sessionId(1234) userName(Sub-102) callingStationId(+34100100102) nasId() nasPort(4294967295)
2023-05-24T18:16:32.157 [radius] Sent Accounting-Response message to 172.27.1.194:22090: id(75)
2023-05-24T18:16:32.157 [radius] Received Accounting-Request message from 172.27.1.194:22090: id(75) statusType(start) framedIpAddress(10.0.0.12) mikrotikAddressList() mikrotikRateLimit(10M/20M 0K/0K 0K/0K 0/0)
2023-05-24T18:16:32.157 [subscriber] Updated "10.0.0.12" subscriber: policy(RA-10M/20M-0K-0K-0) sessionId(1234) userName(Sub-103) callingStationId(+34100100103) nasId() nasPort(4294967295)
. . .

‍

REST 메시지가 수신되지 않음

GUI에 REST 정보가 표시되지 않는 경우, BQN 셸에 로그인하여 다음 명령을 실행하면 BQN에서 REST 메시지 수신 여부를 확인할 수 있습니다:

‍


$ ssh bqnadm@192.168.0.121
bqnadm@bqn# system interface en0o1 capture filter ‘tcp and port 3443’
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes

‍

이 예제에서 eno1은 관리 인터페이스입니다.

서버에서 구성->인터페이스->관리로 이동하여 확인합니다(BQN 구성으로 추가된 0을 제거합니다. 예: BQN GUI의 en0s1f0은 UNIX에서는 ens1f0입니다).

BQN 방화벽이 구성된 경우(구성->인터페이스->관리 방화벽) 모든 REST 클라이언트의 IP를 추가해야 합니다(이 예에서는 10.10.10.10 및 10.10.10.11).

이제 메시지가 수신되어야 합니다:

‍

bqnadm@bqn# system interface en0o1 capture filter ‘tcp and port 3443’
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:30:30.767149 IP 192.168.88.12.48316 > 192.168.88.13.ov-nnm-websrv: Flags [S], seq 639501187, win 64240, options [mss 1460,sackOK,TS val 3813494325 ecr 0,nop,wscale 7], length 0
17:30:30.767163 IP 192.168.88.13.ov-nnm-websrv > 192.168.88.12.48316: Flags [S.], seq 2135448282, ack 639501188, win 28960, options [mss 1460,sackOK,TS val 607264358 ecr 3813494325,nop,wscale 5], length 0
17:30:30.767260 IP 192.168.88.12.48316 > 192.168.88.13.ov-nnm-websrv: Flags [.], ack 1, win 502, options [nop,nop,TS val 3813494325 ecr 607264358], length 0
. . .

‍

REST 메시지가 아직 수신되지 않으면 나머지 트래픽 단계를 확인하세요. 이 예에서 REST 클라이언트는 10.10.10.0/24에 있고 BQN은 192.168.0.0/24에 있습니다. 두 서브넷 사이에 유효한 경로가 있고 중간 방화벽이 TCP 포트 3443을 차단하고 있지 않은지 확인합니다.

REST 메시지를 수신했지만 정보가 예상대로 반영되지 않은 경우, 이벤트 로그 및 추적 기능을 활성화하여 ssh를 통해 BQN 서버 셸로 들어갑니다:

bqnadm@bqn# configure
bqnadm@bqn(config)# api common
bqnadm@bqn(config-api)# event level general
bqnadm@bqn(config-api)# event level rest
bqnadm@bqn(config-api)# event level policy
bqnadm@bqn(config-api)# event level subscriber
bqnadm@bqn(config-api)# root
bqnadm@bqn(config)# api rest
bqnadm@bqn(config-rest)# trace request 5
bqnadm@bqn(config-rest)# trace response 5
bqnadm@bqn(config-rest)# root
bqnadm@bqn(config)# commit
bqnadm@bqn(config)# end
bqnadm@bqn#

‍

이제 수신된 REST 요청의 이벤트 로그를 볼 수 있습니다. 다음 예제에서는 BQN이 사용자 를 평가 정책에 할당하는 일부 POST를 수신합니다:

bqnadm@bqn# show api event log
2023-05-24T17:41:40.268 [subscriber] [10.0.0.3] Updated subscriber: policy(rest-static-3) sessionId() subscriberId(n/a) customerId(1) name() mac() nasId() nasPort(4294967295) change(0x71)
2023-05-24T17:41:40.268 [rest] [172.27.1.194:49428] Send HTTP response: code(200) httpLength(70) contentLength(0) hdrExt(0)
2023-05-24T17:41:40.296 [rest] [172.27.1.194:49434] Received HTTP request: method(POST) hdr(44/248) uri(/api/v1/subscribers/10.0.0.4) authorization(Basic) contentLength(56) connection(0) transferEncoding(0x0)
2023-05-24T17:41:40.296 [subscriber] [10.0.0.4] Created subscriber: policy(rest-static-1) sessionId() subscriberId(sub-4) customerId() name() mac() nasId() nasPort(4294967295) change(0x7fff)
2023-05-24T17:41:40.296 [rest] [172.27.1.194:49434] Send HTTP response: code(201) httpLength(75) contentLength(0) hdrExt(0)
. . .

‍

그리고 마지막 요청과 응답의 추적은 /opt/bqn/var/trace 디렉터리에서 찾을 수 있습니다:

bqn0:~ # ls -al /opt/bqn/var/trace/rest*
-rw-r--r-- 1 root root 318 May 24 15:14 rest-req-0000
-rw-r--r-- 1 root root 364 May 24 11:30 rest-req-0001
-rw-r--r-- 1 root root 358 May 24 11:30 rest-req-0002
. . .

‍

REST 메시지가 거부됨

‍

예를 들어 REST API 요청에서 인증서 확인과 관련된 오류가 발생하는 경우입니다:


curl -i -m 20 -u myuser:mypassword -X GET https://192.168.0.120:3443/api/v1/subscribers -H "Content-Type: application/json"
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

그 이유는 BQN 인증서가 자체 서명되어 있고 클라이언트에서 인증서 유효성 검사를 비활성화해야 하기 때문입니다. 예를 들어, curl을 사용합니다:


curl -i -k -m 20 -u myuser:mypassword -X GET https://192.168.0.120:3443/api/v1/subscribers -H "Content-Type: application/json"

그리고 파이썬을 사용합니다:


import requests
import base64
 
 
credentials = "myuser:mypassword"
encoded_credentials = base64.b64encode(credentials.encode()).decode()
URL = https://192.168.0.120:3443/api/v1/subscribers
headers = {
    "accept": "application/json",
    "authorization": f"Basic {encoded_credentials}"
}
 
response = requests.get(URL, headers=headers, verify=False)

BQN은 TLS 1.2를 사용합니다. 일부 새 버전의 파이썬은 기본적으로 TLS 1.2를 거부합니다. 이를 허용하도록 하려면 다음 코드를 사용하세요:


import requests
from requests.adapters import HTTPAdapter
PY_VERSION = platform.python_version().split('.')
if int(PY_VERSION[1]) >= 7:  # 3.7 or more
  from requests.packages.urllib3.util.ssl_ import create_urllib3_context

class BqnRestAdapter(HTTPAdapter):
    """
    Adapter to control the level of security of SSL sessions of HTTPS requests.
    Needed to avoid issues depending on the python/requests/openssl versions.
    """
    # We use python 3.7 defaults
    CIPHERS = ('DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK')

    def init_poolmanager(self, connections, maxsize, block=False):
      context = create_urllib3_context(ciphers=BqnRestAdapter.CIPHERS)
      context.check_hostname = False
      pool = super(BqnRestAdapter, self)
      pool.init_poolmanager(connections=connections,
              maxsize=maxsize,
              block=block,
              ssl_context=context)
      return pool

    def proxy_manager_for(self, connections, maxsize, block=False):
      context = create_urllib3_context(ciphers=BqnRestAdapter.CIPHERS)
      context.check_hostname = False
      pool = super(BqnRestAdapter, self)
      pool.proxy_manager_for(connections=connections,
              maxsize=maxsize,
              block=block,
              ssl_context=context)
      return pool
      
  ...
      
  uriRoot = "https://192.168.0.120:3443/api/v1"
  session = requests.Session()
  session.verify = False
  session.auth = ("myuser", "mypassword")
  session.headers =  {
      "Content-Type": "application/json; charset=utf-8",
      "Accept-Charset": "utf-8"
  }
  session.mount(uriRoot, BqnRestAdapter())
   
  response = session.get(uriRoot + "/policies/rate?policyId=1")

이에 대한 전체 예는 여기에서 확인할 수 있습니다.

‍

청구 메시지가 수신되지 않습니다.

‍

청구 시스템이 구성되어 있고 대시보드의 청구 아이콘이 빨간색이면 청구 시스템에 대한 액세스가 실패한 것입니다.

청구 아이콘을 클릭하면 청구 상태 페이지로 이동합니다:

이 예에서는 12:13:52에 1000 사용자 을 검색하는 동기화에 성공했지만 이후 한 번의 동기화 시도가 실패했습니다. 지금 동기화 버튼을 눌러 동기화를 강제로 시도할 수 있습니다.

오류가 계속되면 다음 단계를 따르세요:

청구 구성이 올바른지 확인합니다(방향 및 자격 증명).
청구 IP 주소가 BQN 서버에서 연결 가능한지 확인합니다:

bqnadm@bqn# net ping 192.168.0.122
PING 192.168.0.122 (192.168.0.122) 56(84) bytes of data.
64 bytes from 172.27.1.194: icmp_seq=1 ttl=64 time=0.169 ms
64 bytes from 172.27.1.194: icmp_seq=2 ttl=64 time=0.180 ms
64 bytes from 172.27.1.194: icmp_seq=3 ttl=64 time=0.152 ms
^C
bqnadm@bqn#

ssh를 통해 BQN 서버 셸에 들어가는 API 로그를 활성화합니다:


bqnadm@bqn# configure
bqnadm@bqn(config)# api common
bqnadm@bqn(config-api)# event level general
bqnadm@bqn(config-api)# event level billing
bqnadm@bqn(config-api)# event level policy
bqnadm@bqn(config-api)# event level subscriber
bqnadm@bqn(config-api)# commit
bqnadm@bqn(config-api)# end
bqnadm@bqn#

이제 BQN과 청구 시스템 간의 이벤트 로그를 볼 수 있습니다. 다음 예제에서는 BQN이 Azotel 청구에 연결하여 10개의 사용자 에 연결된 3개의 정책을 검색합니다:


bqnadm@bqn# show api event log
2022-12-09T10:43:54.480 [billing] Sent HTTP POST request: uri(/restapi/listCustomerBucketData) host(172.27.1.194:443)
2022-12-09T10:43:54.482 [policy] Updated "AZ-1000-500" policy: rate(500/1000)
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.1 subscriber: policy(AZ-1000-500) block(no) customerId(10) name(Subscriber_number_10) nickname()
2022-12-09T10:43:54.482 [policy] Updated "AZ-2000-1000" policy: rate(1000/2000)
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.2 subscriber: policy(AZ-2000-1000) block(no) customerId(11) name(Subscriber_number_11) nickname()
2022-12-09T10:43:54.482 [policy] Updated "AZ-3000-1500" policy: rate(1500/3000)
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.3 subscriber: policy(AZ-3000-1500) block(no) customerId(12) name(Subscriber_number_12) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.4 subscriber: policy(AZ-1000-500) block(no) customerId(13) name(Subscriber_number_13) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.5 subscriber: policy(AZ-2000-1000) block(no) customerId(14) name(Subscriber_number_14) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.6 subscriber: policy(AZ-3000-1500) block(no) customerId(15) name(Subscriber_number_15) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.7 subscriber: policy(AZ-1000-500) block(no) customerId(16) name(Subscriber_number_16) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.8 subscriber: policy(AZ-2000-1000) block(no) customerId(17) name(Subscriber_number_17) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.9 subscriber: policy(AZ-3000-1500) block(no) customerId(18) name(Subscriber_number_18) nickname()
2022-12-09T10:43:54.482 [subscriber] Created 10.0.0.10 subscriber: policy(AZ-1000-500) block(no) customerId(19) name(Subscriber_number_19) nickname()
2022-12-09T10:43:54.482 [billing] Updated 10/10 billing subscribers
bqnadm@bqn#

오류가 있는 경우 로그에 어떤 일이 발생했는지 어느 정도 표시되어야 합니다.

또한 로깅을 BQN과 청구 시스템 간에 교환된 요청 및 응답의 세부 추적까지 확장할 수도 있습니다:


bqnadm@bqn# configure
bqnadm@bqn(config)# api billing
bqnadm@bqn(config-api)# trace request 5
bqnadm@bqn(config-api)# trace response 5
bqnadm@bqn(config-api)# commit
bqnadm@bqn(config-api)# end
bqnadm@bqn#

그리고 BQN은 BQN과 청구 시스템 간의 마지막 5개의 요청 및 응답에 대한 추적을 생성합니다. 추적은 /opt/bqn/var/trace 디렉터리에서 찾을 수 있습니다:


bqn0:~ # ls -al /opt/bqn/var/trace/billing*
-rw-r--r-- 1 root root  224 Apr 13 18:43 /opt/bqn/var/trace/billing-req-0000
-rw-r--r-- 1 root root  224 Apr 13 18:43 /opt/bqn/var/trace/billing-req-0001
-rw-r--r-- 1 root root 1955 Apr 13 18:43 /opt/bqn/var/trace/billing-rsp-0000
-rw-r--r-- 1 root root 1955 Apr 13 18:43 /opt/bqn/var/trace/billing-rsp-0001
. . .

최후의 수단으로, 청구 시스템 API 규칙에 따라 UNIX curl 명령을 사용하여 BQN에서 청구 시스템으로 직접 요청을 보낼 수 있습니다. 예를 들어 Azotel 청구에 쿼리를 보내려면 다음과 같이 하세요:


PS C:\Users\myuser>ssh root@bqn
bqn:~ # curl -H 'Accept: application/json' -H 'Content-Type: application/json' -X POST -d  '{"api_username": "myuser", "api_password": "mypassword", "allcustomers": "1"}' https://demo.azotel.com/restapi/listCustomerBucketData
{"ip":"10.10.0.12","result":0}
bqn:~ #

‍

동기화된 NTP 서버 없음

NTP 아이콘이 노란색이면 NTP가 구성되지 않은 것입니다. 아이콘을 클릭하여 구성 페이지로 이동합니다.

‍

NTP 서버가 구성되어 있지만 BQN이 그 중 어느 서버와도 동기화할 수 없는 경우 대시보드의 NTP 아이콘이 주황색으로 표시됩니다:

NTP 동기화 부족으로 인해 시스템 시간이 갑자기 변경되면 시스템이 조정되는 동안 잠시 서비스가 중단될 수 있습니다. 이런 일이 발생하지 않도록 항상 하나 이상의 NTP 서버를 동기화하세요.

‍

관리->시스템 날짜->NTP 서버에서 구성된 NTP 서버 목록을 확인할 수 있습니다.

하나 이상의 NTP 서버를 동기화해야 합니다. 위의 예에서는 시계 동기화를 위해 NTP 서버 145.238.203.14가 선택되었으며(서버 IP 주소 옆의 *로 표시됨) 36초 전에 연결되었습니다(WHEN 열).

NTP 서버를 사용할 수 없는 경우, 아래 창과 같이 BQN에 NTP가 동기화되지 않음이라는 경고 메시지가 표시됩니다:

‍

To solve the issue, if you have a local NTP server, add it to the list clicking the <i class="fa-solid fa-ellipsis-vertical"></i> menu icon and selecting Add Server…

로컬 NTP 서버가 없는 경우, BQN 방화벽이 활성화된 경우 이를 포함하여 BQN 관리 IP에서 인터넷으로 연결되는 UDP 포트 123이 열려 있는지 확인하세요.

‍

디스크 문제

시스템 디스크의 상태를 확인하려면 대시보드의 디스크 아이콘을 클릭합니다:

디스크 저장 공간이 15% 미만이면 디스크 아이콘이 주황색(경고 상태)으로 표시됩니다.

문서 스타일링 태그

[.p-highlight] 로렘 입섬... [.p-highlight]

로렘 입섬 도르 시트 아멧, 콘섹테투르 아디피싱 엘리트. 에로스 엘리멘툼 트리스티크에 서스펜디스 바리우스 에님. 듀이스 커서스, 마이 퀴스 비베라 오르나레, 에로스 도르 인터둠 널라, 우트 코모도 디암 리베로 비타 에랏. 아이네안 포시 부스 니브 et 저주 커서스 아이디 루트룸 로렘 임페디트. Nunc ut sem vitae risus tristique posuere.

[.p-highlight-blue] Lorem ipsum... [.p-highlight-blue]]

[.p-highlight-red] Lorem ipsum... [.p-highlight-red]

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

단일 [.c-highlight]단어 한 칸 띄어쓰기 [.c-highlight] 스타일링에 대한 미리보기입니다.

싱글 미리보기 word mono-spaced 스타일링.