Geekly Articles each Day
📜 ⬆️ ⬇️

How to take control of network infrastructure. Part two. Cleaning and documentation

image

Our goal at this stage is to establish order in the documentation and configuration.
At the output of this process, you must have the necessary set of documents and a network configured in accordance with them.

Now we will not talk about security audit - the third part will be devoted to this.
')
The complexity of the task at this stage, of course, varies greatly from company to company.

The ideal situation is when


In this case, your task is quite simple. You must review the documents and review all the changes that have been made.

In the worst case, you will have


It is clear that your situation is somewhere in between, but, unfortunately, on this scale is better - worse, with a high probability, you will be closer to a worse end.

In this case, you will be required to include the ability to read minds, because you will have to learn to understand what the “designers” wanted to do, restore their logic, finish what was not finished and remove the “garbage”.
And, of course, you will need to stop their mistakes, change (at this stage as little as possible) the design and change or re-create the scheme.

This article in no way claims to be complete. Here I will describe only the general principles and focus on some common problems that have to be addressed.

Set of documents


Let's start with an example.

Below are some of the documents that are usually created at Cisco Systems when designing.

CR - ustomer Requirements, customer requirements (those. Task).
It is created together with the customer and determines the network requirements.

HLD - High Level Design, high-level design based on network requirements (CR). The document explains and justifies the adopted architectural decisions (topology, protocols, equipment selection, ...). HLD does not contain design details, for example, about the interfaces used and IP addresses. Also, the specific hardware configuration is not discussed here. This document is rather intended to explain the key design concepts to the technical management of the customer.

LLD - Low Level Design, low level design based on high level (HLD).
It should contain all the details necessary for the implementation of the project, such as information on how to connect and configure the equipment. This is a complete guide to the implementation of the design. This document should provide sufficient information for its implementation even by not very qualified personnel.

Something, for example, IP addresses, AS numbers, the physical switching circuit (cabling), can be “rendered” into separate documents, such as the NIP (Network Implementation Plan).

The construction of the network begins after the creation of these documents and takes place in strict accordance with them and then is checked by the customer (tests) for compliance with the design.

Of course, different integrators, different customers, and different countries may have different requirements for project documentation. But I would like to avoid formalities and consider the issue on the merits. This stage is not about design, but about putting things in order, and we need a set of documents sufficient for our tasks (charts, tables, descriptions ...).

And in my opinion, there is a certain absolute minimum, without which it is impossible to effectively control the network.

These are the following documents:


Physical switching circuit


In some small companies, work related to equipment installation and physical switching (cabling) is under the responsibility of network engineers.

In this case, the problem is partially solved by the following approach.


This will give you the opportunity, even in the event of a link problem (when cdp or lldp is not working on this interface), to quickly determine what is connected to this port.
Also, you can easily see which ports you have are occupied and which ones are free, which is necessary for planning connections of new network equipment, servers or workstations.

But it is clear that if you lose access to the equipment, you will lose access to this information. Moreover, in this way you cannot record such important information as what the equipment is, with what power consumption, with how many ports, in which rack it is, what kind of patch panel is there and where (in which rack / patch panel) are they connected . Therefore, additional documentation (not only on hardware descriptions) is very useful.

The ideal option is to use applications created to work with this kind of information. But you can restrict yourself to simple tables (for example, in Excel) or display information that you consider necessary in L1 / L2 diagrams.
Important!

The network engineer, of course, can know quite well the subtleties and standards of SCS, types of racks, types of uninterruptible power supplies, what a cold and hot corridor is, make proper grounding ... just like in principle he can know particle physics or C ++. But it is necessary to understand nevertheless that all this is not his field of knowledge.

Therefore, it is a good practice to solve problems associated with the installation, connection, maintenance of equipment, as well as physical switching to have either dedicated departments or dedicated people. Usually for data centers this is a data center engineers, and for an office it is a help-desk.

If such units are provided for in your company, then the issues of physical switching logging are not your task, and you can restrict yourself to a description on the interface and administrative shutdown of unused ports.

Network diagrams


There is no universal approach to drawing schemes.

The most important thing is that the schemes should give an understanding of how traffic will go, through which logical and physical elements of your network.

By physical elements we mean


Under logical -


Also, if your network is not completely elementary, it will consist of different segments.
for example


It would be reasonable to have several schemes that give both a general picture (as traffic flows between all these segments) and a detailed explanation of each individual segment.

Since in modern networks there can be many logical levels, it is possible that a good (but not obligatory) approach is to do different schemes for different levels, for example, in the case of an overlay approach, the following schemes could:


Of course, the most important scheme without which it is impossible to understand the idea of ​​your design is the routing scheme.

Routing scheme


At least this diagram should be reflected


Also, the L2 scheme (OSI) is often useful.

L2 scheme (OSI)


This diagram may reflect the following information:


Typical design errors


An example of a bad approach to building a network.

Let's take a simple example of building a simple office LAN.

Having experience in teaching telecoms to students, I can say that by the middle of the second semester virtually every student has the necessary knowledge (as part of the course that I taught) in order to set up a simple office LAN.

What is difficult to connect switches to each other, configure VLANs, SVI interfaces (in the case of L3 switches) and register static routing?

Everything will work.

But at the same time, issues related to

  • security
  • by reservation
  • network scaling
  • performance
  • bandwidth
  • reliability
  • ...

At times, I hear a statement that an office LAN is something very simple and I usually hear it from engineers (and managers) who do everything but not networks, and they say it so confidently that they don’t be surprised if LAN will be made by people with insufficient practice and knowledge and will be made approximately with the mistakes that I will describe below.

Typical design level L1 errors (OSI)



I would also refer to type L1 errors related to the resources of the equipment used, for example,


Typical L2 design level errors (OSI)


Often, when there is no good understanding of how STP works, what potential problems it carries with it, the switches are connected randomly, with default settings, without additional tuning of STP.

As a result, we often have the following


Examples of errors in L3 (OSI) design


A few characteristic mistakes novice networkers:


Criteria for assessing the quality of design


When we talk about optimality / non-optimality, we need to understand in terms of what criteria we can evaluate it. Here, from my point of view, the most significant (but not all) criteria (and decoding applied to routing protocols):


Changes


The basic principle at this stage can be expressed by the formula "do no harm."
Therefore, even if you do not fully agree with the design and the chosen implementation (configuration), it is not always advisable to make changes. A reasonable approach is to rank all the identified problems by two parameters:


First of all, it is necessary to eliminate the fact that in real time it reduces the level of the provided service below permissible, for example, problems leading to packet loss. Then eliminate what is easiest and safer to eliminate in order of decreasing severity of risk (from design or configuration problems that carry greater risks towards smaller ones).

Perfectionism at this stage can be harmful. Bring the design to a satisfactory state and synchronize the network configuration in accordance with it.

Source: https://habr.com/ru/post/434750/

More articles:


All Articles