[j-nsp] ScreenOS 6.3 / IPv6 BGP problems with "defunct" routes

Phil Mayers p.mayers at imperial.ac.uk
Sat Jun 19 07:25:11 EDT 2010


All,

I've got a case open with Juniper but I'm not expecting them to get back 
to me "in time" so I thought I'd ask here on the off-chance...

We run a pair of Netscreen 5400s in routed mode, with BGP as the routing 
protocol. About two months ago we upgraded to ScreenOS 6.3 and enabled 
IPv6, including IPv6 BGP, which generally works well.

Soon after this, we had a problem where all of the IPv6 BGP routes via a 
given neighbour went "defunct" immediately following an event being logged:

Module Level  Type Description
system crit  00205 IPv6 neighbor gateway 2001:630:12::70:4 is reachable.

...and immediately followed by a flurry of:

system notif 00625 Session (id 1808049 src-ip 2001:630:12:x dst-ip 
2001:y dst port 53) route is invalid.

The route object then says:

ic-ns5400:ic-ns5400-2(M)-> get route v6 id 112
route in trust-vr:
------------------------------------------------
id:                   112
IP address/mask:      ::/0
next hop (gateway):   2001:630:12::70:4
preference:           40(defunct)
metric:               0
description:
outgoing interface:   ethernet2/2.3
vsys name/id:         Root/0
tag:                  0
flag:                 8800c080/00000000
type:                 EBGP
Redistributed to:
status:               inactive (for 13 hours 52 minutes 12 seconds)


At this point, nothing we can do will fix the routes short of a complete 
"clear" of the BGP session. A soft-reconfig does not help.

There doesn't seem to be any specific triggering condition. The upstream 
neighbour is a Cisco 6500/sup720 and I have no reason to believe that it 
is becoming unreachable.

This seems to be a very infrequent but obviously high-impact issue. The 
last time this happened I "fixed" it by resetting the BGP sessions, and 
Juniper basically said "we don't know, gather <long list of debug> next 
time it happens and re-open the case".

It has now happened again.

I've gathered all this debug info, but I'm pretty sure based on what I 
know that the info will not be sufficient to resolve the problem, and if 
I "fix" it we'll be back at square one, having eradicated the evidence.

Does anyone have any suggestions?

Cheers,
Phil


More information about the juniper-nsp mailing list