[j-nsp] OSPF log messages

Hitesh Patel Hitesh at nildram.net
Tue Aug 17 04:06:36 EDT 2004


If all the other aspects are eliminated like area ID, authentication,
hello/dead interval, MTU, option field etc., it could well be firewall
and/or packet filters preventing them to pass Init state to 2-way ? It might
be allowing diagnostic pings, SSH traffic but not IP routing(OSPF packet
ID89 ?) If that is not the case, possibly local router is not seeing it's
own router ID in the neighbour field in hello packet ?

Worth checking on other router on same media to see what they see to be
adjecent, neighbour/s, DR/BDR ...

Regards

Hitesh Patel

-----Original Message-----
From: Paul Goyette [mailto:pgoyette at juniper.net] 
Sent: 16 August 2004 19:29
To: Jack.W.Parks at alltel.com; robert.walton at ffastfill.com;
juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] OSPF log messages


You're not receiving a corresponding DbD packet from your neighbors.  If
there was an MTU mismatch, it would be detected by comparing your MTU with
the value in a received DbD packet, but you're apparently not receiving any
DbD from the neighbors.

The I bit is still set in the DbDs you're sending out, so you're still
negoriating which router will be master and which is slave.  No actual DD
contents are being exchanged yet.

Check the far side to see what it is receiving and maybe sending...

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of
Jack.W.Parks at alltel.com
Sent: Monday, August 16, 2004 11:12 AM
To: robert.walton at ffastfill.com; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] OSPF log messages


Timer (Hello/Dead) mismatches?

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Robert Walton
Sent: Monday, August 16, 2004 11:27 AM
To: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] OSPF log messages


Hi,

	I'm seeing Hello packets being exchanged no problem however the when
i trace the database-description packets i see the following continuously in
the logs.

Aug 16 17:20:53 OSPF resend last DBD to 217.27.24.34
Aug 16 17:20:53 OSPF resend last DBD to 217.27.24.44
Aug 16 17:20:53 OSPF sent DbD 217.27.24.45 -> 217.27.24.34 (fe-0/3/1.212,
IFL 0x56)
Aug 16 17:20:53   Version 2, length 32, ID 146.101.129.217, area 0.0.0.0
Aug 16 17:20:53   checksum 0x0, authtype 0
Aug 16 17:20:53   options 0x42, i 1, m 1, ms 1, seq 0x926fe06b, mtu 1500
Aug 16 17:20:53 OSPF sent DbD 217.27.24.45 -> 217.27.24.44 (fe-0/3/1.212,
IFL 0x56)
Aug 16 17:20:53   Version 2, length 32, ID 146.101.129.217, area 0.0.0.0
Aug 16 17:20:53   checksum 0x0, authtype 0
Aug 16 17:20:53   options 0x42, i 1, m 1, ms 1, seq 0x926ea536, mtu 1500
Aug 16 17:20:58 OSPF resend last DBD to 217.27.24.34
Aug 16 17:20:58 OSPF sent DbD 217.27.24.45 -> 217.27.24.34 (fe-0/3/1.212,
IFL 0x56)
Aug 16 17:20:58   Version 2, length 32, ID 146.101.129.217, area 0.0.0.0
Aug 16 17:20:58   checksum 0x0, authtype 0
Aug 16 17:20:58   options 0x42, i 1, m 1, ms 1, seq 0x926fe06b, mtu 1500
Aug 16 17:20:58 OSPF resend last DBD to 217.27.24.44
Aug 16 17:20:58 OSPF sent DbD 217.27.24.45 -> 217.27.24.44 (fe-0/3/1.212,
IFL 0x56)
Aug 16 17:20:58   Version 2, length 32, ID 146.101.129.217, area 0.0.0.0
Aug 16 17:20:58   checksum 0x0, authtype 0
Aug 16 17:20:58   options 0x42, i 1, m 1, ms 1, seq 0x926ea536, mtu 1500
Aug 16 17:21:01 OSPF resend last DBD to 217.27.24.34

I've checked the MTU at both ends and they are fine so there shouldn't be a
problem of one neighbor sending DBD's larger than the MTU... I've also
performed large pings to all adjacencies.

waltonro at FFALCR002A> ping 217.27.24.34 size 10000
PING 217.27.24.34 (217.27.24.34): 10000 data bytes
10008 bytes from 217.27.24.34: icmp_seq=0 ttl=255 time=29.623 ms 10008 bytes
from 217.27.24.34: icmp_seq=1 ttl=255 time=17.913 ms 10008 bytes from
217.27.24.34: icmp_seq=2 ttl=255 time=17.699 ms 10008 bytes from
217.27.24.34: icmp_seq=3 ttl=255 time=17.733 ms 10008 bytes from
217.27.24.34: icmp_seq=4 ttl=255 time=18.050 ms 10008 bytes from
217.27.24.34: icmp_seq=5 ttl=255 time=27.562 ms 10008 bytes from
217.27.24.34: icmp_seq=6 ttl=255 time=17.812 ms ^C
--- 217.27.24.34 ping statistics ---
8 packets transmitted, 7 packets received, 12% packet loss round-trip
min/avg/max/stddev = 17.699/20.913/29.623/4.889 ms

waltonro at FFALCR002A> ping 217.27.24.44 size 10000
PING 217.27.24.44 (217.27.24.44): 10000 data bytes
10008 bytes from 217.27.24.44: icmp_seq=0 ttl=255 time=19.937 ms 10008 bytes
from 217.27.24.44: icmp_seq=1 ttl=255 time=17.728 ms 10008 bytes from
217.27.24.44: icmp_seq=2 ttl=255 time=17.455 ms 10008 bytes from
217.27.24.44: icmp_seq=3 ttl=255 time=17.621 ms ^C
--- 217.27.24.44 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss round-trip
min/avg/max/stddev = 17.455/18.185/19.937/1.016 ms

So there shouldn't be any layer-2 issues, can anyone point me in the
direction of where i can go from here??

cheers,
Rob

-----Original Message-----
From: Jody Holmes [mailto:skwire at skwire.net]
Sent: 16 August 2004 09:26
To: Robert Walton
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] OSPF log messages


*
Quoting "Robert Walton" <robert.walton at FFastFill.com>
@ (8/16/2004 2:18:35 AM):

> Quick question for you OSPf experts, what does the following log 
> message mean? [Time stamp] OSPF periodic xmit from w.x.y.z to 
> 224.0.0.5 (IFL 78)

That address is the AllOSPFRouters multicast address.  OSPF Hello packets
are sent out on this address.  The only time Hello packets are unicast is on
an NBMA segment.


--
Jody Holmes   [~]  |  "Have no fear of perfection --
skwire at skwire.net  |   you'll never reach it."  S. Dali




________________________________________________________________________
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify
security at ffastfill.com

This email has been scanned for all viruses by the FFastFill Email Security
System.
________________________________________________________________________

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
****************************************************************************
**************
The information contained in this message, including attachments, may
contain privileged or confidential information that is intended to be
delivered only to the person identified above. If you are not the intended
recipient, or the person responsible for delivering this message to the
intended recipient, ALLTEL requests that you immediately notify the sender
and asks that you do not read the message or its attachments, and that you
delete them without copying or sending them to anyone else.


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
 
 



More information about the juniper-nsp mailing list