CPU 사용률이 높은 Catalyst 6500 플랫폼의 WCCP 컨피그레이션 가이드

소개

이 문서에서는 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
• Cisco Catalyst 6500 Series 스위치
• Cisco IOS^® 소프트웨어

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• Cisco Catalyst 6500 Series 스위치
• Cisco IOS Software 릴리스 12.1(50)SY 이상(Supervisor Engine 2T 포함)(정책 기능 카드 4)
• Cisco IOS Software 릴리스 12.2(18)SXD1 이상(Supervisor Engine 720 포함)(정책 기능 카드 3)

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

WCCP 기능 개요

일반적으로 WCCP라고 하는 기능에는 실제로 세 가지 구성 요소가 포함됩니다.

1. 라우터 또는 스위치에서만 구현되는 기능
2. 웹 캐시와 같은 트래픽 처리 엔티티에서만 구현된 기능
3. WCCP는 양쪽에 구현됨

이 문서에서는 다음 3가지 WCCP 운영 특성을 살펴봅니다.

1. 할당 방법은 어떤 WCCP 트래픽과 트래픽의 대상에 대해 어떤 WCCP 디바이스를 선택할지 결정합니다.WCCP 프로토콜은 함께 클러스터링된 여러 디바이스를 지원합니다.
2. 리디렉션 방법은 트래픽이 이동하던 일반 네트워크 경로에서 변경해야 할 경우 WCCP 어플라이언스에 트래픽 흐름을 전달합니다.
3. 반환 방법은 트래픽을 처리할 수 없는 경우 WCCP 어플라이언스에서 라우터로 트래픽을 다시 전송하는 방법을 결정합니다.WCCP 어플라이언스가 요청을 서비스하는 경우 패킷은 요청자에게 직접 반환됩니다.

WCCP 및 Catalyst 6500

Catalyst 6500 Supervisor Engine 2, Supervisor Engine 32 및 Supervisor Engine 720은 다음과 같은 WCCP 기능과 방법을 지원합니다.

• WCCP 버전 2(WCCPv2)
• 해시 기반 할당 방법
• 마스크 기반 할당 방법(하드웨어 가속)
• L3 GRE(Generic Routing Encapsulation) 리디렉션 방법(Supervisor Engine 32 및 Supervisor Engine 720에서 하드웨어 가속)
• 레이어 2(L2) 리디렉션 방법(Supervisor Engine 2, Supervisor Engine 32 및 Supervisor Engine 720에서 하드웨어 가속)
• GRE 반환 방법
• Cisco IOS Software Release 12.2SXH를 사용한 L2 반환 방법(Supervisor Engine 2, Supervisor Engine 32 및 Supervisor Engine 720에서 하드웨어 가속)

이러한 기능에 대한 자세한 내용은 Cisco 6500 Series Cisco IOS Software Configuration Guide, 12.2SX에서 Configuring WCCP(WCCP 구성)를 참조하십시오.

WCCP 할당 방법

WCCP 할당은 WCCP 프로토콜이 리디렉션하는 트래픽 및 리디렉션된 트래픽을 수신하는 WCCP 엔티티를 결정합니다.

WCCP가 라우터의 인터페이스 및 WCCP 엔티티에 구성된 경우 리디렉션 디바이스(Catalyst 6500)는 리디렉션될 트래픽과 트래픽을 전송할 위치를 알아야 합니다.서비스 그룹 클러스터 내의 WCCP 엔티티는 모두 Catalyst 6500과 WCCP 프로토콜을 통해 통신합니다.그러나 클러스터의 작동 방식(할당 방법, 리디렉션 방법 등)을 제어하기 위해 클러스터를 나타내도록 하나의 WCCP 어플라이언스가 선택됩니다. WCCP 어플라이언스 및 라우터는 서비스 그룹의 웹 캐시 간에 패킷이 분산되는 방법을 협상할 수 있습니다.서비스 그룹은 최대 32개의 라우터와 32개의 WCCP 엔티티 간에 다대다 관계로 정의됩니다.협상은 서비스 그룹별로 이루어집니다.따라서 여러 서비스 그룹에 참여하는 웹 캐시는 각 서비스 그룹에 대해 다른 할당 방법을 협상할 수 있습니다.현재 사용 가능한 WCCP 서비스는 다음과 같습니다.

