[GTER] Problema Ativação PTT

Wed Sep 11 18:08:33 -03 2013

Ja tive problema semelhante com a operadora que me fornece transporte até o
PTT-SP e era problema de MTU pois fizeram Q-in-Q pra mim. VEja se a Algar
não está aprontando algo e seu MTU está ruim.
No meu caso também funcionou por algumas boas horas e depois ficou muito
ruim.

Em 11 de setembro de 2013 10:17, Pedro NOC <
pedro.siqueira at friistelecom.com.br> escreveu:

> Segue abaixo a interface do ATMv4, só recebo arp request.
>
>
> --- monitor traffic interface ge-1/0/9.3611
>
> verbose output suppressed, use <detail> or <extensive> for full protocol
> decode
> Address resolution is ON. Use <no-resolve> to avoid any reverse lookup
> delay.
> Address resolution timeout is 4s.
> Listening on ge-1/0/9.3611, capture size 96 bytes
>
> 08:07:43.183514  In arp who-has as262801.sp.ptt.br tell as12989.sp.ptt.br
> 08:07:43.185517  In arp who-has as28206-s2.sp.ptt.br tell
> as53114.sp.ptt.br
> 08:07:43.241305  In arp who-has as12136.sp.ptt.br tell as16736.sp.ptt.br
> 08:07:43.250217  In arp who-has as31529.sp.ptt.br tell as22381.sp.ptt.br
> 08:07:43.260853  In arp who-has as28279.sp.ptt.br tell as28331.sp.ptt.br
> 08:07:43.262265  In arp who-has as28254.sp.ptt.br tell as53059.sp.ptt.br
> 08:07:43.263508  In arp who-has as53099.sp.ptt.br tell as52828.sp.ptt.br
> Reverse lookup for 187.16.216.191 failed (check DNS reachability).
> Other reverse lookup failures will not be reported.
> Use <no-resolve> to avoid reverse lookups on IP addresses.
>
> 08:07:43.266312  In arp who-has 187.16.216.191 tell as262664.sp.ptt.br
> 08:07:43.269251  In arp who-has as53216.sp.ptt.br tell as12989.sp.ptt.br
> 08:07:43.275065  In arp who-has as262777.sp.ptt.br tell as53053.sp.ptt.br
> 08:07:43.275075  In arp who-has as262777.sp.ptt.br tell as53053.sp.ptt.br
> 08:07:43.275083  In arp who-has as28267.sp.ptt.br tell as262581.sp.ptt.br
> 08:07:43.287974  In arp who-has as28204.sp.ptt.br tell as53059.sp.ptt.br
> 08:07:43.293312  In arp who-has as53008-s2.sp.ptt.br tell
> as262750.sp.ptt.br
> 08:07:43.301485  In arp who-has as28280.sp.ptt.br tell as52850.sp.ptt.br
> 08:07:43.303241  In arp who-has as52971.sp.ptt.br tell as28153.sp.ptt.br
> 08:07:43.327579  In arp who-has as16397-s1.sp.ptt.br tell
> as263015.sp.ptt.br
> 08:07:43.327590  In arp who-has as16397-s1.sp.ptt.br tell
> as263015.sp.ptt.br
> 08:07:43.335278  In arp who-has as27715.sp.ptt.br tell as53114.sp.ptt.br
> 08:07:43.336194  In arp who-has as28191.sp.ptt.br tell as52909.sp.ptt.br
> 08:07:43.337080  In arp who-has as28654.sp.ptt.br tell as262444.sp.ptt.br
> 08:07:43.338175  In arp who-has as28651.sp.ptt.br tell as262785.sp.ptt.br
> 08:07:43.340269  In arp who-has as262476.sp.ptt.br tell
> as52888-s1.sp.ptt.br
> 08:07:43.348498  In arp who-has 187.16.217.62 tell as262405.sp.ptt.br
> 08:07:43.351235  In arp who-has as262518.sp.ptt.br tell 187.16.218.11
> 08:07:43.383322  In arp who-has as262324.sp.ptt.br tell as12989.sp.ptt.br
> 08:07:43.383777  In arp who-has as263080.sp.ptt.br tell 187.16.218.19
> 08:07:43.383786  In arp who-has as263080.sp.ptt.br tell 187.16.218.19
> 08:07:43.391163  In arp who-has as28666.sp.ptt.br tell as53222.sp.ptt.br
> 08:07:43.391643  In arp who-has as27724.sp.ptt.br tell as262750.sp.ptt.br
> 08:07:43.407863 Out arp who-has rs2.sp.ptt.br tell as53131.sp.ptt.br
>
>
> ----Abaixo o v6.
>
> monitor traffic interface ge-1/0/9.3612
>
> verbose output suppressed, use <detail> or <extensive> for full protocol
> decode
> Address resolution is ON. Use <no-resolve> to avoid any reverse lookup
> delay.
> Address resolution timeout is 4s.
> Listening on ge-1/0/9.3612, capture size 96 bytes
>
> Reverse lookup for fe80::d6ca:6dff:fe45:ec failed (check DNS reachability).
> Other reverse lookup failures will not be reported.
> Use <no-resolve> to avoid reverse lookups on IP addresses.
>
> 08:11:09.617484  In IP6 fe80::d6ca:6dff:fe45:ec > ff02::1:ff45:ec: HBH
> ICMP6, multicast listener report , length 24
> 08:11:09.720653  In IP6 fe80::211:93ff:fed4:721b > ff02::1:ffd4:721b: HBH
> ICMP6, multicast listener report , length 24
> 08:11:09.729444  In IP6 fe80::215:faff:fe76:ab60 > ff02::1:ff00:1: ICMP6,
> neighbor solicitation, who has as22548.sp.ptt.br, length 32
> 08:11:10.460384 Out IP6 truncated-ip6 - 22 bytes missing!2001:12f8::217:158
> > ff02::1:ff00:254: ICMP6, neighbor solicitation[|icmp6]
> 08:11:11.461513 Out IP6 truncated-ip6 - 22 bytes missing!2001:12f8::217:158
> > ff02::1:ff00:254: ICMP6, neighbor solicitation[|icmp6]
> 08:11:12.458084  In IP6 fe80::21b:cff:fe1e:e01a > ff02::1: ICMP6, router
> advertisement, length 64
> 08:11:12.462383 Out IP6 truncated-ip6 - 22 bytes missing!2001:12f8::217:158
> > ff02::1:ff00:254: ICMP6, neighbor solicitation[|icmp6]
> 08:11:14.464391 Out IP6 truncated-ip6 - 22 bytes
> missing!fe80::5e5e:ab0e:1cdb:5f69 > ff02::1:ff00:252: ICMP6, neighbor
> solicitation[|icmp6]
> 08:11:14.464428 Out IP6 truncated-ip6 - 22 bytes
> missing!fe80::5e5e:ab0e:1cdb:5f69 > ff02::1:ff00:253: ICMP6, neighbor
> solicitation[|icmp6]
> 08:11:14.833367  In IP6 fe80::215:faff:fe76:ab60 > ff02::1:ff00:1: ICMP6,
> neighbor solicitation, who has as22548.sp.ptt.br, length 32
> 08:11:15.833354  In IP6 fe80::215:faff:fe76:ab60 > ff02::1:ff00:1: ICMP6,
> neighbor solicitation, who has as22548.sp.ptt.br, length 32
> 08:11:16.598466  In IP6 fe80::768e:f8ff:fea5:81c1 > ff02::1: ICMP6, router
> advertisement, length 64
> 08:11:16.833339  In IP6 fe80::215:faff:fe76:ab60 > ff02::1:ff00:1: ICMP6,
> neighbor solicitation, who has as22548.sp.ptt.br, length 32
> 08:11:17.935749  In IP6 fe80::20c:42ff:fe20:6caf > ff02::1: ICMP6, router
> advertisement, length 56
> 08:11:18.282081  In IP6 fe80::d6ca:6dff:fe45:ec > ff02::1: ICMP6, router
> advertisement, length 56
> 08:11:18.468433 Out IP6 truncated-ip6 - 22 bytes missing!2001:12f8::217:158
> > ff02::1:ff00:254: ICMP6, neighbor solicitation[|icmp6]
> 08:11:19.220427 Out IP6 truncated-ip6 - 22 bytes missing!2001:12f8::217:158
> > ff02::1:ff00:254: ICMP6, neighbor solicitation[|icmp6]
> 08:11:19.234088  In IP6 fe80::c67d:4fff:fe65:9cc5 > ff02::1: ICMP6, router
> advertisement, length 64
> 08:11:19.378905  In IP6 fe80::222:b0ff:fe61:60db > ff02::1: ICMP6, router
> advertisement, length 56
> 08:11:19.469401 Out IP6 truncated-ip6 - 22 bytes
> missing!fe80::5e5e:ab0e:1cdb:5f69 > ff02::1:ff00:252: ICMP6, neighbor
> solicitation[|icmp6]
> 08:11:19.469437 Out IP6 truncated-ip6 - 22 bytes
> missing!fe80::5e5e:ab0e:1cdb:5f69 > ff02::1:ff00:253: ICMP6, neighbor
> solicitation[|icmp6]
> 08:11:20.470406 Out IP6 truncated-ip6 - 22 bytes missing!2001:12f8::217:158
> > ff02::1:ff00:254: ICMP6, neighbor solicitation[|icmp6]
> ^C
> 22 packets received by filter
> 0 packets dropped by kernel
>
>
>
> Em 11 de setembro de 2013 07:41, Josivan Barbosa <
> josivan.barbosa01 at gmail.com> escreveu:
>
> > Você poderia capturar o tráfego e ver o que está acontecendo. No Juniper
> > tem como fazer isso, só não lembro agora o comando.
> > Outra coisa, você disse que trocou o equipamento, mas não li nada sobre
> > liberação do MAC no PTT-SP.
> >
> >
> > Em 10 de setembro de 2013 20:29, Pedro NOC <
> > pedro.siqueira at friistelecom.com.br> escreveu:
> >
> >> Você tem a designação do circuito do lado da Algar? O que significa
> >>
> >> quarentena pra vc? Apenas as sessões ficam estabelecidas mas vc não
> >> utiliza
> >> o link para cursar tráfego?
> >>
> >> Designação?!? É um clear channel ou vc quis dizer o numero do circuito?!
> >> Quarentena é quando o PTT nos coloca em um ambiente de teste. Neste
> >> ambiente, apenas fechamos os peers mas não recebemos prefixo nenhum.
> Neste
> >> ambiente os peers sobem, e eu pingo os ips.
> >> Em ambiente de produção do PTT, as sessões não sobem e nem pingo os ips.
> >>
> >>
> >> >Por acaso vc não está exportando mais do que deveria de volta para o
> PTT
> >> e
> >> está estourando o limite de prefixos configurado para a sua sessão?
> >>
> >> >p.s. isso não explicaria não conseguir pingar os ips diretamente
> >> conectados... mas ainda acho válido a verificação.
> >>
> >> Então, a principio meus filtros estão coreetos, pois na primeira vez que
> >> efetuamos os testes tudo funcionou perfeitamente, depois de algumas
> horas
> >> tudo parou.
> >> Exatamente... eu teria que pelo menos pingar. O que não acontece.
> >>
> >>
> >>
> >> >A vlan de produção tem outro número, não ? Será que seu transporte não
> >> >configurou estaticamente o número da VLAN da quarentena ?
> >>
> >> No meu lado, as vlans são as mesmas. Questionei hoje a equipe do PTT
> sobre
> >> isso, me informaram que eles fazem tradução de vlan; do lado deles eles
> >> mudam as vlans sim. Vlan de produção é diferente de vlan de quarentena.
> >>
> >>
> >>
> >> Em 10 de setembro de 2013 20:08, Rubens Kuhl <rubensk at gmail.com>
> >> escreveu:
> >>
> >> > >
> >> > > o mesmo modelo em Campinas e funcionava). Trocamos por um Juniper
> MX5.
> >> > > - Foi solicitado a Algar que: aumentasse o limite de trafego de
> >> > > broadcast(15Mb), o MTU e a limitação do numero MACs dos
> equipamentos.
> >> > > - Trocamos o IP fornecido pelo PTT-SP.
> >> > > - Trocamos a vlan fornecida pelo PTT-SP.
> >> > > - Algar trocou o switch final onde nos conectamos ao PTT.
> >> > >
> >> > > Em quarentena os peers sobem, e eu pingo todos os ips, em produção
> nem
> >> > > pingo nenhum ip.
> >> > >
> >> > >
> >> > A vlan de produção tem outro número, não ? Será que seu transporte não
> >> > configurou estaticamente o número da VLAN da quarentena ?
> >> >
> >> >
> >> > Rubens
> >> > --
> >> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> *
> >> *
> >> *  Pe**dro Siqueira*
> >>   INOC-DBA 53131*100
> >>     Network Manager
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
>
>
> --
> *
> *
> *  Pe**dro Siqueira*
>   INOC-DBA 53131*100
>     Network Manager
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Vinicius Garcia