Re: Command Preference?

Gr8 job, have you ever tested this condition?

On Tue, Mar 29, 2011 at 10:21 AM, Steve Di Bias <sdibias_at_gmail.com> wrote:

> Brian, excellent write up. For the record when I originally posted my
> response I was clearly posting my answer from a CCIE test perspective, and
> not the real world. However that being said I do agree with you from real
> world perspective.
>
> On Tue, Mar 29, 2011 at 10:16 AM, Laidlaw, Patrick A. <
> Patrick.Laidlaw_at_wwt.com> wrote:
>
> > Brian,
> >
> > That was a great thanks for the explanation.
> >
> >
> > Patrick
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > Brian McGahan
> > Sent: Tuesday, March 29, 2011 9:50 AM
> > To: Vitali Aivazov
> > Cc: Cisco certification
> > Subject: RE: Command Preference?
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> -Steve Di Bias
>
>
> 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