* 사용자가 구성할 수 있는 서비스는 인바운드 또는 아웃바운드 방향에 인터페이스 레벨 명령을 적용하여 Catalyst 6500에서 구현됩니다.인바운드 또는 아웃바운드 선택의 의미는 나중에 논의되지만, 최대 하드웨어 성능을 위해 리디렉션 목록을 WCCP와 결합할 수 있으므로 인바운드는 기본 방법입니다.

WCCP에 대해 구성된 라우터는 WCCP 통신 메시지에서 서비스 그룹에 대해 지원되는 할당 방법을 광고합니다.이러한 메시지가 없는 경우 Catalyst 6500은 기본 해시 기반 할당 방법만 지원합니다.

Catalyst 6500과 WCCP 어플라이언스 간의 협상이 완료되면 WCCP 지정 엔티티는 WCCP를 통해 어떤 트래픽이 리디렉션되고 어떤 WCCP 엔티티가 트래픽에 할당되는지 Catalyst 6500에 알립니다.예를 들어 WCCP 엔티티는 사용 가능한 WCCP 디바이스가 4개 이상인 경우 Catalyst 6500에 특정 서브넷의 모든 웹 트래픽을 서비스 그룹의 캐시 엔진 1 - 4로 리디렉션하도록 알릴 수 있습니다.

WCCP에는 두 가지 할당 방법이 있습니다.

1. 해시 기반 할당(기본값)은 WCCP 지정 어플라이언스의 지시문과 함께 소프트웨어 기반 해시 알고리즘을 사용하여 어떤 WCCP 어플라이언스가 트래픽을 수신하는지 확인합니다.Supervisor Engine 32 또는 Supervisor Engine 720 플랫폼에서는 NetFlow 하드웨어 리소스를 사용하여 일부 수준의 하드웨어 지원을 적용합니다.
2. 마스크 기반 할당은 WCCP 엔티티에 트래픽을 할당하기 위해 Catalyst 6500의 하드웨어 기능, 특히 ACL(Access Control List) TCAM(Ternary Content Addressable Memory)을 사용합니다.이것이 기본 방법입니다.

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)) 항상 일부 레벨의 소프트웨어 처리가 필요합니다.

해시 기반 할당 방법을 사용하면 다음 기능에 영향을 줍니다.

• NetFlow 테이블 - PFC에서 지원하는 항목 수가 제한되고 플로우 마스크가 전체 NetFlow 테이블에 대해 인터페이스 전체 플로우로 변경됩니다.
• CPU 사용률 - 각 플로우의 첫 번째 패킷이 소프트웨어 스위치로 바뀌므로 CPU 사용률이 증가합니다.
• 성능 - 조회를 위해 CPU로 트래픽을 보내는 속도가 제한되므로 CPU가 보호됩니다.
• NetFlow 기능 - NetFlow 리소스를 사용하는 기타 기능은 NetFlow 리소스를 WCCP에서 사용하는 경우 영향을 받을 수 있습니다.

소프트웨어 처리에 대한 해시 기반 할당 요구 사항으로 인한 제한 사항 및 영향은 인그레스(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 하드웨어에서 하드웨어로 리디렉션됩니다.

참고:WCCP가 이그레스(egress) 기능으로 구성된 경우 마스크 할당에는 마스크 기반 할당 방법의 모든 이점이 부정되는 소프트웨어 처리가 필요합니다.

두 마스크 기반 옵션 중 인그레스 마스크 기반 할당만 초기 및 후속 패킷에 대해 전체 하드웨어 기반 포워딩을 활성화합니다.해시 기반 할당 또는 이그레스(egress) 프로세싱과 같은 다른 옵션은 초기 패킷의 소프트웨어 전환 및 후속 패킷의 하드웨어-NetFlow 스위치드 포워딩을 유발합니다.

WCCP 리디렉션 방법

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 디바이스로 전달하는 방법은 트래픽을 Catalyst 6500으로 다시 보내기 위해 WCCP 디바이스에서 사용하는 방법과 다를 수 있습니다.WCCP는 두 디바이스 모두 지원하는 전달 및 반환 방법을 협상하기 위해 사용됩니다.WCCP 반환 방법을 참조하십시오.

L3(GRE) 포워딩 방법

WCCP L3 작업에서는 GRE를 캡슐화 방법으로 사용합니다.리디렉션된 패킷은 프로토콜 유형이 0x883e인 GRE 헤더에 캡슐화되고, 일치하는 서비스 ID 및 해시 버킷이 포함된 4바이트 WCCP 리디렉션 헤더(WCCPv2만 해당)가 포함됩니다. GRE를 사용하면 WCCP 클라이언트를 여러 L3(라우팅된) 홉으로 Catalyst 6500에서 분리할 수 있습니다.

이 시나리오에서는 WCCP 리디렉션에 사용할 수 있는 옵션은 다음과 같습니다.

1. 인그레스 - L3(GRE) 리디렉션 + 해시 할당;소프트웨어 처리가 필요합니다.
2. 인그레스 - L3(GRE) 리디렉션 + 마스크 할당;이를 위해서는 전체 하드웨어 처리가 필요하며 Supervisor Engine 32 또는 Supervisor Engine 720에서만 사용할 수 있습니다.
3. 이그레스 - L3(GRE) 리디렉션 + 해시 할당;소프트웨어 처리가 필요합니다.
4. 이그레스 - L3(GRE) 리디렉션 + 마스크 할당;소프트웨어 처리가 필요합니다.

인그레스 - L3(GRE) 리디렉션 + 해시 할당

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에서 사용할 수 있습니다.

인그레스 - L3(GRE) 리디렉션 + 마스크 할당

Supervisor Engine 2에서 각 GRE 패킷이 처리를 위해 MSFC로 전송됩니다.하드웨어에서 GRE 캡슐화가 지원되지 않으므로 MSFC는 GRE와 WCCP 헤더를 모두 적용해야 하며, 이는 모든 트래픽에 대해 소프트웨어 스위칭을 강제합니다.

마스크 기반 할당 방법을 사용하면 GRE는 기본적으로 지원되며 마스크 할당에서는 포워딩에 ACL TCAM 하드웨어를 사용하므로 Supervisor Engine 32 및 Supervisor Engine 720이 하드웨어에서 초기 및 후속 패킷을 전달합니다.

이그레스 - L3(GRE) 리디렉션 + 해시 할당

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에서 사용할 수 있습니다.

이그레스 - L3(GRE) 리디렉션 + 마스크 할당

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 전달 방법

L2 포워딩을 사용하면 서비스 그룹 내의 WCCP 엔티티(ACNS, WAFS, WAAS 등)가 동일한 서브넷의 일부이며 Catalyst 6500에 인접한 L2입니다.따라서 트래픽의 높은 처리량, 낮은 레이턴시 리디렉션이 가능합니다.WCCP가 구성된 인그레스 인터페이스 및 WCCP 어플라이언스가 있는 인터페이스는 다른 VLAN에 있어야 합니다.

참고:L2 리디렉션을 사용하면 소스 MAC가 라우터로 설정되고 대상 MAC이 캐시 엔진으로 설정된 상태로 패킷이 재작성됩니다.이 리디렉션 방법의 유일한 단점은 캐시 엔진이 Catalyst 6500에서 L2에 연결할 수 있어야 하며 구성된 인그레스 WCCP 인터페이스와 다른 L3 인터페이스에 상주해야 한다는 것입니다.

참고:WCCP 디바이스로 전달하는 방법은 트래픽을 Catalyst 6500으로 다시 보내기 위해 WCCP 디바이스에서 사용하는 방법과 다를 수 있습니다.WCCP는 두 디바이스 모두 지원하는 전달 및 반환 방법을 협상하기 위해 사용됩니다.WCCP 반환 방법을 참조하십시오.

이 시나리오에서 WCCP 리디렉션에 사용할 수 있는 옵션은 다음과 같습니다.

• 인그레스 - L2 리디렉션 + 해시 할당;소프트웨어 처리가 필요합니다.
• 인그레스(ingress) - L2 리디렉션 + 마스크 할당을 수행하려면 전체 하드웨어 처리가 필요하며 권장 사항입니다.
• 이그레스 - L2 리디렉션 + 해시 할당;소프트웨어 처리가 필요합니다.
• 이그레스 - L2 리디렉션 + 마스크 할당;소프트웨어 처리가 필요합니다.

인그레스 - L2 + 해시 할당

L2 + 해시 할당을 사용하여 인그레스(ingress)에 구성된 경우 WCCP 트래픽은 모든 플로우의 첫 번째 패킷을 소프트웨어 스위치로 전송하여 하드웨어 NetFlow 테이블에 NetFlow 항목을 생성합니다.

참고:NetFlow 흐름 마스크는 인터페이스 전체 흐름 모드로 설정되어 스위치에 구성된 다른 NetFlow 기능에 영향을 줄 수 있습니다.

WCCP는 상태 비저장 메커니즘이므로 소프트웨어에서 정보가 유지되지 않습니다.하드웨어에서 NetFlow 테이블의 항목으로 유지 관리됩니다.NetFlow 테이블 항목이 존재하는 한 흐름의 후속 트래픽은 하드웨어에서 전달됩니다.

NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU가 얼마나 활용되는지 결정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.

수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.

인그레스 - L2 + 마스크 할당

인그레스(ingress)에 구성된 경우 L2 + 마스크 할당이 Catalyst 6500에서 지원되는 가장 효율적인 WCCP 방법입니다.모든 트래픽은 각 플로우의 초기 패킷을 포함하여 하드웨어 스위칭됩니다.소프트웨어 리디렉션이 필요하지 않습니다.초기 및 후속 패킷 전달은 하드웨어에서 제공합니다.

Catalyst 6500의 하드웨어 ACL TCAM 리소스는 WCCP 패킷이 수신되기 전에 하드웨어 항목을 사전 프로그래밍하기 위해 사용됩니다.

이 방법을 사용하고 전체 하드웨어 스위칭을 활용하려면 WCCP 엔티티는 L2 리디렉션과 마스크 기반 할당 방법도 지원해야 합니다.이 방법의 컨피그레이션은 WCCP 엔티티에서 완료되며, Catalyst 6500은 WCCP 엔티티/그룹과의 초기 통신 중에 최상의 방법을 협상합니다.

이그레스 - L2 + 해시 할당

이그레스 L2 + 해시 할당을 통해 WCCP 트래픽은 모든 플로우의 첫 번째 패킷을 소프트웨어 스위치로 전송하여 하드웨어 NetFlow 테이블에 NetFlow 항목을 생성합니다.

참고: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 + 마스크 할당은 L2 + 해시 할당 사례와 같이 소프트웨어의 각 플로우에서 첫 번째 패킷을 전환합니다.후속 패킷은 하드웨어에서 NetFlow 스위칭됩니다.

참고:NetFlow 흐름 마스크는 인터페이스 전체 흐름 모드로 설정되어 스위치에 구성된 다른 NetFlow 기능에 영향을 줄 수 있습니다.

PFC2 및 PFC3는 이그레스 ACL 인접성 프로그래밍을 지원하지 않으므로 각 흐름에서 초기 패킷에 대한 소프트웨어 프로세싱을 강제로 수행합니다.플로우의 후속 패킷은 하드웨어에서 전달됩니다.

NetFlow 항목을 설정하면 CPU 사용률에 영향을 주지만, 후속 패킷 전달은 하드웨어에서 수행됩니다.트래픽 패턴, 특히 고유한 흐름의 수는 CPU가 얼마나 활용되는지 결정합니다.Catalyst 6500의 NetFlow 리소스를 사용하는 경우 모든 트래픽이 소프트웨어로 전달됩니다.

수퍼바이저 PFC의 NetFlow 리소스는 다양한 플랫폼에 따라 다릅니다.현재 가장 큰 NetFlow 리소스는 Supervisor Engine 720 플랫폼의 PFC-3BXL에서 사용할 수 있습니다.

WCCP 반환 방법

WCCP 엔터티가 요청을 서비스할 수 있음

WCCP를 사용하여 트래픽을 가로채고 WCCP 엔티티가 해당 패킷에 대해 전체 작업을 수행하면 패킷이 WCCP 디바이스에서 클라이언트로 다시 전송될 준비가 됩니다.일반적으로 처리된 이 트래픽은 네트워크의 클라이언트로 다시 전송되며, WCCP 디바이스에서 클라이언트로 다시 전송될 때 특별한 캡슐화가 필요하지 않습니다.

WCCP 가로채기로 인해 클라이언트 요청이 성공적으로 처리되었기 때문에(캐시에서 파일, 캐시에서 스트림 분할, WAAS에서 파일) 패킷의 대상 주소가 원래 요청자가 되는 패킷의 일반 트래픽으로 다시 네트워크로 전송될 수 있습니다.이 트래픽은 WCCP 어플라이언스에서 클라이언트로 네트워크 경로에 있는 경우 Catalyst 6500에서 일반적으로 L3/스위칭할 수 있습니다.L2 연결 WCCP 어플라이언스를 사용하면 트래픽이 네트워크 경로에 있습니다.대상이 이제 인터넷 또는 인트라넷의 서버가 아닌 원래 클라이언트로 변경되었으므로 WCCP 디바이스에서 Catalyst 6500으로 다시 전송하기 위해 캡슐화가 필요하지 않습니다.그런 다음 네트워크는 다른 IP 트래픽 흐름과 마찬가지로 이를 처리하고 Catalyst 6500의 하드웨어 포워딩을 사용하여 요청된 트래픽을 클라이언트로 반환합니다.

WCCP 엔터티가 요청을 서비스할 수 없음

WCCP 엔티티가 요청된 작업을 수행할 수 없는 경우 WCCP 어플라이언스는 트래픽을 Catalyst 6500으로 다시 전송하고 패킷의 원래 목적지를 유지해야 할 수 있습니다.캡슐화 없이 WCCP 엔티티에서 이 트래픽을 전달하면 트래픽 루프가 발생할 수 있습니다.클라이언트에서 실패한 서비스 시도를 숨기고 원래 목적지로 패킷을 전송하여 서비스하려면 패킷은 변경되지 않고 원래 포워딩 경로에 다시 배치되고 원래 목적지로 WCCP 가로채기 없이 전달되어야 합니다.

WCCP 반환 방법에서 WCCP를 사용하여 이러한 패킷을 캡슐화하고, 처음부터 가로챈 디바이스로 다시 전송하고, 캡슐화를 해제한 다음, 가로챈 전달 경로에 다시 배치할 수 있습니다.이러한 패킷은 WCCP에서 가로채지 않은 것처럼 정상적으로 전송해야 합니다.

이러한 사례의 예는 다음과 같습니다.

• 트래픽이 우회되는 오버로드된 트래픽 캐시
• WCCP 엔터티가 트래픽을 서비스하지 못하도록 거부하는 캐시 디바이스의 규칙
• 디바이스에서 사용할 수 없는 서비스를 찾는 우회된 트래픽

현재 이 반환 방법은 GRE 캡슐화를 통해서만 수행할 수 있으며 Catalyst 6500 하드웨어에서 아직 지원되지 않습니다.이 방법으로 많은 양의 트래픽을 Catalyst 6500으로 다시 보내는 경우 이 트래픽이 소프트웨어에서 처리되기 때문에 높은 CPU 사용률이 발생할 수 있습니다.Cisco IOS Software 릴리스 12.1(18)SXH에는 Catalyst 6500 하드웨어에서 지원하는 L2 반환 방법이 있습니다.

GRE 반환

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 서비스 그룹의 적절한 확장 또는 오버빌드가 이러한 상황을 방지하는 유일한 방법입니다.

L2 반품 개선 사항

12.2(18)SXH에서 옵션을 사용하면 WCCP 엔티티가 반환 트래픽을 캡슐화하지 않고 L2 MAC 주소를 다시 쓸 수 있습니다.이 L2 반환 개선 사항(Cisco 버그 ID CSCuk59825)은 WCCP가 마스크 할당과 인그레스 리디렉션을 사용하도록 구성된 경우 반환된 트래픽의 하드웨어 처리를 활성화합니다.

WCCP 옵션 요약

Catalyst 6500에서 구현된 경우, WCCP는 이 표에 나와 있는 것처럼 다양한 구성 옵션을 제공합니다.WCCP 어플라이언스는 이러한 옵션을 협상하고 Catalyst 6500에서 사용하는 옵션을 제어합니다.컨피그레이션은 WCCP 연결의 WCCP 어플라이언스 쪽에서 수행됩니다.

하드웨어의 관점에서 모든 이그레스 WCCP 컨피그레이션에는 소프트웨어 처리가 필요하며 CPU 사용률에 영향을 미칩니다.또한 해시 기반 할당 방법을 사용하여 CPU 사용률에 동일한 영향을 미칠 수 있는 경우 인그레스(ingress)에도 소프트웨어 처리가 필요합니다.

Catalyst 6500에서 WCCP 구축의 권장 방법은 마스크 할당을 사용하는 L2 리디렉션(사용 가능한 경우 L2 반환)입니다.

팁:하나의 옵션만 고성능 전체 하드웨어 기반 포워딩을 보장합니다.Supervisor Engine 2, Supervisor Engine 32 및 Supervisor Engine 720에서 마스크 할당을 사용하는 인그레스 기반 L2 리디렉션

WCCP 설계 권장 사항

상황에 맞는 최적의 WCCP 구축 방법을 결정할 수 있도록 이러한 컨피그레이션 권장 사항을 사용하십시오.

요약

WCCP 인그레스(ingress)를 리디렉션 방법으로 사용할 수 있도록 네트워크를 설계합니다.효율적인 설계 방법은 계층적 L3 배포 네트워크의 일부로 캐싱 스위치 블록을 갖는 것입니다.이를 통해 몇 개의 주요 인그레스 포트에서 WCCP 서비스 트래픽을 식별할 수 있습니다.

• 12.2(18)SXF7 이상 버전의 Cisco IOS 소프트웨어를 사용합니다.
• 인그레스 인터페이스에서 트래픽을 식별하고 리디렉션합니다.
• L2 리디렉션 방법을 지원하는 WCCP 어플라이언스를 사용합니다.
• 마스크 기반 할당 방법을 지원하는 WCCP 어플라이언스를 사용합니다.
• 가능한 경우 WCCP 어플라이언스에서 서비스할 수 없는 트래픽에 대해 Catalyst 6500의 리디렉션 목록을 사용합니다.
• Supervisor Engine 720을 사용하여 이그레스 또는 모든 해시 기반 할당 컨피그레이션과 NetFlow 타이머를 조정합니다.
• WCCP 어플라이언스에는 전용 L3 환경과 SVI/VLAN 인터페이스가 있어야 합니다.

또한 Cisco Advanced Service는 다음과 같은 설계 고려 사항을 권장합니다.

• 마스크 할당이 포함된 L2 리디렉션이 완전하지 않은 환경에서는 Supervisor Engine 720이 Supervisor Engine 2 플랫폼보다 성능이 좋지 않습니다.하드웨어를 업그레이드하지 말고 이 상황에서 더 나은 성능을 기대하십시오.
• 대규모 중앙 사이트 구축의 경우, 트래픽 가로채기와 포워딩을 위해 PBR(Policy-based Routing) 및 CSM(Cisco Content Switching Model)/ACE(Application Control Engine)가 포함된 설계를 고려하십시오.
• WCCPv2는 완벽한 환경에서 예상대로 작동합니다.그러나 어떤 상황에서는 라우터의 CPU 사용률이 높은 수준에 도달하여 디바이스를 사용할 수 없게 하고 다시 로드해야 하는 상황이 발생할 수 있습니다.
  
  
  • WCCPv2는 인그레스 하드웨어 가속 L2 마스크 기반 할당 모드에서 MSFC의 CPU가 필요한 다른 모드로 돌아갑니다.
  • WCCP가 잘못 구성되었습니다(예: 마스크 할당 대신 인그레스 또는 L2 해시 대신 이그레스).
• Catalyst 6500을 사용하는 모든 대용량 WCCP 구축(캐싱, 스트리밍, WAAS 또는 기타 '높은 트래픽 속도' 시나리오)은 전체 프로덕션 배포 전에 라이브 트래픽으로 성능을 테스트해야 합니다.

추가 권장 사항

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)의 구성은 다음과 같습니다.

