[GTER] Baixo desempenho PTP 10 GB

Shine eshine at gmail.com
Fri Oct 3 02:36:31 -03 2014 

Não sou especialista em Huawei, mas não está estranho esse line protocol
state???
===
-RB01>dis interface GigabitEthernet 8/0/1
GigabitEthernet8/0/1 current state : UP
Line protocol current state : *DOWN*
Description:HUAWEI, Quidway Series, GigabitEthernet8/0/1 Interface
===

Se puder fazer um mirror no switch e capturar alguns pacotes, quem sabe
isso não te dá uma pista?
Tente também limpar os contadores, o Quidway tem muito mais frames que o
Allied, fica difícil saber se é porque perdeu/descartou ou porque um foi
limpo antes/rebootado.
Interessante que o Allied está configurado com Jumbo, mas não vi nenhuma
estatística de Jumbo nele. Talvez fazer testes específicos com frames de
tamanhos fixos para ver alguma relação de performance/tamanho_frame?





Em 2 de outubro de 2014 17:07, Rafael Ramos <rafael.ramos at newtelecom.net.br>
escreveu:

> Olá Pessoal, desculpe a demora para a resposta:
>
> Verificamos junto ao pessoal de fibra com OTDR e Power Meter.
>
> A fibra está 100% não tendo nenhum degral nos testes com OTDR, realizamos
> teste com potencia em ambas as fibras TX e RX ambas em 1.2 Km chegaram a
> potencia de -6,78 TX -6.93 RX. Os Conectores são azuis SC/LC e LC/LC em
> seus DIO estão com todos polimentos idênticos inclusive as SFPs usam o
> mesmo polimento.
>
> Fiz um teste colocando uma SFP de 1GB para verificar o CRC e estáva zerado
> em testes o desempenho foi o mesmo. =(
>
> Retornei a SFP de 10GB em outra porta os CRC sumiram porem o desempenho
> continua o mesmo.
>
>
> Estou desconfiado que possa ser algo de incompatibilidade entres os
> Switch´s
>
> Na Ponta A o Switch Allied está Taggeando 3 vlans que utilizamos.
>
> Ponta B o Huawei usa o Dot1q vlan sobre subinterface.
>
> Segue abaixo as estatisticas de porta:
>
> Ponta A:
>
> -HOS# sh interface 26
>   ifIndex.............................. 26
>   ifMtu................................ 9198
>   ifSpeed.............................. 0
>   ifAdminStatus........................ Up
>   ifOperStatus......................... Up
>   ifLinkUpDownTrapEnable............... Enabled
>
>
> -HOS# sh switch port=26 counter
>
> Port Statistics:
>
> Port: 26
>
> Bytes Rx ......... 3661499042          Bytes Tx ......... 4082136176
> Frames Rx ........ 21423291            Frames Tx ........ 24740329
> Bcast Frames Rx .. 70083               Bcast Frames Tx .. 65
> Mcast Frames Rx .. 0                   Mcast Frames Tx .. 301002
> Frames 64 ........ 3241411             Frames 65-127 .... 33494608
> Frames 128-255 ... 6116422             Frames 256-511 ... 611079
> Frames 512-1023 .. 433666              Frames 1024-1518 . 673153
> CRC Error ........ 0                   Jabber ........... 0
>
> No. of Rx Errors . 0                   No. of Tx Errors . 0
> UnderSize Frames . 0                   OverSize Frames .. 0
> Fragments ........ 0                   Collision ........ 0
> Frames 1519-1522 . 1593281             Dropped Frames ... 69335
>
> X-HOS# show Switch port=26
>
> Port #26 Information:
>
>  Port Description (ifName) ............ Port_26
>  Port Type ............................ XFP
>  Status ............................... Enabled
>  Link State ........................... Up
>  Configured Speed/Duplex .............. Auto
>  Configured MDI Crossover ............. N/A
>  Actual Speed/Duplex .................. 10000 Mbps/Full Duplex
>  Actual MDI Crossover ................. N/A
>  Flow Control Status .................. Disabled
>  Flow Control Threshold ............... 7935 cells
>  Backpressure Status .................. Disabled
>
>  Backpressure Threshold ............... 7935 cells
>  HOL Blocking Prevention Threshold .... 682 cells
>  Broadcast Ingress Filtering .......... Disabled
>  Broadcast Egress Filtering ........... Disabled
>  Unknown Multicast Ingress Filtering .. Disabled
>  Unknown Multicast Egress Filtering ... Disabled
>  Unknown Unicast Ingress Filtering .... Disabled
>  Unknown Unicast Egress Filtering ..... Disabled
>  Broadcast Rate Limiting Status ....... Disabled
>  Broadcast Rate ....................... 262143 packet/960 uSecond
>  Multicast Rate Limiting Status ....... Disabled
>  Multicast Rate ....................... 262143 packet/960 uSecond
>  Unknown Unicast Rate Limiting Status . Disabled
>  Unknown Unicast Rate ................. 262143 packet/960 uSecond
>  XFP #6 ............................... Present
>
>
>  XFP #6 information:
>   Tranceiver Identifier ......................... XFP
>   Connector Type ................................ LC
>   Encoding Algorithm ............................ NRZ/SONET
> Scr/8B10B/64B66B
>   Minimum Bit Rate .............................. 9900M Bits/sec
>   Maximum Bit Rate .............................. 11300M Bits/sec
>   Link Length Supported For SMF Fiber ........... 10km
>   Link Length Supported For EBW 50/125 um Fiber . 0m
>   Link Length Supported For 50/125 um Fiber ..... 0m
>
>  PVID ................................. 4092
>  Port Priority (0-7) 0=Low 7=High...... 0
>  Override Priority .................... No
>  Mirroring State....................... Disabled
>
>
> Ponta B:
>
>
> -RB01>dis interface GigabitEthernet 8/0/1
> GigabitEthernet8/0/1 current state : UP
> Line protocol current state : DOWN
> Description:HUAWEI, Quidway Series, GigabitEthernet8/0/1 Interface
> Route Port,The Maximum Transmit Unit is 1500
> Internet protocol processing : disabled
> IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
> e024-7f95-6234
> The Vendor Name is FINISAR CORP.   , The Vendor PN is FTLX1412M3BCL
> Transceiver max BW: 9900~11300Mbps, Transceiver Mode: Single Mode
> WaveLength: 1310nm, Transmission Distance: 10km
> Rx Optical Power: -3.54dBm, normal range: [-18.01,  2.00]dBm
> Tx Optical Power: -2.26dBm, normal range: [-6.00,  1.00]dBm
> Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and
> Send D
>                    isable
> Last physical up time   : 2014-10-01 16:56:41 UTC-03:00
> Last physical down time : 2014-10-01 16:56:39 UTC-03:00
> Current system time: 2014-10-02 17:02:25-03:00
> Statistics last cleared:never
>     Last 300 seconds input rate: 27512 bits/sec, 31 packets/sec
>     Last 300 seconds output rate: 16600 bits/sec, 26 packets/sec
>     Input: 590833215 bytes, 3785764 packets
>     Output: 388962336 bytes, 3234261 packets
>     Input:
>       Unicast: 3742389 packets, Multicast: 43372 packets
>       Broadcast: 3 packets, JumboOctets: 116201 packets
>       CRC: 0 packets, Symbol: 0 packets
>       Overrun: 0 packets, InRangeLength: 0 packets
>       LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
>       Fragment: 0 packets, Undersized Frame: 0 packets
>       RxPause: 0 packets
>     Output:
>       Unicast: 3234188 packets, Multicast: 0 packets
>       Broadcast: 73 packets, JumboOctets: 28594 packets
>       Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
>       System: 0 packets, Overrun: 0 packets
>       TxPause: 0 packets
>     Input bandwidth utilization  :    0%
>     Output bandwidth utilization :    0%
>
>
>
>
> Em 1 de outubro de 2014 18:41, Shine <eshine at gmail.com> escreveu:
>
> > Quando falamos de polimento ((PC, UPC, SPC, APC), precisa ver qual o
> > polimento usado no transceiver (neste caso os Finisar) e usar o polimento
> > adequado para ele. Geralmente os transceivers de 10GE usam polimento SPC
> ou
> > UPC. Portanto usar cabo azul é correto, principalmente se for UPC, embora
> > tenha maior perda por reflexão. Usar conectores com polimento APC irá
> > diminuir a perda por reflexão, mas a perda de sinal será maior ainda.
> >
> > Recomendo isolar inicialmente indícios que indiquem um problema físico
> > antes de tentar fechar o diagnóstico (deram uma boa dica de usar DOM se
> > houver essa possibilidade). Laboratório simulando o ambiente também
> ajudará
> > a ter uma leitura do comportamento nos equipamentos e interfaces
> > envolvidas, é fácil atenuar o sinal ótico para simular a perda no
> ambiente
> > (não considero uma situação de perda por dispersão cromática, isso não
> deve
> > ocorrer em uma conexão de apenas 1 km).
> >
> > Em 1 de outubro de 2014 17:06, Carlos Ribeiro <cribeiro at telbrax.com.br>
> > escreveu:
> >
> > > Só para a acertar as definições e facilitar a compra: o conector "azul"
> > é a
> > > especificação "PC", que indica que o contato físico é com alinhamento
> > > direto dos núcleos das fibras. O conector "verde" é a especificação
> > "APC",
> > > que indica contato com um pequeno ângulo que reduz a reflexão direta do
> > > sinal.
> > >
> > > Então, na hora de cotar, use os conectores APC para aplicações mais
> > > críticas. Mas sempre use a combinação adequada para sua instalação...
> > >
> > > *Carlos Ribeiro*
> > > *Sócio*
> > > Cel: +55 (31) 9303-3366
> > > Tel: +55 (31) 3305-5620
> > > Geral: +55 (31) 3305-5600
> > > cribeiro at telbrax.com.br
> > > www.telbrax.com.br
> > >
> > > Em 1 de outubro de 2014 11:33, Antonio Carlos Sanches <
> > > asanches at omni.net.br>
> > > escreveu:
> > >
> > > > Em redes de 10 GB nao gosto de usar os conectores azuis, eles tem um
> > > indice
> > > > muito grande de reflexao, ainda mais em uma curta distancia como a
> > sua. O
> > > > ideal , no meu entendimento, seria o de cor verde, que reduz muito
> esse
> > > > problema de reflexao.
> > > > Olá Rafael,
> > > >
> > > > Eu concordo com o Marcelo, o teste inicial em bancada pode ajudar
> para
> > > > estabelecer a referência.
> > > >
> > > > Com relação ao cabeamento óptico, possivelmente os seus transceivers
> > > > suportam ddmi (Digital Diagnostic Monitoring Interface), o que
> > > > dependendo do equipamento de rede pode te passar informações ópticas.
> > > >
> > > > No PTT Forúm 7 foi feita a apresentação abaixo que aborda o ddmi e
> > > > também a utilização de recursos de medições ópticas, como power
> meter:
> > > >
> > > > PTT.br - Fibras Ópticas - Abordagem Operacional
> > > >
> > >
> >
> http://ptt.br/pttforum/7/doc/PTT.br-7PTTForum_Fibras_opticas.20131203.pdf
> > > >
> > > > Com relação ao teste de 10Gbps para a validação com tráfego real, se
> > > > você tiver servidores com placas de 10GE, basta utilizar qualquer
> > > > distribuição GNU/Linux, com apache de um lado e um único wget do
> outro
> > > > que você consegue atingir a capacidade do link.
> > > >
> > > > Por exemplo, no laboratório do PTT.br temos hoje um servidor Dell
> R620
> > > > com uma placa Intel integrada com 2 portas 10GE. Utilizamos nele
> > > > Ubuntu com virtualização no kernel (kvm) e duas máquinas virtuais
> > > > também com Ubuntu, cada máquina associada a uma placa de rede 10GE.
> > > > Com essa estrutura geramos tráfego de 10Gbps entre as máquinas
> > > > virtuais com Apache e wget.
> > > >
> > > > Caso você não disponha de servidores com placas de 10GE não há
> > > > problema, pois você pode utilizar servidores com placas de 1GE e
> > > > amplificar o tráfego.
> > > >
> > > > Segue uma solução simples de amplificação de tráfego que
> desenvolvemos
> > > > e ainda utilizamos hoje, só que com servidores com placas de 10GE
> para
> > > > validar enlaces de 100GE:
> > > >
> > > > LACNIC XV – NAPLA 2011
> > > > Traffic Amplification Model for Network Infrastructure Stress
> > > >
> > > >
> > >
> >
> http://lacnic.net/documentos/lacnicxv/napla/10a%20lacnicxv-napla-stress-banda.pdf
> > > >
> > > > Abraços,
> > > >
> > > > Eduardo Ascenço Reis
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> * Rafael Nascimento Ramos*
>
>  Diretor de Tecnologia
>
> Av. Cel Sezefredo Fagundes, 2699 – sl 2, Tucuruvi
> São Paulo, SP – Brasil, CEP:02306-003.
>
> +55 11 2267 6787
> +55 11 9 9333-1359 (mobile)
>
> e-mail: rafael.ramos at newtelecom.net.br
>
> http://www.newtelecom.net.br
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list