[GTER] Baixo desempenho PTP 10 GB

Fábio - RJ Network fabio at rjnetwork.com.br
Fri Oct 3 16:37:41 -03 2014


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
>



More information about the gter mailing list