목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

표기 규칙

배경 정보

IPC 용어 기본 사항

IPC 주소 형식

IPC를 통해 어떤 정보를 전송해야 합니까?

IPC 메시지 전송 방법

Cisco 7500 시리즈

Cisco 12000 시리즈

문제, 알려진 버그 및 개선 사항을 해결하는 단계

1단계:IPC 캐시 조정

2단계:IPC 처리량 조정

IPC 개선 사항 목록

Cisco 7600 시리즈

Cisco TAC에 대한 문제 해결 정보 수집

관련 정보

소개

이 문서에서는 라우터가 IPC 관련 로그 메시지를 보고하는 이유와 이 문제를 해결하는 방법에 대해 설명합니다.이 문서에는 IPC 용어 검토도 포함되어 있습니다.

사전 요구 사항

요구 사항

이 문서의 독자는 다음 주제에 대해 알고 있어야 합니다.

- Cisco 라우터 관리

- IPC 및 용어

사용되는 구성 요소

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

- Cisco 12000, 1000, 7600 및 7500 Series 라우터를 지원하는 모든 Cisco IOS® 소프트웨어 릴리스.

- Cisco 12000, 1000, 7600 및 7500 Series 라우터

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

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 규칙을 참조하십시오.

배경 정보

Cisco IOS IPC(Software Inter-Process Communication) 모듈은 분산 시스템의 프로세스가 상호 작용할 수 있는 통신 인프라를 제공합니다.또한 백플레인, 네트워크 및 공유 메모리 간에 투명한 통신을 제공합니다.

IPC 서비스는 RP에서 LC로 전송되는 IPC 메시지를 교환하고 액티브 RP와 스탠바이 RP 간에 LC(Line Card)와 RP(Central Route Processor)가 서로 통신하는 수단 역할을 합니다.이러한 메시지에는 컨피그레이션 명령과 해당 명령에 대한 응답 및 LC에서 RP에 보고해야 하는 "이벤트"가 포함됩니다.

Cisco 12000 Series, Cisco 1000 Series, Cisco 7600 Series 및 Cisco 7500 Series는 IPC 메시지를 기반으로 분산 아키텍처를 사용합니다.드문 경우지만 이러한 라우터는 다음과 같은 IPC 관련 로그 메시지를 보고할 수 있습니다.

- Cisco 12000 Series - %IPC-3-NOBUFF:주 IPC 메시지 헤더 캐시가 비웠습니다.

- Cisco 7500 Series - %IPC_RSP_CBUS-3-NOBUF:IPC 메시지를 전송할 IPC 메모리 버퍼가 더 이상 없음

참고: IPC는 Cisco 6400 Series 및 Cisco 7304 Series에서도 사용됩니다.

IPC 용어 기본 사항

더 일반적인 IPC 용어:

- IPC - 프로세스 간 통신.

- IPC Address - 16비트 시트 ID와 16비트 포트 ID로 구성된 32비트 단어입니다.

- IPC 클라이언트 - IPC 서비스를 사용하는 소프트웨어 모듈입니다.

- IPC 포트 - 모든 통신의 소스 및 대상으로 사용되는 IPC 내의 통신 엔드포인트입니다.

- IPC Seat - IPC 시트는 IPC의 도움으로 통신할 수 있는 프로세서와 같은 컴퓨팅 요소입니다.IPC 시트는 IPC 클라이언트 및 포트가 상주하는 곳입니다.

- IPC 세션 - IPC 세션은 두 IPC 포트 간의 활성 단방향 통신 채널입니다.

IPC를 사용하는 모든 통신은 IPC 포트 간에 발생합니다.포트는 IPC의 통신 엔드포인트입니다.각 IPC 포트는 IPC 주소라는 논리적 주소와 연결됩니다.IPC는 IPC 메시지를 보낼 때 IPC 포트의 IPC 주소를 반환 주소로 사용하거나 IPC 메시지를 받을 때 대상 주소를 사용합니다.

IPC 주소 형식

IPC 주소는 로컬 IPC 사용자 관리자에 의해 IPC 포트에 할당됩니다.시트는 IPC 프로토콜이 현재 실행 중인 프로세서입니다.시트 관리자는 로컬 IPC 포트 및 로컬 이름 서비스 목록을 유지 관리하고 열린 IPC 통신 세션을 유지 관리하는 프로세스입니다.

IPC 포트가 생성되면 IPC 클라이언트는 IPC 포트에 포트 이름을 할당합니다.그러면 다른 IPC 클라이언트는 새로 생성된 IPC 포트를 참조할 때 포트 이름을 사용할 수 있습니다.포트 이름은 시트 이름과 포트 기능 또는 설명으로 구성된 문자 문자열입니다.

Cisco IPC는 포트에 대해 세 가지 수준의 신뢰성을 제공합니다.이는 포트가 열려 있을 때 정의됩니다.

- 신뢰성:메시지 전달이 보장됩니다.실패 시 배송이 다시 시도됩니다.

- 신뢰할 수 없음:배달은 최선의 시도입니다.배송이 실패했는지 아무런 표시도 없습니다.

- 알림에 신뢰할 수 없음:메시지 전달이 보장되지 않습니다.그러나 발신자는 실패에 대한 알림을 받습니다.

