Amin 's Blog

Для примера посмотрим вот на такую схему:

Есть два клиента, у каждого из которых есть своя сложная сеть. И вот им приперло соединить свои филиалы в единую сеть, прозрачно пробросив свои вланы через сеть вышележащего прова. Понятно, что согласовать вланы и обойтись простым тегированием тут не выйдет. Влан 1 (он же влан по-умолчанию) у каждого клиента свой, а у провайдера — свой. Да и админ банка сильно удивится, если увидит в своем втором влане левый траффик от добывающей компании 😀 .

Суть QinQ вообщем-то проста и незатейлива — переводим клиентские порты в особый режим «туннелирования клиентских вланов». Режим этот у циско называется «dot1q-tunnel», у длинка- qinq-UNI. В этом случае железка для таких портов не занимается анализом тегов у входящих пакетов, а тупо наворачивает на них еще одну метку (внешнюю), по которой собственно и ориентируется провайдерское оборудование. На схеме выше тегированный траффик клиентских вланов 1 и 2 для одной компании будет дополнительно обернут тегом 3015, а для другой — тегом 3016. При выходе через такие хитрые порты с дважды тегированного траффика будет срезана только внешняя (провайдерская) метка с номером 301x, и клиенту будет направлен уже одиночно тегированный (его внутренними тегами!) траффик, который можно и нужно будет принять самым обычным 802.1q-транком.

Клиенту тут сплошные удобства — ему не надо вообще задумываться про QinQ, он строит свои собственные вланы как он хочет.

Теперь посмотрим, как это работает. Смотреть будем Wireshark-ом, втыкая его в нужный порт на тестовом стенде. Скажу честно — без раскурки дампов траффика поначалу въехать может быть тяжеловато. Простое одиночное тегирование по 802.1q, оно же влан-вульгарис, работает вот так:[Eth-Header; type: 0x0800][IP] —802.1q—>[Eth-Header; type: 0x8100][802.1q; VLAN: 2; type: 0x0800][IP] Я постарался выделить добавленный заголовок и изменившиеся значения типа полезной нагрузки. Тут никаких особых проблем нет.

QinQ повторяет подобный трюк еще раз, и вот тут мы встречаем самые первые грабли. По стандарту QinQ (он же 802.1ad) должен работать вот так:[Eth-Header; type: 0x8100][802.1q; VLAN: 2; type: 0x0800][IP] —QinQ—>[Eth-Header; type: 0x88a8][802.1ad; VLAN: 3015; type: 0x8100][802.1q; VLAN: 2; type: 0x0800][IP] В дампе траффика это выглядит вот так:

Однако такой тип в L2-заголовке, хоть и прописан в стандарте, нормально понимают только некоторые типы железок.

Приснопамятная циска решила, что нехх мутить воду, и решила специальное значение type = 0x88a8 для QinQ-траффика не использовать, вместо этого навешивая два совершенно одинаковых 802.1q-заголовка подряд:[Eth-Header; type: 0x8100][802.1q; VLAN: 2; type: 0x0800][IP] —Cisco-QinQ—>[Eth-Header; type: 0x8100][802.1q; VLAN: 3015; type: 0x8100][802.1q; VLAN: 2; type: 0x0800][IP] В дампе траффика это выглядит вот так:

Так вот — это вызывает определенную попаболь при попытке состыковать оборудование разных производителей. Вещь неочевидная, и детально особо нигде не описанная. Формально и то, и другое — дважды тегированный траффик, но QinQ по стандарту имеет право называться только первый вариант. К сожалению, у циско тут нашлись последователи, так что тип 0х8100 в QinQ-траффике вполне себе живет и здравствует. Так что если у вас все настроено, но траффик не ходит или ходит как-то странно и местами — проверьте тип. Это особенно актуально, если на разных концах туннеля используется оборудование от разных производителей. Например, в датацентре может стоять теплая ламповая циска, а на втором конце туннеля в Урюпинске — D-Link или ещё что похуже.

Внутренние интерфейсы, смотрящие внутрь провайдерской сети, настраиваются как обычные транки, для которых разрешается прохождение вланов 3015 и 3016, выделенных QinQ-клиентам. О внутренних вланах клиента провайдеру как правило знать ничего не требуется, и в настройке там ничего интересного нет.

Итак, вы познали дзен L2-типов, прописали везде 0x8100 (на некоторых цисках — 0x9100 и даже 0x9200 для пущего кайфа 😀 :D), и тут вас подстерегают следующие грабли.

Называются они MTU, он же максимальный размер кадра. Ясен хер, что использование двойного тегирования увеличивает размер кадра. Минимум увеличить надо до 1504 байт, но лучше прописать несколько больше. Можно без проблем поставить 1600 и забыть. Засада тут в том, что для цисок изменение System MTU требует … перезагрузки маршрутизатора. А точнее _всех_ цисок, у которых размер SystemMTU недостаточен и через которые пойдет QinQ-траффик. Это очень, очень гнусно, поэтому рекомендуется сделать это сильно заранее и как всякое настоящее злодейство — глубокой ночью. Однако это только прелюдия к граблям. Самая суть граблей с MTU может обнаружиться в виде кетайского медиа-конвертера, который ясен фиг никак обнаруживаться не будет. Симптомы мерзейшие: пинг ходит, трейс ходит, SSH работает. А вот HTTP и RDP — хуй. Лучшее решение тут — выкинуть китайские конвертеры нахуй. Ещё один возможный косяк — это MTU и работа протоколов динамической маршрутизации. Читать тут, бдить, грабли всегда где-то рядом 😀.

Остальные грабли более специфичны и фичасты, и по ним мы прогуляемся в процессе настройки.

На циске Тут все достаточно просто. Убеждаемся, что SystemMTU — торт, создаем выделенный для клиента влан, в который завернем клиентские вланы, пропишем его на промежуточных транках, как обчно. Потом на порту, смотрящем в сторону ТвистГаза, пишем:

configure terminal  interface <интерфейс к клиенту>  switchport access vlan 3015  switchport mode dot1q-tunnel

Посмотреть на содеянные безобразия —

show dot1q-tunnel  show vlan dot1q tag native

dot1q tunneling ethertype {0x88a8|0x9100|0x????...}

Тут тоже лежит специальный бережно сохраненный костыль — у разных цисок набор допустимых к включению типов разный. Стороннее оборудование естественно иногда не понимает, что это за НЁХ с 0x9100 :cat: Собственно, всё. Более сложные случаи рассматриваются в документации, например на сайте циски.

на D-Link. Там все гораздо, гораздо более запущено. Причем сильно запущено. Первое, с чего надо начать — с обновления версий прошивок. Кто не верит — может на форуме д-линка поискать про QinQ. На старых прошивках был занятнейший баг — настроить роли портов для QinQ можно было только после глобального включения этого самого QinQ. Однако его включение «по-тупому» (а это была единственная возможная команда) приводило к тому, что у такого свитча отваливалось управление. :bug: Так что мой вам добрый, очень добрый совет — перед использованием QinQ на д-линках смоделировать все на тестовом стенде, не забывая втыкать ноут со сниффером в разные интересные места тестового стенда. В отличие от циски, где самое серьезное изменение — это SystemMTU, а настройки QinQ затрагивают один-единственный порт, тут настройки затрагивают свитч целиком.

disable asymmetric_vlan  enable pvid auto_assign

Настроим самый обычные вланы, какие мы делаем обычно, но назовем их понятным образом:

# R2  create vlan qinq_3015 tag 3015  config vlan qinq_3015 add tagged 9-10  config vlan qinq_3015 add untagged 8    # R3  create vlan qinq_3016 tag 3016  config vlan qinq_3016 add tagged 9-10  config vlan qinq_3016 add untagged 8

Вздрогнули, помолились, включаем:

enable qinq

