Discussion:
[j-nsp] vpn-apply-export
Blaz Zupan
2003-11-10 08:23:16 UTC
Permalink
After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I found out that a
customers connection through a L3 MPLS VPN was suddenly broken. Although the
VPN itself was apparently working, the upgraded M5 was not announcing the
static default route configured under the routing instance to the other PE
router (a Cisco 7206 running IOS 12.2(14)S3).

Here is what I had configured:

policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
as-path limited-routes "[0-65535]{0,2}";

This was applied as an export policy on the BGP session towards the Cisco PE.
The Cisco does not have enough memory for the full BGP routing table, so I'm
limiting the number of routes with the above policy.

The routing instance for the L3 VPN had this config:

somevpn {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-somevpn-import;
vrf-export vpn-somevpn-export;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.x;
}
}
}

I later replaced the vrf-import and vrf-export with "vrf-target
target:12644:1", because it's much nicer and easier.

The above static route was not distributed to the Cisco PE router for unknown
reasons. After some experimentation, I added "static" to this term:

term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}

The default route suddenly appeared on the Cisco PE router. Obviously the IPv4
unicast policy was affecting the VPNv4 routes, so in the end effect it behaved
like I had vpn-apply-export configured, but I did not.

Am I misunderstanding something or is this a bug? The same configuration was
working flawlessly with 5.5R1.2.
Cliff DeGuzman
2003-11-10 17:17:12 UTC
Permalink
Hi,

vrf-target should pick up static routes as well. Can you please contact
our JTAC and open a case so they can investigate this.

Thanks!
Cliff
-----Original Message-----
Sent: Sunday, November 09, 2003 11:23 PM
Subject: [j-nsp] vpn-apply-export
After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
found out that a customers connection through a L3 MPLS VPN
was suddenly broken. Although the VPN itself was apparently
working, the upgraded M5 was not announcing the static
default route configured under the routing instance to the
other PE router (a Cisco 7206 running IOS 12.2(14)S3).
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
as-path limited-routes "[0-65535]{0,2}";
This was applied as an export policy on the BGP session
towards the Cisco PE. The Cisco does not have enough memory
for the full BGP routing table, so I'm limiting the number of
routes with the above policy.
somevpn {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-somevpn-import;
vrf-export vpn-somevpn-export;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.x;
}
}
}
I later replaced the vrf-import and vrf-export with
"vrf-target target:12644:1", because it's much nicer and easier.
The above static route was not distributed to the Cisco PE
router for unknown reasons. After some experimentation, I
term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}
The default route suddenly appeared on the Cisco PE router.
Obviously the IPv4 unicast policy was affecting the VPNv4
routes, so in the end effect it behaved like I had
vpn-apply-export configured, but I did not.
Am I misunderstanding something or is this a bug? The same
configuration was working flawlessly with 5.5R1.2.
_______________________________________________
http://puck.nether.net/mailman/listinfo/junipe> r-nsp
harry
2003-11-10 17:37:47 UTC
Permalink
Hmmm. The static route does not appear to have the "from-customer from-lix
from-six" communities attached, nor does it have any as path attributes. I
do not think the static should be advertised in this context, regardless of
JUNOS version as you policy only accepts routes with these attributes. You
can add community/AS path attributes to a static on routing-options; perhaps
this information was there at one time?

As for why it works with vrf-target, this is easy. This option exports all
active routes in the VRF, which includes the static default.