show ipc nodes 명령은 소위 IPC 영역에 있는 IPC 시트를 표시합니다.

Router#show ipc nodes

There are 3 nodes in this IPC realm.

ID Type       Name                         Last  Last

Sent  Heard

10000 Local      IPC Master                   0      0

1030000 RSP-CY     RSP IPC card slot 3          7      7

1000000 RSP-CY     RSP IPC card slot 0          10     10

슬레이브 RP가 있는 경우 show ipc nodes 명령은 Cisco 1000 Series Router의 다음 샘플 출력에 표시된 대로 슬레이브 RP 주소를 나열합니다.

10k-2#show ipc nodes

There are 5 nodes in this IPC realm.

ID   Type       Name                      Last  Last

Sent  Heard

10000   Local      IPC Master                0     0

20000   UDP        C10K Line Card slot 2/0   3     3

30000   UDP        C10K Line Card slot 3/0   3     3

40000   UDP        C10K Line Card slot 1/0   3     3

50000   Ethernet   Slave                     18    45

IPC 포트를 생성한 후 IPC 클라이언트는 IPC 마스터에서 제어하는 글로벌 이름 서비스에 포트 이름을 등록할 수 있습니다.

서로 통신하는 IPC 시트 모음을 영역이라고 합니다.각 IPC 영역에 대해 단일 IPC 시트를 IPC 영역 관리자 또는 마스터 또는 IPC 마스터로 간단하게 지정합니다.논리적으로, IPC 프로토콜의 모든 IPC 시트 연결은 포인트-투-포인트 연결입니다.모든 IPC 시트 통신은 일반적으로 활성 RP와 라인 카드 또는 대기 RP 간에 이루어집니다.라인 카드와 라인 카드 간 통신이 가능합니다.

디바이스는 IPC 메시지를 교환하기 전에 로컬 포트를 생성하고 목적지 포트를 찾아야 합니다.디바이스가 로컬 포트를 생성하지만 IPC 통신은 단순하므로 이러한 포트는 소스 포트로 간주되지 않습니다.RP가 LC와 통신하려는 경우 먼저 LC에서 포트를 엽니다(LC는 포트를 생성하여 IPC 마스터 - RP에 등록해야 함). 열기가 성공하면 일반 IPC 메시지 트래픽을 시작할 수 있습니다.

Cisco 12000 및 7500 Series에서 GRP(Gigabit Route Processor) 또는 RSP(Route Switch Processor)와 같은 경로 프로세서가 IPC 엔드포인트의 역할을 합니다."IPC 마스터"는 프로세서 그룹을 제어합니다.라우터가 초기화되면 IPC 마스터는 시스템의 라인 카드에 있는 IPC 엔드포인트를 검색합니다.이를 위해 IPC 마스터는 모든 슬롯을 스캔하고 컨트롤러 유형을 식별하며 컨트롤러에 IPC 기능이 있는지 확인합니다.

이러한 포트를 보려면 show ipc ports 명령을 사용합니다.IPC 슬레이브에서 이 명령은 특정 IPC 시트에 생성된 포트를 나열합니다.IPC 마스터에서 이 명령을 실행하면 마스터에서 생성된 포트와 IPC 슬레이브(LC)에서 등록한 포트가 표시됩니다. 또한 show ipc ports open 명령은 이 IPC 시트로부터 연 포트를 나열합니다.다음은 출력의 예입니다.

router#show ipc ports

There are 87 ports defined.

Port ID Type Name

10000.1 unicast IPC Master:Zone

10000.2 unicast IPC Master:Echo

10000.3 unicast IPC Master:Control

10000.4 unicast IPC Master:Init

port_index = 0 seat_id = 0x1020000 last sent = 0 last heard = 1

port_index = 1 seat_id = 0x1010000 last sent = 0 last heard = 1

port_index = 2 seat_id = 0x1040000 last sent = 0 last heard = 1

port_index = 3 seat_id = 0x1050000 last sent = 0 last heard = 1

port_index = 4 seat_id = 0x1060000 last sent = 0 last heard = 1

port_index = 5 seat_id = 0x1070000 last sent = 0 last heard = 1

port_index = 6 seat_id = 0x1080000 last sent = 0 last heard = 1

port_index = 7 seat_id = 0x1090000 last sent = 0 last heard = 1

port_index = 8 seat_id = 0x10A0000 last sent = 0 last heard = 1

port_index = 9 seat_id = 0x10B0000 last sent = 0 last heard = 1

port_index = 10 seat_id = 0x1030000 last sent = 0 last heard = 1

10000.5 unicast Remote TTY Server Port

port_index = 0 seat_id = 0x1070000 last sent = 0 last heard = 2

port_index = 1 seat_id = 0x1010000 last sent = 0 last heard = 2

port_index = 3 seat_id = 0x1040000 last sent = 0 last heard = 2

port_index = 4 seat_id = 0x1050000 last sent = 0 last heard = 2

Port ID Type Name

port_index = 5 seat_id = 0x1060000 last sent = 0 last heard = 3

port_index = 6 seat_id = 0x1080000 last sent = 0 last heard = 2

