RE: Auto MDI/MDI-X + conference rooms + bored == loop
We had a school district that had a large number of dumb switches in each class room hanging off real ones. These would get looped when a student or staff member plugged a patch cable into two ports on the end switch, taking down large portions of the network. It seems Cisco 3500's ignore a BPDU that comes in the same port it comes out. We switched them to 3750's as part of other upgrades, which eliminated the BPDU problem (3560's and 3550's also work correctly), RSTP, enabled port fast, root guard, loop back detection, and storm control. Then set the switches to automatically come back in service from err-disable after 60 seconds or so. In every single test we did (looping off a dumb switch, looping two ports on the 3750, looping between two 3750 in different stacks), there was immediate blocking occurring that prevented any non-sense from effecting the network. Of course the little switches get taken out along with anything connected, but that's really just an indicator of the need for more drops from real switches. Additionally, turning on only one of the features at a time still shut down the port within a second or so. I don't really like BPDUGuard when rootguard is available, as I think other devices should be able to participate in STP so long as they aren't trying to reconverge the network by grabbing root or becoming a transit between two building switches. As for RSTP, it's on for every switch we deploy unless there is some compelling reason not to do so. I have yet to find another switch that will not work even if it only supports old STP. -WT -Original Message- From: Chuck Anderson [mailto:c...@wpi.edu] Sent: Friday, March 26, 2010 6:09 PM To: nanog@nanog.org Subject: Auto MDI/MDI-X + conference rooms + bored == loop Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP edge or portfast or faststart modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the edge STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). Desktop switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to edge ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on Desktop switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)
RE: [NANOG] Multihoming for small frys?
I got a /22 in January, and was told by someone from ARIN that the policy below only applied to allocations to ISP's, not to assignments for end customers. At the time, they said an end user must show at least 25% immediate usage (so a /24) and that there was no requirement for future usage. In my experience, if you can show you have some semblance of ability, two real peers, and an existing and established business, you should be able to get the request through easily in about a week, start to finish. When you're ready, fill out the request form, the worst that can happen is they reject you or defer you until you can provide more info. If you have questions for/about ARIN, call them (number is on the website) and talk to one of their people, they've been pretty knowledgeable, friendly, and helpful in my experience. -Will -Original Message- From: Tony Varriale [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 3:03 PM To: Andy Dills Cc: nanog@nanog.org Subject: Re: [NANOG] Multihoming for small frys? Thanks for the info. We needed larger than /22 anyways. I am a bit surprised that they will hand out a small allocaiton for multihomers. These days it's very easy to do. And, could be a easy way to horde some v4. Notice the caveats: To qualify under the IPv4 Multi-homing policy, your organization must prove an intent to multi-home, demonstrate utilization for at least a /23-worth of IP addresses assigned by upstream providers, and provide 3-, 6-, and 12-month utilization projections. In addition, your organization must agree to use the requested IPv4 address space to renumber out of your current address space, and to return the original address space to your upstream provider(s) once the renumbering is complete. Additional space will not be allocated until this is completed. Organizations that qualify under this policy may also qualify and request space under ARIN's general IPv4 allocation policy. Of course, this could be smoke and mirrors. Not sure. tv - Original Message - From: Andy Dills [EMAIL PROTECTED] To: Tony Varriale [EMAIL PROTECTED] Cc: nanog@nanog.org Sent: Wednesday, May 21, 2008 1:53 AM Subject: Re: [NANOG] Multihoming for small frys? On Tue, 20 May 2008, Tony Varriale wrote: AFAIK, ARIN doesn't give out /22s anymore. Last time I went to the well...it's was a /20 or better. Nah, it's /22 for multi-homed networks, /20 for single-homed. http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html 4.3.2.2 Multihomed Connection For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /22. If assignments smaller than a /22 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose. Are there really networks who can justify a /20 that aren't multi-homed? The mind boggles. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
