Re: Command Preference?

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
>
>
>
> -----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
> >
> >
> > -----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
Received on Tue Mar 29 2011 - 20:06:42 ART