[j-nsp] OSPFv3 interoperability with another vendor

[Paul Goyette]

> After some more investigation following has been found:
> 
> Mastership mismatch is not the cause of the JNPR sending MS 
> bit on. It is
> done to signal the master to reset the state machine to 
> ExStart. JNPR does
> this because state machine went to BadLSReq and restarted negotiation.
> 
> Dec  4 01:59:28.631862 OSPF neighbor fe80::209:b4ff:fe30:114c 
> (ge-1/3/0.0)
> state changed from Exchange to ExStart due to BadLSReq (event 
> reason: no LSA
> corresponded to the link-state request) (nbr helped: 0) Dec  4
> 01:59:28.631895 OSPF neighbor fe80::209:b4ff:fe30:114c 
> (ge-1/3/0.0) state
> changed by event BadLSReq (event reason: no LSA corresponded to the
> link-state request)
> 
> The reason for this is the bad LS type, as interpreted by the JNPR;
> 
> Dec  4 01:59:28.631674   type Unknown (-1062723575), id 
> 0.0.0.1, adv rtr
> 192.168.1.4
> Dec  4 01:59:28.631692   type Unknown (-2147475455), id 
> 0.0.0.0, adv rtr
> 192.168.1.4
> 
> I suspect bad typecasting of the LSA's type field in either 
> the JNPR or the
> another vender router
> 
> As you (may) know this field is 16bit in OSPFv3 and 8 in OSPFv2
> 
> Please comment on this

-1062723575 --> 0xFFFF FFFF C0A8 2009
-2147475455 --> 0xFFFF FFFF 8000 2001

We've never seen his before, as far as I know.  It would be
extremely helpful to get a live packet capture of this LSReq
packet.  Second best would be to get corresponding detailed
debug trace from BOTH machines at the same time, so we can
see what the other machine thinks it is sending us.  

You should work this through normal support channels if at
all possible.