• wccp 버전 2
• wccp 라우터 목록 IP 주소
• wccp 서비스 router-list-num 숫자 마스크 할당

NetFlow 사용률을 검토하고 WCCP에서 NetFlow 항목을 모두 사용하고 있으며 소프트웨어 처리를 사용하고 있는지 확인하려면 다음 명령을 사용합니다.

• show mls netflow table contention 세부 정보
• show mls netflow ip sw 설치됨
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• mls ip 표시
• show fm netflow 카운터

NetFlow 리소스가 사용되고 있어 WCCP 소프트웨어 문제가 발생하는 경우 이러한 명령은 기존 항목을 적극적으로 지우고 새 항목을 위한 공간을 생성할 수 있습니다.(NetFlow 공간보다 더 많은 항목이 있는 경우에는 도움이 되지 않습니다.)

• mls 에이징 빠른 시간 3 임계값 1
• 긴 MLS 64
• mls 정상 노화 32
• mls ip netflow 생성 소프트웨어 모드 고속(Supervisor Engine 2에 없는 일부 Supervisor Engine 720 NetFlow 변경 사항이 비활성화됨)

패킷 삭제를 방지하려면 WCCP 엔티티는 WCCP가 구성된 인터페이스가 아닌 인터페이스에서 트래픽을 리디렉션해야 합니다.모든 조건이 충족되면 Catalyst 6500 WCCP는 이 상황에서 패킷을 삭제합니다.

