Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지에서
 

예: 수신 단일 속도 2색 폴리서 구성 및 멀티필드 분류자 구성을 통해 네트워크 내에서 인바운드 트래픽 제한

이 예는 단일 속도 2색 폴리서로 네트워크 내에서 고객 트래픽을 제한하는 방법을 보여줍니다. 폴리서는 토큰 버킷이라는 개념을 사용하여 어떤 트래픽이 떨어질지 식별합니다. 폴리서에서는 인터페이스 수준에서 계약 중 및 계약 외 트래픽의 CoS(Class of Service) 전략을 적용합니다. 수신 패킷, 발신 패킷 또는 둘 다에 단일 속도 2색 폴리서 적용할 수 있습니다. 이 예는 유입 트래픽에 대한 입력(수신) 폴리서로 폴리서로 폴리서를 적용합니다. 멀티필드 분류자 CoS 큐잉 옵션은 트래픽을 할당된 대기열에 배치하여 나중에 스케줄링 및 쉐이핑을 적용하여 출력 인터페이스 수준에서 리소스 활용도를 관리하는 데 도움이 됩니다.

토큰 버킷 개념과 그 기본 알고리즘에 대한 철저한 설명은 이 문서의 범위를 벗어나 있습니다. 트래픽 폴리싱 및 CoS에 대한 자세한 내용은 일반적으로 QOS 지원 네트워크( Miguel Barreiros와 Peter Lundqvist)의 도구 및 기반을 참조하십시오. 이 교재는 많은 온라인 서점과 www.juniper.net/books 이용할 수 있습니다.

요구 사항

이 절차를 확인하기 위해 이 예는 트래픽 생성기를 사용합니다. 트래픽 생성기는 하드웨어 기반이거나 서버 또는 호스트 머신에서 실행되는 소프트웨어일 수 있습니다.

이 절차의 기능은 Junos OS 실행되는 디바이스에서 널리 지원됩니다. 여기에 표시된 예는 릴리스 10.4를 Junos OS MX 시리즈 라우터에서 테스트 및 검증되었습니다.

개요

치안

단일 속도 2색 폴리싱은 제한에 부합하지 않는 트래픽에 암시적 또는 구성된 작업을 적용하여 특정 서비스 수준에 대해 구성된 트래픽 플로우 속도를 적용합니다. 인터페이스의 입력 또는 출력 트래픽에 단일 속도 2색 폴리서를 적용하면 폴리서가 다음 구성 요소에 정의된 속도 제한으로 트래픽 흐름을 측정합니다.

  • 대역폭 제한 - 인터페이스에서 수신 또는 전송되는 패킷에 대해 허용되는 초당 평균 비트 수입니다. 대역폭 제한을 초당 절대 비트 수 또는 1에서 100까지의 백분율 값으로 지정할 수 있습니다. 백분율 값이 지정되면, 효과적인 대역폭 제한은 물리적 인터페이스 미디어 속도 또는 구성된 쉐이핑 속도의 백분율로 계산됩니다.

  • 버스트 크기 제한 - 데이터 버스트에 허용되는 최대 크기. 버스트 크기는 바이트로 측정됩니다. 버스트 크기를 계산하기 위한 두 가지 공식을 권장합니다.

    버스트 크기 = 대역폭 x 버스트 트래픽 허용 시간/ 8

    또는

    버스트 크기 = 인터페이스 mtu x 10

    버스트 크기 구성에 대한 정보는 트래픽 폴리서에 대한 적절한 버스트 크기 결정 을 참조하십시오.

    참고:

    인터페이스를 위한 한정된 버퍼 공간이 있습니다. 일반적으로 인터페이스의 예상 총 버퍼 깊이는 약 125ms입니다.

구성된 제한(녹색 트래픽으로 분류)에 부합하는 트래픽 플로우의 경우, 패킷은 암시적으로 PLP(패킷 손실 우선 순위) 수준으로 표시되며 제한되지 않은 인터페이스를 통과하도록 허용됩니다.

구성된 제한(빨간색 트래픽으로 분류)을 초과하는 트래픽 플로우의 경우, 폴리서에 구성된 트래픽 폴리싱 작업에 따라 패킷이 처리됩니다. 이 예는 15KBps 제한을 초과하여 버스트된 패킷을 버립니다.

레이어 3 트래픽을 속도 제한하기 위해 다음 방법으로 2색 폴리서 를 적용할 수 있습니다.

  • 특정 프로토콜 수준에서 논리적 인터페이스에 직접 연결됩니다.

  • 특정 프로토콜 수준에서 논리적 인터페이스에 적용되는 표준 무상태 방화벽 필터의 작업으로 사용됩니다. 이 예에서 사용되는 기법입니다.

