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

-----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
Received on Tue Mar 29 2011 - 18:23:37 ART