Теперь настраиваем собственно QinQ. И вот мы получаем по лбу первыми граблями от д-линка. На свитче со включенным QinQ порт может быть в двух режимах — UNI и NNI. Д-линк прямо пишет в документации, что первый — для клиентского траффика, а NNI-порты должны смотреть в сторону ядра сети. После включения все порты однако будут именно в NNI-режиме. Отдельного Normal-режима или access-порта-вульгарис при включенном глобально qinq на д-линке не предусмотрено. Остерегайтесь граблей 😀

А что всё-таки делать с обычными клиентскими access-портами на этом же свитче ? Д-линк, насколько я понял, подразумевает их настройку как UNI, но в этом случае если клиент пошлет туда тегированный траффик — он отправится по нашей сети дважды тегированным. Если разобрать такой траффик будет некому — то для нас ничего страшного не случится. Если оставить их как NNI (то есть для тегированного траффика вторая метка не навешивается, режим включенный по умолчанию), то доступ порта к вланам все равно по-прежнему будет регулироваться настройками обычных вланов. В документации от д-линка этот вопрос освещен достаточно мутно. На DES-3200-10 обычный клиентский порт, добавленный как untagged в соответствующий клиентский влан, нормально работал как в UNI, так и в NNI-режиме. Я рекомендую оставить настройку в NNI, в этом случае вторая метка навешиваться точно не будет (нафиг эту головную боль на клиенстких портах), а членство во вланах регулироваться будет как обычно.

Тут грабли с TPiD встречаются нам ещё раз: при глобально действующем outer_tpid нужно ставить 0х8100. При любых других значениях обычные (не-QinQ) вланы работать не будут вовсе. Если кстати у вас управляющий влан — не нативен (то есть ходит тегированным), то смена outer_tpid на что-либо отличное от 0x8100 приведёт к невозможности приема одиночно тегированного траффика другим оборудованием, и соответственно к потере управления свитчем с последующим отлётом яиц в дальний космос. Да, д-линк такой д-линк. На свитчах типа DGS-3627G с этим получше — там в новых прошивках уже можно задавать TPiD для каждого порта отдельно. Не прошло и десяти лет.

Поскольку нам не интересно вмешиваться во внутренние теги (мы настраиваем Port-Based QinQ, про Selective QinQ пока не будем), то выключаем влан-трансляцию и доверие клиентским VLAN_iD:

config qinq ports all trust_cvid disable vlan_translation disable

Теперь надо решить, какой тип дважды тегированного траффика будет. У меня заработало на значении 0x8100 (dot1q-tunnel, который Cisco-QinQ), но поскольку у д-линка по умолчанию включен стандартный QinQ (0x88a8) — то меняем:

config qinq ports all outer_tpid 0x8100

Чтобы включить назад стандартный QinQ, соответственно:

config qinq ports all outer_tpid 0x88a8

Тут тоже у д-линка лежит ещё одна кучка садово-огородного инвентаря. На куче железок поменять можно только тип исходящих кадров, и только для _всех_ портов сразу. Попытка сменить outer_tpid только для одного порта — сопровождается оповещением, что параметр сменен глобально.

Теперь переводим порт, смотрящий в сторону клиента, в режим навешивания второй метки для тегированного траффика:

config qinq ports 8 role uni

Какие ещё грабли могут подстерегать ? Могут возникнуть траблы с передачей нетегированного траффика внутри QinQ-туннеля. Решается вот такой командой для клиентского порта:

config gvrp 8 acceptable_frame admit_all

Опять же детали не скажу — тут надо много тестить, на каждой железке есть свои багофичи и прочие неисправимые преимущества.

О тестировании.

interface GigabitEthernet0/1.3015     encapsulation dot1Q 3015 second-dot1q 1     ip address 192.168.1.0 255.255.255.0

На линуксе (Fedora17) QinQ-сабинтерефейс поднимается аналогично интерфейсу в одиночном влане, с помощью команды vconfig. Например, для анализа траффика в выше приведенной схеме делем вот так:

