NetCLI

Cisco Network Guide

(Ts) Troubleshooting przełączników sieciowych*

by · 28 stycznia 2020

Spis treści Pokaż

Troubleshooting wydajności przełącznika

Budowa przełącznika Cisco Catalyst Switch

Cisco Catalyst Switch Hardware
  • Ports – Zarówno fizyczne jak i logiczne interfejsy przełącznika umożliwiają komunikację z innymi urządzeniami.
  • Forwarding Logic – Przełączniki zawierają fizyczne komponenty umożliwiające podejmowanie decyzji na temat routingu.
  • Backplane – Łączy ze sobą wszystkie interfejsy przełącznika umożliwiając wewnętrzną komunikacje w obrębie jednego urządzenia. Nadchodzące ramki są przesyłane z interfejsu wejściowego (Ingress Port) na interfejs wyjściowy (Egress Port).
  • Control Plane – Kontroluje prace systemu IOS tworząc niezbędne struktury (NP. tablice „MAC Address Table”).

Show interface interfejs counters [errors]

  • Komenda [show interface interfejs counters] oraz komenda [show interface interfejs counters errors] umożliwia wykrywanie podstawowych błędów związanych z odbieraniem ramek Ethernet-owych.
  • Wydruk komendy [show interface interfejs counters errors] wygląda następująco:
# show interfaces fastEthernet 1/0/1   counters errors
Port        Align-Err     FCS-Err    Xmit-Err     Rcv-Err    UnderSize  OutDiscards   
Fa1/0/1        0             0          0            0           0           0
Port      Single-Col  Multi-Col     Late-Col  Excess-Col  Carri-Sen      Runts     Giants 
Fa1/0/1        0           0            0         0           0            0         0
  • Align-Err – An alignment error occurs when frames do not end with an even number of octets, while simultaneously having a bad cyclic redundancy check (CRC). An alignment error normally suggests a Layer 1 issue, such as cabling or port (either switchport or network interface card [NIC] port) issues.
  • FCS-Err – A frame check sequence (FCS) error occurs when a frame has an invalid checksum, although the frame has no framing errors. Like the Align-Err error, an FCS-Err often points to a Layer 1 issue, but it also occurs when there is a duplex mismatch.
  • Xmit-Err – A transmit error (that is, Xmit-Err) occurs when a port’s transmit buffer overflows. A speed mismatch between inbound and outbound links often results in a transmit error.
  • Rcv-Err – A receive error (that is, Rcv-Err) occurs when a port’s receive buffer overflows. Congestion on a switch’s backplane could cause the receive buffer on a port to fill to capacity, as frames await access to the switch’s backplane. However, most likely, a Rcv-Err is indicating a duplex mismatch.
  • UnderSize – An undersized frame is a frame with a valid checksum but a size less than 64 bytes. This issue suggests that a connected host is sourcing invalid frame sizes.
  • Single-Col – A Single-Col error occurs when a single collision occurs before a port successfully transmits a frame. Common reasons for a Single-Col error include high bandwidth utilization on an attached link or a duplex mismatch.
  • Multi-Col – A Multi-Col error occurs when more than one collision occurs before a port successfully transmits a frame. Similar to the Single-Col error, common reasons for a Multi-Col error include high bandwidth utilization on an attached link or a duplex mismatch.
  • Late-Cor – A late collision is a collision that is not detected until well after the frame has begun to be forwarded. While a Late-Col error could indicate that the connected cable is too long, this is an extremely common error seen in mismatched duplex conditions.
  • Excess-Col – The Excess-Col error occurs when a frame experiences 16 successive collisions, after which the frame is dropped. This error could result from high bandwidth utilization, a duplex mismatch, or too many devices on a segment.
  • Carri-Sen – The Carri-Sen counter is incremented when a port wants to send data on a half-duplex link. This is normal and expected on a half-duplex port, because the port is checking the wire to make sure that no traffic is present prior to sending a frame. This operation is the carrier sense procedure described by the carrier sense multiple access with collision detect (CSMA/CD) operation used on half-duplex connections. Full-duplex connections, however, do not use CSMA/CD.
  • Runts – A runt is a frame that is less than 64 bytes in size and has a bad CRC. A runt could result from a duplex mismatch or a Layer 1 issue.
  • Giants – A giant is a frame size greater than 1518 bytes (assuming that the frame is not a jumbo frame) that has a bad FCS. Typically, a giant is caused by a problem with the NIC in an attached host. The jumbo frame has a frame size greater than 1518 bytes, but it has a valid FCS.

