September 2011 - mice-discuss

Re: Remote MICE members?

by Ryan Goldberg

Forwarded to my team. Nicely put. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Tuesday, September 20, 2011 10:18 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Remote MICE members? On 9/20/11 19:54 CDT, Jay Hanke wrote: > Frankly, I'm surprised at the outpouring of love for spanning-tree on > the list. I've on more than one occasion selected a vendor with a ring > or a virtual chassis technology to avoid spanning-tree in the core. I > was also thrilled at the prospect of something like TRILL. > > Can someone take it on to make a design recommendation? Let me be clear, I don't love spanning-tree at all. But turning off spanning-tree and praying you never have a loop is worse than spanning-tree. My personal design preference is to design your network with a loop free topology at layer2. Then it is possible to run without spanning-tree. Any redundancy is provided using LAGs, GMPLS or MPLS transport technologies, not loops in the bridge topology. However, you still run spanning-tree to catch mistakes, they will happen and spanning tree will keep them from melting the network. When the network is built and is functioning as designed, spanning-tree has nothing to converge, the network has a loop free topology. In this design, spanning-tree is only there to ensure the network is actually built and actually functioning as designed. When you are driving your car, if you see head lights coming at you on the wrong side of the road, most people slow down and get ready to take the ditch. Rather than take a head on into the other guy, or into the ditch, at full speed. In this design, spanning-tree is looking for head light on the wrong side of the road, rather than assuming it will never happen, which is what you are doing if you just turn spanning-tree off. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by David Farmer

On 9/20/11 19:54 CDT, Jay Hanke wrote: > Frankly, I'm surprised at the outpouring of love for spanning-tree on > the list. I've on more than one occasion selected a vendor with a ring > or a virtual chassis technology to avoid spanning-tree in the core. I > was also thrilled at the prospect of something like TRILL. > > Can someone take it on to make a design recommendation? Let me be clear, I don't love spanning-tree at all. But turning off spanning-tree and praying you never have a loop is worse than spanning-tree. My personal design preference is to design your network with a loop free topology at layer2. Then it is possible to run without spanning-tree. Any redundancy is provided using LAGs, GMPLS or MPLS transport technologies, not loops in the bridge topology. However, you still run spanning-tree to catch mistakes, they will happen and spanning tree will keep them from melting the network. When the network is built and is functioning as designed, spanning-tree has nothing to converge, the network has a loop free topology. In this design, spanning-tree is only there to ensure the network is actually built and actually functioning as designed. When you are driving your car, if you see head lights coming at you on the wrong side of the road, most people slow down and get ready to take the ditch. Rather than take a head on into the other guy, or into the ditch, at full speed. In this design, spanning-tree is looking for head light on the wrong side of the road, rather than assuming it will never happen, which is what you are doing if you just turn spanning-tree off. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Andrew Hoyos

On Sep 20, 2011, at 7:08 PM, Richard Laager wrote: > I haven't had any cross-vendor problems, even mixing RSTP and MSTP (in > configurations for which they are designed to mix). Same here, at least as it relates to standards based MST/RSTP implementations. Never had issues there. OTOH, when trying to interop between per VLAN STP implementations (like RPVST+/Cisco, and VSTP/Juniper type scenarios), things *do* get a bit dicey. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Andrew Hoyos

On Sep 20, 2011, at 7:54 PM, Jay Hanke wrote: > Frankly, I'm surprised at the outpouring of love for spanning-tree on > the list. I've on more than one occasion selected a vendor with a ring > or a virtual chassis technology to avoid spanning-tree in the core. I > was also thrilled at the prospect of something like TRILL. > > Can someone take it on to make a design recommendation? I'll throw out a vote for a spanning-tree free IX design. I'd also throw up a flag of caution for allowing the IX network to be extended inside other carriers networks. Doing so only extends the failure domain of the IX, and makes it tougher to monitor and maintain. Now, OTOH, I think carrier sponsored "remote switches" with a connection into the core IX switches, and a prescribed participant facing config would be a better option, and better suited for the long haul. And to Jay's point, folks can still sell transport circuits to get folks connected into the exchange, just pop the other end into one of these "MICE Remote Switches". Honestly, I'm a little surprised that there is spanning tree running now across the IX. My vote would be for something along the lines of: - spanning tree free core/remote switches, managed under the guise of MICE - set config on participant facing ports - only allowing IPv4/IPv6/ARP - storm control set to low pps threshold or outright blocking of broadcast traffic besides ARP/ND packets - one MAC addr per participant facing port This recipe, IMHO, is the only way to avoid L2 meltdown in the future if more and more connection points are added. Thanks, Andrew ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Jay Hanke

