{"id":31067,"date":"2019-10-31T21:39:16","date_gmt":"2019-10-31T18:39:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie\/"},"modified":"2019-10-31T21:39:16","modified_gmt":"2019-10-31T18:39:16","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","title":{"rendered":"How to Take Control of Your Network Infrastructure. Chapter Two. Cleaning and Documentation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>This article is the second in a series titled \"How to Take Control of Your Network Infrastructure.\" You can find the content of all articles in the series and links here. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">here<\/a><\/noindex><\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"How to Take Control of Your Network Infrastructure. Chapter Two. Cleaning and Documentation\" src=\"\/wp-content\/uploads\/2019\/04\/7b8e020272ed52ef0a119714b0a5d58b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOur goal at this stage is to bring order to the documentation and configuration. <br \/>\nBy the end of this process, you should have the necessary documentation and a network configured according to it.<\/p>\n<p>At this point, we won't discuss security audits \u2013 that will be covered in the third part. <\/p>\n<p>The complexity of the task at this stage varies greatly from company to company.<\/p>\n<p>The ideal situation is when<\/p>\n<ul>\n<li>your network was built according to the design and you have a complete set of documents<\/li>\n<li>your company has implemented <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/433614\/\">a change control and management process<\/a><\/noindex> for the network<\/li>\n<li>according to this process, you have documents (including all necessary diagrams) that provide complete information about the current state of affairs<\/li>\n<\/ul>\n<p>\nIn this case, your task is quite simple. You need to review the documents and look through all the changes that have been made. <\/p>\n<p>In the worst-case scenario, you will have<\/p>\n<ul>\n<li>a network created without a design, without a plan, without approvals, by engineers lacking sufficient qualification,<\/li>\n<li>with chaotic, undocumented changes, full of 'junk' and suboptimal solutions.<\/li>\n<\/ul>\n<p>\nIt\u2019s clear that your situation is somewhere in between, but unfortunately, on this scale, better or worse likely places you closer to the worse end.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>In this case, you will also need the ability to read minds, because you will have to learn to understand what the 'designers' intended, restore their logic, finish what was left undone, and remove the 'junk.' <br \/>\nAnd of course, you will need to fix their mistakes, change (as minimally as possible at this stage) the design, and modify or recreate the diagrams. <\/p>\n<p>This article does not claim to be exhaustive. Here, I will only describe general principles and touch on some common issues that need to be addressed.<\/p>\n<h2>Set of Documents<\/h2>\n<p><\/p>\n<blockquote><p>Let's start with an example.<\/p>\n<p>Below are some documents that are typically created at Cisco Systems during the design process.<\/p>\n<p><b>CR<\/b> \u2013 Customer Requirements, client requirements (technical assignment).<br \/>\nCreated collaboratively with the client, it defines the network requirements.<\/p>\n<p><b>HLD<\/b> \u2013 High Level Design, a high-level design based on network requirements (CR). The document explains and justifies the architectural decisions made (topology, protocols, equipment selection, \u2026). HLD does not contain the design details, such as the interfaces used and IP addresses. Specific equipment configurations are also not discussed here. This document is rather intended to explain key design concepts to the client's technical management.<\/p>\n<p><b>LLD<\/b> \u2013 Low Level Design, low-level design based on high-level design (HLD). <br \/>\nIt should include all the details necessary for project implementation, such as information on how to connect and configure the equipment. This is a complete guide for implementing the design. This document should provide sufficient information for its execution even by less skilled personnel. <\/p>\n<p>Certain elements, such as IP addresses, AS numbers, or physical cabling schemes, can be 'extracted' into separate documents, such as <b>NIP<\/b> (Network Implementation Plan).<\/p>\n<p>Network construction begins after these documents are created and occurs strictly in accordance with them, and is then verified by the client (tests) for compliance with the design.<\/p><\/blockquote>\n<p>\nOf course, different integrators, different clients, and different countries may have varying requirements for project documentation. However, we would like to avoid formalities and focus on the substance. This stage is not about design but about establishing order, and we need a sufficient set of documents (diagrams, tables, descriptions, etc.) to accomplish our tasks. <\/p>\n<p>In my opinion, there exists an absolute minimum without which effective network control is impossible.<\/p>\n<p>These documents are as follows:<\/p>\n<ul>\n<li>a diagram (log) of physical cabling<\/li>\n<li>one or more network diagrams with significant L2\/L3 information<\/li>\n<\/ul>\n<p><\/p>\n<h2>Physical cabling diagram<\/h2>\n<p>\nIn some small companies, tasks related to equipment installation and physical cabling are the responsibility of network engineers. <\/p>\n<p>In this case, the problem is partially solved by the following approach. <\/p>\n<ul>\n<li>use the description on the interface to explain what is connected to it<\/li>\n<li>administratively shut down all unused ports of the networking equipment<\/li>\n<\/ul>\n<p>\nThis will allow you, even in case of a link issue (when CDP or LLDP is not working on this interface), to quickly identify what is connected to this port.<br \/>\nYou will also easily see which ports are occupied and which are free, which is necessary for planning connections of new networking equipment, servers, or workstations. <\/p>\n<p>However, it is clear that if you lose access to the equipment, you will also lose access to this information. Additionally, this way you won\u2019t be able to log such important information as what equipment is there, its power consumption, the number of ports, what rack it is located in, what patch panels are there, and where (in which rack\/patch panel) they are connected. Therefore, additional documentation (not just descriptions on the equipment) is very useful.<\/p>\n<p>The ideal option is to use applications designed for working with such information. But you can also get by with simple tables (for example, in Excel) or display the information you consider necessary in L1\/L2 diagrams.<\/p>\n<blockquote><p>Important!<\/p>\n<p>A network engineer can certainly be well-versed in the intricacies and standards of structured cabling systems, types of racks, types of uninterruptible power supplies, what a cold and hot aisle is, and how to make proper grounding, just as they may know the physics of elementary particles or C++. But it must be understood that all of this is not their area of expertise. <\/p>\n<p>Therefore, it is good practice to have either dedicated departments or designated individuals for tasks related to the installation, connection, support of the equipment's functionality, as well as physical patching. Usually, for data centers, this means data center engineers, and for offices \u2014 help desk. <\/p>\n<p>If such departments are provided in your company, then the issue of maintaining a log of physical patching is not your responsibility, and you can limit yourself to just the description on the interface and the administrative shutdown of unused ports.<\/p><\/blockquote>\n<h2>Network diagrams<\/h2>\n<p>\nThere is no one-size-fits-all approach to drawing diagrams.<\/p>\n<p>The most important thing is that the diagrams should provide an understanding of how traffic will flow through the logical and physical elements of your network.<\/p>\n<p>By physical elements, we mean<\/p>\n<ul>\n<li>active equipment<\/li>\n<li>interfaces\/ports of active equipment<\/li>\n<\/ul>\n<p>\nBy logical, we mean <\/p>\n<ul>\n<li>logical devices (N7K VDC, Palo Alto VSYS, \u2026)<\/li>\n<li>VRF <\/li>\n<li>VLANs<\/li>\n<li>subinterfaces<\/li>\n<li>tunnels<\/li>\n<li>zones<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>\nMoreover, if your network is not completely basic, it will consist of different segments. <br \/>\nFor example<\/p>\n<ul>\n<li>data center<\/li>\n<li>internet<\/li>\n<li>WAN<\/li>\n<li>remote access<\/li>\n<li>office LAN<\/li>\n<li>DMZ<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>\nIt would be reasonable to have several diagrams that provide both a general picture (how traffic flows between all these segments) and a detailed explanation of each individual segment.<\/p>\n<p>Since modern networks can have many logical layers, it might be a good (but not mandatory) approach to create different diagrams for different layers. For example, in the case of an overlay approach, these could be the following diagrams:<\/p>\n<ul>\n<li>overlay<\/li>\n<li>L1\/L2 underlay<\/li>\n<li>L3 underlay<\/li>\n<\/ul>\n<p>\nOf course, the most important diagram, without which it's impossible to understand the idea of your design, is the routing diagram.<\/p>\n<h4>Routing diagram<\/h4>\n<p>\nAt a minimum, this diagram should reflect<\/p>\n<ul>\n<li>which routing protocols are used and where<\/li>\n<li>basic information on routing protocol configuration (area\/AS number\/router-id\/\u2026)<\/li>\n<li>on which devices redistribution occurs<\/li>\n<li>where route filtering and aggregation take place<\/li>\n<li>information about the default route <\/li>\n<\/ul>\n<p>\nAdditionally, an L2 diagram (OSI) is often useful.<\/p>\n<h4>L2 diagram (OSI)<\/h4>\n<p>\nThis diagram can reflect the following information:<\/p>\n<ul>\n<li>which VLANs<\/li>\n<li>which ports are trunk ports<\/li>\n<li>which ports are aggregated in ether-channel (port channel), virtual port channel<\/li>\n<li>which STP protocols are used and on which devices<\/li>\n<li>main STP settings: root\/root backup, STP cost, port priority<\/li>\n<li>additional STP settings: BPDU guard\/filter, root guard\u2026<\/li>\n<\/ul>\n<p><\/p>\n<h2>Common mistakes in design<\/h2>\n<p><\/p>\n<blockquote><p>An example of a poor approach to building a network.<\/p>\n<p>Let's take a simple example of building a basic office local area network.<\/p>\n<p>Based on my experience teaching telecom to students, I can say that virtually any student by the middle of the second semester possesses the required knowledge (within the course I taught) to configure a simple office LAN.<\/p>\n<p>What is so difficult about connecting switches to each other, configuring VLANs, SVI interfaces (in the case of L3 switches), and writing static routing?<\/p>\n<p>Everything will work.<\/p>\n<p>But there are still sidelined issues related to <\/p>\n<ul>\n<li>Mutual TLS, access control, etc.<\/li>\n<li>redundancy<\/li>\n<li>network scalability<\/li>\n<li>performance<\/li>\n<li>throughput<\/li>\n<li>Retrying requests, timeouts, canary approaches (traffic splitting\/redirection), etc.<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>\nSometimes I hear the assertion that an office LAN is something very simple, and I usually hear this from engineers (and managers) who deal with anything but networks, and they say this with such confidence that you wouldn't be surprised if the LAN is set up by people with insufficient practice and knowledge, making them with the kinds of mistakes I will describe below.<\/p><\/blockquote>\n<p><\/p>\n<h4>Typical level L1 (OSI) design errors<\/h4>\n<p><\/p>\n<ul>\n<li>If you are indeed responsible for structured cabling, one of the most unpleasant legacies you may inherit is careless and poorly thought-out cabling.<\/li>\n<\/ul>\n<p>\nAlso, I would attribute errors of L1 type to issues related to the resources of the equipment used, such as<\/p>\n<ul>\n<li>insufficient bandwidth<\/li>\n<li>insufficient TCAM on the equipment (or its ineffective use)<\/li>\n<li>insufficient performance (often applies to firewalls)<\/li>\n<\/ul>\n<p><\/p>\n<h4>Typical level L2 (OSI) design errors<\/h4>\n<p>\nOften, when there is a lack of good understanding of how STP works and what potential problems it poses, switches are connected chaotically, with default settings, without additional STP tuning. <\/p>\n<p>As a result, we often have the following<\/p>\n<ul>\n<li>a large STP network diameter, which can lead to broadcast storms <\/li>\n<li>STP root will be determined randomly (based on MAC address) and the traffic path will be suboptimal<\/li>\n<li>ports connected to hosts will not be configured as edge (portfast), which will lead to STP recalculating when end stations are turned on\/off<\/li>\n<li>the network will not be segmented at L1\/L2, resulting in issues with any switch (for example, power overload) causing STP topology recalculation and stopping traffic across all VLANs on all switches (including in critical segments for service continuity)<\/li>\n<\/ul>\n<p><\/p>\n<h4>Examples of L3 (OSI) design errors<\/h4>\n<p>\nSeveral characteristic mistakes made by novice networkers:<\/p>\n<ul>\n<li>frequent use (or reliance solely on) static routing<\/li>\n<li>the use of suboptimal routing protocols for this design<\/li>\n<li>suboptimal logical segmentation of the network<\/li>\n<li>suboptimal use of address space, preventing route aggregation<\/li>\n<li>absence of backup routes<\/li>\n<li>lack of redundancy for the default gateway<\/li>\n<li>asymmetric routing during route reconstructions (which can be critical in the case of NAT\/PAT, stateful firewalls)<\/li>\n<li>MTU issues<\/li>\n<li>during route reconstructions, traffic passes through other security zones or even different firewalls, leading to dropped traffic<\/li>\n<li>poor scalability of the topology<\/li>\n<\/ul>\n<p><\/p>\n<h2>Criteria for evaluating design quality<\/h2>\n<p>\nWhen we talk about optimality\/suboptimality, we must understand from which criteria we can evaluate it. From my perspective, the most significant (but not all) criteria (and their interpretations concerning routing protocols) are:<\/p>\n<ul>\n<li>scalability<br \/>\n For example, you decided to add another data center. How easily can you do that?<\/li>\n<li>manageability<br \/>\n How easy and safe are operational changes, such as announcing a new network or filtering routes<\/li>\n<li>availability<br \/>\n What percentage of the time does your system provide the required level of service<\/li>\n<li>security<br \/>\n How secure is the transmitted data<\/li>\n<li>price<\/li>\n<\/ul>\n<p><\/p>\n<h2>Changes<\/h2>\n<p>\nThe main principle at this stage can be expressed by the formula 'do no harm'.<br \/>\nTherefore, 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 prioritize all identified issues based on two parameters: <\/p>\n<ul>\n<li>how easily this problem can be fixed<\/li>\n<li>how great the risk it poses<\/li>\n<\/ul>\n<p>\nFirst, eliminate anything that currently degrades the level of service below acceptable, such as problems causing packet loss. Then address what is easier and safer to fix in decreasing order of risk severity (from design or configuration issues posing the greatest risks to lesser ones).<\/p>\n<p>Perfectionism at this stage can be harmful. Bring the design to a satisfactory state and synchronize the network configuration accordingly.<br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/434750\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb. \u0421\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0432\u0441\u0435\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0446\u0438\u043a\u043b\u0430 \u0438 \u0441\u0441\u044b\u043b\u043a\u0438 \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0437\u0434\u0435\u0441\u044c. \u041d\u0430\u0448\u0430 \u0446\u0435\u043b\u044c \u043d\u0430 \u0434\u0430\u043d\u043d\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u2014 \u043d\u0430\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u043f\u043e\u0440\u044f\u0434\u043a\u0430 \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u041d\u0430 \u0432\u044b\u0445\u043e\u0434\u0435 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0443 \u0432\u0430\u0441 \u0434\u043e\u043b\u0436\u0435\u043d \u0431\u044b\u0442\u044c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b\u0439 \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0442 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u043e\u0432 \u0438 \u0441\u0435\u0442\u044c, \u0441\u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0432 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0438 \u0441 \u043d\u0438\u043c\u0438. \u0421\u0435\u0439\u0447\u0430\u0441 \u043c\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23042,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31067","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0432\u0442\u043e\u0440\u0430\u044f. \u0427\u0438\u0441\u0442\u043a\u0430 \u0438 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:39:16+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:39:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47How to Take Control of Your Network Infrastructure. Chapter Two. Cleanup and Documentation | ProHoster","description":"This article is the second in the series \"How to Take Control of Your Network Infrastructure.\"","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0432\u0442\u043e\u0440\u0430\u044f. \u0427\u0438\u0441\u0442\u043a\u0430 \u0438 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:39:16+00:00","article:modified_time":"2019-10-31T18:39:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31067","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 04:22:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:24:13","updated":"2026-01-21 04:22:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/31067","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=31067"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/31067\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/23042"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=31067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=31067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=31067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}