> Date: Sat, 18 Apr 2009 16:35:51 +0100 > From: Nick Hilliard <n...@foobar.org> > > ... i just don't care if people use L2 connectivity to get to an exchange > from a router somewhere else on their LAN. They have one mac address to > play around with, and if they start leaking mac addresses towards the > exchange fabric, all they're going to do is hose their own > connectivity.
yeah we did that at PAIX. if today's extremenetworks device has an option to learn one MAC address per port and no more, it's because we had a terrible time getting people to register their new MAC address when they'd change out interface cards or routers. hilarious levels of fingerpointing and downtime later, our switch vendor added a knob for us. but we still saw typo's in IP address configurations whereby someone could answer ARPs for somebody else's IP. when i left PAIX (the day MFN entered bankruptcy) we were negotiating for more switch knobs to prevent accidental and/or malicious ARP poisoning. (and note, this was on top of a no-L2-devices rule which included draconian auditing rights for L2/L3 capable hardware.) > As you've noted, there is a natural progression for services providers > here from shared access to pni, which advances according to the business > and financial requirements of the parties involved. If exchange users > decide to move from shared access peering to PNI, good for them - it > means their business is doing well. But this doesn't mean that IXPs don't > offer an important level of service to their constituents. Because of > them, the isp industry has convenient access to dense interconnection at > a pretty decent price. yes, that's the progression of success. and my way of designing for success is to start people off with VNI's (two-port VLANs containing one peering) so that when they move from shared-access to dedicated they're just moving from a virtual wire to a physical wire without losing any of the side-benefits they may have got from a shared-access peering fabric. > > Q in Q is not how i'd build this... cisco and juniper both have > > hardware tunnelling capabilities that support this stuff... it just > > means as the IXP fabric grows it has to become router-based. > > Hey, I have an idea: you could take this plan and build a tunnel-based or > even a native IP access IXP platform like this, extend it to multiple > locations and then buy transit from a bunch of companies which would give > you a native L3 based IXP with either client prefixes only or else an > option for full DFZ connectivity over the exchange fabric. You could > even build a global IXP on this basis! It's a brilliant idea, and I just > can't imagine why no-one thought of it before. :-). i've been known to extend IXP fabrics to cover a metro, but never beyond.