HTHs
-----Original Message-----
Sent: Sunday, November 09, 2003 11:23 PM
Subject: [j-nsp] vpn-apply-export
After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
found out that a customers connection through a L3 MPLS VPN
was suddenly broken. Although the VPN itself was apparently
working, the upgraded M5 was not announcing the static
default route configured under the routing instance to the
other PE router (a Cisco 7206 running IOS 12.2(14)S3).
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
as-path limited-routes "[0-65535]{0,2}";
This was applied as an export policy on the BGP session
towards the Cisco PE. The Cisco does not have enough memory
for the full BGP routing table, so I'm limiting the number of
routes with the above policy.
somevpn {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-somevpn-import;
vrf-export vpn-somevpn-export;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.x;
}
}
}
I later replaced the vrf-import and vrf-export with
"vrf-target target:12644:1", because it's much nicer and easier.
The above static route was not distributed to the Cisco PE
router for unknown reasons. After some experimentation, I
term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}
The default route suddenly appeared on the Cisco PE router.
Obviously the IPv4 unicast policy was affecting the VPNv4
routes, so in the end effect it behaved like I had
vpn-apply-export configured, but I did not.
Am I misunderstanding something or is this a bug? The same
configuration was working flawlessly with 5.5R1.2.
_______________________________________________
http://puck.nether.net/mailman/listinfo/junipe> r-nsp
Blaz Zupan
2003-11-10 17:57:52 UTC
Permalink
Post by harry
Hmmm. The static route does not appear to have the "from-customer from-lix
from-six" communities attached, nor does it have any as path attributes. I
do not think the static should be advertised in this context, regardless of
JUNOS version as you policy only accepts routes with these attributes. You
can add community/AS path attributes to a static on routing-options; perhaps
this information was there at one time?
As I understand the documentation, if vpn-apply-export is not configured, only
vpn-import/vpn-export or vpn-target policy apply to the routes created under
the routing-instance. At least that's how it worked with 5.5R1.2. When you
configure vpn-apply-export, it should first apply the vpn-import/vpn-export or
vpn-target and after that the normal BGP policy. Problem is, it behaves for me
like I have vpn-apply-export configured, but I don't have it.
harry
2003-11-10 17:45:09 UTC
Permalink
I think that the presence of explicit vrf import/export policy negate the
effects of vrf-target automatic policy. IOW, once you specify vrf-target you
should delete the vrf-import and vrf-export statements.
-----Original Message-----
Cliff DeGuzman
Sent: Monday, November 10, 2003 8:17 AM
Subject: RE: [j-nsp] vpn-apply-export
Hi,
vrf-target should pick up static routes as well. Can you
please contact our JTAC and open a case so they can investigate this.
Thanks!
Cliff
-----Original Message-----
Sent: Sunday, November 09, 2003 11:23 PM
Subject: [j-nsp] vpn-apply-export
After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
found out that a customers connection through a L3 MPLS VPN
was suddenly broken. Although the VPN itself was apparently
working, the upgraded M5 was not announcing the static
default route configured under the routing instance to the
other PE router (a Cisco 7206 running IOS 12.2(14)S3).
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
as-path limited-routes "[0-65535]{0,2}";
This was applied as an export policy on the BGP session
towards the Cisco PE. The Cisco does not have enough memory
for the full BGP routing table, so I'm limiting the number of
routes with the above policy.
somevpn {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-somevpn-import;
vrf-export vpn-somevpn-export;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.x;
}
}
}
I later replaced the vrf-import and vrf-export with
"vrf-target target:12644:1", because it's much nicer and easier.
The above static route was not distributed to the Cisco PE
router for unknown reasons. After some experimentation, I
term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}
The default route suddenly appeared on the Cisco PE router.
Obviously the IPv4 unicast policy was affecting the VPNv4
routes, so in the end effect it behaved like I had
vpn-apply-export configured, but I did not.
Am I misunderstanding something or is this a bug? The same
configuration was working flawlessly with 5.5R1.2.
_______________________________________________
http://puck.nether.net/mailman/listinfo/junipe> r-nsp
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
Blaz Zupan
2003-11-10 17:50:59 UTC
Permalink
Post by harry
I think that the presence of explicit vrf import/export policy negate the
effects of vrf-target automatic policy. IOW, once you specify vrf-target you
should delete the vrf-import and vrf-export statements.
I did.
Cliff DeGuzman
2003-11-10 17:50:23 UTC
Permalink
Maybe I misunderstood the question.

