[GTER] Problemas com switch Dell PC 5448

[Lista]

montei um cenário parecido com o ocorrido em laboratório, para ver se
é falha de equipamento ou não.
Para vc entender melhor seria o seguinte:
cliente A chegando com um cabo único no meu swtich, porém a porta
deixei como acesso, nas seguintes configurações.

!
interface ethernet g1
port storm-control broadcast enable
exit
interface ethernet g1
port storm-control broadcast rate 3500
exit
interface ethernet g1
port storm-control include-multicast unknown-unicast
exit
spanning-tree mode rstp
spanning-tree bpdu filtering
interface ethernet g1
spanning-tree disable
exit
interface ethernet g1
spanning-tree portfast
!
Essa configuração seria para o switch filtrar pacotes "loopado" em L2,
na porta do switch. pelo que entendi e olhei na documentação do
switch.

PS: Switch do lado A, não faço ideia de como esteja.
ficando mais ou menos assim

|sw_pc5448|-----------------------|sw_cliente|

Sem cabo redundante.




Por ser portas de acesso, deixo em modo portfast e filtrando o bpdus,
caso receba
Em 1 de fevereiro de 2012 15:52, Rubens Kuhl <rubensk at gmail.com> escreveu:
> Não entendi o que você está propondo, mas o que eu adotei num cenário
> similar foi:
> - Se o cliente não tem como gerar loop, BPDU Filter. Jogava fora
> qualquer lixo que vinha do cliente.
> - Se o cliente tinha como gerar loop (ex: cliente abordado com
> redundância), BPDU Guard. Chegou um BPDU é porque ele vai gerar um
> loop então a porta entrava em shutdown (nem block, pois a ausência de
> novos BPDUs não fazia a porta voltar, tinha que ser por comando).
>
>
> Rubens
>
>
>
> 2012/2/1 Lista <lista.gter at gmail.com>:
>> essa é uma configuração padrão do STP, para evitar que ambos pacotes
>> bpdus chegando por interface diferente do switch acaba por deixar uma
>> em block.
>> Agora no caso em que a outra ponta, como disse não temos controle,
>> supondo que tenha um HUB, ou seja, não vai enviar nenhum bpdu, e outra
>> só ligamos até o outro switch via 1 cabo de rede, então não tem como
>> receber dois frame bpdu em interface distintas.
>> Em ambos os casos não seria para o Storm-control tomar alguma atitude
>> com essa porta, e não deixar a cpu do sw ir as alturas?
>> A situação seria, como filtrar esse Storm, na interface onde não tem o
>> pq utilizar spanning-tree por se de acesso, e não de core, ou algo que
>> seja viavel deixar ativado?
>>
>>
>>
>> 2012/2/1 Rubens Kuhl <rubensk at gmail.com>:
>>> 2012/2/1 Lista <lista.gter at gmail.com>:
>>>> teria algum exemplo de como aplicar isso Rubens, ou alguma documentação?
>>>
>>> http://www.juniper.net/us/en/local/pdf/implementation-guides/8010002-en.pdf
>>>
>>>
>>>
>>> Rubens
>>> --
>>> 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