[j-nsp] OSPF Debug
Raymond Cheh
rcheh at juniper.net
Mon Feb 23 17:56:15 EST 2004
Scotty,
Since the m5 can see both the incoming and outgoing OSPF hellos
and from the trace, the m160 does not see any incoming OSPF hellos,
it points to possible GE problems on the M160 side. The ospf hello
packets being sent from the M5 does not reach the routing-engine on
the M160.
To confirm that this is the case, I am wondering if you may
look into messages to see if you see these messages:
Feb 23 13:15:19 router fpc# IFFPC: 'IFD Ether mfilter set' (opcode 57)
failed
Feb 23 13:15:19 router fpc# ifd 133; Ether mfilter error (1)
and if you try a 'show interface ge-#/#/# extensive', look at
the filter statistics section and see if there are any 'Input DA
rejects' such as this:
Filter statistics:
Input packet count 129
Input packet rejects 127
Input DA rejects 127 <---- incrementing
Input SA rejects 1
Fortunately, it doesn't point to an interoperability problem
between JunOS 5.6 and 6.2.
If you don't see those error messages, it may be something else and
we'll need to do some more tracing....
Please let us know. Thanks.
Raymond
-----Original Message-----
From: Chris Summers
Sent: Sunday, February 22, 2004 8:04 PM
To: Scotty; Raymond Cheh; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] OSPF Debug
Scotty,
Unnumbered links should only be used on pt-pt type interfaces and not on
broadcast interfaces.
Would it be possible to see the entire ospf and corresponding interface
configs from both routers?
Is there any firewall filter applied to either interface?
thanks,
chris
At 09:32 PM 2/22/2004 -0500, Scotty wrote:
>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
More information about the juniper-nsp
mailing list