По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Прямо сейчас, пока ты читаешь эту статью, в серверной комнате организации А под толстым слоем пыли, окруженная множеством переплетенных проводов мигает разноцветными лампочками офисная АТС. Но давайте будем тише - дежурный IT - специалист, скорее всего спит, поставив переадресацию на мобильный телефон - а вдруг что - то сломается? Вообще, облака, на своем старте - наделали шума. Все начали задаваться вопросом - а зачем нам сервер в офисе, когда можно арендовать VPS/VDS/SaaS в облаке и “не париться”? В статье мы ответим на вопрос - почему одни компании выносят свою телефонию в облако или покупают услугу виртуальной АТС, тем самым создавая возможность поставить вендинговую машину или настольный теннис в серверной комнате, а другие, продолжают перебирать провода, протирать пыль с серверов и наслаждаться мерцанием цветовых серверных индикаторов от офисной АТС. Бюджет: сравниваем облако и размещение в офисе Первое, что стоит спросить себя - а как мы будем платить за АТС? Что для нас важно, а что нет? Мы, как интегратор, все чаще сталкиваемся с тем, что в компаниях (SMB) идет сокращение бюджета на IT и соответствующие отделы находят выходы из этой ситуации. С точки зрения локальной (офисной) АТС - далее мы будем называть ее порой “on-premise” решение (говоря так, мы чувствуем себя немного круче), IT - отдел экономит деньги ежемесячной оплате хосту (SaaS платформе, которая дает вам услугу виртуальной АТС). Но эта экономия реальна только в том случае, если вы не меняете аппаратные компоненты сервера с АТС. В таком случае модель вы платите только за услуги провайдера, электричество и заработную плату IT’шнику. Модель “купил - запитал - работает, не трожь” работает, более чем. Однако, в случае выхода из строя того или иного компонента, компания несет определенного рода дополнительные расходы. Отметим, опять же, на нашем опыте - случается это редко. Современные сервера имеют высокое качество комплектующих, и если вы не планируете поливать сервера водой, обдавать из огнемета или выставлять на улице - скорее всего, данная неприятность вам не грозит. Не менее важный фактор - обновление ПО. Проблема в том, что если вы обновляете программное обеспечение офисной “on-premise” (да - да, мы же предупреждали) АТС, есть риск выхода из строя. Опять же, данная проблема решается простым резервированием, так называемой отказоустойчивостью, по принципу Active - Standby (один сервер активен, а второй в резерве и всегда готов выйти в активную роль). Этот нюанс требует дополнительной проработки, а следовательно, дополнительных денежных затрат. Теперь про масштабируемость. В случае, если проснувшись в один прекрасный день вы осознаете, что ваш бизнес вырос в разы (вы сходили на бизнес - тренинг, к шаману или проделали магический обряд), то офисные локально размещенные станции масштабируются несколько сложнее и затратнее, чем виртуальные. Это отражается на деньгах и стоимости масштабирования. Тут есть важный пункт - офисная АТС гораздо более гибка, чем виртуальная. Дело в том, что виртуальная АТС дается вам в неком готовом контейнере предустановок, где SaaS платформа редко дает возможность доработки станции. Да, признаем, некоторые облачные АТС имеют API, но когда вопрос заходит о масштабном изменении логики работы АТС (кастомизация скриптами, например) - тут происходит коллапс. В этом плане офисные АТС явно выигрывают перед облачными, несмотря на стоимость затрат на эту самую кастомизацию. Просто сам факт ее возможность при быстром росте бизнеса - это преимущество (поверьте, знаем о чем говорим на опыте разных проектов). Редкие, но некоторые IT - отделы предпочитают облачную телефонию. Это более предсказуемо и снимает с них часть ответственности. Например, когда директор компании задает вопрос ITшнику почему не работает телефония, тот может смело спихнуть ответственность на виртуального хостера. Модернизация и апгрейд: витаем в облаках или в офисе? Тут пальму первенства заслуженно забирают облака. Дело в том, что если у вас в офисе живет on-premise АТС, так или иначе, рано или поздно вам придётся обновлять аппаратные компоненты сервера (процессор, оперативная память, наращивать мощность RAID массивов, тем самым увеличивая пространство для хранения данных). Это происходит по двум причинам: растёт нагрузка на сервер и текущие мощности уже не справляются, или обновление программного обеспечения требует более производительных комплектующих. При облачном размещении таких проблем нет - ваш хост автоматически наращивает мощности виртуальной машины, внутри которой живет ваша АТС. Это, безусловно, сказывается на мощности, но выходит дешевле покупки комплектующих под локальных сервак. Кстати про обновление - в случае решения, размещённого в вашем офисе, обновление ПО производят ваши ITшники, тогда как при размещении в облаке, хост сам обновляет ПО и раскатывает их на боевую среду. Интеграция телефонии с внешними системами Любителям on-premise решений посвящается. Откиньтесь на диване поудобнее - в этой главе уже есть победитель. И это не облако. Дело в том, что с ростом компании, уровень технологичности неизбежно повышается. Новые направления деятельности и увеличение потока клиентов обязывают связать ИТ - узлы в единую экосистему: интеграция телефонии и CRM, справочниками, базами данных, звонки по нажатию, триггерный автоматический обзвон, предиктивный дайлер и прочие. Все эти “хотелки” так или иначе требуют доработки вашей станции, так как интеграцию со всем на свете разработчики облачный виртуальных АТС предусмотреть не могут, а открыть исходный код и раздвинув горизонт кастомизации до бесконечности, рискуют получить уязвимости в безопасности. Именно по этой причине, офисная коробка дает больше. Например: вы хотите сделать маршрутизацию на базе гороскопа клиента. В вашей CRM есть номер телефона клиента, имя и его дата рождения. При входящем звонке, телефония “смотрит” в вашу CRM и видит месяц рождения клиента (по номеру, с которого он звонит). Кастомная прослойка понимает - он рыба, а рыбам, сегодня не рекомендуется иметь деловых отношений. И на базе этого решения офисная телефонная станция терминирует вызов. Как вам? Пожалуй, надо признать, пример весьма спорный. Но посыл понятен - коробка в офисе даст больший пул возможностей, а облако, максимум, обрезанный API. Катастрофы: коробки или облако? В офисе над вами прорвало трубу и залило серверную (мы реально встречали такие кейсы). Сервера вышли из строя, не работает ничего. Есть две новости, начнем с хорошей: Сервер был на гарантии и имеется контракт на горячую замену от интегратора; Сервера больше нет. Несмотря на контракт горячей замены, просто в минимум 24 часа вам гарантирован (если не реализована схема отказоустойчивости с географически распределенными серверами по ЦОДам). В облаке, как правило, SaaS дает вам гарантию работоспособности от 90%. Облачная вычислительная мощность живет в разных ЦОДах, при отказе аппаратного сервера, виртуальная машина с вашей ВАТС переедет на другой аппаратный сервер за сотые доли секунды. Что неплохо. Тут, пожалуй, для SMB компании первенство мы отдадим облаку. Итоги Как облака, так и размещенные в офисе решения имеют свои преимущества. Если курс вашей компании на безграничную кастомизацию, интеграцию всех ИТ - систем между собой для создания экосистемы и амбициозные бизнес - процессы, у вас есть грамотный IT - специалист, то выбирайте коробку, которую вы разместите в офисе. Если вы не хотите проблем с сервером, обслуживанием, вы малый бизнес, у вас нет своего IT’шника в штате и хотите рабочую телефонию с минимумом головной боли - облако подойдет под ваши требования.
img
Привет, бро! В статье расскажем в чем разница между RIPv1 (Routing Information Protocol Version 1) и его продолжение RIPv2. Погнали? Про Routing Information Protocol Version 1 (RIPv1) Прямо и по пунктам: RIPv1 это Distance-Vector протокол. Если переводить на русский - дистанционно-векторный. ; Distance vector routing - так называемая дистанционно-векторная маршрутизация, главный принцип которой основан на вычислении специальных метрик, которые определяют расстояние (количество узлов) до сети назначения RIPv1 это classfull протокол. Это означает, что он не отправляет маску подсети в апдейтах маршрутизации; RIPv1 не поддерживает VLSM (Variable Length Subnet Masking); VLSM (Variable Length Subnet Masking) - метод эффективного использования IP – адресации, который избавляет от привязки к классу сети (класс A, класс B, класс C). VLSM позволяет дробить подсеть на подсеть и так далее. Тем самым, мы можем эффективно использовать адресное пространство согласно реальных потребностей, а не класса сети; RIPv1 поддерживает максимум 15 хопов! Это означает, что любой маршрутизатор, который расположен от вас в больше, чем 15 узлов (маршрутизаторов) будет отмечен как недоступный; Раз в 30 секунд RIPv1 отправляет широковещательные апдейты маршрутизации – каждый узел должен принять и обработать этот апдейт; Первая версия RIP не поддерживает авторизация апдейтов маршрутизации – это означает, что потенциально, роутер может обновить таблицу маршрутизации от любого источника; Вот такой он, RIP первой версии. Двигаем дальше и посмотрим, а на что способен его брат – RIP второй версии? Про Routing Information Protocol Version 2 (RIPv2) RIPv2 это гибридный протокол. Он реализован на базе Distance-Vector, но так же поддерживает часть алгоритмов Link State маршрутизации, то есть, может отслеживать состояние каналов; Link State routing - отслеживает состояние каналов и отправляет LSA (Link-state advertisement) пакеты, в которых рассказывает о состоянии своих каналов. Примером link state протокола маршрутизации является OSPF RIPv2 - classless протокол. В отличие от своего старшего брата первой версии, второая версия умеет отправлять маску подсети в апдейтах маршрутизации; RIPv2 поддерживает VLSM!; RIPv2, как и RIPv1 поддерживает максимум 15 хопов; RIPv2 отправляет мультикаст сообщения об апдейтах на адрес 224.0.0.9. Это уменьшает нагрузку на сеть и в первую очередь на узлы, на которых не запущен RIP; Вторая версия RIP поддерживает аутентификацию апдейтов маршрутизации. Это значит, что теперь нельзя будет подсунуть ложный апдейт роутеру (в целом, этим могли пользоваться злоумышленники) – только авторизированные источники;
img
Если Вы не раз сталкивались с большими списками доступа и/или входящими в них object-группами, то наверняка уже задавались вопросом, существует ли инструмент, позволяющий определить, пропустит ли access-лист некий заданный трафик и вообще, какие строки имеют к этому отношение. Конечно, такие инструменты существуют и полностью или частично решают перечисленные задачи. Однако, эти инструменты как правило являются частью функционала больших "комбайнов" управления сетью, 90% функционала которых Вас не интересует. Чтобы продолжить, необходимо скачать утилиту ACL check Безусловно, никто не запрещает использовать регулярные выражения для поиска определённых строк списка доступа прямо в консоли сетевого устройства. Но данный метод предоставит очень поверхностный результат. Например, он не отобразит доступ хоста, попадающего в сетевую маску или порт, попадающий под диапазон. Тем более, таким образом нельзя отобразить все существующие доступы между двумя заданными узлами/сетями. Знающий сетевой администратор осведомлён о безрезультативности метода простого парсинга access-листа в таких ситуациях. Данная небольшая утилита создана именно для этого - найти строки access-листа, разрешающие или запрещающие определённый сетевой трафик. И даже более - выявить все строки, имеющие отношение к доступам между интересующими узлами или сетями. Идея использования проста: Вы задаёте критерий, а программа находит строки access-листа, которые ему удовлетворяют. При этом, сам критерий выглядит как строка access-листа, но без использования оператора "permit" или "deny". Если регулярно добавлять сетевые правила в access-лист без должной проверки их существования, то списки доступа могут содержать большое количество избыточных правил. Чтобы навести порядок в таких access-листах, в данной программе реализован функционал анализа списков доступа на избыточность. Вы можете выявить ненужные строки и освободить ресурсы оборудования. Для анализа ACL с object-группами программе необходимо указать состав object-групп. Вывод ACL будет предоставлен в развёрнутом виде. У нас есть нужные для изучения листов доступа статьи: Стандартные листы контроля доступа (ACL) Расширенные листы контроля доступа (Extended ACL) Интерфейс программы Поле ввода access-листа Поле ввода object-групп Кнопка распознавания access-листа Поле вывода access-листа в детальном виде Однострочное поле ввода условия Многострочный список ввода условий Кнопка прямой проверки Кнопка обратной проверки Поле результата проверки Шкала позиционирования поля детальных результатов (11) по отношению ко всему ACL Поле просмотра детальных результатов проверки Кнопка анализа ACL на конфликты и избыточность Кнопка сортировки строк ACL по различным критериям Маркер текущего активного условия в многострочном списке (6) Шкала сокращённого обозначения результатов проверки условий многострочного списка Переключатель типа маски для различного типа сетевого устройства Переключатель алгоритма проверки адресов источника и назначения Активация режима игнорирования строк ACL с ICMP протоколом в режиме частичного совпадения адресов Меню выбора вариантов CLI команд в составе с именем ACL Вывод object-групп, используемых в распознанном ACL Вывод списка известных программе именованных протоколов, а также типов и кодов ICMP Поле вывода ошибок, возникающих в процессе распознавания ACL Основные шаги Исходный access-list необходимо скопировать в поле 1. Если он содержит object-группы, то их состав необходимо скопировать в поле 2. ACL и object-группы можно копировать как с конфигурации устройства (“show running-config”, “show startup-config”), так и по прямым командам “show access-lists”, “show object”. Ниже приведён пример результата команды “show running-config”, допустимого для использования в поле 1: ip access-list extended ACL permit icmp host 172.16.0.6 host 172.21.0.6 permit ip host 172.16.0.6 host 172.21.0.1 permit tcp host 192.168.8.15 range 1024 65534 host 192.168.66.47 permit tcp 192.168.8.0 0.0.0.255 eq 22 1521 3389 addrgroup ADMIN_BSD permit tcp host 192.168.8.12 eq 1521 192.168.83.20 0.0.0.1 Тот же access-list по команде “show access-lists”: Extended IP access list ACL 10 permit icmp host 172.16.0.6 host 172.21.0.6 20 permit ip host 172.16.0.6 host 172.21.0.1 (32 matches) 30 permit tcp host 192.168.8.15 range 1024 65534 host 192.168.66.47 40 permit tcp 192.168.8.0 0.0.0.255 eq 22 1521 3389 addrgroup ADMIN_BSD (1 match) 50 permit tcp host 192.168.8.12 eq 1521 192.168.83.20 0.0.0.1 Пример результата команды “show running-config”, допустимого для использования в поле 2: object-group ip address ADMIN_BSD host-info 10.237.92.131 host-info 10.22.145.132 host-info 10.22.145.136 host-info 10.22.145.141 Содержимое вывода команды “show object-group”: IP address object group ADMIN_BSD host 10.237.92.131 host 10.22.145.132 host 10.22.145.136 host 10.22.145.141 Также допустимы и другие форматы object-групп. Пример допустимого фрагмента команды “show running-config”: object-group network Servers host 10.15.12.5 host 10.15.5.11 host 10.15.4.2 host 10.15.7.34 object-group service Ports1 tcp-udp eq domain tcp-udp eq 88 udp range 3268 3269 tcp gt 49151 Пример того же фрагмента команды “show object-group”: Network object group Servers host 10.15.12.5 host 10.15.5.11 host 10.15.4.2 host 10.15.7.34 Service object group Ports1 tcp-udp eq domain tcp-udp eq 88 udp range 3268 3269 tcp gt 49151 После копирования ACL и object-групп необходимо нажать кнопку 3. В результате access-list будет распознан и отображён в развёрнутом виде (в случае использования object-групп) в поле 4. Если на этапе распознавания возникли ошибки, то они будут отображены в поле 22. Если номер строки конечного access-листа дополнен ‘0’, это означает, что данная строка получена из object-группы. Если access-лист скопирован вместе с его заголовком, то активируется кнопка 19, позволяющая использовать команды конфигурирования, содержащие имя access-листа. После распознавания ACL необходимо в поле 5 ввести условие для поиска интересуемого нас доступа и нажать кнопку 7. Результат поиска доступа отобразится в поле 9. В случае наличия доступа более детальная информация появится в поле 11. Вызов контекстного меню “Показать результат” по правой кнопке мыши на поле 11 позволит отобразить строки ACL, удовлетворяющие условию поиска. Проверка существования доступа между заданными узлами по определённому порту Предположим, нас интересует существование доступа с хоста 192.168.1.2 по порту TCP 1521 на сервер 192.168.2.2 в следующем списке доступа: ip access-list extended ACL 10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522 20 permit tcp host 192.168.1.2 any 30 permit tcp host 192.168.1.3 any eq 1521 Копируем access-лист в поле 1 и нажимаем кнопку 3. В поле 5 вводим следующее условие: tcp host 192.168.1.2 gt 1023 host 192.168.2.2 eq 1521 Нажимаем кнопку 7 или клавишу “Enter”. В поле 9 отобразится результат: Разрешено в строке 1: 10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522 Имеются ещё совпадения Здесь значение “1:” является результатом сквозной нумерации всех строк конечного (распознанного) ACL, а “10” – номер строки в исходном ACL. Надпись “Имеются ещё совпадения” означает, что в ACL присутствуют и другие строки, в которых теоретически может сработать наше условие. Результаты совпадения правил можно просмотреть в поле 11. Если на этом поле вызвать контекстное меню (правой кнопкой мыши) и выбрать пункт “Показать результат”, то появится дополнительное окно с выборкой сработавших строк ACL. Определение узлов заданной сети, к которым имеется доступ по определённому порту Рассмотрим ситуацию, когда требуется выяснить, к каким серверам сети 192.168.2.0 /24 открыт доступ по SSH (TCP 22). Список доступа следующий: ip access-list extended ACL 10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522 20 permit tcp any 192.168.2.0 0.0.0.3 eq 22 3389 30 permit tcp host 192.168.1.3 host 192.168.2.254 40 permit tcp host 192.168.1.10 any Копируем access-лист в поле 1 и нажимаем кнопку 3. Ставим переключатель 17 в положение “частичное по src и dst”. Алгоритм будет учитывать строки ACL, в которых IP-адреса источника и назначения полностью или частично попадают в диапазон адресов, указанный в условии. В поле 5 вводим следующее условие: tcp any gt 1023 any eq 22 Нажимаем кнопку 7 или клавишу “Enter”. В поле 9 отобразится результат Блок Результаты совпадения правил можно просмотреть в поле 11. Если на этом поле вызвать контекстное меню (правой кнопкой мыши) и выбрать пункт “Показать результат”, то появится дополнительное окно с выборкой сработавших строк ACL. Символ “?” в этом окне означает частичное совпадение по адресам. Определение доступов, открытых между определёнными узлами Выясним, какие доступы открыты от узла 192.168.1.10 к узлу 192.168.2.254 в следующем ACL: ip access-list extended ACL 10 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 range 1521 1522 20 permit tcp any 192.168.2.0 0.0.0.3 eq 22 3389 30 permit tcp host 192.168.1.3 host 192.168.2.254 40 permit tcp host 192.168.1.10 any Копируем access-лист в поле 1 и нажимаем кнопку 3. Ставим переключатель 17 в положение “частичное по src и dst”. В поле 5 вводим следующее условие: ip host 192.168.1.10 host 192.168.2.254 Метод состоит в том, что заданное условие рассматривается как access-лист, а каждая строка исходного ACL как отдельное условие. Другими словами, условие и ACL меняются ролями. Кнопка (8), решающая эту задачу, называется “Обратная проверка”. Нажимаем кнопку 8 или комбинацию “Ctrl-Enter”. В поле 9 отобразится результат: Блок Результаты совпадения правил можно просмотреть в поле 11. Если на этом поле вызвать контекстное меню (правой кнопкой мыши) и выбрать пункт “Показать результат”, то появится дополнительное окно с выборкой сработавших строк ACL. Символ “?” в этом окне означает частичное совпадение по адресам. Важным требованием при такой проверке является необходимость установки переключателя 17 в среднее положение. Многострочный список условий (поле 6) Список условий (6) предназначен для ввода нескольких условий и последовательной их проверки. Для ввода каждого следующего условия (новой строки) предусмотрена комбинация “Shift-Enter”. Для проверки условия из списка необходимо установить на него курсор и нажать кнопку 7 (Enter) или 8 (Ctrl-Enter). На шкале 15 напротив строки запрошенного условия отобразится соответствующий символ результата. Он сохранится до изменения условия в этой строке списка. Сортировка (кнопка 13) Распознанный access-list, выведенный в развёрнутом виде в поле 4, можно упорядочить по различным критериям и их комбинации. При нажатии на кнопку сортировки (13) открывается дополнительное окно. 1-7 – Кнопки включения элементов в цепь сортировки 8 – Отображение исходных номеров строк 9 – Режим группирования результатов сортировки Каждый следующий критерий в цепочке выбирается соответствующей кнопкой. Рассмотрим следующий список доступа: 1 permit udp 192.168.8.0 0.0.0.255 host 192.168.38.24 eq syslog 2 permit tcp 192.168.8.0 0.0.0.255 host 192.168.38.23 eq 1514 3 permit tcp 192.168.8.0 0.0.0.255 host 192.168.38.24 eq 1514 4 permit tcp 192.168.8.0 0.0.0.255 host 192.168.38.23 eq 4041 5 permit tcp 192.168.8.0 0.0.0.255 host 192.168.12.26 6 permit ip 192.168.8.0 0.0.0.255 192.168.41.0 0.0.0.255 7 permit ip 192.168.8.0 0.0.0.255 host 192.168.41.31 Чтобы упорядочить эти строки сначала по IP адресу назначения, а затем по протоколу, необходимо нажать последовательно кнопки 5 и 1: Цифры в круглых скобках на соответствующих кнопках указывают позицию элемента в цепочке сортировки. При отключении элемента из цепочки также исключаются все элементы с номерами выше отключенного. Анализ на конфликты и избыточность (кнопка 12) Кнопка “Анализ” (12) становится активной после распознания access-листа. Её нажатие запускает процесс анализа строк access-листа на конфликты и избыточность. Конфликтующей является строка access-листа, которая никогда не сработает из-за вышестоящего правила противоположного значения (“deny” после “permit” или наоборот). К примеру, загрузим следующий ACL: 10 permit icmp any any 20 permit tcp host 10.15.2.11 eq 1521 host 10.15.1.10 30 deny tcp 10.15.2.0 0.0.0.255 10.15.0.0 0.0.31.255 40 permit udp 10.15.2.0 0.0.0.255 host 10.19.9.232 50 permit udp 10.15.2.0 0.0.0.255 host 10.19.9.120 eq syslog 60 permit tcp host 10.15.2.11 eq 1521 host 10.15.7.11 Распознаем его (кнопка 3) и нажмём кнопку “Анализ” (12). Программа предупредит нас о имеющихся конфликтах: Кнопка “Да” откроет окно с результатами анализа, включающими только конфликты: Если нажать кнопку ‘Нет’, то откроется окно, включающее как конфликтующие, так и избыточные правила. Рассмотрим следующий access-list: 10 permit icmp any any 20 permit tcp host 192.168.1.10 host 192.168.2.20 eq 22 30 permit tcp host 192.168.1.10 host 192.168.2.20 40 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 Анализ такого ACL отобразит следующие результаты: Здесь жирным шрифтом выделены строки, если имеются другие правила, попадающие под их действие. Остальные строки (обычный шрифт) являются производными правилами. Установив курсор на определённой строке, удерживая нажатой клавишу “Ctrl”, получим детальную информацию в нижней части окна: Поле результатов Поле детализации выбранного правила Иерархический вид детализации В данном случае правило 2 является производным от правила 3. В свою очередь, правило 3 входит в правило 4. Визуально уровень такой вложенности можно определить по отступам строки вправо или выбрать иерархический вид (3). При иерархическом виде производные правила будут выведены ниже строк, в которые они входят. Можно выделить диапазон интересуемых строк в поле 1 и вызвать контекстное меню правой кнопкой мыши, в котором выбрать варианты удаления избыточных строк. Следует учитывать намеренное чередование операторов “permit” и “deny” в одном ACL для его упрощения. В таких случаях следует анализировать ACL частями. Например, до и после операторов “deny”. Либо анализировать полностью, но дополнительно обращать внимание на порядок следования конфликтующих строк в ACL и не удалять такие производные строки из исходного ACL. Опции запуска программы Предусмотрены следующие опции запуска exe-файла: /h, /?, /help – вызов справки параметров запуска /l (rus) – выбор языка /nm – включение режима “netmask” /pm (and,or) – выбор режима совпадения адресов /skipicmp – включение режима “игнорировать ICMP при частичном совпадении”.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59