레이어 2 트래픽을 속도 제한하기 위해 2색 폴리서만 논리적 인터페이스 폴리서로 적용할 수 있습니다. 방화벽 필터를 통해 레이어 2 트래픽에 2색 폴리서 적용할 수 없습니다.

주의:

서로 배타적이기 때문에 폴리서 내에서 대역폭 제한 또는 대역폭 퍼센트 중 하나를 선택할 수 있습니다. 어그리게이션, 터널 또는 소프트웨어 인터페이스에 대역폭 퍼센트를 사용하도록 폴리서를 구성할 수 없습니다.

이 예에서 호스트는 웹 서비스를 에뮬레이션하는 트래픽 생성기입니다. 디바이스 R1 및 R2는 서비스 프로바이더가 소유하고 있습니다. 웹 서버는 디바이스 R2 뒤에 있는 사용자에 의해 액세스됩니다. 호스트는 소스 포트 TCP HTTP 포트 80 및 소스 포트 12345를 사용하여 트래픽을 사용자에게 전송합니다. 단일 속도 2색 폴리서가 구성되고 호스트를 디바이스 R1에 연결하는 디바이스 R1의 인터페이스에 적용됩니다. 폴리서에서는 웹 서버 소유자(이 경우 호스트가 에뮬레이션됨)와 호스트를 디바이스 R1에 연결하는 링크를 통해 흐르는 웹 트래픽에 대해 디바이스 R1을 소유한 서비스 프로바이더 간에 계약상의 대역폭 가용성을 적용합니다.

웹서버 소유자와 디바이스 R1 및 R2를 소유한 서비스 프로바이더 간의 계약상 대역폭 가용성에 따라 폴리서는 호스트에서 발생하는 HTTP 포트 80 트래픽과 포트 12345 트래픽을 호스트와 디바이스 R1 사이의 기가비트 이더넷 인터페이스의 최대 전송 속도 10 x의 허용 가능한 버스트 속도로 사용 가능한 대역폭의 700Mbps(70%)를 사용하는 것으로 제한합니다.

참고:

실제 시나리오에서는 종종 웹 호스팅 서비스를 통한 추가 서비스로 포함되기 때문에 FTP, SFTP, SSH, TELNET, SMTP, IMAP 및 POP3와 같은 다양한 포트의 트래픽을 속도 제한할 수 있습니다.

참고:

라우팅 프로토콜, DNS 및 네트워크 연결 운영을 유지하는 데 필요한 기타 프로토콜과 같은 네트워크 제어 프로토콜에 대해 속도에 제한되지 않는 추가 대역폭을 제공해야 합니다. 이것이 방화벽 필터에 최종 허용 조건이 있는 이유입니다.

토폴로지

이 예는 그림 1의 토폴로지 를 사용합니다.

그림 1: 단일 속도 2색 폴리서 시나리오 Single-Rate Two-Color Policer Scenario

그림 2 는 폴리싱 동작을 보여줍니다.

그림 2: 단일 속도 2색 폴리서 시나리오 Traffic Limiting in a Single-Rate Two-Color Policer Scenario 에서 트래픽 제한

멀티필드 분류

분류기는 폴리싱이 구성된 경우 라우터 또는 스위치가 모든 폴리싱을 통해 패킷을 생성한 후 패킷을 검사하고 분류하는 데 사용하는 소프트웨어 작업입니다. 분류 중에 패킷 헤더 내용을 검토하며, 이 검사는 아웃바운드 인터페이스가 모든 패킷을 처리하기에 너무 바빠서 디바이스가 패킷을 무차별적으로 떨어뜨리는 대신 패킷을 지능적으로 삭제하기를 원할 때 패킷이 어떻게 처리되는지 결정합니다. 관심 패킷을 감지하는 한 가지 일반적인 방법은 소스 포트 번호입니다. TCP 소스 포트 번호 80 및 12345는 이 예에서 사용되지만, 패킷 탐지를 위한 다른 많은 일치 기준은 방화벽 필터 일치 조건을 사용하여 멀티필드 분류자에서 사용할 수 있습니다. 이 예의 구성은 소스 포트 80이 있는 TCP 패킷이 BE-데이터 포워딩 클래스 및 대기열 번호 0으로 분류되는 것을 지정하며, 소스 포트 12345가 있는 TCP 패킷은 프리미엄 데이터 포워딩 클래스 및 대기열 1로 분류됩니다. 두 포트 번호의 트래픽은 폴리서에 의해 먼저 모니터링됩니다. 트래픽이 폴리서 를 통해 전송되면 전송을 위해 할당된 대기열의 아웃바운드 인터페이스로 전달됩니다.