# vconfig add eth0 3015  # vconfig add eth0 3016  # vconfig add eth0.3015 1  # vconfig add eth0.3015 2  # vconfig add eth0.3016 1  # vconfig add eth0.3016 2

Этими командами мы создали для сетевой карты eth0 два сабинтерфейса для снятия внешних меток — eth0.3015 / eth0.3016 и еще четыре сабинтерфеса для qinq-траффика: eth0.3015.1, eth0.3015.2, eth0.3016.1 и eth0.3016.2 . Настройка параметров делается с помощью того же ifconfig:

# ifconfig eth0.3015.1 inet 192.168.1.0/24 up

После этих настроек перезапускаем Wireshark, и видим в списке шесть новых сетевых интерфейсов. Окно с общим списком интерфейсов позволяет сразу увидеть, сколько пакетов приходит на каждый сабинтерфейс, и посмотреть, куда какой траффик приходит и как снимаются метки на линуксе. Входящие дважды тегированные пакеты обрабатываются и нормально разбираются с любым TPiD (судя по статистике на сабинтерфейсах и дампам траффика), а вот исходящие пакеты по-умолчанию идут с TPID = 0x8100. Так что если на оборудовании как-то по-другому — траффик будет идти только в одну сторону (линуксовая машина принять и разобрать траффик сможет, а вот посланные её пакеты будут отброшены оборудованием из-за несовпадения TPiD). Если кто знает, как сделать так, чтобы только для дважды тегированных пакетов линукс ставил некий заранее заданный TPiD для тестирования других вариантов настройки QinQ — буду крайне признателен.

На FreeBSD (8.2) мне удалось поднять только одиночно тегированный сабинтерфейс, фокус с QinQ не прошел. Фряха без проблем работает с сабинтерфейсами для обычных вланов, а вот с QinQ не вышло — сабинтерфейс на сабинтерфейсе уже не создается.

На винде разбор QinQ вам не грозит ни в каком виде и никак, даже если вы сделаете миньет Баллмеру. Там и обычные-то вланы нихера нативно не поддерживаются (только на некоторых сетевухах, криво и после продолжительного секаса с дровами), а про qinq даже не мечтайте, не в этой жизни. В контексте данной статьи Windows Server 2008 Datacenter Edition и Windows 95 для нас одинаково убоги и для тестирования абсолютно непригодны.

Вот такая вот теплая ламповая технология. Надеюсь, добытая информация будет вам полезной.

Продолжение серии: https://aminux.wordpress.com/2016/04/15/q-in-q__juniper_part2/

Привет. Коммутация – одна из самых нелюбимых тем у слушателей, готовящихся к CCIE Routing and Switching. Бывают люди, которые с ходу разбираются с динамической маршрутизацией (таких большинство), кто-то сразу вкуривает, как работает Frame Relay (их меньше), кто-то интересуется взаимодействием TokenRing и IPX (это некрофилы). Свичинг не любит практически никто – за его “мутность”. В случае, например, динамической маршрутизации, весь траблшутинг и анализ ситуации достаточно понятен и осознаваем мозгом – можно посмотреть, от кого к кому пришли какие маршруты и достаточно быстро сделать выводы о типовых проблемах в конфигурировании. В случае с траблшутингом работ на канальном уровне дело обычно хуже – надо лезть в отладку и вычислять “кто на кого почему каким портом в каком статусе смотрит и не напутали ли ничего с виланами-stp-прочим”. В принципе, со временем уже становится проще, но на психически здорового человека, попавшего на курс SWITCH с детальным разбором работы протоколов семейства STP, производит специфическое впечатление. Усугубляется это наличием книжки от русской редакции Cisco Press с названием “Коммутация в локальных сетях”, в которой полторы тысячи страниц, примеры про CatOS года так от 2003-2004, жуткий язык изложения достаточно несложных тем и постоянный подтекст а-ля Братья Гримм “но это ещё фигня, дальше только страшнее будет” (у меня в своё время сложилось впечатление, что цель этой серии – нагон слушателей на курсы путём внедрения мысли вида “видите, как всё страшно, без курсов никак не справитесь”). Поэтому на коммутацию можно и нужно потратить время – именно детальное знание таких “очевидных” штук и отличает профессионала от “мы с ребятами вчера убунту поставили – вроде всё понятно, теперь мы специалисты по суперкомпьютерной ОС”. Сегодняшний разговор – про метки кадров. Как обычно, я предполагаю, что Вы знаете коммутацию на уровне CCNA.

