Thus, it was not reported in the hourly syslog message. There are many reasons, but the most common ones are: The information in the fabric header of the packet might be corrupt, so the source module cannot be determined the XBAR that was traversed is removed from the system since the error incremented. The system is unable to ascertain the XBAR that the packet traversed. Notice that the XBAR information is missing. CRC error with a single source module, receive module, but no XBAR instance: %OC_USD-SLOT4-2-RF_CRC: OC2 received packets withĬRC error from MOD 1In this message, Module 4 (M4) reported the CRC error from M1.In this case, M1 detected CRC errors from M15 through XBAR slot 1 instance 1. XBAR 1 is the cross bar in which the packet was received. The module where the CRC errors originate is referred to as the ingress module (M15 in this case), and the module that reported the problem is the egress module (M1). CRC error with a single source module, receive module, and XBAR instance: %OC_USD-SLOT1-2-RF_CRC: OC1 received packets withĬRC error from MOD 15 through XBAR slot 1/inst 1This means that the module in slot 1 detected a CRC error from M15 through XBAR slot 1/instance 1.This section describes four of the most common types of fabric CRC Errors. Understand the Different Fabric CRC Errors This is reported by M1, which indicates that it received packets with the wrong CRC from Module 15 (M15) via XBAR slot 1/instance 1. Here is a sample error message: %OC_USD-SLOT1-2-RF_CRC: OC1 received packets withĬRC error from MOD 15 through XBAR slot 1/inst 1 In M1/Fab1 architecture, CRCs are detected only on the egress linecard (S3). So, the devices involved in the path are the ingress Octopus, chassis, crossbar fabric, and egress Octopus. If CRC is detected in S3, a problem might have happened in S1 or S2 also, since no CRC check is performed in those stages. With the assumption that a unidirectional flow from Module 1 (M1) to Module 2 (M2) is present, the ingress Octopus-1 on M1 performs error checks on packets it receives from the south, and the egress Octopus-1 on M2 from the north. Please remember that most of the Nexus 7000 Series switches have three or more XBARs installed. Stage 1 (S1), Stage 2 (S2), and Stage 3 (S3) are the three stages of the Nexus 7000 fabric, Octopus is the queue engine, Santa Cruz (SC) is the fabric ASIC, and Instance 1 and 2 are the two SC instances on the XBAR. The previous image gives an overview of the components involved when a packet traverses a fabric module. Here is a high-level diagram of a Nexus 7018 fabric module with M1 linecards: This document covers the most common types of fabric CRC errors. A troubleshoot of fabric Cyclic Redundancy Checksums (CRCs) involves the collection of data, data analysis, and an elimination process in order to isolate the problem component. This document describes how to resolve fabric errors reported in the Cisco Nexus 7000 platform.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |