OSPF and MTU

[briedcan]

I understand that when configuring an ATM link the MTU size must be the same on both ends of the circuit in order for OSPF neighbor relationships to form. My question is why when they are different does the state show either Init or Exchange? I thought that MTU agreement occured in either Ex-Start or Exchange and according to this document it does: http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a00800949f7.shtml#trouble_neigh_states Can someone please explain how and why this happens? Appreciated!

bc

[ruwhite · Accepted solution]

You are correct in stating the check occurs when transitioning to ex start, but we won't actually go into ex start unless the check succeeds. In other words, the check doesn't occur _in_ the ex start state, but when transitioning _to_ the ex start state, if that makes sense. That's why the routers stick in the init state, since we can't transition to the ex start state.

If the mtu's mismatch, but OSPF believes they match, I think you will get stuck in the exchange state. You shouldn't make it to the exchange state if your mtu's mismatch in the configuration, I don't think, unless your mtu changes while exchanging DBD's, or something like that.

Russ.W

[briedcan]

Thanks for the help Russ! I have another MTU related question that you might be able to field. When you have a DS3 on an ATM interface is there any benefit to having your MTU set higher than 1500 (what I typically set it to) or will this cause problems? It seems like with a higher MTU you could have more efficient use of bandwidth but it also seems like you might trigger jumbo frames (causing drops). Do you have any thoughts on this?

bc

[ruwhite]

It all depends on what sort of segment the packet source and sink are on, and the types of stuff you're doing in the middle. If all your hosts (servers and workstations) are on 1500 byte mtu segments, and you're not doing anything "special," then you don't really need to bump the mtu's in the middle. If, however, you are running tunnels, encryption, mpls, or other type sof things that are going to generate larger packets through the middle of your network, then bumping the mtu is really nice.

It could also make a difference if you're converging BGP, and would like to reduce the packet count across the wire. EIGRP won't transmit anything larger than a 1500 byte mtu no matter what the actual mtu is, so you won't get much help there.... IS-IS, I think, can operate over jumbo links, reducing packet count, but I'm not certain cisco supports it, or what happened to the drafts on that one. OSPF, I think can take advantage of larger MTU sizes, since LSAs are repackaged at every hop, anyway, so it might get some gain out of larger mtu's.

Hope that helps....

Russ.W

[briedcan]

Well here is my scenario. I have remote locations that are connected back to our data center via point-to-point( /32 ) ATM connections. On the remote side we use either the MC3810 or 2621XM. In the data center the point to points enter a 6500 after riding an MGX con as transport. In this instance would having the MTU set higher have any benifit or detriment? In some instances our end router sits in the same room as an MGX and connected with a DS3. Would these instances be any different?

bc

[ruwhite]

I don't think so--as long as you're not running anything that adds to the header size of the packet, it's not going to matter if the MTU on the wan links is the same as the MTU on the local links. It doesn't sound like you're doing anything that would add to the packet size on the routers themselves.

Of course, it's not going to do any harm to set the MTU higher, and it may save you headaches later, if something crops up that requires a larger MTU, and you don't remember to set it. So, setting it higher is fine, it's not hurting or helping anything at the moment, as long as both ends of every link are set the same.

Russ.W