Re: Command Preference?

Hey team,

I never imagined such a great thread when I posted the original question.
Thank you everyone thus far. You are my teachers.

**** First lab test ****

I too labbed it up ... BUT I used routers and not switches as the original
question. 2 routers and 150 routes. R1 and R3 -- R3 has the 150
routes.

With the IP MTU command, I cannot create a problem.

With the interface mtu command, I can get problems to occur. My lab is
perhaps a bit wacky though ... I set the MTU on one side to be 500, and then
1100.

Sending router (R3):

*Mar 30 03:04:23.915: OSPF: Send DBD to 1.1.1.1 on Serial0/0/1 seq 0x428 opt
0x52 flag 0x3 len 1252
*Mar 30 03:04:23.915: OSPF: Retransmitting DBD to 1.1.1.1 on Serial0/0/1
[18]

The receiving router's MTU is too small, and the sending router's packets
are dropped. The neighbor relationship never comes up.

**** 2nd test ****

labbed with Router and Switch!!!!!!
*
My 3560 will not let me set the interface or global MTU to anything less
than 1500.* Hummm ... makes it harder to break things

I cannot really create this problem with my switch and router. I can tell
the switch to ignore the MTU differences, or use the MTU of 1500 for routing
... which helps solve the problem of mtu mismatch.

*****

So ... my theory at this point ... knowing Cisco, is that this was a real
problem in the past. Probably this messed a lot of people up in production
...

However ... my belief is that Cisco has likely made it harder to screw
things up when routing between a switch and a router.

It is still easy to break a router to router OSPF session. But thankfully,
it is not as easy or likely to ever mess up a OSPF session on a switch.

*****

Any thoughts on this testing? Should I re-test this in another way?

TIA

.

On Tue, Mar 29, 2011 at 9:07 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Brian McGahan @ 29/03/2011 20:23 -0300 dixit:
>
> Test it out and see for yourself. It's always been a known design problem
>> for OSPF,
>>
> > that's the the MTU check is there to begin with.
>
> AFAIK, it's a design *feature*.
> At least, that's Moy point of view, citing from "Anatomy of an internet
> protocol":
> ...
> Over these data links, it is possible that two neighboring routers will
> disagree on the largest packet that can be sent over the link, which
> causes problems in forwarding. As one router sends a packet that is too
> big for the other to receive, it becomes impossible to deliver large
> packets over certain paths. (One might think that IP fragmentation
> would deal with this situation, but although fragmentation nicely
> handles links with differing MTUs, it assumes that all routers attached
> to a given link agree on that link's MTU.) As a result, OSPF was
> modified to detect and avoid links having MTU mismatches.
>
> i.e. it's done on purpouse.
>
> Given that PMTU discovery can be hard to get done because of security
> wizards, having the routing protocol choose routes over a consistent MTU
> path sounds right. We should not resort to tcp mss tinkering if it was
> always that way.
>
> -Carlos
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Andrew Lee Lissitz
all.from.nj_at_gmail.com
Blogs and organic groups at http://www.ccie.net