Why network engineers need programming
It is interesting to exchange views and experience of using programming languages in solving problems of a network engineer, if you use any methods and approaches of automation, write about it in the comments, and I will talk about some of my best practices in this direction.
Not so long ago, I was a participant in a project to change the IGP interaction scheme; it was necessary to migrate to a live network as part of the project. Considering the scale of the project, the work was broken up into several independent stages, and we developed an excellent, in terms of network design, migration plan in order to seamlessly proceed to the next stage and roll back the configuration of the routers to the previous one if the tests showed different than expected behavior. When planning the configuration, we divided the stages into groups with a complex and simple set of changes, in order to prepare the configuration of the stages, which we assigned to a complex group, we wrote the generator and the actual source data environment, which is updated after the successful completion of the stage and serves as a starting point for preparing the following configuration .
At the penultimate stage, when it was only necessary to strip part of the old configuration, we faced an unplanned break in the service due to literally several “childish” syntactic errors in the set of executable commands that were written manually for this stage. We quickly corrected errors, so we even put in the allotted work window, and we learned, I think, a useful conclusion - if you can automate the filling of certain configuration blocks using templates, do it as often as possible . In large tasks, this reduces the likelihood of error, and in routine operations saves time. At the output, you get a unified configuration that is easy to operate, with minimal time.
')
In an ideal world, I could not come up with reasons why network engineers can use programming experience, but the real world and our ideas about it often do not coincide. For many network engineers, a situation may seem familiar when something on the network had to be configured in a certain way, but for some reason, or mistakenly configured differently - the STP filter or broadcast traffic suppression is not registered on the client interface some sections in the CoPP filter, BGP prefix type mismatch assigned by community, missed MTU on backbone interface, and so on. The pain list can be continued for a very long time, so the configuration of services and components of the live network should be periodically validated to match the established templates and the required parameter sets . Before validation, you will have to type the configuration elements; this is in itself a great and useful work. Spread the configuration elements into sets, and the sets into subsets, assigning each of them the required template and the required set of properties. For example, a switch port may belong to multiple client ports or, in the case of ERPS, be transit through one or multiple rings. For typing, I usually use the description field, for ports, for example, it might look like this: id / type / speed / phb / mon_s / mon_b / remote ,
If you type BGP groups, a good beginning can be filling, which determines the group’s belonging to one of the sets: UP for upstream operators, DN for customers, PR for exchange points or PPR for private joints, IAS for Inter-AS joints. Each of these groups, in turn, can be typed by the desired set of transmitted or received prefixes.
For operation it is useful to type also:
As I already wrote, typing should be considered not only as a prerequisite for carrying out validation, but also as a separate process of obtaining a formal description of the objects in your network, which will be useful for planning work, assessing risks and determining the level of importance of a particular event. It's nice when the change of the NOC, finding an emergency indication on the RSVP redundant path at half past three in the morning, assigns an appropriate level of response to the incident instead of waking the network engineers of the second level of support.
Depending on the tasks, the list and rules of typing can vary within very wide limits; take this process seriously so that during the validation stage of configurations your check rules are simple, and templates are deprived of redundancy and intersections between them. I recommend not to leave white spots or exceptions to the rules of typification, in this case it is better to work according to the “all or nothing” rule. If there are exceptions, make rules of them so that you can break up the set of objects with individual features into several sets of elements with unified characteristics. For example, if joints with CE on your network can have both Active-Active and Active-Backup, reflect this as separate types.
The writing of validation procedures is very closely related to the syntax for representing configuration blocks of manufacturers of the equipment in use. If the operating system of your equipment allows you to present the configuration in the form of XML or JSON, then there is nothing further to talk about, since it is a pleasure to check the fields of these formats. But even if the configuration blocks of your manufacturer have a slightly less formal look, don’t be in a hurry to refuse this idea. A good help in this work is the CLI References and the Command Guide, in which not only the required or optional parameters of the configuration blocks are indicated, but also the exact sequence and interrelation of the lexemes used. For example, the following command for Huawei routers
mpls rsvp-te timer retransmission {increment-value increment | retransmit-value interval} *
matches the pattern {x | y | ...} *, which implies one or more optional arguments. I advise you not to rely on memory when you write a validator code, just keep the page with the description of the necessary command for the current software version of your equipment open.
For myself, I have designated two approaches to parsing configuration files, in simple cases it is logical to use regular expressions in combination with the dictionary of the manufacturer's tokens. This is not a very flexible approach with almost zero tolerability, but these types of checks are implemented quite simply. For more in-depth analysis or for transferring configuration tasks to equipment from another manufacturer, I propose to consider the configuration file as a tree whose elements are related by the parent-child relationship. In such a data structure, you can easily search and select samples for various conditions.
It is useful if the typing procedure will not only report errors, missed or unnecessary commands, but also indicate the configuration places whose type could not be recognized. This will help after a few work cycles to get rid of white spots and bring the configuration of network equipment to a unified form. Do not rush to fix the errors found directly from the validator, as my experience in implementing configuration verification systems shows, it is necessary for some time to maintain a feedback between the results of the validator and the classification of network objects. Inaccuracies are possible, so until a certain point I advise you to closely monitor the results of work and make appropriate adjustments. I also advise you to pay special attention to the automatic configuration editing scenarios based on the errors found, carefully monitor the sequence of generated commands so that this sequence does not depend on the order of the verification procedures, this is especially important in multi-threaded environments. A trivial example of this inconsistency is adding a missing VLAN number per port before it is advertised in the global table. In an amicable way, after executing each command, it is necessary to check the interpreter's response , this practice minimizes the likelihood of using a half-way configuration, like declaring a BGP neighbor with a missing prefix export policy, and the like.
But not the configuration of a single busy network engineer, sometimes you need to look at the network, as they say, from above. A good help in this matter will serve as graph theory and algorithms for them. Initial knowledge in this area allows you to find closed and open rings in your network, evaluate the degree of connectivity of clusters or groups of devices, predict partial failure scenarios, determine the boundaries of failure and risk domains, and solve other analytical and creative problems.
Not so long ago, I was a participant in a project to change the IGP interaction scheme; it was necessary to migrate to a live network as part of the project. Considering the scale of the project, the work was broken up into several independent stages, and we developed an excellent, in terms of network design, migration plan in order to seamlessly proceed to the next stage and roll back the configuration of the routers to the previous one if the tests showed different than expected behavior. When planning the configuration, we divided the stages into groups with a complex and simple set of changes, in order to prepare the configuration of the stages, which we assigned to a complex group, we wrote the generator and the actual source data environment, which is updated after the successful completion of the stage and serves as a starting point for preparing the following configuration .
At the penultimate stage, when it was only necessary to strip part of the old configuration, we faced an unplanned break in the service due to literally several “childish” syntactic errors in the set of executable commands that were written manually for this stage. We quickly corrected errors, so we even put in the allotted work window, and we learned, I think, a useful conclusion - if you can automate the filling of certain configuration blocks using templates, do it as often as possible . In large tasks, this reduces the likelihood of error, and in routine operations saves time. At the output, you get a unified configuration that is easy to operate, with minimal time.
')
In an ideal world, I could not come up with reasons why network engineers can use programming experience, but the real world and our ideas about it often do not coincide. For many network engineers, a situation may seem familiar when something on the network had to be configured in a certain way, but for some reason, or mistakenly configured differently - the STP filter or broadcast traffic suppression is not registered on the client interface some sections in the CoPP filter, BGP prefix type mismatch assigned by community, missed MTU on backbone interface, and so on. The pain list can be continued for a very long time, so the configuration of services and components of the live network should be periodically validated to match the established templates and the required parameter sets . Before validation, you will have to type the configuration elements; this is in itself a great and useful work. Spread the configuration elements into sets, and the sets into subsets, assigning each of them the required template and the required set of properties. For example, a switch port may belong to multiple client ports or, in the case of ERPS, be transit through one or multiple rings. For typing, I usually use the description field, for ports, for example, it might look like this: id / type / speed / phb / mon_s / mon_b / remote ,
- Id - for example client1
- The type can be the following values: CUST2 - clients with the second level service, CUST3 - clients with the third level service, BB - trunk MPLS ports of the third level, AG - MPLS ports to aggregation devices, AC - MPLS ports to access devices, BR - trunk ports the second level, TR - transit ports of the third level, etc.
- speed - actual or contractual bands.
- php is a type of classification, repainting and processing QOS PHB.
- mon_s - type of reaction to emergency indication of a change in NOC or monitoring system.
- mon_b is the type of local response of the device to an emergency.
- remote - identifier of the response equipment and port.
If you type BGP groups, a good beginning can be filling, which determines the group’s belonging to one of the sets: UP for upstream operators, DN for customers, PR for exchange points or PPR for private joints, IAS for Inter-AS joints. Each of these groups, in turn, can be typed by the desired set of transmitted or received prefixes.
For operation it is useful to type also:
- RSVP paths - reserved / not, signaling / data, primary / standby, with or without band, inside or between provinces.
- Ethernet / TDM pseudowires, with or without SLA, wide or narrow cavities, with or without back-up.
- VPLS or VPN instances — service or client, with or without SLA, are wide or narrowly cavitary.
As I already wrote, typing should be considered not only as a prerequisite for carrying out validation, but also as a separate process of obtaining a formal description of the objects in your network, which will be useful for planning work, assessing risks and determining the level of importance of a particular event. It's nice when the change of the NOC, finding an emergency indication on the RSVP redundant path at half past three in the morning, assigns an appropriate level of response to the incident instead of waking the network engineers of the second level of support.
Depending on the tasks, the list and rules of typing can vary within very wide limits; take this process seriously so that during the validation stage of configurations your check rules are simple, and templates are deprived of redundancy and intersections between them. I recommend not to leave white spots or exceptions to the rules of typification, in this case it is better to work according to the “all or nothing” rule. If there are exceptions, make rules of them so that you can break up the set of objects with individual features into several sets of elements with unified characteristics. For example, if joints with CE on your network can have both Active-Active and Active-Backup, reflect this as separate types.
The writing of validation procedures is very closely related to the syntax for representing configuration blocks of manufacturers of the equipment in use. If the operating system of your equipment allows you to present the configuration in the form of XML or JSON, then there is nothing further to talk about, since it is a pleasure to check the fields of these formats. But even if the configuration blocks of your manufacturer have a slightly less formal look, don’t be in a hurry to refuse this idea. A good help in this work is the CLI References and the Command Guide, in which not only the required or optional parameters of the configuration blocks are indicated, but also the exact sequence and interrelation of the lexemes used. For example, the following command for Huawei routers
mpls rsvp-te timer retransmission {increment-value increment | retransmit-value interval} *
matches the pattern {x | y | ...} *, which implies one or more optional arguments. I advise you not to rely on memory when you write a validator code, just keep the page with the description of the necessary command for the current software version of your equipment open.
For myself, I have designated two approaches to parsing configuration files, in simple cases it is logical to use regular expressions in combination with the dictionary of the manufacturer's tokens. This is not a very flexible approach with almost zero tolerability, but these types of checks are implemented quite simply. For more in-depth analysis or for transferring configuration tasks to equipment from another manufacturer, I propose to consider the configuration file as a tree whose elements are related by the parent-child relationship. In such a data structure, you can easily search and select samples for various conditions.
It is useful if the typing procedure will not only report errors, missed or unnecessary commands, but also indicate the configuration places whose type could not be recognized. This will help after a few work cycles to get rid of white spots and bring the configuration of network equipment to a unified form. Do not rush to fix the errors found directly from the validator, as my experience in implementing configuration verification systems shows, it is necessary for some time to maintain a feedback between the results of the validator and the classification of network objects. Inaccuracies are possible, so until a certain point I advise you to closely monitor the results of work and make appropriate adjustments. I also advise you to pay special attention to the automatic configuration editing scenarios based on the errors found, carefully monitor the sequence of generated commands so that this sequence does not depend on the order of the verification procedures, this is especially important in multi-threaded environments. A trivial example of this inconsistency is adding a missing VLAN number per port before it is advertised in the global table. In an amicable way, after executing each command, it is necessary to check the interpreter's response , this practice minimizes the likelihood of using a half-way configuration, like declaring a BGP neighbor with a missing prefix export policy, and the like.
But not the configuration of a single busy network engineer, sometimes you need to look at the network, as they say, from above. A good help in this matter will serve as graph theory and algorithms for them. Initial knowledge in this area allows you to find closed and open rings in your network, evaluate the degree of connectivity of clusters or groups of devices, predict partial failure scenarios, determine the boundaries of failure and risk domains, and solve other analytical and creative problems.
Source: https://habr.com/ru/post/350366/
All Articles