Re: Command Preference?

To all,

I asked this few e-mails ago and I am asking you guys to please share a
topology where Ignoring the MTU will cause a routing loop, I really LOVE to
see that and I am sure everyone else will kill to see it as well. I am
always willing to learn.

My last 2 questions on this GR8 subject:

In a live production network, obviously a decent size network, where things
are working correctly, would your *ever* touch the MTU as your first choice?

In a production network have you ever seen two routers connected back to
back with varying MTUs, and I mean in 100s of bytes, for example where one
end is 1500 and the other end is 750? Remember in a production network of a
decent size between two routers that are connected back to back. If so, why
did the other router/device have an MTU of 750, i am sure there must have
been a reason, and how did you configure OSPF.

On Wed, Mar 30, 2011 at 10:05 AM, Brian McGahan <bmcgahan_at_ine.com> wrote:

> Yes. The key is that in the real world the MTU must match, otherwise the
> database can become unsynchronized. When this occurs, transient loops can
> occur. Ignoring the MTU fixes the symptom, but not the problem itself.
>
> You can see a more detailed example of the problem here:
> http://goo.gl/WcZ2W.
>
> HTH,
>
> 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 30, 2011, at 8:06 AM, "Ametewee, Selassie K. (Lockheed Martin
> IS&GS)" <Selassie.Ametewee_at_va.gov> wrote:
>
> > So to spin it back to the real world, can you use the mtu command on the
> > interface to increase the size to 1500 to be compatible with the other
> > side?
> >
> > Thanks
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > Brian McGahan
> > Sent: Tuesday, March 29, 2011 7:24 PM
> > To: Scott Morris; ccielab_at_groupstudy.com
> > Subject: RE: Command Preference?
> >
> > 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_note09186a008009
> > 3f0d.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