По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Создание разделов диска позволяет разделить жесткий диск на несколько разделов, которые действуют независимо. В Linux пользователи должны структурировать устройства хранения (USB и жесткие диски) перед их использованием. Разбиение на разделы также полезно, когда вы устанавливаете несколько операционных систем на одном компьютере. В этом пошаговом руководстве вы узнаете, как создать раздел с помощью команды Linux parted или fdisk. Вариант 1: разбить диск на разделы с помощью команды parted Выполните следующие действия, чтобы разбить диск в Linux с помощью команды parted. Шаг 1. Список разделов Перед созданием раздела составьте список доступных запоминающих устройств и разделов. Это действие помогает определить устройство хранения, которое вы хотите разбить на разделы. Выполните следующую команду с sudo, чтобы вывести список устройств хранения и разделов: sudo parted -l Терминал распечатывает доступные устройства хранения с информацией о: Model - Модель запоминающего устройства. Disk - Имя и размер диска. Sector size - логический и физический размер памяти. Не путать с доступным дисковым пространством. Partition Table - тип таблицы разделов (msdos, gpt, aix, amiga, bsd, dvh, mac, pc98, sun и loop). Disk Flags - разделы с информацией о размере, типе, файловой системе и флагах. Типы разделов могут быть: Primary (Основной) - содержит файлы операционной системы. Можно создать только четыре основных раздела. Extended (Расширенный) - особый тип раздела, в котором можно создать более четырех основных разделов. Logical (Логический) - Раздел, созданный внутри расширенного раздела. В нашем примере есть два устройства хранения - /dev/sda и /dev/sdb Примечание. Первый диск хранения (dev/sda или dev/vda) содержит операционную систему. Создание раздела на этом диске может сделать вашу систему не загружаемой. Создавайте разделы только на дополнительных дисках (dev/sdb, dev/sdc, dev/vdb или dev/vdc). Шаг 2: Откройте диск для хранения Откройте диск хранения, который вы собираетесь разделить, выполнив следующую команду: sudo parted /dev/sdb Всегда указывайте запоминающее устройство. Если вы не укажете имя диска, он будет выбран случайным образом. Чтобы сменить диск на dev/sdb, выполните: select /dev/sdb Шаг 3: Создайте таблицу разделов Прежде чем разбивать диск, создайте таблицу разделов. Таблица разделов расположена в начале жесткого диска и хранит данные о размере и расположении каждого раздела. Типы таблиц разделов: aix, amiga, bsd, dvh, gpt, mac, ms-dos, pc98, sun и loop. Чтобы создать таблицу разделов, введите следующее: mklabel [partition_table_type] Например, чтобы создать таблицу разделов gpt, выполните следующую команду: mklabel gpt Введите Yes, чтобы выполнить: Примечание. Два наиболее часто используемых типа таблиц разделов - это gpt и msdos. msdos поддерживает до шестнадцати разделов и форматирует до 16 ТБ, а gpt форматирует до 9,4 ЗБ и поддерживает до 128 разделов. Шаг 4: проверьте таблицу Запустите команду print, чтобы просмотреть таблицу разделов. На выходе отображается информация об устройстве хранения: Примечание. Запустите команду help mkpart, чтобы получить дополнительную справку о том, как создать новый раздел. Шаг 5: Создайте раздел Давайте создадим новый раздел размером 1854 Мбайт, используя файловую систему ext4. Назначенное начало диска должно быть 1 МБ, а конец диска - 1855 МБ. Чтобы создать новый раздел, введите следующее: mkpart primary ext4 1MB 1855MB После этого запустите команду print, чтобы просмотреть информацию о вновь созданном разделе. Информация отображается в разделе Disk Flags: В таблице разделов gpt, тип раздела - это обязательное имя раздела. В нашем примере primary - это имя раздела, а не тип раздела. Чтобы сохранить свои действия и выйти, введите команду quit. Изменения сохраняются автоматически с помощью этой команды. Примечание. Сообщение «You may need to update /etc/fstab file» сигнализирует о том, что раздел может быть смонтирован автоматически во время загрузки. Вариант 2: разбить диск на разделы с помощью команды fdisk Выполните следующие действия, чтобы разбить диск в Linux с помощью команды fdisk. Шаг 1. Список существующих разделов Выполните следующую команду, чтобы вывести список всех существующих разделов: sudo fdisk -l Вывод содержит информацию о дисках и разделах хранилища: Шаг 2: Выберите диск для хранения Выберите диск для хранения, на котором вы хотите создать разделы, выполнив следующую команду: sudo fdisk /dev/sdb Диск /dev/sdbstorage открыт: Шаг 3: Создайте новый раздел Запустите команду n, чтобы создать новый раздел. Выберите номер раздела, набрав номер по умолчанию (2). После этого вас попросят указать начальный и конечный сектор вашего жесткого диска. Лучше всего ввести в этом разделе номер по умолчанию (3622912). Последний запрос связан с размером раздела. Вы можете выбрать несколько секторов или установить размер в мегабайтах или гигабайтах. Введите + 2 GB, чтобы установить размер раздела 2 ГБ. Появится сообщение, подтверждающее создание раздела. Шаг 4: запись на диск Система создала раздел, но изменения не записываются на диск. 1. Чтобы записать изменения на диск, выполните команду w: 2. Убедитесь, что раздел создан, выполнив следующую команду: sudo fdisk -l Как видите, раздел /dev/sdb2 создан. Отформатируйте раздел После создания раздела с помощью команды parted или fdisk отформатируйте его перед использованием. Отформатируйте раздел, выполнив следующую команду: sudo mkfs -t ext4 /dev/sdb1 Смонтировать раздел Чтобы начать взаимодействие с диском, создайте точку монтирования (mount point) и смонтируйте к ней раздел. 1. Создайте точку монтирования, выполнив следующую команду: sudo mkdir -p /mt/sdb1 2. После этого смонтируйте раздел, введя: sudo mount -t auto /dev/sbd1 /mt/sdb1 Терминал не распечатывает вывод, если команды выполнены успешно. 3. Убедитесь, что раздел смонтирован, с помощью команды df hT:
img
Hiya! Merion Metrics our call stats (CDR) application for Asterisk, it shows the most important diagrams and call graphs as well as call history in an easy and convenient format. Showing call stats this way makes them easy to understand for everyone - from CEO to an office manager About Merion Metrics Short description of Merion Metrics: Full statistics - the most important info only: date, time, source and destination of a call, as well as it’s recording; Free trial - try the whole spectrum of these features - completely for free; Easy and quick installation - we are always here to help you; Cross-platform - developed in Java. Compatible with any UNIX platform; For supervisors - Got tired of heavy and awkward CDR interface in FreePBX? Or maybe you experienced something similar with CDR Viewer? we know that feeling; Easy to export in PDF and CSV - export all your calls into PDF and send it over to your colleagues in an easy readable format; Try Merion Metrics for free: Try Merion Metrics Merion Metrics Installation Attention! You should to have a license key from our support team at this point. You can get it by follow link: https://asterisk.merionet.ru/merionmetrics Of course for your convenience we have a step by step video guide. Enjoy :) Installation video - guide Installation guide by plain text System Requirements RAM: 256 MB min CPU: Pentium 2 266 МГц + минимум Java Runtime Environment (JRE): version 8+ Browser: Internet Explorer 9+ Preparation Firstly, connect to your Asterisk via SSH using user root. Directory creation for the app Run the following commands: mkdir /home/merionstat Upload app distro MerionMonitoring-*.*.*.jar into the directory you’ve just created: /home/merionstat. You can do that using WinSCP, for example. Important: App distro will have a certain version number. Here, in the installation guide, we always put version number as MerionMonitoring-*.*.*.jar. In your case it will be something like MerionMonitoring-1.1.9.jar. SQL user creation Follow the link that will generate an uncrackable password and right it down on save it somewhere. After that, execute the following command sequence: mysql CREATE USER 'interface'@'localhost' IDENTIFIED BY 'your_password'; GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY 'your_password'; Where your_password - some freshly generated password from the link above пароль. For example: mysql CREATE USER 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz'; GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz'; And yet another reminder – save your password somewhere else. Call recordings directory For sake of playing call recordings through our app, you have to do the following: Generate another password via our password generator and save it;. Execute the following commands: mkdir /var/www/html/generated_password chown asterisk:asterisk /var/www/html/generated_password chmod 775 /var/www/html/generated_password For example: mkdir /var/www/html/5v9MpbtUA8 chown asterisk:asterisk /var/www/html/5v9MpbtUA8 chmod 775 /var/www/html/5v9MpbtUA8 Open file /etc/fstab and add there the following sequence: /var/spool/asterisk/monitor/ /var/www/html/generated_password/ none rbind 0 0 For example: /var/spool/asterisk/monitor/ /var/www/html/5v9MpbtUA8/ none rbind 0 0 Save all the changes in fstab file. After that, execute the following command in CLI: mount -a Start Application launch Run the following commands: cd /home/merionstat nohup java -jar MerionMonitoring-*.*.*.jar & Right after command’s execution press Enter. Application setup The first connection After launching .jar archive, please open the following address in your web-browser: http://your_IP_address:7070/#!/config (You can use any browser, we recommend using Google Chrome). Once it opened, enter your license key – you can get it from our support engineer. Click “Check the license”. If you encounter any kind of a problem during that phase, please address it to our technical support team: helpdesk@merionet.ru. After that you have to pass the initial authorization, and to do that, you need to use the following credentials: admin/IEJu1uh32 On the next step you’ll need to configure database connection. If you are using Asterisk IP - PBX, just follow the guide: Database - mysql or mariadb; DB host: If your DB installed on the same server as our application - localhost; If your DB installed on some kind of external server - IP_address_of_your_database; DB port - is being set up automatically, so please change it only if your DB is listening for requests on another port; DB connection string - leave this without changes; Table name - In case of Asterisk it’s cdr; Scheme - that should be the name of database, for Asterisk it’s asteriskcdrdb; User - You created the user some time ago in “SQL user creation” part of this guide. If you copied all the commands without any changes – that would be interface; Password - the one you’ve probably generated using our password generator; Voice recordings host - link like http://your_ip_address/generated_password/, where generated_password is a sequence you created on a previous stage Call recordings directory. So, it’s gonna be something like http://192.168.1.7/5v9MpbtUA8/; Station type - Asterisk; After you finish all the above, click “Connect”. If something went wrong, address the issue to our support team helpdesk@merionet.ru. On the next step, you have to match field name in the table with it’s actual meaning. In case of Asterisk you can leave everything as it is. At the bottom of this page click the button “Set the matches” and “Launch the Application”. Our app will redirect you to the application’s initial page. By default, administrator’s login and password are: admin/admin Known issues Application is already launched If you can’t open the app using the default link http://IP_ADDRESS:7070/#!/config, please check if it wasn’t launched before. To do so, please run the command below: ps aux | grep Merion Analyze the command output: root 4919 0.1 13.1 2120384 801784 ? Sl Dec11 19:12 java -jar MerionMonitoring-*.*.*.jar If you see something similar, you have to kill the process using it’s PID (marked with orange in output example above). So execute the following command: kill -9 4919 Check the output again: ps aux | grep Merion If the one you’ve seen before is gone, then you can try to lauch it again: cd /home/merionstat nohup java -jar MerionMonitoring-*.*.*.jar & Database on the external server If you are connecting to an external data base, you need to add some additional configuration for MySQL settings, that you’ve done in “SQL user creation”. You might need it if you install call stats app on a different server, not the one you have Asterisk installed on. In this case you need to run the following commands on the server where you have your DB (usually it’s your Asterisk server): mysql GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'IP_адрес_интерфейса' IDENTIFIED BY ''your_password'; Where: your_password - password generated with our our tool; Call_stats_app_IP_ADDRESS - IP-address of the server where you decided to install our Call Stats Application. For example: mysql GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'192.168.1.78' IDENTIFIED BY '6nzB0sOWzz'; Also, please check that the following ports are open: 3306 - for MySQL and MariaDB; 5432 - for PostgreSQL. Slow data loading If you are experiencing some issues with data download – it might be related to the big size of your database. We recommend to launch our app (.jar file) with some additional keys. According to the “Application launch”, run the following command: cd /home/merionstat nohup java -jar MerionMonitoring-*.*.*.jar -Xms128m -Xmx256m & Where: -Xms128m - minimal amount of RAM available for the app. In our example – it’s 128 Megabytes. -Xmx256m - maximum amount of RAM available for the app. In our example – it’s 256 Megabytes; How to send a request to our support team? If you are experiencing any technical issues with configuration of our app – we will definitely help you. We’ll need the files from /home/merionstat directory – the one where you’ve put our distro MerionMonitoring-*.*.*.jar, according to step “Directory creation for the app”. Depending on the phase where you’ve encountered any technical issues, you might have the following files there: columns_mapping.cfg configuration.properties nohup.out Please send us those files and description of your issue – we’ll try to help you. Telegram - @merion_support_bot Email - helpdesk@merionet.ru
img
Виртуальные сети - это, в простейшем виде, создание логических топологий, построенных на основе физической топологии. Эти логические топологии часто называют виртуальными топологиями - отсюда и концепция виртуализации сети. Эти топологии могут состоять из одного виртуального канала в более крупной сети, называемого туннелем, или набора виртуальных каналов, которые кажутся полной сетью поверх физической сети, называемой наложением. Этот раздел лекций начнется с обсуждения того, почему создаются и используются виртуальные топологии, проиллюстрированные двумя примерами использования. Во втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. Далее будут рассмотрены два примера технологий виртуализации: сегментная маршрутизация (segment routing-SR) и программно - определяемые глобальные сети (Software-Defined Wide Area Networks- SD-WAN). Понимание виртуальных сетей Виртуализация усложняет проектирование протоколов, сетей и устранение неполадок, так зачем же виртуализировать? Причины, как правило, сводятся к разделению нескольких потоков трафика в одной физической сети. Это может показаться подозрительно похожим на другую форму мультиплексирования, потому что это еще одна форма мультиплексирования. Основные различия между рассмотренными до сих пор формами мультиплексирования и виртуализацией заключаются в следующем: Позволяет нескольким плоскостям управления работать с различными наборами информации о достижимости в рамках одной физической топологии; Позволяет нескольким наборам достижимых пунктов назначения работать в одной физической топологии без взаимодействия друг с другом; Рассмотренные до этого момента методы мультиплексирования были сосредоточены на том, чтобы позволить нескольким устройствам использовать одну физическую сеть (или набор проводов), позволяя каждому устройству взаимодействовать с любым другим устройством (при условии, что они знают друг о друге с точки зрения достижимости). Виртуализация направлена на разбиение одной физической сети на несколько доменов достижимости, где каждое устройство в домене достижимости может взаимодействовать с любым другим устройством в том же домене достижимости, но устройства не могут связываться между доменами достижимости (если нет какой-либо точки соединения между достижимостью домены). На рисунке 1 показана сеть с виртуальной топологией, расположенной поверх физической топологии. На рисунке 1 виртуальная топология была создана поверх физической сети, с виртуальным каналом [C,H], созданным для передачи трафика по сети. Чтобы создать виртуальную топологию, C и H должны иметь некоторую локальную информацию пересылки, отделяющую физическую топологию от виртуальной топологии, которая обычно проходит либо через E, либо через D. Это обычно принимает форму либо специального набора записей виртуального интерфейса в локальной таблице маршрутизации, либо таблицы виртуальной маршрутизации и пересылки (VRF), содержащей только информацию о виртуальной топологии. Рассмотрение потока пакетов через виртуальную топологию может быть полезно для понимания этих концепций. Как бы выглядел поток пакетов, если бы C и H имели виртуальные интерфейсы? Рисунок 2 демонстрирует это. На рисунке 2 процесс пересылки выполняется следующим образом: A передает пакет к M. C получает этот пакет и, исследуя свою локальную таблицу маршрутизации, находит, что кратчайший путь к месту назначения лежит через виртуальный интерфейс к H. Этот виртуальный интерфейс обычно называется туннельным интерфейсом; он выглядит с точки зрения таблицы маршрутизации, как и любой другой интерфейс маршрутизатора. Виртуальный интерфейс, через который необходимо передать пакет, имеет инструкции перезаписи, которые включают добавление нового заголовка, заголовка туннеля или внешнего заголовка в пакет и пересылку полученного пакета. Исходный заголовок пакета теперь называется внутренним заголовком. C добавляет внешний заголовок и обрабатывает новый пакет для пересылки. Теперь C исследует новый пункт назначения, которым является H (помните, что исходным пунктом назначения был M). H не подключен напрямую, поэтому C необходимо выяснить, как достичь H. Это называется рекурсивным поиском, поскольку C ищет путь к промежуточному месту назначения, чтобы доставить пакет к конечному месту назначения, но не к нему. Теперь C поместит правильную информацию в пакет в заголовок link local, чтобы перенаправить трафик на E. Когда E получает этот пакет, он удаляет внешнюю информацию о переадресации, Заголовок link local и пересылает трафик на основе первого заголовка C, помещенного в пакет, во время первоначального поиска. Этот внешний заголовок говорит E переслать пакет в H; E не видит и не включает исходный внутренний заголовок, помещенный на пакет A. E добавит новый Заголовок link local, чтобы пакет был правильно переадресован в H, и передаст пакет по правильному интерфейсу. Когда H получает пакет, он удаляет Заголовок link local и обнаруживает внешний заголовок. Внешний заголовок говорит, что пакет предназначен для самого H, поэтому он очистит этот заголовок и обнаружит исходный заголовок пакета или внутренний заголовок. Теперь H посмотрит в своей локальной таблице маршрутизации и обнаружит, что M локально подключен. H поместит правильный Заголовок link local в пакет и передаст его через правильный интерфейс, чтобы пакет достиг M. Если C и H используют VRF, а не туннельные интерфейсы, процесс в предыдущем списке изменяется на шагах 2 и 8. На шаге 2 C будет искать M как пункт назначения в VRF, связанном каналом [A, C]. Когда C обнаруживает, что трафик к M должен пересылаться через виртуальную топологию через H, он помещает внешний заголовок в пакет и снова обрабатывает пакет на основе этого внешнего заголовка через базовый VRF или, скорее, таблицу маршрутизации, представляющую физическую топологию. Когда H получает пакет, он удаляет внешний заголовок и снова обрабатывает пакет, используя VRF, к которому подключен M, для поиска информации, необходимой для пересылки трафика в его конечный пункт назначения. В этом случае интерфейс туннеля заменяется отдельной таблицей пересылки; вместо того, чтобы обрабатывать пакет через одну и ту же таблицу дважды с использованием двух разных адресатов, пакет обрабатывается через две разные таблицы пересылки. Термин туннель имеет много различных определений; в этих статьях туннель будет использоваться для описания виртуального канала, где внешний заголовок используется для инкапсуляции внутреннего заголовка, и: Внутренний заголовок находится на том же уровне или более низком уровне, чем внешний заголовок (например, заголовок Ethernet, переносимый внутри заголовка IPv6; обычно IPv6 переносится внутри Ethernet). По крайней мере, некоторые сетевые устройства на пути, будь то виртуальные или физические, пересылают пакет только на основе внешнего заголовка. Переход от виртуальных интерфейсов к VRFs концептуально отличается достаточно, чтобы породить различные описательные термины. Underlay -это физическая (или потенциально логическая!) топология, через которую туннелируется трафик. Overlay - это набор туннелей, составляющих виртуальную топологию. В большинстве случаев термины Underlay и Overlay не используются с отдельными туннелями или в случае службы, работающей через общедоступный Интернет. Сервис, который создает виртуальную топологию через общедоступный Интернет, часто называют сервисом over-the-top. Опять же, эти термины используются в некоторой степени взаимозаменяемо и даже очень небрежно в более широком мире сетевой инженерии. На этом фоне пора перейти к вариантам использования, чтобы узнать о наборе проблем, которые необходимо решить виртуализацией. Предоставление услуг Ethernet по IP-сети. Хотя приложения не должны создаваться с использованием подключения Ethernet в качестве базового, многие из них это делают. Например: Некоторые поставщики систем хранения данных и баз данных строят свои устройства с предположением, что подключение Ethernet означает короткое расстояние и короткую задержку, или они проектируют системы поверх проприетарных транспортных протоколов непосредственно поверх кадров Ethernet, а не поверх пакетов интернет-протокола (IP). Некоторые продукты виртуализации включают в свои продукты предположения о возможности подключения, такие как надежность кеширования Ethernet для IP-адресов для шлюза по умолчанию и других доступных мест назначения. Для таких приложений требуется то, что выглядит как соединение Ethernet между устройствами (физическими или виртуальными), на которых работают различные узлы или копии приложения. Помимо этого, некоторые сетевые операторы считают, что запуск большого плоского домена Ethernet проще, чем запуск крупномасштабного IP-домена, поэтому они предпочли бы создавать самые большие домены Ethernet, которые они могут ("коммутация, где можно, маршрутизация, где необходимо", была распространенная поговорка в те времена, когда коммутация выполнялось аппаратно, а маршрутизация выполнялась программно, поэтому коммутация пакетов выполнялась намного быстрее, чем их маршрутизация). Некоторые кампусы также построены с основной идеей - никогда не просить устройство коммутировать свой IP-адрес после подключения. Поскольку пользователи могут быть подключены к разным сегментам Ethernet в зависимости от их домена безопасности, каждый сегмент Ethernet должен быть доступен в каждой точке беспроводного доступа и часто на каждом порте Ethernet в кампусе. Учитывая сеть, основанную на IP, которая предполагает Ethernet как один из многих транспортных средств, поверх которых будет работать IP, как вы можете обеспечить подключение Ethernet к устройствам, связанным по IP-сети? На рисунке 3 показаны задачи, которые необходимо решить. На рисунке 3 процесс, работающий на A с IP-адресом 2001:db8:3e8:100::1, должен иметь возможность взаимодействовать со службой, работающей на B с IP-адресом 2001:db8:3e8:100::2, как если бы они находились в одном сегменте Ethernet (две службы должны видеть друг друга в обнаружении соседей и т. д.). Чтобы сделать проблему более сложной, служба на A также должна иметь возможность перемещаться в K без изменения своего локального кэша обнаружения соседей или маршрутизатора по умолчанию. Сама сеть, является маршрутизируемой сетью, работающей под управлением IPv6. Что необходимо для выполнения требований? Должен быть способ передачи кадров Ethernet по IP-сети, разделяющей серверы. Обычно это будет своего рода туннельная инкапсуляция, как описано в начале этого раздела. Туннелирование позволило бы принимать кадры Ethernet на C, например, инкапсулированные в какой-то внешний заголовок, чтобы их можно было транспортировать по маршрутизируемой сети. Когда пакет, содержащий кадр Ethernet, достигает D, этот внешний заголовок может быть удален, и кадр Ethernet пересылается локально. С точки зрения D, фрейм имеет локальное происхождение. Должен быть способ узнать о пунктах назначения, доступных через туннель, и привлечь трафик в туннель. На самом деле это две отдельные, но взаимосвязанные проблемы. Привлечение трафика в туннель может включать запуск второй плоскости управления с ее собственными VRFs или добавление дополнительной информации в существующую плоскость управления об адресах Ethernet Media Access Control (MAC), доступных на каждом пограничном маршрутизаторе. Может потребоваться перенести маркировку качества обслуживания (QoS) из внутреннего заголовка во внешний заголовок, чтобы трафик обрабатывался правильно при его пересылке. Виртуальный частный доступ к корпоративной сети. Почти в каждой организации есть какие-то удаленные сотрудники, либо на полную ставку, либо просто люди, которые перемещаются, и у большинства организаций есть какие-то удаленные офисы, где часть сотрудников работает вдали от главного офиса, чтобы напрямую взаимодействовать с местным организациями в некоторых отраслях, например, с покупателями или поставщиками. Все эти люди по-прежнему нуждаются в доступе к сетевым ресурсам, таким как электронная почта, системы путешествий, файлы и т. д. Эти службы, конечно, не могут быть доступны в общедоступном Интернете, поэтому необходимо предоставить какой-то другой механизм доступа. На рисунке 4 показаны типичное проблемное пространство. В этом варианте использования есть две основные проблемы: Как можно защитить трафик между отдельным хостом - B - и тремя хостами в небольшом офисе - C, D и E - от перехвата и чтения злоумышленником? Как можно защитить сами адреса назначения от попадания в публичную сеть? Эти проблемы связаны с некоторой защитой, которая, в свою очередь, подразумевает некоторую форму инкапсуляции пакетов. Как можно управлять качеством работы пользователей в этих удаленных местах для поддержки передачи голоса по IP и других приложений в реальном времени? Поскольку провайдеры в Интернете не поддерживают QoS, необходимо обеспечить другие формы гарантии качества. Таким образом, задача, которую необходимо решить, включает еще две общие проблемы. Должен быть способ инкапсулировать трафик, передаваемый по общедоступной сети, без раскрытия исходной информации заголовка и без подвергания информации, содержащейся в пакете, для проверки. Самым простым решением этих проблем является туннелирование (часто в зашифрованном туннеле) трафика от A и F к граничному маршрутизатору в сети организации G, где инкапсуляция может быть удалена, а пакеты перенаправлены на A. Должен быть способ объявить достижимые пункты назначения от G к удаленным пользователям, а также существование (или достижимость) удаленных пользователей к G и сети позади G. Эта информация о достижимости должна использоваться для привлечения трафика в туннели. В этом случае плоскости управления может потребоваться перенаправить трафик между различными точками входа и выхода в общедоступную сеть и попытаться контролировать путь трафика через сеть, чтобы обеспечить удаленным пользователям хорошее качество работы. Подведем итоги Два варианта использования, показанные выше, актуализируют два вопроса, которые должно решить каждое решение сетевой виртуализации: Как трафик инкапсулируется в туннель, чтобы можно было отделить пакеты и информацию плоскости управления от базовой сети? Решением этой проблемы обычно является некоторая форма инкапсуляции, в которую помещается исходный пакет, когда он передается по сети. Основное внимание при инкапсуляции - поддержка аппаратной коммутации в базовой сети, чтобы обеспечить эффективную пересылку инкапсулированных пакетов. Второстепенным соображением является размер формата инкапсулирующего пакета; каждый октет дополнительного заголовка инкапсуляции уменьшает объем полезной нагрузки, которую туннель может нести (если нет разницы между максимальной единицей передачи или MTU в сети, предназначенной для учета дополнительной информации заголовка, налагаемой туннелированием). Примечание Path MTU Detection (PMTUD) часто плохо определяет MTU инкапсулированных пакетов. Из-за этого часто требуется ручная настройка MTU в точке наложения заголовка туннеля. Как пункты назначения достигаются через туннель, объявленный через сеть? В более общих туннельных решениях туннель становится "просто еще одним звеном" в общей топологии сети. Пункты назначения, доступные через туннель, и дополнительная виртуальная связь просто включены как часть плоскости управления, как и любые другие пункты назначения и каналы. В этих решениях существует одна таблица маршрутизации или пересылки в каждом устройстве, и рекурсивный поиск используется для обработки пакета посредством пересылки в точке, где трафик входит в туннель или головной узел туннеля. Трафик привлекается в туннель путем изменения метрик таким образом, чтобы туннель был более желательным путем через сеть для тех пунктов назначения, которые оператор сети хотел бы получить через туннель. Это обычно означает в основном ручные решения проблемы привлечения трафика в туннель, такие как установка метрики туннеля ниже пути, по которому проходит туннель, а затем фильтрация пунктов назначения, объявленных через туннель, чтобы предотвратить объявления пунктов назначения, которые должны быть недоступны через туннель. На самом деле, если пункты назначения, достижимые через туннель, включают конечную точку туннеля (хвост туннеля), может образоваться постоянная петля маршрутизации, или туннель будет циклически переключаться между правильной переадресацией трафика и не переадресацией трафика вообще. В решениях с overlay и over-the-top развертывается отдельная плоскость управления (или передается отдельная база данных с информацией о доступности для адресатов, достижимых в underlay и overlay в единой плоскости управления). Пункты назначения, доступные через underlay и overlay, помещаются в отдельные таблицы маршрутизации (VRF) на головной станции туннеля, а таблица, используемая для пересылки трафика, основана на некоторой форме системы классификации. Например, все пакеты, полученные на конкретном интерфейсе, могут быть автоматически помещены в оверлейный туннель, или все пакеты с определенным классом обслуживания, установленным в их заголовках пакетов, или весь трафик, предназначенный для определенного набора пунктов назначения. Механизмы полного наложения и верхней виртуализации обычно не полагаются на метрики для привлечения трафика в туннель на головной станции. Еще одно необязательное требование - обеспечить качество обслуживания либо путем копирования информации QoS из внутреннего заголовка во внешний заголовок, либо путем использования какой-либо формы проектирования трафика для передачи трафика по наилучшему доступному пути.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59