On Fri, Aug 31, 2012 at 7:30 AM, Tom Taylor wrote:
> Has anyone run into a situation where the MTU at one end of a link was
> configured 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 misma
Looks good.
On 31/08/2012 11:13 AM, Ben Bartsch wrote:
mturoute.exe works great
http://www.elifulkerson.com/projects/mturoute.php
...
If you don't exceed the MTU ever then it shouldn't matter, but unless
the MTUs are above what the protocol can handle on a specific link you
probably will. Most commonly this happens on DSL links using PPPoE (the
MTU needs to be at 1492 for the overhead) and it causes all kinds of odd
behavior
My question was actually prompted by an issue that comes up with
multicast routing, where either the underlying RIB is static or the
unicast routing protocol managed to operate successfully. In any event,
in some cases the PIM messages get large enough to be lost at layer 2.
One proposal befor
mturoute.exe works great
http://www.elifulkerson.com/projects/mturoute.php
On Fri, Aug 31, 2012 at 9:47 AM, Justin M. Streiner wrote:
> On Fri, 31 Aug 2012, Andrew K. wrote:
>
> Besides routing protocol convergence is there any service issues with
>> running mismatched MTU? Assuming the pac
On Fri, 31 Aug 2012, Andrew K. wrote:
Besides routing protocol convergence is there any service issues with running
mismatched MTU? Assuming the packet flow does not exceed the smallest MTU
value.
Not really, but given the bursty nature of IP traffic, that's a very
dubious assumption.
In
Besides routing protocol convergence is there any service issues with
running mismatched MTU? Assuming the packet flow does not exceed the
smallest MTU value.
On 8/31/2012 10:28 AM, Dan White wrote:
On 08/31/12 09:30 -0400, Tom Taylor wrote:
Has anyone run into a situation where the MTU at o
On 08/31/12 09:30 -0400, Tom Taylor wrote:
Has anyone run into a situation where the MTU at one end of a link
was configured 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?
Perf
Subject: Re: MTU mismatch on one link
On Fri, 31 Aug 2012, Tom Taylor wrote:
> Has anyone run into a situation where the MTU at one end of a link was
> configured differently from the MTU at the other end? How did you catch it?
>
> In general, do you see any need for a debuggin
On Fri, Aug 31, 2012 at 01:52:09PM +, Paul Vinciguerra wrote:
> 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 ICMP
> error, at Layer-2 when you exceed the far side's MTU, the packets are
>
On Fri, 31 Aug 2012, Tom Taylor wrote:
Has anyone run into a situation where the MTU at one end of a link was
configured 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?
Some rou
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 ICMP
error, at Layer-2 when you exceed the far side's MTU, the packets are silently
dropped.
Paul Vinciguerra
CCIE# 10291
120 W Park Avenue, Suite
12 matches
Mail list logo
