On Wed, Oct 03, 2012 at 04:09:52PM +1300, Mark Frater said:
Anyone know what the rational is around the "official policy around APE" of only having a single MAC address per port?
It's a pretty common caveat, if you look at the T&C's of other IX's (LINX, AMIX, et al) they've certainly had such restrictions in the past - I don't know if they still do, but that's coz it's no longer my problem to know :-). The historic rationale was based on the observation that it's very hard to prevent loops in a shared ethernet (where you don't control the edge devices) - either you a) expose your internal loop prevention process (xSTP or EAPS or whatever) to the edge devices, in which case you get into all sorts of ugly cross vendor interactions, edge devices trying to be the root of the STP, and so forth, or you b) turn off your internal loop process in ports facing the devices of the IX participants, in which case your internal fabric should be pretty stable, but you have no mechanism to prevent loops between two edge ports. Most IX operators plump for option (B), on the basis that one should at least try and keep one's own house in order. So the MAC limit is a way of reducing the impact of loops when they do happen - if ISP A has two connections to the exchange, and loops them together, then the only traffic that can get round the loop will the two MAC addresses associated with ISP A's two ports. That changes the loop event from being a fullon broadcast/unicast flooding extravaganza to one where the only packets getting looped are packets from the ISP doing the looping. This is much easier/quicker to track down and fix, and with the right broadcast/multicast storm controls in place, often isn't particularly impactful on other IX participants.
I would have thought that there was some technical merit in allowing at least 2 to cover rotuer replacement (without MAC address spoofing)
I think you'll find that the limit is implemented as "one unique MAC address", rather than a specific MAC - if you flap the copper, or wait five minutes, then you can start over with a new MAC. No MAC spoofing required. That said, if you've got a chatty layer 2 device in front of your peering router, your MAC may have had to have been fixed to a specific device, so that the switch in front didn't keep getting the slot.
and offer some peer router diversity options (e.g. either via separate peering sessions or VRRP implementation.)
For the limit to be useful, it doesn't have to be one MAC, it has to match how many MAC's the port will see under normal conditions, so that when the port goes abnormal, it can't suddenly add a bunch of MAC's from the exchange and reannounce the looped traffic. VRRP? Surely you jest. It's a peering exchange, not a microsoft exchange :-). Cheers Simon -- Simon Blake simon(a)katipo.co.nz Geek for hire +64 22 402 0044