[113716] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: IXP

daemon@ATHENA.MIT.EDU (Arnold Nipper)
Sun Apr 19 14:53:44 2009

Date: Sun, 19 Apr 2009 20:53:31 +0200
From: Arnold Nipper <arnold@nipper.de>
To: Chris Caputo <ccaputo@alt.net>
In-Reply-To: <Pine.LNX.4.64.0904191725281.7743@nacho.alt.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1B13214A44A296C48708166D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.04.2009 19:43 Chris Caputo wrote

> On Sun, 19 Apr 2009, Mikael Abrahamsson wrote:
>> On Sat, 18 Apr 2009, Nick Hilliard wrote:
>> > - ruthless and utterly fascist enforcement of one mac address per=20
>> > port, using either L2 ACLs or else mac address counting, with no=20
>> > exceptions for any reason, ever.  This is probably the single more=20
>> > important stability / security enforcement mechanism for any IXP.
>>=20
>> Well, as long as it simply drops packets and doesn't shut the port or =

>> some other "fascist" enforcement. We've had AMSIX complain that our=20
>> Cisco 12k with E5 linecard was spitting out a few tens of packets per =

>> day during two months with random source mac addresses. Started=20
>> suddenly, stopped suddenly. It's ok for them to drop the packets, but =

>> not shut the port in a case like that.
>=20
> From the IX operator perspective it is important to immediately shut do=
wn=20
> a port showing a packet from an extra MAC address, rather than just=20
> silently dropping them.

We (DE-CIX) simply nail each MAC statically to the customer port and
allow traffic from these statically configured MAC addresses to enter
the switch fabric.

Initially this was done as a workaround as the F10 boxes didn't support
port-security. Meanwhile we think this is the best way to handle MAC
management. As a benefit there is no need to shut down customer ports
when frames from additional MACs arrive. These are simply ignored.

Works really great for us. YMMV.



Arnold
--=20
Arnold Nipper / nIPper consulting, Sandhausen, Germany
email: arnold@nipper.de       phone: +49 6224 9259 299
mobile: +49 172 2650958         fax: +49 6224 9259 333


--------------enig1B13214A44A296C48708166D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ63Mrrz6CwpRB/EwRAoASAJwKB6os/Z5CGxe+4tD+91MGT704tQCgliHL
GjWGCb+A4PzpWAqu4unTrwA=
=G4tm
-----END PGP SIGNATURE-----

--------------enig1B13214A44A296C48708166D--


home help back first fref pref prev next nref lref last post