[GTER] IX - ATMv6 - Pacotes Broadcast(multicast) corretamente esperados

[Josivan Barbosa]

Passando para os pacotes que realmente não são esperados, estou
recebendo trafego unicast ipv6 entre outros participantes (como em um
espelhamento de porta) em uma determinada
localidade do IX.br. Já abri chamado. Estou aguardando a equipe do
IX.br verificar.


Em 14 de maio de 2018 10:04, Douglas Fischer
<fischerdouglas at gmail.com> escreveu:
> Renan,
> de cara eu confesso que até fiquei um tiquinho indignado com sua sugestão.
> Mas lembrei da curca de Dunning-Kruger e voltei a dar uma olhada na rfc.
> E agradeço a sugestão.
>
>       Source Address
>                      Either an address assigned to the interface from
>                      which this message is sent or (if Duplicate Address
>                      Detection is in progress [ADDRCONF
> <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>]) the
>                      unspecified address.
>
>
>
> E a conclusão que cheguei é que continuo sem entender exatamente o que
> acontece.
>
>
> Eu me lembro de ter lido em alguma das RFCs relacionadas a IPv6 que a ordem
> de precedência de escolha do endereço a ser utilizado é sempre do maior
> escopo DISPONÍVEL para o menor...
>  - 1º Global Address
>  - 2º Unique Local Address
>  - 3º Link-Local.
> A não ser que as camadas superiores definam o endereço de origem.
>
> Na prática, o que eu andei vendo na rede do IX (multi-vendor e bem
> heterogênea)é que:
>     (Informação baseada no EUI, mac pode ter sido clonado)
>  - Os servers do NIC sempre usam Global Address como source para Neighbor
> Solicitation.
>  - A maioria dos Cisco e dos Huawei usam o Global Address como source para
> N.S.
>  - Uma pequena parte dos Juniper usam Global Address como source para N.S.
>  - Praticamente todos os MK(routerboard) usam LinkLocal como source para
> N.S.
>    - Os que usam Global Address, acho que estão com mac clonado. TTL indica
> isso.
>
>
> E agora? Oque significa isso?
> - Que nessa parte(qual source será usado) existe um ponto de livre escolha?
> - Vendors que não estão em compliance com alguma das RFCs envolvidas?
> - Existem configurações em cada vendor que colocariam isso dentro dos
> conformes?
>
>
>
> Em 9 de maio de 2018 09:55, Renan Menezes <renanitmanager at gmail.com>
> escreveu:
>
>> Bom dia Douglas,
>>
>> Dá uma olhada na RFC, talvez ela te esclareça sobre o que deve usar.
>>
>> https://tools.ietf.org/html/rfc4861
>>
>> Uma apostila muito bem elaborada é a do nic.br
>> http://ipv6.br/media/arquivo/ipv6/file/48/IPv6-apostila.pdf [Página 91 do
>> PDF]
>>
>>
>> Em 9 de maio de 2018 00:43, Douglas Fischer <fischerdouglas at gmail.com>
>> escreveu:
>>
>> > Em 29 de abril de 2018 20:32, Rubens Kuhl <rubensk at gmail.com> escreveu:
>> >
>> > > 2018-04-29 17:21 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
>> > >
>> > > > Os participantes não deveriam estar emitindo esses pacotes
>> > > > somente perguntando por destinos na Faixa Rede do ATMv6?
>> > >
>> > > Vale questionar neste caso se não é de gente que subiu sessão entre
>> > > diferentes ASN no ATMv6 e quis assim. Talvez isso fosse mais apropriado
>> > em
>> > > VLANs entre participantes, mas não me parece tão grave se for esse
>> mesmo
>> > o
>> > > caso.
>> > >
>> >
>> > Além dos casos de participantes com Neighbor Solicitation com os Target
>> em
>> > LinkLocal(FE80)
>> > (essa tá meio atravessada na garganta ainda)
>> >
>> > Constatei que existem:
>> > a - participantes que fazem Neighbor solicitation usando origem
>> > Global-Address
>> > b - participantes que fazem Neighbor solicitation usando origem
>> Link-Local
>> >
>> > Não consegui identificar nenhuma similaridade entre eles...
>> > - Múltiplos vendors em cada uma delas.
>> > - Acho que não ví Routeboard nos que usam Global-Address.
>> > - Creio que tudo que vi vindo de server do NIC.BR usava Global-Address
>> > com origem da NS
>> >
>> >
>> > Existe alguma lógica ou protocolo que define quando se usa Endereço
>> Global
>> > ou Link-Local para procurar MAC de um outro Neighbor?
>> >
>> >
>> >
>> > --
>> > Douglas Fernando Fischer
>> > Engº de Controle e Automação
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter



-- 
Att

Josivan Barbosa