|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Paul Vinciguerra <pvinci@VinciConsulting.com> To: Tom Taylor <tom.taylor.stds@gmail.com>, NANOG list <nanog@nanog.org> Date: Fri, 31 Aug 2012 13:52:09 +0000 In-Reply-To: <5040BC58.7060808@gmail.com> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org You need to raise your MTU above that on the other side and do a ping size = sweep. Unlike at Layer-3 when you can use set a DF bit and get back an ICM= P error, at Layer-2 when you exceed the far side's MTU, the packets are sil= ently dropped. Paul Vinciguerra CCIE# 10291 120 W Park Avenue,=A0Suite 308 Long Beach, NY 11561 P: 516-977-2095 =A0. =A0F: 516-977-2482 =A0. =A0TF: 866-998-4624 vinciconsulting.com -----Original Message----- From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 Sent: Friday, August 31, 2012 9:30 AM To: NANOG list Subject: MTU mismatch on one link Has anyone run into a situation where the MTU at one end of a link was conf= igured differently from the MTU at the other end? How did you catch it? In general, do you see any need for a debugging tool to be standardized to = find such mismatches? Tom Taylor
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |