По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Как узнать, что ваша сеть нуждается в обновлении? Компания Cisco перечислила 5 признаков того, что ваша сеть нуждается в обновлении, а также перечислила основные технологии и услуги, которые могут помочь вам построить более интеллектуальную, более безопасную и более эффективную сеть. Давайте посмотрим, что они предлагают? Вы полагаетесь на устаревшую систему защиты Всего один неверный клик, и вы можете подвергнуть риску активы клиентов и повлиять на всю организацию. Чтобы безопасно подключить все, начните с использования Cisco Software-Defined Access (SD-Access), чтобы упростить сегментацию и автоматизировать политику в сети. Используйте данные реального времени для обеспечения безопасного доступа, обеспечения наглядности и аналитики, а также для обнаружения подозрительной активности - даже в зашифрованном трафике. Вы проводите большую часть своего времени на поддержание работы сети Вы не можете подготовить свою сеть к будущему, если будете тратить все свое время на поддержку устаревшей инфраструктуры и программного обеспечения. Благодаря сети, основанной на виртуализации Cisco DNA и программном обеспечении Cisco ONE, вы можете повысить производительность, упростить развертывание, эксплуатацию и управление. Cisco DNA Center упрощает проектирование, провижининг, настройку политик и внесение изменений в конфигурацию единой сетевой структуры на централизованной панели мониторинга. Скорость сети не соответствует требованиям Старые сети не были построены для удовлетворения технологических требований сегодняшнего дня. Когда вы переходите на новую сеть, готовая к использованию цифровая инфраструктура позволяет легко контролировать и улучшать взаимодействие с сетью. Благодаря современным конвергентным проводным и беспроводным технологиям вы можете внедрять новые решения быстрее, чем когда-либо. Беспроводные решения Cisco 802.11ac Wave 2 работают в 11,5 раз быстрее, чем технологии предыдущего поколения. Вы не знаете, что происходит в вашей сети То, чего вы не знаете, может повредить вашему бизнесу, а то, что вы знаете, может иметь большое значение. Cisco DNA Analytics and Assurance использует машинное обучение для предоставления действенных идей, а централизованная панель мониторинга Cisco DNA Center помогает оптимизировать производительность сети и приложений. Это означает, что вы можете принимать более разумные решения на основе данных с помощью сети. Вам нужно улучшить опыт Ожидания растут на всех фронтах - и, если вы не будете советовать им, то будет соответствовать кто-то другой. Поскольку сотрудникам нужны возможности работы на дому, а клиентам - индивидуальный подход, вам понадобится готовая к использованию цифровая инфраструктура, предназначенная для обеспечения безопасности, мобильности, интернета вещей и облачных вычислений. Если все сделано правильно, то преимущество сети может дать вам представление о ваших пользователях, их устройствах и приложениях, к которым они обращаются - все это будет применяться при изменении и совершенствовании сети.
img
Первоначально BGP был разработан как протокол Внешнего шлюза (Exterior Gateway Protocol - EGP), что означает, что он предназначался для подключения сетей или автономных систем (AS), а не устройств. Если BGP является EGP, это должно означать, что другие протоколы маршрутизации, такие как RIP, EIGRP, OSPF и IS-IS, должны быть протоколами внутренних шлюзов (Interior Gateway Protocols- IGP). Четкое определение внутренних и внешних шлюзов оказалось полезным при проектировании и эксплуатации крупномасштабных сетей. BGP является уникальным среди широко распространенных протоколов в том, что касается расчета пути без петель. Существует три широко используемых протокола векторов расстояний (Spanning Tree, RIP и EIGRP). Существует два широко используемых протокола состояния канала связи (OSPF и IS-IS). И есть еще много примеров этих двух типов протоколов, разработанных и внедренных в то, что можно было бы считать нишевыми рынками. BGP, однако, является единственным широко развернутым протоколом вектора пути. Каковы наиболее важные цели EGP? Первый - это, очевидно, выбор путей без петель, но это явно не означает кратчайшего пути. Причина, по которой кратчайший путь не так важен в EGP, как в IGP, заключается в том, что EGP используются для соединения объектов, таких как поставщики услуг, поставщики контента и корпоративные сети. Подключение сетей на этом уровне означает сосредоточение внимания на политике, а не на эффективности - с точки зрения сложности, повышение состояния с помощью механизмов политики при одновременном снижении общей оптимизации сети с точки зрения передачи чистого трафика. BGP-пиринг BGP не обеспечивает надежной передачи информации. Вместо этого BGP полагается на TCP для передачи информации между одноранговыми узлами BGP. Использование TCP гарантирует: Обнаружение MTU обрабатывается даже для соединений, пересекающих несколько переходов (или маршрутизаторов). Управление потоком осуществляется базовым транспортом, поэтому BGP не нуждается в непосредственном управлении потоком (хотя большинство реализаций BGP действительно взаимодействуют со стеком TCP на локальном хосте, чтобы повысить пропускную способность, в частности, для BGP). Двусторонняя связь между одноранговыми узлами обеспечивается трехсторонним рукопожатием, реализованным в TCP. Несмотря на то, что BGP полагается на базовое TCP-соединение для многих функций, которые плоскости управления должны решать при построении смежности, по-прежнему существует ряд функций, которые TCP не может предоставить. Следовательно, необходимо более подробно рассмотреть процесс пиринга BGP. Рисунок 1 позволяет изучить этот процесс. Сеанс пиринга BGP начинается в состоянии ожидания (idle state). A отправляет TCP open на порт 179. B отвечает на временный порт (ephemeral port) на A. После завершения трехстороннего подтверждения TCP (сеанс TCP успешен), BGP перемещает состояние пиринга для подключения. Если пиринговый сеанс формируется через какой-либо тип фильтрации на основе состояния, такой как брандмауэр, важно, чтобы открытое TCP-сообщение передавалось «изнутри» фильтрующего устройства. В случае сбоя TCP-соединения состояние пиринга BGP переводится в активное. A отправляет BGP open в B и переводит B в состояние opensent. В этот момент A ожидает от B отправки сообщения keepalive. Если B не отправляет сообщение keepalive в течение определенного периода, A вернет сеанс обратно в состояние ожидания (idle state). Открытое сообщение содержит ряд параметров, например, какие семейства адресов поддерживают два спикера BGP и hold timer. Это называется согласованием возможностей. Самый низкий (минимальный) hold timer из двух объявленных выбирается в качестве hold timer для однорангового сеанса. Когда B отправляет A сообщение keepalive, A переводит B в состояние openconfirm. На этом этапе A отправит B сообщение keepalive для проверки соединения. Когда A и B получают сообщения поддержки активности друг друга, пиринговый сеанс переходит в established state. Два узла BGP обмениваются маршрутами, поэтому их таблицы обновлены. A и B обмениваются только своими лучшими путями, если какая-либо форма многонаправленного распространения BGP не поддерживается и не настроена на двух спикерах. Чтобы уведомить A, что он завершил отправку всей своей локальной таблицы, B отправляет A сигнал End of Table (EOT) или End of RIB (EOR). Существует два типа пиринговых отношений BGP: одноранговые узлы BGP в одной и той же автономной системе (AS, что обычно означает набор маршрутизаторов в одном административном домене, хотя это довольно общее определение) называются внутренними одноранговыми узлами BGP (internal BGP - iBGP) и Одноранговые узлы BGP между автономными системами называются внешними (или внешними - exterior) узлами BGP (eBGP). Хотя два типа пиринговых отношений BGP построены одинаково, у них разные правила объявления. Процесс выбора оптимального пути BGP Поскольку BGP предназначен для соединения автономных систем, алгоритм наилучшего пути ориентирован в первую очередь на политику, а не на отсутствие петель. Фактически, если вы изучите какое-либо стандартное объяснение процесса наилучшего пути BGP, то, является ли конкретный путь свободным от петель, вообще не будет учитываться в процессе принятия решения. Как же тогда BGP определяет, что конкретный узел объявляет маршрут без петель? Рисунок 2 демонстрирует это. На рисунке 2 каждый маршрутизатор находится в отдельной AS, поэтому каждая пара спикеров BGP будет формировать сеанс пиринга eBGP. A, который подключен к 2001: db8: 3e8: 100 :: / 64, объявляет этот маршрут к B и C. Объявления маршрута BGP несут ряд атрибутов, одним из которых является путь AS. Перед тем, как A объявит 100 :: / 64 для B, он добавляет свой номер AS в атрибут AS Path. B получает маршрут и объявляет его D. Перед объявлением маршрута к D он добавляет AS65001 к AS Path. Тогда путь AS, прослеживающийся от A до C, на каждом шаге выглядит примерно так: Получено B: [AS65000] Получено C: [AS65000, AS65001] Получено D: [AS65000, AS65001, AS65003] Когда D получил маршрут от B, он анонсирует его обратно в C (в BGP нет split horizon). Предположим, что C, в свою очередь, объявляет обратный маршрут к A по какой-то причине (в этой ситуации это не так, потому что путь через A был бы лучшим путем к месту назначения, а просто для демонстрации предотвращения петель), A будет проверять AS Path и обнаружение его локальной AS находится в AS Path. Это явно петля, поэтому A просто игнорирует маршрут. Поскольку этот маршрут игнорируется, он никогда не помещается в таблицу топологии BGP. Следовательно, с использованием процесса наилучшего пути BGP сравниваются только маршруты без петель. В большинстве реализаций процесс наилучшего пути BGP состоит из 13 шагов (первый шаг реализуется не всегда, так как это локальное решение со стороны узла BGP): Выбирается маршрут с наибольшим весом. Некоторые реализации не используют вес маршрута. Выбирается маршрут с наивысшим местным предпочтением (local preference- LOCAL PREF). Local preference собой политику выхода локальной AS - какую точку выхода из доступных точек выхода предпочел бы владелец этой AS, как и узел BGP. Предпочитайте маршрут с локальным происхождением, то есть на этом узле BGP. Этот шаг редко используется в процессе принятия решения. Предпочитайте путь с самым коротким AS Path. Этот шаг предназначен для выбора наиболее эффективного пути через объединенную сеть, выбора пути, который будет проходить через наименьшее количество автономных систем для достижения пункта назначения. Операторы часто добавляют записи AS Path, чтобы повлиять на этот шаг в процессе принятия решения. Предпочитайте путь с наименьшим значением координат. Маршруты, которые перераспределяются из IGP, предпочтительнее маршрутов с неизвестным происхождением. Этот шаг редко оказывает какое - либо влияние на процесс принятия решений. Предпочитайте путь с самым низким multiexit discriminator (MED). MED представляет входную политику удаленной AS. Таким образом, MED сравнивается только в том случае, если от одной и той же соседней AS было получено несколько маршрутов. Если один и тот же маршрут получен от двух разных соседних автономных систем, MED игнорируется. Предпочитайте маршруты eBGP маршрутам iBGP. Предпочитайте маршрут с наименьшей стоимостью IGP до следующего перехода. Если политика локального выхода не задана (в форме локального предпочтения), и соседняя AS не установила политику входа (в форме MED), то путь с ближайшим выходом из локального маршрутизатора выбирается как точка выхода. Определите, следует ли устанавливать несколько путей в таблице маршрутизации (настроена некоторая форма multipath). При сравнении двух внешних маршрутов (полученных от однорангового узла eBGP) предпочтите самый старый маршрут или маршрут, изученный первым. Это правило предотвращает отток маршрутов только потому, что маршруты обновляются. Предпочитайте маршрут, полученный от однорангового узла с наименьшим идентификатором маршрутизатора. Это просто средство разрешения конфликтов для предотвращения оттока в таблице маршрутизации. Предпочитайте маршрут с наименьшей длиной кластера. Предпочитайте маршрут, полученный от однорангового узла с наименьшим адресом пиринга. Это, опять же, просто тай-брейк, выбранный произвольно, чтобы предотвратить ненужные связи и вызвать отток в таблице маршрутизации, и обычно используется, когда два одноранговых узла BGP соединены по двум параллельным каналам. Хотя это кажется долгим процессом, почти каждое решение наилучшего пути в BGP сводится к четырем факторам: локальному предпочтению (local preference), MED, длине AS Path и стоимости IGP. Правила объявления BGP BGP имеет два простых правила для определения того, где объявлять маршрут: Объявляйте лучший путь к каждому пункту назначения каждому узлу eBGP. Объявляйте лучший путь, полученный от однорангового узла eBGP, для каждого однорангового узла iBGP. Еще один способ сформулировать эти два правила: никогда не объявлять маршрут, полученный от iBGP, другому узлу iBGP. Рассмотрим рисунок 3. На рисунке 3 A и B - это одноранговые узлы eBGP, а B и C, а также C и D - одноранговые узлы iBGP. Предположим, A объявляет 2001: db8: 3e8: 100 :: / 64 для B. Поскольку B получил это объявление маршрута от однорангового узла eBGP, он объявит 100 :: / 64 на C, который является одноранговым узлом iBGP. C, изучив этот маршрут, не будет объявлять маршрут к D, поскольку C получил маршрут от однорангового узла iBGP, а D также является одноранговым узлом iBGP. Таким образом, на этом рисунке D не узнает о 100 :: / 64. Это не очень полезно в реальном мире, однако ограничение присутствует не просто так. Рассмотрим, как BGP предотвращает образование петель маршрутизации - передавая список автономных систем, через которые прошел маршрут, в самом объявлении маршрута. При объявлении маршрута от одного спикера iBGP к другому AS Path не изменяется. Если узлы iBGP объявляют маршруты, полученные от одноранговых узлов iBGP, одноранговым узлам iBGP, петли маршрутизации могут быть легко сформированы. Одним из решений этой проблемы является простое построение многоуровневых пиринговых отношений между B и D (помните, что BGP работает поверх TCP. Пока существует IP-соединение между двумя узлами BGP, они могут построить пиринговые отношения). Предположим, что B строит пиринговые отношения с D через C, и ни B, ни D не строят пиринговые отношения с C. Что произойдет, когда трафик переключается на 100 :: / 64 посредством D на C? Что будет с пакетами в этом потоке на C? У C не будет маршрута к 100 :: / 64, поэтому он сбросит трафик. Это может быть решено несколькими способами - например, B и D могут туннелировать трафик через C, поэтому C не обязательно должен иметь доступность к внешнему пункту назначения. BGP также можно настроить для перераспределения маршрутов в любой основной запущенный IGP (это плохо - не делайте этого). Для решения этой проблемы были стандартизированы рефлекторы маршрутов BGP. Рисунок 4 иллюстрирует работу отражателей маршрута. На рисунке 4 E сконфигурирован как рефлектор маршрута. B, C и D настроены как клиенты рефлектора маршрутов (в частности, как клиенты E). A объявляет маршрут 2001: db8: 3e8: 100 :: / 64 к B. B объявляет этот маршрут E, потому что он был получен от однорангового узла eBGP, а E является одноранговым узлом iBGP. E добавляет новый атрибут к маршруту, список кластеров, который указывает путь обновления в AS через кластеры отражателя маршрута. Затем E объявит маршрут каждому из своих клиентов. Предотвращение зацикливания в этом случае обрабатывается списком кластеров. Подведение итогов о BGP Хотя изначально BGP был разработан для соединения автономных систем, его использование распространилось на центры обработки данных, передачу информации о виртуальных частных сетях. Фактически, использование BGP практически безгранично. Постепенно BGP превратился в очень сложный протокол. BGP можно описать как: Проактивный протокол, который узнает о достижимых местах назначения через конфигурацию, локальную информацию и другие протоколы. Протокол вектора пути, который объявляет только лучший путь к каждому соседу и не предотвращает образование петель в автономной системе (если не развернуты рефлекторы маршрута или какая-либо дополнительная функция) Выбор путей без петель путем изучения пути, по которому может быть достигнут пункт назначения Проверка двустороннего подключения и MTU за счет использования TCP в качестве основы для передачи информации.
img
На самом деле поиск DNS это не то, что требует частого внимания. Но иногда приходится заботиться об этом. Например, если у вашего провайдера слабые сервера или же в вашей сети часто происходят DNS обращения, то нужно настроить локальный кэширующий DNS сервер. Как кэширующий DNS-сервер может пригодиться? Кэширующий DNS-сервер занимается обработкой DNS запросов, которые выполняет ваша система, затем сохраняет результаты в памяти или кэширует их. В следующий раз, когда система посылает DNS запрос для того же адреса, то локальный сервер почти мгновенно выдает результат. Эта идея может показаться бесполезной. Подумаешь, какие-то там секунды. Но если DNS сервера провайдера тратят много времени на разрешение имени, то в результате падает скорость Интернет серфинга. Например, домашняя страница новостного канала MSNBC для корректной работы обращается более чем к 100 уникальным доменам. Даже если на запрос тратится одна десятая секунды, в итоге получается 10 секунд ожидания, что по нынешним меркам слишком много. Локальный кэширующий DNS увеличивает скорость не только дома или в офисе, он также помогает работе серверов. Например, у вас есть почтовый сервер с анти-спам фильтром, который выполняет очень много DNS запросов. Локальный кэш намного увеличить скорость его работы. И наконец, system-resolved поддерживает новейшие стандарты вроде DNSSEC и DNSoverTLS или DoT. Эти технологии увеличивают безопасность при работе в Интренет. Какой локальный кэширующий сервер выбрать? В этом руководстве будет использован сервер systemd-resolved. Эта утилита является частью набора управления системой systemd. Если в вашей системе используется systemd, а большинство дистрибутивов Linux используют это, то в системе уже установлен systemd-resolved, но не запущен. Большинство систем не используют эту утилиту. systemd-resolved запускает небольшой локальный кэширующий DNS-сервер, который мы настроим на запуск при загрузке системы. Затем мы изменим конфигурацию всей системы так, чтобы DNS запросы шли на локальный сервер. Как проверить используется ли systemd-resolved? В некоторых дистрибутивах, например Ubuntu 19.04, по умолчанию используется systemd-resolved. Если у вас уже запущен systemd-resolved, тогда не нужно что-то настраивать в системе. Но нужно проверить на корректность утилит управления сетевыми настройками, такие как NetworkManager, так как они могут игнорировать системные настройки сети. Перед тем как перейти к следующему разделу проверьте запущен ли в вашей системе systemd-resolved: $ resolvectl status Если в ответ получите сообщение ниже, значит в системе не настроен systemd-resolved: $ resolvectl status Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found. И наоборот, если на выходе видите что-то подобное, то systemd-resolved уже работает: Global LLMNR setting: yes MulticastDNS setting: yes DNSOverTLS setting: opportunistic DNSSEC setting: allow-downgrade DNSSEC supported: no Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 1.0.0.1 Включение и настройка systemd-resolved Отдельно устанавливать systemd-resolved не нужно, так как этот сервис является частью systemd. Всё что нужно сделать это запустить его и добавить в автозагрузку. Для включения данной службы введите команду ниже: $ sudo systemctl start systemd-resolved.service Далее нужно ввести следующую команду, чтобы добавить службу в автозапуск. $ sudo systemctl enable systemd-resolved.service И наконец нужно прописать DNS сервера, куда будет обращаться локальный сервер для разрешения имен. Есть много разных сервисов, но приведённые ниже самые быстрые, бесплатные и оба поддерживают DNSSEC и DoT: Google Public DNS 8.8.8.8 8.8.4.4 Cloudflare Public DNS 1.1.1.1 1.0.0.1 Для этого откройте конфигурационный файл systemd-resolved любым текстовым редактором: $ sudo nano /etc/systemd/resolved.conf Отредактируйте строку, которая начинается на: #DNS= И пропишите одну из вышеуказанных пар. Мы используем Cloudflare Public DNS: DNS=1.1.1.1 1.0.0.1 Сохраните изменения и перезапустите службу systemd-resolved: $ sudo systemctl restart systemd-resolved.service Итак, systemd-resolved уже запущен и готов для выполнения быстрых и безопасных DNS запросов, как только мы настроим систему соответствующим образом. Настройка системы для использования systemd-resolved Есть несколько путей настройки системы на использование локального DNS сервера. Мы рассмотрим два наиболее используемых метода. Первый – рекомендуемый метод, второй конфигурация в режиме совместимости. Разница в том, как будет обрабатываться файл /etc/resolv.conf. В файле /etc/resolv.conf содержатся IP адреса серверов разрешения имен, которые используются программами. Программы при необходимости разрешения доменного имени обращаются к этому файлу в поисках адресов серверов разрешения имен. Итак, первый метод конфигурации заключается в создании символьной ссылки на /run/systemd/resolve/stub-resolv.conf. В этом случае файл /etc/resolv.conf управляется службой systemd-resolved. Это может вызвать проблемы в том случае, если другие программы пытаются управлять файлом /etc/resolv.conf. Режим совместимости оставляет /etc/resolv.conf не тронутым, позволяя программам управлять им. В этом режиме, в настройках программ, управляющих файлом /etc/resolv.conf в качестве системного сервера разрешения имен должен быть указан IP 127.0.0.53. Конфигурация в рекомендуемом режиме При этом режиме конфигурация проводится вручную. Сначала нужно удалить или переименоваться оригинальный файл /etc/resolv.conf. Лучше переименовать, чтобы при необходимости можно было использовать информацию в нем. $ sudo mv /etc/resolv.conf /etc/resolv.conf.original Затем создаем символьную ссылку: $ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf И наконец перезапускаем службу systemd-resolved: $ sudo systemctl restart systemd-resolved.service Настройка в режиме совместимости В режиме совместимости, нужно убедиться, что локальный сервер разрешения имен system-resolved запущен и используется системными службами. Откройте файл /etc/resolv.conf любым редактором: $ sudo nano /etc/resolv.conf Удалите все строки, которые содержать ключевое слово nameserver и добавьте одну единственную строку: nameserver 127.0.0.53 Этот файл мажет быть изменён любой программой. Чтобы предотвратить это нужно настроить программы так, чтобы в качестве DNS они использовали адрес 127.0.0.53. Отладка systemd-resolved Посмотреть, как система выполняет DNS запросы после внесённых изменений сложно. Самый эффективный метод – это включить режим отладки для службы systemd-resolved, а затем просмотреть файл логов. systemd-resolved можно перевести в режим отладки созданием специального служебного файла, в котором содержатся настройки отладки. Делается это следующей командой: $ sudo systemctl edit systemd-resolved.service Вставьте в файл следующие строки: [Service] Environment=SYSTEMD_LOG_LEVEL=debug После этого служба systemd-resolved автоматический перезапуститься. Откройте второй терминал и просмотрите логи в journald: $ sudo journalctl -f -u systemd-resolved Строка, которая содержит слова “Using DNS server” показывает, какой DNS сервер используется для разрешения имён. В нашем случае это DNS сервера Cloudflare Using DNS server 1.1.1.1 for transaction 19995. Слова “Cache miss” в начале строки означает, что для данного домена нет закэшированной информации: Cache miss for example.com IN SOA И наконец слова “Positive cache” в начале строки означает, что systemd-resolved уже запрашивал информацию об этом домене и теперь ответы возвращает из кэша: Positive cache hit for example.com IN A Не забудьте отключить режим отладки, так как в это время создается большой файл логов. Сделать это можно командой: $ sudo systemctl edit systemd-resolved.service а затем удалить добавленные выше две строки. Использование защищенных DNS запросов systemd-resolved один из немногих DNS серверов, которые поддерживает DNSSEC и DNSoverTLS. Эта два механизма позволяют убедиться, что полученная DNS информация подлинная (DNSSEC) и он не был изменён по пути (DoT). Эти функции легко включаются редактированием основного конфигурационного файла system-resolved: $ sudo nano /etc/systemd/resolved.conf Измените файл следующим образом: DNSSEC=allow-downgrade DNSOverTLS=opportunistic Сохраните изменения и перезапустите службу systemd-resolved. $ sudo systemctl restart systemd-resolved.service Пока прописанные DNS сервера поддерживают эти две функции все DNS запросы будут защищены. DNS сервера Google и CloudFlare поддерживают эти механизмы защиты. Заключение Теперь ваша система будет выполнять DNS запросы быстро и эффективно даже если провайдер не работает достаточно быстро. Кроме этого, ваша цифровая жизнь лучше защищена новейшими механизмами защиты DNS запросов.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59