[107472] in North American Network Operators' Group
Re: Force10 Gear - Opinions
daemon@ATHENA.MIT.EDU (Mark Tinka)
Thu Sep 4 04:34:49 2008
From: Mark Tinka <mtinka@globaltransit.net>
To: nanog@nanog.org
Date: Thu, 4 Sep 2008 16:34:37 +0800
In-Reply-To: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com>
Cc: nanog@merit.edu
Reply-To: mtinka@globaltransit.net
Errors-To: nanog-bounces@nanog.org
--nextPart1947144.bnC2uHxVjj
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday 04 September 2008 15:47:01 Paul Wall wrote:
> uRPF strict as a configuration default, on customers
> without possible asymmetry (multihoming, one-way
> tunneling, etc) is not a bad default. But when the
> customers increase in complexity, the time might come to
> relax things some. It's certainly not a be-all-end-all.=20
Our experience with uRPF has been some unpleasant badness=20
when dealing with a few private peers. Our private peering=20
routers don't hold full routes (naturally), so we had to=20
relax (even) the loose-mode uRPF scheme we had for this=20
because some of our peers were leaking our routes to the=20
Internet.
Customer-facing, strict-mode uRPF is standard practice=20
across the board for all customers single-homed to us.=20
Customers for whom we know have multiple connections get=20
loose-mode uRPF. For good measure, each edge router has=20
outbound ACL's on the core-facing interfaces catching RFC=20
1918 and RFC 3330 junk.
On border (transit) routers, we employ loose-mode uRPF with=20
no issues, since these carry a full table. In addition, we=20
catch inbound RFC 1918 and RFC 3330 with ACL's; and just to=20
see how crazy things get, we stick our own prefixes in=20
there since we really shouldn't be seeing them as sources=20
from the wild.
It's quite interesting how many matches we log, particularly=20
for own addresses, on transit and peering links. Of course,=20
the RFC 1918 and RFC 3330 are not without increment as=20
well.
No filtering in the core.
Cheers,
Mark.
--nextPart1947144.bnC2uHxVjj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iQIcBAABAgAGBQJIv52eAAoJEGcZuYTeKm+GVAIP/1MBu20U+V5r0lu1PsRstBbR
1NB2M5cv987eCQrMjbrxa1WI+BhUPuAeMTlD2FvyaFSNDll807g9lkNHqHZOL3QH
oMLbusbS1XdgR4SJ/Uk4Tga0wbdggrHFlbYBdV0bRZ+fK8IKUkAi3GJrnfk1tzQt
Ptr6PTyc96mvL6wG/Gunp/6A6ieGD4bUmCWc+8ggprhfn/3dRkD5qrJL9Wi+vUmQ
DHi+bYPWnwX/n9Cb5JHkO0uPmJZykw1PBA+ZH5w9v5YhbCi5qOCKGdsqGOYKXBoc
duogwi5Aya8aRCZ47mBUAv2ZOAE5FHtaoeJk/i1cGFZqHMwz0K1bswjAdO3H3If5
FSnUtZaN7sp6DPD9eeVAT4noyjLwk1TUb81oOdAL7Sx+N0uxqEpexMwm7+edybjy
CDiw3JrOw53PkB4C+IIUG0n6av3sGSbONOi7RpPwL4YNOlOIqPBrdIcA1JhIgKNH
p1b8lhMoK1sBQzRArnChg1VlwYFh223NtYr1dfpxs1qv6+ekp6JQ6VYIuX+RL5GP
e8PVdeAvdi7AYZfOsG+UzREgPZKNLsbCwqW+zgUQL6DpUOCeAENobAkxTzl0BaCo
LeXVibSwCJRYqYsnlViL4ooxZ0u08bIjq/qy6cpKtuNKoW7uzIu3eHmGPPMMaXdb
OvIix+vOmjSm4B5FijXm
=G5y7
-----END PGP SIGNATURE-----
--nextPart1947144.bnC2uHxVjj--
