[GTER] RES: RX Pause em GE CCR1036 vs. 3c2920.
Paulo Coimbra
coimbra.root at gmail.com
Thu May 8 12:23:22 -03 2014
Senhores boa tarde,
Segue abaixo algumas informacoes obtidas do switch das portas pertencentes
ao LAG. A porta problematica é a GE 1/0/20 e do mikrotik. Vejo que na porta
20 do switch, está incrementando muito erro de CRC na entrada, mas os
pauses bem menores que na CCR.
CCR1036
=======
name: sfp2
driver-rx-byte: 1 334 648 141 913
driver-rx-packet: 6 085 270 243
driver-tx-byte: 9 732 264 003 023
driver-tx-packet: 9 326 060 687
rx-bytes: 1 358 991 739 711
rx-packet: 6 085 280 316
rx-too-short: 0
rx-64: 742 232 717
rx-65-127: 4 212 396 357
rx-128-255: 222 401 216
rx-256-511: 166 314 862
rx-512-1023: 231 572 977
rx-1024-1518: 417 708 449
rx-1519-max: 92 653 738
rx-too-long: 0
rx-broadcast: 4 508 817
rx-pause: 23 522 679
rx-multicast: 666 431
rx-fcs-error: 0
rx-align-error: 0
rx-overflow: 0
rx-length-error: 0
rx-code-error: 0
rx-jabber: 0
rx-ip-header-checksum-error: 0
rx-tcp-checksum-error: 0
rx-udp-checksum-error: 0
tx-bytes: 9 771 282 658 551
tx-packet: 9 326 060 684
tx-64: 722 357 294
tx-65-127: 1 379 765 688
tx-128-255: 344 392 143
tx-256-511: 264 966 056
tx-512-1023: 328 193 612
tx-1024-1518: 3 610 985 078
tx-1519-max: 2 675 400 813
tx-broadcast: 5 168 162
tx-pause: 0
tx-multicast: 60 261
tx-underrun: 0
tx-excessive-collision: 0
tx-multiple-collision: 0
tx-single-collision: 0
tx-deferred: 0
tx-late-collision: 0
tx-fcs-error: 0
tx-carrier-sense-error: 0
HP V1910
========
display interface GigabitEthernet 1/0/19
GigabitEthernet1/0/19 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 20fd-f19f-936d
Description: GigabitEthernet1/0/19 Interface
Loopback is not set
Media type is optical fiber, Port hardware type is 1000_BASE_LX_SFP
1000Mbps-speed mode, full-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 10240
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
PVID: 1024
Port link-type: trunk
VLAN passing : 10-100, 1024
VLAN permitted: 10-100, 1024
Trunk port encapsulation: IEEE 802.1q
Port priority: 0
Last clearing of counters: Never
Peak value of input: 41291671 bytes/sec, at 2014-04-30 20:38:19
Peak value of output: 10368294 bytes/sec, at 2014-04-23 10:08:21
Last 300 seconds input: 14638 packets/sec 14960955 bytes/sec 12%
Last 300 seconds output: 13994 packets/sec 3951452 bytes/sec 3%
Input (total): 59196355439 packets, 61287145973750 bytes
59193709365 unicasts, 1751565 broadcasts, 894509 multicasts, 0
pauses
Input (normal): 59196355439 packets, 61287145973750 bytes
59193709365 unicasts, 1751565 broadcasts, 894509 multicasts, 0
pauses
Input: 0 input errors, 0 runts, 0 giants, - throttles
0 CRC, 0 frame, 0 overruns, 0 aborts
- ignored, - parity errors
Output (total): 49346074393 packets, 13523749746833 bytes
49333351000 unicasts, 8486290 broadcasts, 4237103 multicasts, 0
pauses
Output (normal): 49346074393 packets, 13523749746833 bytes
49333351000 unicasts, 8486290 broadcasts, 4237103 multicasts, 0
pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
- lost carrier, - no carrier
display interface GigabitEthernet 1/0/20
GigabitEthernet1/0/20 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 20fd-f19f-936e
Description: GigabitEthernet1/0/20 Interface
Loopback is not set
Media type is optical fiber, Port hardware type is 1000_BASE_LX_SFP
1000Mbps-speed mode, full-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 10240
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
PVID: 1024
Port link-type: trunk
VLAN passing : 10-100, 1024
VLAN permitted: 10-100, 1024
Trunk port encapsulation: IEEE 802.1q
Port priority: 0
Last clearing of counters: Never
Peak value of input: 27998465 bytes/sec, at 2014-05-02 14:28:58
Peak value of output: 4477968 bytes/sec, at 2014-05-01 14:25:54
Last 300 seconds input: 20586 packets/sec 21841800 bytes/sec 18%
Last 300 seconds output: 13256 packets/sec 2984228 bytes/sec 3%
Input (total): 9257434391 packets, 9696953099283 bytes
9252185777 unicasts, 5147900 broadcasts, 59856 multicasts, 324
pauses
Input (normal): 9257393857 packets, 9696895825650 bytes
9252185777 unicasts, 5147900 broadcasts, 59856 multicasts, 324
pauses
Input: 40534 input errors, 0 runts, 0 giants, - throttles
40534 CRC, 0 frame, 0 overruns, 0 aborts
- ignored, - parity errors
Output (total): 6112403439 packets, 1364598712188 bytes
6107218944 unicasts, 4511879 broadcasts, 672616 multicasts, 0
pauses
Output (normal): 6112403439 packets, 1364598712188 bytes
6107218944 unicasts, 4511879 broadcasts, 672616 multicasts, 0
pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
- lost carrier, - no carrier
Em 7 de maio de 2014 17:33, Douglas Fischer <fischerdouglas at gmail.com>escreveu:
> Henrique,
> não discordo que o HOL possa fazer sentido para ambientes de grande porte,
> em casos onde os buffers de saída não deem conta de segurar pacotes afim de
> manter o ordenamento de pacotes.
>
> P.S.: Na verdade eu só ví isso em FC, principalmente em switchs meia boca
> onde depois de um agregation o enlace seguinte tenha algum
> oversubscription.
>
>
> Mas o que eu quis dizer é que se existe algum problema que só ocorra quando
> em LAG, em não em interface única... Talvez o problema não esteja no
> aggregation. Talvez o aggregation esteja apenas explicitando a existência
> desse problema.
> A mesma lógica vale para o Flow-control habilitado ou não.
>
>
> E se eu tivesse que apostar, eu atiraria no HP.
> Não escondo meus receios sobre MK, mas nesse caso o design do MK é menos
> problemático no que se refere a buffers.
> E cá entre nós, as ASICs dos switch não são famosas por sua performance. E
> me faltam dedos nas mãos para contar os casos que sei de problemas de LAG
> entre HP e outros vendors.
>
>
>
> Em 7 de maio de 2014 15:40, Henrique de Moraes Holschuh
> <hmh at hmh.eng.br>escreveu:
>
> > On Wed, 07 May 2014, Douglas Fischer wrote:
> > > Se o flow control tá complicando as coisas, é porque tem coisa errada.
> >
> > O problema de flow-control é o "head-of-line blocking". Se a switch for
> > meia-boca (não implementar mecanismos efetivos e eficientes para mitigar
> > isso), flow-control causa um verdadeiro inferno de perda de performance
> que
> > é difícil de identificar e de rastrear[1].
> >
> > http://en.wikipedia.org/wiki/Head-of-line_blocking
> >
> > > Desabilitando ele, o problema vai deixar de aparecer nele, para
> aparecer
> > em
> > > outro lugar, ou pior... Ser mascarado e aparecer no pior momento.
> >
> > Perda de pacote é muito mais fácil de rastrear e de entender que os
> > problemas causados/exarcebados pelo flow-control... Eu diria que
> habilitar
> > o flow-control pode mascarar problemas bem mais facilmente que a situação
> > inversa.
> >
> > [1] principalmente devido ao desconhecimento do assunto.
> >
> > --
> > "One disk to rule them all, One disk to find them. One disk to bring
> > them all and in the darkness grind them. In the Land of Redmond
> > where the shadows lie." -- The Silicon Valley Tarot
> > Henrique Holschuh
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
br,
Paulo Coimbra
More information about the gter
mailing list