[GTER] Baixo desempenho PTP 10 GB
Lucas Willian Bocchi
lucas.bocchi at gmail.com
Fri Oct 3 16:49:21 -03 2014
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
More information about the gter
mailing list