[GTER] Baixo desempenho PTP 10 GB
Rafael Ramos
rafael.ramos at newtelecom.net.br
Fri Oct 3 10:22:08 -03 2014
O Line Protocol Current State: Down , é porque estou usando subinterfaces
exemple Gigabitethernet 8/0/1.200 ou seja o 200 é a subinterface que
corresponde a vlan dot1q 200
Em 3 de outubro de 2014 02:36, Shine <eshine at gmail.com> escreveu:
> 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
> >
> --
> 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