I am writing a SNMP Agent for an Ethernet switch.
The agent is able to run and reply to provide SysDescr. It has been written in a modular design, such that, one can add OIDs very easily.
Now, my intention is to create a topology (say ring) of the switches and discover the topology using a common Network Management System like HP-NNMi or OpenNMS (I am testing on OpenNMS btw).
I just want to know, what oids are queried by an NMS, to gather enough information to draw the topology?
[EDIT] I can know, what is the MAC of the remote switches connected to any port of a switch, through MAC learning.
The answer depends on what type of topology you want to capture through your ethernet switch. Usually for a layer two switch (which appears to be the case) LLDP MIB (This is an IEEE std implemented by many switches) is quite useful. From what you described above that is you have information about MACs on a port it appears you probably can go this route. There are some other Physical topology MIBs (like RFC2292) that you may want to look at.
You can have a look at the OpenNMS Enhanced Linkd documentation. It will give you some hints which OID's are used to build a Layer-2 topology based on LLDP, CDP and the Bridge MIB. To build it a topology based on the Bridge MIB, OpenNMS has implemented the algorithm described in Topology Discovery for Large Ethernet Networks. You'll find also hints what information is used to build an OSPF and IS-IS topology.
Every NMS uses their proprietary topology discovery.
Depending on what your switch supports, you'll want to consider at least
RFC1213-MIB ipAddrTable, ipRouteTable
IF-MIB ifTable
IP-FORWARD-MIB inetCidrRouteTable
BRIDGE-MIB dot1dTpFdbTable, dot1dStpPortTable
Q-BRIDGE-MIB dot1qTpFdbTable
LLDP-MIB lldpLocPortTable, lldpRemTable
OSPF-MIB
BGP4-MIB
and if you support VLANs, you'll want to describe those.
We have seen other MIBs queried by NMS applications.
Related
I'm trying to wrap my head around how to use SNMP in my networks. It's for industrial applications, networks with 200-800 IPs, but many quirks and security layers.
What I'd like to do is catch any traps, and periodically read parameters, over SNMP for all my network equipment. It will be sent to an external system for storage and viewing.
I understand now that even though my equipment uses the SNMP standards, the same OIDs can sometimes mean different things, and I then have to get all the MIB files from the vendors.
I find many parsers that can give me information from within the MIBs, but what I need is a whole system for importing MIBs, adding them to some kind of library, and for me to know which devices are currently supported by my library. Then, when I receive a message, I need the system to figure out what equipment has sent that, look up the correct info from the MIB and construct an alarm message based on that.
Is there any solution today that can take a list of IPs and send SNMP-get messages to all of those?
Do I need any setup just to receive SNMP traps, or will they just be
attempted delivered at the specified IP address, and I need only to
listen at the correct port?
Is there any way to parse all those MIBs and turn them into a manageable library?
How do I associate the devices with the info from the MIBs, so I interpret the information correctly?
I want to make a general solution for this, so I can expand it to more devices and vendors easily later. Below is a sketch of how a typical network would look like, but of course with a lot more components in real life. Hope someone has some good input.
I am testing a custom FPGA NIC and I need to send management information (such as header info for matching) and traffic data to it using a traffic generator from within the user space.
The driver built for the FPGA is a modified version of IXGBE with DMA support for management, and also supports DPDK for kernel bypass to achieve high throughput.
I am trying to understand how the various software (driver, userspace application, etc) should be stacked/connected to each-other so I can achieve the objective of reading and writing to PCIe on the NIC using set of scripts from user space?
I have also been looking at this project
https://github.com/CospanDesign/python-pci
which is useful however based on Xilinx XDMA.
Would appreciate any help, pointers on this.
Sorry, the question is too broad. For such a broad question there is a generic answer: have a look at Inter Process Communication:
https://en.wikipedia.org/wiki/Inter-process_communication
There are variety of methods, like Unix sockets, shared memory, netlink etc, to communicate between user space processes. As well as a variety of methods to communicate between user space and kernel space.
Just pick the best for you and try to do something. If it fails, come again on SO and ask ;)
SNMP is generally used to monitor the health of components in network.
For SDN [Software Defined network], is it desirable to use SNMP . I am having doubt like is it better to use some other protocol like NETCONFIG
In general SNMP can be used for configuration of a device, however personally I will not stretch it too far specifically when network configuration operation potentially spans across multiple devices and as a result will have higher order transaction requirements.
RFC3512 provides good perspective around configuration using SNMP. Reading through the RFC it will become apparent that within a device transaction relies on how well the MIBs (the objects used via SNMP for performing configuration changes) are designed and implemented. For configuration spanning across multiple devices the device transaction alone will not suffice, if rolling back the configuration is a requirement (this depending on the nature of service/use-case being addressed by your SDN controller). I would recommend reading the Transaction Control in MIB Objects further to understand the requirements on the protocol and eventually the capabilities of the MIB modules that one will be using for configuration.
Netconf was created with configuration of devices in mind and it offers various capabilities that are of use in this regard. These are covered in detail in the IETF standard for Netconf Protocol RFC under Capabilities section. The capabilities such as Candidate Configuration, Validate Configuration, Confirmed Commit, Rollback on Error and other such are specified in the standard which shall further aid in orchestration of a transaction across multiple device.
I want to monitor 3 kinds of data for windows machines:
cpu temperature,
fan temperature
and fan speed, retrieving these data every 5 minutes. If these data can be retrieved by SNMP, that's my first choice.
I am wondering whether these data's root data source comes from Microsoft or the vendor of the motherboard. If they come from Microsoft, their OID should starts with 1.3.6.1.4.1.311, if they come from motherboard vendor, their OID should starts with 1.3.6.1.4.1.[motherboard vendor private snmp vendor OID], for example 1.3.6.1.4.1.11 for a HP server machine, 11 represents HP's private snmp vendor OID.
If you simply want to know how to query a Windows machine for the relevant SNMP data, this is possibly not the right site to ask this question on as it is a site for Q&A specific to software development. You may have better success asking at Server-Fault - here is a similar question to yours on there.
The OIDs for hardware specific SNMP monitoring are usually vendor specific. Typically you would need the Management Information Base (MIB) files that apply to your specific hardware in order to extract the information about which OIDs pertain to the data you require - as far as I know, CPU and Fan temperature are not generic SNMP properties.
If you cannot find the MIBs for your hardware sets (or there is no SNMP agent for your specific hardware), there is a piece of Windows software called SpeedFan that has an SNMP plugin that allows you to monitor the CPU and fan temperatures via SNMP. However this would require the Speedfan software to run in the background on all machines you wish to monitor. The OIDs for the SpeedFan software SNMP plugin are:
Temperature: .1.3.6.1.4.1.30503.1.5.x
Fans: .1.3.6.1.4.1.30503.1.6.x
Voltages: .1.3.6.1.4.1.30503.1.7.x
To get started monitoring this SNMP data on a Windows client machine you typically would need to:
install SNMP agent service
configure the SNMP service
Install speedfan
Install the Speedfan SNMP plugin
determine which OIDs are pertinent to your hardware (either using SpeedFan or vendor specific MIBs)
use an SNMP tool to perform an SNMP walk or an SNMP get to fetch the relevant SNMP data.
Using the command-line tool netsnmp you can walk the SNMP tree like so:
snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.4.1.30503.1.5
(Assuming that your community string is "public" and you want to walk the "SpeedFan termperatures" sub-tree of your machine in this example).
A handy client tool with a gui for viewing snmp data is mibbrowser
The linked to Server-Fault Q&A has other useful information and links to various SNMP monitoring software solutions such as nagios, opennms etc.
I was poring over the docs for Open DayLight, and can't seem to wrap my head around what software-defined networking even is. All the media hype, blogs and articles I can find on SDN are riddled with buzzwords that don't mean anything to me as an engineer. So I ask: What (exactly) is SDN? What are some specific uses cases/problems it solves? Is it:
Just making proprietary networking hardware serve network APIs, thus allowing programs to configure them (instead of IT guys using a console or web interface)?; or
Implementing (traditionally proprietary) networking hardware as software; or
Writing software that somehow integrates with virtual networking hardware used by virtualization platforms (vLANs, vSwitches, etc.)?; or
Something else completely?!?
BONUS: How does Open DayLight fit into this equation here?
First of all, you are right, there is not official definition from NIST or some similar standardization body and the fact that its meaning is fuzzy is exploited by marketing people.
The main point of SDN is that it allows to program network functions with APIs.
In the past, networking devices like switches and routers were only configurable using a proprietary interface (be it vendor specific tools or just the CLI on the device) and there were no APIs which allow to configure OSI L2 - L3 aspects like VLANs and routes but also L6 - L7 aspects like load balancing highly dynamically. Btw. In the case of L6 - L7 functions, the term NVF = Network Virtualized Function seems to be established by now.
This is needed especially for multi tenancy capable virtualized IaaS systems. You can create new VPCs and arrange them together at will. To really isolate tenants from each other, you need to have a L2 isolation and so the same dynamics that is offered for VPCs is propagated to the networking for interconnecting them.
Conclusion: It is about your first bullet with the extension, that the APIs must not necessarily be offered by some hardware appliance, it can also be offered by some pure software implementation.
Regarding OpenDaylight:
It is the OpenStack pendant for SDN. They also actively push integration with OpenStack. They say they are an "open, reference framework for programmability and control through an open source SDN and NFV solution". This means it provides (as you say) a façade for the manfold aspects of networking.
They have all the big names as members which probably means they have the power to establish a de-facto standard like OpenStack did. Members benefit in that they can provide plugins, integrations and adaptations for their products so that they seamlessly integrate with OpenDayligh and you only need to care about a single standard API.
SDN is programmable networks. Different SDN solutions provide different functions in their APIs towards the app developer.
There is a good overview of SDN for software developers here:
https://github.com/BRCDcomm/BVC/wiki/SDN-applications
The most common elements for SDN solutions are
North-bound API: A programming interface used by an application/script to monitor, manage and control the network topology and packet flows within the network.
Network elements: Switching or routing network elements that enforce the rules provided by the application via the north-bound API. These elements may be physical (Cisco, Brocade, Tallac, etc) or virtual (Open VSwitch, Brocade Vyatta vrouter, Cisco 1000, etc) or a combination.
Controller-based solutions have a clustered architectural element (the 'controller') that provides the north-bound api towards applications and an extensible set of south-bound APIs to which network devices connect. Some controllers available today are OpenDaylight, Open Network Operating System (ONOS), Juniper Open Contrail, Brocade Vyatta Controller (ODL distribution), HP VAN Controller and more.
Best rules of thumb to understand an SDN offering:
Read its north-bound API - this tells you what you will be able to monitor, manage and control in your network.
Find out which south-bound APIs it supports - this tells you which switches/routers it might work with.
Some SDN use cases/applications:
DevOps/Admin automation - Applications and scripts that make a network admin or DevOps life easier through automation. OpenStack Neutron is a common example.
Security - HP provides 'Network Protector' that learns the topology of the network and then monitors activity providing alerts and/or remediation of non-compliant behaviors.
Network optimization
Brocade offers 'Traffic Manager' that monitors network utilization and modifies traffic flows in real time to optimize quality based on defined policies.
HP provides 'HP Network Optimizer' that provides an end-to-end voice optimized path for enterprise Microsoft Lync users.
Lyatiss provisions AWS networks in realtime to meet application needs.
Monitoring classroom time-on-task - Elbrys provides an application that provides a teacher with a dashboard to monitor student's time-on-task in real time and cause redirects of individual students to web pages of their choosing. (Disclaimer: I work for Elbrys Networks)
OpenDaylight project proposals page - https://wiki.opendaylight.org/view/Project_Proposals:Main
The concept of SDN is very simple. SDN decouples control-plane (i.e. decision making) from data-plane (the actual forwarding actions) and provides API between them (e.g. OpenFlow API).
Image source: https://www.commsbusiness.co.uk/features/software-defined-networking-sdn-explained/
With SDN architecture, network engineers no longer have to learn proprietary CLI commands for different vendors. They can focus on developing logically centralized control programs to make network global decisions and send it down to network switches (data-plane). Dumped network switches (data-plane) received controller rules/decisions and process network packets accordingly if no decision found they ask the controller.
For example: In SDN architecture routing algorithms developed as a program in the controller, it collects all required metadata (e.g. switches, ports, host connections, links, speed, etc) from the network then make a routing decision for each switch in the network. While in a conventional network, a routing algorithm is implemented in a distributed fashion in all switches (i.e. generally each switch has its own intelligence and makes its own routing decision).
SDN explained by Nick Feamster
Here is a good paper that illustrates the road map to SDN