UNIX way and task generator for computer network architecture
Last winter, one remarkable event took place at our beloved department: the computer network design course was reformed, as a result, instead of one semester of practical classes, two semesters of laboratory classes were formed. On the one hand, both changes, both qualitative and quantitative, meant that students would get more time to master the subject, and the classes would be individual rather than group ones, it’s quite likely that everyone will have to think, not the “core” groups of four -five people. On the other hand, this meant that they would have to develop these very individual tasks, and so that they were all different from each other.
It was then that the idea to write an automatic task generator appeared. About the generator of one of the tasks and I will tell below.
The task was to build and configure the necessary network configuration in Cisco Packet Tracer. Accordingly, the following requirements were imposed on the task generator:
The generator itself consists of a network graph generator itself, a generator of non-overlapping address ranges, and a visualization generator.
')
For writing the generators of the network graph and ranges, it was decided to use the Tcl language, which is now quite undeservedly enjoying relatively low popularity. We did the visualization using Graphviz , and the final document was generated using LaTeX.
The network graph, as is easily seen, can be easily represented as a tree structure in which each network node can be mentioned more than once. The question arose: how to effectively store the tree structure itself? After several attempts to use different approaches, the choice was made in favor of nested dictionaries.
As you know, in Tcl, almost any object can be represented as a text string. The dictionaries are no exception. A dictionary in Tcl is a list containing “key” pairs - “value”, and any list, in turn, can be written as a string in which the elements of the list are separated by spaces. This structure is a bit like JSON, but it has a slightly simpler structure.
Thus, use the dictionary as a list of connections between network nodes: the key is the node number, and the value is the list of nodes with which this node is associated. Each of the elements, in turn, is also a dictionary, which by default contains one element, in which the key is the node number, and the value is empty. The above can be illustrated as follows:
The corresponding dictionary will look like this:
The advantage of this structure is the possibility of sampling along the path to the element: call
Actually, with the means of storing the network structure, the construction of the network itself was no longer a problem - in accordance with the testimony of a random number generator, new nodes were added with simultaneous verification of conditions.
By the way, about the generators. In the first approximation, the script gave very strange results, after which I decided to look at the results of several calls to a random number generator. When I received something like:
Another advantage of the graph storage method was the simplicity of checking for the presence of all nodes in the network — all brackets were thrown out of the graph’s textual representation, resulting in the graph becoming a flat list, then removing duplicate elements (
When the network is generated, the same Tcl script saves the graph in Graphviz dot format, which is converted to EPS, suitable for “feeding” to LaTeX. When the graph is output in dot, the CMR12 font is explicitly specified so that the final document does not have a variety of font typefaces. Here, however, lies one unfortunate surprise: naturally, the fonts created in this way of EPS will not be embedded, but during the final assembly of the document only those characters that are used by LaTeX will be included in the output file. Therefore, in order to correctly display the inscriptions, it was necessary to add the letter “N” behind the paper fields to this very LaTeX source.
To build the document using the traditional "pipeline" of LaTeX, dvips and ps2pdf.
The orchestra conducts a small Makefile that invokes scripts, as well as the aforementioned tools.
After several minutes of operation, the generator produced a two-megabyte PDF containing 1000 tasks per task per page. Tasks looked like this:
It was assumed that the job number will correspond to the last digit of the group number and the student number in the group. In practice, there were more than two times fewer groups than there were hundreds of tasks, and there were far from 100 students in each group, so students would not have a shortage of tasks in the next couple of years.
In addition, a page with parting words was attached to the tasks, as well as a wish to realize why dynamic routing is needed :)
The students 'reaction to the thousand-page PDF was about: “Ehh ?!” One of the students' offers made me laugh: “And if I write a program that parses the network configuration from this PDF, and then generates the configuration for Cisco, will this be counted?”
The generator I described above perfectly serves as an example of how you can, by connecting various programs with each other, to get the desired result without the painful invention of bicycles. Of course, I had to ride a little bit, but everything would have been much worse if I didn’t have at my disposal such wonderful tools as TeXLive, Graphviz, as well as my favorite scripting languages.
In general, this is all that I wanted to tell. Thanks for attention.
PS Those interested can find the source code of the project at: http://bitbucket.org/andrew_shadoura/netgen .
It was then that the idea to write an automatic task generator appeared. About the generator of one of the tasks and I will tell below.
The task was to build and configure the necessary network configuration in Cisco Packet Tracer. Accordingly, the following requirements were imposed on the task generator:
- the maximum number of nodes in the network is 8;
- the maximum number of links leaving a node is 3;
- The maximum number of links in the network is 12.
Some boring technical details
The generator itself consists of a network graph generator itself, a generator of non-overlapping address ranges, and a visualization generator.
')
For writing the generators of the network graph and ranges, it was decided to use the Tcl language, which is now quite undeservedly enjoying relatively low popularity. We did the visualization using Graphviz , and the final document was generated using LaTeX.
The network graph, as is easily seen, can be easily represented as a tree structure in which each network node can be mentioned more than once. The question arose: how to effectively store the tree structure itself? After several attempts to use different approaches, the choice was made in favor of nested dictionaries.
As you know, in Tcl, almost any object can be represented as a text string. The dictionaries are no exception. A dictionary in Tcl is a list containing “key” pairs - “value”, and any list, in turn, can be written as a string in which the elements of the list are separated by spaces. This structure is a bit like JSON, but it has a slightly simpler structure.
Thus, use the dictionary as a list of connections between network nodes: the key is the node number, and the value is the list of nodes with which this node is associated. Each of the elements, in turn, is also a dictionary, which by default contains one element, in which the key is the node number, and the value is empty. The above can be illustrated as follows:
The corresponding dictionary will look like this:
0 {
12
3 4
5 6
7 {
8 2
3 {}
}
} The advantage of this structure is the possibility of sampling along the path to the element: call
[dict get $tree 0 7 8] Actually, with the means of storing the network structure, the construction of the network itself was no longer a problem - in accordance with the testimony of a random number generator, new nodes were added with simultaneous verification of conditions.
By the way, about the generators. In the first approximation, the script gave very strange results, after which I decided to look at the results of several calls to a random number generator. When I received something like:
2 9 0 1 5 7 7 7 4 7 7 7... , I had to slightly modify the getrandom procedure getrandom that it does not return the same values ​​in a row. Probably, experts on random number generators will shower me with something, but this approach has justified itself in this application.Another advantage of the graph storage method was the simplicity of checking for the presence of all nodes in the network — all brackets were thrown out of the graph’s textual representation, resulting in the graph becoming a flat list, then removing duplicate elements (
[lsort -uniq] ) from it get a list of all nodes in the graph.When the network is generated, the same Tcl script saves the graph in Graphviz dot format, which is converted to EPS, suitable for “feeding” to LaTeX. When the graph is output in dot, the CMR12 font is explicitly specified so that the final document does not have a variety of font typefaces. Here, however, lies one unfortunate surprise: naturally, the fonts created in this way of EPS will not be embedded, but during the final assembly of the document only those characters that are used by LaTeX will be included in the output file. Therefore, in order to correctly display the inscriptions, it was necessary to add the letter “N” behind the paper fields to this very LaTeX source.
To build the document using the traditional "pipeline" of LaTeX, dvips and ps2pdf.
The orchestra conducts a small Makefile that invokes scripts, as well as the aforementioned tools.
What happened in the end
After several minutes of operation, the generator produced a two-megabyte PDF containing 1000 tasks per task per page. Tasks looked like this:
It was assumed that the job number will correspond to the last digit of the group number and the student number in the group. In practice, there were more than two times fewer groups than there were hundreds of tasks, and there were far from 100 students in each group, so students would not have a shortage of tasks in the next couple of years.
In addition, a page with parting words was attached to the tasks, as well as a wish to realize why dynamic routing is needed :)
The students 'reaction to the thousand-page PDF was about: “Ehh ?!” One of the students' offers made me laugh: “And if I write a program that parses the network configuration from this PDF, and then generates the configuration for Cisco, will this be counted?”
The generator I described above perfectly serves as an example of how you can, by connecting various programs with each other, to get the desired result without the painful invention of bicycles. Of course, I had to ride a little bit, but everything would have been much worse if I didn’t have at my disposal such wonderful tools as TeXLive, Graphviz, as well as my favorite scripting languages.
In general, this is all that I wanted to tell. Thanks for attention.
PS Those interested can find the source code of the project at: http://bitbucket.org/andrew_shadoura/netgen .
Source: https://habr.com/ru/post/131949/
All Articles