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
Find SysAdmin Jobs
News
-
Kubuntu Focus Announces XE Gen 2 Linux Laptop
Another Kubuntu-based laptop has arrived to be your next ultra-portable powerhouse with a Linux heart.
-
MNT Seeks Financial Backing for New Seven-Inch Linux Laptop
MNT Pocket Reform is a tiny laptop that is modular, upgradable, recyclable, reusable, and ships with Debian Linux.
-
Ubuntu Flatpak Remix Adds Flatpak Support Preinstalled
If you're looking for a version of Ubuntu that includes Flatpak support out of the box, there's one clear option.
-
Gnome 44 Release Candidate Now Available
The Gnome 44 release candidate has officially arrived and adds a few changes into the mix.
-
Flathub Vying to Become the Standard Linux App Store
If the Flathub team has any say in the matter, their product will become the default tool for installing Linux apps in 2023.
-
Debian 12 to Ship with KDE Plasma 5.27
The Debian development team has shifted to the latest version of KDE for their testing branch.
-
Planet Computers Launches ARM-based Linux Desktop PCs
The firm that originally released a line of mobile keyboards has taken a different direction and has developed a new line of out-of-the-box mini Linux desktop computers.
-
Ubuntu No Longer Shipping with Flatpak
In a move that probably won’t come as a shock to many, Ubuntu and all of its official spins will no longer ship with Flatpak installed.
-
openSUSE Leap 15.5 Beta Now Available
The final version of the Leap 15 series of openSUSE is available for beta testing and offers only new software versions.
-
Linux Kernel 6.2 Released with New Hardware Support
Find out what's new in the most recent release from Linus Torvalds and the Linux kernel team.