I thought everything was working correctly with vrf-import/export and
stopped working when the policies were "replaced" with vrf-target.

Cliff
-----Original Message-----
From: Harry Reynolds
Sent: Monday, November 10, 2003 8:45 AM
Subject: RE: [j-nsp] vpn-apply-export
I think that the presence of explicit vrf import/export
policy negate the effects of vrf-target automatic policy.
IOW, once you specify vrf-target you should delete the
vrf-import and vrf-export statements.
-----Original Message-----
Cliff DeGuzman
Sent: Monday, November 10, 2003 8:17 AM
Subject: RE: [j-nsp] vpn-apply-export
Hi,
vrf-target should pick up static routes as well. Can you
please contact our JTAC and open a case so they can
investigate this.
Thanks!
Cliff
-----Original Message-----
Blaz Zupan
Sent: Sunday, November 09, 2003 11:23 PM
Subject: [j-nsp] vpn-apply-export
After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
found out
that a customers connection through a L3 MPLS VPN was suddenly
broken. Although the VPN itself was apparently working,
the upgraded
M5 was not announcing the static default route configured
under the
routing instance to the other PE router (a Cisco 7206 running IOS
12.2(14)S3).
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
as-path limited-routes "[0-65535]{0,2}";
This was applied as an export policy on the BGP session
towards the
Cisco PE. The Cisco does not have enough memory for the full BGP
routing table, so I'm limiting the number of routes with
the above
policy.
somevpn {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-somevpn-import;
vrf-export vpn-somevpn-export;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.x;
}
}
}
I later replaced the vrf-import and vrf-export with "vrf-target
target:12644:1", because it's much nicer and easier.
The above static route was not distributed to the Cisco PE router
for unknown reasons. After some experimentation, I added
"static" to
term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}
The default route suddenly appeared on the Cisco PE router.
Obviously the IPv4 unicast policy was affecting the VPNv4
routes, so
in the end effect it behaved like I had vpn-apply-export
configured,
but I did not.
Am I misunderstanding something or is this a bug? The same
configuration was working flawlessly with 5.5R1.2.
_______________________________________________
http://puck.nether.net/mailman/listinfo/junipe> r-nsp
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
Blaz Zupan
2003-11-10 17:52:58 UTC
Permalink
Post by Cliff DeGuzman
Maybe I misunderstood the question.
I thought everything was working correctly with vrf-import/export and
stopped working when the policies were "replaced" with vrf-target.
You misunderstood it. Everything was working with 5.5R1.2 and
vrf-import/export. It stopped working when I upgraded to 5.7 and no changes to
the configuration. I changed vrf-import/export to vrf-target to simplify the
configuration, I should have mentioned it, it just confused the heck out of
you guys :-)
harry
2003-11-10 18:06:44 UTC
Permalink
I think I need to see the complete config to get a better handle. It sounds
like you are saying:

term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}


Is part of your unicast PE-PE BGP routing policy. I assumed this was part of
your VRF related policies.
-----Original Message-----
Sent: Monday, November 10, 2003 8:58 AM
To: harry
Subject: RE: [j-nsp] vpn-apply-export
Post by harry
Hmmm. The static route does not appear to have the "from-customer
from-lix from-six" communities attached, nor does it have
any as path
Post by harry
attributes. I do not think the static should be advertised in this
context, regardless of JUNOS version as you policy only
accepts routes
Post by harry
with these attributes. You can add community/AS path
attributes to a
Post by harry
static on routing-options; perhaps this information was
there at one
Post by harry
time?
As I understand the documentation, if vpn-apply-export is not
configured, only vpn-import/vpn-export or vpn-target policy
apply to the routes created under the routing-instance. At
least that's how it worked with 5.5R1.2. When you configure
vpn-apply-export, it should first apply the
vpn-import/vpn-export or vpn-target and after that the normal
BGP policy. Problem is, it behaves for me like I have
vpn-apply-export configured, but I don't have it.
Blaz Zupan
2003-11-10 18:20:08 UTC
Permalink
Post by harry
I think I need to see the complete config to get a better handle. It sounds
term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}
Is part of your unicast PE-PE BGP routing policy. I assumed this was part of
your VRF related policies.
Below is the relevant part of the configuration. This is the configuration
that worked with 5.5. With 5.7, I need to add "static" to the "limited-routes"
term of the "to-ibgp-amis-routes" policy, otherwise the static default route
does not propagate to the Cisco PE. I believe this is supposed to be needed
only when I configure vpn-apply-export, but I did not configure it.

