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 변경하면 일정 시간 동안(서버 구성에 따라 10초에서 2분 사이) 트래픽이 중단된다는 점을 유의하시기 바랍니다.

‍

역방향 트래픽

대시보드의 ‘트래픽 역방향’ 아이콘이 주황색(경고)으로 표시되어 있다면, 이는 업링크 방향의 트래픽 처리량이 다운링크 방향보다 더 많음을 나타냅니다. 소규모 환경(실험실의 BQN처럼 사용자 100명 미만인 경우)에서는 정상적인 현상일 수 있지만, 네트워크 환경에서는 액세스 포트가 인터넷 측에 연결되거나 그 반대의 경우처럼 일부 wires 잘못 wires 나타내는 경우가 대부분입니다.

이것이 사실인지 확인하려면, [상태] > [인터페이스] > [처리량] 으로 이동하여 액세스 인터페이스에서는 수신된 트래픽보다 더 많은 트래픽이 전송되고, 인터넷 인터페이스에서는 그 반대의 현상이 나타나는지 확인하십시오. 만약 그렇지 않다면, wire 반대로 wire 있음을 나타내는 것입니다.

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

이제 ‘상태->인터페이스->처리량’에서 액세스 인터페이스의 전송 트래픽이 수신 트래픽보다 더 많이 표시되어야 합니다 :

‍

낮은 트래픽

‍

대시보드의 ‘저 트래픽 ’ 아이콘이 노란색이며 ‘알림’ 상태입니다.

아이콘 위에 마우스를 올려놓으면 ‘트래픽 저조’ 알림이 표시되는지 확인하십시오. 이는 BQN 서버를 통과하는 트래픽이 매우 적음을 나타냅니다. 시스템이 아직 해당 서버를 통해 라우팅될 트래픽을 대기 중인 경우라면 이는 정상적인 현상입니다. 그러나 실제 운영 중인 시스템에서는 네트워크의 다른 곳에서 발생한 장애로 인해 트래픽이 BQN 서버에 도달하지 못하고 있음을 나타낼 수도 있습니다.

‍

비대칭 트래픽

‍

비대칭 트래픽은 BQN 서버가 트래픽 방향 중 하나(업링크 또는 다운링크)만 감지하고 다른 방향은 감지하지 못할 때 발생합니다.

비대칭 트래픽은 BQN을 통과하는 모든 트래픽에 영향을 미칠 수도 있고, 일부에만 영향을 미칠 수도 있습니다.

TCP 최적화는 대칭 트래픽을 필요로 하므로, 비대칭 트래픽은 사용자 저하를 초래하며, 문제가 해결될 때까지 해당 트래픽에 대해서는 TCPO를 비활성화해야 합니다.

모든 트래픽은 비대칭적이다

대시보드의 ‘저 트래픽 ’ 아이콘이 주황색이며 ‘경고’ 상태입니다.

‍

아이콘 위에 마우스를 올려보세요. ‘Traffic-uplink’ 또는 ‘Traffic-downlink’ 중 하나가 경고 상태라면, 해당 방향으로 BQN을 통과하는 트래픽이 없음을 의미하며, 따라서 트래픽이 비대칭 상태임을 나타냅니다. ‘Traffic-uplink ’와 ‘Traffic-downlink’가 모두 경고 상태라면, BQN을 통과하는 트래픽이 없거나 극히 적으며, 비대칭 상태는 아닙니다.

해당 트래픽에서 TCPO를 비활성화하려면, ‘구성(Configuration)’ > ‘최적화 설정(Optimization Settings)’으로 이동하여, 비대칭 현상을 유발하는 트래픽 라우팅 문제가 해결될 때까지 ‘전체 TCP 최적화(Overall TCP Optimization )’ 스위치를 비활성화하십시오.

일부 트래픽은 비대칭적입니다

대시보드의 ‘저 트래픽’ 아이콘은 녹색으로 표시되어 ‘정상’ 상태임에도 불구하고, 서비스 품질 저하에 대한 고객 불만이 접수되고 있습니다.

일부 트래픽이 비대칭적인지 확인하려면, [상태] >사용자> [QoE 지표] 로 이동한 후, 사용자 필터를 설정하여 업링크(MBYTES-DOWN) 또는 다운링크(MBYTES-UP) 방향 중 어느 한쪽의 사용자 표시되도록 하십시오.

멀티캐스트 또는 브로드캐스트 IP 주소는 제외하십시오. 이러한 IP 주소의 경우 트래픽이 한 방향으로만 발생하는 것은 지극히 정상적인 현상입니다. 예를 들어, IPv4의 255.255.255.255 브로드캐스트 주소나 IPv6의 ff02:: 로컬 링크 멀티캐스트 주소와 같이,

한 방향으로는 0바이트인 일반 IP 주소가 보이고 반대 방향으로는 상당한 양의 트래픽이 발생하는 경우, 해당 IP 주소는 비대칭 트래픽 문제를 겪고 있는 것입니다. 이 문제는 대개 잘못된 트래픽 라우팅으로 인해 발생하므로, 동일한 서브넷에 속한 다른 IP 주소들도 같은 문제를 겪게 될 것입니다.

라우팅이 수정되는 동안 해당 트래픽에서 TCPO를 비활성화하려면, ‘구성(Configuration)’ >사용자 (사용자사용자 )’로 이동하여 TCP 최적화가 비활성화된 플로우 정책을 생성하고, 해당 사용자 주소/범위가 포함된 액세스 프로필을 생성한 다음 이를 규칙과 연결하십시오. 자세한 내용은 이 예시를 참조하십시오.

라이선스 관리자

대시보드의 아이콘 '라이선스 관리자'가 노란색으로 표시되고 "license-mgr-connection:notice"라는 텍스트가 나타난다면, 이는 BQN 서버가 라이선스 관리자에 연결할 수 없기 때문입니다. 라이선스 관리자는 BQN 소프트웨어 라이선스의 유효성을 검증하는 역할을 하며, 서버 문제를 보고함으로써 Bequant 보다 선제적인 지원을 제공할 Bequant 돕습니다.

BQN 서버가 라이선스 관리자 IP로 아웃바운드 연결을 시작할 수 있는지 확인하십시오(자세한 내용은 Bequant 문의하십시오).

아웃바운드 연결이 가능한지 확인하려면, root로 로그인한 후 제공된 IP와 포트로 telnet을 실행하십시오:


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

라이선스 관리자에 연결할 수 있다면 텔넷이 성공해야 합니다.

‍

라이선스 확인 불가

대시보드의 라이선스 아이콘이 빨간색이고, “license-available:critical”또는“license-expiration: critical”이라는 문구가 표시된다면, 유효한 라이선스가 없는 것입니다. 이는 다음과 같은 여러 가지 이유로 발생할 수 있습니다:

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

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

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

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

‍

라이선스 한도 초과

대시보드의 라이선스 아이콘이 주황색이고 “license-usage: warning”이라는문구가 표시된다면, 라이선스의 최대 용량을 초과한 상태입니다(BQN 서버의 총 트래픽 처리량이 라이선스 한도를 초과함).

‍

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

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

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

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

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

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

유량 수준에서의 효과:

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

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

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

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

‍

높은 CPU 부하

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

‍

‍

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

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

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

먼저, BQN의 핵심 사용법에 대해 간략히 소개하겠습니다.

CPU 코어 어피니티 확인: I/O 및 워커

BQN에서는 중요한 프로세스가 할당된 CPU 코어에서 최우선 순위로 실행됩니다. 이를 ‘코어 어피니티’라고 합니다. 두 개의 프로세스에 CPU 코어가 할당됩니다:

I/O 프로세스: 네트워크 인터페이스 포트를 통해 들어오고 나가는 트래픽 패킷에 대한 읽기 및 쓰기 작업을 담당합니다.
워커(Workers): 모든 패킷 처리(TCP 최적화, ACM, 다양한 셰이핑 제한, DPI 검사 등)를 담당하는 데이터 플레인 프로세스입니다.

