Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: foundry

MLX broadcast storm protection

 

 

nsp foundry RSS feed   Index | Next | Previous | View Threaded


netservices.incs at gmail

Apr 5, 2011, 9:47 AM

Post #1 of 6 (1144 views)
Permalink
MLX broadcast storm protection

Anyone out there know of a good way to protect against customer broadcast
storms? We use a few MLX switches with customer ports on them. Occasionally,
a customer will create a loop in their equipment which causes a storm all
the way back to our MLXs. The line cards are pretty good at handling (CPU
goes to 30-40%) but would like to know of a good way to protect our MLX.

Also, any have best security practices they apply on customer ports to help
keep the core switching stable?


netservices.incs at gmail

Apr 5, 2011, 9:47 AM

Post #2 of 6 (1124 views)
Permalink
MLX broadcast storm protection [In reply to]

Anyone out there know of a good way to protect against customer broadcast
storms? We use a few MLX switches with customer ports on them. Occasionally,
a customer will create a loop in their equipment which causes a storm all
the way back to our MLXs. The line cards are pretty good at handling (CPU
goes to 30-40%) but would like to know of a good way to protect our MLX.

Also, any have best security practices they apply on customer ports to help
keep the core switching stable?


eric.ndn at gmail

Apr 5, 2011, 10:06 AM

Post #3 of 6 (1094 views)
Permalink
Re: MLX broadcast storm protection [In reply to]

Hi,

What is the natural of your traffic then ? Do you allow broadcast,
unknown unicast to be flooded by the edge-switches ?
Applying L2 ACL at the edge switches might be you answer, if you only
allow traffics sourcing from one MAC addresses.
IMHO, allow the broadcast packets hitting your CPU is bad, just drop
broadcast traffic from unknown source L2 ACL.

On 4/5/11 6:47 PM, Mark Johnson wrote:
> Anyone out there know of a good way to protect against customer broadcast
> storms? We use a few MLX switches with customer ports on them. Occasionally,
> a customer will create a loop in their equipment which causes a storm all
> the way back to our MLXs. The line cards are pretty good at handling (CPU
> goes to 30-40%) but would like to know of a good way to protect our MLX.
>
> Also, any have best security practices they apply on customer ports to help
> keep the core switching stable?
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp


Jan.Pedersen at GlobalConnect

Apr 5, 2011, 10:56 AM

Post #4 of 6 (1106 views)
Permalink
Re: MLX broadcast storm protection [In reply to]

Vlan-cpu-protection on the vlan will secure that broadcast and multicast packets are forwarded in hardware, and won't hit the cpu, and it will also keep most of the unknown-unicast traffic as hardware flooding. This is of course only to protect the cpu.

In order to limit the amount of broadcast and multicast traffic we use these L2 ACLs

access-list 400 permit any ffff.ffff.ffff ffff.ffff.ffff any etype any
access-list 401 permit any 0100.5e00.0000 ffff.ff00.0000 any etype any


interface ethernet X/Y

rate-limit input access-group 400 10253296 10256640

rate-limit input access-group 401 10253296 10256640



Best regards

Jan Pedersen
Senior Network Specialist
D: +45 7730 2932
M: +45 2550 7321

From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Mark Johnson
Sent: 5. april 2011 18:48
To: foundry-nsp [at] puck
Subject: [f-nsp] MLX broadcast storm protection

Anyone out there know of a good way to protect against customer broadcast storms? We use a few MLX switches with customer ports on them. Occasionally, a customer will create a loop in their equipment which causes a storm all the way back to our MLXs. The line cards are pretty good at handling (CPU goes to 30-40%) but would like to know of a good way to protect our MLX.

Also, any have best security practices they apply on customer ports to help keep the core switching stable?


netservices.incs at gmail

Apr 5, 2011, 3:38 PM

Post #5 of 6 (1077 views)
Permalink
Re: MLX broadcast storm protection [In reply to]

Thank you for all who replied. What are most of you service providers out
there doing to protect your equipment from customers? What type of ACLs?


tomeks at man

Apr 6, 2011, 11:58 PM

Post #6 of 6 (1073 views)
Permalink
Re: MLX broadcast storm protection [In reply to]

Hi,

I would recommend "cpu protection" if you _must_ use L2 switching (VPLS) or just use VLLs or VLL-Local for point-to-point connection. There
is no MAC learning within VLL/VLL-local instance.

Check if "cpu protection" works on VLANs. Alternatively try loop detection on the interface.

Tomek

W dniu 2011-04-05 18:47, Mark Johnson pisze:
> Anyone out there know of a good way to protect against customer broadcast storms? We use a few MLX switches with customer ports on them.
> Occasionally, a customer will create a loop in their equipment which causes a storm all the way back to our MLXs. The line cards are
> pretty good at handling (CPU goes to 30-40%) but would like to know of a good way to protect our MLX.
>
> Also, any have best security practices they apply on customer ports to help keep the core switching stable?
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
Attachments: smime.p7s (5.71 KB)

nsp foundry RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.