Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
One think I noticed when working with the BUM filter under VPLS instance is that there is no way to declare a per instance policer that I could find. Your can call the same filter/policer in multiple VPLS instances, but the named policer is a single global instance. So, if you call the same filter w/ 5Mbit policer in 20 instances it is not 20 seperate 5 mbit policers, it is one policer shared across all. I very much want to add a BUM policer by default to all VPLS instances, but I really want to avoid creating a seperate filter and policer config for each instance, when 95% of them would be running one of three standard configs. And yes, this was tested. 10.4R10, trio based (MX960s w/ MPC2 and MX80) the policer was always shared. On 8/17/12 3:20 PM, Chris Kawchuk wrote: Hi Clarke, We pass through BPDUs through VPLS the MX'es- but yes, miscreant users / switches will always be a problem. We do the following to every customer-facing VPLS instance, but only #3 would help you here: 1. Mac Limiting per VPLS Interface (100) (i.e per 'site') 2. Mac Limiting per VPLS (500) 3. Limit Broadcast/Unknown Unicast/Multicast Traffic (5 Mbit) into the VPLS You can put on an input firewall filter which calls a 5 Mbit policer at [routing instances vpls-name forwarding-options family vpls ] to start limiting this type of traffic into the 'bridge domain' at any time. - CK. On 18/08/2012, at 1:08 AM, Clarke Morledge chm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
On Fri, 17 Aug 2012, Jensen Tyler wrote: Quick google for VPLS Multihoming found me this: http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/feature-guide/vpls-multihoming-bgp-signaling-solutions.html Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC Jensen, VPLS multihoming assumes you are intentionally building out a loop-free VPLS domain. My situation is when you have a downstream customer who unintentionally introduces a loop in their Layer2 domain that causes MAC learning table thrashing back inside your VPLS instance. Thanks for the pointer though. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Quick google for VPLS Multihoming found me this: http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/feature-guide/vpls-multihoming-bgp-signaling-solutions.html Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clarke Morledge Sent: Friday, August 17, 2012 10:09 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations? We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
On Fri, Aug 17, 2012 at 8:08 AM, Clarke Morledge chm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. This is probably not the answer you're looking for, but the best solution is to not bridge to your access switches. Everything in the EX series is capable of routing, so why not take advantage of that functionality? Barring that, your options are: storm control, MAC limiting, and MAC move limiting. I've never found storm control to be that useful. It reduces the volume of frames but usually not enough to cancel out all of the negative effects. MAC limiting with a reasonable MAC limit on a port can cause the port to be disabled if too many addresses are seen coming from said port. MAC move limiting is configured per VLAN. It can detect a layer 2 loop with a smaller number of MAC addresses than MAC limiting would, but my concern has always been that (as far as I can tell) there's no way to determine which interface would end up being disabled - it would be bad to have it pick a trunk between your core switches instead of the trunk to the IDF. None of these will ever be as effective as routing. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I believe there was a thread on here within the last month about an event script for the MX platform that would do just that. Going back to the first section, though, you should think thrice before doing VPLS - Ivan PepeInjak has some good articles about the hazards of L2 across your wan on his blog. HTH :w ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Hi, ...on Fri, Aug 17, 2012 at 11:08:53AM -0400, Clarke Morledge wrote: switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. Not that I've used it myself yet, but the aptly named MAC Move Limiting might help here, though usefulness might depend on the actual topology:: http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/port-security-mac-limiting-and-mac-move-limiting.html Alex. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
What about TRILL? Not sure if Juniper has jumped on the TRILL bandwagon yet. -- Regards, Ge Moua Univ of Minn Alumnus -- On 08/17/2012 11:06 AM, Wayne Tucker wrote: On Fri, Aug 17, 2012 at 8:08 AM, Clarke Morledgechm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. This is probably not the answer you're looking for, but the best solution is to not bridge to your access switches. Everything in the EX series is capable of routing, so why not take advantage of that functionality? Barring that, your options are: storm control, MAC limiting, and MAC move limiting. I've never found storm control to be that useful. It reduces the volume of frames but usually not enough to cancel out all of the negative effects. MAC limiting with a reasonable MAC limit on a port can cause the port to be disabled if too many addresses are seen coming from said port. MAC move limiting is configured per VLAN. It can detect a layer 2 loop with a smaller number of MAC addresses than MAC limiting would, but my concern has always been that (as far as I can tell) there's no way to determine which interface would end up being disabled - it would be bad to have it pick a trunk between your core switches instead of the trunk to the IDF. None of these will ever be as effective as routing. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I believe there was a thread on here within the last month about an event script for the MX platform that would do just that. Going back to the first section, though, you should think thrice before doing VPLS - Ivan PepeInjak has some good articles about the hazards of L2 across your wan on his blog. HTH :w ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Hi Clarke, We pass through BPDUs through VPLS the MX'es- but yes, miscreant users / switches will always be a problem. We do the following to every customer-facing VPLS instance, but only #3 would help you here: 1. Mac Limiting per VPLS Interface (100) (i.e per 'site') 2. Mac Limiting per VPLS (500) 3. Limit Broadcast/Unknown Unicast/Multicast Traffic (5 Mbit) into the VPLS You can put on an input firewall filter which calls a 5 Mbit policer at [routing instances vpls-name forwarding-options family vpls ] to start limiting this type of traffic into the 'bridge domain' at any time. - CK. On 18/08/2012, at 1:08 AM, Clarke Morledge chm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