protocols {
mpls {
interface e3-0/0/2.0;
interface fe-0/1/0.308;
}
bgp {
group ibgp {
type internal;
local-address 212.18.32.166;
peer-as 8591;
neighbor 212.18.32.175 {
family inet {
unicast;
}
family inet-vpn {
unicast;
}
export to-ibgp-amis-routes;
cluster 212.18.32.166;
}
}
}
ldp {
interface e3-0/0/2.0;
}
}
policy-options {
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
policy-statement vpn-telemach-import {
term a {
from {
protocol bgp;
community vpn-telemach;
}
then accept;
}
term b {
then reject;
}
}
policy-statement vpn-telemach-export {
term a {
then {
community add vpn-telemach;
accept;
}
}
term b {
then reject;
}
}
community from-customer members 8591:1000;
community from-lix members 8591:1002;
community from-six members 8591:1001;
community vpn-telemach members target:12644:1;
as-path limited-routes "[0-65535]{0,2}";
}

routing-instances {
telemach {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-telemach-import;
vrf-export vpn-telemach-export;
routing-options {
static {
route 0.0.0.0/0 next-hop 213.143.77.41;
}
}
}
}
harry
2003-11-10 18:43:31 UTC
Permalink
Odd. Can you confirm that the static route is active in the VRF?

It seems that:

