[AusNOG] Why-do-internet-exchanges-need-layer-2?

[Christopher Pollock]

PIPE peering doesn't look a whole lot different now than it did ten years
ago, and people still seem happy with how it works.  I wouldn't be
surprised if some of the same 7200s are doing the route-server-ing,
although perhaps someone still there can shed some light on the evolution
of the IX over the last few years.  At the time, the hardware to handle
routing all that traffic that would've come through the routers didn't
exist at a reasonable price.  The only technically and financially feasible
solution was Layer 2.  The other great thing about it was that it allowed
us to well and truly stay out of the layer-3 traffic path.  People would
complain that we were blocking traffic & ACL-ing things, but we were
nothing but a set of switches, which was our absolute confirmation that any
filtered packets were not our doing.  In addition to that, managing and
maintaining a more complex infrastructure would've required a lot more
eyeball time.

I think the real answer as to why the IX doesn't look like what you're
describing is simply that it would be a lot of work to transition to, for
not a lot of benefit.  It would provide better protection from things going
awry at Layer-2 (as IX-connected devices are wont to do), but I don't see
anyone going out of their way to complicate the infrastructure to achieve
it.  Anyone who's worked at any other peering points got any perspective on
this?

tl;dr Layer 2 was cheap and is easy.

--
Christopher Pollock,
io Networks Pty Ltd.
e. chris at ionetworks.com.au
p. 1300 1 2 4 8 16
d. 07 3188 7588
m. 0410 747 765
skype: christopherpollock
twitter.com/chrisionetworks
http://www.ionetworks.com.au
In-house, Outsourced.



On Thu, Sep 27, 2012 at 6:13 PM, Mark Tees
<mark.tees at digitalpacific.com.au>wrote:

> This one has been bugging me for a while now given the common place
> problem of someone storming on one of the peering networks. Trying to work
> out if it is just an old school train of thought or if there are real life
> limitations or advantages on using layer3 in multi lateral peering setups.
>
>
> http://blog.ioshints.info/2012/07/why-do-internet-exchanges-need-layer-2.html
>
> The points Ivan raises for layer-2 in that article appear to be along the
> lines of:
>
> * Simplicity
> * Scenarios where participants want run BGP directly between themselves.
> * Hardware costs (in the past maybe?).
> * All points towards bilateral peering.
>
> I only have experience with Pipe NSW IX and Equinix Peering. Read a little
> bit about LINX and AMS-IX.
>
> Judging from what I have read peering points like LINX moving to VPLS
> setups has not really helped the problem.
>
> Do the majority of people who connect to the peering fabrics in Australia
> just connect to the route servers in an MLP fashion?
>
> The people who use the IX ports for private connections could possibly
> have a second port provisioned or a single port VLAN'd o MPLS CCC'd? Cross
> connect costs might be a problem.
>
> So, for MLP type setups is it feasible to use layer 3 switching between
> participants?
>
> Participants ports would ideally be routed interfaces on layer 3 switches
> with a BGP session to the switch they connect to. You could then limit a
> switch to only X number of members and each switch exchanges routes via
> iBGP either in a mesh or RR setup.
>
> If a customer then goes nuts and starts flooding their port it should be
> contained to the device they connect to. Hopefully, ACLs in place prevent
> problem traffic from getting to the control plane.
>
> There are other things that could be done on layer 2 in terms of ACLs for
> customer ports and monitoring that could prevent some of these problems we
> see. My first thought towards that would be as soon as customer port X
> multicast/broadcast counters start exceeding the average in a big way then
> shut it down.
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20120927/a38dcc50/attachment.html>