[kev]

Здравствуйте коллеги.

Изменилась схема сети. Раньше домовые коммутаторы были подключены в Cisco 6509 по оптике 1G

6509 циску поменяли на C4948E + SNR-2990-24FX куда подключили домовые коммутаторы.

 

После замены коммутатора Cisco 6509 SUP720 на Cisco C4948E возникли проблемы в виде output drops на коммутаторе 3550 на сети справа

Так же output drops были на правой 6509 в сторону 4948. После того как 2Гбит/с поменяли на 10G дропы на этом линке исчезли.

 

Причем все эти дропы ощущаются абонентами в виде потери пакетов, которые подключены к левой стороне сети где заменили оборудование .

У Тех абонентов которые справа потерь пакетов нет.

3550#sh int Po2
Port-channel2 is up, line protocol is up (connected)
  Hardware is EtherChannel, address is 0017.e035.d483 (bia 0017.e035.d483)
  MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 177/255, rxload 35/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 1000BaseLX
  input flow-control is off, output flow-control is on
  Members in this channel: Gi0/3 Gi0/4
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:00:00, output hang never
  Last clearing of "show interface" counters 05:27:25
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 278868000 bits/sec, 88839 packets/sec
  5 minute output rate 1388392000 bits/sec, 142156 packets/sec
     1282873162 packets input, 2060179784 bytes, 0 no buffer
     Received 2293 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 1441 multicast, 0 pause input
     0 input packets with dribble condition detected
     2268995540 packets output, 994889212 bytes, 6925295 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     6925295 output buffer failures, 0 output buffers swapped out

 

Пакеты дропаются выборочно только для абонентов трафик которых маршрутизируется на Cisco 4948E.

Такое ощущение что для для этих абонентов трафик летит в их сторону с большей скоростью и переполняется выходной буфер на 3550.

 

Такое возможно? У кого нибудь есть  мысли о причине подобного поведения.

[v_r]

В 2/28/2018 в 10:29, kev сказал:

input flow-control is off, output flow-control is on

Выключите flow control, возможно в этом проблема.

[Telesis]

On 28.02.2018 at 6:29 PM, kev said:

6925295 underruns

 

[kev]

В 02.03.2018 в 03:36, v_r сказал:

Выключите flow control, возможно в этом проблема.

 

flow control выключен. Проблема не в нем

[passer]

input flow-control is off, output flow-control is on

совсем выключен, ага

[kev]

В 02.03.2018 в 11:12, Telesis сказал:

 

проблему с переполнением output buffer получилось решить путем устранения etherchannel

и распределения нагрузки путем PBR по получившимся в итоге отдельным гигабитным линкам.

 

но дропы всё равно есть.  

 

42 минуты назад, passer сказал:

input flow-control is off, output flow-control is on

совсем выключен, ага

Да вы правы. 

Мы его выключали, потом снова включали.

На примере он включен.

Но на underruns и output buffer errors он никак не влиял. 

К тому же счетчики RxPause TxPause не росли.

 

[applx]

так они и будут, у вас разные скорости с обоих сторон...

[kev]

37 минут назад, applx сказал:

так они и будут, у вас разные скорости с обоих сторон...

все линки подключены на одинаковых скоростях.

1G к 1G

10G к 10G