• 클라이언트와 WCCP 엔티티는 모두 동일한 L3 인터페이스에 있습니다.
• WCCP 리디렉션 정책이 이 인터페이스에 적용됩니다.
• GRE 리디렉션 방법이 사용됩니다.
• 패킷 조각화를 리디렉션해야 합니다.
• Supervisor Engine 720이 사용됩니다.

이러한 상황은 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은 이 명령을 사용하지 않고 이를 협상합니다.

솔루션

참고:이 섹션에 사용된 명령에 대한 자세한 내용을 보려면 Command Lookup Tool(등록된 고객만 해당)을 사용합니다.

ACNS

표준 투명 캐싱 리디렉션의 경우 WCCP 엔티티가 WCCP 라우터에 지원되는 방법을 제공하며 이를 위해 구성해야 할 수도 있습니다.Cisco ACNS의 경우 이 컨피그레이션에서는 최적화된 L2 리디렉션 및 마스크 기반 할당 방법을 요청합니다.

1. Catalyst 6500 최적화를 위한 WCCPv2가 있는지 확인합니다.
   
   

   ContentEngine(config)# wccp version 2

2. 사용할 Catalyst 6500을 정의하는 라우터 목록을 구성합니다.
   
   

   ContentEngine(config)# wccp router-list 1 172.16.16.1