port_index = 7 seat_id = 0x1090000 last sent = 0 last heard = 2

port_index = 8 seat_id = 0x10A0000 last sent = 0 last heard = 2

port_index = 9 seat_id = 0x10B0000 last sent = 0 last heard = 2

[output omitted]

port_index 필드는 수신 메시지를 처리할 때 대상 IPC에서 사용하는 세션 ID입니다.슬레이브 RP가 있는 경우 show ipc ports 명령은 이 샘플 출력에 표시된 대로 대기 포트 정보를 표시합니다.

10k-2#show ipc ports

There are 16 ports defined.

Port ID       Type       Name

10000.1     Unicast    IPC Master:Zone

10000.2     Unicast    IPC Master:Echo

10000.3     Unicast    IPC Master:Control

10000.4     Unicast    Microcode Server

10000.5     Unicast    RFS Server Port

10000.6     Unicast    Remote File System Server Port

10000.7     Unicast    Master : TTY Server Port

port_index = 0  seat_id = 0x50000   last sent = 0     last heard = 0

10000.8     Unicast    C10K Line Card API

port_index = 0  seat_id = 0x20000   last sent = 0     last heard = 58521

port_index = 1  seat_id = 0x30000   last sent = 0     last heard = 64235

port_index = 2  seat_id = 0x40000   last sent = 0     last heard = 13486

50000.3     Unicast    Slave IPC:Control

50000.9     Unicast    Secondary RFS Server Port

50000.A     Unicast    Secondary Old RFS Server Port

50000.8     Unicast    Slave : TTY Client Port

50000.7     Unicast    Secondary Services Port

50000.B     Unicast    IF-con server port

50000.C     Unicast    RF : Standby

50000.D     Unicast    CF : Standby

IPC를 통해 어떤 정보를 전송해야 합니까?

IPC 메시지는 IPC 클라이언트 간에 교환되는 기본 통신 단위입니다.정상 작동 중에 RP와 라인 카드는 IPC 메시지를 통해 자주 상호 작용합니다.메시지에는 헤더, 소스 및 대상 주소 정보, 메시지 데이터가 포함됩니다.

IPC 헤더에서 IPC는 IPC 메시지의 수신 처리를 변경하는 여러 가지 다른 메시지 플래그를 정의합니다.정의된 플래그 중에서 4개의 플래그는 사용된 통신 유형(신뢰할 수 없음, 알림과 신뢰할 수 없음), 다른 4개는 RPC(Remote Procedure Call) 메시징 또는 내부 제어 처리와 관련되며 2개는 전혀 사용되지 않습니다.

다음은 몇 가지 IPC 클라이언트입니다.

- RP가 라인 카드에 버전, 메모리 양, 인터페이스 통계, 인터페이스 상태 변경, 컨피그레이션 데이터 등의 정보를 쿼리하기 위해 보낸 명령입니다.

- 라인 카드에서 RP로 전송되는 RP의 명령에 대한 응답IPC 메시지에 포함된 정보의 예로는 시간 통계 업데이트 및 라인 카드가 대기열에 추가할 수 있는 IPC 메시지 수를 나타내는 Windows 메시지가 있습니다.

- 비동기적으로 생성된 이벤트 또는 메시지입니다.예를 들어 입력 오류, 런타임, 거인과 같은 오류를 보고하고 통계 및 기타 회계 정보(예: 바이트 및 패킷 수)를 보고합니다.

- 활성 RP와 대기 RP 간의 메시지를 체크포인트 적절한 작동으로 전환합니다.

- 일부 Cisco IOS 소프트웨어 프로세스는 라인 카드와 경로 프로세서 간에 정보를 교환해야 합니다.이러한 프로세스는 IPC 애플리케이션으로 간주됩니다.예를 들면 Cisco 12000 Series Route Processor 간에 이미지를 교환하기 위한 Cisco CEF(Express Forwarding) 및 원격 파일 시스템이 있습니다.

표 1에는 IPC 프로토콜 스택의 레이어가 나열되어 있습니다.

표 1 - IPC 프로토콜 스택의 레이어

IPC 프로토콜 스택

IPC 애플리케이션

IPC 메커니즘 자체

Switch Fabric(12000 Series) 또는 CBUS(7500 Series) 데이터 레이어

IPC 메시지 전송 방법

7500 Series 및 12000 Series 라우터 모두 전송을 위해 대기되고 대상 IPC 포트에서 승인을 기다리는 IPC 메시지를 저장하기 위해 특수 버퍼 세트를 할당합니다.

Cisco 7500 시리즈

7500 Series는 MEMD(시스템 패킷 메모리)에서 특수 버퍼 집합을 사용합니다. MEMD 및 7500 아키텍처에 대한 자세한 내용은 "%RSP-3-RESTART의 원인:CBUS 복합?99%에서 실행되는 VIP CPU 및 Rx-Side 버퍼링 이해.

