Strona 1 z 1
3650 output drops
: 08 sie 2017, 14:34
autor: frontier
3650, mam sporo output dropów na jednym interfejsie, chwilowo bylo nawet ponad 30%, czy to wynika z tego ze port sobie nie radzi z taka iloscia pakietów/sek?
Kod: Zaznacz cały
show int giga2/0/14
GigabitEthernet2/0/14 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is cc46.d662.620e (bia cc46.d662.620e)
Description: swib2e:11/5:11.2:prod:int
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 224/255, txload 48/255, rxload 38/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 04:36:06, output never, output hang never
Last clearing of "show interface" counters 00:11:57
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 5866913
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 151463000 bits/sec, 16791 packets/sec
5 minute output rate 189204000 bits/sec, 28648 packets/sec
11526810 packets input, 13059496536 bytes, 0 no buffer
Received 3394 broadcasts (2323 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2323 multicast, 0 pause input
0 input packets with dribble condition detected
20009056 packets output, 16390212969 bytes, 0 underruns
5866913 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Btw. czytalem
https://www.cisco.com/c/en/us/support/d ... ut-dr.html i tam pisza ze przyczyna jest oversubscription no ale mnie to nie dotyczy.
Re: 3650 output drops
: 08 sie 2017, 21:04
autor: lbromirs
A pokaż jak masz ten port skonfigurowany, jaki masz tryb QoSa, co trafia w kolejki/etc. Domyślna konfiguracja nie da Ci pełnej przepustowości portu dla jednej klasy ruchowej.
Re: 3650 output drops
: 09 sie 2017, 10:02
autor: frontier
Dzieki za odpowiedz Lukasz.
Port jest czescia etherchannela, a konfiguracja tak jak piszesz jest standardowa. Pozostale porty tez maja dropy na podobnym poziomie.
Kod: Zaznacz cały
interface GigabitEthernet2/0/14
switchport trunk native vlan 900
switchport trunk allowed vlan 66,80,89-92,881,882,3003
switchport mode trunk
channel-group 20 mode on
spanning-tree bpduguard enable
interface Port-channel20
description swib2e:11/5:11/6:11/9:11/10:11.2:prod:int
switchport trunk native vlan 900
switchport trunk allowed vlan 66,80,89-92,881,882,3003
switchport mode trunk
spanning-tree bpduguard enable
Kod: Zaznacz cały
show platform qos queue config gigabitEthernet 2/0/14
DATA Port:12 GPN:1028 AFD:Disabled QoSMap:0 HW Queues: 96 - 103
DrainFast:Disabled PortSoftStart:1 - 1080
----------------------------------------------------------
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
--- -------- -------- -------- --------- ---------
0 1 5 120 6 480 6 320 0 0 3 1440
1 1 4 0 7 720 3 480 2 180 3 1440
2 1 4 0 5 0 5 0 0 0 3 1440
3 1 4 0 5 0 5 0 0 0 3 1440
4 1 4 0 5 0 5 0 0 0 3 1440
5 1 4 0 5 0 5 0 0 0 3 1440
6 1 4 0 5 0 5 0 0 0 3 1440
7 1 4 0 5 0 5 0 0 0 3 1440
Priority Shaped/shared weight shaping_step
-------- ------------ ------ ------------
0 0 Shared 50 0
1 0 Shared 75 0
2 0 Shared 10000 146
3 0 Shared 10000 0
4 0 Shared 10000 120
5 0 Shared 10000 0
6 0 Shared 10000 48
7 0 Shared 10000 0
Weight0 Max_Th0 Min_Th0 Weigth1 Max_Th1 Min_Th1 Weight2 Max_Th2 Min_Th2
------- ------- ------ ------ ------ ------ ------ ------ ------
0 0 478 0 0 534 0 0 600 0
1 0 573 0 0 641 0 0 720 0
2 0 0 0 0 0 0 0 0 0
3 0 0 0 0 0 0 0 0 0
4 0 0 0 0 0 0 0 0 0
5 0 0 0 0 0 0 0 0 0
6 0 0 0 0 0 0 0 0 0
7 0 0 0 0 0 0 0 0 0
Kod: Zaznacz cały
show platform qos queue stats gigabitEthernet 2/0/14
DATA Port:12 Enqueue Counters
-------------------------------
Queue Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2
----- ------- ----------- ----------- -----------
0 0 0 11889437069 319274064
1 0 0 0 15022755491
2 0 0 0 0
3 0 0 0 0
4 0 0 0 0
5 0 0 0 0
6 0 0 0 0
7 0 0 0 0
DATA Port:12 Drop Counters
-------------------------------
Queue Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop
----- ----------- ----------- ----------- ----------- -----------
0 0 0 0 0 0
1 0 0 23995814424 0 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
AQM Broadcast Early WTD COUNTERS(In terms of Bytes)
--------------------------------------------------
PORT TYPE ENQUEUE DROP
--------------------------------------------------
UPLINK PORT-0 N/A 0
UPLINK PORT-1 N/A 0
UPLINK PORT-2 N/A 0
UPLINK PORT-3 N/A 0
NETWORK PORTS 3749810168686 5360180256529
RCP PORTS 0 0
CPU PORT 0 0
Note: Queuing stats are in bytes
Co to jest TH0, TH1, TH2?
Co jeszcze zauwazylem to wysokie obciazenie CPU i procesu FED i PDSD (nie wiem co to jest), mam wersje 03.07.03E
Kod: Zaznacz cały
show process cpu | ex 0.00
Core 0: CPU utilization for five seconds: 100%; one minute: 98%; five minutes: 95%
Core 1: CPU utilization for five seconds: 85%; one minute: 78%; five minutes: 74%
Core 2: CPU utilization for five seconds: 17%; one minute: 25%; five minutes: 28%
Core 3: CPU utilization for five seconds: 7%; one minute: 8%; five minutes: 13%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
6211 1798209 271427468 715 28.5 28.3 28.0 1088 fed
6212 2558285 281064431 20 0.15 0.09 0.09 0 platform_mgr
6213 3074081 227989473 135 0.50 0.26 0.21 0 stack-mgr
6812 2732614 256278435 1479 18.0 19.2 19.7 0 pdsd
13463 995413 213893003 15 0.10 0.12 0.14 0 wcm
13470 3904043 125081421 138 5.17 4.34 4.37 0 iosd
13471 649102 52584178 94 0.05 0.01 0.03 0 ha_mgr
Re: 3650 output drops
: 09 sie 2017, 10:07
autor: lbromirs
frontier pisze:Dzieki za odpowiedz Lukasz.
Port jest czescia etherchannela, a konfiguracja tak jak piszesz jest standardowa. Pozostale porty tez maja dropy na podobnym poziomie.
Co to jest TH0, TH1, TH2?
Progi klasyfikacji i odrzucania ruchu (w kolejności którą pokazałeś w poleceniach) - od angielskiego 'threshold'.
Wróć proszę do
tego dokumentu i poczytaj dokładnie o nowym modelu QoS w 3650/3850 - domyślnie skonfigurowane polityki powodują u Ciebie, że ruch wpada do dwóch kolejek a te z kolei szybko przeciążasz. Stąd dropy.
Re: 3650 output drops
: 09 sie 2017, 12:14
autor: frontier
Nie do konca rozumiem czy w mojej sytuacji musze tworzyc klase priorytetowa czy moge wszystko w jedna kolejke wrzucic?
Re: 3650 output drops
: 14 sie 2017, 15:26
autor: xhinge
3650/3850 domyslnie jako "Output drops" pokazuja bajty, nie pakiety. Warto zwrocic na to uwage podczas obliczania % dropow.
Wyglada na to, ze nie masz zaaplikowanej zadnej "service policy", czyli domyslnie 2 kolejki sa wykorzystywane i okreslona liczba buforow jest przypisana do kazdej kolejki. W wiekszosci przypadkow to wystarcza, ale u Ciebie najprawdopodobiej pojawiaja sie "micro bursts", ktore nie beda wychwycone przez standardowe metody monitorowania.
Mozna sprobowac powiekszyc bufory na konkretnym porcie, o na przyklad tak:
Kod: Zaznacz cały
!
policy-map <name of policy>
class class-default
bandwidth percent 100
queue-buffers ratio 100
!
int <INT>
service-policy input <name of policy> ! bez tej komendy "multiplier" nie zadziala na porcie
!
qos queue-softmax-multiplier 1200
!
Powyzsze maksymalizje dostepne bufory na platformach 3650/3850. Wiecej buforow ciezko wycisnac z platformy.
Jesli to nie pomoze, to za duzo nie da sie zrobic z perspektywy "output dropow" problem trzeba podejsc inaczej.
Jesli wiesz kiedy dokladnie w ciagu dnia te dropy sie pokazuja, mozesz zrobic SPAN tego portu w kierunku wychodzacym i pozniej przeanalizowac ruch w wiresharku. Statistics -> I/O Graph z odpowiednim interwalem na osi czasu. Nastepnie, zidentifikowac ruch powodujacy micro burst (to moze byc unicast flooding, konkretne aplikacje, etc) i zaadresowac problem blizej zrodla.
Mozesz rowniez, sprobowac zmienic loadbalancing na port-channelu.
Re: 3650 output drops
: 15 sie 2017, 10:34
autor: frontier
xhinge pisze:3650/3850 domyslnie jako "Output drops" pokazuja bajty, nie pakiety. Warto zwrocic na to uwage podczas obliczania % dropow.
Wyglada na to, ze nie masz zaaplikowanej zadnej "service policy", czyli domyslnie 2 kolejki sa wykorzystywane i okreslona liczba buforow jest przypisana do kazdej kolejki. W wiekszosci przypadkow to wystarcza, ale u Ciebie najprawdopodobiej pojawiaja sie "micro bursts", ktore nie beda wychwycone przez standardowe metody monitorowania.
Mozna sprobowac powiekszyc bufory na konkretnym porcie, o na przyklad tak:
Kod: Zaznacz cały
!
policy-map <name of policy>
class class-default
bandwidth percent 100
queue-buffers ratio 100
!
int <INT>
service-policy input <name of policy> ! bez tej komendy "multiplier" nie zadziala na porcie
!
qos queue-softmax-multiplier 1200
!
Powyzsze maksymalizje dostepne bufory na platformach 3650/3850. Wiecej buforow ciezko wycisnac z platformy.
Jesli to nie pomoze, to za duzo nie da sie zrobic z perspektywy "output dropow" problem trzeba podejsc inaczej.
Jesli wiesz kiedy dokladnie w ciagu dnia te dropy sie pokazuja, mozesz zrobic SPAN tego portu w kierunku wychodzacym i pozniej przeanalizowac ruch w wiresharku. Statistics -> I/O Graph z odpowiednim interwalem na osi czasu. Nastepnie, zidentifikowac ruch powodujacy micro burst (to moze byc unicast flooding, konkretne aplikacje, etc) i zaadresowac problem blizej zrodla.
Mozesz rowniez, sprobowac zmienic loadbalancing na port-channelu.
Hej hej,
Dzieki, tak tez zrobilem, dropów duzo mniej ale nadal sa... zmiana algorytmu loadbalancingu tez rozpatrywalem, moze spróbuje.
Btw. Czy switch 3650 przelacza pakiety uzywajac store-and-forward?
Re: 3650 output drops
: 15 sie 2017, 12:04
autor: xhinge
Dodam, ze zmiana loadbalancingu na port-channelu nie powoduje dropow, nie wymaga tez restartowania urzadzenia.
Tak, wszystkie Catalysty robia store-and-forward.
Re: 3650 output drops
: 16 sie 2017, 17:41
autor: frontier
Skoro jest store-and-forward, czy wymiana na Nexusy i uzywanie cut-through wymaga mniejszych buforów dla takiego samego ruchu? Czy to ma jakis zwiazek?
Re: 3650 output drops
: 17 sie 2017, 10:27
autor: xhinge
Nie wszystkie Nexusy/karty liniowe dzisiaja jako cut-trough. Switche DC nie byly budowane z mysla o bufforowaniu pakietow, a przelaczaniu ich jak najszybciej. Duzo rozwiazan DC preferuje by pakiet zostal odrzucony niz przychodzil opozniony lub w zlej kolejnosci. Z tego powodu w przelacznikach DC bufforow jest jeszcze mniej. Dobrze zaprojektowane DC ma przewidywalna ilosc ruchu, "bursty" nie powinny sie pojawiac.
Idea bufforowania to raczej sieci campus/enterprise, gdzie zachowanie uzytkownikow jest ciezko przewidywalne. Dropy i ewentualne opoznieniua spowodowane bufforowaniem pakietow sa tolerowane ...do pewnego stopnia.
Oczywisci to wszystko generalizacja, zycie i prawdziwe implementacje pokazuja, ze wszystko jest bardziej skomplikowane, technologie i produkty campus/DC nachodza na siebie, a kreatywnosc ludzka nie zna granic.
Wracajac do Twojego pytania. Na Nexusach cut-trought bufforowanie odywa sie na interfejsie wejsciowym za pomoca VOQ (virtual output queue). Dostepne buffory na Nexusach i 10G portach bywaja mniejsze niz na najtanszych Catalystach. Nawet jak Catalyst bedzie wymieniony na Nexusa z cut-trought, to nie pomoze przepchac ruchu wiekszego niz szybkosc linku. Zamiana na nexusy moze przyniesc co najwyzej (albo az) linki 10G/40G/100G, co poszerzy waskie gardlo i spowoduje ze bufforowanie w ogole nie bedzie mialo miejsca.
...lub przesunie obciazenie na inne porty w sieci.