[zebra 13232] Is there a reason not to use --enable-snmp?

[Stephane Bortzmeyer]

Is there a good reason (performances, may be?) to --disable-snmp when
configuring Zebra? The Debian package is built without SNMP but
everything seems to work when recompiling with network management on.

[Glen Turner]

Post by Stephane Bortzmeyer
Is there a good reason (performances, may be?) to --disable-snmp when
configuring Zebra? The Debian package is built without SNMP but
everything seems to work when recompiling with network management on.

--disable-snmp reduces package dependencies and given that NetSNMP is a
big, hard-to-configure subsystem in its own right this probably not a bad
thing for a default distribution of Zebra.

You also need --disable-snmp if you are running multiple instances of
Zebra (eg: for a BGP looking glass).

[Michael H. Warfield]

Post by Glen Turner

Post by Stephane Bortzmeyer
Is there a good reason (performances, may be?) to --disable-snmp when
configuring Zebra? The Debian package is built without SNMP but
everything seems to work when recompiling with network management on.

--disable-snmp reduces package dependencies and given that NetSNMP is a
big, hard-to-configure subsystem in its own right this probably not a bad
thing for a default distribution of Zebra.
You also need --disable-snmp if you are running multiple instances of
Zebra (eg: for a BGP looking glass).

Err???

Could you elaborate on that a bit for the unwashed masses?

I've got Zebra up and running with OSPF between various sites
and a couple of private r/o BGP feeds to systems but I'm really an amateur
at this level and I've only now realized the level of utilization of
looking glass servers (and I'm above to set one up for my site and the
site at my office).

I've heard the comments that it's difficult (if not damn
near impossible) to run a decent BGP site (looking for peers - any
offers?) properly without decent looking glass servers (so I intend to
set them up where I can and where appropriate). The comment about
disabling snmp and running multiple instances of Zebra in order to
run a looking glass server has me concerned.

Why is there a conflict there?

Why is it necessary to run multiple instances of Zebra for this
task (pardon my ignorance)?

This could impact future project plans. Is it an endemic/inherent
problem or a problem with a potential fix in the future?

It was on my project schedule to look deeper into setting up an
internal looking glass server in the very near future and this remark
casts that into doubt. Feedback would be helpful before I wasted my
time and everyone elses when shit catches fire and burns... :-/

Mike

[Glen Turner]

Post by Michael H. Warfield
I've heard the comments that it's difficult (if not damn
near impossible) to run a decent BGP site (looking for peers - any
offers?) properly without decent looking glass servers (so I intend to
set them up where I can and where appropriate).

They certainly make debugging misconfigurations a lot easier. Zebra will
also write a log file and you can serve this using HTTP, so you can also
debug past events.

Post by Michael H. Warfield
The comment about disabling snmp and running multiple instances of Zebra
in order to run a looking glass server has me concerned.

You don't need to do this to have Zebra run as a looking glass server for
one autonomous system.

But if you're running multiple looking glasses for multiple autonomous
systems (eg: perhaps insisting that your BGP-speaking customers attach to
your looking glass system) on one box then you need to consider how to do
this. The obvious way if to establish multiple views -- in this case
Zebra threads the multiple BGP connections. This works.

At some level (say if you are running a route-views server for a country
or a backbone network) Zebra's threading begins to not scale well -- in
this case you want to run a full-weight BGP process per autonomous system
and let the operating system sort out the resource contention.

In this case you have multiple bgpd's running all trying to register the
same SNMP object ID space with the NetSNMP SMUX SNMP multiplexor. This
won't be good, so disable SNMP.

They also compete over the /var/run/bgpd.pid file. I've posted a patch to
fix that.

The average ISP might want to run a second bgpd instance on a box if it is
also using Zebra for routing as well as for a looking glass. This would
allow the bgpd doing the routing to run as 'root' and the bgpd doing the
looking glass (where the public can access the command line either
directly or via a HTTP CGI) to run as a less powerful user.

Post by Michael H. Warfield
It was on my project schedule to look deeper into setting up an
internal looking glass server in the very near future and this remark
casts that into doubt. Feedback would be helpful before I wasted my
time...

No need to be negative, I've already done the work for you :-) See message
[zebra 12761] and its follow ups which refer to

http://www.aarnet.edu.au/projects/2002/bgp/zglass.pdf
(source is http://www.aarnet.edu.au/projects/2002/bgp/zglass.sgml)

and discuss the threading versus processes tradeoff. I think the
configuration of /etc/logrotate.conf has a small error in the document.

Best wishes,
Glen

[Stephane Bortzmeyer]

On Wed, Apr 10, 2002 at 11:07:58AM +0930,
Glen Turner <***@aarnet.edu.au> wrote
a message of 12 lines which said:

[NetSNMP]

Post by Glen Turner
big, hard-to-configure subsystem in its own right this probably not a bad
thing for a default distribution of Zebra.

Hmmm, it adds a dependency to libsnmp, OK, but, if you don't use it,
there is nothing to configure so it does not disturb people who do not
use SNMP.

If it seems a real problem, I suggest to the Debian maintainer to have
two packages, zebra and zebra-snmp which will
<debian-speak>Provides/Conflicts</debian-speak> zebra.