Mailing List Archive

Scotty,

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.

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.

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.

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.

Raymond

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
Sent: Sunday, February 22, 2004 11:34 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] OSPF Debug




Im trying to debug an OSPF issue between an M20 (5.6R1.3), interface is
P-1GE-SX going to an M160 (6.2R1.5) and that interface is a PB-2GE-SX.

M20 side seems to be the problem. Basic area 0.0.0.0 setup, textbook
example. I;ve tried numbered and unnumbered interfaces. The M20 side
always is in state "init" it see's the hello and gets the router-id of
the
M160, but the M160 side always goes from "attempt" to state "down"
after
dead-timers expire. A 'show ospf neighbor' shows the neighbor in state
init
on the M20 side and "down" on the M160 side.

I'm thinking that I am forgetting something really stupid or there is
some
sort of compatibility issue. It is clear that the M20 is not sending
its
HELLO packets *or* the M160 is sending it's HELLO and not listening for
the
other side. If you came across this same issue, where would you look
first?


So far I have not seen anything alarming in 'flag all details' on either
router in the traceoptions, further the interfaces do work fine, in fact
I
have an iBGP session between these two routers using these exact same
interfaces. I have verified that MTU is exactly the same, Ive tried
encaps/vlan-tagging, etc just to test things and I always end up with
the
same result. The M160 is a new router getting inserted into network, my
M20
has been around for awhile now and working great with OSPF. Im hoping
it is
as simple as a 5.6/6.2 compatibility problem because that is easy to fix
and
would explain all the hair sitting next to both boxes.

-Scotty

sounds like at least one side is configured as an NBMA link???

chris

At 03:06 PM 2/22/2004 -0800, Raymond Cheh wrote:
>Scotty,
>
>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.
>
>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.
>
>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.
>
>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.
>
>Raymond
>
>-----Original Message-----
>From: juniper-nsp-bounces@puck.nether.net
>[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
>Sent: Sunday, February 22, 2004 11:34 AM
>To: juniper-nsp@puck.nether.net
>Subject: [j-nsp] OSPF Debug
>
>
>
>
>Im trying to debug an OSPF issue between an M20 (5.6R1.3), interface is
>P-1GE-SX going to an M160 (6.2R1.5) and that interface is a PB-2GE-SX.
>
>M20 side seems to be the problem. Basic area 0.0.0.0 setup, textbook
>example. I;ve tried numbered and unnumbered interfaces. The M20 side
>always is in state "init" it see's the hello and gets the router-id of
>the
>M160, but the M160 side always goes from "attempt" to state "down"
>after
>dead-timers expire. A 'show ospf neighbor' shows the neighbor in state
>init
>on the M20 side and "down" on the M160 side.
>
>I'm thinking that I am forgetting something really stupid or there is
>some
>sort of compatibility issue. It is clear that the M20 is not sending
>its
>HELLO packets *or* the M160 is sending it's HELLO and not listening for
>the
>other side. If you came across this same issue, where would you look
>first?
>
>
>So far I have not seen anything alarming in 'flag all details' on either
>router in the traceoptions, further the interfaces do work fine, in fact
>I
>have an iBGP session between these two routers using these exact same
>interfaces. I have verified that MTU is exactly the same, Ive tried
>encaps/vlan-tagging, etc just to test things and I always end up with
>the
>same result. The M160 is a new router getting inserted into network, my
>M20
>has been around for awhile now and working great with OSPF. Im hoping
>it is
>as simple as a 5.6/6.2 compatibility problem because that is easy to fix
>and
>would explain all the hair sitting next to both boxes.
>
>-Scotty
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp

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

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@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp

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@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Scotty
Sent: Sunday, February 22, 2004 8:32 PM
To: 'Raymond Cheh'; juniper-nsp@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@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.

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@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@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp

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@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@puck.nether.net
> >http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

Scotty,

For further support you will need to open up a case with out
Technical Support folks. An Email to support@juniper.net will
be sufficient.

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
Sent: Monday, February 23, 2004 4:23 PM
To: Raymond Cheh
Cc: juniper-nsp@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@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@puck.nether.net
> >http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

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@juniper.net will
> be sufficient.
>
> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
> Sent: Monday, February 23, 2004 4:23 PM
> To: Raymond Cheh
> Cc: juniper-nsp@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@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@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

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@juniper.net will
> >be sufficient.
> >
> >-----Original Message-----
> >From: juniper-nsp-bounces@puck.nether.net
> >[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
> >Sent: Monday, February 23, 2004 4:23 PM
> >To: Raymond Cheh
> >Cc: juniper-nsp@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@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@puck.nether.net
> >>>http://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >>
> >
> >_______________________________________________
> >juniper-nsp mailing list juniper-nsp@puck.nether.net
> >http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >_______________________________________________
> >juniper-nsp mailing list juniper-nsp@puck.nether.net
> >http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

Yes.

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

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Danny McPherson
Sent: Monday, February 23, 2004 7:13 PM
To: juniper-nsp@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@juniper.net will
> be sufficient.
>
> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
> Sent: Monday, February 23, 2004 4:23 PM
> To: Raymond Cheh
> Cc: juniper-nsp@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@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@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

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@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Dorian Kim
Sent: Monday, February 23, 2004 7:46 PM
To: Danny McPherson
Cc: juniper-nsp@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@juniper.net will
> >be sufficient.
> >
> >-----Original Message-----
> >From: juniper-nsp-bounces@puck.nether.net
> >[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Scotty
> >Sent: Monday, February 23, 2004 4:23 PM
> >To: Raymond Cheh
> >Cc: juniper-nsp@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@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@puck.nether.net
> >>>http://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >>
> >
> >_______________________________________________
> >juniper-nsp mailing list juniper-nsp@puck.nether.net
> >http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >_______________________________________________
> >juniper-nsp mailing list juniper-nsp@puck.nether.net
> >http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

Just for clarification..

I think the Juniper folks do a great(++) job of participating
in this forum, more so perhaps than other vendors participate
in their respective forums.

It's just that it seems that I see more of these "referrals"
here then other places (perhaps as a result of more vendor
involvement), and then the issue just dies -- as far as the
list is concerned.

I.e., I do fully understand, I just want to be sure everyone
keeps in mind that folks employ this list _because they don't
have or can't get official support in place.

Thanks!

-danny

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

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

> I.e., I do fully understand, I just want to be sure everyone
> keeps in mind that folks employ this list _because they don't
> have or can't get official support in place.

Are you sure "because" is the right word here?

I'm a recent subscriber to juniper-nsp, so I don't really know enough
about how this list works yet. On cisco-nsp, I know there were quite
a few times we used the list even though we had an official support
contract. Why? Mostly because we felt that we could often get a quicker
answer from the people on the cisco-nsp list than through official
channels - also because there is great value in getting answers from
the "people in the trenches" as oppposed to the more official answers
you get through official support channels.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Feb 24, 2004, at 12:22 AM, sthaug@nethelp.no wrote:

>> I.e., I do fully understand, I just want to be sure everyone
>> keeps in mind that folks employ this list _because they don't
>> have or can't get official support in place.
>
> Are you sure "because" is the right word here?

Yep, you're right. I should have said _some folks. Many
(likely more) use the list resources as you suggest.

-danny


>
> I'm a recent subscriber to juniper-nsp, so I don't really know enough
> about how this list works yet. On cisco-nsp, I know there were quite
> a few times we used the list even though we had an official support
> contract. Why? Mostly because we felt that we could often get a quicker
> answer from the people on the cisco-nsp list than through official
> channels - also because there is great value in getting answers from
> the "people in the trenches" as oppposed to the more official answers
> you get through official support channels.
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
>