Duplex Mismatched

  • Jeżeli urządzenie podłączone do przełącznika wspiera jedynie tryb „half-duplex” to dany interfejs automatycznie wynegocjuje zmianę statusu z trybu „full-duplex” na tryb „half-duplex” (Opcja auto negocjacji musi być włączona).
  • W przypadku braku możliwości automatycznego wynegocjowania trybu pracy interfejsu sieciowego, przełącznik automatycznie przejdzie w tryb „half-duplex”. Jeżeli jednak dojdzie do sytuacji  w której obydwie strony połączenia będą pracowały w innych trybach, komunikacja może zostać zaburzona. Objawem błędnej konfiguracji trybu „duplex” jest stale zwiększający się licznik błędów „FCS-Err” oraz „Late-Col”, widoczny za pomocą komendy [show interface interfejs counters errors].

Encapsulation Mismatched

  • Enkapsulacja połączeń Trunk-owych może być osiągnięta za pomocą jednego z dwóch dostępnych protokołów: ogólnodostępnego 802.1Q ustandaryzowanego przez IEEE bądź ISL stworzonego przez Cisco. Domyślnie urządzenia Cisco wspierające obydwa rozwiązania będą próbowały wynegocjować połączenie ISL za pomocą protokołu DTP.
  • W przypadku łączenia przełączników Cisco z przełącznikami innych firm należy ręcznie skonfigurować połączenie na enkapsulacje 802.1Q ponieważ ani protokół DTP ani enkapsulacja ISL nie są wspierane przez innych producentów.

Funkcja Auto-MDIX

  • Funkcja „Auto-MDIX” umożliwia wykrycie trybu pracy urządzenia podłączonego do jednego z interfejsu przełącznika, sprawdzając czy urządzenia są podłączone odpowiednim kablem „Crossover” bądź „Straight-though”. Jeżeli podłączony został niewłaściwy kabel funkcja „Auto-MDIX” automatycznie dopasuje metodę nadawania i odbierania sygnałów.

Wykorzystanie procesora CPU

Pamięć TCAM a procesor CPU

  • Poziom wykorzystania procesora CPU w przełącznikach Cisco Catalyst jest przeważnie bardzo niski, ponieważ większa część operacji związanych z przekierowywaniem pakietów (Routingiem) jest obsługiwana na poziomie sprzętu fizycznego (Hardware) przy wsparciu pamięci TCAM. Bieżący poziom utylizacji procesora CPU można wyświetlić za pomocą komendy [show processes cpu], która to oprócz bieżącego procentowego zużycia procesora wyświetla procent utylizacji w ciągu ostatniej minuty oraz pięciu ostatnich minut.
  • Wysokie zużycie procesora CPU może negatywnie wpłynąć na wydajność przełącznika, powodując powstawanie opóźnień w obsłudze nadchodzącego ruchu sieciowego. Jedną z przyczyn takiego stanu może być bardzo duża ilość operacji wymagających interwencji procesora, najbardziej wymagające zadania to operacje:
    • ARP Input Process – W przypadku niewłaściwej konfiguracji statycznych tras routingu operacje protokołu ARP mogą znacząco zwiększyć zużycie procesora CPU. Przykładem błędnego użycia trasy statycznej jest trasa domyślna kierowana na interfejs fizyczny np. [ip route 0.0.0.0 0.0.0.0 gigabitethernet 0/0]. W takim przypadku zapytania ARP będą generowane dla każdego pakietu kierowanego na inny docelowy adres IP. Jest to wynikiem braku określenia adresu IP następnego przeskoku, a tym samym adres ten musi być wykryty za pomocą zapytań protokołu ARP.
    • Net Background Process – W przypadku zapełnienia wszystkich wejściowych buforów interfejsu sieciowego, dane mogą zostać przekierowane do głównego bufora, co wymaga użycia procesora CPU. Sytuacja ta może być wykryta w sytuacji zwiększających się wartości „Throttles”, „Ignored” oraz „Overrun” względem określonego interfejsu sieciowego, co jest szczególnie widoczne wydruku komendy [show interface interfejs].
    • IP Background Process – Zmiana statusu interfejsu z aktywnego up/up na pasywny down/down bądź zmiana adresu IP, wymaga każdorazowej interwencji procesora CPU.
    • TCP Timer Process – Procesy związane z połączeniami protokołu TCP obciążają procesor CPU, jeżeli są nawiązywane w dużej ilości, szczególnie jeżeli komunikacja „Three-Way Handshake” nie zostanie poprawnie zakończona, a tym samym zasoby urządzenia będą cały czas blokowane (Sytuacja tak może stanowić atak DDoS).

Komendy SHOW wykorzystywane w procesie troubleshooting-u utylizacji procesora CPU

# show ip arp

Wyświetla zawartość tablicy „ARP Cache”.

# show interface interfejs

Wyświetla szczegółowe informacje na temat danego interfejsu sieciowego.

# show tcp statistics

Wyświetla statystyki związane z protokołem TCP.

# show processes cpu

Wyświetla utylizacje procesora CPU.

# show processes cpu history

Wyświetla historie utylizacji procesora CPU.

Tworzenie kopi informacji o błędach krytycznych (Dump)

# write core [ENTER] adres-IP [ENTER] nazwa-pliku-docelowego