7500 Series에서 IPC 대기열은 프로세서 메모리에 있습니다.일부 버전의 Cisco IOS에서는 프로세서 메모리의 총 IPC 버퍼 공간을 ipc cache size 명령으로 조정할 수 있습니다(아래 샘플 출력 참조).MEMD에는 튜닝할 수 없는 일부 제한된 버퍼가 있습니다.프로세서 메모리에서 대기열에 추가된 IPC 메시지가 전송되고 MEMD에 여유 공간이 있으면 IPC 메시지가 LC로 전송되기 전에 프로세서 메모리에서 MEMD로 "이동"됩니다.

show ipc queue 명령을 사용하여 IPC 큐의 상태를 볼 수 있습니다.

Router#show ipc queue

There are 0 IPC messages waiting for acknowledgment in the transmit queue.

There are 0 IPC messages waiting for a response.

There are 0 IPC messages waiting for additional fragments.

There are 0 IPC messages currently on the IPC inbound.

There are 0 messages currently in use by the system.

참고: 이러한 대기열은 IPC에서 유지 관리하는 소프트웨어 대기열이며 7500 Series의 QA-ASIC 하드웨어 대기열과 혼동해서는 안 됩니다.

Cisco 12000 시리즈

12000 Series에서 GRP는 스위치 패브릭을 통해 IPC 메시지를 전송합니다.부팅 시 버퍼 조각 알고리즘은 소위 tofab(수신 측) 및 frfab(전송 측) 메모리에 두 개의 풀 집합을 생성합니다.show controller tofab queues 명령의 샘플 출력에 표시된 것처럼(아래 참조) 두 집합은 Non-IPC Free Queues 및 IPC Queues입니다.출력을 해석하는 방법에 대한 지침은 Cisco 12000 Series 인터넷 라우터:FAQ.

Cisco 12000 Series에서 GRP는 초기화 시 특정 수의 메시지 헤더를 할당합니다.이러한 헤더에 대한 메모리 할당을 개선하기 위해 몇 가지 수정을 했습니다.

Cisco IOS Software Release 12.0(18)S/ST는 초기화 시 생성된 기본 메시지 헤더 수를 GRP와 LC에서 1000에서 5000으로 늘렸습니다(다음 출력 참조). 릴리스 12.0(23)S 이상에서 IPC 헤더 캐시는 동적으로 증가할 수 있습니다.따라서 더 이상 수동으로 조정할 필요가 없습니다.

LC는 DRAM(Dynamic RAM)에서 IPC 메시지 헤더를 유지합니다. 또한 LC는 tofab에 100개의 버퍼를 할당하고 IPC 메시지에 대해 fromfab 메모리를 할당했습니다.전송된 각 IPC 메시지를 통해 LC는 캐시에서 IPC 메시지 헤더를 요청한 다음 패브릭을 통해 GRP로 메시지를 보내는 데 IPC 메시지 버퍼를 사용할 수 있도록 BMA(frfab Buffer Management ASIC)에 요청을 보내야 합니다.

LC-Slot1#show controllers tofab queues

Carve information for ToFab buffers

SDRAM size: 33554432 bytes, address: 30000000, carve base: 30029100

33386240 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s)

max buffer data size 9248 bytes, min buffer data size 80 bytes

40606/40606 buffers specified/carved

33249088/33249088 bytes sum buffer sizes specified/carved

Qnum        Head    Tail    #Qelem  LenThresh

----        ----    ----    ------  ---------

5 non-IPC free queues:

20254/20254 (buffers specified/carved), 49.87%, 80 byte data size

1          17297   17296    20254    65535

12152/12152 (buffers specified/carved), 29.92%, 608 byte data size

2          20548   20547    12152    65535

6076/6076 (buffers specified/carved), 14.96%, 1568 byte data size

3          32507   38582    6076     65535

1215/1215 (buffers specified/carved), 2.99%, 4544 byte data size

4          38583   39797    1215     65535

809/809 (buffers specified/carved), 1.99%, 9248 byte data size

5          39798   40606    809      65535

IPC Queue:

100/100 (buffers specified/carved), 0.24%, 4112 byte data size

30         72      71       100      65535

Raw Queue:

31         0       17302    0        65535

[output omitted]

문제, 알려진 버그 및 개선 사항을 해결하는 단계

1단계:IPC 캐시 조정

참고: 이 섹션에 향상된 기능이 나열된 IOS 버전 목록은 표 2를 참조하십시오.

드문 상황(예: IPC 클라이언트 간에 대량의 정보를 교환해야 하는 경우)에서 IPC 버퍼 캐시가 고갈될 수 있습니다.Cisco IOS 소프트웨어는 다음 로그 메시지를 사용하여 이 조건을 보고합니다.

Oct 7 03:36:49: %RSP-3-RESTART: interface Serial0/0/4:1, not transmitting

Oct 7 03:39:51: %IPC_RSP_CBUS-3-NOBUF: No more IPC memd buffers to transmit

IPC message

Oct 7 03:40:09: %RSP-3-RESTART: interface Serial0/0/2:1, not transmitting

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/0,

changed state to down

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/1,

changed state to down

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/2,

changed state to down

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on InterfaceSerial0/1/3,

changed state to down

Oct 7 03:40:21: %IPC_RSP_CBUS-3-NOBUF: No more IPC memd buffers to transmit

IPC message

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 0: IPC failure

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 1: IPC failure

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 4: IPC failure

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 5: IPC failure

