Re: Command Preference?

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
>
>
> -----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