[GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
Bruno Vane
broonu at gmail.com
Mon Sep 23 16:17:18 -03 2019
Pessoal, o patch saiu.
Aplicamos e estamos testando.
Verifiquem com distribuidor de vocês.
Em sex, 13 de set de 2019 às 17:49, Otavio Augusto <otavioti at gmail.com>
escreveu:
> quando sair este patch avisa agente
>
> Em sex, 13 de set de 2019 às 17:06, Bruno Vane <broonu at gmail.com>
> escreveu:
> >
> > Pessoal,
> >
> > Desencavando um tópico antigo, mas acho que seja de interesse de outros
> > participantes, o suporte da Huawei na China identificou que era mesmo um
> > bug, e sairá um patch para corrigir o problema. Resumindo, em algum
> momento
> > o BRAS não aplicava corretamente o controle de banda quando o cliente se
> > conectava, era aplicada um car de 32k, mesmo mostrando tudo certo na
> sessão
> > (100Mbps), mostrando a banda aplicada.
> >
> > Em seg, 10 de jun de 2019 às 14:22, Bruno Vane <broonu at gmail.com>
> escreveu:
> >
> > > @Uesley, tanto faz, passando pela caixa ou coma destino à caixa. Dois
> > > clientes lado a lado, um pode ter o problema e o outro não.
> Reconectando,
> > > resolvia.
> > >
> > > Em qui, 6 de jun de 2019 às 11:49, Uesley Correa <
> uesleycorrea at gmail.com>
> > > escreveu:
> > >
> > >> Bom dia.
> > >>
> > >> A perda é passando pelo Huawei ou com destino ao Huawei? Se é com
> destino,
> > >> é bom lembrar que soluções assim (Huawei, Cisco, etc) contém proteção
> de
> > >> CPU conta flood de pacotes de entrada (ICMP, consultas arp, etc).
> Seria
> > >> bom
> > >> dar uma olhada para ver se não é esse o caso.
> > >>
> > >> Saudações,
> > >>
> > >> On Thu, Jun 6, 2019, 08:45 Willian Pires de Souza <
> > >> willian_pires at hotmail.com>
> > >> wrote:
> > >>
> > >> > Quem gera resposta de icmp é o processador do seu roteador você
> > >> > desabilitou IPv6 e teve um ganho ok. Mas o que você tem que levar em
> > >> > consideração.
> > >> > Desabilitar IPv6 não é uma alternativa exceto se você estiver
> > >> considerando
> > >> > que tem ipv4 de sobra, ninguém tem.
> > >> >
> > >> > Ganhar CPU é garantir que o processador certo está tratando o pacote
> > >> > correto.
> > >> >
> > >> > Meu ponto de vista:
> > >> > Garanta que os blocos roteados nessa caixa IPv6/4 tenham um null
> route,
> > >> > isso vai garantir que nenhum pacote sem um destino use o cpu seja
> para
> > >> te
> > >> > enviar um unreachable seja para re escanear a arp table em busca de
> um
> > >> > destino.
> > >> > Icmp rate limite, arp rate limit Sao alcançados depois de uma CPU em
> > >> uso.
> > >> >
> > >> > Garante via ACL que seja impossível que um cliente te envie um
> pacote
> > >> com
> > >> > origem diferente da esperada.
> > >> >
> > >> > Por último acompanhe os logs de rate limit ele vai te ajudar a ver
> que
> > >> > está te gerando problema.
> > >> >
> > >> > Abraço
> > >> >
> > >> > Get Outlook for Android<https://aka.ms/ghei36>
> > >> >
> > >> > ________________________________
> > >> > From: gter <gter-bounces at eng.registro.br> on behalf of Bruno Vane <
> > >> > broonu at gmail.com>
> > >> > Sent: Tuesday, June 4, 2019 1:32:13 PM
> > >> > To: Grupo de Trabalho de Engenharia e Operacao de Redes
> > >> > Subject: Re: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
> > >> >
> > >> > Mas eu perdia pacote IPv4 do cliente pingando para o próprio BRAS.
> > >> >
> > >> > Em seg, 3 de jun de 2019 às 17:04, Willian Pires de Souza <
> > >> > willian_pires at hotmail.com> escreveu:
> > >> >
> > >> > > Deve ser o mesmo motivo :D
> > >> > >
> > >> > > IPV6 sem ter para onde ir.
> > >> > >
> > >> > > O seu problema continua o mesmo, você só esta sem ele por mais um
> > >> tempo.
> > >> > > ________________________________
> > >> > > De: gter <gter-bounces at eng.registro.br> em nome de Bruno Vane <
> > >> > > broonu at gmail.com>
> > >> > > Enviado: sexta-feira, 31 de maio de 2019 10:17
> > >> > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> > >> > > Assunto: Re: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
> > >> > >
> > >> > > Nós desativamos o IPv6 para os clientes PPPoE e até então não
> tivemos
> > >> > mais
> > >> > > problemas.
> > >> > >
> > >> > > Em seg, 27 de mai de 2019 às 19:45, Willian Pires de Souza <
> > >> > > willian_pires at hotmail.com> escreveu:
> > >> > >
> > >> > > > Boa noite,
> > >> > > >
> > >> > > > Me parece que o seu problema é falta de null routing.
> > >> > > >
> > >> > > > Não sei qual o seu bloco ip, mas recomendo que você faça alguns
> > >> > > roteamentos
> > >> > > > marotos estáticos na sua caixa para prevenir destination
> > >> unreachable.
> > >> > > >
> > >> > > > Mass primeiro de tudo, se você tem ospf precisa fazer um
> filtro com
> > >> > oque
> > >> > > > o seu ospf vai
> > >> > > > exportar para evitar exportar rotas estáticas.
> > >> > > >
> > >> > > > Algo assim:
> > >> > > >
> > >> > > > seu bloco local: 201.50.1.0/22 estou pegando uma parte do seu
> /20
> > >> > > >
> > >> > > > ospf 1000 router-id 10.254.100.254
> > >> > > > import-route direct cost 11 type 1
> > >> > > > import-route static cost 11 type 1 route-policy NO_EXPORT_NULL
> > >> > > >
> > >> > > >
> > >> > > > #
> > >> > > > route-policy NO_EXPORT_NULL deny node 10
> > >> > > > if-match ip address prefix-list FULL_NETS
> > >> > > > #
> > >> > > >
> > >> > > > ip prefix-list FULL_NETS index 10 permit 169.254.0.0 16
> > >> > > > ip prefix-list FULL_NETS index 20 permit 172.16.0.0 12
> > >> > > > ip prefix-list FULL_NETS index 30 permit 192.168.0.0 16
> > >> > > > ip prefix-list FULL_NETS index 40 permit 10.0.0.0 8
> > >> > > > ip prefix-list FULL_NETS index 50 permit 100.64.0.0 10
> > >> > > > ip prefix-list FULL_NETS index 60 permit 201.50.1.0 22
> > >> > > >
> > >> > > >
> > >> > > > E por fim adicionar essas rotas para NULL
> > >> > > > ip route-static 10.0.0.0 8 NULL0
> > >> > > > ip route-static 169.254.0.0 16 NULL0
> > >> > > > ip route-static 172.16.0.0 12 NULL0
> > >> > > > ip route-static 192.168.0.0 16 NULL0
> > >> > > > ip route-static 100.64.0.0 10 NULL0
> > >> > > > ip route-static 201.50.1.0 22 NULL 0
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> --------------------------------------------------------------------------------------------------------------------------------------
> > >> > > >
> > >> > > > Qual a explicação por trás disso, que pegamos aqui.
> > >> > > > Muitos clientes acabam solicitando pacotes de redes RFC1918 como
> > >> > destino,
> > >> > > > e isso vai para a querida
> > >> > > > cpu do router, assim como pacotes indo para a sua rede no caso
> /22
> > >> que
> > >> > > > ainda não foi alocado, e isso explica,
> > >> > > > a quantidade de destination unreachable.
> > >> > > >
> > >> > > > A interface que de base que você usa como pppoe pode conter acl
> de
> > >> > > entrada
> > >> > > > e saída bem restritiva, para esses
> > >> > > > alvos e isso é controlado pelo ASIC e não sobe para o CPU do
> router.
> > >> > > >
> > >> > > > Se quiser detalhar, manda a sua configuração base ai que a
> gente da
> > >> uma
> > >> > > > força.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > ________________________________
> > >> > > > De: gter <gter-bounces at eng.registro.br> em nome de Bruno Vane <
> > >> > > > broonu at gmail.com>
> > >> > > > Enviado: segunda-feira, 27 de maio de 2019 10:32
> > >> > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> > >> > > > Assunto: Re: [GTER] Perda de pacotes aleatória em Huawei
> NE20E-S2F
> > >> > > >
> > >> > > > Bom dia Willian,
> > >> > > >
> > >> > > > Segue:
> > >> > > >
> > >> > > >
> > >> > > > <BRAS4-SOVR>display icmp statistics
> > >> > > > Input: bad formats 0 bad checksum
> 0
> > >> > > > echo 14734 destination unreachable
> > >> 232
> > >> > > > source quench 0 redirects
> 0
> > >> > > > echo reply 0 parameter problem
> 0
> > >> > > > timestamp request 0 information request
> 0
> > >> > > > mask requests 0 mask replies
> 0
> > >> > > > time exceeded 76 timestamp reply
> 0
> > >> > > > Mping request 0 Mping reply
> 0
> > >> > > > Output: echo 14 destination unreachable
> > >> > 1770294
> > >> > > > source quench 0 redirects
> 0
> > >> > > > echo reply 14734 parameter problem
> 0
> > >> > > > timestamp request 0 information reply
> 0
> > >> > > > mask requests 0 mask replies
> 0
> > >> > > > time exceeded 1217331 timestamp reply
> 0
> > >> > > > Mping request 0 Mping reply
> 0
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>display ip routing-table statistics
> > >> > > > Summary Prefixes : 18773
> > >> > > > Proto total active added deleted freed
> > >> > > > routes routes routes routes routes
> > >> > > > DIRECT 14 14 14 0 0
> > >> > > > STATIC 0 0 0 0 0
> > >> > > > RIP 0 0 0 0 0
> > >> > > > OSPF 0 0 0 0 0
> > >> > > > IS-IS 0 0 0 0 0
> > >> > > > BGP 6712 6711 13512 6800 6800
> > >> > > > UNR 12048 12048 49059 37011 37011
> > >> > > > Total 18774 18773 62585 43811 43811
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>display cpu-usage service
> > >> > > > Cpu utilization statistics at 2019-05-27 10:30:54 855 ms
> > >> > > > System cpu use rate is : 24%
> > >> > > > ---------------------------
> > >> > > > ServiceName UseRate
> > >> > > > ---------------------------
> > >> > > > SYSTEM 20%
> > >> > > > BRAS 2%
> > >> > > > FEA 2%
> > >> > > > AAA 0%
> > >> > > > ARP 0%
> > >> > > > BGP 0%
> > >> > > > CMF 0%
> > >> > > > CSP 0%
> > >> > > > DEVICE 0%
> > >> > > > DHCP 0%
> > >> > > > ETRUNK 0%
> > >> > > > EUM 0%
> > >> > > > FEC 0%
> > >> > > > FIBRESM 0%
> > >> > > > IFM 0%
> > >> > > > IP STACK 0%
> > >> > > > LDT 0%
> > >> > > > LINK 0%
> > >> > > > LOCAL PKT 0%
> > >> > > > MFLP 0%
> > >> > > > MSTP 0%
> > >> > > > ND 0%
> > >> > > > NETSTREAM 0%
> > >> > > > OAM 0%
> > >> > > > PKI 0%
> > >> > > > PNP 0%
> > >> > > > PTPA 0%
> > >> > > > RBS 0%
> > >> > > > RGM 0%
> > >> > > > RM 0%
> > >> > > > SLA 0%
> > >> > > > SMLK 0%
> > >> > > > SOC 0%
> > >> > > > SVRO 0%
> > >> > > > TNLM 0%
> > >> > > > TUNNEL 0%
> > >> > > > VLAN 0%
> > >> > > > ---------------------------
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>
> > >> > > > <BRAS4-SOVR>display logbuffer | in cpu-defend
> > >> > > > Info: It will take a long time if the content you search is too
> > >> much or
> > >> > > the
> > >> > > > string you input is too long, you can press CTRL_C to break.
> > >> > > > Logging buffer configuration and contents : enabled
> > >> > > > Allowed max buffer size : 10240
> > >> > > > Actual buffer size : 512
> > >> > > > Channel number : 4 , Channel name : logbuffer
> > >> > > > Dropped messages : 0
> > >> > > > Overwritten messages : 0
> > >> > > > Current messages : 333
> > >> > > >
> > >> > > > May 26 2019 12:20:17-03:00 BRAS4-SOVR
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> %%01CPUDEFEND/4/hwXQoSCpDefendDiscardedPacketAlarm_clear(l):CID=0x807f047d-alarmID=0x0c150009-clearType=service_resume;Security
> > >> > > > cpu-defend drop packets alarm cleared. (ChassisID=1, SlotID=3,
> > >> > > > ObjectIndex=40, DiscardedPackets=927569,
> DiscardedThreshold=30000,
> > >> > > > ProtocolDescription=IPV4_MTU_EXCEED, Reason=The discarded rate
> for
> > >> > > packets
> > >> > > > destined to CPU exceeded alarm threshold.)
> > >> > > > May 26 2019 01:31:13-03:00 BRAS4-SOVR
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> %%01CPUDEFEND/4/hwXQoSCpDefendDiscardedPacketAlarm_active(l):CID=0x807f047d-alarmID=0x0c150009;Security
> > >> > > > cpu-defend drop packets alarmed. (ChassisID=1, SlotID=3,
> > >> > ObjectIndex=40,
> > >> > > > DiscardedPackets=927569, DiscardedThreshold=30000,
> > >> > > > ProtocolDescription=IPV4_MTU_EXCEED, Reason=The discarded rate
> for
> > >> > > packets
> > >> > > > destined to CPU exceeded alarm threshold.)
> > >> > > > <BRAS4-SOVR>
> > >> > > >
> > >> > > >
> > >> > > > Em sáb, 25 de mai de 2019 às 19:56, Willian Pires de Souza <
> > >> > > > willian_pires at hotmail.com> escreveu:
> > >> > > >
> > >> > > > > Envie os seguintes comandos:
> > >> > > > >
> > >> > > > > [~SBRSPO17IR04HH20E]display icmp statistics
> > >> > > > > Input: bad format 0 bad checksum
> > >> 43
> > >> > > > > echo 5 destination
> unreachable
> > >> > 24005
> > >> > > > > source quench 0 redirects
> > >> 4
> > >> > > > > echo reply 581888 parameter problem
> > >> 0
> > >> > > > > timestamp request 16 information request
> > >> 0
> > >> > > > > mask requests 0 mask replies
> > >> 0
> > >> > > > > time exceeded 59220 timestamp reply
> > >> 0
> > >> > > > > Mping request 0 Mping reply
> > >> 0
> > >> > > > >
> > >> > > > > Output: echo 584753 destination
> unreachable
> > >> > > 321149
> > >> > > > > source quench 0 redirects
> > >> 0
> > >> > > > > echo reply 5 parameter problem
> > >> 0
> > >> > > > > timestamp request 0 information reply
> > >> 0
> > >> > > > > mask requests 0 mask replies
> > >> 0
> > >> > > > > time exceeded 638654717 timestamp reply
> > >> 15
> > >> > > > > Mping request 0 Mping reply
> > >> 0
> > >> > > > >
> > >> > > > >
> > >> > > > > [~SBRSPO17IR04HH20E]display ip routing-table statistics
> > >> > > > > Summary Prefixes : 772374
> > >> > > > > Proto total active added deleted freed
> > >> > > > > routes routes routes routes routes
> > >> > > > > DIRECT 43 43 52 9 9
> > >> > > > > STATIC 8 8 34 26 26
> > >> > > > > RIP 0 0 0 0 0
> > >> > > > > OSPF 1 0 1 0 0
> > >> > > > > IS-IS 0 0 0 0 0
> > >> > > > > BGP 772324 772323 41438651 40666327
> 40666327
> > >> > > > > Total 772376 772374 41438738 40666362
> 40666362
> > >> > > > >
> > >> > > > >
> > >> > > > > [~SBRSPO17IR04HH20E]display cpu-usage service
> > >> > > > > Cpu utilization statistics at 2019-05-25 17:10:58 858 ms
> > >> > > > > System cpu use rate is : 18%
> > >> > > > > ---------------------------
> > >> > > > > ServiceName UseRate
> > >> > > > > ---------------------------
> > >> > > > > FEA 15%
> > >> > > > > CMF 2%
> > >> > > > > SYSTEM 1%
> > >> > > > > AAA 0%
> > >> > > > > ARP 0%
> > >> > > > > BGP 0%
> > >> > > > > CSP 0%
> > >> > > > > DEVICE 0%
> > >> > > > > DHCP 0%
> > >> > > > > DNS 0%
> > >> > > > > ETRUNK 0%
> > >> > > > > EUM 0%
> > >> > > > > FEC 0%
> > >> > > > > FIBRESM 0%
> > >> > > > > IFM 0%
> > >> > > > > IP STACK 0%
> > >> > > > > LINK 0%
> > >> > > > > LOCAL PKT 0%
> > >> > > > > MFLP 0%
> > >> > > > > MSTP 0%
> > >> > > > > ND 0%
> > >> > > > > NETSTREAM 0%
> > >> > > > > OAM 0%
> > >> > > > > OSPF 0%
> > >> > > > > PNP 0%
> > >> > > > > PTPA 0%
> > >> > > > > RBS 0%
> > >> > > > > RGM 0%
> > >> > > > > RM 0%
> > >> > > > > SLA 0%
> > >> > > > > SMLK 0%
> > >> > > > > SOC 0%
> > >> > > > > SVRO 0%
> > >> > > > > TNLM 0%
> > >> > > > > VLAN 0%
> > >> > > > > TUNNEL 0%
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > display logbuffer | in cpu-defend
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > ________________________________
> > >> > > > > De: gter <gter-bounces at eng.registro.br> em nome de Bruno
> Vane <
> > >> > > > > broonu at gmail.com>
> > >> > > > > Enviado: quinta-feira, 23 de maio de 2019 17:33
> > >> > > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> > >> > > > > Assunto: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
> > >> > > > >
> > >> > > > > Pessoal,
> > >> > > > >
> > >> > > > > Estamos com alguns BRAS Huawei aqui e um deles está
> apresentando
> > >> um
> > >> > > > > problema bem estranho. É um NE20E-S2F Version 8.180 (NE20E
> > >> > > > > V800R010C10SPC500), com patch V800R010SPH035 aplicado.
> > >> > > > >
> > >> > > > > O problema é totalmente (aparentemente) aleatório, um cliente
> > >> PPPoE
> > >> > que
> > >> > > > > está funcionando normalmente de repente para de funcionar, o
> ping
> > >> do
> > >> > > > > cliente para o próprio BRAS fica com uns 70% de perda,
> navegação
> > >> web
> > >> > ou
> > >> > > > > qualquer outro serviço fica impraticável. Isso surge em
> horários
> > >> > > > aleatórios
> > >> > > > > do dia, com uma quantidade de clientes aleatória, não afeta
> todos
> > >> os
> > >> > > > > clientes. Se eu desconectar e reconectar, resolve. Pode ser
> que
> > >> > resolva
> > >> > > > em
> > >> > > > > definitivo bem como pode acontecer de novo, com esse mesmo
> > >> cliente.
> > >> > > > > Acontece tanto em IPv4 e IPv6, e somente com PPPoE, um
> cliente L3
> > >> não
> > >> > > > > apresenta essa perda.
> > >> > > > >
> > >> > > > > Alguém já passou por algum problema parecido?
> > >> > > > >
> > >> > > > > Esse BRAS está com 21 mil clientes, tenho outro que não está
> dando
> > >> > > > > problema, mas versão mais antiga.
> > >> > > > > --
> > >> > > > > gter list
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
> > >> > > > > --
> > >> > > > > gter list
> > >> > > >
> > >> > >
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
> > >> > > > >
> > >> > > > --
> > >> > > > gter list
> > >> > > >
> > >> > >
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
> > >> > > > --
> > >> > > > gter list
> > >> > >
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
> > >> > > >
> > >> > > --
> > >> > > gter list
> > >> > >
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603232027&sdata=Dq%2FyI%2BNyVHzm76FtDXs0j98GobW%2FIsVa%2Fe%2BdqY3ROU8%3D&reserved=0
> > >> > > --
> > >> > > gter list
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603232027&sdata=Dq%2FyI%2BNyVHzm76FtDXs0j98GobW%2FIsVa%2Fe%2BdqY3ROU8%3D&reserved=0
> > >> > >
> > >> > --
> > >> > gter list
> > >> >
> > >>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603232027&sdata=Dq%2FyI%2BNyVHzm76FtDXs0j98GobW%2FIsVa%2Fe%2BdqY3ROU8%3D&reserved=0
> > >> > --
> > >> > 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
>
>
>
> --
> Otavio Augusto
> ---------------------
> Consultor de TI
> echo fkrmzfkz.xdrzc*tfd | tr a-z.* j-za-i at .
> http://www.citiustecnologia.com.br
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list