[j-nsp] OSPF Debug

Paul Goyette pgoyette at juniper.net
Mon Feb 23 23:43:39 EST 2004 

Yes.

For support from Juniper technical staff, you require a support
contract.

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of Danny McPherson
Sent: Monday, February 23, 2004 7:13 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] OSPF Debug


Being that this is an open list for Juniper-related discussions,
as to leverage experience of others, perhaps rather than opening
a case, I have to ask...

Do these _frequent referrals to "open a case" require a support
contract with Juniper?

-danny

On Feb 23, 2004, at 5:28 PM, Paul Goyette wrote:

> Scotty,
>
> For further support you will need to open up a case with out
> Technical Support folks.  An Email to support at juniper.net will
> be sufficient.
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of Scotty
> Sent: Monday, February 23, 2004 4:23 PM
> To: Raymond Cheh
> Cc: juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] OSPF Debug
>
>
> 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
>>
>>
>
> _______________________________________________
> 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
>

_______________________________________________
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