Oct 7 03:40:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface

위의 출력에 나와 있는 것처럼 RP는 IPC의 도움을 받아 라인 카드의 CEF 테이블을 더 이상 업데이트할 수 없으므로 이 상태의 모든 라인 카드에서 CEF를 비활성화합니다.따라서 FIBDISABLE 메시지는 모든 라인 카드에 대해 보고됩니다.

이러한 오류를 해결하려면 RP의 IPC 캐시와 라인 카드의 IPC 메모리를 늘려야 할 수 있습니다.이 작업을 수행하기 전에 show ipc status 명령을 사용하여 RP 또는 LC 또는 둘 다 IPC 버퍼가 부족한지 여부를 조사합니다.이 출력을 RP와 LC에서 모두 검사합니다.

원래 IPC의 도움을 받아 모든 시스템에 할당된 기본 버퍼 수는 1,000개의 캐시된 메시지 헤더였으며, 이는 인바운드 및 아웃바운드 메시지 간에 공유되었습니다.설치된 Cisco IOS 소프트웨어 버전에 따라 IPC 캐시 메시지 헤더의 수가 정적, 동적 또는 튜닝될 수 있습니다.

다음은 기본 1000 메시지 헤더를 가진 라우터에서 show ipc status 명령의 출력입니다.

참고: Cisco IOS Software 릴리스 12.2T 및 12.2S는 이 명령의 출력을 변경합니다.

router#show ipc status

IPC System Status:

This processor is the IPC master server.

1000 IPC message headers in cache

4049362 messages in, 92615 out, 4048932 delivered to local port,

352 acknowledgments received, 386 sent,

0 NACKS received, 0 sent,

15326 messages dropped on input, 154 messages dropped on output

0 no local port, 110 destination unknown, 0 no transport

0 missing callback or queue, 34 duplicate ACKs, 0 retries,

0 message timeouts.

0 ipc_output failures, 0 mtu failures,

7707 msg alloc failed, 0 emer MSG alloc failed, 0 no origs for RPC replies

0 pak alloc failed, 0 memd alloc failed

0 no hwq, 0 failed opens, 0 hardware errors

할당해야 하는 메모리의 양은 플랫폼의 카드 유형(RP 또는 LC, RSP 또는 VIP) 및 IPC가 필요한 애플리케이션의 활동(예: 분산 CEF)에 따라 달라집니다.

Cisco IOS Software Release 12.0(23)S, 12.2(18)S 및 새로운 IOS Trans 12.3 및 12.3T에서 IPC 메시지 캐시는 IPC 캐시의 정적 할당 대신 동적으로 관리됩니다.과부하 IPC 트래픽으로 인해 IPC 메시지 캐시 감소율 문제에 대한 제안 솔루션은 메시지 캐시를 동적으로 확장하고 축소하는 것이었습니다.초기화 시 시스템은 플랫폼에 지정된 기본 메시지 수를 할당합니다.사용 가능한 메시지 수가 "최소" 버퍼에 미치지 못하면 중요 백그라운드 프로세스에 캐시를 증가하도록 알립니다.이를 통해 IPC는 클라이언트의 요구 사항을 충족하기 위해 계속해서 캐시를 확장할 수 있습니다.최근에 할당된 버퍼가 지정된 기간 동안 IPC에서 사용되지 않는 경우 이 프로세스가 축소되기 시작합니다.캐시가 기본 크기에 도달하면 캐시가 중지되어 축소됩니다.이러한 성능 향상은 CSCdv57496에 도입되었습니다. CSCdv57496을 구현하면 ipc cache <size> 명령이 자동으로 수행되므로 더 이상 작동하지 않습니다.이는 모든 IPC 플랫폼에서 유효합니다.

중요 참고 사항:Cisco IOS Software Release 12.3(5.5)T에서 IPC 캐시를 수동으로 튜닝하는 기능이 제거되었습니다.자세한 내용은 CSCec17505(등록된 고객만 해당)를 참조하십시오.

show ipc queue 명령의 출력을 확인할 때 다음 내용을 확인해야 합니다.

c7500#show ipc queue

Message waiting for acknowledgement in  Tx queue :       0

Maximum acknowledgement msg usage in Tx queue :          0

Message waiting for additional Fragments      :          0

Maximum message fragment usage                :          0

There are 0 IPC messages waiting for a response.

There are 0 IPC messages currently on the IPC inboundQ.

Messages currently in use                     :          0

Message cache size                            :       1000

Maximum message cache usage                   :       1344

0 times message cache crossed 5000 [max]

Emergency messages currently in use           :          0

Inbound message queue depth 0

Zone inbound message queue depth 0

라우터가 동적으로 관리되는 IPC 캐시 버퍼를 포함하지 않는 Cisco IOS 소프트웨어 버전을 실행하는 경우, 즉 12.0(23)S, 12.2(18)S, 12.3 및 12.3T 이전의 이미지는 RP의 IPC 캐시와 라인 카드의 IPC 메모리를 수동으로 늘릴 수 있습니다.이 작업을 수행하기 전에 show ipc status 명령을 사용하여 RP, LC 또는 둘 다 IPC 버퍼가 부족한지 여부를 조사합니다.이 출력을 RP와 LC에서 모두 검사합니다.

필요한 경우 다음 명령을 사용하여 메모리를 조정할 수 있습니다.

- RP에서 IPC 헤더 캐시를 늘리기 위한 ipc cache 5000 configuration 명령

- ipc 캐시 <size> [슬롯 {slot_num | all}] 명령을 실행하여 Cisco 12000 LC의 캐시를 늘립니다.

참고: IPC 메시지에 더 많은 메모리를 할당하면 다른 프로세스에 사용할 수 있는 메모리가 줄어듭니다.단일 IPC 메시지의 크기는 실제로 다른 Cisco IOS 소프트웨어 브랜치에 따라 다릅니다.show memory summary 명령을 사용하여 프로세서 풀에 여유 메모리가 충분한지 확인합니다.

2단계:IPC 처리량 조정

참고: 이 섹션에 향상된 기능이 나열된 IOS 버전 목록은 표 2를 참조하십시오.

경우에 따라 RP와 LC 간의 IPC 처리량을 조정할 수도 있습니다.이는 RP가 큰 CEF 테이블을 LC에 업로드해야 하는 경우에 특히 유용합니다.예를 들어, 라우터가 부팅하는 동안 BGP 피어로부터 많은 양의 라우팅 정보를 수신하는 경우 이러한 문제가 발생할 수 있습니다.IPC 대역폭을 늘리기 위해 ip cef linecard ipc memory xxxxx 명령을 사용하여 LC에서 추가 IPC 버퍼링을 구성할 수 있습니다.이 명령은 CSCds89515에서 도입되었습니다(등록된 고객만 해당). 이 메모리의 값은 CSCdu54205(등록된 고객만 해당) 및 CSCuk27162(등록된 고객만 해당)에서 허용되는 기본값으로 설정되었습니다.

이 매개변수를 변경할 때 결과를 나타내는 명령은 다음과 같습니다.

Router#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)#ip cef line ipc mem 20000

Router(config)#^Z

Router#show cef state

...

RP state:

Expanded LC ipc memory:             20000 Kbytes

...

or, alternatively:

Router#show cef line

Slot      MsgSent    XDRSent  Window   LowQ   MedQ  HighQ Flags

0           12515      21687     505      0      0      0 up

1           12515      21675     505      0      0      0 up

3           12515      21701     505      0      0      0 up

5           12515      21700     505      0      0      0 up

2           12518      22008     505      0      0      0 up

Router#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)#ip cef line ipc mem 20000

Router(config)#^Z

Router#show cef line

Slot      MsgSent    XDRSent  Window   LowQ   MedQ  HighQ Flags

0           12538      22097    4966      0      0      0 up

1           12538      22081    4966      0      0      0 up

3           12538      22115    4966      0      0      0 up

5           12538      22114    4966      0      0      0 up

2           12541      22418    4966      0      0      0 up

IPC 개선 사항 목록

표 2는 여러 플랫폼에서 IPC 메모리를 수동적이고 동적으로 조정하기 위해 Cisco IOS 소프트웨어에서 구현된 개선 사항을 개괄적으로 설명합니다.

표 2 - Cisco IOS 소프트웨어의 향상된 기능

Cisco 버그 ID

고정 수신

개선 사항

CSCdk75315(등록된 고객만 해당)

12.0(5)S 12.0(5) 12.0(5)T 11.3(10)AA

ipc cache <size> 명령의 도움을 받아 구성할 수 있는 IPC 캐시 크기를 지정합니다.

CSCds89515(등록된 고객만 해당)

12.2(4)B 12.1(9)E 12.1(8a)E 12.2(3)T 12.2(2)S 12.1(9) 12.0(14)ST1 12.2(2) 12.2(1)S3 12.0(15)S32.0(16)ST2.10 6)S

Cisco 12000 Series Internet Router에서 대규모 라우팅 업데이트(예: 부팅 중)의 메모리 부족 상태로 인해 분산형 Cisco Express Forwarding(dCEF)을 비활성화할 수 있습니다. 이를 해결하려면 BGP(Border Gateway Protocol)의 최대 경로를 줄여 CEF가 라인 카드에 전달하는 정보의 양을 줄입니다.또는 수신 BGP 업데이트의 속도를 줄이기 위해 TCP 윈도우 크기를 줄입니다.자세한 내용은 최적의 라우팅 달성 및 BGP 메모리 소비 감소를 참조하십시오.또는 ip cef linecard ipc memory 0-128000 interface configuration 명령을 입력할 수도 있습니다.라인 카드 프로세서 또는 주 메모리의 양은 전체 메모리의 50%로 제한됩니다.이 명령을 사용하면 CEF 라우팅을 통해 메시지를 업데이트할 수 있도록 대기열에 더 많은 양의 라인 카드 프로세서 메모리를 할당할 수 있습니다.RP는 CEF 업데이트를 더 빨리 릴리스하여 메모리를 확보할 수 있으며, RP에서 메모리 부족 상태가 발생하는 것을 방지합니다.VIP(Versatile Interface Processor) 수를 기준으로 dCEF는 VIP에 바인딩된 IPC 메시지를 버퍼링하기 위해 RSP에 많은 양의 임시 메모리가 필요합니다. 특히 대규모 BGP 피어가 발생하거나 FIB(Forwarding Information Base)가 CBUS 복합 또는 VIP 충돌 후(또는 clear line 명령이 실행된 경우) VIP에 전달되는 IPC가 필요합니다.

