По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всякий раз, когда мы отправляем данные из одного узла в другой в компьютерной сети, данные инкапсулируются на стороне отправителя, а деинкапсулируются на стороне получателя. В этой статье мы узнаем, что такое инкапсуляция. Мы также подробно изучим процесс инкапсуляции и деинкапсуляции в моделях OSI и TCP/IP.
Инкапсуляция данных
Инкапсуляция данных - это процесс, в котором некоторая дополнительная информация добавляется к элементу данных, чтобы добавить к нему некоторые функции. В нашей сети мы используем модель OSI или TCP/IP, и в этих моделях передача данных происходит через различные уровни. Инкапсуляция данных добавляет к данным информацию протокола, чтобы передача данных могла происходить надлежащим образом. Эта информация может быть добавлена в заголовок (header) или в конец (footer или trailer) данных.
Данные инкапсулируются на стороне отправителя, начиная с уровня приложения и заканчивая физическим уровнем. Каждый уровень берет инкапсулированные данные из предыдущего слоя и добавляет некоторую дополнительную информацию для их инкапсуляции и некоторые другие функции с данными. Эти функции могут включать в себя последовательность данных, контроль и обнаружение ошибок, управление потоком, контроль перегрузки, информацию о маршрутизации и так далее.
Деинкапсуляция данных
Деинкапсуляция данных - это процесс, обратный инкапсуляции данных. Инкапсулированная информация удаляется из полученных данных для получения исходных данных. Этот процесс происходит на стороне получателя. Данные деинкапсулируются на том же уровне на стороне получателя, что и инкапсулированный уровень на стороне отправителя. Добавленная информация заголовка и футера удаляется из данных в этом процессе.
На рисунке показано, как футер и хедер добавляются и удаляются из данных в процессе инкапсуляции и деинкапсуляции соответственно.
Данные инкапсулируются на каждом уровне на стороне отправителя, а также деинкапсулируются на том же уровне на стороне получателя модели OSI или TCP/IP.
Процесс инкапсуляции (на стороне отправителя)
Шаг 1. Уровень приложения, представления и сеанса в модели OSI принимает пользовательские данные в виде потоков данных, инкапсулирует их и пересылает данные на транспортный уровень. Тут не обязательно добавится к данным какой-либо хедер или футер - это зависит от приложения.
Шаг 2. Транспортный уровень берет поток данных с верхних уровней и разделяет его на несколько частей. Транспортный уровень инкапсулирует данные, добавляя соответствующий заголовок к каждой части. Эти фрагменты данных теперь называются сегментами данных. Заголовок содержит информацию о последовательности, так что сегменты данных могут быть повторно собраны на стороне получателя.
Шаг 3. Сетевой уровень берет сегменты данных с транспортного уровня и инкапсулирует их, добавляя дополнительный заголовок к сегменту данных. Этот заголовок данных содержит всю информацию о маршрутизации для правильной доставки данных. Здесь инкапсулированные данные называются пакетом данных или дейтаграммой.
Шаг 4: Канальный уровень берет пакет данных или дейтаграмму с сетевого уровня и инкапсулирует ее, добавляя дополнительный заголовок и нижний футер. Заголовок содержит всю информацию о коммутации для правильной доставки данных соответствующим аппаратным компонентам, а футер содержит всю информацию, связанную с обнаружением ошибок и контролем. Здесь инкапсулированные данные называются фреймом данных.
Шаг 5: Физический уровень берет кадры данных с уровня канала передачи данных и инкапсулирует их, преобразовывая их в соответствующие сигналы данных или биты, соответствующие физической среде.
Процесс деинкапсуляции (на стороне получателя)
Шаг 1: Физический уровень принимает инкапсулированные сигналы данных или биты от отправителя и деинкапсулирует их в форме кадра данных, который будет перенаправлен на верхний уровень, то есть на канальный уровень.
Шаг 2: Канальный уровень берет кадры данных с физического уровня. Он деинкапсулирует фреймы данных и проверяет заголовок фрейма, скоммутирован ли фрейм данных на правильное оборудование или нет. Если кадр пришел в неправильное место назначения, он отбрасывается, иначе он проверяет информацию в футере. Если есть какая-либо ошибка в данных, запрашивается повторная передача данных, если нет, то они деинкапсулируются, и пакет данных пересылается на верхний уровень.
Шаг 3. Сетевой уровень принимает пакет данных или дейтаграмму из канального уровня. Он деинкапсулирует пакеты данных и проверяет заголовок пакета, направлен ли пакет в правильное место назначения или нет. Если пакет направляется в неправильный пункт назначения, пакет отбрасывается, если все ок, то он деинкапсулируется, и сегмент данных пересылается на верхний уровень.
Шаг 4: Транспортный уровень берет сегменты данных с сетевого уровня и деинкапсулирует их. Сначала он проверяет заголовок сегмента, а затем повторно собирает сегменты данных для формирования потоков данных, а затем эти потоки данных пересылаются на верхние уровни.
Шаг 5: Уровень приложения, представления и сеанса в модели OSI берет инкапсулированные данные с транспортного уровня, деинкапсулирует их, и данные, относящиеся к конкретному приложению, пересылаются в приложения.
Ansible один из двух (наряду с SaltStack) наиболее популярных программных комплексов третьей волны, которые позволяют удалённо управлять конфигурациями. Тем не менее, в сегменте сетевого оборудования лидирует наш сегодняшний герой (если о ПО можно так сказать). В первую очередь это вызвано тем, что Ansible не поставит перед пользователем задачи устанавливать агент на хостинги, требующие от него управления. Тем паче ежели Ваш аппарат взаимодействует с ними через CLI, то Ansible это то, что доктор прописал.
Одним выстрелом три "электронных зайца"
Вообще, прежде чем знакомить уважаемых читателей со сценарием работы в данном программном комплексе, позвольте перечислить несколько его достоинств:
Ansible позволяет параллельно подключать по SSH к устройствам (пользователь может сам определить их число).
Ansible может передавать задачи на подключённые машины.
Ansible способен разбивать машины, входящих в систему, на подгруппы и передавать специальных задачи для каждой подгруппы.
Конечно, указаны не все достоинства Ansible. Просто в данных 3 пунктах, как мне кажется, отражена основная суть работы в данной среде. Выполняя эти три задачи, система автоматически освобождает Вас от головной боли по делегированию задач и функций в компании. Время деньги, как говорится.
Сценарии
Ну и переходим к основному блюду нашего материала - сценариям (playbook). Они состоят из двух частей набора команд для выполнения (play) и конкретных команд (task). Они выполняются друг за другом.
Все записи данных осуществляются с помощью YAMLа. К несомненным плюсам его использования следует отнести то, что он гораздо лучше воспринимается людьми, нежели тот же самый JSON. Ежели Вы больше привыкли Вы к Python, то тут у Вас не возникнет проблем с адаптацией, так как синтаксис у них схожий.
А вот так происходит процесс написания сценария (комментарии даны построчно к выводу):
Имя сценария обязательный элемент для любого сценария;
Сценарий применяется к машинам в подгруппе cisco-routers;
Выключение режима сбора событий в конкретной машине (если не выключить данный режим, то система потратит много времени на решение ненужных задач);
В разделе task указывается список команд для каждого конкретного случая;
После чего происходит выполнение команды:
PLAY [Run show commands on routers] ***************************************************
TASK [run sh ip int br] ***************************************************************
changed: [192.168.100.1]
changed: [192.168.100.3]
changed: [192.168.100.2]
TASK [run sh ip route] ****************************************************************
changed: [192.168.100.1]
changed: [192.168.100.3]
changed: [192.168.100.2]
PLAY [Run show commands on switches] **************************************************
TASK [run sh int status] **************************************************************
changed: [192.168.100.100]
TASK [run sh vlans] *******************************************************************
changed: [192.168.100.100]
PLAY RECAP ****************************************************************************
192.168.100.1 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.100 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.2 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.3 : ok=2 changed=2 unreachable=0 failed=0
И запускаем проверку выполнения команд:
SSH password:
PLAY [Run show commands on routers] ***************************************************
TASK [run s hip int br] ***************************************************************
Changed: [192.168.100.1] => {“changed”: true, “rc”: 0, “stderr”: “Shared connection
To 192.168.100.1 closed.
”, “stdout”: “
Interface IP-Address
OK? Method Status Protocol
Ethernet0/0 192.
168.100.1 YES NVRAM up up
Ethernet0/1
192.168.200.1 YES NVRAM up up
Loopback0
10.1.1.1 YES manual up up
”, “stdout_lines
“: [“”, “Interface IP-Address OK? Method Status
Protocol”, “Ethernet0/0 192.168.100.1 YES NVRAM up
up “, “Ethernet0/1 192.168.200.1 YES NVRAM up
up “, “Loopaback0 10.1.1.1 YES manual up
up “]}
А что внутри?
А теперь поговорим о начинке сценария. Основу составляют переменные. Это могут быть данные о машине, выводы команд, а также их можно вводить вручную.
Главное не забывать правила написания имён. Их всего два:
имена всегда должны состоять из букв, цифр и нижнего подчёркивания;
имена всегда должны начинаться с буквы.
Переменные могут быть определены разными способами:
Инвентарным файлом
[cisco-routers]
192.168.100.1
192.168.100.2
192.168.100.3
[cisco-switches]
192.168.100.100
[cisco-routers:vars]
ntp_server=192.168.255.100
log_server=10.255.100.1
PLAYBOOKом
-name: Run show commands on router:
hosts: cisco-routers
gather_facts: false
vars:
ntp_server: 192.168.255.100
log_server: 10.255.100.1
tasks:
-name: run sh ip int br
raw: s hip int br | ex unass
-name: run s hip route
raw: sh ip route
Специальными файлами, созданными для групп:
[cisco-routers]
192.168.100.1
192.168.100.2
192.168.100.3
[cisco-switches]
192.168.100.100
Или группами каталогов
|– group_vars _
| |– all.yml |
| |–cisco-routers.yml | Каталог с переменными для групп устройств
| |–cisco-switches.yml _|
|
|–host vars _
| |–192.168.100.1 |
| |–192.168.100.2 |
| |–192.168.100.3 | Каталог с переменными для устройств
| |–192.168.100.100 _|
|
|–myhosts | Инвертарный файл
Команда register позволяет сохранять результаты выполнений модулей в переменные. После чего переменная может быть использована в шаблонах, принятиях решений о выполнении заданного сценария.
---
- name: Run show commands on routers
hosts: cisco-routers
gather_facts: false
tasks:
-name: run s hip int br
raw: s hip int br | ex unass
register: sh_ip_int_br_result
---
debug отображает информацию в стандартном потоке вывода в виде произвольной строки, переменной или фактах о машине.
---
- name: Run show commands on routers
hosts: cisco-routers
gather_facts: false
tasks:
-name: run s hip int br
raw: sh ip int br | ex unass
register: sh_ip_int_br_result
-name: Debug registered var
debug: var=sh_ip_int_br_result.stdout_lines
После чего результатом работы станет следующее:
SSH password:
PLAY [Run show commands on routers] ***************************************************
TASK [run sh ip int br] ***************************************************************
changed: [192.168.100.1]
changed: [192.168.100.2]
changed: [192.168.100.3]
TASK [Debug registered var] ***********************************************************
ok: [192.168.100.1] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.1 YES NVRAM up up “,
“Ethernet0/1 192.168.200.1 YES NVRAM up up “,
“Loopback0 10.1.1.1 YES manual up up “
]
}
ok: [192.168.100.2] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.1 YES NVRAM up up “,
“Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “,
“Loopback0 10.1.1.1 YES manual up up “
]
}
ok: [192.168.100.3] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.3 YES NVRAM up up “,
“Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “,
“Loopback0 10.1.1.1 YES manual up up “,
“Loopback10 10.255.3.3 YES manual up up “
]
}
PLAY RECAP ****************************************************************************
192.168.100.1 : ok=2 changed=1 unreachable=0 failed=0
192.168.100.2 : ok=2 changed=1 unreachable=0 failed=0
192.168.100.3 : ok=2 changed=1 unreachable=0 failed=0
Вместо заключения
Можно ещё долго приводить примеры работы в системе, но ещё один факт так сказать "вишенка на торте". К плюсам Ansible следует отнести и то, что заданную команду система может выполнять практически до бесконечности. Пока не наступит требуемый результат трансформации не прекратятся. Пользователю можно не беспокоиться - программа сама всё сделает за Вас, а Вы можете заниматься другими делами.
CatOS (Catalyst Operating System) – это операционная система, которая использовалась в коммутаторах Cisco в линейке Catalyst, но впоследствии была вытеснена Cisco IOS. Первоначально она называлась "XDI" от компании Crescendo Communications, Cisco переименовала ее в CatOS, когда они приобрели Crescendo в конце 1993 года.
/p>
CatOS работала на коммутаторах серий 200, 2948G, 4000, 4500, 5000, 5500, 6000 и 6500. CatOS все еще может работать на некоторых модульных коммутаторах Cisco, «гибридных» режимах. В гибридном режиме NMP (процессор коммутатора) запускает CatOS, а в маршрутном процессоре работает Cisco IOS.
Сравнение CatOS и IOS
Есть три варианта ОС для коммутаторов линейки Catalyst: CatOS, гибридный режим (hybrid) и нативный режим (Native IOS). CatOS настраивает только коммутацию второго уровня. Для коммутаторов Catalyst третьего уровня (Catalyst 6500 с MSFC - многоуровневой функциональной картой коммутатора), CatOS можно использовать для функций второго уровня, а IOS может управлять MSFC. Этот процесс называется гибридным режимом. В нативном режиме IOS управляет функциями уровня 2 и уровня 3 в коммутаторе.
Новые модели Cisco Catalyst Switch (с новейшими версиями Cisco IOS) также позволяют конфигурировать через модуль веб-графического интерфейса (GUI), который представлен на HTTP-сервере, расположенном на коммутаторе Cisco Catalyst. Команда IOS ip http-server позволяет использовать эту конфигурацию. В IOS 12.x эта команда всегда включена как заводская настройка. Некоторые новейшие модели коммутатора Cisco Catalyst (называемые Catalyst Express) больше не разрешают доступ к IOS или CatOS вообще - эти коммутаторы можно настроить только с помощью графического интерфейса.
Свойство
CatOS
Cisco IOS
Конфигурационный файл
Два конфигурационных файла: один для NMP, один для MSFC
Один конфигурационный файл
Образ ОС
Два образа: один для NMP, один для MSFC
Один образ
Стандартный статус порта
Каждый порт включен
Каждый порт в выключенном состоянии
Формат конфигурационных команд
Команды с ключевым словом set определяет каждую конфигурационную команду
Структура команд Cisco IOS с командами глобального уровня и уровня интерфейса
Режим конфигурации
Нет конфигурационного режима (команды set, clear и show)
Команда configure terminal активирует режим конфигурации
Теперь сравним команды CatOS и IOS
CatOS
Cisco IOS
set vlan [vlan-id] [mod]/[port]
interface [gigabit/fastethernet] [mod]/[port]switchportswitchport mode accessswitchport access vlan [vlan-id]
set port enable [mod]/[port]
interface [gigabit/fastethernet] [mod]/[port]no shutdown
set port disable [mod]/[port]
interface [gigabit/fastethernet] [mod]/[port]shutdown
set spantree portfast
interface [gigabit/fastethernet] [mod]/[port]spanning-tree portfast
set port speed [mod]/[port] [auto/10/100/1000]
interface [gigabit/fastethernet] [mod]/[port]speed [auto/10/100/1000]
set port duplex [mod]/[port] [half/full]
interface [gigabit/fastethernet] [mod]/[port]duplex [auto/full/haif]
reset system
reload
show cam dynamic
show mac-address-table dynamic
show channel
show etherchannel summary
show port [mod]/[port]
show nterface [gigabit/fastethernet] [mod]/[port]
show spantree
show spanning-tree
show trunk
show interfaces trunk
show vlan
show vlan
show vtp domain
show vtp status
set system name [label]
hostname [label]
set spantree backbonefast
spanning-tree backbonefast
set spantree macreduction table
spanning-terr extend system-id