[GTER] Switch para port mirroring

[Shine]

Continuando.... (não sei como a sequência de teclas acabou enviando...)

No caso do Alessandro não se sabe a quantidade de portas a espelhar, mas
sabe-se que vai concentrar em apenas uma porta.
Se for somente um equipamento, não faz sentido para mim falar em TAP, pq se
o switch for moderno ele consegue apenas comprar um switch e tirar o
espelhamento.
O Douglas levantou uma questão válida. Acho que o Alessandro vai obviamente
coletar em uma porta com velocidade superior. Se as portas espelhadas são
1G e ele tem um tráfego médio de 30% , com uma porta de 10G ele consegue
espelhar um monte de portas sem perda de dados, acho que fica claro que tem
que dimensionar. Mas em se tendo uma situação de tráfego espelhado
excedente em um pico e exaustão dos buffers disponíveis, o correto é o
tráfego espelhado ser descartado, sem nenhum efeito colateral ao tráfego do
switch. Um equipamento de qualidade tem esse comportamento e aí é com o
Alessandro fazer a avaliação de risco, benefício e custo. De repente para o
negócio não há orçamento para esse investimento e cada um sabe aonde o calo
aperta.

Se ficarmos estendendo a discussão para fora do escopo original vamos
entrar em uma seara de assuntos falando de dedup, masking, timestamp...
acho que aí seria melhor abrir um novo tópico.

Em 13 de abril de 2018 00:04, Shine <eshine at gmail.com> escreveu:

> Tap e NPB é uma solução out-of-band.
> Não existe moto-contínuo, mas a solução é passiva portanto você tem uma
> cópia do tráfego com segurança de falhas.
> No caso de tap ótico, você tem uma perda de potência do sinal, então o
> distância do link deve ser redimensionada para acomodar.
> https://en.wikipedia.org/wiki/Network_tap
>
> O NPB (Network Packet Broker) é necessário para agregar todo o tráfego
> coletado, sendo passível de filtrar de diversas maneiras. Existem modelos
> mais ou menos sofisticados.
> https://en.wikipedia.org/wiki/Data_monitoring_switch
>
> Mas a questão do Alessandro é: port mirroring, também conhecido como SPAN
> (Switch Port ANalyzer), então supor TAP+NPB como solução é precipitado.
> Não se sabe a quantidade de portas que ele quer espelhar, mas sabe-se
>
> Em 12 de abril de 2018 13:42, Christian Lyra <poplyra+eng at gmail.com>
> escreveu:
>
>> Caros,
>>
>> O ideal seria usar um network tap, que é um equipamento feito pra isso e é
>> fail-safe (se falhar não atralha em nada). A tempos atras pesquisei a
>> possibilidade de usar um splitter optico para capturar trafego, mas acabou
>> que não levei o projeto adiante.
>>
>> 2018-04-11 19:24 GMT-03:00 Shine <eshine at gmail.com>:
>>
>> > É, pode acontecer, mas aí a culpa não é só do operador.
>> > Um sistema operacional decente de switching deveria por um limite de
>> > consumo do buffer e fazer o scheduling correto dos recursos.
>> > Uma vez que se acaba o buffer disponível, os pacotes excedentes deveriam
>> > ser descartados e subir um log/alarme. E nada de afetar a porta de
>> origem.
>> >
>> > Em 11 de abril de 2018 12:23, Douglas Fischer <fischerdouglas at gmail.com
>> >
>> > escreveu:
>> >
>> > > ​Outra coisa para tomar cuidado é o Over-subscription no Span-Port...
>> > >
>> > > Mandar mais trafego de espelhamento para uma port(ou conjunto de
>> portas)
>> > > que ela(s) podem aguentar.
>> > > Os buffers atolam, e afeta a porta de origem do espelhamento.
>> > >
>> > > Já fiz dedo-gordo numa dessas e quase matei uma rede por uns 10
>> > minutos...
>> > > P.S.: Se não em engano nesse caso atolou também CPU.
>> > >
>> > >
>> > > Em 11 de abril de 2018 00:43, Shine <eshine at gmail.com> escreveu:
>> > >
>> > > > Bom, não é somente Juniper, o consumo do tráfego espelhado pode
>> > impactar
>> > > em
>> > > > qualquer switch.
>> > > > No caso de switches em um único chip, não há problemas, já que o
>> > consumo
>> > > é
>> > > > mesmo interno.
>> > > > No caso de switches em múltiplos chips (por exemplo chassis), pode
>> > haver
>> > > um
>> > > > impacto no fabric se o tráfego espelhado tiver que passar por
>> múltiplos
>> > > > ASICs diferentes. Precisa ver até onde o caso é extremo.
>> > > >
>> > > > Em 10 de abril de 2018 17:42, Leonardo Amaral - Listas <
>> > > > listas at leonardoamaral.com.br> escreveu:
>> > > >
>> > > > > Até onde me recordo, o port mirroring dos juniper QFX entra na
>> conta
>> > > > total
>> > > > > de capacidade de forwarding.
>> > > > >
>> > > > >
>> > > > >
>> > > > > [image: --]
>> > > > >
>> > > > > Leonardo Amaral
>> > > > > [image: https://]about.me/leonardo.amaral
>> > > > > <https://about.me/leonardo.amaral?promo=email_sig&utm_
>> > > > > source=email_sig&utm_medium=email_sig&utm_campaign=external_
>> links>
>> > > > >
>> > > > > Em 10 de abril de 2018 14:01, Alessandro Daudt <
>> > > > daudtalessandro at gmail.com>
>> > > > > escreveu:
>> > > > >
>> > > > > > Pessoal, eu tenho uma aplicação que usa basicamente port
>> mirroring.
>> > > > > >
>> > > > > > O problema é que isso ocupa muita CPU nos meus switch.
>> > > > > >
>> > > > > > Alguém sabe me dizer se existe algum tipo de switch que seja
>> feito
>> > > para
>> > > > > ter
>> > > > > > maior performance  com port mirroring?
>> > > > > >
>> > > > > > --
>> > > > > >
>> > > > > > Alessandro Luís Daudt
>> > > > > > Engenheiro Eletricista
>> > > > > > CREA RS213418
>> > > > > > Tel. 51 984 222 008
>> > > > > > --
>> > > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > > > > >
>> > > > > --
>> > > > > 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
>> > >
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>