나머지 BQN 프로세스들은 사용 가능한 코어에서 실행되지만, 지정된 코어가 있는 경우에는 스케줄러가 우선순위가 낮은 프로세스를 선점하여 우선순위가 높은 프로세스를 실행할 수 있습니다. 서버에 충분한 CPU 코어가 있는 경우, 일부 코어는 할당되지 않은 상태로 남겨져 우선순위가 낮은 프로세스에 전용으로 할당될 수 있습니다.

서버의 CPU 코어 어피니티를 확인하려면 다음 명령을 실행하십시오:


bqnadm@bqn0# show pkteng affinity>
BQN FUNCTION                                      AFFINITY COUNT
  0 cpu-available                                      3ff    10
  0 pkteng-all                                         3f8     7
  0 pkteng-worker                                      3f0     6
  0 pkteng-io                                          008     1
  0 en0s27-io                                          008     1
  0 en0s28-io                                          008     1

이 예시에서 서버는 10개의 코어를 가지고 있습니다. 7개의 코어는 우선순위가 높은 프로세스에 할당되는데, 그중 6개는 워커 프로세스를 실행하고 1개는 I/O 프로세스를 실행하는 데 사용됩니다. 나머지 3개의 코어는 할당되지 않은 상태로 남아, 저우선순위 프로세스를 실행할 준비가 되어 있습니다. 구체적인 코어 할당은 CPU 코어 수, wires 수 wires 해당 wires 속도에 따라 달라집니다. BQN은 이러한 변수들을 바탕으로 가장 최적의 할당을 시도합니다. 이 예제에서는 wire 10 wire 하나 있습니다.

‘affinity’ 필드는 할당된 코어를 나타냅니다. 이 예시에서 IO는 코어 번호 3에 위치하며, 첫 번째 코어는 0(0x8 = 1000)이고, wire 두 인터페이스 모두에서 발생하는 트래픽을 처리합니다. 워커들은 코어 4부터 9(0x3F0=1111110000)까지에 배치되어 있습니다. 0번부터 2번 코어까지는 할당되지 않은 상태입니다(범용 코어).

워커 프로세스 인스턴스에는 1부터 번호가 매겨집니다. 예시에서 워커 인스턴스 1은 코어 4에, 워커 인스턴스 6은 코어 9에 있습니다.

사용자 ‘추가 정보’ 섹션을 사용자 특정 사용자 처리 중인 워커 인스턴스를 확인할 수 있습니다.

‍

과부하가 걸린 코어가 어디인지 확인하세요

‘통계’ > ‘시스템’ > ‘CPU’로 이동하여 사용률이 80% 이상인 CPU 코어를 확인하십시오. 높은 부하가 과거에 발생했을 수도 있으므로 지난 24시간 동안의 기록을 다시 살펴보십시오.

영향을 받은 CPU 코어가 I/O용인지, 아니면 작업용인지 확인하십시오.

때로는 CPU 부하가 순간적으로 급증하더라도 시스템 통계에는 나타나지 않는 경우가 있습니다. 이는 해당 통계가 5분 간격의 평균값을 표시하기 때문입니다. ‘관리(Administration)’ > ‘로그(Logs)’ > ‘시스템(System)’으로 이동하십시오 .

줄 수를 늘리고(예: 1000줄), ‘cpu’로 필터링하도록 Positive 정규식을 설정합니다. 그러면 생성된 CPU 경보가 표시될 뿐만 아니라, 무엇보다도 어떤 특정 CPU 코어가 영향을 받았는지를 나타내는 로그 항목도 확인할 수 있습니다. 다음 예시에서, 코드 6은 사용률이 94%에 달해 고경보 상태로 전환됩니다:


2026-07-02T12:17:18.372852+02:00 bqn0 ctrmgr[6968]: [proc] Changed CPU 6 usage level from "normal" to "high" (94% busy).

이 예시에서 Core 6은 워커입니다.

‍

작업자 CPU 코어의 높은 부하

일반적으로 원인은 트래픽 불균형입니다. BQN은 사용자 기반으로 사용 가능한 워커들에 트래픽을 분배합니다. 만약 소수의 IP 주소에 트래픽이 지나치게 집중되면, 해당 IP를 처리하는 워커들이 과부하 상태에 빠질 수 있습니다.

‘통계’ >사용자> ‘시간별 상위’ 로 이동하여, 트래픽이 사용자 사이에 어떻게 분배되어 있는지 확인하세요 . 상위 사용자들이 나머지 사용자들보다 훨씬 더 많은 트래픽을 차지하고 있는지 살펴보세요.

확인하려면, 사용량이 가장 많은 IP를 마우스 오른쪽 버튼으로 클릭하여 해당 사용자 이동한 후, ‘추가 세부 정보’에서 인스턴스 번호를 확인하십시오. 예를 들어, 현재 살펴보고 있는 예시에서 워커 코어 번호가 6이라면, 예상되는 인스턴스 번호는 3입니다. 이 인스턴스 번호는 시스템 로그에 보고된 번호와 일치해야 합니다.

불균형한 트래픽이 발견되지 않는다면, 문제는 전반적인 트래픽 양이 많기 때문일 수 있습니다. 이 경우, 부하가 높은 워커 코어는 수시로 바뀔 수 있습니다. ‘통계(Statistics) → 처리량(Throughput) → 개요(Overview)’로 이동하여 트래픽 피크가 워커 피크와 일치하는지 확인해 보십시오.

하드웨어 업그레이드가 필요할 수 있습니다. Bequant 문의하십시오.

한편, BQN은 워커 코어의 높은 부하를 완화하기 위한 내부 메커니즘을 갖추고 있으며, 최적화된 트래픽의 양을 줄임으로써 트래픽 손실을 방지하려고 합니다.

하드웨어 업그레이드를 기다리는 동안 취할 수 있는 다른 완화 조치:

과부하를 유발하는 해당 IP에 대해 바이패스를 활성화하십시오. 해당 IP의 트래픽은 최적화되거나 전송 속도 제한이 적용되지 않지만, 해당 IP에 대한 트래픽 처리가 워커에서 수행되지 않으므로 영향을 받는 코어의 부하는 줄어들 것입니다.
BQN과 최종 사용자 사이에 NAT를 사용하고 있다면, NAT가 사용하는 IP 주소 수를 늘려 BQN이 더 많은 주소로 트래픽을 분산할 수 있도록 하십시오.

BQN 서버를 TCPO 및/또는 플로우별 속도 제한 용도로만 사용하는 경우, 플로우별 트래픽 분산을 활성화하여 CPU 부하 분산을 개선할 수 있습니다. 플로우별 트래픽 조정은 기본값인사용자 대신, 개별 플로우별로 CPU 코어 간에 트래픽 부하를 분배합니다. 이를 통해 CPU 부하 균형이 개선되지만,사용자 코어 단위로 이루어지기 때문에 ACM, 정책 속도 또는 사용자 제한과 같은 사용자 제어는 불가능합니다.

‍

‍

IO CPU 코어의 높은 부하

IO 코어의 높은 부하는 심각한 문제입니다. 코어의 처리 용량이 부족하면 일부 패킷이 중계되지 못해 결국 패킷 손실로 이어지기 때문입니다.

이 문제는 대개 트래픽량이 많을 때 발생합니다. ‘통계(Statistics) → 처리량(Throughput) → 개요( Overview)’로 이동하여 트래픽 피크가 영향을 받는 IO 코어의 피크와 일치하는지 확인하십시오.

또 다른 가능성은 BQN 서버의 네트워크 인터페이스가 여러 IO 프로세스 간에 트래픽을 분산 처리하는 기능을 지원하지 않을 수 있다는 점입니다. 이는 일부 네트워크 카드 모델에서 PPPoE 트래픽의 경우 발생합니다. 다음을 참조하십시오. 지원되는 네트워크 인터페이스 및 XL710 문제 해결을 참조하십시오.

