[168199] in North American Network Operators' Group
Re: best practice for advertising peering fabric routes
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Jan 15 10:53:00 2014
From: Leo Bicknell <bicknell@ufp.org>
In-Reply-To: <38C51356-6825-4D57-B29F-E03F177B687F@arbor.net>
Date: Wed, 15 Jan 2014 09:52:43 -0600
To: "Dobbins, Roland" <rdobbins@arbor.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_F1FCB9EA-5549-4E26-BADB-D5C9937DBD9D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Jan 15, 2014, at 9:37 AM, "Dobbins, Roland" <rdobbins@arbor.net> =
wrote:
> But what I'm saying is that that whether or not they want to use jumbo =
frames for Internet traffic, it doesn't matter, because PMTU-D is likely =
to be broken either at the place where the traffic is initiated, the =
place where the traffic is received, or both - so any nonsense in the =
middle, especially on IXP networks in particular, isn't really a =
significant issue in and of itself.
Your assertion does not match my deployment experience.
When I have deployed endpoints that have working PMTU-D, I have 99.999% =
success with the ISP's in the middle having working PMTU-D. It even =
works fine for 9K providers connected to 1500B exchange points, because =
the packet-too-big typically originates from the input side of the =
router (the backbone link to the IXP router). Indeed, the only place =
I've seen it broken is where the ISP 9K peers at an exchange, and the =
"far end" ISP runs a < 9K backbone (like 4470), so the far end =
IXP-router does the packet-to-big, and originates it from the exchange =
LAN, which because it's no longer in the table fails to past uRPF.
(Business class) ISP's don't break PMTU-D, end users break it with the =
equipment they connect. So a smart user connecting equipment that is =
properly configured should be able to expect it to work properly.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--Apple-Mail=_F1FCB9EA-5549-4E26-BADB-D5C9937DBD9D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIVAwUBUtauy7N3O8aJIdTMAQLZ4hAAor1CHLkb7Jq+SEU0Sleldj9rvv62opB5
4Fuu4wsmJZROhxZXGlRGMRVzTBaIyGvIiLd/0qJAaamsRWnAaWBNdBnHkstlcV/E
+I7tNGb0eAAjG9S4bnAvc5YksGwBup0WTow9f/y6vUNG+RwLVBjFdXUgKj39grek
EH/ZFEwtgwG+tzo+jaR2sysC8BQ49EceMdyXcewqgCpEbo5eel+VMYjxW3FfKXWI
9N88wrEmGNI5A3r8RdOZvuu72oMknboAvgHV0eAewoNsQDc0OlTrKw/FjpsWTbKD
ePkgyE/JsvEpRvotZUCUfjsNRof4xec6+S6aFSg1VS3TNhvozRfF+UNrF58afR97
iw3aQCOJdtOkNnCTu8AnbZadge0VIbALyiaFYUQ9e8EjdNtiOkjt4kW/qWAkTcW1
eq55irfBRyl+jqfqJAV9kjjSNrEaDrxc7VtM96ILTlc5uRkkRiInDkllx2CQCPh7
bucP7LhETZDsmDw78MDYU9R0OONMs5oFKBiD1Uyx/QfDxY/wXbaF2vcP0NzNXJww
GqXWmnasC2xEW97nlCopz0T3rso+agF6ogpPDSKl9uwdECvZZWlkcL/FEq15MWIv
2VOFklYrWTNzNVfNoLh8rcVuTRT8rWAyOnS5poLajmF2gOgx7PoAevYlfdBw69e4
Qq8H6mjc3+A=
=9zps
-----END PGP SIGNATURE-----
--Apple-Mail=_F1FCB9EA-5549-4E26-BADB-D5C9937DBD9D--