> I haven't had any cross-vendor problems, even mixing RSTP and MSTP (in > configurations for which they are designed to mix). I think the problems come in more on the mixing vendors and more importantly mixing administrative domains with spanning tree. There are more than a couple of vendors with random spanning-tree quirks. Frankly, I'm surprised at the outpouring of love for spanning-tree on the list. I've on more than one occasion selected a vendor with a ring or a virtual chassis technology to avoid spanning-tree in the core. I was also thrilled at the prospect of something like TRILL. Can someone take it on to make a design recommendation? Jay ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Justin Krejci

We mix vendors a lot including on the Minneapolis wifi network using MST and rstp. So literally thousands of bridges talking, more or less, faithfully. Sure some bugs exist but when facing adversity one must adapt or flounder (Darwinism?). Getting vendors to fix bugs helps immensely too of course. And yes convergence is faster than vanilla STP. Sent via BlackBerry from T-Mobile -----Original Message----- From: Richard Laager <rlaager(a)WIKTEL.COM> Sender: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Tue, 20 Sep 2011 19:08:52 To: <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Remote MICE members? On Tue, 2011-09-20 at 17:01 -0700, Owen DeLong wrote: > On Sep 20, 2011, at 4:57 PM, Richard Laager wrote: > > > On Tue, 2011-09-20 at 15:13 -0700, Owen DeLong wrote: > >> Unfortunately, fast converging spanning tree tends to be vendor-specific. > > > > RSTP and MSTP are both standards. Aren't they fast enough? > > > > If you have two vendors with compatible implementations of them, perhaps. Admittedly, it's > been a while, but, last time I tried, the interoperability across multiple vendors wasn't there > once you departed from normal 90-second spanning tree. I haven't had any cross-vendor problems, even mixing RSTP and MSTP (in configurations for which they are designed to mix). I'm about to add another vendor to the mix, so we'll see if this blows up in my face now that I've publicly said it's been working. ;) Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Richard Laager

On Tue, 2011-09-20 at 17:01 -0700, Owen DeLong wrote: > On Sep 20, 2011, at 4:57 PM, Richard Laager wrote: > > > On Tue, 2011-09-20 at 15:13 -0700, Owen DeLong wrote: > >> Unfortunately, fast converging spanning tree tends to be vendor-specific. > > > > RSTP and MSTP are both standards. Aren't they fast enough? > > > > If you have two vendors with compatible implementations of them, perhaps. Admittedly, it's > been a while, but, last time I tried, the interoperability across multiple vendors wasn't there > once you departed from normal 90-second spanning tree. I haven't had any cross-vendor problems, even mixing RSTP and MSTP (in configurations for which they are designed to mix). I'm about to add another vendor to the mix, so we'll see if this blows up in my face now that I've publicly said it's been working. ;) Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Owen DeLong

On Sep 20, 2011, at 4:57 PM, Richard Laager wrote: > On Tue, 2011-09-20 at 15:13 -0700, Owen DeLong wrote: >> Unfortunately, fast converging spanning tree tends to be vendor-specific. > > RSTP and MSTP are both standards. Aren't they fast enough? > If you have two vendors with compatible implementations of them, perhaps. Admittedly, it's been a while, but, last time I tried, the interoperability across multiple vendors wasn't there once you departed from normal 90-second spanning tree. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 21, 2011

Re: Remote MICE members?

by Richard Laager

On Tue, 2011-09-20 at 15:13 -0700, Owen DeLong wrote: > Unfortunately, fast converging spanning tree tends to be vendor-specific. RSTP and MSTP are both standards. Aren't they fast enough? Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 20, 2011

Re: Remote MICE members?

by Jay Hanke

>> > That works great for CNS! > > I was thinking of other providers that might want to do the same thing. If you want to plop a switch in 511 or remotely, I don't think it's an issue to connect it into the MICE fabric. Actually there are a fair number of participants with similar setups who . Back to the original Grumpy's meeting we're going to err on the side of connectivity until it's a problem and then we can deal with it. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 20, 2011