Sniffer on a CIP? Not that I'm aware of. Unfortunately I can't really do any detailed debugging on the router, either, as it's a core router and crashing it due to overloading with debugging would make me rather unpopular. I don't believe a DR/BDR is required on this link - it's set to 0.0.0.0 for all the working neighbours on the link.
Any hints on what might cause a bad checksum just for these neighbours? Thanks, JMcL Steven A. Ridder wrote: > > It looks like the options in the packets do not march. Any way > to get a > sniffer on there to see what each is sending as options. It > could also be a > priority issue if the network is a broadcast/nbma network where > neither is > being elected a DR? Finally, could a checksum be bad? > > -- > > RFC 1149 Compliant. > > > > ""Jenny McLeod"" wrote in message > news:200211140127.BAA14210@;groupstudy.com... > > OK, I'll admit this is a real-life problem, not strictly a > study question. > > 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 > > > > 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. > > 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 > > > > 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=57418&t=57410 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
