По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, дорогой читатель! На этапе траблшутинга системные администраторы прибегают к просмотру и анализу лог – файлов Asterisk. В статье поговорим про причины отбоя вызова (hangupcause) в Asterisk, как их найти в лог – файле и что они означают.
Поиск Hangupcause
Подключаемся к нашему серверу IP – АТС по SSH. Открываем консоль и вводим следующую команду:
[root@asterisk ~]# grep -e '[CALLID].*HANGUPCAUSE' /var/log/asterisk/full
Здесь CALLID - это идентификатор вызова. Найти его очень просто. В лог – файле введите номер звонящего/вызываемого абонента и найдете примерно вот такую запись (в примере поиск осуществляется по номеру 89123456789):
[2017-02-08 18:58:03] VERBOSE[18823][C-00000009] pbx.c: Executing [recordcheck@sub-record-check:11] Goto("Local/89123456789@from-internal-00000007;2", "startrec") in new stack
Находим запись выше. Здесь, [C-00000009] - является идентификатором вызова.
После того, как Вы нашли hangupcause, его необходимо понять. Переходим к следующему шагу – интерпретация.
Все причины отбоя вызова в Asterisk
Ниже, в таблице, мы составили причины отбоя вызова и соответствующие для них коды SIP ответов с небольшим описанием:
Код отбоя (hangupcause)
Полученный SIP - ответ
Описание
1
410
Unallocated (unassigned) - неназначенный номер. Данная ошибка указывает, что вызываемый номер назначения не может быть вызван, по причине отсутствия маршрута до него. Как правило, данную ошибку возвращает провайдер телефонных услуг. Например, при звонка зарубеж, данная ошибка может возвращаться из-за отсутствия маршрута к номеру назначения.
2
500
No route to specified transit network - ошибка индицирует о том, что оборудование, сгенерировавшее данную ошибку получило запрос запрос на маршрутизацию вызова через неизвестную ей транзитную сеть. Вполне возможно, что данная сеть в целом не существует.
3
404
No route to destination - чисто "сетевая" ошибка. Обозначает отсутствие коннективити (маршрутизации) между сетями инициатора вызова и вызываемого абонента.
4
500
Send special information tone - вызываемый абонент не может быть вызван по причинам "долгосрочного характера", и звонящий должен получить специальный звуковой тон.
5
500
Misdialled trunk prefix - сигнализирует о том, что к вызываемому номеру был подставлен ошибочный телефонный префикс.
6
500
Channel unacceptable - проблемы на канале связи. Как правило это сетевая проблема.
7
500
Call awarded and being delivered in an established channel - индикация того, что пользователь получил входящий вызов и что пользователь уже имеет аналогичный вызов
8
500
Prefix 0 dialed but not allowed - префикс в начале номер "0" не разрешен
9
500
Prefix 1 dialed but not allowed - префикс в начале номер "1" не разрешен
10
—
Prefix 1 not dialed but required - префикс "1" подставлен в начало номера, но не является требованием
11
—
More digits received than allowed, call is proceeding - в вызываемом номере передано больше цифр, чем позволено на оборудовании передающим данный код отбоя
16
BYE
Normal call clearing - вызов был закончен естественным образом (кто - то из абонентов положил трубку)
17
486
User busy - индицирует, что вызываемый абонент не может принять вызов, так как находится в состоянии "Занят" (есть активный разговор)
18
480
No user responding - вызываемый абонент не ответил на сообщение о вызове (инициации) в течение определенного времени
19
480
T.301 expired: – User Alerted, No answer from user - аппарат вызываемого абонента звонил, но он не ответил на звонок
21
603
Call rejected - вызов отклонен
22
480
Number changed to number in diagnostic field - индицирует о том, что вызываемый номер более не существует. В сообщение так же может быть включен новый номер вызываемого абонента
23
—
Reverse charging rejected - вариант, когда за звонок платит принимающая вызов сторона. Данное сообщение обозначает отклонение такого вызова.
24
—
Call suspended - оборудование получило запрос на приостановку вызова
25
—
Call resumed - вызов возобновлен (продолжение 24 отбоя)
26
500
Non-selected user clearing - пользователю не был назначен входящий вызов
27
404
Destination out of order - данное сообщение индицирует о том, что телефонная сигнализация не может быть доставлена через выбранный NIC (сетевой интерфейс). В данном случае, проблема скорее всего кроется на L1 или на L2 уровне (физический или канальный)
28
484
Invalid number format or incomplete address - неправильный формат вызываемого номера или номер указан не полностью
29
501
EKTS facility rejected by network - проблема на уровне платы - устройство отклонено на уровне сети
30
500
Response to STATUS ENQUIRY - сообщение ответ на запрос о состоянии
31
404
Normal, unspecified - эта причина отбоя используется в случае, если другие причины (более конкретные) не были применены
33
—
Circuit out of order - построенный канал связи вышел из строя
34
503
No circuit/channel available - нет доступного для установления соединения канала связи
35
500
Destination unattainable - нет возможности доставить сообщение до получателя
36
500
Out of order - объект функционирует не корректно
37
500
Degraded service - уведомление о том, что сервис находится в некорректном состоянии
38
503
Network out of order - сетевое соединение функционирует не корректно (вероятная проблема на уровне L3)
39
500
Transit delay range cannot be achieved - требуемый диапазон задержки (время обработки, передачи) не может быть достигнут
40
500
Throughput range cannot be achieved - требуемый диапазон пропускной способности (передача сообщения) не может быть достигнута
41
503
Temporary failure - временная неработоспособность сервиса. "Временная" означает то, что пользователь может попробовать еще раз через некоторое время
42
503
Switching equipment congestion - в настоящее время, оборудование коммутации испытывает пиковые значения нагрузки и не может обработать запрос
43
500
Access information discarded - данная причина индицирует о том, что по запросу сеть (L3) не может доставить информацию о доступе к удаленному пользователю
44
503
Requested circuit channel not available - запрошенный канал связи недоступен
45
500
Preempted - данная причина указывает на то, что вызов был прерван
46
500
Precedence call blocked - означает, что вызываемый пользователь занят вызовов с более высоким приоритетом
47
503
Resource unavailable, unspecified - причина, отправляемая в том случае, если ни одна другая не была отправлена
49
500
Quality of service unavailable - использование QoS требование не доступно
50
500
Requested facility not subscribed - пользователь запросил услугу, которую он не может получить по причине отсутствия доступа к ней
51
—
Reverse charging not allowed - вариант, когда за звонок платит принимающая вызов сторона не разрешен для данного пользователя
52
—
Outgoing calls barred - исходящий вызов запрещен для абонента
53
500
Outgoing calls barred within CUG - данная причина означает, что несмотря то, что пользователь является членом закрытой группы юзеров (CUG - Closed User Groups) для совершения исходящего вызова, ему данная итерация запрещена
54
—
Incoming calls barred - входящий вызов запрещен для абонента
55
603
Incoming calls barred within CUG - данная причина означает, что несмотря то, что пользователь является членом закрытой группы юзеров (CUG - Closed User Groups) для приема входящего вызова, ему данная итерация запрещена
56
—
Call waiting not subscribed - пользователь не имеет права (не подписан) на услугу "Ожидание вызова"
57
501
Bearer capability not authorized - пользователь запросил расширение пропускной способности канала до оборудования, но не имеет права на подобные итерации
58
501
Bearer capability not presently available - пользователь запросил расширение пропускной способности канала до оборудования, но в данный момент данная функция не доступна
63
503
Service or option not available, unspecified - сообщение сообщает о недоступности услуги в том случае, если другие причины (более конкретные) не были отправлены пользователю
65
501
Bearer service not implemented - служба передачи (переноса) информации не реализована
66
500
Channel type not implemented - устройство, посылающее данную причину не поддерживает указанный типа канала связи
67
—
Transit network selection not implemented - не удалось совершить выбор транзитной сети
68
—
Message not implemented - данное сообщение не реализовано
69
500
Requested facility not implemented - эта причина указывает на то, что устройство, отсылающее эту причину не поддерживает запрашиваемые дополнительные услуги
70
500
Only restricted digital information bearer capability is available - данное сообщение указывает на то, что пользователь запросил неограниченный доступ к пропускной способности канала связи, но устройство поддерживает только с ограничениями
79
501
Service or option not implemented, unspecified - услуга или опция не реализована (когда другие причины не были отправлены)
81
500
Invalid call reference value - эта причина указывает на то, что устройство, отсылающее эту причину, получило сообщение с идентификатором вызова, который в настоящее время не используется на интерфейсе сети пользователя
82
500
Identified channel does not exist - эта причина указывает на то, что устройство, отсылающее эту причину, получило запрос на использование канала, который не активизирован на сетевом интерфейсе. Например, если пользователь использует в потоке Е1 (PRI) тайм – слоты с 1 по 12, а запросил использовать с 3 по 24 – будет сгенерирована данная причина
83
500
A suspended call exists, but this call identity does not - вызов существует, но отсутствуют идентификаторы для него
84
500
Call identity in use - оборудование получило запрос на приостановление вызова, содержащий идентификатор вызова, под которым вызов уже значится приостановленным
85
500
No call suspended - получен запрос на возобновление вызова с идентификатором звонка, который не числится в списке приостановленных
86
500
Call having the requested call identity has been cleared - получен запрос на возобновление вызова с идентификатором звонка, который был прерван в результате тайм - аута
87
603
Called user not member of CUG - вызываемый абонент не является членом закрытой группы юзеров (CUG - Closed User Groups)
88
404
Incompatible destination - система получила запрос на установление соединения с параметрами, которые не могут быть обслужены
89
—
Non-existent abbreviated address entry - не существующий адрес
90
500
Destination address missing, and direct call not subscribed - адрес назначения не указан, а опция директивного вызова недоступна для пользователя
91
500
Invalid transit network selection (national use) - получен индикатор транзитной сети, который имеет неверный формат (в рамках рекомендации Q.931)
92
—
Invalid facility parameter 93 Mandatory information element is missing - обязательный элемент информационного сообщения отсутствует
93
500
Message type non-existent or not implemented - получено устройством сообщение не может быть интерпретировано на оборудовании
95
404
Invalid message, unspecified - неправильное сообщение. Используется только тогда, когда другие (более конкретные сообщения) не были отправлены
96
500
Mandatory information element is missing - в полученном оборудованием сообщение отсутствует важное для его обработки поле
97
500
Message type non-existent or not implemented - тоже самое что и 93 код
98
500
Message not compatible with call state or message type non-existent or not implemented - сообщение не совместимо с текущим состоянием звонка или не может быть интерпретировано оборудованием
99
500
Information element nonexistent or not implemented - информационный элемент не существует или не может быть интерпретирован оборудованием
100
500
Invalid information element contents - элемент не может быть интерпретирован. Помимо этого, одно или более полей сообщения были закодировано алгоритмом, который не поддерживает оборудованием.
101
500
Message not compatible with call state - полученное сообщение не соответствует состоянию вызова
102
408
Recovery on timer expiry - процедура восстановления по причине тайм - аута параллельно с алгоритмами обработки ошибок
103
500
Parameter non-existent or not implemented – passed on - параметр не существует или не реализован на оборудовании
111
404
Protocol error, unspecified - ошибка, которая отправляется в случае, если более детальное сообщение не было отправлено
127
500
Internetworking, unspecified - на этапе установления соединения произошел сбой
Если вы на пути изучения Kubernetes, начните с лабораторной среды. Использование лабораторной среды позволит вам правильно развернуть и получить рабочую среду Kubernetes и это является одним из лучших способов проведения экспериментов и обучения.
В этой статье рассмотрим установку Minikube на Windows Hyper-V Server 2019, его конфигурацию и работу с приложениями и их развертываниями.
Что такое Minikube?
Minikube это простой и быстрый способ создать локальный кластер Kubernetes. Он работает на MacOs, Lunix и Windows системах. Также это отличный вариант для разработчиков и тех, кто еще плохо знаком или только начинает изучать Kubernetes.
Некоторые возможности и особенности решения Minikube:
Кроссплатформенность, т.е. поддерживает все основные ОС: Linux, macOS и Windows;
В зависимости от возможностей, можно развернуть в виртуальной машине, контейнере или на железо;
Поддержка Docker;
Наличие драйверов для VmWare, VirtualBox, Docker, KVM, Hyper-V и др.;
Поддержка последних версий Kubernetes;
Docker API для быстрого развертывания образов;
Использование дополнений (addons);
Minikube обладает интегрированной поддержкой Dashboard Kubernetes
Установка Minikube
Для работы в Minikube на Hyper-v нужно выполнить следующие действия:
Проверить соответствие минимальным требованиям
Предварительно настроить Hyper-v server
Выбрать диспетчер пакетов для установки Minikube
Установить Minikube
Запустить кластер Kubernetes
Подключиться к кластеру, посмотреть дашборд
1. Проверка соответствия минимальным требованиям:
Для развертывания и использования Minikube в соответствии с его документацией должны удовлетворяться следующие требования:
2 GB свободной оперативной памяти
2 или более CPU
От 20 GB или более свободного дискового пространства
Наличие интернет
Docker container или виртуальная машина, например, VirtualBox или Hyper-V
2. Настройка Hyper-v server
Какой-то специальной настройки Hyper-v не требует, должны выполняться стандартные требования для работы Hyper-v: 64-разрядный процессор с преобразованием адресов второго уровня (SLAT), достаточный объем оперативной памяти и быстрые диски. Поддержка виртуализации в BIOS/UEFI (у Intel - Intel VT, у AMD - AMD-V). Чтобы виртуальные системы имели доступ в интернет, нужно заранее создать внешний виртуальный коммутатор.
Вначале посмотрим доступные сетевые адаптеры:
Get-NetAdapter
Найденное имя адаптера добавим в команду ниже.
Создать новый внешний сетевой адаптер можно командой PowerShell
New-VMSwitch -name ExternalSwitch -NetAdapterName "Ethernet 2" -AllowManagementOS $true
В противном случае при первом запуске Minikube покажет ошибку:
! StartHost failed, but will try again: creating host: create: precreate: no External vswitch nor Default Switch found. A valid vswitch must be available for this command to run.
Попросит выполнить minikube delete и отправит читать документацию: https://docs.docker.com/machine/drivers/hyper-v/
3. Диспетчер пакетов
В этой статье используется Windows Server 2019, и мы будем использовать Chocolatey, так как другой диспетчер пакетов - Windows Package Manager поддерживает только Windows 10.
Из PowerShell выполним команды:
iwr https://chocolatey.org/install.ps1 -outfile C:install.ps1
c:install.ps1
4. Инсталляция Minikube
После установки Chocolatey нужно выполнить команду:
choco install minikube
5. Запуск
Если после выполнения команды minikube start он не запускается, значит нужно установить соответствующие драйвера и провайдер
Для запуска с привилегированными правами, выполним:
runas /noprofile /user:администратор powershell
В нашем случае для Hyper-V выполняем:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Проверим установку компонентов:
Get-WindowsFeature –Name –hyper-v
Выяснилось, что актуальная версия Minikube не работает c Hyper-v, понизим версию командой
choco install minikube --version 1.6.2 --allow-downgrade
затем удалим minikube delete и снова запустим
minikube start
6. Подключение
Проверить, что VM запущена, поможет команда PowerShell
Get-vm
Просмотреть, что окружение запущено можно командой kubectl get po –A
Подготовим хостовую систему для работы браузеров, установив дополнительные компоненты:
Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0
И перезагрузим сервер, затем выполним команду minikube dashboard
На сервер предварительно скопирован браузер Firefox, в нем откроем ссылку и убедимся в работоспособности.
Виртуальные сети - это, в простейшем виде, создание логических топологий, построенных на основе физической топологии. Эти логические топологии часто называют виртуальными топологиями - отсюда и концепция виртуализации сети. Эти топологии могут состоять из одного виртуального канала в более крупной сети, называемого туннелем, или набора виртуальных каналов, которые кажутся полной сетью поверх физической сети, называемой наложением.
Этот раздел лекций начнется с обсуждения того, почему создаются и используются виртуальные топологии, проиллюстрированные двумя примерами использования. Во втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. Далее будут рассмотрены два примера технологий виртуализации: сегментная маршрутизация (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 из внутреннего заголовка во внешний заголовок, либо путем использования какой-либо формы проектирования трафика для передачи трафика по наилучшему доступному пути.