Re: [j-nsp] SNMP Polling
Hi, Why would you do that? You could use RADIUS for accounting purposes. /Evgeny From: juniper-nsp [juniper-nsp-boun...@puck.nether.net] on behalf of Wan [eazy_...@yahoo.com] Sent: Friday, August 30, 2013 7:59 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] SNMP Polling Hi, Does polling many interface on Juniper MX will impact CPU/SYSTEM performance? We are using MX as BRAS and would like to pool all the subsciber interface utilization directly from PP0 interface. Can someone share interm of scaling, how many interface we can pool for traffic utilization before it impact performance. /Kamal ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP Polling
Hi, Does polling many interface on Juniper MX will impact CPU/SYSTEM performance? We are using MX as BRAS and would like to pool all the subsciber interface utilization directly from PP0 interface. Can someone share interm of scaling, how many interface we can pool for traffic utilization before it impact performance. /Kamal ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling issue MX
It looks like there were possibly multiple mib2d process bugs. In our
case, restarting mib2d did not always resolve the issue.
The good news is that it does look like 10.2R3 fixes the mib2d issues we
were experiencing. We've been running 10.2R3 (or a derivative) for
several weeks and SNMP appears to be stable.
Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
On Sunday, Richard said:
On Sun, Jan 09, 2011 at 04:14:04PM +0300, Tarique A. Nalkhande - BMC wrote:
All,
Even we faced a similar problem on our MX's running 10.2R3. Further
findings revealed memory leak bug for mib2d process.. restarting mib2d
fixed it.
Juniper is probably tracking it through some internal PR, the
committed release is 10.2R3 which doesn't look likely.
Hrmm supposedly the mib2d memory leak is fixed was 10.2R3, but we never
actually tested it, we just skipped straight ahead to 10.3R2 on new
deployments (as there were many other SNMP bugs still not fixed in 10.2
at the time). A quick and dirty workaround for the memory leak issue is
to periodically restart the mib2d process, which you can do with an
event script like so:
event-options {
generate-event {
/* Adjust ttimer as necessary based on memory consumption */
restart-mib2d time-interval 604800;
}
policy restart-mib2d {
events restart-mib2d;
/* Adjust this too, to something slightly less than above */
within 60 {
not events restart-mib2d;
}
then {
event-script restart-mib2d;
}
}
}
/var/db/scripts/op/restart-mib2d.slax:
version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos";;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;
import "../import/junos.xsl";
match / {
{
var $restart-mib2d = {
"restart mib-process gracefully";
}
var $result = jcs:invoke($restart-mib2d);
}
}
--
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling issue MX
On Sun, Jan 09, 2011 at 04:14:04PM +0300, Tarique A. Nalkhande - BMC wrote:
> All,
>
> Even we faced a similar problem on our MX's running 10.2R3. Further
> findings revealed memory leak bug for mib2d process.. restarting mib2d
> fixed it.
> Juniper is probably tracking it through some internal PR, the
> committed release is 10.2R3 which doesn't look likely.
Hrmm supposedly the mib2d memory leak is fixed was 10.2R3, but we never
actually tested it, we just skipped straight ahead to 10.3R2 on new
deployments (as there were many other SNMP bugs still not fixed in 10.2
at the time). A quick and dirty workaround for the memory leak issue is
to periodically restart the mib2d process, which you can do with an
event script like so:
event-options {
generate-event {
/* Adjust ttimer as necessary based on memory consumption */
restart-mib2d time-interval 604800;
}
policy restart-mib2d {
events restart-mib2d;
/* Adjust this too, to something slightly less than above */
within 60 {
not events restart-mib2d;
}
then {
event-script restart-mib2d;
}
}
}
/var/db/scripts/op/restart-mib2d.slax:
version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos";;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;
import "../import/junos.xsl";
match / {
{
var $restart-mib2d = {
"restart mib-process gracefully";
}
var $result = jcs:invoke($restart-mib2d);
}
}
--
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling issue MX
All, Even we faced a similar problem on our MX's running 10.2R3. Further findings revealed memory leak bug for mib2d process.. restarting mib2d fixed it. Juniper is probably tracking it through some internal PR, the committed release is 10.2R3 which doesn't look likely. Thanks & Regards Tarique Abbas Nalkhande -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Richard A Steenbergen Sent: 02 September, 2010 11:54 AM To: Chintan Pandya Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SNMP polling issue MX On Thu, Sep 02, 2010 at 12:56:21PM +0530, Chintan Pandya wrote: > Hi All, > > We are facing issue in polling SNMP statistics on MX 960 sub-interfaces. > JUNOS 10.2R1.8 is running on router. > > The sub-interfaces statistics are not getting polled on the Reporter > software, where as the parent statistics are getting polled. > The SNMP statistics can be seen on the router. > The issue is with all types of interfaces AE, XE, GE. > > Nothing wrong seems with the configuration. Semi-known issue, see the discussion about bugs in 10.2 (in the Trio card thread) from a few days ago. We somehow stopped being able to replicate it, and it didn't seem like they had a PR on it back when we were looking, so please open a case on it. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp --Disclaimer-- This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling issue MX
Hey thanks Richard, The case has been logged already. On Thu, Sep 2, 2010 at 2:24 PM, Richard A Steenbergen wrote: > On Thu, Sep 02, 2010 at 12:56:21PM +0530, Chintan Pandya wrote: > > Hi All, > > > > We are facing issue in polling SNMP statistics on MX 960 sub-interfaces. > > JUNOS 10.2R1.8 is running on router. > > > > The sub-interfaces statistics are not getting polled on the Reporter > > software, where as the parent statistics are getting polled. > > The SNMP statistics can be seen on the router. > > The issue is with all types of interfaces AE, XE, GE. > > > > Nothing wrong seems with the configuration. > > Semi-known issue, see the discussion about bugs in 10.2 (in the Trio > card thread) from a few days ago. We somehow stopped being able to > replicate it, and it didn't seem like they had a PR on it back when we > were looking, so please open a case on it. :) > > -- > Richard A Steenbergenhttp://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling issue MX
On Thu, Sep 02, 2010 at 12:56:21PM +0530, Chintan Pandya wrote: > Hi All, > > We are facing issue in polling SNMP statistics on MX 960 sub-interfaces. > JUNOS 10.2R1.8 is running on router. > > The sub-interfaces statistics are not getting polled on the Reporter > software, where as the parent statistics are getting polled. > The SNMP statistics can be seen on the router. > The issue is with all types of interfaces AE, XE, GE. > > Nothing wrong seems with the configuration. Semi-known issue, see the discussion about bugs in 10.2 (in the Trio card thread) from a few days ago. We somehow stopped being able to replicate it, and it didn't seem like they had a PR on it back when we were looking, so please open a case on it. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP polling issue MX
Hi All, We are facing issue in polling SNMP statistics on MX 960 sub-interfaces. JUNOS 10.2R1.8 is running on router. The sub-interfaces statistics are not getting polled on the Reporter software, where as the parent statistics are getting polled. The SNMP statistics can be seen on the router. The issue is with all types of interfaces AE, XE, GE. Nothing wrong seems with the configuration. Thanks Chintan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling a logical-system without encoding it asLS/r...@community
> > One question though: I see that you mention ri2, which is different > > from the default routing instance. Does that actually matter? So far > > we have not been using routing instances, but do you think we > > actually need to setup one explicitly, within the logical-system? No, it doesn't matter. Instead of "lr1/ri1" used in my config, in your case you can use "mytarget/default". > > One more question: > > In your configuration I see only physical interfaces. To the extent of > your knowledge, does it matter if the entry point is a logical sub- > interface (unit) assigned to lr1, while the physical interface is used > by R1? Again, I don't think this should cause any problem. Thanks Subodh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling a logical-system without encoding it asLS/r...@community
On 15 Ιαν 2009, at 5:25 ΜΜ, Zenon Mousmoulas wrote:
On 15 Ιαν 2009, at 1:44 ΜΜ, Subodh Kumar wrote:
It would depend on which interface is your packet entering the system
(router). Consider an example:
_
| || |
| | (lr1/ri2) | |
| R1 || nms1 |
| |fe-0/0/3em1 | |
|___||___|
- (lr1/ri2) indicate the routing-instance
- Ip Address:
nms1 (em1): 14.14.14.1
logical-systems lr1 {
routing-instances {
ri2 {
...
interface fe-0/0/3;
...
}
}
interfaces{
fe-0/0/3 {
unit 0 {
family inet {
address 14.14.14.2/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 14.14.14.100/32
}
}
}
}
}
Now if you send a SNMP packet from 'nms1' on ip-addess 14.14.14.100
or
14.14.14.2, that makes sure that packet is entering the system from
inetrafce fe-0/0/3 which is part of logical-systems 'lr1'. In this
case
you don't need to specify the prefix 'lr1/default' in the community
string.
In your case, it looks that the SNMP packet is getting into the
router
through 'fxp0' or some interface that is part of 'default'
routing-instance. Does the 'ping 10.0.0.5' from the NMS work for you?
Yes I can ping from the nms to the loopback of the logical system,
but you are right, traffic is routed between nms and lr1 through R1
= it enters through an interface that belongs to R1 (the physical
router).
Thanks for the suggestion! This looks promising. We will slightly
alter the network topology, in order to try this out.
One question though: I see that you mention ri2, which is different
from the default routing instance. Does that actually matter? So far
we have not been using routing instances, but do you think we
actually need to setup one explicitly, within the logical-system?
One more question:
In your configuration I see only physical interfaces. To the extent of
your knowledge, does it matter if the entry point is a logical sub-
interface (unit) assigned to lr1, while the physical interface is used
by R1?
Thanks,
Z.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling a logical-system without encoding it asLS/r...@community
On 15 Ιαν 2009, at 1:44 ΜΜ, Subodh Kumar wrote:
It would depend on which interface is your packet entering the system
(router). Consider an example:
_
| || |
| | (lr1/ri2) | |
| R1 || nms1 |
| |fe-0/0/3em1 | |
|___||___|
- (lr1/ri2) indicate the routing-instance
- Ip Address:
nms1 (em1): 14.14.14.1
logical-systems lr1 {
routing-instances {
ri2 {
...
interface fe-0/0/3;
...
}
}
interfaces{
fe-0/0/3 {
unit 0 {
family inet {
address 14.14.14.2/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 14.14.14.100/32
}
}
}
}
}
Now if you send a SNMP packet from 'nms1' on ip-addess 14.14.14.100 or
14.14.14.2, that makes sure that packet is entering the system from
inetrafce fe-0/0/3 which is part of logical-systems 'lr1'. In this
case
you don't need to specify the prefix 'lr1/default' in the community
string.
In your case, it looks that the SNMP packet is getting into the router
through 'fxp0' or some interface that is part of 'default'
routing-instance. Does the 'ping 10.0.0.5' from the NMS work for you?
Yes I can ping from the nms to the loopback of the logical system, but
you are right, traffic is routed between nms and lr1 through R1 = it
enters through an interface that belongs to R1 (the physical router).
Thanks for the suggestion! This looks promising. We will slightly
alter the network topology, in order to try this out.
One question though: I see that you mention ri2, which is different
from the default routing instance. Does that actually matter? So far
we have not been using routing instances, but do you think we actually
need to setup one explicitly, within the logical-system?
Best regards,
Z.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling a logical-system without encoding it asLS/r...@community
It would depend on which interface is your packet entering the system
(router). Consider an example:
_
| || |
| | (lr1/ri2) | |
| R1 || nms1 |
| |fe-0/0/3em1 | |
|___||___|
- (lr1/ri2) indicate the routing-instance
- Ip Address:
nms1 (em1): 14.14.14.1
logical-systems lr1 {
routing-instances {
ri2 {
...
interface fe-0/0/3;
...
}
}
interfaces{
fe-0/0/3 {
unit 0 {
family inet {
address 14.14.14.2/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 14.14.14.100/32
}
}
}
}
}
Now if you send a SNMP packet from 'nms1' on ip-addess 14.14.14.100 or
14.14.14.2, that makes sure that packet is entering the system from
inetrafce fe-0/0/3 which is part of logical-systems 'lr1'. In this case
you don't need to specify the prefix 'lr1/default' in the community
string.
In your case, it looks that the SNMP packet is getting into the router
through 'fxp0' or some interface that is part of 'default'
routing-instance. Does the 'ping 10.0.0.5' from the NMS work for you?
Thanks
Subodh
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling a logical-system without encoding it asLS/r...@community
On 15 Ιαν 2009, at 12:04 ΜΜ, Subodh Kumar wrote:
Is it at all possible to configure snmp so that when the
logical system is polled on a specific address (e.g. the one assigned
to its' lo0.) it will reply as if the specially encoded
community had been specified? Is it possible i.e. to identify the
logical system not through the community but rather through the
destination address?
Yes its possible, but the address/interface you poll should be part of
the routing-instance. E.g. interface fe-0/1/0.0 is part of routing
instance "ri1". The configured primary address on fe-0/1/0.0 is
10.0.0.5
and the community is "public". In that case sending a snmp request on
address 10.0.0.5 with community "public" will get you data specific to
routing-instance "ri1".
I'm not sure how this applies to logical systems, however. Lo0.1 is
part of the logical system:
logical-systems {
mytarget {
interfaces {
# [...]
lo0 {
unit 1 {
family inet {
address 10.0.0.5/32;
}
}
}
However it has not been explicitly assigned to a specific routing
instance, since we don't use any, therefore I believe it belongs to
the default RI.
When I poll through this interface with community "public", I get no
answer...
The SNMP configuration looks like this:
community private {
authorization read-write;
clients {
0.0.0.0/0 restrict;
}
}
community public {
authorization read-only;
clients {
0.0.0.0/0 restrict;
;/32
/32;
/32;
}
logical-system mytarget {
routing-instance default;
}
}
routing-instance-access;
Do we need to explicitly configure an RI, apart from the implicitly
existing "default", even only for this purpose, then assign all of the
logical-system's interfaces to it?
This feature is only supported from Release 8.4 onwards. Hope you are
using a release after it.
We're using R9.3.
Thank you so much for your insight.
Best regards,
Z.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP polling a logical-system without encoding it asLS/r...@community
> Is it at all possible to configure snmp so that when the > logical system is polled on a specific address (e.g. the one assigned > to its' lo0.) it will reply as if the specially encoded > community had been specified? Is it possible i.e. to identify the > logical system not through the community but rather through the > destination address? Yes its possible, but the address/interface you poll should be part of the routing-instance. E.g. interface fe-0/1/0.0 is part of routing instance "ri1". The configured primary address on fe-0/1/0.0 is 10.0.0.5 and the community is "public". In that case sending a snmp request on address 10.0.0.5 with community "public" will get you data specific to routing-instance "ri1". This feature is only supported from Release 8.4 onwards. Hope you are using a release after it. Thanks Subodh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP polling a logical-system without encoding it as LS/r...@community
Hi, We have a script that attempts to do network discovery, polling every system and then its' neighbors through SNMP, so it's practically based on the assumption that the community string remains the same on every system it comes across. Now this script should discover a JUNOS logical system, however, according to the documentation, it needs to use a different community in order to target specifically that logical system: http://www.juniper.net/techpubs/software/junos/junos93/swconfig-net-mgmt/routing-instance-identifying-junos-nm.html#id-10865737 This is not very convenient because it breaks the previously stated assumption. Is it at all possible to configure snmp so that when the logical system is polled on a specific address (e.g. the one assigned to its' lo0.) it will reply as if the specially encoded community had been specified? Is it possible i.e. to identify the logical system not through the community but rather through the destination address? I've also tried the suggestion in the next paragraph: http://www.juniper.net/techpubs/software/junos/junos93/swconfig-net-mgmt/routing-instance-in-snmp-community-specifying-junos-nm.html#routing-instance-in-snmp-community However it did not make a difference and I'm not really sure how it correlates to the above. Thanks in advance for any hints. Best regards, Zenon Mousmoulas GRNET ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