또 다른 가능한 원인은 pcapwire , 이 경우 처리량이 약 1 Gbps로 제한됩니다¹. 만약 이것이 잘못된 구성이었고 네트워크 카드가 인텔 호환 제품이라면, ‘구성(Configuration) → 인터페이스(Interfaces) → 데이터 Wires )’로 이동하여 해당 wire 일반(DPDK) wire 변경하십시오.

하드웨어 업그레이드가 필요할 수 있습니다. Bequant 문의하십시오.

그동안 취할 수 있는 조치 중 하나는 CPU 코어 어피니티를 변경하여, 워커 코어나 할당되지 않은 코어를 IO 프로세스에 재할당하는 것입니다. Bequant 이를 도와드릴 것입니다.

‍

높은 메모리 부하

대시보드의 메모리 아이콘이 녹색이 아니라면, 일부 프로세스에서 메모리가 부족해지고 있는 것입니다.

메모리 사용량에 따라 두 가지 유형의 경보가 있습니다:

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

메모리 사용량 확인하기

‘통계’ > ‘시스템’ > ‘메모리’로 이동하여 사용량이 임계값을 초과한 메모리가 무엇인지 확인하십시오. 높은 사용량이 과거에 발생했을 수도 있으므로 지난 24시간 동안의 기록을 다시 살펴보십시오.

시스템 메모리는 다음 세 부분으로 나뉩니다:

DPDK 풀: DPDK 라이브러리를 위해 할당된 시스템 메모리로, 트래픽 패킷을 저장합니다. NUMA 서버의 경우, 각 NUMA에는 해당 NUMA에 장착된 네트워크 카드와 관련된 트래픽을 저장하기 위한 전용 DPDK 풀이 있습니다.
메모리 풀(mpool): 워커 프로세스가 플로우, 사용자 트래픽 메타데이터에 대한 정보를 저장하는 데 사용하는 시스템 메모리입니다.
나머지 시스템 메모리(전체 메모리의 20%): 이 메모리는 시스템의 나머지 부분에서 사용되며, 예를 들어 외부 청구 시스템과 연동하는 API 관리자나 관리 작업 등에 할당됩니다.

메모리 사용량이 높아지는 흔한 원인 중 하나는 과도한 트래픽 처리량입니다. ‘통계(Statistics) → 처리량(Throughput) → 개요(Overview)’의 피크 값이 ‘통계(Statistics) → 시스템(System) → 메모리(Memory)’의 피크 값과 일치하는지 확인해 보십시오.

때로는 메모리 사용량이 일시적으로 급증하더라도 시스템 통계에는 나타나지 않는 경우가 있습니다. 이는 해당 통계가 5분 간격의 평균값을 표시하기 때문입니다. ‘관리(Administration)’ > ‘로그(Logs)’ > ‘시스템(System)’으로 이동하십시오 .

줄 수를 늘리고(예: 1000줄), ‘memory’로 필터링하도록 Positive 정규식을 설정하세요. 그러면 생성된 메모리 경보가 표시될 것입니다.

DPDK 풀의 사용률이 높음을 나타내는 로그 항목은 다음과 같습니다(이 예시에서 DPDK 풀의 사용률은 92%입니다):


2026-07-02T12:21:34.762841+02:00 bqn0 pktengmgr[6971]: [proc] Changed DPDK memory usage: instance(2) usage(92%) pid(7002).

DPDK 풀은 모든 워커가 공유하므로, 워커 인스턴스 2가 요청을 보내던 중에 경보가 발생했다는 사실만으로는 높은 사용량의 원인이 인스턴스 3이라고 단정할 수 없습니다.

mpool의 사용률이 높음을 나타내는 로그 항목은 다음과 같습니다(이 예시에서 mpool의 사용률은 96%입니다):


2026-07-02T12:21:42.439632+02:00 bqn0 pktengmgr[6971]: [proc] Changed PktEng memory usage: instance(3) usage(96%) pid(7002).

mpool은 모든 워커 간에 균등하게 분할되며, 각 워커는 자체 서브풀을 가지고 있습니다. 따라서 경보가 발생한 워커 인스턴스(이 예시에서는 워커 인스턴스 3)가 높은 사용량을 유발한 원인입니다.

하드웨어 업그레이드가 필요할 수 있습니다. Bequant 문의하십시오.

한편, BQN은 높은 메모리 사용량을 완화하기 위한 내부 메커니즘을 갖추고 있어, 최적화된 트래픽의 양을 줄임으로써 트래픽 손실을 방지하려고 합니다.

DPDK 풀의 높은 사용량

이는 NUMA 구성이 잘못되었기 때문일 수 있습니다. NUMA 서버에서는 네트워크 카드가 두 개의 NUMA 영역에 분산되어 있어야 합니다. 만약 모든 네트워크 카드가 동일한 NUMA 영역에 있다면, 다른 NUMA 영역의 DPDK 풀은 사용되지 않는 반면, 모든 네트워크 카드가 있는 NUMA 영역의 DPDK 풀 사용률은 높아지게 됩니다.

이 문제를 해결하려면 네트워크 카드를 재할당하여 서버의 두 Numa 영역에 분산시켜야 합니다. Bequant 이를 도와드릴 뿐만 아니라, 그동안 DPDK 풀 사용량을 미세 조정하는 데도 도움을 드릴 것입니다. 또한, ‘구성(Configuration)’ > ‘최적화 설정(Optimization Settings)’으로 이동하여 일부 트래픽을 바이패스 경로로 설정할 수 있습니다.

mpool 사용량이 높음

문제에 관련된 워커 인스턴스가 소수에 불과하다면, 트래픽 불균형이 원인일 수 있습니다. BQN은 사용자 기반으로 사용 가능한 워커들에 트래픽을 분산합니다. 소수의 IP 주소에 트래픽이 지나치게 집중될 경우, 해당 IP 주소를 처리하는 워커의 메모리가 부족해질 수 있습니다.

‘통계’ >사용자> ‘시간별 상위 ’로 이동 하여, 사용자 간의 트래픽 분포를 확인하세요 . 상위 사용자들이 나머지 사용자들보다 훨씬 더 많은 트래픽을 차지하고 있는지 살펴보세요.

확인하려면, 사용량이 가장 많은 IP를 마우스 오른쪽 버튼으로 클릭하여 해당 사용자 이동한 후, ‘추가 세부 정보’에서 인스턴스 번호를 확인하십시오. 예를 들어, 현재 살펴보고 있는 예시에서는 인스턴스 3입니다. 이 인스턴스는 시스템 로그에 보고된 인스턴스와 일치해야 합니다.

mpool 사용량이 높은 것은 동시 접속 사용자 수 사용자 트래픽 흐름이 많기 때문일 수도 있습니다.

이 문제를 해결하려면 하드웨어 업데이트가 필요합니다. 그동안 트래픽이 집중되는 IP 주소들은 [구성] > [최적화 설정]으로 이동하여 바이패스 모드로 설정할 수 있습니다.

‍

시스템 메모리 사용량이 높음

이는 트래픽 양이 많거나, 동시 사용자 트래픽 흐름이 많거나, 외부 과금 시스템과의 동기화 교환으로 인해 발생할 수 있습니다.

메모리가 디스크로 페이징되면 서버 속도가 상당히 느려지므로, 메모리 업그레이드 중에는 ‘구성’ > ‘최적화 설정’으로 이동하여 모든 트래픽을 우회하도록 설정하는 것이 좋습니다.

‍

RADIUS 동기화 없음

RADIUS는 ‘Configure->RADIUS/REST/Billing’ 에서 구성되어 있지만 , ‘Status->사용자>사용자 RADIUS 관련 정보를 찾을 수 없습니다. ‘RADIUS에 의해 할당됨 ’으로 필터링해도 사용자 표시되지 않습니다 .

RADIUS 트래픽 수신 상태 확인

‘상태(Status) → 인터페이스(Interfaces) → 링크 상태(Link State) ’에서 관리 인터페이스(MGT 열에 체크 표시가 된 인터페이스)를 선택하고, 필터로 “포트 1812 또는 포트 1813”을 지정하여 RADIUS 트래픽을 캡처합니다:

