Priscilla Oppenheimer wrote: > > Jenny McLeod wrote: > > > > 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. > > I would assume it means Options too. > > > 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. > > It surprises me too from what I've read and seen in Sniffer > traces! I'm guessing that it's not a problem though. It's an > unused bit, so it can probably be set either way and the > recipient ignores it?
JMcL: That's what I'm hoping. The RFC says it should be cleared, but it also says that receiving stations should ignore unrecognised bits ;-) > > > Obviously the value of MTU being reported in the received DBD > > is also a concern! > > I've read that the MTU is set to zero for virtual links. Could > the mainframe think it's a virtual link?? > JMcL: Possibly. Or at least it might be something to do with this. After a bit more snooping around the mainframe definitions, we've found that a definition for a virtual interface on the m/f (sort of the equivalent of a loopback interface on a Cisco) has an MTU value defined for the non-working (or at least not completely working) IP stacks but not for the working stacks. Whether this has anything to do with the problem is, as yet, unknown, but it's one more thing for the mainframe guru to try fiddling with. Pardon if the description isn't very clear - I'm not very familiar with the mainframe end of this. > > > > 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? > > Could there be some sort of connectivity problem and the > router's ACKs aren't really getting to the mainframe??? I'm > thinking that just because the router's debug says the router > is sending something it doesn't mean it really got there. Like > one hand clapping? > JMcL: I don't think it's a *physical* connectivity issue, because hellos get through OK (apparently in both directions or the m/f wouldn't send DBDs at all, yes?) But it does look like the m/f is ignoring/not seeing the DBDs from the router, which I think is what it should do if the MTU advertised by the router is larger than what the m/f thinks it should be. > I wish I could be more help. Normally I wouldn't even attemp to > answer an OSPF question, but Chuck has been AWOL for a while. > Where's Pamela when we need her? ;-) > > Priscilla > > > > > Thanks, > > JMcL > > JMcL: we have a few things to try now on the mainframe end - including the old standard of "swap the order of the configuration items and see what the problem does". Obviously, being a core part of the network, interruptive testing is limited, but I'll bung up the resolution eventually (assuming we find one ;-). I think it's more likely to need a fix at the mainframe end, not the Cisco end. Thanks, JMcL Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57417&t=57410 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
