[j-nsp] OSPF Debug

Jack.W.Parks at alltel.com Jack.W.Parks at alltel.com
Mon Feb 23 10:27:25 EST 2004


Is this a local patch fiber patch, or over some long haul transport?
Could it be different default MTUs for each of the PICs (don't have any
PB-2GE-SX)?

Some Questions:

Are the MTUs the same?
Is the Hello Timer the same?
Is the Deal Interval the same?


Jack

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Scotty
Sent: Sunday, February 22, 2004 8:32 PM
To: 'Raymond Cheh'; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] OSPF Debug


Raymond,

> I'd suggest doing some 'traceoptions hello detail' and that'd capture 
> the hello packets on both routers. Also, I personally like to do 
> monitor traffic on the interfaces as it is simpler to see if you 
> receives the OSPF packets on the interfaces from the other routers.

Ok I did that on the M160 and I get this (summarized)

# run monitor traffic interface ge-0/0/0.0
verbose output suppressed, use <detail> or <extensive> for full protocol
decode Listening on ge-0/0/0.0, capture size 96 bytes

21:04:35.454751 Out IP 10.10.10.3 > 224.0.0.5: OSPFv2 Hello length: 44
21:04:41.121834  In IP 10.10.10.4.4405 > 10.10.10.3.bgp: P
3886338746:3886338773(27) ack 145002704 win 16384 <nop,nop,timestamp
1665163887 130574421>: BGP, length: 27 21:04:43.285516 Out IP 10.10.10.3
> 224.0.0.5: OSPFv2 Hello length: 44 21:04:51.466302 Out IP 10.10.10.3 >
224.0.0.5: OSPFv2 Hello length: 44 21:04:51.619965  In IP
10.10.10.4.4405 > 10.10.10.3.bgp: P 27:111(84) ack 1 win 16384
<nop,nop,timestamp 1665164936 130575218>: BGP, length: 84 ^C 94 packets
received by filter 0 packets dropped by kernel

The monitored box is the M160 (down state) 10.10.10.3  As I can see
there is nothing seen on the 224.0.0.5 from .4 ..  yet tcp seems to work
fine as you can see the BGP session is active.
 
> The "attempt" state is interesting. Does it really say that? The M20 
> is in 'init' state, so it is seeing the hello's from the M160. And so,

> the question is whether the M160 is receiving the hello packets and if

> it is rejecting them for some reasons.

Correction, "Attempt" only happens in un-numbered mode..  dead time
counts down to zero and it goes to "down"  From what I can tell its not
getting the packets.  Why I wonder.

The hello detail stuff on the M20 shows that .4 does indeed send hello
packets to 224.0.0.5:

Feb 22 21:19:46 OSPF sent Hello 10.10.10.4 -> 224.0.0.5 (ge-0/3/0.0, IFL
36)
Feb 22 21:19:46   Version 2, length 48, ID 10.20.30.42, area 0.0.0.0
Feb 22 21:19:46   checksum 0xffff, authtype 65535
Feb 22 21:19:46   mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 128
Feb 22 21:19:46   dead_ivl 40, DR 1010.10.4, BDR 0.0.0.0

> My guess is that when you tried using ip addresses on the interfaces, 
> you can ping between the routers because the bgp session is working. 
> Are you using the GE ip addresses for your bgp endpoints? If you are 
> using the loopback addresses, they may not go through this GE link.

Correct iBGP peer to the localhost IP (router-id) did not work, makes
sense though there is no IGP on the M160. so this peer is setup direct
to the GE interface IP's

> Let me know what you find! I am quite sure there aren't any changes 
> between 5.6 and 6.2 in basic OSPF that may cause this problem but I'll

> set it up myself and verify that. Thanks.

Right, looking at the release notes I don't see anything shocking.

-Scotty

_______________________________________________
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. 




More information about the juniper-nsp mailing list