Одиночный вариант: метим кадры 802.1Q

Достаточно часто возникает задача логического мультиплексирования нескольких потоков данных в пределах одной физической среды передачи. Для её [задачи] реализации в стандартах семейства 802.x даже есть специальный стандарт – 802.2. Но в самом распространённом протоколе канального уровня – 802.3 – вместо данной схемы формирования заголовка LLC-уровня используется Ethernet II (т.е. когда после SRC MAC сразу идёт 2 байта с кодом протокола (поле EtherType)). Конечно, есть и другие варианты – например, любимый фирмой Novell “raw ethernet”, когда сразу после двухбайтового поля Length идёт заголовок IPX, но на данный момент это решение уже не используется. Что же используется? В основном используется 802.1Q – достаточно простой стандарт, подразумевающий добавление в кадр дополнительного заголовка размером в 4 байта, и имеющего такой формат:

• Поле TPID – Tag Protocol ID – два байта, идентифицирующие тип доп.заголовка – всегда 0x8100.
• Поле PCP – Priority Code Point – три бита, рождённые в муках комитетом 802.1p, которому вообще-то предписывали заниматься динамической фильтрацией мультикастового трафика, но, видимо, увидев КПД (три бита), расстреляли комитет в полном составе. Эти три бита также часто называются CoS – Class of Service.
• Поле CFI – Canonical Format Indicator – 1-битовый флаг, показывающий формат MAC-адресов. В авторизованных курсах Cisco игриво называется “Признак Token Ring”, хотя говорит чуть о другом. Это поле всегда должно быть в нуле (т.е. показывать нормальность формата MAC’ов в кадре), а если оно в единице – это говорит о том, что MAC’и в кадре нетрадиционной ориентации и не могут дружить с обычными коммутаторами. По сути, найдя единицу в этом поле, коммутатор не должен отдавать указанный кадр в untagged-виде (т.е. например в транк с native-vlan’ом, совпадающим с указанным в заголовке), т.к. в этом случае не гарантируется корректная обработка кадра получателем.
• Поле VID – Virtual LAN ID – 12 бит, содержащих наконец-то главное – номер VLAN’а.

Чуть уточнение в плане терминологии. Когда упоминается о “чистом 802.1p”, то обычно имеется в виду вариант 802.1Q, в котором VID = 0. Тогда значимым считается только поле PCP, и вся конструкция называется Priority Tag. В остальных случаях – 802.1Q. В случае явного указания “Заголовок 802.1Q/p” обычно подразумевается, что обрабатываются оба поля – и номер VLAN, и приоритет канального уровня. Поле CFI сейчас фактически не используется. В стандартах семейства 802.11 местная реализация записи данных QoS канального уровня называется 802.11e и технически представляет из себя тот же заголовок 802.1Q. Конечно, есть ещё вариант логического мультиплексирования с использованием ISL-инкапсуляции, но про него, если нужно, я напишу подробнее отдельно. Сейчас основное и стандартное решение всё ж 802.1Q. Соответственно, вкратце про то, как объединить/разделить несколько потоков данных внутри одной Ethernet-сети (да и WiFi) мы разобрались, можно подытожить:

• Можно сделать несколько независимых потоков данных, разделив их на канальном уровне
• Для протоколов 802.x для этого существует SNAP-инкапсуляция
• Кроме протокола 802.3, для него практикуется использование 802.1Q, который заодно умеет передавать данные о приоритете кадра через поле 802.1p
• Ну и кроме 802.11, для которого есть 802.11e, который по сути тот же 802.1Q

