Solved: Ospf Hello Message

manish-young · ‎07-20-2003

Can some one tell me.

In Order for OSPF to form an adjacency with its newly discoverd neighbor, Which all config perameters must match??

mark-obrien · ‎07-20-2003

Manish,

All routers in the area must have their options agree. There are bits in the options field of OSPF packets indicating whether the sending router can accept external routes (i.e., whether or not the router understands the area to be a stub area) and bits indicating whether the sending router can accept Type 7 LSAs (i.e., whether or not the router understands the area to be a NSSA). So, the routers must agree on the area's definition - stub, NSSA or "normal". Also, the subnet masks must agree.

Regards,

Mark

View solution in original post

mark-obrien · ‎07-20-2003

The area ID, subnet and mask, HelloInterval, RouterDeadInterval, Options and Authentication must all agree before full adjacency is established. I have also seen some instances, probably IOS version related, in which a full adjacency did not occur until MTU matched.

HTH

Mark

manish-young · ‎07-20-2003

hi mark,

thanks for you post. i will be taking bsci soon so i was taking boson bsci test . over there they says that: Area, hello & dead, Authentication and "Stub area id" should match. I think stub area id will be used when router are in stub area, so according to me only area id, hello/dead and authentication

should match

correct me if i am wrong

with regards

Manish

mark-obrien · ‎07-20-2003

Manish,

All routers in the area must have their options agree. There are bits in the options field of OSPF packets indicating whether the sending router can accept external routes (i.e., whether or not the router understands the area to be a stub area) and bits indicating whether the sending router can accept Type 7 LSAs (i.e., whether or not the router understands the area to be a NSSA). So, the routers must agree on the area's definition - stub, NSSA or "normal". Also, the subnet masks must agree.

Regards,

Mark

ruwhite · ‎07-21-2003

The MTU must match, as well.

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.

RFC2328, section 10.6.

Rather than wait for the DBD exchange, however, Cisco checks the MTU in the hello packet for a matching value. This isn't strictly "by the spec," but it has the same effect--the adjacency won't be formed if the MTU's are configured differently on either end.

:-)

Russ.W

mark-obrien · ‎07-22-2003

Russ,

Thanks for that explanation. I've seen the phenomenon of routers not becoming adjacent when their MTUs don't match and I appreciate the confirmation. However, I don't find a field in the Hello packet, or in the OSPF header, for the MTU. How is the MTU communicated?

Mark

ruwhite · ‎07-22-2003

Okay, you made me go look at the code! :-) It's not in the hello, we _do_ check at the dbd exchange. We will go two way, but will not build the adjacency, since the first packet in exstart/negotiate will show the mismatched MTU, which will cause the adjacency to fail.

I've always thought we stuck it in the hello somplace, since it shows up as a mismatch in debug ip ospf adjacency. I also discovered a command I didn't know about while I was there--ip ospf mtu-ignore, that tells OSPF to ignore the mtu mismatch on dbd exchange. I don't think you'd actually want to use this command (you could create a black hole through mtu mismatch), but you never know....

:-)

Russ.W

borek · ‎07-24-2003

By the way, I recently encountered the MTU mismatch problem on a Cat3550+EMI - the OSPF was stuck at EXSTART stage. After lot of troubleshooting (and some swearing) I discovered that when you put port on a 3550 into a routed mode its MTU is increased to 1546 bytes! One needs to set "ip mtu 1500" on the iface for OSPF to work properly.