Re: Command Preference?

The nice thing is that OSPF is doing exactly what it is supposed to do.

If you separate things in MTU enough to still cause a problem, then OSPF
will correct itself even if the MTU is ignored. (If ignored, everything
is processed and life is good. If things are missed, OSPF will correct
and kill the peering session to start from scratch) But the bottom line
is that no routing loop can be created out of this.

Sorry for my gap in posting. I decided to sleep as I'm six hours ahead
of where I normally am at the moment. :)

Some relevant notes from the RFC about exchanges:

When the database exchange starts (EXSTART), routers will send DBD's
with the interface's MTU size in the options field. The initial ones
indicating EXSTART will have the I, M and MS bits set but no other
information.

In EXCHANGE, you'll actually get information about routes.

"In state Exchange the Database Description Packets actually
contain summaries of the link state information contained in the
router's database. Each LSA in the area's link-state database
(at the time the neighbor transitions into Exchange state) is
listed in the neighbor Database summary list. Each new Database
Description Packet copies its DD sequence number from the
neighbor data structure and then describes the current top of
the Database summary list. Items are removed from the Database
summary list when the previous packet is acknowledged.

Database Description packets must be processed in
sequence, as indicated by the packets' DD sequence
numbers. If the router is master, the next packet
received should have DD sequence number equal to the DD
sequence number in the neighbor data structure. If the
router is slave, the next packet received should have DD
sequence number equal to one more than the DD sequence
number stored in the neighbor data structure. In either
case, if the packet is the next in sequence it should be
accepted and its contents processed as specified below.

Else, generate the neighbor event SeqNumberMismatch and
stop processing the packet. "

This all occurs until the last packet is sent from each side (whoever's
master) and indicates "ExchangeDone".

Appendix Note 8: "Note that it is possible for a router to
resynchronize any of its fully established adjacencies by setting the
adjacency's state back to ExStart. This will cause the other end of the
adjacency to process a SeqNumberMismatch event, and therefore to also go
back to ExStart state."

So yes... There's a potential issue. However, there are mechanisms
built into OSPF in order to detect and deal with them. And then there
are commands that also set to deal with them.

So you're saying that as long as we have Catalyst switches, we can do
fine... But if you have other equipment without a 'system mtu routing'
command, that the ONLY viable solution is to set MTU to be the same
everywhere? No.

Great discussion though, and it's always fun to lab things up....

By the way, MTU is settable as well. Or at least someone forgot to tell
my 2811 about that restriction:

NDC-R2(config)#int f0/0
NDC-R2(config-if)#mtu ?
  <64-1600> MTU size in bytes

NDC-R2(config-if)#mtu 1600
NDC-R2(config-if)#
NDC-R2(config-if)#do sh int f0/0 | in MTU
  MTU 1600 bytes, BW 100000 Kbit/sec, DLY 100 usec,
NDC-R2(config-if)#

R2(config-if)#ip mtu 1500
R2(config-if)#do sh int f0/0 | in MTU
  MTU 1600 bytes, BW 100000 Kbit/sec, DLY 100 usec,
R2(config-if)#do sh ip int f0/0 | in MTU
  MTU is 1500 bytes
R2(config-if)#

Have fun with it all! But KNOW what your router is doing! :)

*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/30/11 7:07 AM, Narbik Kocharians wrote:
> Very nice discussion, i truly enjoyed it.
>
> All From-NJ,
>
> You will NOT see a routing loop, i have tried it in many ways and this is
> NOT happening. I did not see one way routes, or anything like that.
> You can change the IP MTU or the MTU under a serial interface or an FastE
> interface between the two routers or even bunch of routers, and you will not
> see that. I set one side to 1500 and the other side to 1100 and i was able
> to exchange 100 routes and then i tried 150 and i gave up. Because it worked
> like expected.
>
> I guess it depends on your preference. But i agree with what Brian said in
> his last post:
> *What I should have said is that MTU mismatch is a well known design
> problem, in which the OSPF control plane attempts to alert you of; it's not
> an OSPF design issue per-se.*
>
> But i kind of disagree with routing loops or networks not being reachable,
> because i did not see that in the test.
>
> On Tue, Mar 29, 2011 at 9:44 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>
>> Right, that's the key; the DBD MTU check is done on purpose. What I should
>> have said is that MTU mismatch is a well known design problem, in which the
>> OSPF control plane attempts to alert you of; it's not an OSPF design issue
>> per-se. Disabling the MTU check fixes the symptom, but not the underlying
>> problem.
>>
>> Also note that if you test this there is an underlying difference between
>> the "mtu" command and the "ip mtu". Also FastE doesn't support changing the
>> physical MTU, so you'd need to test this on GigE, TenGigE, or POS. Seeing
>> the problem is less likely on POS though, since some encapsulations don't
>> work if the MTU doesn't match in the first place.
>>
>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>> bmcgahan_at_INE.com
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com <http://www.ine.com/>
>>
>> On Mar 29, 2011, at 8:08 PM, "Carlos G Mendioroz" <tron_at_huapi.ba.ar>
>> wrote:
>>
>>> Brian McGahan @ 29/03/2011 20:23 -0300 dixit:
>>>> 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.
>>> AFAIK, it's a design *feature*.
>>> At least, that's Moy point of view, citing from "Anatomy of an internet
>>> protocol":
>>> ...
>>> Over these data links, it is possible that two neighboring routers will
>>> disagree on the largest packet that can be sent over the link, which
>>> causes problems in forwarding. As one router sends a packet that is too
>>> big for the other to receive, it becomes impossible to deliver large
>>> packets over certain paths. (One might think that IP fragmentation
>>> would deal with this situation, but although fragmentation nicely
>>> handles links with differing MTUs, it assumes that all routers attached
>>> to a given link agree on that link's MTU.) As a result, OSPF was
>>> modified to detect and avoid links having MTU mismatches.
>>>
>>> i.e. it's done on purpouse.
>>>
>>> Given that PMTU discovery can be hard to get done because of security
>>> wizards, having the routing protocol choose routes over a consistent MTU
>>> path sounds right. We should not resort to tcp mss tinkering if it was
>>> always that way.
>>>
>>> -Carlos
>>>
>>> --
>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>
>> 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 Wed Mar 30 2011 - 07:35:54 ART