3. 최적화 방법을 사용하도록 서비스를 구성합니다.
   
   

   ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign

라우터 측에서 Catalyst 6500 설계는 WCCP 디바이스가 현재 트래픽 경로(인그레스 또는 이그레스)에 없는 전용 L3 인터페이스에 있는지 확인해야 합니다. 하드웨어 성능의 경우 단일 이그레스 인터페이스를 선택한 경우보다 더 많은 인터페이스를 구성해야 하는 경우에도 Catalyst 6500에 대한 인바운드 트래픽을 캡처해야 합니다.이상적인 설계에서는 이 디바이스에 도달하기 전에 모든 트래픽을 집계하며, 몇 개의 인터페이스만 WCCP 인그레스 컨피그레이션을 필요로 합니다.

Catalyst 6500의 WCCP 구성은 다음과 같아야 합니다.

1. WCCPv2 구성:
   
   

   6500Switch# ip wccp version {1 | 2}

2. WCCP 서비스 그룹을 구성합니다.
   
   

   6500Switch (config)# ip wccp service [accelerated] redirect-list access-list

   12.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 version 2
wccp router-list 1 router-ip-addresses
wccp service router-list-num 1 l2-redirect mask assign

ip wccp version 2
ip wccp service redirect-list 120
access-list 120 deny tcp ...
access-list 120 deny udp ...
access-list 120 permit ip any any

