[GTER] Problema Ativação PTT

Pedro NOC pedro.siqueira at friistelecom.com.br
Wed Sep 11 10:17:43 -03 2013 

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

More information about the gter mailing list