The customers at this time have dedicated VLANs, though the plan is to 
eventually move to a shared VLAN environment with firewalls built into the 
topology(mitigating much of this problem with the L3 device sitting between 
their switch & ours).  We have a boiler-plate 802.1q config for each VLAN that 
works in most of our environment, it's the colo customers with their own 
switches & multiple uplinks where the problem occurs.  We've mitigated this 
problem by vetting the customer's switch config prior to turning up the 2nd 
uplink, but as you can imagine that doesn't close the loophole entirely(not to 
mention it isn't a scalable solution).  In essence what I'm imagining is 
setting the path cost significantly lower on one uplink than the other(say 
10,000 v. 20,000), which would essentially designate the 2nd uplink as a 
back-up.

I'd also like to deploy a solution that blocks bpdus coming from the customer's 
equipment, but as I mentioned bpdu-guard didn't meet our needs.  That's perhaps 
a tangent discussion for another time though.  I'm more focused on the path 
cost functionality at this point.


Network Engineer
> 214-981-1954 (office)
> 214-642-4075 (cell)
> [EMAIL PROTECTED]
http://www.speakeasy.net
-----Original Message-----
From: Lee Pedder [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2008 10:04 AM
To: Jonathan Brashear
Cc: [email protected]
Subject: Re: [f-nsp] FESX spanning-tree path cost success?

2008/9/8 Jonathan Brashear <[EMAIL PROTECTED]>:
> Our DC has had intermittent issues over the past year with spanning-tree 
> loops with customers who have multiple uplinks to our switch fabric.  We've 
> explored a few different options with limited to no success(such as bpdu 
> guard, stp-protect, etc.), but currently we're considering setting manual 
> path costs on ports as a way to help avoid the loops & subsequent cpu spikes 
> we've dealt with.

How do you connect your customers? Is it a shared VLAN environment, or
do you have a separate VLAN per customer, to which the customer plugs
in 2 end stations?

I have seen similar issues in this scenario where customers create
loops by plugging both into a switch, but this has been down to STP
being misconfigured, not running, or worse - an end device that
forwards everything but BPDUs. Are you running STP/RSTP on all ports,
and are they sending BPDUs? Functions like stp-protect and
stp-bpdu-guard will only work if the ports are part of the STP
topology in the first place (their STP state should not list as
DISABLED). They are usually coupled with fast port-span or rstp
admin-edge-port.

What are your plans for manually setting path costs, and how would
this prevent loops in your scenario?

For a shared environment where the risk to one VLAN is higher, you may
also consider port security - either lock down to configured
mac-addresses or implement dynamic learning with an appropriate number
of max addresses. On a network without protection, a loop will cause
lots of mac addresses to appear out of the port(s) causing it. With
port security, you can have the switch shut down a port that violates
the security policy without having to include the edge ports in the
STP topology.

Regards,
Lee
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp

Reply via email to