> 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. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp