[GTER] RES: RX Pause em GE CCR1036 vs. 3c2920.
Shine
eshine at gmail.com
Thu May 8 21:01:07 -03 2014
Paulo,
Isso explica o comportamento. Quando um pacote mostra um erro de CRC ele é
imediatamente descartado e há uma retransmissão. Possivelmente os buffers
do switch não são grandes o suficiente para comportar a carga de
retransmissão (até pq isso pode gerar mais erros e retransmissões) e no
final ele pede pauses.
Vejo que a conexão é de longa distância, então seria interessante que
fossem repassados os níveis de sinal nessa porta (se ele tiver DOM), rever
o circuito ótico, considerar problemas na porta, adaptador ótico...
Particularmente acho que flow control não te ajuda neste modelo de conexão,
sugiro que você desabilite ele em todos os equipamentos e controle somente
os erros (que não irão sumir quando você desabilitar o flow, claro...).
Talvez você não observe efeitos nas aplicações dos clientes, mas com
certeza você tem um comportamento errático do circuito físico e não está
usando essa conexão com a melhor eficiência.
Em 8 de maio de 2014 12:23, Paulo Coimbra <coimbra.root at gmail.com> escreveu:
> 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
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list