Saving and evaluating network paths in Neo4j
Feeding Machine
Of course, it would be extremely tedious to type in the data manually for a large network. That's why the routers.yml
file in Listing 1 [2] defines the key data for all routers in the readable YAML format. The links between the routers as relations in the graph later implicitly result from connecting the gateway addresses of one router with the LAN IP of the next one.
Listing 1
routers.yml
The script in Listing 2 grabs the Yaml records of all the routers from the routers.yml
file. Starting in line 28, it iterates through the list and dumps it into the database as a collection of nodes – thanks to the CPAN REST::Neo4p module. While doing so, it saves all the references to the node objects created in the %lans
hash using the LAN IPs as the key.
Listing 2
router-setup
The script also stores the gateway IPs encountered in the @gateways
array along with the routers that use these gateway IPs. Starting in line 46, a for
loop iterates through @gateways
, uses the %lans
hash to discover the target object, and defines one gateway
relation from the start to the destination router in the database using the method relate_to()
.
As soon as the script finishes, a glance at the browser interface provided through port 7474 shows that the data is properly stored in Neo4j (Figure 2).
With a query such as MATCH (n) RETURN n
, which returns all previously stored nodes, the database browser shows the nodes as numbered squiggles in graph mode and their relationships as labeled arrows that point from one node to the next in the graph.
When you click on a node, its attributes are displayed in a dialog box that pops up. In text mode, the boxes shown in Figure 2 with the attribute values of the nodes edge into the picture.
Gordian Knot
To be able to replace the network structure in the database without leftovers if changes are made to the Yaml data, Listing 2 starts by deleting all the previously defined nodes and relations in the graph. This step is not as easy as you might think, because to keep the data model intact, Neo4j refuses to delete nodes that still have relationships. The Cypher query for purging the database therefore does:
MATCH (n) OPTIONAL MATCH (n)-[r]-() DELETE n,r
This matches all nodes n
– as well as any relationships to another (anonymous) node emanating from them. The delete statement that follows then deletes the entry for the node, including it's outgoing relations.
To show all the routers stored in the database with the Neo4j shell, you would just run the query shown in Figure 3. If you simply had a RETURN n
, instead of the return clause with three attribute values of interest (n.name
, n.hardware_vendor
, …), the query result would contain all the defined attributes, which could be hard to read. Instead, the query uses RETURN
with specific field names to hide any values that are not of interest.
Walking Paths
Of course, the advantages of a graph database are not found in menial services, such as finding nodes by their attributes, but in finding connection paths between nodes. It's actually quite simple to find out which network connections exist in the graph: The query in Figure 4 uses MATCH(n)
to consider all the routers on the network. The relation description -[r:gateway*]->
matches one or more relations of the type gateway
; the (m)
in the query after the relation description stands for the terminating node in the found path.
Because the Cypher query stores the results in the p
variable with a prepended p=
, a subsequent RETURN p
would output all routing paths with all the routers considered by the query including their attributes. That would be a real mess of data. The return statement therefore restricts the output to the router name at the beginning of the route and uses collect(m.name)
to concatenate the names of all subsequent routers on the path covered by the query.
The output in Figure 4 thus has two columns: The first contains the identified start router, and the second contains a list with the names of routers passed through on the way to the open Internet.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Direct Download
Read full article as PDF:
Price $2.95
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
News
-
An All-Snap Version of Ubuntu is In The Works
Along with the standard deb version of the open-source operating system, Canonical will release an-all snap version.
-
Mageia 9 Beta 2 Ready for Testing
The latest beta of the popular Mageia distribution now includes the latest kernel and plenty of updated applications.
-
KDE Plasma 6 Looks to Bring Basic HDR Support
The KWin piece of KDE Plasma now has HDR support and color management geared for the 6.0 release.
-
Bodhi Linux 7.0 Beta Ready for Testing
The latest iteration of the Bohdi Linux distribution is now available for those who want to experience what's in store and for testing purposes.
-
Changes Coming to Ubuntu PPA Usage
The way you manage Personal Package Archives will be changing with the release of Ubuntu 23.10.
-
AlmaLinux 9.2 Now Available for Download
AlmaLinux has been released and provides a free alternative to upstream Red Hat Enterprise Linux.
-
An Immutable Version of Fedora Is Under Consideration
For anyone who's a fan of using immutable versions of Linux, the Fedora team is currently considering adding a new spin called Fedora Onyx.
-
New Release of Br OS Includes ChatGPT Integration
Br OS 23.04 is now available and is geared specifically toward web content creation.
-
Command-Line Only Peropesis 2.1 Available Now
The latest iteration of Peropesis has been released with plenty of updates and introduces new software development tools.
-
TUXEDO Computers Announces InfinityBook Pro 14
With the new generation of their popular InfinityBook Pro 14, TUXEDO upgrades its ultra-mobile, powerful business laptop with some impressive specs.