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
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
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
Simon Blake simon(a)katipo.co.nz
Geek for hire +64 22 402 0044