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.<div>
<br></div><div>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?</div>
<div><br></div><div>tl;dr Layer 2 was cheap and is easy.<br><div><br></div><div>--<br>Christopher Pollock,<br>io Networks Pty Ltd.<div>e. <a href="mailto:chris@ionetworks.com.au" target="_blank">chris@ionetworks.com.au</a><br>
p. 1300 1 2 4 8 16</div><div>d. 07 3188 7588</div><div>m. 0410 747 765</div><div>skype: christopherpollock</div><div><a href="http://twitter.com/chrisionetworks" target="_blank">twitter.com/chrisionetworks</a></div><div>
<div>
<a href="http://www.ionetworks.com.au" target="_blank">http://www.ionetworks.com.au</a><br>In-house, Outsourced.</div></div><br>
<br><br><div class="gmail_quote">On Thu, Sep 27, 2012 at 6:13 PM, Mark Tees <span dir="ltr"><<a href="mailto:mark.tees@digitalpacific.com.au" target="_blank">mark.tees@digitalpacific.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
<a href="http://blog.ioshints.info/2012/07/why-do-internet-exchanges-need-layer-2.html" target="_blank">http://blog.ioshints.info/2012/07/why-do-internet-exchanges-need-layer-2.html</a><br>
<br>
The points Ivan raises for layer-2 in that article appear to be along the lines of:<br>
<br>
* Simplicity<br>
* Scenarios where participants want run BGP directly between themselves.<br>
* Hardware costs (in the past maybe?).<br>
* All points towards bilateral peering.<br>
<br>
I only have experience with Pipe NSW IX and Equinix Peering. Read a little bit about LINX and AMS-IX.<br>
<br>
Judging from what I have read peering points like LINX moving to VPLS setups has not really helped the problem.<br>
<br>
Do the majority of people who connect to the peering fabrics in Australia just connect to the route servers in an MLP fashion?<br>
<br>
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.<br>
<br>
So, for MLP type setups is it feasible to use layer 3 switching between participants?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div><br></div></div>