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

[Josivan Barbosa]

Porta compartilhada. Administro os dois únicos participantes que usam
esta porta.
Topologia:

                      IX.br
                          |
                  sw extreme

                   /              \
              Router A      Router B


Cada um no seu quadrado. Um já está em produção e o outro em
quarentena. Consigo capturar o tráfego apenas no roteador que está em
produção apenas na VLAN do ATMv6.



Em 16 de maio de 2018 16:24, Douglas Fischer
<fischerdouglas at gmail.com> escreveu:
> Tá em CIX? Ou as Vlans vem de uma porta compartilhada?
>
> Aposto em unicastflood decorrente de trafego uniderecional.
> Esse tráfego pode ser intencionalmente unidirecional devido a multiplas
> conexões ao IX.
>
> Isso tem a ver com o Aging-Time da tabela CAM e o comportamento
> padrão(block o foward-to-all) no caso de mac-nãio mapeado.
>
>
> Vou fazer uma palestra sobre isso na GTER da semana que vem.
>
>
>
> Em 16 de maio de 2018 14:25, Josivan Barbosa <josivan.barbosa01 at gmail.com>
> escreveu:
>
>> 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
>> --
>> 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