Теперь удвоим ставки.

Технология 802.1ad – двойная метка

Как указывалось выше, у данной технологии есть и другие названия. QinQ, к примеру, или Stacked VLAN – всё это тоже имеет отношение к 802.1ad. Суть же достаточно проста. 12 бит для номера VLAN хватает только на 4 с небольшим тысячи отдельных сред передачи данных, а когда надо больше – то нужно придумывать что-то другое. Сценарии могут быть различны – провайдеру надо “пробросить” транк клиента, не затрагивая схему нумерации VLAN’ов, надо балансировать нагрузку между субинтерфейсами внутри сети провайдера, либо просто – маловато номеров. Самое простое – сделать ещё одну такую же метку (tag). В этом случае внешней (OuterTag) будет называться метка, которая ближе к заголовку кадра (т.е. которая сразу за SRC MAC), а внутренней (InnerTag) – следующая за ней. Также изменения будут и в названиях VID – VID во внешней метке будет называться SP-VLAN (Service Provider), во внутренней – CE-VLAN (Customer Edge). Самих меток коснутся изменения – если внутренняя сохранит свой вид, то у внешней будет использоваться другой EtherType – вместо 0x8100 там могут быть:

• 0x88a8
• 0x9100
• 0x9200

Притом стандартным является 0x88a8, остальные же два распознаются только частью оборудования (например, старшими линейками роутеров Cisco – значение 0x9200 будет являться стандартным для организации туннелей Q-in-Q между роутерами семейства Cisco 10000). Дополнительным изменением является смена роли “бестолкового” бита CFI у OuterTag. Вместо CFI бит станет называться DEI – Drop Eligible Indicator, и по сути является дополнительным флагом для управления механимом CoS и работает аналогично подобному у Frame Relay. Над данной структурой определены 2 операции – push tag и pop tag. Операция push tag над обычным 802.1Q кадром добавляет новый OuterTag, операция pop tag над QinQ-кадром удаляет OuterTag и возвращает кадр в вид 802.1Q (соответственно, его 802.1Q является бывшим InnerTag’ом). Давайте перейдём к практической части – как это настраивается.

Базовые операции с настройкой 802.1Q на оборудовании Cisco

Начинаем настройку всегда с предположения, что ничего не настроено и не работает. Поэтому заходим на интерфейс и пробуем ввести команду host(config-if)# switchport В случае, если наш коммутатор умный и поддерживает L3, то эта команда в явном виде укажет, что порт должен работать в режиме порта коммутатора, а не routed. Если глупый – пошлёт, сказав, что такой команды нет. Это не страшно. Далее, мы с Вами должны зафиксировать тип транкинга – чтобы не тратилось время на автосогласование типа транка. Мы выберем 802.1Q. host(config-if)# switchport trunk encapsulation dot1q Если надо вернуть автосогласование типа транкинга, то: host(config-if)# switchport trunk encapsulation negotiate Опять же – если коммутатор просто не знает других типов транкинга, кроме 802.1Q, он не сможет выполнить эту команду. Что тоже, в общем-то, не страшно. Эту команду надо делать до переключения интерфейса в транк по той причине, что иначе переключение просто не произойдёт. Теперь фиксируем EtherType транка – помним, что он может не всегда быть 0x8100: host(config-if)# switchport dot1q ethertype тип И включаем в явном виде транк: host(config-if)# switchport mode trunk В общем-то интерфейс теперь работает в режиме транка, и если с другой стороны будет стоять динамическое согласование либо тоже транк – всё будет ОК. Если есть уверенность, что с той стороны тоже в явном виде будет транк, а не динамическое согласование, можно убрать обработку кадров протокола согласования транка (DTP). Это чуть уменьшит трафик (чисто символически, в общем), плюс приведёт к тому, что когда с другой стороны будет динамически настроенный порт, то всё закончится плохо – связь не будет установлена, т.к. наша сторона будет молчать, как пленный партизан, на все запросы. Выключить динамическое согласование транкинга можно так: host(config-if)# switchport nonegotiate Теперь настройка для роутеров. В случае PE-роутера, который будет принимать поток со Stacked VLAN, ему надо будет по внешней метке понять, на какой субинтерфейс отдать поток клиентского трафика. Поэтому на родительском интерфейсе (не на субинтерфейсе!) надо для начала указать используемый EtherType. Это необходимо, чтобы работать с не-Cisco оборудованием, которое использует EtherType = 0x9100 да и вообще – в явном виде указать не помешает. Убирайте разложенные грабли заранее. Команда host(config-if)# dot1q tunneling ethertype значение устанавливает на интерфейсе используемый EtherType, а команда host(config-if)# no dot1q tunneling ethertype возвращает тип к дефолтному 0x8100. После этого нам, скорее всего, захочется создать субинтерфейс, на котором надо будет принимать трафик с нужными SP-VLAN и CE-VLAN. Это делается командой: host(config-subif)# encapsulation dot1q SP-VLAN second-dot1q CE-VLAN Вместо CE-VLAN можно указать слово any, тогда на этот интерфейс будут приходить все “остальные” кадры, для которых не нашлось явно сконфигурированных субинтерфейсов. Также надо отметить, что SP-VLAN будет задаваться явным значением, а CE-VLAN может быть и диапазоном (вида 40-50,70,80).

