[j-nsp] show route advertising-protocol on IPv6 peers

[Daniel Verlouw]

Hi all,

has anyone ever seen the behaviour below? I've been going back and forth
with JTAC for months now without any result (which seems to be the norm
nowadays...). We just upgraded a few M-series boxes from 9.3 to 9.5R3
and the issue still persists. It seems the issue was introduced in one
of the earlier 9.x releases.

daniel at XXXXX> show route advertising-protocol bgp <ipv6 neighbor>
error: timeout communicating with routing daemon

Dec 16 16:20:23.671 2009 XXXXX mgd[73749]: %INTERACT-6-UI_CMDLINE_READ_LINE: User 'daniel', command 'show route advertising-protocol bgp <ipv6 neighbor> '
Dec 16 16:21:23.659 2009 XXXXX mgd[73749]: %DAEMON-5-UI_READ_TIMEOUT: Timeout on read of peer 'routing'

It's most obvious with IPv6 neighbors receiving a full feed (+/- 2400
prefixes) from us, whereas the same command with an IPv4 neighbor
receiving a full feed (>300k prefixes) is almost instantaneous.

Cheers,
Daniel.

[Mark Tinka]

On Wednesday 16 December 2009 11:39:40 pm Daniel Verlouw

Post by Daniel Verlouw
has anyone ever seen the behaviour below? I've been going
back and forth with JTAC for months now without any
result (which seems to be the norm nowadays...). We just
upgraded a few M-series boxes from 9.3 to 9.5R3 and the
issue still persists. It seems the issue was introduced
in one of the earlier 9.x releases.
daniel at XXXXX> show route advertising-protocol bgp <ipv6
neighbor> error: timeout communicating with routing
daemon

We've never seen this issue before. We have about 95% of our
M7i/M10i routers running JUNOS 9.3R2.8, all with a full v6
table, no issues.

The other 5% are running JUNOS 9.4R1.8 (yuk!), all with a
full v6 table, no issues either.

Control plane is an RE-850 with 1.5GB of DRAM, if that helps
any.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20091217/a39ea808/attachment.bin>

[Daniel Verlouw]

Post by Daniel Verlouw
It's most obvious with IPv6 neighbors receiving a full feed (+/- 2400
prefixes) from us, whereas the same command with an IPv4 neighbor
receiving a full feed (>300k prefixes) is almost instantaneous.

funny enough, I just ran into the same issue with an IPv4 peer receiving
only a single default route from us. Still working with JTAC, but so far
nothing useful..

--Daniel.

[Richard A Steenbergen]

Post by Daniel Verlouw

Post by Daniel Verlouw
It's most obvious with IPv6 neighbors receiving a full feed (+/- 2400
prefixes) from us, whereas the same command with an IPv4 neighbor
receiving a full feed (>300k prefixes) is almost instantaneous.

funny enough, I just ran into the same issue with an IPv4 peer receiving
only a single default route from us. Still working with JTAC, but so far
nothing useful..

Yeah I've seen that behavior for years now, never got around to opening
a case on it though. If you specify the table in your show route command
(either inet.0 or inet6.0) it will return the results quickly, it's
only slow if you don't request a specific table.

[Daniel Verlouw]

Post by Richard A Steenbergen
Yeah I've seen that behavior for years now, never got around to opening
a case on it though. If you specify the table in your show route command
(either inet.0 or inet6.0) it will return the results quickly, it's
only slow if you don't request a specific table.

thanks for the tip Richard, that seems to work! I've added this to the
case notes, so hopefully they'll come up with a fix.

--Daniel.