[GTER] Baixo desempenho PTP 10 GB
Rafael Ramos
rafael.ramos at newtelecom.net.br
Fri Oct 3 10:22:48 -03 2014
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
More information about the gter
mailing list