Re: Command Preference?

Very nice discussion, i truly enjoyed it.

All From-NJ,

You will NOT see a routing loop, i have tried it in many ways and this is
NOT happening. I did not see one way routes, or anything like that.
You can change the IP MTU or the MTU under a serial interface or an FastE
interface between the two routers or even bunch of routers, and you will not
see that. I set one side to 1500 and the other side to 1100 and i was able
to exchange 100 routes and then i tried 150 and i gave up. Because it worked
like expected.

I guess it depends on your preference. But i agree with what Brian said in
his last post:
*What I should have said is that MTU mismatch is a well known design
problem, in which the OSPF control plane attempts to alert you of; it's not
an OSPF design issue per-se.*

But i kind of disagree with routing loops or networks not being reachable,
because i did not see that in the test.

On Tue, Mar 29, 2011 at 9:44 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:

> Right, that's the key; the DBD MTU check is done on purpose. What I should
> have said is that MTU mismatch is a well known design problem, in which the
> OSPF control plane attempts to alert you of; it's not an OSPF design issue
> per-se. Disabling the MTU check fixes the symptom, but not the underlying
> problem.
>
> Also note that if you test this there is an underlying difference between
> the "mtu" command and the "ip mtu". Also FastE doesn't support changing the
> physical MTU, so you'd need to test this on GigE, TenGigE, or POS. Seeing
> the problem is less likely on POS though, since some encapsulations don't
> work if the MTU doesn't match in the first place.
>
> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> bmcgahan_at_INE.com
>
> Internetwork Expert, Inc.
> http://www.INE.com <http://www.ine.com/>
>
> On Mar 29, 2011, at 8:08 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
>
>
>
>
>
>
>
>

-- 
*Narbik Kocharians
*CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com <http://www.micronicstraining.com/>
Sr. Technical Instructor
*Ask about our FREE Lab Voucher with our Boot Camps*
YES! We take Cisco Learning Credits!
Training & Remote Racks available
Blogs and organic groups at http://www.ccie.net