CSCdu21591(등록된 고객만 해당)

12.0(17)ST4 12.0(18)ST 12.0(18)S

12000 Series 라우터에서 기본 IPC 메시지 헤더 캐시 크기를 1000에서 5000으로 늘립니다.이전에는 파서가 하드 코딩된 값 1000과 15000 사이의 임의의 숫자를 수락했습니다. 오늘날 파서는 플랫폼 정의 최소값과 최대 캐시 크기 사이의 숫자만 허용합니다.또한 원래 사용자 지정 IPC 캐시 값을 제거하기 위해 컨피그레이션에서 no ipc cache 명령을 실행해도 컨피그레이션에서 ipc cache 명령을 지울 수 없었습니다.대신 ipc cache x 명령을 삽입했습니다. 여기서 x는 현재 정의된 기본 캐시 크기입니다.현재 no ipc cache 명령은 예상 동작을 갖습니다.컨피그레이션에서 ipc cache 명령을 완전히 제거합니다.

CSCdu12540

12.0(19)ST 12.0(19)S

Cisco 12000 Series에만 적용:원래 ipc cache <size> 명령은 RP IPC 캐시에 대해서만 작동합니다.이제 LC에서 ipc cache 명령을 다음과 같이 사용할 수 있습니다.

ipc cache <size> [slot {slot_num | all}]

slot_num 및 all 옵션은 함께 사용할 수 없습니다.예를 들어 다음 명령은 유효합니다.ipc cache 4000 slot all ipc cache 3000 slot 5 이 명령은 슬롯 5의 캐시 크기를 3000으로 늘리고 다른 모든 슬롯의 캐시 크기를 4000으로 늘립니다.all 옵션을 사용하여 LC에 대한 이전 캐시 크기 구성 문을 덮어쓰려면 "NOPREFIX"를 사용하여 비휘발성 RAM(NVRAM)의 이전 명령을 삭제하고 올바른 결과를 구현해야 합니다.접두사 모드에서 no ipc 캐시 슬롯 {slot_num을 사용합니다. | all} 명령을 실행하여 캐시 크기를 기본값으로 재설정합니다.

CSCdu54205

12.0(19)ST 12.0(19)S

Cisco 12000 Series에만 적용:이러한 개선 사항으로 라인 카드 CEF 업데이트 메모리 할당의 기본값이 512개의 메시지로 변경되었습니다.문제가 관찰되지 않는 한 ip cef linecard ipc memory xxxxx 명령을 더 이상 사용할 필요가 없습니다.

CSCuk27162(등록된 고객만 해당)

12.2(9)T 12.2(9)S 12.2(9) 12.0(21)ST 12.0(22)S

이 소프트웨어 개선으로 부팅 시 할당된 라인 카드 ipc 버퍼의 플랫폼당 기본 수가 변경됩니다.또한 플랫폼당 RSP 기본 라인 카드 IPC 메모리를 25개에서 128개의 IPC 메시지로 늘립니다.해결 방법:ip cef linecard ipc memory xxxxx 전역 컨피그레이션 명령을 사용하여 라인 카드의 버퍼 수를 늘립니다.

CSCdv57496

12.0(23)S

IPC 캐시의 정적 할당 대신 IPC 메시지 캐시를 동적으로 관리합니다.CSCdv57496을 구현하면 ipc cache <size> 명령이 자동으로 수행되므로 더 이상 유효하지 않습니다.이는 모든 IPC 플랫폼에서 유효합니다.

CSCdz77490

12.2(19.7)S 12.0(26.2)S 12.3(1)B 12.3(1)

CSCdz77490을 구현하면 ipc cache <size> 명령줄 인터페이스가 Cisco IOS 소프트웨어 트레인 12.3 및 12.3T에서 제거됩니다.Cisco IOS 12.3 열차에서는 이 명령이 숨겨지지만, 터미널에서 구성한 경우 사용자에게 메시지가 인쇄됩니다.다음 주 릴리스 12.4에서는 이 명령이 제거됩니다.

CSCec17505(등록된 고객만 해당)

미정

증상:ipc cache <size> CLI 명령을 사용하여 캐시 크기를 변경할 경우 ipc 캐시 크기가 변경되지 않습니다.조건:이 조건은 IPC를 사용한 아키텍처 변경의 결과로 발생합니다.해결 방법:이제 IPC 캐시 기능이 자동으로 수행되며 CLI에서 사용자가 변경할 수 없습니다.이 개선 사항은 사용자가 IPC 캐시를 수동으로 변경할 수 없게 하는 Cisco IOS 소프트웨어 버전에서 ipc cache <size>CLI 명령을 제거합니다.사용자가 ipc cache <size> CLI 명령을 사용하여 IPC 캐시를 수동으로 변경할 수 있는 버전에는 CLI가 계속 있으므로 이전 버전과의 호환성 문제는 없어야 합니다.

