Configuração do pvst 3750 e 2960G

Olá pessoal,

Sou novo no forum e estou com um problema em uma topologia STP.

Imagine o seguinte cenário:

Um switch 3750 com o pvst ativo, conecto ao 3750 2 (dois) 2960G através de Fibra multimodo. No 3750, onde possuo várias vlans, configuro todas com com o spanning tree vlan [vlans] priority 4096, dessa forma faço com que sempre seja o root. No switch 2960G-1 e 29060G-2 faço um balanceamento de vlans da seguinte forma. Vlan pares trafegam no 29060G-1 e impares 2960G-2. Faço a configuração mudanndo as priority.
Abaixo dos switch 2960 possuo switch sem STP, DLINK, que faço ligação de duas portas, uma em cada switch 2960G.




Nesse caso enfrento um problema que ao gerar um looping no switch DLINK o 2960G-1 mostra a porta que ocorre o looping, como self-loop, mas depois de um tempo o 3750 começa a perder eleição de root bridge para o 2960G-1 e há uma sobre carga nesse equipamento e perco a gerencia do mesmo, depois de um tempo toda minha rede cai.

Alguma ideia para contornar essa situação.
Já tentei utilizar o spanning tree vlan [vlans] root primary no 3750, mas mesmo assim ocorre o problema.

Eu acredito que este loop esteja fazendo com que o root se perca na rede, por isso a rede começa a oscilar.
Podemos tentar aplicar estas 3 configurações para proteger contra loops vindos do DLINK.
Estas 3 configurações devem ser aplicadas nas interafces do 2960 que conectam ao DLINK.

1 - Configurar na interface que conecta ao DLINK o spanning-tree loop-guard que deve colocar a porta em error-disable ao perceber um loop na topologia.
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml#loop_guard

2 - Como o DLINK não fala STP, podemos configurar a feature de spanning-tree bpdu guard nestas interfaces (apenas para garantir que o spanning-tree não seja habilitado nestes switchs não gerenciaveis, ou pior, que após ser habilitado o switch tente assumir o root do ambiente).
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_35_se/configuration/guide/swstpopt.html#wp1095752

3 - Para proteger o ambiente contra novos floods de multicast, podemos utilizar a feature storm-control.
Esta feature pode ser utilizada nas interfaces para prevenção contra floods de tráfego broadcast, multicast ou unicast.
O comando irá monitorar o tráfego de input, e quando ultrapassar o threshold configurado poderá dropar ou desabilitar a interface.
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.1_19_ea1/configuration/guide/swtrafc.html#wp1085954

O comportamento default do storm-control é de dropar o tráfego excedente, mas pode ser utilizado um recurso em conjunto (disponivel a partir da versão 12.2(25)SE) para que a interface entre em error-disable.

Quando a interface entrar em error-disable ela ficará desabilitada até que seja realizado um shut/no shut, ou pode também ser configurado um intervalo de tempo para que ela seja automaticamente reabilitada.

#conf t
(config)#errdisable recovery cause storm-control (tempo em segundos)

Segue o script a ser aplicado nas interfaces conectadas a estes switchs não gerenciaveis.
Configurei um limite de 10% para broadcast e de 10% para multicast.
obs. pode ser configurado também uma limitação para unicast através do comando "storm-control unicast level X"

#conf t
(config)#interface FastethernetX/X
(config-if)#spanning-tree bpduguard enable
(config-if)#storm-control broadcast level 10
(config-if)#storm-control multicast level 10
(config-if)#storm-control action shutdown

Após ser configurado os valores de storm-control podem ser monitorados através do comando:

#show interfaces FastethernetX/X counters storm-control
#show storm-control FastethernetX/X multicast
#show storm-control FastethernetX/X broadcast
#show storm-control FastethernetX/X history


Tenta aplicar elas e depois me diz se isso resolveu seu problema de loop ;-)

obs. existe também aquela configuração de root-guard, mas eu acho que apenas estas linhas já devem resolver.

abs,