사이버 거래
네트워크 장치를 상상해 봅시다. 내장 스위치 칩, 여러 포트 간의 트래픽을 관리하도록 구성됩니다. 특정 포트를 서로 격리하기 위해 포트가 생성되었습니다. 여러 개의 다리.
기능성 하드웨어 오프로드 장치의 CPU를 사용하는 대신 스위치 칩 자체가 트래픽을 처리하도록 하여 성능을 향상시키는 것을 목표로 이러한 브리지에 있습니다.
구성
/interface bridge
add name=bridge1
add name=bridge2
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge2 interface=ether3
add bridge=bridge2 interface=ether4
문제
성능 테스트를 수행한 후 서로 다른 브리지 간의 데이터 전송 속도에 상당한 불일치가 관찰되었습니다. 첫 번째 브리지는 최대 케이블 속도로 트래픽을 처리할 수 있지만 후속 브리지는 상당히 낮은 성능을 나타냅니다.
또한 라우팅해야 하는 패킷의 대기 시간이 상당히 길어집니다.
시스템 상태를 검사해 보니 CPU가 최대 용량으로 작동하고 있는 것으로 나타났습니다. 하드웨어 오프로드 상태를 확인하면 첫 번째 브리지에만 이 기능이 활성화되어 있음이 나타납니다.
이는 후속 브리지를 통과하는 모든 트래픽이 CPU를 통해 처리되어 병목 현상이 발생하고 성능이 최적화되지 않음을 의미합니다.
[admin@MikroTik] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW
0 H ether1 bridge1 yes
1 H ether2 bridge1 yes
2 ether3 bridge2 yes
3 ether4 bridge2 yes
이 문제의 근본 원인은 문제의 장치가 스위치 칩에서 포트 격리를 지원하지 않기 때문입니다. 이 기능이 없는 장치에서는 하나의 브리지만 하드웨어 오프로드 기능의 이점을 누릴 수 있습니다.
이로 인해 다른 브리지를 통과하는 트래픽의 CPU 사용률이 높아져 성능 저하 및 대기 시간 문제가 발생합니다.
증상 :
- 후속 브리지의 포트에 "H" 플래그(하드웨어 오프로드 표시기)가 없습니다.
- 최초가 아닌 교량에서의 낮은 데이터 전송 속도.
- CPU 사용량이 높습니다.
- 하드웨어 오프로드 없이 브리지를 통해 라우팅되어야 하는 패킷의 대기 시간이 높습니다.
문제는 포트 격리에 대한 지원 부족으로 인해 하드웨어 오프로드가 활성화된 상태에서 여러 브리지를 처리하는 장치의 제한 사항에 있습니다.
이 문제는 높은 수준의 격리와 효율성이 필요한 환경에서 일관되지 않고 잠재적으로 수용할 수 없는 네트워크 성능을 초래합니다.
가능한 결과:
1. 일관성 없는 성능:
첫 번째이자 가장 분명한 결과는 네트워크의 다양한 세그먼트에 대한 일관성 없는 낮은 성능입니다. 이는 중요한 애플리케이션이나 서비스에 대해 일정한 수준의 성능이 예상되는 경우 특히 문제가 될 수 있습니다.
2. CPU 과부하:
지속적이고 높은 CPU 사용량은 브리지를 통과하는 트래픽의 성능에 영향을 미칠 뿐만 아니라 동일한 장치에서 실행되는 다른 기능 및 서비스에도 영향을 미칠 수 있습니다.
3. 지연 문제:
VoIP나 온라인 게임처럼 대기 시간에 민감한 애플리케이션이나 서비스에서는 결과가 훨씬 더 심각해 해당 서비스를 사실상 사용할 수 없게 될 수도 있습니다.
4. 숨겨진 비용:
이 문제를 해결하기 위해 하드웨어를 변경하거나 업그레이드해야 하면 예상치 못한 추가 비용이 발생할 수 있습니다. 또한 문제를 식별하고 해결하는 데 소요되는 시간과 자원은 다른 숨겨진 비용을 나타냅니다.
제안된 솔루션:
1. 하드웨어 변경:
문제를 해결하는 가장 직접적인 방법은 하드웨어 오프로드를 통해 여러 브리지에서 포트 격리를 지원하는 장치로 전환하는 것입니다.
2. 구성 최적화:
이상적이지는 않지만 가장 중요하거나 대용량 트래픽을 처리하는 브리지에 하드웨어 오프로드 기능을 수동으로 할당하여 CPU의 로드를 줄일 수 있습니다.
/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes
3. VLAN 구현:
VLAN을 사용하여 네트워크 트래픽을 분리하는 것은 특히 현재 하드웨어가 하드웨어 오프로드의 여러 인스턴스를 지원하지 않는 경우 여러 브리지를 사용하는 것보다 더 효율적인 대안이 될 수 있습니다.
4. 펌웨어/소프트웨어 업데이트:
경우에 따라 펌웨어 또는 소프트웨어 업데이트를 통해 문제를 완화하거나 해결하는 데 도움이 되는 추가 기능을 사용할 수 있지만 하드웨어 제한인 경우에는 그럴 가능성이 낮습니다.
5. 모니터링 및 분석:
모니터링 도구는 병목 현상을 식별하고 성능을 최적화하기 위해 네트워크를 재구성하는 방법에 대한 통찰력을 제공하는 데 도움이 될 수 있지만, 이것이 근본적인 문제를 해결하지는 못합니다.
결론적으로
여러 브리지에서 하드웨어 오프로드를 제한하는 것은 네트워크의 성능과 효율성에 여러 가지 부정적인 결과를 초래할 수 있는 심각한 문제입니다.
문제를 식별하고 이해하는 것은 간단한 재구성부터 전체 하드웨어 변경에 이르기까지 가장 적합한 솔루션을 찾는 첫 번째 단계입니다.
간단한 지식 퀴즈
이 기사에 대해 어떻게 생각하시나요?
당신이 배운 지식을 감히 평가할 수 있습니까?
이 글에 추천도서
관련 기사
관련 기사
관심을 가질 만한 다른 주제
주제를 제안하고 싶으신가요?
매주 새로운 콘텐츠를 게시합니다. 구체적인 것에 대해 이야기하고 싶나요?