Заключение

Тема решений класса Metro Ethernet и Carrier достаточно интересна, по крайней мере – надо хорошо представлять базовые вопросы, принципы и терминологию. Как всегда я пишу в этом месте статьи – в случае проявления интереса данный материал может быть (и будет) расширен и дополнен.Дата последнего редактирования текста: 2013-10-05T07:08:21+08:00Возможно, вам будет также интересно почитать другие статьи про на нашей Knowledge BaseЗайдите на сайт под своей учётной записью, чтобы видеть комментарии под техническими статьями. Если учётной записи ещё нет — зарегистрируйтесь, это бесплатно.

LEARN IN Сетевая Академия Cisco

100% онлайн обучениеОфициальные сертификаты CiscoПрофессиональные инструкторыСтенды с реальным оборудованием

[powr-countdown-timer label=»Enter a Label»]

Сетевая Академия Cisco — учебное учреждение основанное корпорацией в 1997 году на базе 64 учебных заведений в США, а в данный момент существующее в 165 странах мира. Наша задача подготовить высококлассных профессионалов в сфере информационных технологий, дать возможность молодым, талантливым и целеустремленным людям найти себя в жизни, освоив одну из самых престижных и востребованных профессий в сфере IT.

Что такое Академия Cisco?

Материалы предоставленные компанией Cisco являются передовыми с точки зрения психологии обучения студентов — выполняя интерактивные задания, лабораторные работы, просматривая высококачественные видеоматериалы, слушатели приобщаются к захватывающему миру информационных технологий. Материал построен таким образом, чтобы вдохновлять студентов, захватывать их воображение и в тоже время мотивировать их на выполнение сложных заданий, что в свою очередь приводит к главному результату — человек становится профессионалом, который любит свою работу и вдохновлен ею.

Выберите курс соответствующий именно Вашему уровню подготовки В Академии Cisco разработаны курсы рассчитанные на слушателей с разным уровнем подготовки. Начинающим карьеру в IT и школьникам подойдет курс IT Essentials, курс CCNA Routing & Switching подойдет тем, кто освоил программу IT Essentials или имеет небольшой опыт работы, и наконец курс CCNP рассчитан на повышение квалификации профессионалов.

Выбрать курсЗаписаться на курс

Используемые источники:

• https://aminux.wordpress.com/2012/06/17/q-in-q/
• https://www.atraining.ru/vlan-tag-switching-in-detail/
• http://learnin.ru/

</table>