IXP

Mon Apr 20 22:11:13 UTC 2009

> -----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