[j-nsp] OSPF Debug
Paul Goyette
pgoyette at juniper.net
Tue Feb 24 00:28:09 EST 2004
Don't get me wrong, having this list is great. Having other
folks to help our users with their problems/questions/etc.
lightens our load. And Juniper personnel often jump in and
give quick answers here as well.
However, as Dorian indicates, when an issue gets to a point
where detailed technical assistance or extended and on-going
involvement of Juniper staff occurs, we need to manage the
interaction in a more formal manner. This is for our own
benefit as well as for the customer/user, as it provides a
tracking and measurement mechanism.
We (Juniper) need to jump in every now and then when an issue
reaches an admittedly nebulous threshold and remind both the
customer and the Juniper person(s) involved that the formal
support channel should be used to bring an issue to a proper
resolution. Unfortunately, this odious task often falls to
myself.
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of Dorian Kim
Sent: Monday, February 23, 2004 7:46 PM
To: Danny McPherson
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] OSPF Debug
Well.. I don't know the answer to your question, but...
When Dave O'Leary and I set up this list initially, the original intention
was to set up a list that would draw vendor specific questions off of
nanog, and to provide a forum for juniper users to share hints and tips
etc., just like cisco-nsp...
Both *-nsp lists have had the vendor people on it from the beginning to
help folks out, and it's very nice of them to do so, but neither lists were
ever meant to be official support vehicles of the vendors. Hence, it seems
reasonable to me that the juniper folks on this list redirect questions
to the regular support channel beyond a certain point.
-dorian
On Mon, Feb 23, 2004 at 08:13:25PM -0700, Danny McPherson wrote:
> 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
_______________________________________________
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