nanog mailing list archives
RE: IXP
From: "Michael K. Smith - Adhost" <mksmith () adhost com>
Date: Mon, 20 Apr 2009 15:11:13 -0700
-----Original Message----- So here is an idea that I hope someone shoots down. We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc. As far as I can tell, the principal reason to use a shared fabric is
to
allow multiple connections to networks that may not justify their own dedicated ($$$$) router port. Once they do, they can move over to a PNI. However, an IXP is (at the hardware level at least) trying to achieve any-to-any connectivity without concern for capacity up to the port size of each port on every flow. Scaling this to multiple pieces of hardware has posed interesting challenges when the connection speed to participants is of the same order as the interconnection between IXP switches. So here is a hybrid idea, I'm not sure if It has been tried or seriously considered before. Since the primary justification for a shared fabric is cost
savings....
What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G. [Michael K. Smith - Adhost] This sounds like fertile ground for unintended consequences.
Unmanaged
spanning tree topological changes as three people, previously
connected
to their own switch and to others, now decide to connect to each other as well, using those inexpensive L2 ports.
If each port is in its own pVLAN or similar, and they are only allowed to talk to their uplinks and not other L2 ports on the same switch, loops are avoided. I should have hashed that point out with another line. Yes, strictly throwing up an unconfigured switch becomes a problem after the 2nd one goes in -- but only for those brave enough to peer with you and dumb enough to allow their switch to behave that way. The double-edged clue sword. Deepak [Michael K. Smith - Adhost] The problem is the model as you've presented it, or as I've read it anyway, allows that type of insertion as part of its root design. If all of the switches have to speak spanning tree because they may be connected to each other on some connection outside of your administrative control, then you have no control over what happens "over there" that causes issues with the STP domain. I'm a big fan of the operational simplicity of a L2 shared fabric with spanning tree disallowed by policy and configuration with all of its resources dedicated to forwarding frames. I'm not convinced that a more complex L3 shared architecture over a shared L2 fabric gets you any more security or resiliency, but it certainly keeps the exchange people busy! I should note that I do technical work for the Seattle Internet Exchange so I'm showing a bias. But, with that said, we have benefited greatly from this model, through consistent, tragedy free growth and very high uptime. Regards, Mike
Current thread:
- Re: IXP, (continued)
- Re: IXP Paul Vixie (Apr 18)
- Re: IXP Paul Vixie (Apr 17)
- Re: IXP Nick Hilliard (Apr 18)
- Re: IXP Paul Vixie (Apr 18)
- Re: IXP Jeff Young (Apr 18)
- Re: IXP vijay gill (Apr 19)
- Re: IXP Alan Hannan (Apr 19)
- RE: IXP Deepak Jain (Apr 20)
- RE: IXP Michael K. Smith - Adhost (Apr 20)
- RE: IXP Deepak Jain (Apr 20)
- RE: IXP Michael K. Smith - Adhost (Apr 20)
- Re: IXP Niels Bakker (Apr 20)
- Re: IXP Lamar Owen (Apr 21)
- RE: IXP Holmes,David A (Apr 22)
- Re: IXP Adrian Chadd (Apr 22)
- Re: IXP Richard A Steenbergen (Apr 17)
- Re: IXP Daniel Roesen (Apr 17)
- Re: IXP Randy Bush (Apr 17)
- Re: IXP Matthew Moyle-Croft (Apr 17)
- RE: IXP Deepak Jain (Apr 17)
- Re: IXP Stephen Stuart (Apr 17)