캡처 타임아웃을 회계 중간 기간보다 긴 기간으로 설정하십시오.

CLI를 사용하여 RADIUS 트래픽을 캡처할 수도 있습니다. SSH를 통해 연결하십시오:


$ 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

‍

트래픽이 캡처되지 않는다면, RADIUS 메시지가 BQN 서버에 도달하지 않는 것입니다. . 다음 섹션을 참조하십시오.

RADIUS 메시지를 수신하지 못했습니다

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

‍

‍

여전히 RADIUS 메시지를 수신하지 못한다면, 나머지 트래픽 경로를 확인해야 합니다. 이 예시에서 RADIUS 클라이언트는 10.10.10.0/24 서브넷에 있고, BQN은 192.168.0.0/24 서브넷에 있습니다. 두 서브넷 사이에 유효한 경로가 있는지, 그리고 중간에 위치한 방화벽이 UDP 포트 1813(RADIUS 계정) 및(RADIUS 프록시 모드인 경우) UDP 포트 1812(RADIUS 인증)를 차단하고 있지 않은지 확인하십시오.

시스템 로그를 확인하십시오

RADIUS 메시지는 수신되었으나 RADIUS 동기화가 이루어지지 않은 경우, 시스템 로그를 확인하십시오.

‘관리’ > ‘로그’ > ‘시스템 ’으로 이동한 후 “RADIUS” 정규식을 사용하세요.

시스템 로그 항목이 발견되지 않으면 로그 수준을 높일 수 있습니다. SSH를 통해 BQN 서버에 접속하십시오:


bqnadm@bqn# configure
bqnadm@bqn(config)# logging
bqnadm@bqn(config-api)# feature api debug
bqnadm@bqn(config-api)# commit
bqnadm@bqn(config-api)# end
bqnadm@bqn#

잠시 기다린 후, ‘관리’ > ‘로그’ > ‘시스템’에서 “RADIUS” 정규식을 사용하여 다시 확인해 보세요.

예를 들어, 이 로그 항목은 IP 주소 10.10.10.10이 알 수 없는 주소임을 나타냅니다:


2026-07-14T09:53:01.792598+02:00 bqn0 apimgr[7018]:[api] [en0o1@192.168.0.121] %WARN-ENOENT: Ignore RADIUS message from unknown client 10.10.10.10:60864: rcvIgnore(7) code(Accounting-Request) id(121)authenticator(b1de13f7e72888077c8df46242489229) avpNumber(4) length(79)

‘구성’ > ‘RADIUS/REST/청구’ > ‘RADIUS ’로 이동하여 해당 주소를 유효한 RADIUS 클라이언트로 추가하십시오.

이 다른 로그 항목은 클라이언트가 사용하는 비밀번호가 BQN에 등록된 비밀번호와 일치하지 않음을 나타냅니다:


2026-07-14T10:20:42.083613+02:00 arzua apimgr[7018]: [api][en0o1@192.168.0.121] %ERR-EBADE: Received invalid authenticator inAccounting-Request RADIUS message from 10.10.10.10:60849:code(Accounting-Request) id(43) authenticator(2503e1985bb9f8eac6120bb48b532ed2)avpNumber(4) length(79)

‘구성(Configuration)’ > ‘RADIUS/REST/청구(Billing)’ > ‘ RADIUS’로 이동하여 RADIUS 클라이언트의 비밀번호가 올바른지 확인하십시오.

API 로그 활성화

RADIUS 메시지가 수신되었으나 RADIUS 동기화가 이루어지지 않은 경우, 시스템 로그 대신 API 로그를 확인할 수 있습니다.

ssh를 통해 BQN 서버 셸에 접속합니다:


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

다음 명령어를 사용하여 API 로그를 확인하세요:


bqnadm@bqn# show api event log

회계 시작(Accounting Start) 메시지가 성공적으로 수신된 예시와 BQN이 RADIUS 클라이언트에 보낸 해당 응답은 다음과 같습니다:


2026-07-14T10:23:00.773 [radius] [eno1@192.168.0.121:1813] Received Accounting-Request message from 10.10.10.10:60832: id(74) avpNumber(4)presentMask(0xfa0000) address(10.0.0.1) acctSessionId(xcattqjvzo) acctType(Start) block(n/a) callingStationId(n/a) class(n/a) nasId(n/a) nasIp(n/a) nasPort(n/a) nasPortId(n/a) policyName(RA-30M/40M-60M/80M-50M/70M-2/3) quotaTime(n/a) quotaVolume(n/a) radiusDhcp(no) sessionId(n/a) subscriberGroup(n/a) subscriberId(n/a) userName(n/a) userPassword(n/a)
2026-07-14T10:23:00.773 [radius] [eno1@192.168.0.121:1813] Send Accounting-Request message to 10.10.10.10:60832 client: id(74) code(Accounting-Response) id(74) authenticator(01a5ca704c9f183c00934d1b1ac7af37) avpNumber(0) length(20)

이 RADIUS 메시지는 사용자 주소 10.0.0.1에 속도 정책 RA-30M/40M-60M/80M-50M/70M-2/3을 할당합니다.

다음은 수신된 ‘회계 시작(Accounting Start)’ 메시지의 예시입니다. 이 메시지는 처리되어 ‘OK’ 응답이 전송되었으나, 정책 요율 이름에 문제가 있는 경우입니다:


2026-07-14T10:23:20.153 [radius] [eno1@192.168.0.14:1813] Received Accounting-Request message from 192.168.0.74:60776: id(35) avpNumber(4) presentMask(0x1a0000) address(10.0.0.1) acctSessionId(xcattqjvzo) acctType(Start) block(n/a) callingStationId(n/a) class(n/a) nasId(n/a)nasIp(n/a) nasPort(n/a) nasPortId(n/a) policyName(n/a) quotaTime(n/a) quotaVolume(n/a) radiusDhcp(no) sessionId(n/a) subscriberGroup(n/a) subscriberId(n/a) userName(n/a) userPassword(n/a)
2026-07-14T10:23:20.153 [radius] [eno1@192.168.0.14:1813] Send Accounting-Request message to 192.168.0.74:60776 client: id(35) code(Accounting-Response) id(35) authenticator(160cf3a4da8d15d9683af46d21797762) avpNumber(0) length(20)

RADIUS 메시지에서 정책 이름을 추출할 수 없습니다: policyName(n/a). 이 경우 ‘AVP 매개변수 확인’ 섹션으로 이동하십시오.

RADIUS AVP 매개변수 확인

RADIUS 메시지를 수신하고 수락했음에도 불구하고 BQN에 RADIUS에서 전송된 속성이 표시되지 않는 경우, 수신된 RADIUS 트래픽 캡처 기록을 확인하여 해당 메시지에 예상된 AVP가 포함되어 있는지 확인하십시오.

또한, [구성] > [RADIUS/REST/청구] > [RADIUS] 로 이동 하여 [AVP 선택] 섹션에서 요금 정책이 적용된 AVP가 목록에 포함되어 있는지(즉, BQN에서 지원되는지) 및 무시되지 않는지 확인하십시오. 예를 들어, Mikrotik-Rate-Limit AVP를 사용하는 경우:

‍

REST 동기화 없음

REST는 [Configure] > [RADIUS/REST/Billing] > [REST] 에서 구성되지만, [Status] >사용자>사용자 ]에서는 REST 관련 정보를 찾을 수 없습니다. ‘REST에 의해 할당됨’으로 필터링해도 사용자 표시되지 않습니다 .

‍

REST 트래픽 수신 상태 확인

‘상태(Status) > 인터페이스(Interfaces) > 링크 상태(Link State) ’에서 관리 인터페이스(MGT 열에 체크 표시가 된 인터페이스)를 선택하고, 필터로 “tcp 및 포트 3443”을 지정하여 REST 트래픽을 캡처합니다:

‍

BQN OAM IP 주소로 REST 쿼리를 몇 개 전송하세요.

CLI를 사용하여 REST 트래픽을 캡처할 수도 있습니다. SSH를 통해 연결하세요:


$ 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

‍

트래픽이 캡처되지 않는다면, REST 메시지가 BQN 서버에 도달하지 않는 것입니다. 다음 섹션을 참조하십시오.

REST 메시지를 수신하지 못했습니다.

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

‍

‍

여전히 REST 메시지가 수신되지 않는다면, 나머지 트래픽 경로를 확인해야 합니다. 이 예시에서 REST 클라이언트는 10.10.10.0/24 서브넷에, BQN은 192.168.0.0/24 서브넷에 위치해 있습니다. 두 서브넷 사이에 유효한 경로가 설정되어 있는지, 그리고 중간에 있는 방화벽이 TCP 포트 3443을 차단하고 있지 않은지 확인하십시오.

시스템 로그를 확인하십시오

REST 메시지가 수신되었으나 REST 동기화가 이루어지지 않은 경우, 시스템 로그를 확인하십시오.

‘관리’ > ‘로그’ > ‘시스템’ 으로 이동한 후 “REST|HTTP” 정규식을 사용하세요.

시스템 로그 항목이 발견되지 않으면 로그 수준을 높일 수 있습니다. SSH를 통해 BQN 서버에 접속하십시오:


bqnadm@bqn# configure
bqnadm@bqn(config)# logging
bqnadm@bqn(config-api)# feature api debug
bqnadm@bqn(config-api)# commit
bqnadm@bqn(config-api)# >end
bqnadm@bqn#

잠시 기다린 후, ‘관리’ > ‘로그’ > ‘시스템’에서 “REST|HTTP” 정규식을 사용하여 다시 확인해 보세요.

예를 들어, 이 로그 항목은 IP 주소 10.10.10.10i가 알 수 없는 주소임을 나타냅니다:


2026-07-14T12:27:52.273156+02:00 bqn0 apimgr[7018]: [api] %ERR-EACCES: Denied connection access to "10.10.10.10" REST client: port(52008)

‘구성’ > ‘RADIUS/REST/청구’ > ‘REST’로 이동하여 해당 주소가 유효한 REST 클라이언트인지 확인하십시오.

다음 로그 항목은 사용자 이름이나 사용자 비밀번호가 잘못되었음을 나타냅니다:


2026-07-14T12:36:17.334812+02:00 bqn0 apimgr[7018]: [api] [10.10.10.10:52004] Received 178 bytes: current(0) end(178) size(178) rw(false) data(47 45 54 20 2f 61 70 69 2f 76 31 2f 73 75 62 73 63 72 69 62 65 72 73 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 31 39 32 2e 31 36 38 2e 30 2e 31 34 3a 33 34 34 33 0d 0a 41 75 74 68 6f 72 69 7a 61 74 69 6f 6e 3a 20 42 61 73 69 63 20 62 58 6c 31 63 32 56 79 4d 54 70 74 65 58 4e 6c 59 33 4a 6c 64 41 3d 3d 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 75 72 6c 2f 37 2e 38 31 2e 30 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6f 6e 0d 0a 0d 0a)
2026-07-14T12:36:17.335462+02:00 bqn0 apimgr[7018]: [api] [192.168.0.74:52004] %ERR-EACCES: Unauthorized HTTP request does not match a user: uri(/api/v1/subscribers) authorization(Basic) authorization(80/24)
2026-07-14T12:36:17.335741+02:00 bqn0 apimgr[7018]: [api] [192.168.0.74:52004] Send HTTP response: code(401) subCode(1)

‘구성(Configuration)’ > ‘RADIUS/REST/청구(Billing)’ > ‘REST ’로 이동하여, 사용자 이름과 비밀번호가 REST 클라이언트에서 사용하는 것과 동일한지 확인하십시오.

API 로그 활성화

REST 메시지가 수신되었으나 RADIUS 동기화가 이루어지지 않은 경우, 시스템 로그 대신 API 로그를 확인할 수 있습니다.

ssh를 통해 BQN 서버 셸에 접속합니다:


bqnadm@bqn# configure
bqnadm@bqn(config)# api common
bqnadm@bqn(config-api)# event level rest
bqnadm@bqn(config-api)# commit
bqnadm@bqn(config-api)# end
bqnadm@bqn#

다음 명령어를 사용하여 API 로그를 확인하세요:


bqnadm@bqn# show api event log

성공적으로 수신된 REST 쿼리와 BQN 응답의 예시:


2026-07-14T12:43:26.707 [rest] [10.10.10.10] Received HTTP request: method(GET) hdr(34/138) uri(/api/v1/subscribers) authorization(Basic) contentLength(0) connection(0) transferEncoding(0x0)
2026-07-14T12:43:26.708 [rest] [10.10.10.10:51920] Send HTTP response: code(200) httpLength(2323) contentLength(2250) hdrExt(0)

다음은 알 수 없는 URI가 포함된 수신된 REST 쿼리의 예시입니다(쿼리가 올바르게 구성되지 않았습니다).


2026-07-14T12:44:46.276 [rest] [10.10.10.10:51928] %ERR-ENOENT: Unknown URI in HTTP request: method(GET) hdr(38/138) uri(/api/v1/subscribersss) authorization(Basic) contentLength(0) connection(0) transferEncoding(0x0)
2026-07-14T12:44:46.276 [rest] [10.10.10.10:51928] Send HTTP response: code(400) subCode(2) message(Unknown URI)

API 추적 기능 활성화

요청 중 하나에 문제가 있음을 확인한 경우, API 추적을 활성화하여 어떤 요청이 문제를 일으키고 있는지 파악할 수 있습니다. 이렇게 하면 각 요청 또는 응답마다 추적 파일이 생성됩니다.

ssh를 통해 BQN 서버 셸에 접속합니다:


bqnadm@bqn# configure
bqnadm@bqn(config)# api rest
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은 최근 5건의 REST 요청 및 응답에 대한 추적 정보를 생성합니다. 이 추적 정보는 /opt/bqn/var/trace 디렉터리에서 확인할 수 있습니다. ssh를 사용하여 로그인하십시오:


bqnadm@bqn0# file ls -al /opt/bqn/var/trace/rest*
-rw-r--r-- 1 root root  174 Jul 14 12:53 /opt/bqn/var/trace/rest-req-0000
-rw-r--r-- 1 root root  230 Jul 14 12:53 /opt/bqn/var/trace/rest-req-0001
-rw-r--r-- 1 root root 1858 Jul 14 12:53 /opt/bqn/var/trace/rest-rsp-0000
-rw-r--r-- 1 root root  179 Jul 14 12:53 /opt/bqn/var/trace/rest-rsp-0001

첫 번째 요청/응답은 정상입니다:


bqnadm@bqn0# file less /opt/bqn/var/trace/rest-req-0000
GET /api/v1/subscribers HTTP/1.1
Host: 192.168.0.14:3443
Authorization: Basic bXl1c2VyOm15c2VjcmV0
User-Agent: curl/7.81.0
Accept: */*
Content-Type: application/json


bqnadm@bqn0# file less /opt/bqn/var/trace/rest-rsp-0000
HTTP/1.1 200 Ok
Content-Type: application/json
Content-Length: 1785

{
  "items" : [
  {
. . .

‍

두 번째 요청/응답에 오류가 있습니다:


bqnadm@bqn0# file less /opt/bqn/var/trace/rest-req-0001
POST /api/v1/subscribers/10.0.0.1 HTTP/1.1
Host: 192.168.0.121:3443
Authorization: Basic bXl1c2VyOm15c2VjcmV0
User-Agent: curl/7.81.0
Accept: */*
Content-Type: application/json
Content-Length: 26

