[GTER] Baixo desempenho PTP 10 GB
willian pires
willian_pires at hotmail.com
Mon Oct 13 14:16:04 -03 2014
Desativa auto-negociação e flow control no huawei no allied também.
> Date: Fri, 3 Oct 2014 16:59:18 -0300
> From: erigler at gmail.com
> To: gter at eng.registro.br
> Subject: Re: [GTER] Baixo desempenho PTP 10 GB
>
> +1
>
> Em 3 de outubro de 2014 16:49, Lucas Willian Bocchi <lucas.bocchi at gmail.com>
> escreveu:
>
> > Tem algo de podre no reino da Dinamarca.
> >
> > Nunca vi isso, e olha que já mexi com equipamento tranqueira...
> >
> > Em 3 de outubro de 2014 16:37, Fábio - RJ Network
> > <fabio at rjnetwork.com.br> escreveu:
> > > Ué, interface 10GB só dá opção de setar 1GB?
> > >
> > >
> > > --
> > > Fábio R. Hernandes
> > > RJ Network - Tecnologia Integrada
> > > Fone: (17) 3211 4211
> > > www.rjnetwork.com.br
> > >
> > >
> > > 2014-10-03 10:22 GMT-03:00 Rafael Ramos <rafael.ramos at newtelecom.net.br
> > >:
> > >
> > >> Não fiz o teste em bancada =(
> > >>
> > >> Em 3 de outubro de 2014 00:00, Fernando Frediani <fhfrediani at gmail.com>
> > >> escreveu:
> > >>
> > >> > Ola Rafael,
> > >> > Dois pontos.
> > >> >
> > >> > 1 - Você chegou a fazer o teste de bancada com os switches ? Deu
> > 10Gbp/s
> > >> > tranqüilo ?
> > >> > 2 - Já cogitou convidar o pessoal da empresa de fibra para fazer o
> > teste
> > >> > de 10Gbp/s usando, se possível, switches deles invés de OTDR ou Power
> > >> Meter
> > >> > ?
> > >> >
> > >> > Por enquanto acho correta a sua suspeita a respeito dos switches.
> > >> >
> > >> > Fernando
> > >> >
> > >> >
> > >> > On 02/10/2014 21:07, Rafael Ramos wrote:
> > >> >
> > >> >> 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
> > >> >>>
> > >> >>>
> > >> >>
> > >> >>
> > >> > --
> > >> > 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
> > >>
> > > --
> > > 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
More information about the gter
mailing list