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

Douglas Fischer fischerdouglas at gmail.com
Wed May 16 22:07:36 -03 2018 

Andei procurando sobre o aging time da mac address table no Extreme.
Meus caderno de catequese, que documentação horrível de se achar...

Descobri que eles chamam a CAM table de FDB, e o comando para definir isso é
 - configure fdb agingtime <seconds>
Mas não descobri qual é o default deles(todos os vendors que conheci é
300s).

Subir um pouco(1h-2h) esse tempo SOMENTE nas vlans envolvidas, tende a
ajudar...
(não sei como faz isso especificamente para uma vlan no extreme)

Ainda estou trabalhando numa solução mais elegante.


Por curiosidade, quais são o vendors dos routers?


Em 16 de maio de 2018 19:44, Josivan Barbosa <josivan.barbosa01 at gmail.com>
escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação

More information about the gter mailing list