you
Patrick will start you away.
at that time.
And I co-founded a company that is offering support
and custom development for NetXMS in 2009.
And since 2017, it's my full-time job to lead the development
of NetXMS and also participate in the management of state company.
So, why do we need network discovery in the first place?
So, we usually want to create nice maps of our networks,
preferably automatically, so we don't need to draw it,
and we want them up to date.
We want to correlate events in our network based on topology.
So, a very simple example, when we have an upstream router down,
you don't want to get a lot of alerts for all devices behind the router.
We want to correlate them into single alert.
The main source of information is IP neighbors.
And it will be ARP caches on devices for IP version 4
and neighbor discovery protocol caches for IP version 6.
And basically, we just read all the IP addresses mentioned in the ARP table
and took it as a potential target for monitoring.
The routing tables are another useful source of information.
We can take host routes, we can take gateway addresses from routing tables,
and this is really helpful dealing with point-to-point links
or any other links when we don't have ARP protocol.
And this actually allows our passive discovery
to help through the civil links, for example, in the network.
In NetXMS, we also use other sources of information about IP addresses.
So, any syslog message, for some reason, comes to the management server.
Any SNMP trap received, we can take the source address
and use it as a potential device to monitor.
And we also can support proprietary methods, proprietary MIPS,
like an example of Micropeak, Neighbor Tables,
so anything that is specific to certain equipment.
In NetXMS, we have a special layer, we call it network device drivers.
Those are pluggable modules that hide vendor specifics
and provide information in a unified form to the upper layer.
Active scan, that's really simple, we just send out packets
and network devices like switches and routers,
they should be accessible by SNMP from network management system.
The monitoring system will take some preparation steps.
So, for each device that is added to the monitoring,
we will read full interface information from that device,
name of the interface, description, MAC address, IP addresses,
because we will need this information to match topology data.
If device supports BridgeMap, which is normal for all switches,
then we will read Bridgeport Mapping as well from BridgeMap.
And if device is LDP capable, then we will read LDP local port information as well.
Then we have multiple sources of topology information,
and the first and most important and most reliable usually is LDP.
It's an industry standard now,
and a brief summary how LDP operates.
So, each LDP capable device will send a fixed intervals,
information frames that can be received by other LDP capable device.
And if we talk about switches, the switch will work in a bit unusual way,
it will not forward the frame as it will do with any other frame,
it will receive it and process it,
and on other ports it will send its own LDP information frames.
So, each frame contains a sequence of TLV structures,
and there are a few mandatory TLVs, which principles as LDP,
so basically we will do the same stuff, but we will use different MIPs.
Another interesting source is switch forwarding database,
or sometimes it's called MAC address table.
It's not a protocol as such, it's just a table within the switch
that determines to which port the switch should forward frames
designed for specific MAC address.
And if we read MAC address table from the switch,
we can identify ports that only have one MAC address known on them.
And we can assume that this is only one device connected to that switch port,
so we can add a topology link connecting that device,
which may not be manageable at all, so it may be just,
we can just ping it and know its MAC address,
and we know that it's connected on that switch port.
And this is a MAC address table example, and we see that the first three ports
have only one MAC address, so we can assume that the end nodes connected,
it's not some link between switches.
Another bit unusual source of topology information is spending free.
This is a spending free protocol that's never intended to be a protocol
for topology discovery, but still we can get some information
about connectivity between switches from spending free,
and we can use it as last resort if we don't have LLDP or CDP between switches.
So how spending free operates?
When the switches are connected in the spending free domain,
they elect a root bridge, and then every switch will have a root port.
This is the port that points to the shortest path to the root,
and it will also elect designated ports.
In theory, the problem is there's a lot of vendors,
especially maybe not from the top, they implement LLDP in the wrong way,
so they may send wrong information LLDP packets itself.
They may send everything correctly on LLDP level,
but they may report absolute garbage through the SNMP when you read this LLDP myth.
So we actually have a lot of code inside the monitoring
to deal with inconsistencies and incorrect data in devices from different vendors.
Those are some comments from our code related to specific devices.
So that's it, a quick overview of how we do network discovery.
If you have any questions, you can ask us later, visit our website. Thank you.
We have one question.
Hello, sorry, can I ask one question?
Question.
Sorry.
Yeah.
I have one question.
Real quick, I was wondering if you've looked into using Open Config at all to collect some of this data.
No.
Have you considered or looked at Open Config at all to collect some of this data about neighbors?
I don't.
Open Config.
Open Config now, we don't use it.
But we always open to new ways.