Re: Command Preference?

I just labbed this up and let me tell you guys what i saw:

R1 is connected to R2
R1's interface has an MTU of 1500
R2's interface has an MTU of 1000

R1 is advertising 100 routes to R2
and i do NOT see any issues whatsoever.

My question is should i increase the number of routes to 200? At what point
would we see a problem, has anyone tested this?
Brian you said earlier that you saw that in a production network, how many
routes did you have there? Do you remember?

I agree with Abdul, This is an excellent tech discussion.

On Tue, Mar 29, 2011 at 5:06 PM, Abdul Anekwe <rslab007_at_gmail.com> wrote:

> Brian, & Scott,
>
> Brilliant write up. Full of technical details, RFC references, real world
> relevance, but most of all, lab exam implications.
>
> Great stuff...
>
>
>
>
>
> On Tue, Mar 29, 2011 at 7:23 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>
> > Actually you don't get stuck in EXSTART. The neighbors will be FULL but
> > the database won't be fully synchronized everywhere. A common case for
> this
> > would be if some routers on a LAN are using large frame sizes for GigE,
> but
> > not all of them. Ultimately it depends on how large the LSAs are that
> need
> > to be sent. If they exceed the MTU of the larger side and need
> > fragmentation, then the side with the smaller MTU won't be able to
> receive
> > them. The key to this design problem is that sometimes it will happen
> with
> > an MTU mismatch, but not always. The result is non-deterministic which
> > makes it difficult to troubleshoot. In a case like this, using "ip ospf
> > mtu-ignore" would not help you, it would actually make the problem less
> > obvious to solve.
> >
> > 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.
> >
> > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > bmcgahan_at_INE.com
> >
> > Internetwork Expert, Inc.
> > http://www.INE.com <http://www.ine.com/>
> >
> >
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > Scott Morris
> > Sent: Tuesday, March 29, 2011 5:36 PM
> > To: ccielab_at_groupstudy.com
> > Subject: Re: Command Preference?
> >
> > Great write up!
> >
> > But what you are describing is exactly the reason that the "ip ospf
> > mtu-ignore" command was created. Yes, you'll drop packets, and yes,
> > you will get stuck in an EXSTART phase as one side is discarding the
> > packets received that are too large.
> >
> >
> >
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml
> >
> > But making a conscious choice to use this command in order to overcome
> > this will not have any adverse effects. Unless you are using it in a
> > situation that involves someone else's links in the middle (L2?) that
> > have constrained MTUs and will drop things.... And you'd recognize that
> > fairly quickly anyway by the idea that you wouldn't attain a full
> > synchronization! :) (In other words, do homework first, then test
> > appropriately... But in non-CCIE-esque topologies, problems should not
> > be seen)
> >
> > Is it nice that MTUs match everywhere? Probably a good thing, it's
> > there for a reason. Are there other methods (like "system mtu routing
> > 1500" on your cat's)??? Yup. Should you know what problem you're
> > seeing and solve it within the constraints of the lab? Yup.
> >
> > Should you worry about the after effects of implementing this command?
> > Nope. Not if you've done the homework before implementing it.
> >
> > Just my two cents for the evening....
> >
> >
> >
> >
> > *Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713,
> >
> > CCDE #2009::D, JNCIE-M #153, JNCIE-ER #102, CISSP, et al.
> >
> > CCSI #21903, JNCI-M, JNCI-ER
> >
> > swm_at_emanon.com
> >
> >
> > Knowledge is power.
> >
> > Power corrupts.
> >
> > Study hard and be Eeeeviiiil......
> >
> >
> > On 3/29/11 6:49 PM, Brian McGahan wrote:
> > > Actually it *can* harm the network. The issue is that the OSPF
> > HELLO, Database Description (DBD), Link-State Request (LSR), and
> Link-State
> > Acknowledgement (LSAck) packets are generally small, but the Link-State
> > Update (LSU) packets are generally not.
> > >
> > > When establishing a new neighbor, the DBD packet is used to tell
> > the neighbors what LSAs are in the database, but not to give the details
> > about them. Specifically the DBD contains the LSA Header information,
> but
> > not the actual LSA payload. The idea behind this is to optimize flooding
> in
> > the case that the receiving router already received the LSA from another
> > neighbor, in which case flooding does not need to occur during adjacency
> > establishment.
> > >
> > > For example, suppose that you and I, routers A and B, both have
> > neighbors C and D, and the database is synchronized. If you and I form a
> > new adjacency, my DBD exchange to you will say that I have LSAs A, B, C,
> and
> > D in my database. Since you are already adjacent with C and D, and I am
> > adjacent with them, you already have all of my LSAs, possibly with the
> > exception of the new link that connects us. This means that even though I
> > describe LSAs A and B to you with my DBD packet, you don't send an LSR to
> me
> > for them, which means I don't send you an LSU about them. This is the
> > normal optimization of how the database is exchanged so that excessive
> > flooding doesn't occur. The problem with MTU mismatch however, is when
> you
> > and I establish an adjacency and *don't* already know anything about each
> > others' database, which means that a full flooding procedure must occur.
> > >
> > > Suppose now that you, router A, know about LSAs A1 through An in
> > your database, and I, router B, know about LSAs B1 through Bn. When we
> > establish adjacency your DBD to me will describe A1-An, while mine will
> > describe B1-Bn. Since I don't have A1-An, I will send you an LSR about
> > them, and likewise since you don't have B1-Bn, you will send an LSR about
> > those to me. When you reply back to me with the LSUs about A1-An, it is
> > highly likely that the LSU packet itself will contain more than one LSA
> in
> > the payload, potentially up to your MTU when the packet is generated.
> The
> > idea behind this is that since you need to send me more than one LSA,
> it's
> > more efficient to send them in as few LSUs as possible, instead of
> sending
> > one LSA per LSU. The problem occurs in this flooding procedure when your
> > MTU is larger than mine.
> > >
> > > If your MTU is 1500 bytes, and my MTU is 1000 bytes, any LSU you
> > send me over 1000 bytes will be dropped as I receive it. This is not a
> > transmission problem on your side, but is a receiving problem on my side.
> > The result will be that our adjacency forms, but our databases do not
> > become synchronized. The best case scenario will be that I can't send
> > traffic to certain destinations; the worst case scenario is that SPF
> > calculation fails and a loop occurs in the topology.
> > >
> > > To prevent this case, the DBD packets contains each of our MTUs.
> > This allows to routers to decide whether they should even bother
> flooding
> > in the first place. If you send me your DBD and the MTU says 1500 bytes,
> > and my DBD sent to you says 1000 bytes, we won't bother sending LSRs or
> LSUs
> > to each other, because we know that it is likely that database
> > synchronization will fail.
> > >
> > > The reason that this matters is that the "ip ospf mtu-ignore"
> > command is not a fix to the underlying problem. Instead it is simply an
> > exception to the OSPF adjacency state machine. Per RFC 2328, OSPF
> Version
> > 2, the following should occur:
> > >
> > >
> > > 10.6. Receiving Database Description Packets
> > >
> > > This section explains the detailed processing of a received
> > > Database Description Packet.
> > > <snip>
> > > If the Interface MTU field in the Database Description packet
> > > indicates an IP datagram size that is larger than the router
> can
> > > accept on the receiving interface without fragmentation, the
> > > Database Description packet is rejected. Otherwise, if the
> > > neighbor state is:
> > > <snip>
> > >
> > > This means that if you configure "ip ospf mtu-ignore", the DBD
> > state machine skips the MTU check. This however, does not mean that the
> > database will properly synchronize. So like Tyson said, "Preferably you
> > will fix the underlying issues by fixing the design instead of applying
> > 'CCIE' tactics to work around issues."
> > >
> > > Within the scope of the lab, yes you should understand what this
> > command does. Within the scope of a real OSPF design, no, you should not
> > use it. Instead you should ensure that the MTUs actually *do* match in
> the
> > network, which would prevent the case of a failure of the database to
> > synchronize.
> > >
> > >
> > > HTH,
> > >
> > > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > bmcgahan_at_INE.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.INE.com <http://www.ine.com/>
> > >
> > >
> > > -----Original Message-----
> > > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
> Of
> > Vitali Aivazov
> > > Sent: Tuesday, March 29, 2011 8:49 AM
> > > To: Tyson Scott
> > > Cc: Larry Hadrava; Narbik Kocharians; Cisco certification; ALL From_NJ
> > > Subject: Re: Command Preference?
> > >
> > > What if MTU was changed on purpose, so to modify MTU value just for
> OSPF
> > > adjacency to be formed is risky unless the reason of initial MTU change
> > is
> > > clear.
> > >
> > > In real life scenario I would use ignore MTU check on OSPF to get
> > adjacency
> > > formed, at least this will not harm existing network. However, in a lab
> > > scenario it all depends on wording of a question.
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> 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