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?

> 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??

> 
> 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?

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




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=57414&t=57410
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to