RE: Command Preference?

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

-----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
>
>
> -----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
>
>
Received on Wed Mar 30 2011 - 09:07:42 ART