[j-nsp] OSPF Debug

Mon Feb 23 19:22:59 EST 2004

Raymond,

You Juniper guys are too smart. ok so I do indeed have those messages
and show interface extensive shows this:

  Filter statistics:
  (snip)
    Input packet rejects                 36556
    Input DA rejects                     36556
    Input SA rejects                         0

And I have these in my messages log:
Feb 21 22:32:34  edge1 fpc0 GE(0/0): link 0 filter entry 0 is already
free
Feb 21 22:32:34  edge1 fpc0 IFFPC: 'IFD Ether mfilter set' (opcode 57)
failed
Feb 21 22:32:34  edge1 fpc0 ifd 128; Ether mfilter error (7)

So to fix this i simply moved the patch and the ip to ge0/1/0.0 on the
M160 and it worked fine the first time.  Does this mean i have a
defective PB-2GE-SX ?  I guess the only real way to find out is to put
it in another FPC, in a known working slot to figure out if it is my
FPC2 or my PIC.  Or is there a better wait to diagnose this?

-Scotty

On Mon, 2004-02-23 at 17:56, Raymond Cheh wrote:
> 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
> 
> 