{"subscriberId": "unknown}

bqnadm@bqn0# file less /opt/bqn/var/trace/rest-rsp-0001
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 99

{
  "error" : {
    "code" : 400,
    "subCode" : 22,
    "message" : "Invalid body content"
  }
}

The POST request has a wrong body. Review the REST clientPOST request and compare it with the REST API reference manual. In this example,the POST body had a typo (double quotes after value missing): {"subscriberId": "myid}

‍

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)

‍

REST TLS 버전

‍

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 사용자 을 검색하는 동기화에 성공했지만 이후 한 번의 동기화 시도가 실패했습니다. 지금 동기화 버튼을 눌러 동기화를 강제로 시도할 수 있습니다.

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

청구 시스템 접속 인증 정보(API 키, 사용자 이름/비밀번호 등)를 확인하십시오. 이러한 인증 정보는 청구 시스템에 등록되어 있어야 합니다.
일부 청구 시스템(예: Splynx)에서는 특정 REST API 호출에 대한 접근 권한을 부여해야 합니다.
일부 청구 시스템(예: Azotel)의 경우, 청구 시스템에 접속하는 소스 IP 주소도 인증을 받아야 합니다. 이는 BQN 관리 주소에서 청구 시스템으로 연결되는 공용 IP 주소입니다(BQN 서버가 공용 IP 주소를 사용하는 경우에도 마찬가지입니다).
청구 서버의 IP 주소를 확인할 수 있는지 확인하십시오. 확인할 수 없는 경우, BQN의 ‘청구 상태’ 항목 중 ‘서버’ 필드에 0.0.0.0이 표시됩니다. 이는 서버 이름이 알려지지 않았거나 BQN에 DNS 서버가 설정되어 있지 않기 때문일 수 있습니다. DNS 서버를 설정하려면 관리 인터페이스 페이지로 이동하십시오.

청구 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#

시스템 로그를 확인하십시오

‘관리’ > ‘로그’ > ‘시스템’으로 이동한 후 “billing” 정규식을 사용하세요.

결제 서버에 연결하는 데 문제가 발생하면 다음과 같은 메시지가 표시됩니다:


2026-07-09T14:51:37.989030+02:00 bqn0 apimgr[6852]: [api] %ERR-ENOTCONN: Cannot connect to foo.server.com:443 billing server: retry(4)

시스템 로그 항목이 발견되지 않으면, 로그 수준을 높일 수 있습니다. SSH를 통해 BQN 서버에 접속하려면:


bqnadm@bqn# configure
bqnadm@bqn(config)# logging
bqnadm@bqn(config-api)# feature api debug
bqnadm@bqn(config-api)# commit
bqnadm@bqn(config-api)# end
bqnadm@bqn#

잠시 기다린 후, ‘billing’ 정규식을 사용하여 [관리] > [로그] > [시스템]에서 다시 확인해 보세요:


2026-07-10T12:43:24.287545+02:00 bqn06 apimgr[9015]: [api] Received HTTP response from billing server: ... {"errors": [{"message": "You have exceeded the allowed rate limit for queries. Please refer to https://app.gaiia.com/docs/rate-limits for more information on rate limits and how to manage them.", "extensions": {"code": "RATE_LIMITED", "cost": 16, "limit": 500, "used": 492, "remaining": 8...}}]}

이 첫 번째 예시에서는 요청이 오류를 반환했습니다. HTTP 상태 코드는 200이지만, REST 수준 오류 코드인 RATE_LIMITED가 포함되어 있습니다.

그리고 %ERR-EINVAL을 검색하면:


2026-07-10T12:43:24.289068+02:00 bqn06 apimgr[9015]: [api] %ERR-EINVAL: Cannot get "accounts" array element

BQN은 청구 시스템에서 “계정 정보”를 가져올 수 없다고 불만을 제기하고 있습니다.

이 두 로그를 보면 근본 원인을 알 수 있습니다. 이 문제는 API 키의 요청 한도를 초과했기 때문에 발생합니다. 해결책은 한도를 늘리는 것입니다.

요청 오류의 또 다른 예시:


2026-07-10T14:41:47.766401+02:00 bqn06 apimgr[7546]: [api] %ERR: Unexpected HTTP response from billing server: status(401) transferEncoding(not-present) header(HTTP/1.1 401 Unauthorized#015#012Server: HTTPS Equipment Simulator#015#012Date: Fri, 10 Jul 2026 12:41:47 GMT#015#012Content-Length: 99#015#012Content-Type: application/json;charset=UTF-8#015#012#015#012) isBodyComplete(yes) bodyOffset(167) bodyLength(99) endOffset(266) body({"error": {"code": 401, "internal_code": "UNAUTHORIZED", "message": "Invalid authorization data!"}})

이 경우, 청구 시스템은 내부 코드 UNAUTHORIZED와 함께 HTTP 401 코드를 반환합니다. 따라서 이 다른 예시의 근본 원인은 액세스 자격 증명에 있습니다. 즉, API 키나 보조 자격 증명이 잘못되었거나, BQN이 승인되지 않은 IP 주소에서 청구 시스템에 접속하고 있는 것입니다.

API 로그 활성화

청구 서버에 접속할 수 있는데도 동기화가 실패하고 syslog 항목이 발견되지 않는 경우, API 로그를 활성화하여 더 심층적인 분석을 진행하십시오. ssh를 통해 BQN 서버 셸에 접속하십시오:


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

다음 명령어를 사용하여 API 로그를 확인하세요:


bqnadm@bqn# show api event log
bqnadm@bqn#

성공적인 요청의 예시(이 경우 “products” 배열을 가져오기 위한 POST 요청):


2026-07-09T17:01:43.472 [billing] Send HTTP POST request to 192.168.122.200:4443: uri(/api/v1) httpLength(576) contentLength(412) hdrExt(86)
2026-07-09T17:01:43.484 [billing] Received HTTP response from billing server: status(200) transferEncoding(chunked) header(HTTP/1.1 200 OK
Server: HTTPS Equipment Simulator
Date: Thu, 09 Jul 2026 15:05:43 GMT
Transfer-Encoding: chunked
Content-Type: application/json;charset=UTF-8

) isBodyComplete(yes) bodyOffset(165) bodyLength(5206) endOffset(5371)
2026-07-09T17:01:43.485 [billing] Received 4 elements in "products" array

그리고 실패한 요청의 예시(청구 “계정”에 대한 쿼리 시도와 관련된):


2026-07-09T17:01:43.486 [billing] Send HTTP POST request to 192.168.122.200:4443: uri(/api/v1) httpLength(1343) contentLength(1178) hdrExt(86)
2026-07-09T17:01:43.496 [billing] Received HTTP response from billing server: status(200) transferEncoding(chunked) header(HTTP/1.1 200 OK
Server: HTTPS Equipment Simulator
Date: Thu, 09 Jul 2026 15:05:43 GMT
Transfer-Encoding: chunked
Content-Type: application/json;charset=UTF-8

) isBodyComplete(yes) bodyOffset(165) bodyLength(410) endOffset(575)
2026-07-09T17:01:43.498 [billing] %ERR-EINVAL: Cannot get "accounts" array element

API 추적 기능 활성화

ssh를 통해 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건의 요청과 5건의 응답에 대한 추적 정보를 생성합니다. 이 추적 정보는 /opt/bqn/var/trace 디렉터리에 있습니다. ssh를 사용하여 로그인하십시오.


bqnadm@bqn0# file ls -al /opt/bqn/var/trace/billing*
-rw-r--r-- 1 root root  576 Jul  9 17:24 /opt/bqn/var/trace/billing-req-0000
-rw-r--r-- 1 root root 1343 Jul  9 17:24 /opt/bqn/var/trace/billing-req-0001
-rw-r--r-- 1 root root 5371 Jul  9 17:24 /opt/bqn/var/trace/billing-rsp-0000
-rw-r--r-- 1 root root  575 Jul  9 17:24 /opt/bqn/var/trace/billing-rsp-0001

“계정”과 관련된 요청을 찾아보세요:


bqnadm@bqn0# file less /opt/bqn/var/trace/billing-req-0001
POST /api/v1 HTTP/1.1
Content-Type: application/json
Content-Length: 1178
Host: 192.168.122.200
Content-Type: application/json
X-Gaiia-Api-Key: gdhdfffkfjkk

{    "query": "query Accounts {      accounts( filter: { status: { type: { in: [ACTIVE, INACTIVE, 
. . .

요청(이 예시에서는 0001)을 확인한 후에는, 동일한 ID를 가진 응답을 확인하세요:


bqnadm@bqn0# file less /opt/bqn/var/trace/billing-rsp-0001
HTTP/1.1 200 OK
Server: HTTPS Equipment Simulator
Date: Thu, 09 Jul 2026 15:28:34 GMT
Transfer-Encoding: chunked
Content-Type: application/json;charset=UTF-8

{"errors": [{"message": "You have exceeded the allowed rate limit for queries. Please refer to https://app.gaiia.com/docs/rate-limits for more information on rate limits and how to manage them.", "extensions": {"code": "RATE_LIMITED", 
. . .

이 경우, API 키의 요청 한도를 초과했기 때문에 문제가 발생합니다. 해결책은 한도를 늘리는 것입니다.

curl을 사용하여 청구 서버와 직접 통신하기

문제의 원인이 여전히 파악되지 않는 경우, Linux의 curl 명령어를 사용하여 청구 시스템에 직접 요청을 보낼 수 있습니다. 청구 시스템에 BQN 서버에서만 접근할 수 있는 경우가 아니라면, BQN 서버와 다른 서버에서도 이 작업을 수행할 수 있습니다. 이 작업에는 청구 시스템 및 API 요청 규약에 대한 전문 지식이 필요합니다. 예를 들어, Azotel 청구 시스템에 쿼리를 보내려면 다음과 같이 합니다:


myuser@mylaptop:~$ curl -k -H 'Accept: application/json' -H 'Content-Type: application/json' -X POST -d  '{"api_username": "myuser", "api_password": "mypassword", "allcustomers": "1"}' https://mybilling.:443/restapi/listCustomerBucketData | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2431    0  2354  100    77  86088   2815 --:--:-- --:--:-- --:--:-- 90037
{
  "result": {
    "customerBucketData": [
      {
        "customerid": "sub-1",
        "ipaddresses": [
          {
            "ip": "10.0.0.1"
          },
          {
            "ip": "ff01:abcd:ef01:2345::1/64"
          }
        ],
        "bucket": {
          "name": "Policy 1",
. . .
myuser@mylaptop:~$

‍

동기화된 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이 열려 있는지 확인하세요.

REACH 열은 서버에 연결에 성공한 횟수를 나타냅니다. 0은 서버에 연결할 수 없음을 의미합니다.

NTP 서버에 접속은 가능하지만 동기화가 되지 않는 것으로 보인다면, 해당 서버를 삭제한 후 다시 추가해 보십시오.

NTP 동기화 문제가 해결되는 동안, 대시보드의 ‘시스템 시간’에서 현재 시간과 날짜를 확인하고 실제 시간과 비교해 보십시오. 차이가 크지 않다면 심각한 문제는 아니지만, 향후 긴급한 상황이 발생하지 않도록 반드시 수정해야 합니다.

‍

디스크 문제

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

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

‍

인텔 네트워크 카드 XL710은 PPPoE 트래픽 40Gbps에 도달하지 못합니다.

PPPoE 트래픽을 처리하는 Intel XL710 네트워크 카드가 40Gbps 링크를 협상했음에도 불구하고 처리량이 10Gbps로 제한될 수 있습니다. 카드가 PPPoE 트래픽의 부하 분산을 수행하지 않고 패킷이 단일 프로세스로 전달되어 최대 처리량이 제한되는 것이 원인일 수 있습니다.

인텔 카드의 패킷 배포 기능은 인텔 동적 장치 개인화(DDP)를 통해 구현됩니다. 다음 세 가지 조건이 충족되어야 합니다.

BQN bqnkernel 패키지는 R3.0.19 이상이어야 합니다. 패킷 설치 후 시스템을 재부팅해야 합니다.
카드 펌웨어 버전은 PPPoE 부하 분산을 지원하는 DDP를 지원해야 합니다(아래 섹션 참조).
BQN bqn 패키지는 R4.27 이상이어야 합니다.

네트워크 카드 펌웨어 업데이트

다음 펌웨어 업데이트 절차는 Intel 네트워크 카드에서만 작동합니다. Intel 칩셋을 사용하는 Intel 이외의 네트워크 카드는 이 절차로 업데이트할 수 없습니다.

PPPoE 배포에는 펌웨어 버전 7.0과 DDP 버전 1.1.6.1이 필요합니다(이론적으로는 펌웨어 버전 6.01도 작동하지만, 저희 연구실에서 검증되지 않았습니다).

다음 절차에는 트래픽 중단과 서버 재부팅이 포함되므로 BQN 서버를 트래픽 경로에서 벗어나야 합니다.

먼저, 카드 펌웨어 버전을 확인하려면 XL710 인터페이스 포트가 운영체제에서 접근 가능해야 합니다. 즉, DPDK 제어 하에 있지 않아야 합니다. 따라서 인터페이스 포트 중 어느 하나라도 wire 일부인 경우, 해당 포트를 pcap 모드로 설정해야 합니다. BQN GUI에서 구성(Configuration) > 인터페이스(Interfaces) > 데이터 Wires )로 이동하여 해당 네트워크 카드의 포트가 wires 제거한 후, 해당 포트를 pcap 모드로 설정하여 다시 생성하십시오.

이 작업이 완료되면 인터페이스가 표시되며, ethtool 명령어를 사용하여 펌웨어 버전을 확인할 수 있습니다:


me@ubuntu:~ $ ssh root@bqn
bqn0:~ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 10:f1:81:4e:13:a0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.121/24 scope global eno1
       valid_lft forever preferred_lft forever
24: ens1f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2026 qdisc mq state UP qlen 1000
    link/ether 64:9d:99:00:00:01 brd ff:ff:ff:ff:ff:ff
25: ens1f0: &t;BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2026 qdisc mq state UP qlen 1000
    link/ether 64:9d:99:00:00:02 brd ff:ff:ff:ff:ff:ff
bqn0:~ # ethtool -i ens1f0
driver: i40e
version: 2.8.20-k
firmware-version: 5.00 0x80004112 1.2154.0
bus-info: 0000:08:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
bqn0:~ #

이 예시에서는 펌웨어 버전이 5.0이고 카드를 업데이트해야 합니다. 이 섹션의 나머지 부분에서 업데이트 방법을 설명했습니다.

펌웨어 업데이트를 하려면 서버가 부팅되어야 OS 커널이 이러한 변경 사항을 허용합니다. grub 설정 파일을 편집하기 전에 백업해 두세요.


bqn0:~ # cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bkup
bqn0:~ # vim /boot/grub2/grub.cfg

‍

첫 번째 메뉴 항목에서 linuxboot 라인 에 iomem=relaxed를 추가하십시오. 해당 라인은 다음과 유사하게 표시됩니다:


. . .
menuentry "BQN OS 4.12.14-155.g4755291-default" --class os {
        echo Loading vmlinuz-4.12.14-155.g4755291-default
        linux /boot/vmlinuz-4.12.14-155.g4755291-default root=UUID="fc421e6f-a3ed-4db7-949e-97157dd34a94" rootfstype=ext4 mitigations=off iomem=relaxed
        echo Loading initrd-4.12.14-155.g4755291-default
        initrd /boot/initrd-4.12.14-155.g4755291-default
}
menuentry "BQN OS 4.12.14-155.g4755291-default (debug)" --class os {
. . .

파일을 저장하고 서버를 재부팅하세요.


bqn0:~ # reboot

X700 제품군용 Intel 업데이트 도구를 PC에 다운로드하고 압축을 푼 후 Linux 패키지를 BQN 서버로 전송하세요. 예:


me@ubuntu:~ $ wget --no-check-certificate https://downloadmirror.intel.com/29156/eng/nvmupdatepackage_700_series_v7_00.zip
--2025-05-09 12:31:00--  https://downloadmirror.intel.com/29156/eng/nvmupdatepackage_700_series_v7_00.zip
Resolving downloadmirror.intel.com (downloadmirror.intel.com)... 108.157.109.71, 108.157.109.55, 108.157.109.39, ...
Connecting to downloadmirror.intel.com (downloadmirror.intel.com)|108.157.109.71|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 258056036 (246M) [binary/octet-stream]
Saving to: 'nvmupdatepackage_700_series_v7_00.zip'

nvmupdatepackage_700_series_v7_00.z 100%[===================================================================>] 246.10M  23.0MB/s    in 11s

2025-05-09 12:31:11 (22.9 MB/s) - 'nvmupdatepackage_700_series_v7_00.zip' saved [258056036/258056036]

me@ubuntu:~ $ unzip ./nvmupdatepackage_700_series_v7_00.zip
Archive:  ./nvmupdatepackage_700_series_v7_00.zip
  inflating: 700Series_NVMUpdatePackage_v7_00_EFI.zip
  inflating: 700Series_NVMUpdatePackage_v7_00_ESX.tar.gz
  inflating: 700Series_NVMUpdatePackage_v7_00_FreeBSD.tar.gz
  inflating: 700Series_NVMUpdatePackage_v7_00_Linux.tar.gz
  inflating: 700Series_NVMUpdatePackage_v7_00_Windows.exe
 
me@ubuntu:~ $ scp ./700Series_NVMUpdatePackage_v7_00_Linux.tar.gz root@bqn:
700Series_NVMUpdatePackage_v7_00_Linux.tar.gz                                              100%   50MB  50.4MB/s   00:00

‍

BQN 서버로 가서 tarball을 압축 해제하고 업데이트 도구를 실행합니다.


me@ubuntu:~ $ ssh root@bqn

bqn0:~ # tar xvfz 700Series_NVMUpdatePackage_v7_00_Linux.tar.gz
700Series/
700Series/Linux_x64/
700Series/Linux_x64/25G_PHY_MISC_3.txt
. . .

bqn0:~ # ./700Series/Linux_x64/nvmupdate64e
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.33.15.1
Copyright (C) 2013 - 2019 Intel Corporation.


WARNING: To avoid damage to your device, do not stop the update or reboot or power off the system during this update.
Inventory in progress. Please wait [.........|]

Num Description                          Ver.(hex)  DevId S:B    Status
=== ================================== ============ ===== ====== ==============
01) Intel(R) Ethernet Converged          5.00(5.00)  1583 00:008 Update available
    Network Adapter XL710-Q2
02) Intel(R) Ethernet Network Adapter                1592 00:130 Not supported
    E810-C-Q2

Options: Adapter Index List (comma-separated), [A]ll, e[X]it
Enter selection: 01
Would you like to back up the NVM images? [Y]es/[N]o: Y
Update in progress. This operation may take several minutes.
[**+.......]

Num Description                          Ver.(hex)  DevId S:B    Status
=== ================================== ============ ===== ====== ==============
01) Intel(R) Ethernet Converged          7.00(7.00)  1583 00:008 Up to date
    Network Adapter XL710-Q2
02) Intel(R) Ethernet Network Adapter                1592 00:130 Not supported
    E810-C-Q2
Tool execution completed with the following status: All operations completed successfully.
Press any key to exit.

bqn0:~ #

이 도구는 시스템에서 감지된 모든 X710 네트워크 카드에 대한 펌웨어 업데이트 프로세스를 안내합니다.

펌웨어 업데이트 완료 후, wires 일반 모드(pcap 미사용) wires 복원하십시오. BQN GUI에서 구성(Configuration) -> 인터페이스(Interfaces) -> 데이터 와이어(DataWires) 로 이동하여 해당 네트워크 카드의 포트를 wires 제거한 후, 일반 모드(pcap 선택란 미체크)로 포트를 설정하여 다시 생성하십시오.

grub 구성 파일에서 iomem=relaxed 매개변수를 제거하고 시스템을 재부팅하십시오:


bqn0:~ # cp /boot/grub2/grub.cfg.bkup /boot/grub2/grub.cfg
bqn0:~ # reboot

PPPoE 부하 분산이 활성화되어 있는지 확인

네트워크 펌웨어, bqn커널 및 bqn 패키지가 올바른 버전이면 기본적으로 각 XL710 네트워크 포트에서 PPPoE 트래픽의 부하 분산이 활성화되어야 합니다. 예를 들어


bqnadm@bqn0 # show interface en0s1f0 device
Driver: igb_uio
PCI class: 0x20000
PCI vendor ID: 0x8086 : Intel Corporation
PCI device ID: 0x1583 : Ethernet Controller XL710 for 40GbE QSFP+
PCI sub-vendor ID: 0x8086 : Intel Corporation
PCI sub-device ID: 0x0000
PCI slot: 0000:08:00.1
NUMA node: 0
DDP profile total: 1
  Track id (0): 0x80000006
  Version (0): 1.1.6.1
  Profile name (0): PPPoE and PPPoL2TPv2
DDP backup available: yes
bequant@bqn0# show interface en0s1f1 device
Driver: igb_uio
PCI class: 0x20000
PCI vendor ID: 0x8086 : Intel Corporation
PCI device ID: 0x1583 : Ethernet Controller XL710 for 40GbE QSFP+
PCI sub-vendor ID: 0x8086 : Intel Corporation
PCI sub-device ID: 0x0000
PCI slot: 0000:08:00.1
NUMA node: 0
DDP profile total: 1
  Track id (0): 0x80000006
  Version (0): 1.1.6.1
  Profile name (0): PPPoE and PPPoL2TPv2
DDP backup available: yes
bqnadm@bqn0 #

show 명령어는 하나의 DDP 프로파일(PPPoE용)이 존재하며 부하 분산이 활성화되었음을 나타냅니다.

PPPoE 부하 분산 비활성화

네트워크 카드와 DDP 프로필에 문제가 있는 경우, 네트워크 카드의 모든 포트에서 no ddp pppoe 명령을 사용하여 DDP를 비활성화한 후, 해당 인터페이스 중 하나에서 system interface ddp reset을 실행할 수 있습니다. 예를 들어:


bqnadm@bqn0# configure
bqnadm@bqn0(config)# interface en0s1f0
bqnadm@bqn0(config-iface)# no ddp pppoe
bqnadm@bqn0(config-iface)# root
bqnadm@bqn0(config)# interface en0s1f1
bqnadm@bqn0(config-iface)# no ddp pppoe
bqnadm@bqn0(config-iface)# root
bqnadm@bqn0(config-iface)# commit
bqnadm@bqn0(config-iface)# end
bqnadm@bqn0# system interface en0s1f0 ddp reset
DDP reset successful
bqnadm@bqn0# show interface en0s1f0 device
Driver: igb_uio
PCI class: 0x20000
PCI vendor ID: 0x8086 : Intel Corporation
PCI device ID: 0x1583 : Ethernet Controller XL710 for 40GbE QSFP+
PCI sub-vendor ID: 0x8086 : Intel Corporation
PCI sub-device ID: 0x0000
PCI slot: 0000:08:00.0
NUMA node: 0
DDP profile total: 0
DDP backup available: yes
bequant@bqn0# show interface en0s1f1 device
Driver: igb_uio
PCI class: 0x20000
PCI vendor ID: 0x8086 : Intel Corporation
PCI device ID: 0x1583 : Ethernet Controller XL710 for 40GbE QSFP+
PCI sub-vendor ID: 0x8086 : Intel Corporation
PCI sub-device ID: 0x0000
PCI slot: 0000:08:00.1
NUMA node: 0
DDP profile total: 0
DDP backup available: yes
bqnadm@bqn0 #

명령 시스템 인터페이스 ddp reset은 시스템 재부팅 없이 DDP 프로파일을 언로드합니다. 단, 전체 네트워크 카드를 재설정하려면 포트 중 하나에 적용하는 것으로 충분합니다.

문제가 지속되면 네트워크 카드의 모든 포트에서 no ddp pppoe를 유지하고 시스템을 재부팅하세요.

‍

문서 스타일링 태그

[.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 스타일링.