policy-statement vpn-telemach-export {
term a {
then {
community add vpn-telemach;
accept;
}
}
term b {
then reject;

Should match on all active routes in the VRF and export them. Once a route
is accepted it cannot be later rejected (as I understand), so I am not sure
why modifying your PE-PE export policy should have any effect. Your AS path
reg x seems to match on a null AS path, so this explains why adding static
allows the export of the static despite no as path parameters being
configured for that static. You may want to open a case with JTAC as this
does not seem to be the desired behavior.
-----Original Message-----
Sent: Monday, November 10, 2003 9:20 AM
To: harry
Subject: RE: [j-nsp] vpn-apply-export
Post by harry
I think I need to see the complete config to get a better
handle. It
Post by harry
term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}
Is part of your unicast PE-PE BGP routing policy. I assumed
this was
Post by harry
part of your VRF related policies.
Below is the relevant part of the configuration. This is the
configuration that worked with 5.5. With 5.7, I need to add
"static" to the "limited-routes" term of the
"to-ibgp-amis-routes" policy, otherwise the static default
route does not propagate to the Cisco PE. I believe this is
supposed to be needed only when I configure vpn-apply-export,
but I did not configure it.
protocols {
mpls {
interface e3-0/0/2.0;
interface fe-0/1/0.308;
}
bgp {
group ibgp {
type internal;
local-address 212.18.32.166;
peer-as 8591;
neighbor 212.18.32.175 {
family inet {
unicast;
}
family inet-vpn {
unicast;
}
export to-ibgp-amis-routes;
cluster 212.18.32.166;
}
}
}
ldp {
interface e3-0/0/2.0;
}
}
policy-options {
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
policy-statement vpn-telemach-import {
term a {
from {
protocol bgp;
community vpn-telemach;
}
then accept;
}
term b {
then reject;
}
}
policy-statement vpn-telemach-export {
term a {
then {
community add vpn-telemach;
accept;
}
}
term b {
then reject;
}
}
community from-customer members 8591:1000;
community from-lix members 8591:1002;
community from-six members 8591:1001;
community vpn-telemach members target:12644:1;
as-path limited-routes "[0-65535]{0,2}";
}
routing-instances {
telemach {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-telemach-import;
vrf-export vpn-telemach-export;
routing-options {
static {
route 0.0.0.0/0 next-hop 213.143.77.41;
}
}
}
}
Blaz Zupan
2003-11-10 18:48:32 UTC
Permalink
Post by harry
Odd. Can you confirm that the static route is active in the VRF?
It is.
Post by harry
Should match on all active routes in the VRF and export them. Once a route
is accepted it cannot be later rejected (as I understand), so I am not sure
why modifying your PE-PE export policy should have any effect. Your AS path
reg x seems to match on a null AS path, so this explains why adding static
allows the export of the static despite no as path parameters being
Another way to make it work is to modify policy-statement to-ibgp-amis-routes
like this (new "term mpls" below):

policy-statement to-ibgp-amis-routes {
term mpls {
from community vpn;
then accept;
}
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
}
community vpn members target:12644:1
Post by harry
configured for that static. You may want to open a case with JTAC as this
does not seem to be the desired behavior.
Thanks for confirming that I'm not smoking crack :-)
Gary Tate
2003-11-11 00:05:28 UTC
Permalink
A behavioural change was indeed introduced in 5.7R1 to do an implicit
vpn-apply-export when RR or ASBR functionality is enabled. This was
introduced as part of PR27920.

So what you are seeing is the following:

Your vrf policy is accepting the vrf static route which which moves it
to the l3vpn.bgp table.

The route attributes are maintained and it is therefore still seen as
static.

The next stage is to apply the pe-pe policy to routes in the l2vpn.bgp
table, which in your case rejects the route - your final statement is
to reject all.

As you have seen the addition of protocol static or the addition to a
match on the vrf-target fixed your problem.

In short, as you first speculated, the router does have an implicit
vpn-apply-export and hence you see this behaviour.

I have taken steps to document more clearly this change in behaviour.

Sorry for the earlier confusion, I missed the cluster id which should
have alerted me to the fact that this was an PE-RR combined
configuration.


Gary
Gary Tate
2003-11-11 00:07:47 UTC
Permalink
l3vpn.bgp** table - sorry for typo
Post by Gary Tate
A behavioural change was indeed introduced in 5.7R1 to do an implicit
vpn-apply-export when RR or ASBR functionality is enabled. This was
introduced as part of PR27920.
Your vrf policy is accepting the vrf static route which which moves it
to the l3vpn.bgp table.
The route attributes are maintained and it is therefore still seen as
static.
The next stage is to apply the pe-pe policy to routes in the
l2vpn.bgp** table, which in your case rejects the route - your final
statement is to reject all.
As you have seen the addition of protocol static or the addition to a
match on the vrf-target fixed your problem.
In short, as you first speculated, the router does have an implicit
vpn-apply-export and hence you see this behaviour.
I have taken steps to document more clearly this change in behaviour.
Sorry for the earlier confusion, I missed the cluster id which should
have alerted me to the fact that this was an PE-RR combined
configuration.
Gary
Phil Rosenthal
2003-11-11 01:58:17 UTC
Permalink
Has anyone ever seen this error in /var/log/messages ?

Nov 10 14:27:11 juniper /kernel: Nexthop index allocation failed:
public index space exhausted

I get that error about 600 times every 10 minutes.

--Phil Rosenthal
ISPrime, Inc.
Phil Rosenthal
2003-11-11 02:06:58 UTC
Permalink
This is on a 6.0R1.3 btw.
Post by Phil Rosenthal
Has anyone ever seen this error in /var/log/messages ?
public index space exhausted
I get that error about 600 times every 10 minutes.
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
Gary Tate
2003-11-11 02:45:15 UTC
Permalink
Have corrected the typo's so no one is confused. Sorry
Post by Gary Tate
A behavioural change was indeed introduced in 5.7R1 to do an implicit
vpn-apply-export when RR or ASBR functionality is enabled. This was
introduced as part of PR27920.
Your vrf policy is accepting the vrf static route which which moves it
to the bgp.l3vpn table.
The route attributes are maintained and it is therefore still seen as
static.
The next stage is to apply the pe-pe policy to routes in the bgp.l3vpn
table, which in your case rejects the route - your final statement is
to reject all.
As you have seen the addition of protocol static or the addition to a
match on the vrf-target fixed your problem.
In short, as you first speculated, the router does have an implicit
vpn-apply-export and hence you see this behaviour.
I have taken steps to document more clearly this change in behaviour.
Sorry for the earlier confusion, I missed the cluster id which should
have alerted me to the fact that this was an PE-RR combined
configuration.
Gary
Gary Tate
2003-11-11 03:42:54 UTC
Permalink
The kernal stores indexes to next-hops. There is only a limited number
of next-hop indexes that can be stored before memory is full and
produce the message you are seeing.

It would help to know your configuration. a 'show route summary' and
'show pfe route summary' just to get the idea of the size of your
routing tables.

Also what type of hardware you are using could help
Gary
Post by Phil Rosenthal
This is on a 6.0R1.3 btw.
Post by Phil Rosenthal
Has anyone ever seen this error in /var/log/messages ?
public index space exhausted
I get that error about 600 times every 10 minutes.
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
Phil Rosenthal
2003-11-11 03:46:48 UTC
Permalink
M20, dual SSB-E, dual RE
Post by Gary Tate
show route summary
inet.0: 128188 destinations, 581434 routes (128094 active, 1 holddown,
127366 hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
BGP: 581265 routes, 127925 active
Static: 62 routes, 62 active

tablea.inet.0: 107 destinations, 107 routes (107 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active

tableb.inet.0: 107 destinations, 107 routes (107 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active

inet6.0: 484 destinations, 487 routes (484 active, 0 holddown, 0 hidden)
Restart Complete
Direct: 4 routes, 4 active
Local: 2 routes, 2 active
BGP: 479 routes, 476 active
Static: 2 routes, 2 active
Post by Gary Tate
show pfe route summary
IPv4 Route Tables:
Index Routes Size(b)
-------- ---------- ----------
Default 128413 8595747
1 4 265
2 111 7538
3 111 7538

MPLS Route Tables:
Index Routes Size(b)
-------- ---------- ----------
Default 1 64

IPV6 Route Tables:
Index Routes Size(b)
-------- ---------- ----------
Default 495 33922
1 3 209


-P
Post by Gary Tate
The kernal stores indexes to next-hops. There is only a limited
number of next-hop indexes that can be stored before memory is full
and produce the message you are seeing.
It would help to know your configuration. a 'show route summary' and
'show pfe route summary' just to get the idea of the size of your
routing tables.
Also what type of hardware you are using could help
Gary
Post by Phil Rosenthal
This is on a 6.0R1.3 btw.
Post by Phil Rosenthal
Has anyone ever seen this error in /var/log/messages ?
public index space exhausted
I get that error about 600 times every 10 minutes.
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
Josef Buchsteiner
2003-11-11 06:50:04 UTC
Permalink
Phil,

an additional question.
is this a Route Reflector for vpn-routes ?
and perform the following.
show system virtual-memory | match rtn

Josef
Post by Phil Rosenthal
M20, dual SSB-E, dual RE
Post by Gary Tate
show route summary
inet.0: 128188 destinations, 581434 routes (128094 active, 1 holddown,
127366 hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
BGP: 581265 routes, 127925 active
Static: 62 routes, 62 active
tablea.inet.0: 107 destinations, 107 routes (107 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
tableb.inet.0: 107 destinations, 107 routes (107 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
inet6.0: 484 destinations, 487 routes (484 active, 0 holddown, 0 hidden)
Restart Complete
Direct: 4 routes, 4 active
Local: 2 routes, 2 active
BGP: 479 routes, 476 active
Static: 2 routes, 2 active
Post by Gary Tate
show pfe route summary
Index Routes Size(b)
-------- ---------- ----------
Default 128413 8595747
1 4 265
2 111 7538
3 111 7538
Index Routes Size(b)
-------- ---------- ----------
Default 1 64
Index Routes Size(b)
-------- ---------- ----------
Default 495 33922
1 3 209
-P
Post by Gary Tate
The kernal stores indexes to next-hops. There is only a limited
number of next-hop indexes that can be stored before memory is full
and produce the message you are seeing.
It would help to know your configuration. a 'show route summary' and
'show pfe route summary' just to get the idea of the size of your
routing tables.
Also what type of hardware you are using could help
Gary
Post by Phil Rosenthal
This is on a 6.0R1.3 btw.
Post by Phil Rosenthal
Has anyone ever seen this error in /var/log/messages ?
public index space exhausted
I get that error about 600 times every 10 minutes.
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
Phil Rosenthal
2003-11-11 09:02:22 UTC
Permalink
Post by Josef Buchsteiner
Phil,
an additional question.
is this a Route Reflector for vpn-routes ?
and perform the following.
show system virtual-memory | match rtn
Josef
Nope.

I already upgraded to 6.1R1.4, and rebooted, but here's what it says
Post by Josef Buchsteiner
show system virtual-memory |match rtn
rtnexthop, iffamily, temp, devbuf, zombie, proc-args, dev_t,
ipfw, rtnexthop, iflogical, iftable, temp, devbuf, proc-args,
rtnexthop 510 100K 211K127940K 221948 0 0 128,256

--Phil Rosenthal
ISPrime, Inc.

Gary Tate
2003-11-11 05:05:15 UTC
Permalink
This looks fine. I would open a case with the JTAC so that they can
look further into the issue with you.

Gary
Post by Phil Rosenthal
M20, dual SSB-E, dual RE
Post by Gary Tate
show route summary
inet.0: 128188 destinations, 581434 routes (128094 active, 1 holddown,
127366 hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
BGP: 581265 routes, 127925 active
Static: 62 routes, 62 active
tablea.inet.0: 107 destinations, 107 routes (107 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
tableb.inet.0: 107 destinations, 107 routes (107 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 54 routes, 54 active
Local: 53 routes, 53 active
inet6.0: 484 destinations, 487 routes (484 active, 0 holddown, 0
hidden)
Restart Complete
Direct: 4 routes, 4 active
Local: 2 routes, 2 active
BGP: 479 routes, 476 active
Static: 2 routes, 2 active
Post by Gary Tate
show pfe route summary
Index Routes Size(b)
-------- ---------- ----------
Default 128413 8595747
1 4 265
2 111 7538
3 111 7538
Index Routes Size(b)
-------- ---------- ----------
Default 1 64
Index Routes Size(b)
-------- ---------- ----------
Default 495 33922
1 3 209
-P
Post by Gary Tate
The kernal stores indexes to next-hops. There is only a limited
number of next-hop indexes that can be stored before memory is full
and produce the message you are seeing.
It would help to know your configuration. a 'show route summary' and
'show pfe route summary' just to get the idea of the size of your
routing tables.
Also what type of hardware you are using could help
Gary
Post by Phil Rosenthal
This is on a 6.0R1.3 btw.
Post by Phil Rosenthal
Has anyone ever seen this error in /var/log/messages ?
public index space exhausted
I get that error about 600 times every 10 minutes.
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
_______________________________________________
http://puck.nether.net/mailman/listinfo/juniper-nsp
--Phil Rosenthal
ISPrime, Inc.
Phil Rosenthal
2003-11-11 05:27:25 UTC
Permalink
Post by Gary Tate
This looks fine. I would open a case with the JTAC so that they can
look further into the issue with you.
Gary
I've already upgraded to 6.1R1.4, I will do it again if it reoccurs.

--Phil Rosenthal
ISPrime, Inc.
Loading...