SNMP agents for mobile telecom infrastructure

Hi,

I am currently looking at adding SNMP agent functionality to some existing telecoms mobile infrastructure software running under Linux. This would be done by defining and implementing some enterprise- specific MIBs, and using SNMPv3.

Linux has its own standard SNMP agent (running as the snmpd daemon) that handles standard MIB variables, such as MIB-II (RFC 1213).

For a mobile telecoms operator's point of view, is it better to have two separate SNMP agents, one for the standard basic Linux node and one for the telecoms software, or is it preferable to incorporate both into a single SNMP agent?

A single SNMP agent could run using the standard SNMP UDP ports, i.e.

161 for operations such as gets and sets and 162 for operations like traps, whereas different ports could be used if there is more than one agent.

I know that it is possible to have sub agents, with communication between sub agents and a master agent using a protocol such as AgentX or SNMP.

Are there any views, recommendations or best practices on this, particularly for mobile telecoms management?

Thanks in advance for any info or advice.

Reply to
NetEd
Loading thread data ...

From somewhere in cyberspace, NetEd said: ...

It depends on your requirements.

The arguments in favor of using a single SNMP agent:

  • uses stock startup settings - no new daemon to add to node
  • easier to configure the monitoring systems - everything uses port 161
  • simpler firewall / iptables configuration

But there are also arguments against it:

  • application MIB code could cause snmpd to slow down or stall, interfering with data collection from the system MIBs
  • possible difficulty when upgrading Linux software on node - future changes in snmpd might require re-integration effort
  • easier to swap out SNMP daemon if you decide the application MIB needs to built on a different software platform

Since you're already installing your application on the Linux nodes, it should not be that much extra work to install a 2nd SNMP daemon for the application MIB. That would probably be more managable in the long run.

Reply to
Ed Ravin

A second SNMP daemon would either be a subagent or spun up on a different port. Neither is completely transparent nor trivial.

Reply to
Les Cargill

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.