По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Настройка IPv4-адресации для удаленного доступа к устройствам Cisco Чтобы иметь возможность подключения к коммутатору по Telnet или SSH, а также использовать другие протоколы управления на основе IP (например, Simple Network Management Protocol или SNMP) функционировать должным образом, коммутатору требуется IP-адрес, а также настройки других сопутствующих параметров. IP-адрес не влияет на функциональную работу коммутатора. В этой части будут рассмотрены основные параметры IPv4-адресации, необходимые для настройки коммутатора, а затем будут приведены команды и примеры настроек. Коммутаторы могут быть настроены с параметрами IPv6-адресации. Настройки IPv4 и IPv6 аналогичны. Далее уделим основное внимание исключительно IPv4. Настройки IP-адресации узла и коммутатора Коммутатор нуждается в тех же настройках IP-адресации, что и компьютер с сетевым интерфейсом Ethernet (FastEthernet). Напомню, что каждый ПК имеет процессор. Этот процессор управляется специальной операционной системой для обработки сигналов и отправки их на сетевую карту. Компьютер имеет минимум оду сетевую карту Ethernet (NIC). Настройки сетевой карты ПК включают в себя: настройка статического или получаемого по DHCP IP-адреса сетевой карты.Коммутатор использует те же принципы, что и ПК, но за исключением того, что коммутатор использует виртуальную сетевую карту внутри устройства. Как и ПК, коммутатор имеет реальный процессор, работающий под управлением ОС (IOS). Коммутатор обладает множеством портов Ethernet (FastEthernet, GigEthernet), но в отличие от ПК, коммутатор не назначает IP-адрес управления какому-то конкретному порту или всем сразу. Коммутатор использует NIC концепцию (NIC-like), называемую коммутируемым виртуальным интерфейсом (SVI), или, чаще всего, именуемым интерфейсом VLAN, который действует как отдельная сетевая карта (NIC) коммутатора. Тогда настройки на коммутаторе сводятся к настройке IP-адресации VLAN. Пример настройки показан на рисунке: На рисунке изображен виртуальный ПК, подключенный к другим реальным узлам в сети через виртуальный интерфейс VLAN 1. IP-адрес интерфейса VLAN1-192.168.1.8; маска подсети 225.255.255.0 и подсеть VLAN 1 - 192.168.1.0. Виртуальный ПК и интерфейс VLAN1 являются частью коммутатора. Остальные узлы находятся за пределами коммутатора. Используя интерфейс VLAN 1 с настроенной IP-адресацией, коммутатор может отправлять и получать кадры на любом из портов VLAN 1. В коммутаторе Cisco, по умолчанию, все порты назначены во VLAN 1. В коммутаторах можно настроить большое количество VLAN, поэтому у системного администратора есть выбор, какой VLAN использовать. Таки образом IP-адрес управления не обязательно должен быть настроен именно на VLAN1 Коммутатору Cisco второго уровня (L2) задается только один IP-адрес для управления. Однако можно использовать любой VLAN, через который подключается коммутатор. Настройка включает: настройку т интерфейса VLAN с указанием его номера (например VLAN11) и присвоением соответствующего IP-адреса с маской подсети. Например, на рисунке показан коммутатор 2 уровня с несколькими физическими портами в двух различных VLAN (VLAN 1 и 2). На рисунке также показаны подсети, используемые в этих VLAN. Системный администратор может выбрать для использования передачи данных либо то, либо другое. На рисунке виртуальный ПК коммутатора соединен с другими системами вне устройства с помощью двух интерфейсов VLAN. Подсети виртуальных локальных сетей 192.168.1.0 и 192.168.2.0. Интерфейсу VLAN 1 присвоен Ili-адрес из подсети 192.168.1.0 Интерфейсу VLAN 2, присвоен Ili-адрес из подсети 192.168.2.0 Обратите внимание, что VLAN должен быть привязан к физическому порту коммутатора. Если этого не сделать, то интерфейс VLAN не включится (то есть он будет в состоянии down), и соответственно коммутатор не сможет обмениваться пакетами с другими устройствами в сети. Примечание: Некоторые коммутаторы Cisco могут быть настроены для работы в качестве коммутатора 2 уровня или коммутатора 3 уровня. Действуя в качестве коммутатора 2 уровня, коммутатор обрабатывает, пересылает и управляет пакетами Ethernet. В другом случае, коммутатор может работать как коммутатор 3 уровня. Это означает, что коммутатор может выполнять как коммутацию 2 уровня, так и маршрутизацию IP-пакетов уровня 3, используя логику третьего уровня, обычно используемую маршрутизаторами. В данной статье рассматриваются коммутаторы второго уровня (L2) Настройка IP-адреса (и маски) на одном интерфейсе VLAN позволяет коммутатору обмениваться пакетами с другими узлами в подсети, принадлежащей этой VLAN. Однако коммутатор не может взаимодействовать за пределами локальной подсети без другого параметра конфигурации, называемого шлюзом по умолчанию (default gateway). Причина настройки шлюза по умолчанию на коммутаторе такая же, как и на обычном компьютере. То есть при отправке пакета сетевая карта компьютера думает, как и кому отправить пакет А именно: отправить IP-пакеты узлам, находящимся в той же подсети, напрямую или отправить IP-пакеты узлам, находящимся в другой подсети, через ближайший маршрутизатор, то есть через шлюз по умолчанию. На рисунке изображена данная концепция: На коммутаторе (справа) на VLAN1 настроен IP-адрес 192.168.1.200. Через этот интерфейс (VLAN1) коммутатор может обмениваться пакетами с ПК, входящими в подсеть 192.168.1.0 (желтый сектор) Однако для связи с узлом A, расположенным в левой части рисунка, коммутатор должен использовать маршрутизатор R1 (шлюз по умолчанию) для пересылки IP-пакетов на узел A. Чтобы пакеты дошли до узла А на коммутаторе необходимо произвести настройку шлюза по умолчанию, указав IP-адрес маршрутизатора R1 (в данном случае 192.168.1.1). Обратите внимание, что коммутатор и маршрутизатор используют одну и ту же маску, 255.255.255.0, которая помещает адреса в одну подсеть. Настройка IPv4-адресации на коммутаторе Настройка IP-адресации на коммутаторе осуществляется настройкой на VLAN. Следующие этапы показывают команды, используемые для настройки IPv4 на коммутаторе (настройка IP-адресации на VLAN 1). Введите команду interface vlan 1 в режиме глобальной конфигурации для входа в режим настройки интерфейса VLAN 1. Введите команду ip address <ip-address> <mask> для назначения ip-адреса и маски подсети в режиме конфигурации интерфейса. Введите команду no shutdown в режиме конфигурации интерфейса, чтобы включить интерфейс VLAN 1, если он еще не включен. Введите команду ip default-gateway<ip-address> для назначения ip-адреса шлюза по умолчанию в режиме глобальной конфигурации, чтобы настроить шлюз по умолчанию. (Необязательно) Введите команду ip name-server ip-address1 ip-address2 ... в режиме глобальной конфигурации, чтобы настроить коммутатор на использование DNS для преобразования имен в соответствующие IP-адреса. Пример настройки статической IP-адресации В этом примере показана особенно важная и распространенная команда: команда [no] shutdown. Что бы включить интерфейс ("поднять") на коммутаторе, используйте команду no shutdown в режиме конфигурации интерфейса . Что бы отключить интерфейс используйте в этом же режиме команду shutdown . Эта команда может использоваться на физических интерфейсах Ethernet, которые коммутатор использует для пересылки пакетов Ethernet, а также на интерфейсах VLAN. Кроме того, обратите внимание на сообщения, которые появляются непосредственно под командой no shutdown в примере выше. Эти сообщения являются сообщениями системного журнала, генерируемыми коммутатором, говорящий о том, что коммутатор действительно включил интерфейс. Коммутаторы (и маршрутизаторы) генерируют сообщения системного журнала в ответ на различные события, и эти сообщения появляются на консоли. Настройка коммутатора для получения IP-адреса по DHCP Коммутатор также может использовать протокол Dynamic Host Configuration Protocol (DHCP)для динамического назначения параметров IPv4-адресации. В принципе, все, что вам нужно сделать, это сказать коммутатору использовать DHCP на интерфейсе и включить интерфейс. Предполагая, что DHCP работает в этой сети, коммутатор автоматически получит все его настройки. Следующие этапы показывают команды для настройки коммутатора, используя в качестве примера интерфейс VLAN 1. Войдите в режим конфигурации VLAN 1 с помощью команды глобальной конфигурации interface vlan 1 и включите интерфейс с помощью команды no shutdown по мере необходимости. Назначьте IP-адрес и маску с помощью подкоманды ip address dhcp. Пример настройки IP-адресации коммутатора по DHCP Проверка настроек IPv4 - адресации на коммутаторе Настройку IPv4 адресацию коммутатора можно проверить несколькими способами. Во-первых, вы всегда можете посмотреть текущую конфигурацию с помощью команды show running-config. Во-вторых, вы можете посмотреть информацию об IP-адресе и маске с помощью команды show interfaces vlan x, которая показывает подробную информацию о состоянии интерфейса VLAN в VLAN x. Наконец, если используется DHCP, используйте команду show dhcp lease, чтобы увидеть (временно) арендованный IP-адрес и другие параметры. (Обратите внимание, что коммутатор не хранит полученные настройки IP-адресации по DHCP в файле running-config.) Ниже показан пример выходных данных вышеприведенных команд. Выходные данные команды show interfaces vlan 1 отображают две очень важные детали, связанные с IP-адресацией коммутатора. Во-первых, команда show выводит список состояния интерфейса VLAN 1-в данном случае "up/up." Если интерфейс VLAN 1 выключен, тогда коммутатор не сможет отправлять пакеты через этот интерфейс. Примечательно, что если вы забудете выполнить команду no shutdown, интерфейс VLAN 1 останется в состоянии выключен и будет указан как " administratively down " в выводе команды show. Во-вторых, обратите внимание, что выходные данные содержат IP-адрес интерфейса в третьей строке. Если вы вручную настроите IP-адрес, то он всегда будет отображаться; однако, если вы используете DHCP и DHCP не работает, то команда show interfaces vlan x не будет выводить IP-адрес на экран. Если же DHCP работает, то вы увидите IP-адрес после использования команды show interfaces vlan 1. Хотите почитать про базовую настройку коммутаторов? По ссылкам доступны первая и вторая части статьи
img
В предыдущих статьях мы познакомились как управлять ресурсами AWS с помощью Terraform, в данной статье мы посмотрим, как создавать работающий web-сервер с помощью Terraform. Для развертывания настоящего боевого Web сервера, нам понадобится создать с помощью Terraform два ресурса. Инстанс EC2 и группу безопасности для того, чтобы открыть порт 80 во внешний мир. Для начала создадим новую директорию Lesson-2 и файл WebServer.tr. Вспоминаем именно данный файл с данным расширением является основным для написания кода и управления. Напоминаю, что это обычный текстовый файл, который редактируется с помощью любого текстового редактора в нашем случае мы будем использовать текстовый редактор nano. Mkdir Lesson-2 cd Lesson-2 nano WebServer.tr Сразу будем привыкать к оформлению кода и добавим в код комментарии, комментарии добавляются следующим образом. Ставим знак решетки # и за ней пишем комментарий. #----------------------------------------------- # Terraform # #Build WebServer during BootStrap #-------------------------------------------------- Для начала пишем, кто провайдер и регион для размещения наших ресурсов. provider "aws" { region = "eu-central-1" } Кстати, есть интересный сайт awsregion.info на котором можно посмотреть название регионов и место размещение. Сайт на момент написания статьи обновляется и поддерживается в актуальном состоянии. Так первый ресурс это инстанс EC2. Resource служебное слово, далее название ресурса в кавычках и имя, которое мы ему даем в кавычках, далее открываются и закрываются фигурные скобки. Именно между ними мы и будем описывать наш ресурс. Далее добавляем ami – который показывает, какой образ мы будем использовать. Instance_type – тип и размер ресурса, который мы будем использовать. В итоге смотрим, что у нас получилось в первой итерации кода: resource "aws_instance" "WebServer_my" { ami = "ami-0767046d1677be5a0" #Amazon Linux ami instance_type = "t2.micro" } В результате исполнения данной части у нас будет создан инстанс EC2. Далее создадим 2-й ресурс aws_security_group, фактически это правило сети для брандмауэра. Так же описание начинаем со служебного слова resource, далее название ресурса и имя ресурса в кавычках, а в конце открывающаяся и закрывающаяся скобка в которой пойдет описание ресурса. Указываем параметр name - этот параметр обязательный для корректного отображения, description – параметр не обязательный, но можем указать, vpc_id мы не указываем т.к используем ресурс vpc по умолчанию. Далее идет описание правил сетевых на языке Terraform. Служебный параметр ingress для входящего трафика с фигурными скобками где мы вставим порты и другие параметры данного параметра. И второй служебный параметр engress для исходящего трафика с фигурными скобками. Cidr_blocks = [“подсеть”], указывают откуда или куда разрешен данный поток трафика т.е подсеть 0.0.0.0/0 означает весь интернет или все подсети. Обратите внимание: Мы разрешили входящий трафик на 80 порт, тот порт на котором будет работать наш веб сервер. Мы разрешили входящий трафик на 22 порт, тот порт, который может принимать соединение для подключения по SSH протоколу. Мы разрешили ICMP трафик до нашего сервера, чтобы можно было из интернета проверить его доступность. Мы разрешили трафик на 443 порт, если мы в будущем захотим сделать защищенное HTTPS соединение. И мы разрешили весь исходящий трафик с сервера указав protocol “-1” В такой конфигурации кода Terraform мы получим два отдельных ресурса Инстанс EC2 и группу безопасности, но нас такой вариант не устроит. Нам необходимо, чтобы данная группа безопасности была автоматически присоединена к нашему серверу. Это можно сделать с помощью нового параметра, который мы добавим в первую часть кода, где мы описывали aws_instance. Данный параметр называется vpc_security_group_id, с помощью данного параметра можно сразу присоединить несколько групп безопасности, через знак равенства и скобки “= [“номер группы безопасности”]”. Например, номер группы безопасности можно взять той, что создается по умолчанию. Все остальные указываются, через запятую. Но в нашем случае данный вариант не подойдет, потому что у нас должно все подключиться автоматически, т.е присоединить ту группу безопасности, которая создастся и которую мы описали ниже. А делается это достаточно просто после знака = в квадратных скобках без кавычек вставляем aws_security_group – то что это группа безопасности, затем . – разделитель, затем вставляем имя группы безопасности, которую мы создали mywebserver, опять разделитель символ точки ., и мы ходим взять id. В итоге получается следующий параметр и его значение: vpc_security_group_ids = [aws_security_group.mywebserver.id] Этой самой строчкой мы привязали группу безопасности к нашему создаваемому инстансу. И как следствие возникла зависимость инстанса от группы безопасности. Следовательно, Terraform создаст сначала группу безопасности, а затем уже создаст инстанс. Код Terraform не выполняется сверху вниз, зачастую он исполняется в зависимости от зависимостей или вообще одновременно, когда многие части зависят друг от друга. Следовательно, вот в таком коде мы создали зависимость. По коду вы можете заметить, что если необходимо еще дополнительный порт открыть, например, в группе безопасности, то необходимо скопировать часть кода, отвечающую за открытие порта и добавить необходимые настройки, порт и протокол, подправить cidr_blocks. После корректировки вставить в правильное место, как параметр. И для того, чтобы завершить настройку нашего Web сервера, нам необходимо написать параметр user_data. В амазоне это называется bootstrapping, т.е начальная загрузка. User_data = <<EOF Скрипт EOF Как вы видите сам скрипт будет находится между EOF, а знак << говорит о том, что скрипт мы подаем на ввод. Далее, как любой скрипт в Linux системе мы пишем сначала интерпретатор или shell который будет исполнять и на языке понятном для bash. Поэтому в скрипте не должно быть никаких отступов! Это важно, даже если плагин текстового редактора пытается поправить. Теперь сам скрипт: user_data = <<EOF #!/bin/bash apt -y update apt -y install apache2 myip=`curl http://169.254.169.254/latest/meta-data/local-ipv4` echo "<h2>WebServer with IP: $myip</h2><br> Build by Terraform!" > /var/www/html /index.html sudo service httpd start chkconfig httpd on EOF Сначала обновляем систему apt –y update, далее команда apt –y install apache2 устанавливаем apache веб сервер непосредственно. Следующая строка присваиваем значение переменной myip, с помощью получения данных из самого амазона curl http://169.254.169.254/latest/meta-data/local-ipv4. Далее просто добавляем в индексную страницу по умолчанию вывод того что мы получили с подстановкой IP. Следующая строка стартует сервис, и последняя строка проверяет конфигурацию апача. Таким образом, мы получаем полностью готовый скрипт. Нам остается его сохранить в файле и инициализировать Terraform, командой terraform init и даем команду на применение terraform apply. В результате команды мы видим, что будет создано 2 ресурса, все, как и планировалось. Инстанс и группа безопасности. Как мы видим сначала, из-за зависимости создается группа безопасности. А затем поднимается инстанс, к которому и будет привязана данная группа. Спустя пару минут мы можем видеть, что у нас веб сервер поднялся. IP-адрес можно найти в консоли. Далее, если нам более данный Web сервер не нужен, то мы его можем уничтожить простой командой terraform destroy. И мы увидим, что из-за зависимостей ресурсы будут уничтожаться в обратном порядке тому, в котором они запускались. Сначала инстанс, потом группа безопасности. Скрипт вы можете легко модифицировать и добавить более сложные детали установки и настройки веб сервера – это полностью рабочая конфигурация.
img
Телефонная станция Cisco Call Manager Express (CME) – это телефонная станция, которая функционирует на базе маршрутизатора ISR (Integrated Service Router). Цифровая IP АТС CME разработана для малого и среднего бизнеса, а также, для удаленных филиалов и представительств крупных компаний. Функционал и количество поддерживаемых телефонных аппаратов зависит от платформы, поверх которой функционирует Call Manager Express. Телефонный функционал изначально зашит в IOS (Internetwork Operation System) маршрутизатора, поэтому, для его работы необходима лишь активация. Цифровая IP – АТС Cisco Call Manager Express работает с интерфейсами E1, FXO и FXS. Поддерживает сигнализацию на базе протокола SIP и SCCP, функционал видеоконференцсвязи, интеграцию с голосовой почтой и многие другие опции. Т.к Cisco Call Manager Express базируется поверх граничного ISR маршрутизатора, то он имеет уникальную возможность выступать как устройство модели «все в одном». Это означает одновременную передачу данных, контроля над Cisco IP – телефонами, транки в телефонную сеть общего пользования (ТфОП) и различные приложения. Отметим следующие ключевые особенности CME: Обслуживание вызова: CME это устройство «все в одном». Он поддерживает маршрутизацию трафика, работу с телефонной сигнализацией и оконечными устройствами; Локальная библиотека пользователей: CME хранит данные о пользователях сети, данных авторизации, например, PIN коды пользователей; Возможность управления через командную строку и графический интерфейс: Функционал IP АТС зашит напрямую в операционную систему маршрутизатора IOS. Поэтому, в специальном режиме, можно пользоваться командной строкой, выводить различные данные и так далее. У компании Cisco Systems также есть гибкая и удобная в настройке утилита Cisco Configuration Professional (CCP). Она позволяет производить настройки через удобный графический интерфейс пользователя (GUI) ; Поддержка Computer Telephony Integration (CTI): Интерфейс CTI позволяет интегрировать телефонную станцию с другими приложениями корпоративной сети. Например, подобная интеграция позволяет делать звонки напрямую из почтового клиента Microsoft Outlook; Возможность настройки транков к прочим VoIP системам: CME может выступать как одиночное решение, напрямую подключаемое к ТфОП. Помимо этого, имеется возможность подключаться поверх сети передачи данных к центральной площадке, на примере данной дипломной работы, к кластеру серверов Cisco Unified Communications Manager поверх сети передачи данных; Интеграция с дополнительными услугами: В CME имеется возможность встраивания модуля Cisco Unity Express (CUE), который позволит использовать голосовую почту в корпоративном контуре. Cisco Call Maganer Express особенно удобен для подключения удаленных офисов к существующей системе корпоративной связи на базе Cisco На рисунке приведена схема работы Cisco Call Manager и стрелками обозначены направления работы протоколов сигнализации, при установлении соединения через ТфОП. На данном примере, пользователь Cisco IP – телефона снимает трубку и начинает набирать номер абонента, находящегося в ТфОП. На данном этапе передача цифр номера и управление вызовом обеспечивается протоколам SIP или SCCP, в зависимости от настройки оконечного устройства. Как только абонент набирает номер, телефонная станция CME, опираясь на заранее настроенный план нумерации, определяет, что вызов находится за пределами корпоративной сети (за граничным шлюзом) и его необходимо отправить в ТфОП. С этого момента, CME выступает в роли голосового шлюза и преобразует сигнализацию из формата SIP или SCCP в формат понятный E1 или FXO транку. Как только вызов установлен, Cisco Call Manager Express начинает преобразовывать аудио из формата VoIP в формат Public Switched Telephone Network (PSTN) или как принято говорить в РФ – ТфОП. Поскольку процесс преобразования аудио – трафика достаточно сложен и несет в себе большую аппаратную нагрузку, в Call Manager Express оборудован дополнительный процессор Digital Signal Processors (DSP), специально предназначенный для преобразования голосового трафика. Важно отметить, что при проектировании корпоративной телефонной сети, учитывается проектируемая нагрузка и соответственно, специально подбираются ресурсы DSP. При объединении площадок, настраивается Site to Site VPN – туннель, в котором трафик площадок передается в зашифрованном виде. В функционал CME можно легко внедрить голосовое меню на базе VXML скрипта, который будет являться конфигурацией. Другими словами, VXML будет отдавать команды маршрутизатору на определенные действия, будь то перевод звонка на определенный номер или воспроизведение звукового файла. Реализация VXML голосового меню происходит на граничном маршрутизаторе. При объединении офисов, настраивается “Dial Peer” – команда действий телефонной станции при наборе определенного номера. План нумерации определяется с учетом потребностей площадок, масштабируемости и удобства ведения бизнеса.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59