По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Интересная проблема, упомянутая как в RFC 2597, так и в RFC 3246, - это проблема сохранения метки при туннелировании помеченного пакета. Когда пакет туннелируется, исходный пакет оборачивается-или инкапсулируется-внутри нового IP-пакета. Значение байта ToS находится внутри IP-заголовка теперь инкапсулированного пакета. Ой-ой. Что только что произошло с тщательно разработанной схемой классификации трафика? Ответ заключается в том, что сетевые устройства участвуют в отражении ToS при туннелировании.
Когда пакет туннелируется, значение байта ToS в инкапсулированном пакете копируется (или отражается) в IP-заголовке туннельного пакета. Это сохраняет классификацию трафика туннелированного приложения.
Аналогичная проблема возникает при отправке маркированного трафика из сетевого домена, который вы контролируете, в тот, который вам не принадлежит. Наиболее распространенный пример - отправка помеченного трафика из вашей локальной сети в сеть вашего поставщика услуг, пересекая его глобальную сеть. Поставщики услуг, как часть контракта на обеспечение связи, также часто предоставляют дифференцированные уровни обслуживания. Однако, чтобы они могли предоставлять дифференцированные услуги, трафик должен быть помечен таким образом, чтобы они могли его распознать. Их схема маркировки вряд ли будет такой же, как ваша схема маркировки, учитывая огромное количество возможных возможных схем маркировки.
Предлагается несколько решений этой дилеммы:
Мутация DSCP: в этом сценарии сетевое устройство на границе между LAN и WAN переводит метку из исходного значения, назначенного в LAN, в новое значение, которое будет соблюдать SP. Перевод выполняется в соответствии с таблицей, настроенной сетевым инженером.
Трансляция DSCP: для провайдеров SP нередко наблюдаются только первые три бита байта ToS, что восходит к временам IP Precedence, определенным еще в RFC791.
Во втором решении сетевой инженер сталкивается с проблемой создания современной схемы маркировки DSCP с использованием шести битов, даже если поставщик услуг будет обращать внимание только на первые три. Задача состоит в том, чтобы поддерживать дифференциацию. Например, рассмотрим схему, показанную в таблице ниже. Эта схема не решит проблему.
В этой таблице определены шесть уникальных значений DSCP для использования в локальной сети. Однако эти шесть уникальных значений уменьшаются до трех уникальных значений, если только первые три бита учитываются поставщиком услуг. Это означает, что некоторый трафик, который до попадания в сеть провайдера мог обрабатываться по-разному, теперь будет помещен в одну корзину. В этом примере EF и CS5, ранее уникальные, попадают в один и тот же класс, когда они покидают граничный маршрутизатор, поскольку оба начальных бита EF и CS5 равны 101. То же самое касается AF11, AF12 и AF13 - три ранее различных классы трафика, которые теперь будут обрабатываться одинаково при прохождении SP WAN, поскольку все они имеют одинаковое начальное значение 001 в начальных трех битах.
Способ решить эту проблему - создать схему маркировки DSCP, которая будет поддерживать уникальность в первых трех битах, как показано в таблице. Однако для этого может потребоваться сокращение общего количества классов трафика. Ограничение схемы первыми тремя битами для определения классов уменьшит общее количество классов до шести.
В таблице выше показана схема маркировки, использующая сочетание значений EF, AF и Class Selector, специально выбранных для сохранения уникальности первых трех битов.
Вот 5 советов, которые помогут Вам получить приятные впечатления и повысить производительность при использовании VMWare Workstation.
5 лайфхаков для пользователя VMWare Workstation
1. Убедитесь, что выбрана правильная гостевая операционная система
Вы можете убедиться в этом в меню Настройки -> Редактор конфигурации -> Гостевая ОС (Settings -> Configuration Editor -> Guest OS).
2. Параметры настройки памяти
Если Вы планируете запускать одну виртуальную машину продолжительное время, то хорошим решением является предоставление виртуальной машине половины памяти, доступной на хосте.
На хосте Linux перейдите в раздел Настройки -> Общий объем зарезервированной памяти (Settings -> Total Reserved Memory.).
На хосте Windows NT или Windows 2000 перейдите в раздел Параметры -> Глобальные настройки -> Память (Settings -> Global Preferences -> Memory).
3. Обычный режим и режим отладки
Виртуальные машины будут работать немного медленнее, если они работают в режиме отладки.
Выберите Параметры -> Редактор конфигурации -> Разное (Settings -> Configuration Editor -> Misc).
Убедитесь, что на хосте Linux установлен обычный уровень регистрации (Logging level -> Normal).
Убедитесь, что на хосте Windows NT или Windows 2000 снят флажок "Выполнить с отладочной информацией" (Run with Debugging Information).
4. Установите инструменты VMware
Внутри виртуальной машины диски SCSI и диски IDE, использующие прямой доступ к памяти (DMA - direct memory access), имеют примерно одинаковую производительность. Однако диски IDE могут быть очень медленными в гостевой операционной системе, которая либо не может использоваться, либо не настроена на использование DMA. VMWare Tools поможет решить эту проблему.
После установки VMWare Tools можно перетаскивать файлы между хостом и виртуальной машиной. Для использования данной функции необходимо установить VMWare Tools.
VMWare Tools можно установить в меню «Виртуальная машина» -> Установка VMWare Tools.
5. Снимки виртуальных машин
Выключите (выключите питание) вашу виртуальную машину перед созданием снимка.
Снимки, сделанные в состоянии «Включено» (Power On) или «Приостановлено» (Suspended) часто занимают больше места и памяти, а также могут занять некоторое время для загрузки в следующем восстановлении снимка. "Включения питания" или "приостановленного" состояния, часто занимают больше места и памяти, а также загрузка может занять некоторое время при следующем восстановлении снимка. Если Вы можете, выключите виртуальную машину, а затем сделайте снимок.
Протокол Syslog - это способ для сетевых устройств отправлять сообщения о событиях на сервер регистрации - обычно известный как Syslog сервер. Этот протокол поддерживается широким спектром устройств и может использоваться для регистрации различных типов событий. Например, маршрутизатор может отправлять сообщения о том, что пользователи подключаются через консоль, а веб-сервер может регистрировать события, в которых отказано в доступе.
Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.
В отличие от SNMP, Syslog не может использоваться для «опроса» устройств для сбора информации. Например, SNMP имеет сложную иерархическую структуру, которая позволяет станции управления запрашивать у устройства информацию о таких вещах, как данные о температуре или доступное дисковое пространство. Это невозможно с Syslog - он просто отправляет сообщения в центральное место, когда инициируются определенные события.
Syslog серверы
Syslog - отличный способ объединить логи из нескольких источников в одном месте. Как правило, большинство серверов Syslog имеют несколько компонентов, которые делают это возможным.
Syslog слушатель: Syslog сервер должен получать сообщения, отправленные по сети. Процесс прослушивания собирает данные системного журнала, отправленные через 514 UDP порт. Как мы знаем UDP-сообщения не подтверждаются или не гарантируются, поэтому имейте в виду, что некоторые сетевые устройства будут отправлять данные Syslog через 1468 TCP порт для обеспечения доставки сообщений.
База данных: большие сети могут генерировать огромное количество данных syslog’а . Хорошие серверы будут использовать базу данных для хранения логов для быстрого поиска.
Программное обеспечение для управления и фильтрации: из-за больших объемов данных иногда бывает сложно найти конкретные записи в журнале. Решение состоит в том, чтобы использовать syslog сервер, который автоматизирует часть работы и позволяет легко фильтровать и просматривать важные сообщения журнала. Серверы должны иметь возможность генерировать оповещения, уведомления и алерты в ответ на выбранные сообщения, чтобы администраторы сразу узнавали, когда возникла проблема, и могли предпринять быстрые действия
Syslog сообщения
Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение.
Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog'а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».
Syslog сообщения также имеют поле уровня серьезности. Уровень серьезности указывает, насколько важным считается сообщение. Серьезность «0» является чрезвычайной ситуацией, «1» - это предупреждение, которое требует немедленных действий, а шкала продолжается вплоть до «6» и «7» - информационных и отладочных сообщений.
0
Emergency
Система не работоспособна
1
Alert
Система требует немедленного вмешательства
2
Critical
Состояние системы критическое
3
Error
Сообщения об ошибках
4
Warning
Предупреждения о возможных проблемах
5
Notice
Сообщения о нормальных, но важных событиях
6
Informational
Информационные сообщения
7
Debug
Отладочные сообщения
Недостатки syslog
У протокола syslog есть несколько недостатков.
Во-первых, проблема согласованности. Протокол Syslog не определяет стандартный способ форматирования содержимого сообщения - и существует столько же способов форматирования сообщения, сколько существует разработчиков. Некоторые сообщения могут быть удобочитаемыми, а некоторые нет. Syslog это не волнует - он просто предоставляет способ передачи сообщения.
Есть также некоторые проблемы, которые возникают из-за того, что syslog использует UDP в качестве транспорта - поэтому возможно потерять сообщения из-за перегрузки сети или потери пакетов.
Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам.
Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.