W przypadku wystąpienia błędu krytycznego, urządzenie wyśle zrzut własnej pamięci operacyjnej na wskazany w komendzie adres IP (Przy użyciu protokołu TFTP).

Zrzutu pamięci z użyciem protokołu FTP

Zrzut pamięci zostanie wykonany w przypadku zajścia błędu krytycznego.

(config)# ip ftp username login

Określa nazwę użytkownika usługi FTP.

(config)# ip ftp password hasło

Określa hasła użytkownika usługi FTP.

(config)# exception protocol ftp

Określa za pomocą jakiego protokołu zostanie wykonany zrzut pamięci.

(config)# exception dump {nazwa-domenowa / adres-IP}

Określa urządzenie na jakie zostanie wykonany zrzut pamięci.

Zrzutu pamięci z użyciem protokołu TFTP / RCP

(config)# exception protocol {tftp / rcp)

Określa za pomocą jakiego protokołu zostanie wykonany zrzut pamięci.

(config)# exception dump {nazwa-domenowa / adres-IP}

Określa urządzenie na jakie zostanie wykonany zrzut pamięci.

Problemy związane z wysokim poziomem utylizacji pamięci

Memory Leak

  • W sytuacji rozpoczęcia nowego procesu, system IOS wydziela na jego utrzymanie cześć własnej pamięci. Po zakończeniu wykonywania operacji pamięć ta winna być zwrócona, jeżeli jednak tak się nie stanie dochodzi do sytuacji zwanej „Memory Leak”. Obecne wykorzystanie pamięci przez system operacyjny IOS można zaobserwować za pomocą wydruku komendy [show memory allocating-process totals].
# show memory   allocating-process totals
Head           Total(b)          Used(b)           Free(b)         Lowest(b)     Largest(b)   Processor     433A7F0    68159248    31930556    36228692    34345180       16768896
 I/O         6400000    12582912     8668852     3914060      3794516        3912032
Driver te     2E00000       1048576           44            1048532      1048532       1048532
Allocator PC Summary for: Processor

     PC                   Total        Count            Name   0x024B0BEC
4276620       1      LC   message chunk   0x016DA424
4231044      19     Init   0x0138955C
3676596    3979   *Packet Header*   0x020A8098
2689356       9         Init   0x01BCC67C
2460948     317    Process Stack   0x021D02D0
1148240      63     COLL: coll rec   0x024AE640
680140        1       MDFS SPD Chunks   ...
  • Head – Określa adres alokacji pamięci.
  • Total – Określa całkowitą ilość pamięci.
  • Used – Określa całkowitą ilość wykorzystywanej pamięci.
  • Free – Określa całkowitą wolnej pamięci.
  • Lowest – Określa najniższą ilość wykorzystywanej pamięci, od momentu uruchomienia systemu IOS.
  • Largest – Określa najwyższą ilość wykorzystywanej pamięci, od momentu uruchomienia systemu IOS.
  • Buffer Leak – Stanowi problem podobny do „Memory Leak”, z tymże dotyczący buforów a nie pamięci. Poziom wykorzystania buforów można określić za pomocą komendy [show interfaces] jak i komendy [show buffers].

Pytania i odpowiedzi

  • ? Informacja: The FIB and RIB receive routing updates at the same time.
  • ? Informacja: CEF–A single database of routing information is built for the switching hardware.
  • ! Problem 1: Komenda „show mac-address-table” nie wyświetla interfejsu ani sieci VLAN do której należy adres MAC.
  • $ Rozwiązanie 1: Host wysłał ramkę, której przełącznik nie może zrozumieć lub wykorzystuje dwie karty sieciowe do wysyłania jak i odbierania ruchu pomiędzy urządzeniami (NP. korzysta z funkcji Load balancing).
  • ! Problem 2: Jakie kroki należy podjąć w celu zbadania problemów dotyczących „Duplex Mismatch”?
  • $ Rozwiązanie 2: Pola „auto-speed” jak i „auto-dupleks” powinny być takie same na obydwóch interfejsach określonego połączenia. Ponad to wartość „runts”  jak i wartość „input errors” winna wynosić 0 i nie ulegać zwiększeniu.
  • ? Pytanie 1: Jakie stwierdzenie opisuje przełącznik wykorzystujący funkcję CEF?
  • $ Odpowiedź 1: Pojedyncza baza routingu jest stworzona w strukturze sprzętowej przełącznika.
  • ? Pytanie 2: W jaki sposób można opisać operację zachodzące w pamięci FIB?
  • $ Odpowiedź 2: Pamięć FIB przetrzymuje trasy dotarcia do hostów jak i najbardziej szczegółowy wpis (prefix) sieci wraz z adresem następnego przeskoku. Zawartość pamięci FIB może być wyświetlona za pomocą komendy [show ip cef vlan].

Pozostałe tematy związane ze wstępem do warstwy drugiej

PDFPRINT

Robert T Kucharski

Cisco Network Engineer in GPW.

Dodaj komentarz