[zhenya`]

Тут речь про переходы между. Между бордером и 3550 сколько линк? И загрузка какая?

[kev]

2 минуты назад, zhenya` сказал:

Тут речь про переходы между. Между бордером и 3550 сколько линк? И загрузка какая?

сейчас два линка по 1G.

Загрузка в пике чуть больше 90%.  

Но на 3550 уже нет ошибок после того как разбили etherchannel.

 

За несколько суток накопилась статистика на 4948E на 10G портах которые смотрят на SNR-2990-24FX

Tx-Drops-Queue-8

Te1/49                         0                 0                0             25309
Te1/50                         0                 0                0             27654

 

но сейчас счетчик не растет.

[zhenya`]

Добавьте пару линков ещё и стрельнете больше 2 гиг или около того.

[kev]

30 минут назад, zhenya` сказал:

Добавьте пару линков ещё и стрельнете больше 2 гиг или около того.

так то оно так. Но это не объясняет потери внутри сети.

Даже при минимальной загрузке канала. На 500 пингов 4-5 потерь.

Не понятно только где идут потери.

 

Все счетчики ошибок на транзитном оборудовании по нулям а потери есть.

 

PS: когда стоял 6509 таких проблем не было. Поставили 4948. Появились

Изменено 5 марта, 2018 пользователем kev

[Telesis]

15 hours ago, kev said:

 

PS: когда стоял 6509 таких проблем не было. Поставили 4948. Появились

Так и линк стал 10Г, соответственно бёрст стал чаще и больше. На 3550 буфера захлебнулись.

Можно попробовать поиграться с QoS на 3550, но все равно это не на долго.

 

[Butch3r]

17 часов назад, kev сказал:

Загрузка в пике чуть больше 90%.  

Это очень плохо, расширяйте емкость

[applx]

22 hours ago, kev said:

все линки подключены на одинаковых скоростях.

1G к 1G

10G к 10G

посчитайте с какой скоростью 10Г порт опустошит свой буфер и с какой 1Г?

[kev]

5 часов назад, Telesis сказал:

Так и линк стал 10Г, соответственно бёрст стал чаще и больше. На 3550 буфера захлебнулись.

Можно попробовать поиграться с QoS на 3550, но все равно это не на долго.

 

Как я уже писал ранее ошибок переполнения буфера на 3550 не наблюдается.

 

Путем тестирования выяснилось что потери идут на 4948. Причем только пакеты которые на ней маршрутизируются.

Ошибок на интерфейсах 4948 тоже не наблюдается.

 

Команда ниже показывает увеличивающиеся счетчики дропающихся пакетов. Но как диагностировать причину этих дропов не понятно.

4948#sh platform software drop-port
Drop Port Software State
  Dequeue Enabled           : True
  DropQueue Water mark Reg  : 0x8000600038001D4C
  DropQueue Water mark Reg  : 0x7FE32010
(Empty, PreEmpty, Head:0x1AD3, Tail:0x1AD3)
  DropActivityCount                : 29673685024
  DropOverrunCount                 : 0

Drop Event Reason            Packets Dropped
-----------------            ---------------
 SptDrop                         231585735
 InpL2AclDrop                    1176372947
 InpL3AclDrop                    800703
 UcastRpfDrop                    165
 BridgeToRxPortDrop              631980916575
 rplErrDrop                      49282223801
 OutL3AclDrop                    2941
 OutPolicerDrop                  239182969
 TxQueFullDrop                   71430653
 DblDrop                         5780140

 

[Telesis]

22 hours ago, kev said:

Tx-Drops-Queue-8

 

Spoiler

Queue 8 is the default queue with no QoS Configured

Reduce tx-queue size OR Modify default queue size

 

 

23 minutes ago, kev said:

4948#sh platform software drop-port

Spoiler

BridgeToRxPortDrop - received in a vlan with no other ports, replicated to a floodset/entry where ingress port was a member
DblDrop - packets dropped by DBL (including DBL on CPU ports)
rplErrDrop - broadcast/multicast packets dropped while being replicated, many normal reasons to increment, including: rpf failure, floodset containing drop port, packets replicated to the CPU but also bridged to a floodset/entry containing the CPU
SptDrop  - spanning-tree drop; packets dropped because a port is not in a forwarding state
SrcHitDrop - dropped at source learning stage; example: static MAC drop entry
TxQueFullDrop  - a tx port is oversubscribed

 

Изменено 6 марта, 2018 пользователем Telesis

[kev]

16 минут назад, Telesis сказал:

   Queue 8 is the default queue with no QoS Configured

  Скрыть содержимое

BridgeToRxPortDrop - received in a vlan with no other ports, replicated to a floodset/entry where ingress port was a member
DblDrop - packets dropped by DBL (including DBL on CPU ports)
rplErrDrop - broadcast/multicast packets dropped while being replicated, many normal reasons to increment, including: rpf failure, floodset containing drop port, packets replicated to the CPU but also bridged to a floodset/entry containing the CPU
SptDrop  - spanning-tree drop; packets dropped because a port is not in a forwarding state
SrcHitDrop - dropped at source learning stage; example: static MAC drop entry
TxQueFullDrop  - a tx port is oversubscribed

 

А где нибудь можно ещё увидеть эти дропы.

Может есть мануал по выяснению причин их возникновения.

[Telesis]

Spoiler

https://yadi.sk/i/j72AX9EV3T5XHe

 

[kev]

Быстро растут encapsulation failed. Может в этом проблема?

4948#sh ip traffic
IP statistics:
  Rcvd:  70543 total, 38976 local destination
         0 format errors, 0 checksum errors, 6140 bad hop count
         0 unknown protocol, 0 not a gateway
         0 security failures, 0 bad options, 26508 with options
  Opts:  0 end, 0 nop, 0 basic security, 0 loose source route
         0 timestamp, 0 extended security, 0 record route
         0 stream ID, 0 strict source route, 26508 alert, 0 cipso, 0 ump
         0 other
  Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
         0 fragmented, 0 couldn't fragment
  Bcast: 2484 received, 785 sent
  Mcast: 23482 received, 8296 sent
  Sent:  28907 generated, 753 forwarded
  Drop:  23902 encapsulation failed, 0 unresolved, 0 no adjacency
         0 no route, 0 unicast RPF, 0 forced drop
         0 options denied, 0 source IP address zero

 

[Tosha]

Имхо загрузка 90% очень высока. Снижайте до 80%.