Cisco 7600 시리즈

Catalyst 6000/Cisco 7600 Series는 Catalyst OS를 실행할 때 MSFC(Multilayer Switch Feature Card)라고 하는 선택적 라우터 카드가 있는 Supervisor Engine을 사용합니다. 수퍼바이저의 CPU와 MSFC의 CPU는 이더넷 대역외 관리 버스를 통해 IPC 메시지를 통해 통신합니다.Cisco IOS System Software를 실행할 때 RP와 SP(스위치 프로세서)도 IPC 메시지를 통해 통신합니다.원래 IPC 메시지에 대해 3,000개의 버퍼가 생성되었습니다.드문 경우이지만, 시스템은 IPC 버퍼가 부족하며 다음 오류 메시지를 보고합니다.

01:52:13: %ICC-2-NOMEM: No memory available for unregistering card Card2

02:42:08: %IPC-3-NOBUFF: The main IPC message header cache has emptied

-Traceback= 4026779C 40268350 4025F930 40223D34 40221C40 40221EA4 401EAB10

참고: ICC는 InterCard Communications를 의미합니다.

Cisco IOS Software 릴리스 12.1(08a)E01 및 12.1(10)E에서 Cisco 7600 Series는 기본적으로 6000 IPC 메시지 버퍼를 생성합니다.또한 버전 12.1(08a)E 및 12.1(09)EC에서 변경한 내용은 많은 수의 VLAN(Virtual LAN) 관련 업데이트로 인해 발생하는 IPC 헤더 고갈을 방지하는 데 도움이 됩니다.각 ICC 메시지는 한 번에 하나의 VLAN이 아닌 VLAN 링크 상태 변경 그룹의 광고를 합니다.

Cisco 7600 Series용 최신 라인 카드는 고속 패킷 처리 속도를 위해 DFC(Distributed Feature Daughter Card)를 지원합니다.DFC 지원 라인 카드는 로컬 Cisco Express Forwarding 및 인접성 테이블을 유지하고 IPC 메시지를 사용하여 수퍼바이저와 통신합니다.

일부 IPC 메시지는 Catalyst 6000 스위칭 버스의 MTU(최대 전송 단위)보다 큽니다(예: 1500바이트보다 큰 메시지에서 SONET 인터페이스 통계를 보고하는 데 사용되는 IPC 메시지). 이러한 메시지는 프래그먼트화되어야 합니다.드문 경우지만 IPC 프래그먼트 헤더 캐시가 삭제되고 시스템은 다음 오류 메시지를 보고합니다.

%IPC-DFC6-3-NOBUFF: The fragment IPC message header cache has emptied

Cisco IOS Software 릴리스 12.1(08a)E 및 12.1(09.05)EC에서 변경된 내용은 IPC 프래그먼트 버퍼 헤더 수를 32개에서 128개로 늘립니다.

이 메시지는 IPC 클라이언트에서 중복 승인을 받은 경우 디버그 출력에 나타날 수 있습니다.

IPC:ACK HDR에 대한 원본 메시지를 찾을 수 없습니다.

중복 확인은 확인 메시지를 잃게 하는 미디어 문제 때문에 가장 일반적으로 발생합니다.이 승인 손실을 해결하려면 미디어 문제를 피하기 위해 슬롯에 라인 카드를 재장착하거나 교체하십시오.

Cisco TAC에 대한 문제 해결 정보 수집

위의 트러블슈팅 단계를 따르고 Cisco TAC에서 서비스 요청을 생성하려는 후에도 지원이 필요한 경우 IPC-3-NOBUFF 관련 오류 메시지 트러블슈팅을 위해 다음 정보를 포함해야 합니다.

- 케이스를 열기 전에 수행된 트러블슈팅.

- show technical-support 출력(가능한 경우 enable 모드)

- 로그 출력 또는 콘솔 캡처 표시(사용 가능한 경우)

수집된 데이터를 압축되지 않은 일반 텍스트 형식(.txt)으로 케이스에 첨부하십시오. 케이스에 정보를 첨부할 수 있습니다.이렇게 하려면 Case Query Tool의 도움을 받아 업로드합니다(등록된 고객만 해당). Case Query Tool에 액세스할 수 없는 경우, 케이스 번호를 메시지 제목 줄에 attach@cisco.com으로 보내 관련 정보를 케이스에 첨부할 수 있습니다.
참고: IPC-3-NOBUFF 예외 문제를 해결하는 데 필요하지 않은 경우 문제의 근본 원인을 파악하는 데 필요한 중요한 정보가 손실될 수 있으므로 위의 정보를 수집하기 전에 라우터를 수동으로 다시 로드하거나 전원을 껐다가 다시 켜지 마십시오.

관련 정보

- "%RSP-3-RESTART의 원인:CBUS 복합?

- IPC 프로세스에 대한 CPU 호그 정보 표시

- Cisco 12000 Series 인터넷 라우터:자주 묻는 질문(FAQ)

- 최적의 라우팅 달성 및 BGP 메모리 소비 감소

- Cisco 12000 Series 인터넷 라우터 기술 지원 페이지

- Cisco 라우터 제품 지원 페이지

- Technical Support - Cisco Systems