По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Эта статья подробно объясняет функции и терминологию протокола RIP (административное расстояние, метрики маршрутизации, обновления, пассивный интерфейс и т.д.) с примерами.
RIP - это протокол маршрутизации вектора расстояния. Он делится информацией о маршруте через локальную трансляцию каждые 30 секунд.
Маршрутизаторы хранят в таблице маршрутизации только одну информацию о маршруте для одного пункта назначения. Маршрутизаторы используют значение AD и метрику для выбора маршрута.
Первая часть статьи про базовые принципы работы протокола RIP доступна по ссылке.
Административная дистанция
В сложной сети может быть одновременно запущено несколько протоколов маршрутизации. Различные протоколы маршрутизации используют различные метрики для расчета наилучшего пути для назначения. В этом случае маршрутизатор может получать различную информацию о маршрутах для одной целевой сети. Маршрутизаторы используют значение AD для выбора наилучшего пути среди этих маршрутов. Более низкое значение объявления имеет большую надежность.
Административная дистанция
Протокол/Источник
0
Непосредственно подключенный интерфейс
0 или 1
Статическая маршрутизация
90
EIGRP
110
OSPF
120
RIP
255
Неизвестный источник
Давайте разберемся в этом на простом примере: А маршрутизатор изучает два разных пути для сети 20.0.0.0/8 из RIP и OSPF. Какой из них он должен выбрать?
Ответ на этот вопрос скрыт в приведенной выше таблице. Проверьте объявленную ценность обоих протоколов. Административное расстояние - это правдоподобие протоколов маршрутизации. Маршрутизаторы измеряют каждый источник маршрута в масштабе от 0 до 255. 0 - это лучший маршрут, а 255-худший маршрут. Маршрутизатор никогда не будет использовать маршрут, изученный этим (255) источником. В нашем вопросе у нас есть два протокола RIP и OSPF, и OSPF имеет меньшее значение AD, чем RIP. Таким образом, его маршрут будет выбран для таблицы маршрутизации.
Метрики маршрутизации
У нас может быть несколько линий связи до целевой сети. В этой ситуации маршрутизатор может изучить несколько маршрутов, формирующих один и тот же протокол маршрутизации. Например, в следующей сети у нас есть два маршрута между ПК-1 и ПК-2.
Маршрут 1:
ПК-1 [10.0.0.0/8] == Маршрутизатор OFF1 [S0/1 - 192.168.1.254] = = Маршрутизатор OFF3 [S0/1-192.168.1.253] = = ПК-2 [20.0.0.0/8]
Маршрут 2:
ПК-1 [10.0.0.0/8] == Маршрутизатор OFF1 [S0/0 - 192.168.1.249] == Маршрутизатор OFF2 [S0/0 - 192.168.1.250] == Маршрутизатор OFF2 [S0/1 - 192.168.1.246] == Маршрутизатор OFF3 [S0/0 - 192.168.1.245] == ПК-2 [20.0.0.0/8]
В этой ситуации маршрутизатор использует метрику для выбора наилучшего пути. Метрика - это измерение, которое используется для выбора наилучшего пути из нескольких путей, изученных протоколом маршрутизации. RIP использует счетчик прыжков в качестве метрики для определения наилучшего пути. Прыжки - это количество устройств уровня 3, которые пакет пересек до достижения пункта назначения.
RIP (Routing Information Protocol) - это протокол маршрутизации вектора расстояния. Он использует расстояние [накопленное значение метрики] и направление [вектор], чтобы найти и выбрать лучший путь для целевой сети. Мы объяснили этот процесс с помощью примера в нашей первой части этой статьи.
Хорошо, теперь поймите концепцию метрики; скажите мне, какой маршрут будет использовать OFF1, чтобы достичь сети 20.0.0.0/8? Если он выбирает маршрут S0/1 [192.168.1.245/30], он должен пересечь устройство 3 уровня. Если он выбирает маршрут S0/0 [19.168.1.254/30], то ему придется пересечь два устройства уровня 3 [маршрутизатор OFF! и последний маршрутизатор OFF3], чтобы достичь целевой сети.
Таким образом, он будет использовать первый маршрут, чтобы достигнуть сети 20.0.0.0/8.
Маршрутизация по слухам
Иногда RIP также известен как маршрутизация по протоколу слухов. Потому что он изучает информацию о маршрутизации от непосредственно подключенных соседей и предполагает, что эти соседи могли изучить информацию у своих соседей.
Обновления объявлений
RIP периодически транслирует информацию о маршрутизации со всех своих портов. Он использует локальную трансляцию с IP-адресом назначения 255.255.255.255. Во время вещания ему все равно, кто слушает эти передачи или нет. Он не использует никакого механизма для проверки слушателя. RIP предполагает, что, если какой-либо сосед пропустил какое-либо обновление, он узнает об этом из следующего обновления или от любого другого соседа.
Пассивный интерфейс
По умолчанию RIP транслирует со всех интерфейсов. RIP позволяет нам контролировать это поведение. Мы можем настроить, какой интерфейс должен отправлять широковещательную передачу RIP, а какой нет. Как только мы пометим любой интерфейс как пассивный, RIP перестанет отправлять обновления из этого интерфейса.
Расщепление горизонта
Split horizon-это механизм, который утверждает, что, если маршрутизатор получает обновление для маршрута на любом интерфейсе, он не будет передавать ту же информацию о маршруте обратно маршрутизатору-отправителю на том же порту. Разделенный горизонт используется для того, чтобы избежать циклов маршрутизации.
Чтобы понять эту функцию более четко, давайте рассмотрим пример. Следующая сеть использует протокол RIP. OFF1-это объявление сети 10.0.0.0/8. OFF2 получает эту информацию по порту S0/0.
Как только OFF2 узнает о сети 10.0.0.0/8, он включит ее в свое следующее обновление маршрутизации. Без разделения горизонта он будет объявлять эту информацию о маршруте обратно в OFF1 на порту S0/0.
Ну а OFF1 не будет помещать этот маршрут в таблицу маршрутизации, потому что он имеет более высокое значение расстояния. Но в то же время он не будет игнорировать это обновление. Он будет предполагать, что OFF1 знает отдельный маршрут для достижения сети 10.0.0.0/8, но этот маршрут имеет более высокое значение расстояния, чем маршрут, который я знаю. Поэтому я не буду использовать этот маршрут для достижения 10.0.0.0/8, пока мой маршрут работает. Но я могу воспользоваться этим маршрутом, если мой маршрут будет недоступен. Так что это может сработать как запасной маршрут для меня.
Это предположение создает серьезную сетевую проблему. Например, что произойдет, если интерфейс F0/1 OFF1 выйдет из строя? OFF1 имеет прямое соединение с 10.0.0.0/8, поэтому он сразу же узнает об этом изменении.
В этой ситуации, если OFF1 получает пакет для 10.0.0.0/8, вместо того чтобы отбросить этот пакет, он переадресует его из S0/0 в OFF2. Потому что OFF1 думает, что у OFF2 есть альтернативный маршрут для достижения 10.0.0.0/8.
OFF2 вернет этот пакет обратно в OFF1. Потому что OFF2 думает, что у OFF1 есть маршрут для достижения 10.0.0.0/8.
Это создаст сетевой цикл, в котором фактический маршрут будет отключен, но OFF1 думает, что у OFF2 есть маршрут для назначения, в то время как OFF2 думает, что у OFF1 есть способ добраться до места назначения. Таким образом, этот пакет будет бесконечно блуждать между OFF1 и OFF2. Чтобы предотвратить эту проблему, RIP использует механизм подсчета прыжков (маршрутизаторов).
Количество прыжков
RIP подсчитывает каждый переход (маршрутизатор), который пакет пересек, чтобы добраться до места назначения. Он ограничивает количество прыжков до 15. RIP использует TTL пакета для отслеживания количества переходов. Для каждого прыжка RIP уменьшает значение TTL на 1. Если это значение достигает 0, то пакет будет отброшен.
Это решение только предотвращает попадание пакета в петлю. Это не решает проблему цикла маршрутизации.
Split horizon решает эту проблему. Если расщепление горизонта включено, маршрутизатор никогда не будет вещать тот же маршрут обратно к отправителю. В нашей сети OFF2 узнал информацию о сети 10.0.0.0/8 от OFF1 на S0/0, поэтому он никогда не будет транслировать информацию о сети 10.0.0.0/8 обратно в OFF1 на S0/0.
Это решает нашу проблему. Если интерфейс F0/1 OFF1 не работает, и OFF1, и OFF2 поймут, что нет никакого альтернативного маршрута для достижения в сети 10.0.0.0/8.
Маршрут отравления
Маршрут отравления работает противоположном режиме расщепления горизонта. Когда маршрутизатор замечает, что какой-либо из его непосредственно подключенных маршрутов вышел из строя, он отравляет этот маршрут. По умолчанию пакет может путешествовать только 15 прыжков RIP. Любой маршрут за пределами 15 прыжков является недопустимым маршрутом для RIP. В маршруте, находящимся в неисправном состоянии, RIP присваивает значение выше 15 к конкретному маршруту. Эта процедура известна как маршрутное отравление. Отравленный маршрут будет транслироваться со всех активных интерфейсов. Принимающий сосед будет игнорировать правило разделения горизонта, передавая тот же отравленный маршрут обратно отправителю. Этот процесс гарантирует, что каждый маршрутизатор обновит информацию об отравленном маршруте.
Таймеры RIP
Для лучшей оптимизации сети RIP использует четыре типа таймеров.
Таймер удержания (Hold down timer) - RIP использует удерживающий таймер, чтобы дать маршрутизаторам достаточно времени для распространения отравленной информации о маршруте в сети. Когда маршрутизатор получает отравленный маршрут, он замораживает этот маршрут в своей таблице маршрутизации на период таймера удержания. В течение этого периода маршрутизатор не будет использовать этот маршрут для маршрутизации. Период удержания будет прерван только в том случае, если маршрутизатор получит обновление с той же или лучшей информацией для маршрута. Значение таймера удержания по умолчанию составляет 180 секунд.
Route Invalid Timer - этот таймер используется для отслеживания обнаруженных маршрутов. Если маршрутизатор не получит обновление для маршрута в течение 180 секунд, он отметит этот маршрут как недопустимый маршрут и передаст обновление всем соседям, сообщив им, что маршрут недействителен.
Route Flush Timer - этот таймер используется для установки интервала для маршрута, который становится недействительным, и его удаления из таблицы маршрутизации. Перед удалением недопустимого маршрута из таблицы маршрутизации он должен обновить соседние маршрутизаторы о недопустимом маршруте. Этот таймер дает достаточно времени для обновления соседей, прежде чем недопустимый маршрут будет удален из таблицы маршрутизации. Таймер Route Flush Timer по умолчанию установлен на 240 секунд.
Update Timer -В RIP широковещательная маршрутизация обновляется каждые 30 секунд. Он будет делать это постоянно, независимо от того, изменяется ли что-то в маршрутной информации или нет. По истечении 30 секунд маршрутизатор, работающий под управлением RIP, будет транслировать свою информацию о маршрутизации со всех своих интерфейсов.
RIP - это самый старый протокол вектора расстояний. Для удовлетворения текущих требований к сети он был обновлен с помощью RIPv2. RIPv2 также является протоколом вектора расстояния с максимальным количеством прыжков 15.
Вы все еще можете использовать RIPv1, но это не рекомендуется. В следующей таблице перечислены ключевые различия между RIPv1 и RIPv2.
Основные различия между RIPv1 и RIPv2
RIPv1
RIPv2
Он использует широковещательную передачу для обновления маршрутизации.
Он использует многоадресную рассылку для обновления маршрутизации.
Он посылает широковещательный пакет по адресу назначения 255.255.255.255.
Он отправляет многоадресную рассылку по адресу назначения 224.0.0.9.
Он не поддерживает VLSM.
Он поддерживает VLSM.
Он не поддерживает никакой аутентификации.
Он поддерживает аутентификацию MD5
Он поддерживает только классовую маршрутизацию.
Он поддерживает как классовую, так и бесклассовую маршрутизацию.
Он не поддерживает непрерывную сеть.
Он поддерживает непрерывную сеть.
Основной задачей, серверов является быть площадкой для функционирования серверного ПО или предоставления сервиса от (англ. Service - Сервис). Одним из основных сервисов в офисе, является сервис доступа к Internet для сотрудников офиса. Данный сервис необходимо предоставлять для сотрудников в целях осуществления ими своих служебных обязанностей. Обычно данный сервис, предоставляется по заранее определенным правилам для данного офиса или сотрудников.
Классическим вариантом для предоставления данного сервиса является ОС CentOS 7 + Squid.
Данная Связка очень распространена. Будем считать, что у нас имеется уже установленная ОС CentOS7 с подключением в интернет и доступна по порту 22 ssh для настройки.
Установка
Первое, что нам необходимо сделать это обновить ОС.
yum update
Если машина является прокси сервером, то логично предположить, что у нее должен быть включен Firewall, следовательно, нам нужно открыть во внутрь порт, на который сервис squid будет принимать подключения от клиентов внутренней сети. В большинстве случаев используют порт 3128, но можно взять любой не занятый.
Настраиваем правило на Firewall:
firewall-cmd --permanent --add-port=3128/tcp
И обязательно надо перезапустить сервис:
firewall-cmd --reload
Далее переходим к установке и настройке непосредственно самого Squid. Установка производится следующей командой:
yum install squid -y
Открываем файл конфигурации для правки и добавления:
nano /etc/squid/squid.conf
В конфигурации прописаны стандартные подсети, но иногда подсеть пользовательских ПК не совпадает со стандартной или не входит, то вносим ее в конфигурационный файл acl localnet src 217.33.25.0/24
Чтобы наш прокси сервер пропускал любой трафик, необходимо добавить следующую строчку в конфигурацию http_access allow all
Очень важно, чтобы данная строчка была в конфигурации выше строчки запрещающего правила. Запрещающая строчка выглядит так: http_access deny all
Следующим шагом необходимо настроить каталок для кэша:
cache_dir ufs /var/spool/squid 8192 32 256
В данной команде ufs - файловая система для squid данная файловая система используется для squid, путь для хранения кэша, 8192 - размер в МБ сколько будет выделено под кэш, 32 количество каталогов первого уровня для размещения кэша, 256 количество каталогов второго уровня.
Следующим шагом будет создание структуры директорий для кэширования. Это можно сделать следующей командой: squid -z и вот наш прокси-сервер уже готов можно запускать прокси сервер, командой: systemctl start squid. А чтобы необходимый сервис запускался автоматически после перезагрузки или отключения сервера добавляем сервис наш в автозапуск: systemctl enable squid
Дополнительной настройки для https не требуется все должно работать по умолчанию. И обязательно перезагрузить squid следующей командой systemctl restart squid
Для управления squid можно пользоваться командой service status squid, service stop squid.
Если сделанные изменения не затрагивают глобальных параметров, можно вообще не перезапускать сервис целиком, а дать команду squid перечитать конфиг squid -k reconfigure. Сервер для приема и проксирования соединений готов. Следующей задачей является настройка клиентских ПК для его использования. Если офис не большой 20-30 пользователей можно решить задачу, что называется в лоб. Сделать настройку в браузере в ручном режиме: Идем, Панель управления → Свойства Браузера → Подключения → Настройка сети → убираем галочку "Автоматическая настройка сети", добавляем галочку в поле "Прокси-Сервер", использовать прокси сервер для локальных подключений, в поле адрес прописываем или FQDN имя сервера и в поле порт 3128.
Важный момент! FQDN имя сервера должно правильно разрешатся в DNS службе, указанной в настройках сетевого подключения. Проверить можно просто, открываем командную строку и пишем nslookup FQDN, если команда возвращает правильный ip адрес, то все сделано правильно.
Рассмотрим вариант, когда у нас большое количество пользовательских ПК 100+. Естественно в такой ситуации проблематично сразу, всем сделать настройку для использования прокси-сервера.
Самый оптимальный путь в данном случае это настройка параметров браузера, через WPAD файл и доставка на ПК сотрудника через web сервис.
Устанавливаем web сервис:
yum install httpd -y
Переходим в рабочий каталог:
cd /var/www/html
Создаем новый файл командой touch wpad.dat и приводим его вот к такому виду, как на картинке:
Файл состоит из java скрипта основная строчка return "PROXY FQDN:3128"; Это то, что попадет в настройки в веб браузеры ваших пользователей. Первая часть готова! Далее нам надо доставить данные настройки конечным пользователям. В этом нам поможет DHCP. Можно конечно сделать, через DNS, но там больше мороки на мой взгляд. Проще всего использовать DHCP сервер, но для этого необходимо внести коррективы и добавить дополнительную опцию 252, где будет указан url файла авто настройки. Данная опция может применятся на машину или на целую подсеть, а далее уже вместе с остальными настройками попадает на конечную машину пользователя.
Запускаем веб и ставим в автозагрузку:
systemctl start httpd systemctl enable httpd
DHCP сервер настраивается следующим образом:
Открываем консоль управление DHCP сервера. В свойствах сервера выбираем управление опциями -Set predefined Option. И добавляем опцию 252 - Имя -WPAD, код 252 Тип данных - String, Описание Web Proxy WPAD.
Затем в поле String добавляем значение URL по умолчанию и сохраняем параметр. После этого мы можем данную опцию применять, либо к серверу в целом либо к определенной областиподсети адресов.
Определение проблемного пространства
Сетевые инженеры часто сталкиваются с проблемой слишком большого трафика для слишком малого канала связи. В частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. Рисунок ниже иллюстрирует это.
На рисунке A обменивается данными с G, а B обменивается данными с E. Если каждая из этих пар устройств использует близкую к доступной полосе пропускания на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполагая, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети.
Когда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускная способность канала. Во время перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определять, какой трафик следует перенаправить, какой отбросить и в каком порядке следует пересылать пакеты. Для решения этой проблемы были созданы различные схемы приоритезации.
Управление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживания (QoS). Восприятие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Например, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаются. Кроме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки.
По этим причинам, а также из-за того, что конфигурация, необходимая для реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считается темным искусством. Чтобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей для различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов.
Хотя можно погрузиться во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же.
Почему бы просто не сделать линии связи достаточно большими?
После обдумывания ценностного предложения QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии связи, чтобы избежать перегрузки. В конце концов, если бы линии связи были достаточно большими, перегрузка исчезла бы. Если перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. Весь трафик будет доставлен, и все эти досадные проблемы, связанные с недостаточной пропускной способностью, будут устранены. Действительно, избыточное выделение ресурсов, возможно, является лучшим QoS из всех.
К сожалению, стратегия избыточного обеспечения не всегда является доступным вариантом. Даже если бы это было так, самые большие доступные каналы связи не могут преодолеть определенные модели трафика. Некоторые приложения будут использовать столько пропускной способности, сколько доступно при передаче данных, создавая точку перегрузки для других приложений, совместно использующих линию связи. Другие будут передавать в микроперерывах, подавляющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управления передачей (TCP)-будут намеренно собирать путь время от времени, чтобы определить наилучшую скорость передачи данных. В то время как более крупная линия связи может сократить время существования состояния перегрузки, в некоторых сценариях нет такой вещи, как наличие достаточной полосы пропускания для удовлетворения всех требований.
Большинство сетей построены на модели избыточной подписки, когда некоторая совокупная пропускная способность распределяется в определенных узких местах. Например, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Это приводит к коэффициенту переподписки 480:160, который уменьшается до 3:1. Неявно, 160 Гбит/с полосы пропускания центра обработки данных является потенциальным узким местом - точкой перегрузки - для 480 Гбит/с полосы пропускания хоста. И все же соотношение переподписки 3:1 является обычным явлением в схемах коммутации центров обработки данных. Зачем?
Окончательный ответ - часто деньги. Часто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Например, в структуре центра обработки данных, приведенной выше, почти наверняка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 Гбит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. Сетевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питания, а также стоимость дополнительного охлаждения, необходимого для управления окружающей средой после добавления необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола.
Затраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Некоторые события перегрузки не являются достаточно частыми, чтобы оправдать дорогостоящее обновление сети. Будет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Нет. Вместо этого для решения проблемы с трафиком вносятся другие корректировки.
Например, компании могут наиболее остро столкнуться с этим ограничением в глобальных сетях, где каналы арендуются у поставщиков услуг (SP). Частично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов для организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой протяженности самостоятельно. Эти линии дальней связи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии связи в одном кампусе или даже в одном здании. Высокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней связи.
Организации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий связи, но, опять же, важно помнить о деньгах.
В мире избыточной подписки и последующих точек перегруженности, а также временных моделей трафика, которые требуют тщательного управления, схемы приоритизации трафика QoS всегда будут необходимы.
Классификация
Схемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определяется?
Классы трафика представляют собой агрегированные группы трафика. Потоки данных из приложений, требующих аналогичной обработки или представляющих аналогичные схемы трафика в сети, помещаются в группы и управляются политикой QoS (или классом обслуживания, CoS). Эта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS для потенциально бесконечного числа приложений. С практической точки зрения сетевые инженеры обычно группируют трафик в четыре класса. Конечно, возможны и другие классы, и такие схемы существуют в производственных сетях. Однако управление системой классификации и политическими действиями становится все более утомительным по мере того, как число классов превышает четыре.
Каждый пакет может быть отнесен к определенной CoS на основе адреса источника, адреса назначения, порта источника, порта назначения, размера пакета и других факторов. Предполагая, что каждое приложение имеет свой собственный профиль или набор характеристик, каждое приложение может быть помещено в определенный CoS и действовать в соответствии с локальной политикой QoS. Проблема с этим методом классификации трафика заключается в том, что классификация является только локально значимой-действие классификации относится только к устройству, выполняющему классификацию.
Такая классификация пакетов требует много времени, а обработка каждого пакета потребует больших вычислительных ресурсов. Поэтому лучше не повторять эту обработку на каждом устройстве, через которое проходит пакет. Вместо этого лучше один раз классифицировать трафик, пометить пакет в этой единственной точке и действовать в соответствии с этой маркировкой на каждом последующем переходе в сети.
Примечание: Несмотря на то, что пакеты и кадры в сети различны, в этой статье будет использоваться термин пакеты.
Были разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживания (ToS), включенное в заголовок Интернет-протокола версии 4 (IPv4). Версия 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели. Кадры Ethernet используют 3-битное поле как часть спецификации 802.1p. На рисунке показано поле ToS IPv4.
В наилучшей сетевой практике классификация трафика должна приводить к одному действию и только к одному действию-маркировке. Когда пакет помечен, присвоенное значение может сохраняться и действовать на протяжении всего пути следования пакета по сетевому пути. Классификация и последующая маркировка должны быть "одноразовым" событием в жизни пакета.
Лучшая практика QoS - рекомендуется маркировать трафик, как близко к источнику, насколько это возможно. В идеале трафик будет помечен в точке входа в сеть. Например, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства Интернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следования пакета по сети.
Альтернативная схема классификации и маркировки трафика входящим сетевым устройством заключается в том, что приложение само маркирует свой собственный трафик. Другими словами, пакет отправляется с уже заполненным байтом ToS. Это поднимает проблему доверия. Следует ли разрешить приложению ранжировать собственную важность? В худшем случае все приложения эгоистично помечают свои пакеты значениями, указывающими наивысшую возможную важность. Если каждый пакет помечен как очень важный, то на самом деле ни один пакет не является особо важным. Чтобы один пакет был более важным, чем любой другой, должна быть дифференциация. Классы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение.
Для сохранения контроля над классификацией трафика все сети, реализующие QoS, имеют границы доверия. Границы доверия позволяют сети избежать ситуации, когда все приложения помечают себя как важные. Представьте, что произошло бы на перегруженной дороге, если бы у каждого автомобиля были мигающие аварийные огни - действительно важные автомобили не выделялись бы.
В сети некоторым приложениям и устройствам доверяют отмечать свой собственный трафик. Например, IP-телефонам обычно доверяют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управления, то есть метки, которые IP-телефоны применяют к своему трафику, принимаются входным сетевым устройством. Другие конечные точки или приложения могут быть ненадежными, что означает, что байт ToS пакета стирается или перезаписывается при входе. По умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Например, производителям, помещенным в пакет сервером, часто доверяют, а маркировкам, установленным конечным хостом, - нет. На рисунке ниже показана граница доверия.
На рисунке 3 пакеты, передаваемые B, помечены AF41. Поскольку эти пакеты исходят от хоста в домене доверия QoS, маркировка остается, пока они проходят через D. Пакеты, исходящие от A, помечаются EF; однако, поскольку A находится за пределами доверенного домена QoS, эта маркировка удаляется в D. Пакеты в пределах доверенного домена, исходящие из A, рассматриваются как немаркированные с точки зрения QoS. Маркировка протокола физического уровня и верхнего уровня может быть связана, а может и не быть. Например, маркировка верхнего уровня может быть скопирована в маркировку нижнего уровня, или маркировка нижнего уровня может быть перенесена через сеть, или маркировка нижнего уровня может быть удалена. Существует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы понять, как маркировка обрабатывается на разных уровнях, а также на каждом переходе.
Хотя операторы сети могут использовать любые значения, которые они выбирают в байте ToS для создания различных классов трафика, часто лучше придерживаться некоторых стандартов, таких как значения, определенные стандартами IETF RFC. Эти стандарты были определены для того, чтобы дать сетевым инженерам логическую схему, позволяющую надлежащим образом различать множество различных классов трафика.
Две из этих схем "Per Hop Behavior" появляются в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновляющих или уточняющих содержание этих основополагающих документов. Оба эти RFC определяют схемы маркировки трафика, включая точные значения битов, которые должны заполнять байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. Они известны как точки кода дифференцированного обслуживания или значения DSCP.
Например, схема гарантированной пересылки RFC2597 определяет 12 значений в побитовой иерархической схеме для заполнения восьми битов в поле байта ToS. Первые три бита используются для идентификации класса, а вторые три бита определяют приоритет отбрасывания. Последние два бита не используются. Таблица 1 иллюстрирует маркировку кода для нескольких классов AF.
В таблице 1 показано значение бита DSCP для AF11, трафика класса 1 с низким приоритетом отбрасывания, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывания. Изучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. Весь трафик класса 1 помечается 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. Весь трафик с низким приоритетом отбрасывания помечается 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывания-100 во-вторых трех битах и т. д.
Схема гарантированной пересылки показана в таблице 2 для примера. Это не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Например, схема выбора класса, описанная в RFC2474, существует для обратной совместимости со схемой маркировки приоритета IP. Приоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. Селектор классов также использует восемь значений, заполняя первые три бита шестибитового поля DSCP значимыми значениями (соответствующими устаревшей схеме приоритета IP), а последние три бита - нулями. В таблице 2 показаны эти селекторы классов.
RFC3246 определяет требования к задержке, потерям и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (десятичное 46).
Количество и разнообразие формально определенных значений DSCP может показаться ошеломляющим. Комбинированные определения AF, CS и EF сами по себе приводят к формальным определениям для 21 различных классов из возможных 64, использующих шесть битов поля DSCP. Ожидается ли, что сетевые инженеры будут использовать все эти значения в своих схемах приоритезации QoS? Следует ли разбивать трафик с такой высокой степенью детализации для эффективного QoS?
На практике большинство схем QoS ограничиваются от четырех до восьми классов трафика. Различные классы позволяют обрабатывать каждую группу по-своему во время перегрузки. Например, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. Другой класс трафика может иметь приоритет над всем остальным трафиком. Еще один может быть определен как критически важный для бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. Трафик сетевого протокола, критичный для стабильности инфраструктуры, можно рассматривать как очень высокий приоритет. Класс трафика scavenger может находиться в конце списка приоритетов, получая немного больше внимания, чем немаркированный трафик.
Схема, включающая эти значения, вероятно, будет представлять собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличаться от организации к организации. Обычно принятые значения включают EF для критического трафика с требованием своевременности, например VoIP, и CS6 для трафика управления сетью, такого как протоколы маршрутизации и резервирования на первом этапе. Немаркированный трафик (т.е. значение DSCP, равное 0) доставляется по принципу "максимальных усилий", без каких-либо гарантий уровня обслуживания (обычно это считается классом scavenger, как указано выше).