On Wed, 2002-11-13 at 20:27, Jenny McLeod wrote: > OK, I'll admit this is a real-life problem, not strictly a study question. Ack, I seem to have stirred something up here :-) I really didn't object to real life scenarios, just those that are ultra specific to a given network. Anyway, onward and upward.
> I have a couple of OSPF adjacencies that refuse to start up. Just to make > this entertaining, these are not router to router - they are Cisco to > mainframe, over a CIP. > Five IP stacks neighbour the router - two are OK, three get stuck in > EXSTART/EXCHANGE. The five IP stacks also connect to a different router, > and these adjacencies are fine. > It looks to me like the classic MTU mismatch symptoms, but a printout of the > m/f definitions shows the MTUs to be 4096, as does "show int" on the > router. I'll get the m/f guru to check the definitions for white space - I > don't know if that will affect it. There have been various m/f changes > lately (and a couple of router ones) errors may have crept into the configs. > > What has me baffled is some of the debug output from the router (debug ip > ospf events). > > Nov 14 11:51:14.121 ESuT: OSPF: Rcv DBD from x.x.x.x on Channel6/0 seq > 0x3DCDF2DA opt 0x2 flag 0x7 len 32 mtu 0 state EXCHANGE > Nov 14 11:51:14.121 ESuT: OSPF: Send DBD to x.x.x.x on Channel6/0 seq > 0x3DCDF2DA opt 0x42 flag 0x2 len 1472 My money is on either the mtu mismatch (master seems confused here) or the multicast nature of dbd process cause folks to get confused. Bit 2 in options is the E bit where set (0x2) means stub and unset means normal area. Both agree on the stubbiness of the area, so that should be fine. Bit 3 is the O bit and setting it refers to ones capability with opaque LSAs. The flags seem cool as the first side is master/initial and the slave is properly recognized. Hence, from the above, only the MTU really stand out as odd. > The debug doco isn't particularly detailed for this command, but I assume > opt refers to the options field. RFC 2328 seems to think that the first two > bits of the options field should be cleared, so the value of 0x42 being sent > by the router surprises me. Keep in mind that 2328 isn't really all that new :-) If you skim 2370, the opaque bit is defined Obviously the value of MTU being reported in the received DBD is also a > concern! > > Other debug output indicates that the m/f sends the same DBD several times > (same seq), which the router acks, then after this is received several times > the router claims > Nov 14 11:51:20.037 ESuT: OSPF: EXCHANGE - OPTIONS/INIT not match > Nov 14 11:51:20.037 ESuT: OSPF: Bad seq received from 92.1.2.20 on Channel6/0 Maybe the multicast medium is creating some chaos here. Have you tried (or can you) turn off all but two routers and see if they work alone? > Is anyone aware of any other gremlins that cause similar symptoms? Or any > other ideas? > > Thanks, > JMcL Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57467&t=57410 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
