이 문서에서는 Cisco Catalyst 6500 Series 플랫폼에서 WCCP(Web Cache Communication Protocol)를 사용하는 방법에 대해 설명합니다.
WCCP는 원래 웹 트래픽(HTTP)을 가로채서 로컬 캐시 디바이스에 전달하는 방법으로 설계되었으며, 이를 로컬 위치에서 클라이언트에 제공하고 값비싼 WAN 대역폭을 절약할 수 있습니다.
네트워크 사용자 관점에서 WCCP는 사용자가 특별한 컨피그레이션 없이 네트워크 레벨에서 사용되기 때문에 투명합니다. 이는 레이어 3(L3) 디바이스를 통과하는 웹 트래픽을 로컬 캐시 디바이스로 식별하고 리디렉션하기 위한 것입니다.WCCP는 원래 웹 트래픽을 위해 설계되었지만, 투명 리디렉션 방법은 볼륨 낮은 링크를 통해 대용량 콘텐츠의 다른 문제를 해결하는 매우 유용한 메커니즘이 되었습니다.따라서 이후 WCCP 버전에 프로토콜 지원이 추가되었습니다.이러한 추가 기술에는 HTTP, HTTPS, FTP, 비디오 스트리밍 및 CIFS(Common Internet File System)와 같은 파일 캐싱 기술과 같은 프로토콜이 포함됩니다. 이러한 기술은 WAFS(Wide Area File Services), WAAS(Wide Area Application Services), AON(Application Oriented Networking), ACNS(Application and Content Networking Software)의 향상된 기능과 같은 새로운 Cisco 솔루션과 플랫폼을 지원합니다.
기업이 비디오 기반 커뮤니케이션 및 교육과 같은 최신 생산성 툴과 실시간 및 온디맨드 비디오를 구현함에 따라 WCCP 도입이 증가하고 있습니다.통합 데이터 센터와 같은 비용을 제어하기 위해 WCCP는 추가적인 고대역폭 서비스를 지원할 필요가 있습니다.
오늘날의 콘텐츠 리치 네트워크를 사용하는 WCCP의 중요성 때문에 Catalyst 6500과 같은 일부 플랫폼은 WCCP를 사용하여 하드웨어 지원 성능을 구현하여 프로토콜에 필요한 CPU 부하를 줄였습니다.이 문서에서는 하드웨어 활용도를 극대화하고 CPU 로드를 줄이기 위해 Catalyst 6500에 WCCP를 구축하는 방법에 대해 설명합니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
일반적으로 WCCP라고 하는 기능에는 실제로 세 가지 구성 요소가 포함됩니다.
이 문서에서는 다음 3가지 WCCP 운영 특성을 살펴봅니다.
Catalyst 6500 Supervisor Engine 2, Supervisor Engine 32 및 Supervisor Engine 720은 다음과 같은 WCCP 기능과 방법을 지원합니다.
이러한 기능에 대한 자세한 내용은 Cisco 6500 Series Cisco IOS Software Configuration Guide, 12.2SX에서 Configuring WCCP(WCCP 구성)를 참조하십시오.
WCCP 할당은 WCCP 프로토콜이 리디렉션하는 트래픽 및 리디렉션된 트래픽을 수신하는 WCCP 엔티티를 결정합니다.
WCCP가 라우터의 인터페이스 및 WCCP 엔티티에 구성된 경우 리디렉션 디바이스(Catalyst 6500)는 리디렉션될 트래픽과 트래픽을 전송할 위치를 알아야 합니다.서비스 그룹 클러스터 내의 WCCP 엔티티는 모두 Catalyst 6500과 WCCP 프로토콜을 통해 통신합니다.그러나 클러스터의 작동 방식(할당 방법, 리디렉션 방법 등)을 제어하기 위해 클러스터를 나타내도록 하나의 WCCP 어플라이언스가 선택됩니다. WCCP 어플라이언스 및 라우터는 서비스 그룹의 웹 캐시 간에 패킷이 분산되는 방법을 협상할 수 있습니다.서비스 그룹은 최대 32개의 라우터와 32개의 WCCP 엔티티 간에 다대다 관계로 정의됩니다.협상은 서비스 그룹별로 이루어집니다.따라서 여러 서비스 그룹에 참여하는 웹 캐시는 각 서비스 그룹에 대해 다른 할당 방법을 협상할 수 있습니다.현재 사용 가능한 WCCP 서비스는 다음과 같습니다.
WCCP 서비스 | 프로토콜 |
웹 캐시 | HTTP |
53 | DNS 캐시 |
60 | FTP |
61 | WAAS - 전달 |
62 | WAAS - 역방향 |
70 | HTTPS |
80 | RTSP(Real-Time Streaming Protocol) |
81 | UDP(MMSU)를 통한 MMS(Microsoft Media Server) |
82 | MMS over TCP(MMST) |
83 | UDP를 사용하는 RTSP(RTSPU) |
89 | CIFS 캐시 WAAS |
98 | 사용자 지정 웹 캐시 |
99 | 역방향 프록시 |
90-97 | 사용자 구성 가능 * |
* 사용자가 구성할 수 있는 서비스는 인바운드 또는 아웃바운드 방향에 인터페이스 레벨 명령을 적용하여 Catalyst 6500에서 구현됩니다.인바운드 또는 아웃바운드 선택의 의미는 나중에 논의되지만, 최대 하드웨어 성능을 위해 리디렉션 목록을 WCCP와 결합할 수 있으므로 인바운드는 기본 방법입니다.
WCCP에 대해 구성된 라우터는 WCCP 통신 메시지에서 서비스 그룹에 대해 지원되는 할당 방법을 광고합니다.이러한 메시지가 없는 경우 Catalyst 6500은 기본 해시 기반 할당 방법만 지원합니다.
Catalyst 6500과 WCCP 어플라이언스 간의 협상이 완료되면 WCCP 지정 엔티티는 WCCP를 통해 어떤 트래픽이 리디렉션되고 어떤 WCCP 엔티티가 트래픽에 할당되는지 Catalyst 6500에 알립니다.예를 들어 WCCP 엔티티는 사용 가능한 WCCP 디바이스가 4개 이상인 경우 Catalyst 6500에 특정 서브넷의 모든 웹 트래픽을 서비스 그룹의 캐시 엔진 1 - 4로 리디렉션하도록 알릴 수 있습니다.
WCCP에는 두 가지 할당 방법이 있습니다.
WCCP 서비스 그룹 내의 모든 디바이스는 동일한 할당 방법을 사용해야 합니다.할당 방법은 WCCP 엔티티에 구성되며 Catalyst 6500에서 학습됩니다.자세한 내용은 WCCP 설계 권장 사항을 참조하십시오.
해시 기반 할당 메커니즘은 소프트웨어에서 수행하는 알고리즘에 의존합니다.해시 알고리즘을 활용하기 위해 특정 흐름의 첫 번째 패킷이 하드웨어 경로에서 해시가 수행되는 소프트웨어 경로로 전송됩니다.
이 소프트웨어는 흐름의 다양한 구성 요소에 대한 XOR 해시를 수행하며, 트래픽 흐름을 다양한 WCCP 엔티티로 분할하는 해시를 제공합니다.해시 메커니즘은 사용 가능한 WCCP 엔터티 간에 트래픽이 배포되는 방법을 결정합니다.
해시 결과는 하드웨어 NetFlow 테이블에 프로그래밍되며, 해당 흐름의 후속 패킷이 전달됩니다.WCCP에서 해싱할 수 있는 필드에 관계없이 전체 5튜플이 사용됩니다.즉, WCCP가 활성화된 경우 NetFlow가 인터페이스, 전체 흐름 모드로 전환됩니다.이는 NetFlow 리소스가 필요할 수 있는 다른 기능에 영향을 미칩니다.자세한 내용은 WCCP 결함 섹션을 참조하십시오.
Catalyst 6500의 WCCP에 대한 일반적인 질문은 "WCCP를 활성화하면 CPU 사용률이 왜 증가합니까?"입니다. 해시 기반 할당을 사용하는 경우 각 플로우의 소프트웨어 기반 초기 패킷 프로세싱은 CPU에 부담을 주고 사용률이 증가한 가장 큰 원인입니다.현재 사용 가능한 PFC3(Policy Feature Card 3) 포워딩 하드웨어에서 WCCP가 이그레스(egress) 기능으로 구성되었거나 해시 기반 할당이 사용 중인 경우(인그레스(ingress) 또는 이그레스(egress)) 항상 일부 레벨의 소프트웨어 처리가 필요합니다.
해시 기반 할당 방법을 사용하면 다음 기능에 영향을 줍니다.
소프트웨어 처리에 대한 해시 기반 할당 요구 사항으로 인한 제한 사항 및 영향은 인그레스(ingress) 트래픽과 이그레스(egress) 트래픽 모두에 적용됩니다.네트워크가 DoS(Denial of Service) 공격과 같은 비정상적인 트래픽 패턴을 진행 중인 경우 CPU에 미치는 영향이 커질 수 있습니다.일반적인 공격 또는 WORM 보안 침해에서는 호스트에서 전송하는 모든 패킷이 새 목적지 또는 포트로 전송되며, 이로 인해 모든 패킷이 소프트웨어에서 처리됩니다.WCCP 리디렉션 트래픽이 첫 번째 패킷 처리를 위해 CPU로 명시적으로 전송되고 있으므로 보호 방법이 제한됩니다.인터페이스에서 'deny' ACL 항목을 사용하면 CPU로 전송되는 항목을 제한할 수 있습니다.그러나 이러한 유형의 공격에 대한 속도 제한 또는 기타 보호 기능은 없습니다.
마스크 기반 할당은 인그레스 또는 이그레스(egress)에 구성되었는지에 따라 다르게 처리됩니다.
인그레스 마스크 기반 할당을 사용하면 패킷이 전달되기 전에 마스크가 ACL TCAM에 프로그래밍되므로 NetFlow 테이블 및 소프트웨어 처리가 필요하지 않습니다.WCCP 엔티티는 여러 해시 버킷을 선택하고 각 버킷에 주소 마스크 및 WCCP 어플라이언스를 할당합니다.할당이 완료되면 수퍼바이저는 각 버킷에 대해 TCAM 항목 하나와 하드웨어 인접성 하나를 프로그래밍하고 L2 재작성을 통해 주소 마스크와 일치하는 패킷을 연결된 WCCP 어플라이언스에 리디렉션합니다.
WCCP가 인그레스 기능으로 구성된 경우 하드웨어 ACL 테이블에서 ACL 리디렉션 인접성 항목을 사용할 수 있습니다.WCCP는 엔트리와 일치하면 L2 재작성 또는 GRE 캡슐화를 수행하기 위해 적절한 인접성을 사용합니다.따라서 인그레스(ingress)에서 마스크 할당을 사용하면 L2 재작성(Supervisor Engine 2, Supervisor Engine 32, Supervisor Engine 720) 및 GRE 캡슐화(Supervisor Engine 32 및 Supervisor Engine 720만 해당)가 모두 하드웨어에서 수행됩니다.
WCCP가 이그레스 기능으로 구성된 경우, 흐름의 패킷이 이미 시스템에 의해 라우팅되었기 때문에 하드웨어에서 ACL 리디렉션 인접성이 지원되지 않습니다.플로우의 첫 번째 패킷은 처리를 위해 소프트웨어로 전송됩니다.적절한 리디렉션 인접성이 확인되면 NetFlow 하드웨어(ACL TCAM 대신)에 프로그래밍되며, 여기서 엔트리는 L2 재작성 또는 GRE 캡슐화를 수행하는 인접성을 가리킵니다.플로우의 후속 패킷은 NetFlow 하드웨어에서 하드웨어로 리디렉션됩니다.
두 마스크 기반 옵션 중 인그레스 마스크 기반 할당만 초기 및 후속 패킷에 대해 전체 하드웨어 기반 포워딩을 활성화합니다.해시 기반 할당 또는 이그레스(egress) 프로세싱과 같은 다른 옵션은 초기 패킷의 소프트웨어 전환 및 후속 패킷의 하드웨어-NetFlow 스위치드 포워딩을 유발합니다.
Catalyst 6500이 아닌 WCCP 엔티티는 Catalyst 6500에 해시 테이블 및 마스크/값 세트를 지시하므로 Catalyst 6500 스위치가 아니라 해당 어플라이언스에서 리디렉션 방법의 구성이 수행됩니다.Catalyst 6500은 WCCP 엔티티/그룹과의 WCCP 통신을 기반으로 사용 가능한 최상의 리디렉션 방법을 결정합니다.이 협상은 리디렉션된 트래픽이 어플라이언스에 전달되는 방법을 결정합니다.두 가지 리디렉션 옵션이 있습니다.L3(GRE) 및 L2(MAC 주소 재작성)
WCCPv1에서는 GRE 캡슐화라고도 하는 L3 리디렉션만 사용할 수 있습니다.L3 리디렉션을 통해 각 WCCP 리디렉션 패킷은 프로토콜 유형 0x883E로 표시된 GRE 헤더에 캡슐화되고 48진수 WCCP 리디렉션 헤더가 그 다음에 WCCP 어플라이언스(예: 캐시 엔진)로 전송됩니다.
WCCPv2가 도입되면서 Catalyst 6500과 같은 하드웨어 스위칭 플랫폼을 활용하기 위해 L2 리디렉션을 추가했습니다.WCCP에서 L2 리디렉션을 사용하는 경우 WCCP 어플라이언스와 Catalyst 6500은 동일한 L2 VLAN 내에서 L2에 인접해 있어야 합니다. 리디렉션된 L2 트래픽은 GRE 캡슐화를 사용하지 않습니다.대신 MAC 목적지 주소는 Catalyst 6500에서 L2 연결 WCCP 엔티티의 주소로 재작성되고 일반 하드웨어 스위칭을 통해 전달됩니다.
WCCP L3 작업에서는 GRE를 캡슐화 방법으로 사용합니다.리디렉션된 패킷은 프로토콜 유형이 0x883e인 GRE 헤더에 캡슐화되고, 일치하는 서비스 ID 및 해시 버킷이 포함된 4바이트 WCCP 리디렉션 헤더(WCCPv2만 해당)가 포함됩니다. GRE를 사용하면 WCCP 클라이언트를 여러 L3(라우팅된) 홉으로 Catalyst 6500에서 분리할 수 있습니다.
이 시나리오에서는 WCCP 리디렉션에 사용할 수 있는 옵션은 다음과 같습니다.
Supervisor Engine 2에서 각 GRE 패킷은 처리를 위해 MSFC(Multilayer Switch Feature Card)로 전송됩니다.하드웨어에서 GRE 캡슐화가 지원되지 않으므로 MSFC는 GRE와 WCCP 헤더를 모두 적용해야 하며, 이는 모든 트래픽에 대해 소프트웨어 스위칭을 강제합니다.
해시 기반 할당 방법을 사용하면 Supervisor Engine 32 및 Supervisor Engine 720은 NetFlow 테이블 항목이 설정되도록 소프트웨어의 모든 플로우의 첫 번째 패킷을 전달합니다.그런 다음 패킷은 GRE로 캡슐화되고(초기 패킷의 캡슐화 및 포워딩은 소프트웨어에서 수행됨) WCCP 어플라이언스에 전달됩니다.
NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만 후속 패킷 포워딩은 Supervisor Engine 720 및 Supervisor Engine 32의 하드웨어에서 수행됩니다. 트래픽 패턴, 특히 고유한 플로우 수는 CPU의 사용량에 따라 결정됩니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.
수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.
Supervisor Engine 2에서 각 GRE 패킷이 처리를 위해 MSFC로 전송됩니다.하드웨어에서 GRE 캡슐화가 지원되지 않으므로 MSFC는 GRE와 WCCP 헤더를 모두 적용해야 하며, 이는 모든 트래픽에 대해 소프트웨어 스위칭을 강제합니다.
마스크 기반 할당 방법을 사용하면 GRE는 기본적으로 지원되며 마스크 할당에서는 포워딩에 ACL TCAM 하드웨어를 사용하므로 Supervisor Engine 32 및 Supervisor Engine 720이 하드웨어에서 초기 및 후속 패킷을 전달합니다.
Supervisor Engine 2에서 각 패킷은 처리를 위해 MSFC로 전송됩니다.하드웨어에서 GRE 캡슐화가 지원되지 않으므로 MSFC는 GRE와 WCCP 헤더를 모두 적용해야 하며, 이는 모든 트래픽에 대해 소프트웨어 스위칭을 강제합니다.
Supervisor Engine 32 및 Supervisor Engine 720에서 해시 기반 할당 방법을 사용하면 Catalyst 6500은 NetFlow 테이블 항목이 설정되도록 소프트웨어의 모든 플로우의 초기 패킷을 전달합니다.그런 다음 패킷은 GRE로 캡슐화되고 WCCP 엔티티로 전달됩니다.
NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU의 사용 정도를 지정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.
수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.
Supervisor Engine 2에서 각 패킷은 처리를 위해 MSFC로 전송됩니다.하드웨어에서 GRE 캡슐화가 지원되지 않으므로 MSFC는 GRE와 WCCP 헤더를 모두 적용해야 하며, 이는 모든 트래픽에 대해 소프트웨어 스위칭을 강제합니다.
Supervisor Engine 32 및 Supervisor Engine 720에서 마스크 기반 할당 방법을 사용하면 모든 플로우의 첫 번째 패킷이 소프트웨어 스위치로 전환되므로 NetFlow 테이블 항목이 설정됩니다.어떤 수퍼바이저도 이 소프트웨어 처리를 강제하고 각 플로우의 초기 패킷에 대해 NetFlow 리소스(하드웨어 ACL TCAM 대신)를 사용하는 이그레스 ACL 인접성 프로그래밍을 지원하지 않습니다.그런 다음 패킷이 GRE에 캡슐화되고 WCCP 어플라이언스에 전달됩니다.
NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU의 사용 정도를 지정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.
수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.
L2 포워딩을 사용하면 서비스 그룹 내의 WCCP 엔티티(ACNS, WAFS, WAAS 등)가 동일한 서브넷의 일부이며 Catalyst 6500에 인접한 L2입니다.따라서 트래픽의 높은 처리량, 낮은 레이턴시 리디렉션이 가능합니다.WCCP가 구성된 인그레스 인터페이스 및 WCCP 어플라이언스가 있는 인터페이스는 다른 VLAN에 있어야 합니다.
이 시나리오에서 WCCP 리디렉션에 사용할 수 있는 옵션은 다음과 같습니다.
L2 + 해시 할당을 사용하여 인그레스(ingress)에 구성된 경우 WCCP 트래픽은 모든 플로우의 첫 번째 패킷을 소프트웨어 스위치로 전송하여 하드웨어 NetFlow 테이블에 NetFlow 항목을 생성합니다.
WCCP는 상태 비저장 메커니즘이므로 소프트웨어에서 정보가 유지되지 않습니다.하드웨어에서 NetFlow 테이블의 항목으로 유지 관리됩니다.NetFlow 테이블 항목이 존재하는 한 흐름의 후속 트래픽은 하드웨어에서 전달됩니다.
NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU가 얼마나 활용되는지 결정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.
수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.
인그레스(ingress)에 구성된 경우 L2 + 마스크 할당이 Catalyst 6500에서 지원되는 가장 효율적인 WCCP 방법입니다.모든 트래픽은 각 플로우의 초기 패킷을 포함하여 하드웨어 스위칭됩니다.소프트웨어 리디렉션이 필요하지 않습니다.초기 및 후속 패킷 전달은 하드웨어에서 제공합니다.
Catalyst 6500의 하드웨어 ACL TCAM 리소스는 WCCP 패킷이 수신되기 전에 하드웨어 항목을 사전 프로그래밍하기 위해 사용됩니다.
이 방법을 사용하고 전체 하드웨어 스위칭을 활용하려면 WCCP 엔티티는 L2 리디렉션과 마스크 기반 할당 방법도 지원해야 합니다.이 방법의 컨피그레이션은 WCCP 엔티티에서 완료되며, Catalyst 6500은 WCCP 엔티티/그룹과의 초기 통신 중에 최상의 방법을 협상합니다.
이그레스 L2 + 해시 할당을 통해 WCCP 트래픽은 모든 플로우의 첫 번째 패킷을 소프트웨어 스위치로 전송하여 하드웨어 NetFlow 테이블에 NetFlow 항목을 생성합니다.
또한 이그레스(egress) 방향으로 구성할 경우, CE와 관련된 인접성을 확인하기 위해 흐름의 첫 번째 패킷에 추가 FIB(forwarding information base) 조회가 필요합니다. 이 경우 Catalyst 6500 내에서 패킷 재순환이 필요합니다.후속 패킷은 하드웨어에서 NetFlow 스위칭됩니다.
NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU가 얼마나 활용되는지 결정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.
수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.
이그레스 방향으로 구성된 경우 L2 + 마스크 할당은 L2 + 해시 할당 사례와 같이 소프트웨어의 각 플로우에서 첫 번째 패킷을 전환합니다.후속 패킷은 하드웨어에서 NetFlow 스위칭됩니다.
PFC2 및 PFC3는 이그레스 ACL 인접성 프로그래밍을 지원하지 않으므로 각 흐름에서 초기 패킷에 대한 소프트웨어 프로세싱을 강제로 수행합니다.플로우의 후속 패킷은 하드웨어에서 전달됩니다.
NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU가 얼마나 활용되는지 결정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.
수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.
WCCP를 사용하여 트래픽을 가로채고 WCCP 엔티티가 해당 패킷에 대해 전체 작업을 수행하면 패킷이 WCCP 디바이스에서 클라이언트로 다시 전송될 준비가 됩니다.일반적으로 처리된 이 트래픽은 네트워크의 클라이언트로 다시 전송되며, WCCP 디바이스에서 클라이언트로 다시 전송될 때 특별한 캡슐화가 필요하지 않습니다.
WCCP 가로채기로 인해 클라이언트 요청이 성공적으로 처리되었기 때문에(캐시에서 파일, 캐시에서 스트림 분할, WAAS에서 파일) 패킷의 대상 주소가 원래 요청자가 되는 패킷의 일반 트래픽으로 다시 네트워크로 전송될 수 있습니다.이 트래픽은 WCCP 어플라이언스에서 클라이언트로 네트워크 경로에 있는 경우 Catalyst 6500에서 일반적으로 L3/스위칭할 수 있습니다.L2 연결 WCCP 어플라이언스를 사용하면 트래픽이 네트워크 경로에 있습니다.대상이 이제 인터넷 또는 인트라넷의 서버가 아닌 원래 클라이언트로 변경되었으므로 WCCP 디바이스에서 Catalyst 6500으로 다시 전송하기 위해 캡슐화가 필요하지 않습니다.그런 다음 네트워크는 다른 IP 트래픽 흐름과 마찬가지로 이를 처리하고 Catalyst 6500의 하드웨어 포워딩을 사용하여 요청된 트래픽을 클라이언트로 반환합니다.
WCCP 엔티티가 요청된 작업을 수행할 수 없는 경우 WCCP 어플라이언스는 트래픽을 Catalyst 6500으로 다시 전송하고 패킷의 원래 목적지를 유지해야 할 수 있습니다.캡슐화 없이 WCCP 엔티티에서 이 트래픽을 전달하면 트래픽 루프가 발생할 수 있습니다.클라이언트에서 실패한 서비스 시도를 숨기고 원래 목적지로 패킷을 전송하여 서비스하려면 패킷은 변경되지 않고 원래 포워딩 경로에 다시 배치되고 원래 목적지로 WCCP 가로채기 없이 전달되어야 합니다.
WCCP 반환 방법에서 WCCP를 사용하여 이러한 패킷을 캡슐화하고, 처음부터 가로챈 디바이스로 다시 전송하고, 캡슐화를 해제한 다음, 가로챈 전달 경로에 다시 배치할 수 있습니다.이러한 패킷은 WCCP에서 가로채지 않은 것처럼 정상적으로 전송해야 합니다.
이러한 사례의 예는 다음과 같습니다.
현재 이 반환 방법은 GRE 캡슐화를 통해서만 수행할 수 있으며 Catalyst 6500 하드웨어에서 아직 지원되지 않습니다.이 방법으로 많은 양의 트래픽을 Catalyst 6500으로 다시 보내는 경우 이 트래픽이 소프트웨어에서 처리되기 때문에 높은 CPU 사용률이 발생할 수 있습니다.Cisco IOS Software 릴리스 12.1(18)SXH에는 Catalyst 6500 하드웨어에서 지원하는 L2 반환 방법이 있습니다.
12.2(18)SXH 이전 Cisco IOS 소프트웨어 릴리스에서는 Catalyst 6500에 대해 지원되는 유일한 반환 방법은 GRE 캡슐화입니다.반환 트래픽에 추가된 GRE 헤더 외에 WCCP 헤더도 추가됩니다.GRE는 Supervisor Engine 32 및 Supervisor Engine 720 하드웨어에서 기본적으로 지원되지만 이 추가 헤더는 GRE가 하드웨어 지원을 받지 않게 됩니다.Catalyst 6500 및 WCCP 어플라이언스는 모두 L2 반환 방법을 지원하고 협상해야 합니다.
GRE, 인그레스, 이그레스 또는 WCCP 반환에 대한 GRE 하드웨어 지원이 Supervisor Engine 2에 없습니다.이러한 유형의 GRE 캡슐화를 처리하기 위해 Cisco IOS 소프트웨어는 WCCP 지원 인터페이스에서 WCCP GRE 터널 수신 인접성을 프로그래밍하여 RP(Route Processor)를 가리키도록 하며, 이로 인해 반환 트래픽이 소프트웨어 프로세싱됩니다.
GRE를 통해 반환해야 할 트래픽을 방지하기 위해 Catalyst 6500에서 리디렉션 목록을 사용하는 것은 WCCP 엔티티에서 다시 전송되는 트래픽의 소프트웨어 처리 요구 사항을 줄이는 효과적인 방법입니다.이는 WCCP 엔티티에서 트래픽을 거부하고 GRE를 캡슐화하여 Catalyst 6500으로 다시 전송하도록 하는 것보다 훨씬 효과적입니다.
WCCP 서비스 그룹은 확장 가능합니다.과부하 때문에 초과 트래픽이 우회되면 이 트래픽이 다시 전송되어 Catalyst 6500에 CPU 로드가 생성됩니다.WCCP 서비스 그룹의 적절한 확장 또는 오버빌드가 이러한 상황을 방지하는 유일한 방법입니다.
12.2(18)SXH에서 옵션을 사용하면 WCCP 엔티티가 반환 트래픽을 캡슐화하지 않고 L2 MAC 주소를 다시 쓸 수 있습니다.이 L2 반환 개선 사항(Cisco 버그 ID CSCuk59825)은 WCCP가 마스크 할당과 인그레스 리디렉션을 사용하도록 구성된 경우 반환된 트래픽의 하드웨어 처리를 활성화합니다.
Catalyst 6500에서 구현된 경우, WCCP는 이 표에 나와 있는 것처럼 다양한 구성 옵션을 제공합니다.WCCP 어플라이언스는 이러한 옵션을 협상하고 Catalyst 6500에서 사용하는 옵션을 제어합니다.컨피그레이션은 WCCP 연결의 WCCP 어플라이언스 쪽에서 수행됩니다.
리디렉션 방법 | 배정 메서드 |
인그레스/ 이그레스 |
스위칭 결과 |
L2 | 해시 | 인그레스 | 소프트웨어 처리 |
L2(권장) | Mask | 인그레스 | ACL TCAM을 통한 전체 하드웨어 처리 |
L2 | 해시 | 이그레스 | 소프트웨어 처리 |
L2 | Mask | 이그레스 | 소프트웨어 처리 |
GRE | 해시 | 인그레스 | 소프트웨어 처리 |
GRE(PFC3 이상) | Mask | 인그레스 | NetFlow 전체 플로우를 통한 전체 하드웨어 처리 |
GRE | 해시 | 이그레스 | 소프트웨어 처리 |
GRE | Mask | 이그레스 | 소프트웨어 처리 |
하드웨어의 관점에서 모든 이그레스 WCCP 컨피그레이션에는 소프트웨어 처리가 필요하며 CPU 사용률에 영향을 미칩니다.또한 해시 기반 할당 방법을 사용하여 CPU 사용률에 동일한 영향을 미칠 수 있는 경우 인그레스(ingress)에도 소프트웨어 처리가 필요합니다.
Catalyst 6500에서 WCCP 구축의 권장 방법은 마스크 할당을 사용하는 L2 리디렉션(사용 가능한 경우 L2 반환)입니다.
상황에 맞는 최적의 WCCP 구축 방법을 결정할 수 있도록 이러한 컨피그레이션 권장 사항을 사용하십시오.
WCCP 인그레스(ingress)를 리디렉션 방법으로 사용할 수 있도록 네트워크를 설계합니다.효율적인 설계 방법은 계층적 L3 배포 네트워크의 일부로 캐싱 스위치 블록을 갖는 것입니다.이를 통해 몇 개의 주요 인그레스 포트에서 WCCP 서비스 트래픽을 식별할 수 있습니다.
또한 Cisco Advanced Service는 다음과 같은 설계 고려 사항을 권장합니다.
Catalyst 6500으로 다시 전송되는 패킷을 방지하려면 스위치에서 리디렉션 목록을 사용합니다.캐시 디바이스의 규칙을 리디렉션 목록으로 Catalyst 6500으로 이동할 수 있는 경우 하드웨어 성능이 향상될 수 있습니다.
인그레스-L2 마스크 할당 이외의 방법을 사용하면 Supervisor Engine 720 플랫폼의 NetFlow 리소스를 빠르게 사용할 수 있습니다.Supervisor Engine 720은 다른 어떤 방법으로도 Supervisor Engine 2보다 나은 성능을 제공하지 않습니다.
Supervisor Engine 720 또는 Supervisor Engine 32를 비최적 설계에서 사용해야 하는 경우 WCCP 초기 패킷의 NetFlow 처리 속도를 높일 수 있도록 mls ip netflow creation software-mode fast 명령을 사용하십시오.이렇게 하면 Supervisor Engine 32 및 Supervisor Engine 720 NetFlow에 추가된 향상된 기능이 제거되고 Supervisor Engine 2 NetFlow 하드웨어와 동일한 성능이 제공됩니다.
마스크 할당을 위한 Cisco CE(Content Engine)의 구성은 다음과 같습니다.
NetFlow 사용률을 검토하고 WCCP에서 NetFlow 항목을 모두 사용하고 있으며 소프트웨어 처리를 사용하고 있는지 확인하려면 다음 명령을 사용합니다.
NetFlow 리소스가 사용되고 있어 WCCP 소프트웨어 문제가 발생하는 경우 이러한 명령은 기존 항목을 적극적으로 지우고 새 항목을 위한 공간을 생성할 수 있습니다.(NetFlow 공간보다 더 많은 항목이 있는 경우에는 도움이 되지 않습니다.)
패킷 삭제를 방지하려면 WCCP 엔티티는 WCCP가 구성된 인터페이스가 아닌 인터페이스에서 트래픽을 리디렉션해야 합니다.모든 조건이 충족되면 Catalyst 6500 WCCP는 이 상황에서 패킷을 삭제합니다.
이러한 상황은 Catalyst 6500에 내장된 보호 메커니즘으로 인해 발생합니다.Cisco IOS 소프트웨어는 패킷이 동일한 Cisco IOS 소프트웨어 가상 인터페이스로 들어오고 나가는 것을 방지하는 검사를 수행하며, 이 경우 패킷이 루프되어 원하지 않는 동작이 발생할 수 있습니다.이를 방지하기 위해 WCCP 어플라이언스를 전용 L3 환경으로 이동합니다.
UBRL(사용자 기반 속도 제한)과 WCCP는 flowmask로 인해 인터페이스에서 동시에 작동하지 않습니다.각 유니캐스트 기능에 대해 각 인터페이스에 하나의 flowmask가 있습니다.WCCP에는 전체 흐름이 필요하며 UBRL은 src 전용 또는 dst-only를 사용합니다.
12.2(18)SXF5에서 Supervisor Engine 2 및 L2 반품에 대해 WCCP 지원이 추가되었습니다. 이 지원은 2007년 4월/5월 12.2(18)SXH까지 Supervisor Engine 720에서 이루어지지 않았습니다.
WCCP L2 PFC 리디렉션만 Cisco IOS SLB(software server load balancing)에서 지원됩니다.다른 WCCP 컨피그레이션은 호환되지 않으며 GRE가 작동하지 않습니다.WCCP 가속 명령은 Supervisor Engine 2/MSFC2에만 적용됩니다. 이 명령의 목적은 라우터가 마스크 할당과 L2 리디렉션을 협상하도록 하는 것입니다. 즉, 모든 WCCP 리디렉션이 하드웨어에서 수행됩니다.Supervisor Engine 32 및 Supervisor Engine 720은 이 명령을 사용하지 않고 이를 협상합니다.
표준 투명 캐싱 리디렉션의 경우 WCCP 엔티티가 WCCP 라우터에 지원되는 방법을 제공하며 이를 위해 구성해야 할 수도 있습니다.Cisco ACNS의 경우 이 컨피그레이션에서는 최적화된 L2 리디렉션 및 마스크 기반 할당 방법을 요청합니다.
ContentEngine(config)# wccp version 2
ContentEngine(config)# wccp router-list 1 172.16.16.1
ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign
라우터 측에서 Catalyst 6500 설계는 WCCP 디바이스가 현재 트래픽 경로(인그레스 또는 이그레스)에 없는 전용 L3 인터페이스에 있는지 확인해야 합니다. 하드웨어 성능의 경우 단일 이그레스 인터페이스를 선택한 경우보다 더 많은 인터페이스를 구성해야 하는 경우에도 Catalyst 6500에 대한 인바운드 트래픽을 캡처해야 합니다.이상적인 설계에서는 이 디바이스에 도달하기 전에 모든 트래픽을 집계하며, 몇 개의 인터페이스만 WCCP 인그레스 컨피그레이션을 필요로 합니다.
Catalyst 6500의 WCCP 구성은 다음과 같아야 합니다.
6500Switch# ip wccp version {1 | 2}
6500Switch (config)# ip wccp service [accelerated] redirect-list access-list12.1E Cisco IOS 소프트웨어가 포함된 Supervisor Engine 2 플랫폼에만 accelerated 명령을 사용합니다.
리디렉션 목록은 리디렉션을 위해 선택되거나 선택되지 않은 트래픽을 식별하기 위해 사용됩니다.WCCP 디바이스에서 처리할 수 없는 트래픽에 대한 리디렉션을 방지하는 보다 효율적인 방법인 하드웨어에서 이 ACL을 수행할 수 있습니다.디바이스로 전송되고 서비스할 수 없는 트래픽은 원래 트래픽 경로에 다시 삽입하기 위해 이 Catalyst 6500으로 반환되어야 합니다. 이 경우 추가 처리가 필요합니다.WCCP 액세스 목록은 표준 또는 확장 액세스 목록입니다.
이 예에서는 10.1.1.1에서 12.1.1.1으로 요청이 전송되면 캐시가 무시되고 다른 모든 요청이 리디렉션됩니다.
6500Switch(config)# ip wccp service redirect-list 120
6500Switch(config)# access-list 120 deny tcp host 10.1.1.1 any
6500Switch(config)# access-list 120 deny tcp any host 12.1.1.1
6500Switch(config)# access-list 120 permit ip any any
리디렉션할 트래픽을 수신하는 각 인그레스 인터페이스에서 인그레스 WCCP 방법을 구성합니다.
Router(config-if)# ip wccp service redirect in
이렇게 하면 WCCP 어플라이언스 및 스위치의 컨피그레이션이 완료되므로 이 시점에서 트래픽 리디렉션이 발생해야 합니다.
디바이스의 최종 WCCP 컨피그레이션은 다음과 같습니다.
장치 | 구성 |
WCCP 어플라이언스 | wccp version 2 |
WCCP 라우터: 글로벌 |
ip wccp version 2 |
WCCP 라우터: 각 인그레스 인터페이스 |
ip wccp redirect service in |
이 컨피그레이션을 확인하려면 다음 명령을 입력합니다.
Show ip wccp service detail
멀티캐스트 또는 추가 WCCP 보안을 사용하여 그룹 주소 지정 등의 추가 WCCP 구성 옵션은 WCCP를 사용하여 Web Cache Services 구성을 참조하십시오.
WCCP 및 하드웨어 포워딩을 사용하는 경우 일부 카운터가 예상대로 표시되지 않을 수 있습니다.
NetFlow 하드웨어 리소스를 사용해야 하는 WCCP 컨피그레이션이 있는 경우 다음 MLS(Multilayer Switching) 및 FM(Fabric Manager) 명령을 사용하여 NetFlow 리소스의 상태를 검토할 수 있습니다.
이 Cisco 버그 ID 및 해결 방법 표는 WCCP를 가장 잘 지원하기 위해 Cisco IOS Software 릴리스 12.2(18)SXF7 이상을 사용하는 일반적인 권장 사항을 지원합니다.
Cisco 버그 ID | Cisco IOS Software 릴리스에서 해결됨 | 세부 정보 |
CSCsd20327 | 12.2(18)SXF7 | 서비스 90용 WCCP는 작동 및 중단되며 WCCP 서비스가 손실됩니다.이 문제는 서비스 81, 82 및 90을 구성할 때 발생합니다.패킷 추적은 라우터가 잘못된 대상 IP 주소가 포함된 'I_See_You' 메시지를 사용하여 캐시에서 'Here_I_Am' 메시지에 응답할 수 있음을 나타냅니다. |
CSCsa77785 | 12.2(18)SXF6 | 호스트 기반 표준 ACL을 WCCP 리디렉션 ACL로 사용하여 WCCP L2 리디렉션 및 마스크 할당 모드를 사용하는 경우 다시 로드가 발생할 수 있습니다. |
CSCse69713 | 12.2(18)SXF6 | WCCP 서비스 그룹의 모든 캐시 엔진이 손실되면 트래픽은 스위치드 인 하드웨어 대신 소프트웨어에서 처리됩니다. |
CSCsd28870 | 12.2(18)SXF5 | WCCP 리디렉션 ACL 목록에서 log 키워드로 구성된 ACE는 TCAM 테이블에 프로그래밍되지 않습니다. |
CSCsb61021 | 12.2(18)SXF5 | IP 스푸핑 기능이 캐시 엔진에 구성되어 있고 이그레스 방향으로 WCCP 리디렉션이 구성된 경우 Supervisor Engine 720 또는 Supervisor Engine 32에서 높은 CPU 사용률이 발생할 수 있습니다.클라이언트 또는 서버의 대상이 있는 캐시 엔진의 IP 스푸핑 패킷은 하드웨어 대신 소프트웨어에서 전환됩니다. 이를 해결하려면 인바운드 및 아웃바운드 인터페이스 모두에 대해 ip wccp service redirect in 명령을 사용합니다. |
CSCsb21972 | 12.2(18)SXF2 | WCCP와 NDE가 모두 구성된 경우 정렬 오류로 인해 수많은 역추적(tracebacks)이 표시될 수 있으며, CPU 사용률이 허용되지 않을 만큼 높을 수 있습니다. |
CSCeh85087 | 12.2(18)SXF | WCCP 리디렉션 ACL에 사용자가 구성한 'deny ip any'(deny ip any any)가 있고 많은 WCCP 서비스 그룹이 서비스되는 경우 일부 서비스 그룹과 연결된 트래픽은 CE 라우터로 리디렉션되지 않습니다. |
CSCeh56916 | 12.2(18)SXF | WCCP 서비스가 활성화된 경우 마스크 할당이 할당 방법으로 구성되고 서비스 그룹에 5개 이상의 캐시가 있는 경우 캐시로 전송된 프로토콜 메시지가 오버플로되어 메모리가 손상되고 다시 로드될 수 있습니다. |
CSCsb18740 | 12.2(18)SXF 및 SXE6 | GRE 기반 전달 모드에서 WCCP는 MSFC CPU 사용률을 높이는 소프트웨어 캐시를 불필요하게 사용합니다. |
CSCsb26773 | 12.2(18)SXF | 인바운드 ACL을 사용하면 리디렉션된 모든 트래픽이 손실되어 WCCP 리디렉션이 실패할 수 있습니다. |
CSCsa90830 | 12.2(18)SXE2 | WCCP 인그레스 리디렉션 트래픽은 마스크 할당 모드로 GRE 전달을 위해 캐시 엔진이 구성된 경우 하드웨어 스위칭에 NetFlow 테이블을 사용합니다.NetFlow 테이블이 가득 차면 WCCP 인그레스 리디렉션이 실패합니다. |
CSCec55429 | 12.2(18)SXE | WCCP 서비스 그룹 목록은 우선 순위가 아닌 서비스 그룹이 생성된 순서대로 검사됩니다.여러 동적 WCCP 서비스가 정의된 경우 둘 이상의 서비스 그룹에 대한 선택 기준과 일치하는 트래픽은 우선순위가 가장 높은 서비스 그룹으로 리디렉션되지 않습니다. |
CSCuk50878 | 12.2(18)SXE | Cisco 버그 ID CSCec55429가 해결된 릴리스에서 서비스 그룹의 모든 캐시에 대해 여러 WCC 'cache lost' 및 'cache found' 이벤트가 발생한 후 이러한 이벤트가 발생할 수 있습니다.
|
CSCsa67611 | 12.2(18)SXE | 출력 기능이 구성된 비 MPLS 인터페이스(태그-IP 경로)에서 나가는 수신 MPLS(Multiprotocol Label Switching) 패킷에는 출력 기능이 적용되지 않을 수 있습니다(예: 이그레스 ACL 또는 이그레스 WCCP).이 문제는 출력 ACL 조회를 우회하기 때문에 발생합니다. |
CSCeh13292 | 12.2(18)SXD4 | Supervisor Engine 720에서 WCCPv2를 구성하면 CPU 사용률이 높습니다. |
CSCeb28941 | 12.2(18)SXD1 | NAT(Network Address Translation)는 구성된 WCCP에서 작동하지 않습니다. |
CSCed92290 | 12.2(17d)SXB2 | ARP(next-hop Address Resolution Protocol) 캐시 항목이 없는 WCCP 리디렉션 패킷은 ARP 요청을 생성하기 위해 프로세스 스위칭됩니다.그러나 WCCP 리디렉션 때문에 ARP 요청이 전송되지 않으며, ARP 캐시는 다음 홉에 대해 채워지지 않으며, 후속 WCCP 리디렉션 패킷은 계속 프로세스 스위칭됩니다. |
CSCuk59825 | 12.2(17d)SXF5 -Sup2 Whitney1.0(Sup720용) | 이 Cisco IOS 소프트웨어 릴리스는 L2 반환 트래픽에 대한 하드웨어 지원을 추가했습니다.WCCP RFC(Request for Comment)는 L2 반환을 라우터와 캐시 간의 협상을 위한 선택적 기능으로 지정합니다.지금까지 Cisco IOS 소프트웨어의 WCCP는 필요한 하드웨어 지원이 없기 때문에 이 기능의 협상을 허용하지 않았습니다.이제 이러한 지원을 사용할 수 있으므로 라우터와 캐시 간의 WCCP 프로토콜 교환에서 L2 반환 협상을 활성화할 수 있습니다. |