По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
С момента появления вычислительной техники и интернета компьютерная сеть играет жизненно важную роль для обмена ресурсами и информацией как внутри организации, так и на глобальном уровне. Люди, которым поручено контролировать эти сети, называются сетевыми инженерами или сетевыми администраторами. Сетевые инженеры и администраторы используют различные инструменты для проектирования, мониторинга или анализа компьютерных систем. Что бы не экспериментировать на реальных сетях (что чревато сбоем или выходом из строя сетевой инфраструктуры) системные администраторы для этого используют инструменты сетевого моделирования. Сегодня мы рассмотрим 5 лучших инструментов сетевого моделирования, которые могут помочь вам в проектировании и улучшении производительности системы. После изучения нашего списка инструментов сетевого моделирования, вы сможете выбрать себе наиболее оптимальное программное обеспечение для эмуляции сетей. Данное ПО позволит решить проблемы и провести тесты, которые невозможно применить на реально-существующих сетях из-за риска нарушить нормальное функционирование. GNS3 GNS3: это одна из самых популярных программ эмуляции сети, которая позволяет наблюдать взаимодействие сетевых устройств в различных топологиях сетей. Это программное обеспечение, которое является интегрированным сегментом в международной сети обучения сертификации. Одного такого факта достаточно, чтобы показать, насколько современным и всеобъемлющим является этот программный инструмент, когда речь заходит об успешном моделировании сети. Он прост в установке и реализации, что делает его популярным выбором как на любительском, так и на профессиональном уровне. Cisco Packet Tracer Cisco Packet Tracer: одна из основных причин, по которой этот инструмент моделирования сети, разработанный CISCO systems, занял второе место в ТОП-5, заключается в том, что он кросс-платформенный. Этот уникальный инструмент моделирования поможет вам не только построить топологию сети, но и воспроизвести ее в современных компьютерных сетях. Cisco PT позволяет имитировать соответствующую конфигурацию через CLI. А еще Packet Tracer отлично подходит для VoIP EVE-NG EVE-NG: Emulated Virtual Environment Next Generation or EVEN-NG- это единственный в своем роде многопользовательский сетевой симулятор, предназначенный для небольших предприятий и частных лиц. Реализация этого инструмента моделирования виртуальной сети является как платным, так и бесплатным. Бесплатная версия имеет ограничение в 63 узла на лабораторию. Для виртуализации, связывания и настройки сетевых устройств нет необходимости загружать и устанавливать дополнительное приложение помимо сервера. Все проектирование, подключение и управление сетевыми топологиями можно легко выполнить с помощью интегрированного HTML5- клиента. Важным фактором, который делает EVE-NG одним из лучших инструментов моделирования сети, является то, что приложение экономит время, позволяя вам вносить изменения в топологию сетей во время их одновременного запуска. Кроме того, она подходит как для Ethernet, так и для последовательных интерфейсов. Boson NetSim Boson NetSim: это приложение, имитирующее сетевые коммутаторы и маршрутизаторы Cisco. Одна из ключевых особенностей этого инструмента моделирования заключается в том, что он поставляется вместе со всеми лабораторными работами от Boson, и нет необходимости загружать отдельные файлы и импортировать их позже в NetSim. Весь процесс загрузки, отделки и сортировки лабораторных работ осуществляется в самом приложении. Построение и загрузка топологий сетей могут быть легко выполнены с помощью приложения. И наоборот, вы также можете просматривать топологии, загруженные другими участниками сообщества, и загружать их в приложение. Функции терминала чрезвычайно реалистичны. Также стоит отметить, что Boson NetSim заимствует интуитивно понятную систему настройки от GNS3. Дополнительные модули (называемые надстройками) могут быть включены для настройки сетевого устройства. Когда устройство подключено к топологии сети, программное обеспечение спрашивает, какие именно модули вы хотите добавить. VIRL VIRL: Virtual Internet Routing Lab или VIRL- это эмулятор виртуальной сети от Cisco, который был специально разработан для удовлетворения потребностей образовательных учреждений и частных лиц. Будучи одним из топ-5 инструментов моделирования сетей в 2020 году, он поставляется в высоко масштабируемых вариантах, специально разработанных для средних и крупных предприятий. VIRL, поддерживающий клиент-серверную модель и сервер, могут быть легко установлены на виртуальной машине под управлением ESXi от VMware или даже на "голом железе" сервера. Использование инструмента моделирования VIRL позволяет вам получить доступ к целому ряду лицензированных образов программного обеспечения Cisco, таких, как NX-Osv, IOS-Xrv, ASAv и IOSv (как второго уровня, так и третьего уровня). Хорошо то, что эти образы можно легко извлечь из сервера VIRL и установить поверх других эмуляторов, таких как EVE-NG и GNS3. Кроме того, VIRL ввела функцию, известную как AutoNetKit, которая облегчает базовые функции конфигурации на узлах для автоматического заполнения всей топологии сети. Эта функция очень эффективна в том случае, если вам необходимо быстро оценить модель поведения конкретной технологии или, практически воссоздать всю существующую сеть. Подведем итоги Приведенный выше список, безусловно, является кратким, но он определенно является всеобъемлющим для личных целей. Цель этого списка состоит не только в том, чтобы познакомить вас со списком инструментов моделирования сети входящих топ- 5, но и познакомить вас с возможностями специализированных функций этих инструментов.
img
Предыдущая статья из цикла про соответствие пакетов в IP ACL. Обратные маски, такие как значения dotted-decimal number (DDN), фактически представляют собой 32-разрядное двоичное число. Как 32-разрядное число, маска WC фактически направляет логику маршрутизатора бит за битом. Короче говоря, бит маски WC (wildcard), равный 0, означает, что сравнение должно выполняться как обычно, но двоичный 1 означает, что бит является подстановочным знаком и может быть проигнорирован при сравнении чисел. Кстати, наш калькулятор подсетей показывает и сам считает WC (wildcard) маску. Вы можете игнорировать двоичную маску WC. Почему? Что ж, обычно мы хотим сопоставить диапазон адресов, которые можно легко идентифицировать по номеру подсети и маске, будь то реальная подсеть или сводный маршрут, который группирует подсети вместе. Если вы можете указать диапазон адресов с помощью номера подсети и маски, вы можете найти числа для использования в вашем ACL с помощью простой десятичной математики, как описано далее. Если вы действительно хотите знать логику двоичной маски, возьмите два номера DDN, которые ACL будет сравнивать (один из команды access-list, а другой из заголовка пакета), и преобразуйте оба в двоичный код. Затем также преобразуйте маску WC в двоичную. Сравните первые два двоичных числа бит за битом, но также игнорируйте любые биты, для которых маска WC случайно перечисляет двоичный 1, потому что это говорит вам игнорировать бит. Если все биты, которые вы проверили, равны, это совпадение! Нахождения правильной обратной маски, соответствующей подсети Во многих случаях ACL должен соответствовать всем хостам в определенной подсети. Чтобы соответствовать подсети с помощью ACL, вы можете использовать следующие сочетания: Используйте номер подсети в качестве исходного значения в команде access-list. Используйте обратную маску, полученную путем вычитания маски подсети из 255.255.255.255. Например, для подсети 172.16.8.0 255.255.252.0 используйте номер подсети (172.16.8.0) в качестве параметра адреса, а затем выполните следующие вычисления, чтобы найти обратную маску: Продолжая этот пример, завершенная команда для той же подсети будет следующей: access-list 1 permit 172.16.8.0 0.0.3.255 Соответствие любому/всем адресам В некоторых случаях вам может понадобиться одна команда ACL для сопоставления всех без исключения пакетов, которые достигают этой точки в ACL. Во-первых, вы должны знать (простой) способ сопоставить все пакеты с помощью ключевого слова any. Что еще более важно, вам нужно подумать о том, когда сопоставить все без исключения пакеты. Во-первых, чтобы сопоставить все пакеты с помощью команды ACL, просто используйте ключевое слово any для адреса. Например, чтобы разрешить все пакеты: access-list 1 permit any Итак, когда и где вы должны использовать такую команду? Помните, что все ACL Cisco IP заканчиваются неявным отрицанием любой концепции в конце каждого ACL. То есть, если маршрутизатор сравнивает пакет с ACL, и пакет не соответствует ни одному из настроенных операторов, маршрутизатор отбрасывает пакет. Хотите переопределить это поведение по умолчанию? Настроить permit any в конце ACL. Вы также можете явно настроить команду для запрета всего трафика (например, access-list 1 deny any) в конце ACL. Почему, когда та же самая логика уже находится в конце ACL? Что ж, ACL показывает счетчики списка для количества пакетов, соответствующих каждой команде в ACL, но нет счетчика для этого не явного запрета любой концепции в конце ACL. Итак, если вы хотите видеть счетчики количества пакетов, совпадающих с логикой deny any в конце ACL, настройте явное deny any. Внедрение стандартных IP ACL В этой лекции уже представлены все этапы настройки по частям. Далее суммируются все эти части в единую конфигурацию. Эта конфигурация основана на команде access-list, общий синтаксис которой повторяется здесь для справки: access-list access-list-number {deny | permit} source [source-wildcard] Этап 1. Спланируйте локацию (маршрутизатор и интерфейс) и направление (внутрь или наружу) на этом интерфейсе: Стандартные списки ACL должны быть размещены рядом с местом назначения пакетов, чтобы они случайно не отбрасывали пакеты, которые не следует отбрасывать. Поскольку стандартные списки ACL могут соответствовать только исходному IP-адресу пакета, идентифицируйте исходные IP-адреса пакетов по мере их прохождения в направлении, которое проверяет ACL. Этап 2. Настройте одну или несколько команд глобальной конфигурации списка доступа для создания ACL, учитывая следующее: Список просматривается последовательно с использованием логики первого совпадения. Действие по умолчанию, если пакет не соответствует ни одной из команд списка доступа, - отклонить (отбросить) пакет. Этап 3. Включите ACL на выбранном интерфейсе маршрутизатора в правильном направлении, используя подкоманду  ip access-group number {in | out}. Далее рассмотрим несколько примеров. Стандартный нумерованный список ACL, пример 1 В первом примере показана конфигурация для тех же требований, что и на рисунках 4 и 5. Итак, требования для этого ACL следующие: Включите входящий ACL на интерфейсе R2 S0/0/1. Разрешить пакеты, приходящие от хоста A. Запретить пакеты, приходящие от других хостов в подсети хоста A. Разрешить пакеты, приходящие с любого другого адреса в сети класса A 10.0.0.0. В исходном примере ничего не говорится о том, что делать по умолчанию, поэтому просто запретите весь другой трафик. В примере 1 показана завершенная правильная конфигурация, начиная с процесса настройки, за которым следует вывод команды show running-config. R2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)# access-list 1 permit 10.1.1.1 R2(config)# access-list 1 deny 10.1.1.0 0.0.0.255 R2(config)# access-list 1 permit 10.0.0.0 0.255.255.255 R2(config)# interface S0/0/1 R2(config-if)# ip access-group 1 in R2(config-if)# ^Z R2# show running-config ! Lines omitted for brevity access-list 1 permit 10.1.1.1 access-list 1 deny 10.1.1.0 0.0.0.255 access-list 1 permit 10.0.0.0 0.255.255.255 Во-первых, обратите внимание на процесс настройки в верхней части примера. Обратите внимание, что команда access-list не изменяет командную строку из приглашения режима глобальной конфигурации, поскольку команда access-list является командой глобальной конфигурации. Затем сравните это с выводом команды show running-config: детали идентичны по сравнению с командами, которые были добавлены в режиме конфигурации. Наконец, не забудьте указать ip access-group 1 в команде под интерфейсом R2 S0/0/1, который включает логику ACL (как локацию, так и направление). В примере 2 перечислены некоторые выходные данные маршрутизатора R2, которые показывают информацию об этом ACL. Команда show ip access-lists выводит подробную информацию только о списках ACL IPv4, а команда show access-lists перечисляет сведения о списках ACL IPv4, а также о любых других типах ACL, настроенных в настоящее время, например, списки ACL IPv6. Вывод этих команд показывает два примечания. В первой строке вывода в этом случае указывается тип (стандарт) и номер. Если существовало более одного ACL, вы бы увидели несколько разделов вывода, по одной на каждый ACL, каждая со строкой заголовка, подобной этой. Затем эти команды перечисляют счетчики пакетов для количества пакетов, которые маршрутизатор сопоставил с каждой командой. Например, на данный момент 107 пакетов соответствуют первой строке в ACL. Наконец, в конце примера перечислены выходные данные команды show ip interface. Эта команда перечисляет, среди многих других элементов, номер или имя любого IP ACL, включенного на интерфейсе для подкоманды интерфейса ip access-group. Стандартный нумерованный список ACL, пример 2 Для второго примера используйте рисунок 8 и представьте, что ваш начальник в спешке дает вам некоторые требования в холле. Сначала он говорит вам, что хочет фильтровать пакеты, идущие от серверов справа к клиентам слева. Затем он говорит, что хочет, чтобы вы разрешили доступ для хостов A, B и других хостов в той же подсети к серверу S1, но запретили доступ к этому серверу хостам в подсети хоста C. Затем он сообщает вам, что, кроме того, хостам в подсети хоста A следует отказать в доступе к серверу S2, но хостам в подсети хоста C должен быть разрешен доступ к серверу S2 - и все это путем фильтрации пакетов, идущих только справа налево. Затем он говорит вам поместить входящий ACL на интерфейс F0/0 R2. Если вы просмотрите все запросы начальника, требования могут быть сокращены до следующего: Включите входящий ACL на интерфейсе F0/0 R2. Разрешить пакеты от сервера S1, идущие к хостам в подсети A. Запретить пакетам с сервера S1 идти к хостам в подсети C. Разрешить пакетам с сервера S2 идти к хостам в подсети C. Запретить пакетам с сервера S2 идти к хостам в подсети A. Не было комментариев о том, что делать по умолчанию; используйте подразумеваемое отклонение всего по умолчанию. Как оказалось, вы не можете сделать все, что просил ваш начальник, с помощью стандартного ACL. Например, рассмотрим очевидную команду для требования номер 2: access-list 2 permit 10.2.2.1. Это разрешает весь трафик с исходным IP-адресом 10.2.2.1 (сервер S1). Следующее требование просит вас фильтровать (отклонять) пакеты, полученные с того же IP-адреса! Даже если вы добавите другую команду, которая проверяет исходный IP-адрес 10.2.2.1, маршрутизатор никогда не доберется до него, потому что маршрутизаторы используют логику первого совпадения при поиске в ACL. Вы не можете проверить и IP-адрес назначения, и исходный IP-адрес, потому что стандартные ACL не могут проверить IP-адрес назначения. Чтобы решить эту проблему, вам следует переосмыслить проблему и изменить правила. В реальной жизни вы, вероятно, вместо этого использовали бы расширенный ACL, который позволяет вам проверять как исходный, так и целевой IP-адрес. Представьте себе, что ваш начальник позволяет вам изменять требования, чтобы попрактиковаться в другом стандартном ACL. Во-первых, вы будете использовать два исходящих ACL, оба на маршрутизаторе R1. Каждый ACL разрешает пересылку трафика с одного сервера в эту подключенную локальную сеть со следующими измененными требованиями: Используя исходящий ACL на интерфейсе F0 / 0 маршрутизатора R1, разрешите пакеты с сервера S1 и запретите все остальные пакеты. Используя исходящий ACL на интерфейсе F0 / 1 маршрутизатора R1, разрешите пакеты с сервера S2 и запретите все остальные пакеты. Пример 3 показывает конфигурацию, которая удовлетворяет этим требованиям. access-list 2 remark This ACL permits server S1 traffic to host A's subnet access-list 2 permit 10.2.2.1 ! access-list 3 remark This ACL permits server S2 traffic to host C's subnet access-list 3 permit 10.2.2.2 ! interface F0/0 ip access-group 2 out ! interface F0/1 ip access-group 3 out Как показано в примере, решение с номером ACL 2 разрешает весь трафик с сервера S1, при этом эта логика включена для пакетов, выходящих из интерфейса F0/0 маршрутизатора R1. Весь другой трафик будет отброшен из-за подразумеваемого запрета all в конце ACL. Кроме того, ACL 3 разрешает трафик от сервера S2, которому затем разрешается выходить из интерфейса F0/1 маршрутизатора R1. Также обратите внимание, что решение показывает использование параметра примечания списка доступа, который позволяет оставить текстовую документацию, которая остается в ACL. Когда маршрутизаторы применяют ACL для фильтрации пакетов в исходящем направлении, как показано в Примере 2, маршрутизатор проверяет пакеты, которые он направляет, по списку ACL. Однако маршрутизатор не фильтрует пакеты, которые сам маршрутизатор создает с помощью исходящего ACL. Примеры таких пакетов включают сообщения протокола маршрутизации и пакеты, отправленные командами ping и traceroute на этом маршрутизаторе. Советы по устранению неполадок и проверке Устранение неполадок в списках ACL IPv4 требует внимания к деталям. В частности, вы должны быть готовы посмотреть адрес и обратную маску и с уверенностью предсказать адреса, соответствующие этим двум комбинированным параметрам. Во-первых, вы можете определить, соответствует ли маршрутизатор пакетам или нет, с помощью пары инструментов. Пример 2 уже показал, что IOS хранит статистику о пакетах, соответствующих каждой строке ACL. Вдобавок, если вы добавите ключевое слово log в конец команды access-list, IOS затем выдает сообщения журнала со случайной статистикой совпадений с этой конкретной строкой ACL. И статистика, и сообщения журнала могут помочь решить, какая строка в ACL соответствует пакету. Например, в примере 4 показана обновленная версия ACL 2 из примера 3, на этот раз с добавленным ключевым словом log. Внизу примера затем показано типичное сообщение журнала, в котором показано результирующее совпадение на основе пакета с исходным IP-адресом 10.2.2.1 (в соответствии с ACL) с адресом назначения 10.1.1.1. R1# show running-config ! lines removed for brevity access-list 2 remark This ACL permits server S1 traffic to host A's subnet access-list 2 permit 10.2.2.1 log ! interface F0/0 ip access-group 2 out R1# Feb 4 18:30:24.082: %SEC-6-IPACCESSLOGNP: list 2 permitted 0 10.2.2.1 -> 10.1.1.1, 1 Packet Когда вы впервые устраняете неисправности на ACL, прежде чем вдаваться в подробности логики сопоставления, подумайте, как об интерфейсе, на котором включен ACL, так и о направлении потока пакетов. Иногда логика сопоставления идеальна, но ACL был включен на неправильном интерфейсе или в неправильном направлении, чтобы соответствовать пакетам, настроенным для ACL. Например, на рисунке 9 повторяется тот же ACL, показанный ранее на рисунке 7. Первая строка этого ACL соответствует конкретному адресу хоста 10.1.1.1. Если этот ACL существует на маршрутизаторе R2, размещение этого ACL в качестве входящего ACL на интерфейсе S0/0/1 R2 может работать, потому что пакеты, отправленные хостом 10.1.1.1 - в левой части рисунка - могут входить в интерфейс S0/0/1 маршрутизатора R2. Однако, если R2 включает ACL 1 на своем интерфейсе F0/0 для входящих пакетов, ACL никогда не будет соответствовать пакету с исходным IP-адресом 10.1.1.1, потому что пакеты, отправленные хостом 10.1.1.1, никогда не войдут в этот интерфейс. Пакеты, отправленные 10.1.1.1, будут выходить из интерфейса R2 F0/0, но никогда не попадут в него только из-за топологии сети.
img
В этой статье рассмотрим как решить следующие неисправности: Виртуальная машина не может подключиться к сети Нет связи между сетью и одной виртуальной машиной Невозможно подключиться к сети Интернет Сбой подключения к или от одной виртуальной машины через TCP/IP Вы видите одну или более из ошибок: Destination Host Unreachable Network error: Connection Refused Network cable is unplugged Ping request could not find host (IP address/hostname). Please check the name and try again Unable to resolve target system name (IP address/hostname). Решение Убедитесь, что каждый из последующих шагов подходит для вашей среды. Шаги включают в себя инструкции для выполнения и ссылки на документы для подтверждения шагов и дополнительных корректирующих мер, если они потребуются. Шаги выстроены в наиболее подходящем порядке для выявления и решения проблем. Не пропускайте шаги. Проверьте, что имя или имена Port Group, связанные с сетевыми адаптерам(и) виртуальной машины, существует и задано правильно. Если нет, то исправьте это с помощью Edit Settings на виртуальной машине, проверьте есть ли галочка напротив Connected. Удостоверьтесь в отсутствии проблем с хранилищем или ресурсами, так как это может вызывать неполадки с сетью на виртуальной машине. Это можно проверить на консоли виртуальной машины в ESX/ESXi or Virtual Center/vCenter Server через VI/vSphere Client. Убедитесь, что виртуальный сетевой адаптер присутствует и подключён. Проверьте правильно ли настроена сеть в гостевой системе на виртуальной машине. Проверьте правильно ли работает стек TCP/IP. Если данная виртуальная машина была создана из физической системы, то следует убедиться в отсутствии скрытых сетевых адаптеров. Убедитесь, что vSwitch на достаточно портов для виртуальной машины. Убедитесь, что конфигурация IPSec виртуальной машины выполнена правильно и не повреждена. Наличие двух виртуальных сетевых интерфейсных карт (vNIC) на виртуальной машине поможет исключить проблемы с сетевой интерфейсной картой (NIC) и физической конфигурацией. Чтобы найти возможную проблему: Если политика балансировки загрузки в режиме Default Virtual Port ID на уровне vSwitch и vDS - оставьте одну виртуальную сетевую интерфейсную карту (vNIC) подключённой к vSwitch или vDS и протестируйте различные комбинации виртуальных(vNIC) и физических (pNIC) сетевых интерфейсных карт, чтобы найти виртуальную машину с отсутствующим соединением. Если политика балансировки загрузки в режиме IP Hash: Убедитесь, что порты физического коммутатора настроены как порт-канал. Прты, к которым подключены сетевые интерфейсные карты (NICs), кроме одного и переключайтесь между всеми портами, включая за раз только один порт. Обратите внимание на комбинации портов и сетевых интерфейсных карт (NIC) при которых виртуальные машины теряют соединение. Также вы можете проверить выходные данные о работе сети с помощью команды esxtop с параметром n, чтобы найти используемую виртуальной машиной физическую сетевую интерфейсную карту (pNIC). Попробуйте отключать порты физического свитча по одному, чтобы определить, когда виртуальная машина теряет подключение к сети. Это также исключает неправильные настройки физического порта(-ов).
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59