패킷이 AS(Autonomous System)에 들어갈 때 멀티필드 분류자는 일반적으로 네트워크 에지에서 사용됩니다.

이 예에서 방화벽 필터 mf-classifier를 구성하고 디바이스 R1에서 일부 사용자 지정 포워딩 클래스를 지정합니다. 사용자 지정 포워딩 클래스를 지정할 때 각 클래스를 대기열과 연결합니다.

분류자 작업은 그림 3에 표시됩니다.

그림 3: TCP 소스 포트 Multifield Classifier Based on TCP Source Ports 기반의 멀티필드 분류자

멀티필드 분류자의 방화벽 필터를 필터가 필요한 각 고객 대면 또는 호스트 대면 인터페이스에 입력 필터로 적용합니다. 이 예에서는 디바이스 R1에서 수신 인터페이스 ge-2/0/5가 사용됩니다. 트래픽이 전송되는 인터페이스에서 대기열의 동작을 모니터링합니다. 이 예에서 대기열이 서비스되는 방법을 결정하기 위해 명령에서 옵션을 show interfaces 사용하여 인터페이스 ge-2/0/8의 트래픽 통계를 extensive 검사합니다.

구성

절차

CLI 빠른 구성

이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브러브를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 변경한 다음 계층 수준에서 명령을 CLI [edit] 로 복사해 붙여 넣습니다.

디바이스 R1

디바이스 R2

단계별 절차

다음 예제에서는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 이를 수행하는 방법에 대한 지침은 Junos OS CLI 사용자 가이드구성 모드에서 CLI 편집기 사용을 참조하십시오.

디바이스 R1 구성:

  1. 디바이스 인터페이스를 구성합니다.

  2. 폴리서가 700Mbps의 대역폭과 15KBps의 버스트 크기로 속도 제한을 구성합니다.

  3. 빨간색 트래픽 플로우에서 패킷을 폐기하도록 폴리서 구성합니다.

  4. 사용자 지정 포워딩 클래스 및 관련 대기열 번호를 구성합니다.

  5. 소스 포트가 80(HTTP 트래픽)인 TCP 트래픽을 대기열 0과 연결된 BE-data 포워딩 클래스로 배치하는 방화벽 필터 용어를 구성합니다.

  6. 소스 포트가 12345인 TCP 트래픽을 대기열 1과 연결된 Premium-Data Forwarding 클래스로 배치하는 방화벽 필터 용어를 구성합니다.

  7. 방화벽 필터의 끝에서 다른 모든 트래픽을 수용하는 기본 용어를 구성합니다.

    그렇지 않으면 인터페이스에 도착하여 방화벽 필터에 의해 명시적으로 수락되지 않은 모든 트래픽은 폐기됩니다.

  8. 입력 필터로 방화벽 필터를 ge-2/0/5 인터페이스에 적용합니다.

  9. OSPF를 구성합니다.

단계별 절차

디바이스 R2 구성:

  1. 디바이스 인터페이스를 구성합니다.

  2. OSPF를 구성합니다.

결과

구성 모드에서 , , show class-of-serviceshow firewallshow protocols ospf 명령을 입력show interfaces하여 구성을 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

디바이스 R1 구성이 완료되면 구성 모드에서 을(를) 입력합니다 commit .

디바이스 R2 구성이 완료되면 구성 모드에서 을(를) 입력합니다 commit .

확인

구성이 제대로 작동하는지 확인합니다.

CoS 설정 확인

목적

포워딩 클래스가 올바르게 구성되었는지 확인합니다.

작업

디바이스 R1에서 명령을 실행합니다 show class-of-service forwarding-class .

의미

출력에는 구성된 사용자 정의 분류자 설정이 표시됩니다.

카운터 삭제

목적

방화벽 및 인터페이스 카운터가 삭제되는지 확인합니다.

작업

  • 디바이스 R1에서 명령을 실행 clear firewall all 하여 방화벽 카운터를 0으로 재설정합니다.

  • 디바이스 R1에서 명령을 실행 clear interface statistics ge-2/0/5 하여 인터페이스 카운터를 0으로 재설정합니다.

TCP HTTP 포트 80에서 네트워크로 트래픽 전송 및 결과 모니터링

목적

폴리서 및 사용자 지정 대기열 수준에서 모니터링할 수 있는 트래픽을 보냅니다.