ip wccp redirect service in

이 컨피그레이션을 확인하려면 다음 명령을 입력합니다.

Show ip wccp service detail

멀티캐스트 또는 추가 WCCP 보안을 사용하여 그룹 주소 지정 등의 추가 WCCP 구성 옵션은 WCCP를 사용하여 Web Cache Services 구성을 참조하십시오.

WCCP IOS Show and Debug 명령

• show ip wccp service-number - 'Total Packets Redirected' 카운트를 제공합니다.이 수는 리디렉션되는 플로우 또는 세션 수입니다.
• show ip wccp service-number detail - 'Packets Redirected' 카운트를 제공합니다.개수는 리디렉션되는 플로우 또는 세션 수입니다.
• show ip wccp web-cache detail - 패킷이 아닌 플로우 수가 L2 리디렉션을 사용하고 있음을 나타냅니다.
• clear ip wccp - 'Packets Redirected' 정보에 대한 카운터를 재설정합니다.
• show ip wccp service-number view - 서비스 그룹에 속한 WCCP 디바이스를 표시합니다.
• show ip wccp service-number service - 서비스의 해시, 포트 및 WCCP 우선순위를 표시합니다.인터페이스에 여러 서비스가 구성된 경우 우선 순위가 높은 서비스가 먼저 적용됩니다.
• debug ip wccp events - WCCP 프로토콜의 상태를 트러블슈팅합니다.
• debug ip wccp packets - WCCP 패킷 처리 엔터티 간의 통신을 검토합니다.

WCCP 및 하드웨어 포워딩을 사용하는 경우 일부 카운터가 예상대로 표시되지 않을 수 있습니다.

• WCCP ACL이 하드웨어에서 완전히 처리되면 WCCP 카운터에 정확한 패킷 수가 표시되지 않을 수 있습니다.
• WCCP에서 해시 기반 할당 및 NetFlow 하드웨어 리소스를 사용하는 경우 WCCP 카운터에 패킷 수 대신 흐름 수가 반영될 수 있습니다.

NetFlow 명령

NetFlow 하드웨어 리소스를 사용해야 하는 WCCP 컨피그레이션이 있는 경우 다음 MLS(Multilayer Switching) 및 FM(Fabric Manager) 명령을 사용하여 NetFlow 리소스의 상태를 검토할 수 있습니다.

• show mls netflow table contention 세부 정보
• show mls netflow ip sw 설치됨
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• mls ip 표시
• show fm netflow 카운터

WCCP 결함

이 Cisco 버그 ID 및 해결 방법 표는 WCCP를 가장 잘 지원하기 위해 Cisco IOS Software 릴리스 12.2(18)SXF7 이상을 사용하는 일반적인 권장 사항을 지원합니다.