작업

  1. 트래픽 생성기를 사용하여 소스 포트가 80인 20TCP 패킷을 네트워크로 보냅니다.

    -의 플래그는 소스 포트를 설정합니다. -k 플래그는 소스 포트가 증가하지 않고 80에서 안정적으로 유지되도록 합니다. -c flag는 패킷 수를 20으로 설정합니다. -d 플래그는 패킷 크기를 설정합니다.

    참고:

    이 예에서는 폴리서 수가 8Kbps의 대역폭 제한과 1500KBps의 버스트 크기 제한으로 감소하여 일부 패킷이 누락되도록 합니다.

  2. 디바이스 R1에서 명령을 사용하여 방화벽 카운터를 show firewall 확인합니다.

    hping 출력에서는 명령 출력에 표시된 것과 같이 20%의 패킷 손실(20개 중 4개의 패킷)이 있었고 폴리서에 의해 동일한 수의 show firewall 패킷이 누락되었습니다. 또한 드롭은 방화벽 구성의 mf 분류기에 명시된 대기열 BE 데이터와 관련이 있음을 알 수 있습니다.

  3. 디바이스 R1에서 명령을 사용하여 대기열 카운터를 확인합니다 show interfaces extensive ge-2/0/8| find "Queue counters" .

    방화벽 구성의 mf 분류기에 명시된 대로 대기열 BE-데이터를 사용하여 16개의 패킷이 인터페이스 2/0/8로 전송되었습니다. 위의 그림과 같이 나머지 4개의 패킷은 폴리서에 의해 삭제되었습니다. 대기열 3으로 전송된 4개의 패킷은 네트워크 제어 트래픽입니다. 프로토콜 업데이트를 라우팅할 수 있습니다.

의미

두 디바이스의 출력 결과 4개의 패킷이 폐기되었음을 알 수 있습니다. 즉, 최소 8Kbps의 녹색(HTTP 포트 80) 트래픽이 있었고 빨간색 계약 외 HTTP 포트 80 트래픽에 대한 1500KBps 버스트 옵션이 초과되었음을 의미합니다. 2단계와 3단계에서는 나머지 트래픽을 인터페이스 2/0/8에서 전송하는 데 올바른 대기열이 사용되었음을 알 수 있습니다.

TCP 포트 12345에서 네트워크로 트래픽 전송 및 결과 모니터링

목적

폴리서 및 사용자 지정 대기열 수준에서 모니터링할 수 있는 트래픽을 보냅니다.

작업

  1. 카운터 삭제 섹션에 표시된 대로 카운터를 다시 지웁니다.

  2. 트래픽 생성기를 사용하여 12345의 소스 포트가 있는 20개의 TCP 패킷을 네트워크로 보냅니다.

    -의 플래그는 소스 포트를 설정합니다. -k 플래그는 소스 포트가 증가하지 않고 12345에서 안정적으로 유지되도록 합니다. -c flag는 패킷 수를 20으로 설정합니다. -d 플래그는 패킷 크기를 설정합니다.

  3. 디바이스 R1에서 명령을 사용하여 방화벽 카운터를 show firewall 확인합니다.

    hping 출력에서는 명령 출력에 표시된 것과 같이 20%의 패킷 손실(20개 중 4개의 패킷)이 있었고 폴리서에 의해 동일한 수의 show firewall 패킷이 누락되었습니다. 또한 드롭은 방화벽 구성의 mf 분류기에 명시된 대기열 Premium 데이터와 관련이 있음을 알 수 있습니다.

  4. 디바이스 R1에서 명령을 사용하여 대기열 카운터를 확인합니다 show interfaces extensive ge-2/0/8| find "Queue counters" .

    mf-classifier 방화벽 구성에 명시된 대로 Premium-Data Queue을 사용하여 인터페이스 2/0/8에서 16개의 패킷이 전송되었습니다. 위의 그림과 같이 나머지 4개의 패킷은 폴리서에 의해 삭제되었습니다. 대기열 3으로 전송된 19개의 패킷은 네트워크 제어 트래픽입니다. 프로토콜 업데이트를 라우팅할 수 있습니다.

의미

두 디바이스의 출력은 4개의 패킷이 폐기되었음을 보여줍니다. 즉, 최소 8Kbps의 녹색(IN-contract HTTP 포트 80) 트래픽이 있었고 빨간색 계약 외 HTTP 포트 80 트래픽에 대한 1500KBps 버스트 옵션이 초과되었습니다. 3단계와 4단계에서는 나머지 트래픽을 인터페이스 2/0/8에서 전송하는 데 올바른 대기열이 사용되었음을 알 수 있습니다.