По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Компания Juniper является очень крупным производителем сетевого оборудования в мире - после Cisco and Huawei. После того как вы купили, установили и скоммутировали новое оборудование, возникает вопрос о его правильной настройке. Преимуществом коммутаторов от производителя Juniper, в основном, является возможность объединения до шести коммутаторов в одно единое устройство с надежным и удобным управлением портами, сохраняя стабильную и бесперебойную работу сети. Настройка сетевого интерфейса Настройка QoS (качество обслуживания) Virtual Chassis (объединение коммутаторов) Реализация возможности сброса до заводских настроек Настроив данные компоненты, вы сможете реализовать работу сети с использованием в ней большого количества устройств для осуществления передачи трафика. Настройка сетевого интерфейса Интерфейс коммутатора отвечает за реализацию передачи данных между сетью и пользователем, что и является главной задачей коммутатора. Его конфигурация осуществляется с помощью следующих строк кода: root> configure Entering configuration mode [edit] root# edit interfaces [edit interfaces] root# Конфигурация L3: [edit interfaces] root# set em0 unit 0 family inet address 100.0.0.1/30 Где: Em0 - физический интерфейс, а Family inet - позволяет выбрать протокол интерфейса. Команда "show" позволит из Configuration Mode проверить результат вашей настройки: [edit interfaces] root# show em0 { unit 0 { family inet { address 100.0.0.1/30; } } } [edit interfaces] Теперь примените настройки с помощью следующей команды: root# commit commit complete С помощью команды ping осуществим проверку конфигурации: root> ping 100.0.0.2 rapid PING 100.0.0.2 (100.0.0.2): 56 data bytes !!!!! --- 100.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.402/0.719/1.306/0.343 ms Конфигурация L2 root> configure Entering configuration mode [edit] root# edit interfaces em0 [edit interfaces em0] Необходимо задать дуплекс на интерфейсе: [edit interfaces em0] root# set link-mode full-duplex [edit interfaces em0] root# Примечание: L2 - устройства, работающие на канальном уровне, при этом коммутатором занимается фреймами. А L3 взаимодействуют с IP-адресами и осуществляют маршрутизацию. Конфигурация L3 включает большее число параметров за счет расширенного функционала. Настройка Virtual Chassis После правильной настройки интерфейса, следует перейти к объединению коммутаторов, которое позволит облегчить управление устройствами, а также повысить надежность работы сети, за счет взаимозаменяемости устройств. Следует отметить, что коммутаторы Juniper не имеют отдельным порт VCP, поэтому придется настраивать обычный интерфейс в качестве VCP. Конфигурация VCP вручную: Включите все коммутаторы, также вам понадобятся их заводская маркировка, которую следует записать. Для примера используем следующие: CT0216330172 CV0216450257 Включите коммутатор, который будет выполнять функцию master switch, после чего сделайте сброс настройка с помощью следующей строки кода: request system zeroize Перезагрузив систему, выполните следующие строки: ezsetup set system host-name sw_master set system domain-name metholding.int set system domain-search metholding.int set system time-zone Europe/Moscow set system root-authentication plain-text-password set system name-server 10.10.6.26 set system name-server 10.10.6.28 set system services ssh protocol-version v2 set system ntp server 10.10.1.130 version 4 set system ntp server 10.10.1.130 prefer set vlans Management description 10.10.45.0/24 set vlans Management vlan-id 100 set vlans Management l3-interface vlan.1 set interfaces vlan unit 1 family inet address 10.10.45.100/24 set routing-options static route 0.0.0.0/0 next-hop 10.10.45.1 set interfaces ge-0/0/47 unit 0 family ethernet-switching port-mode trunk set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members Management Активируем preprovisioned configuration mode: set virtual-chassis preprovisioned Вносим серийные номера оборудования: set virtual-chassis member 0 serial-number CT02/16330172 role routing-engine set virtual-chassis member 1 serial-number CV0216450257 role routing-engine set virtual-chassis no-split-detection Проверьте результат, с помощью следующей строки: root@sw-master> show virtual-chassis status Обнулите конфигурацию и включайте остальные коммутаторы: request system zeroize Раздел virtual-chassis в конфигурации должен быть пустой, а для подстраховки, используйте команду: delete virtual-chassis Настроим порты VCP для каждого коммутатора. Для данного примера, соедините коммутаторы портами ge-0/0/0 и ge-0/0/1 соответственно. Теперь задайте эти строки кода на каждом из коммутаторов: request virtual-chassis vc-port set pic-slot 0 port 0 request virtual-chassis vc-port set pic-slot 0 port 1 --------------------ВЫВОД---------------------------- root> show interfaces terse Interface Admin Link Proto Local Remote vcp-255/0/0 up up vcp-255/0/0.32768 up up vcp-255/0/1 up up vcp-255/0/1.32768 up up ge-0/0/2 up down ge-0/0/2.0 up down eth-switch Теперь два коммутатора объединились, проверить можно с помощью команды: show virtual-chassis status show virtual-chassis vc-port Если вы захотите добавить дополнительных участников к virtual-chassis, вам будет необходимо очистить конфигурацию нового коммутатора: show interfaces terse | match vcp Если есть, их надо удалить с командой: request virtual-chassis vc-port delete pic-slot 0 port 0 Внесите серийный номер дополнительного устройства: set virtual-chassis member 2 serial-number CT0217190258 role line-card Настройка портов VCP в новом коммутаторе, в котором мы соединяем следующими портами - ge-0/0/0 и ge-0/0/1: request virtual-chassis vc-port set pic-slot 0 port 0 request virtual-chassis vc-port set pic-slot 0 port 1 Теперь проверьте их наличие: show interfaces terse | match vcp НастройкаQoS Технология QoS используется для распределение используемого трафика и ранжирование на классы с различным приоритетом. Технология необходима для увеличения вероятности пропускания трафика между точками в сети. Сейчас мы рассмотрим деление потока трафика с приоритетом на ip-телефонию и видеоконференцсвязь на коммутаторе и использованием настроек по умолчанию class-of-service (CoS). Допустим, что ip-телефоны подключены к коммутатору, а для маркировки ip-пакетов от ip-PBX и других ip-телефонов используются следующие показания DSCP: 46 - ef - медиа (RTP) 24 - cs3 - сигнализация (SIP, H323, Unistim) 32 - cs4 - видео с кодеков (RTP) 34 - af41 - видео с телефона, софтового клиента, кодека (RTP) 0 - весь остальной трафик без маркировки. DSCP - является самостоятельным элементом в архитектуре сети, описывающий механизм классификации, а также Обеспечивающий ускорение и снижение задержек для мультимедийного трафика. Используется пространство поля ToS, являющийся компонентом вспомогательным QoS. Теперь требуется dscp ef и af отнести к необходимым внутренним классам expedited-forwarding и assured-forwarding. За счет конфигурации classifiers, появляется возможность создания новых классов. ex2200> show configuration class-of-service classifiers dscp custom-dscp { forwarding-class network-control { loss-priority low code-points [ cs6 cs7 ]; } forwarding-class expedited-forwarding { loss-priority low code-points ef; } forwarding-class assured-forwarding { loss-priority low code-points [ cs3 cs4 af41 ]; } } ex2200> show configuration class-of-service schedulers sc-ef { buffer-size percent 10; priority strict-high; } sc-af { shaping-rate 20m; buffer-size percent 10; } sc-nc { buffer-size percent 5; priority strict-high; } sc-be { shaping-rate percent 80; buffer-size { remainder; } } Наименования можно выбрать произвольно, но а процент выделенных буферов - в соответствии с необходимостью. Ключевым приоритетом работы QoS является определение трафика с ограничением пропускающей полосы в зависимости от потребности в ней. Шедулеры сопоставляются в соответствии с внутренними классами, в результате которого scheduler-map и classifier необходимо применяется ко всем интерфейсам, используя и описывая их в качестве шаблона. К интерфейсу возможно применять специфические настройки, подразумевающие возможность написания всевозможных scheduler и scheduler-maps для различных интерфейсов. Конечная конфигурация имеет следующий вид: ex2200> show configuration class-of-service classifiers { dscp custom-dscp { forwarding-class network-control { loss-priority low code-points [ cs6 cs7 ]; } forwarding-class expedited-forwarding { loss-priority low code-points ef; } forwarding-class assured-forwarding { loss-priority low code-points [ cs3 cs4 af41 ]; } } } host-outbound-traffic { forwarding-class network-control; } interfaces { ge-* { scheduler-map custom-maps; unit 0 { classifiers { dscp custom-dscp; } } } ae* { scheduler-map custom-maps; unit 0 { classifiers { dscp custom-dscp; } } } } scheduler-maps { custom-maps { forwarding-class network-control scheduler sc-nc; forwarding-class expedited-forwarding scheduler sc-ef; forwarding-class assured-forwarding scheduler sc-af; forwarding-class best-effort scheduler sc-be; } } schedulers { sc-ef { buffer-size percent 10; priority strict-high; } sc-af { shaping-rate 20m; buffer-size percent 10; } sc-nc { buffer-size percent 5; priority strict-high; } sc-be { shaping-rate percent 80; buffer-size { remainder; } } } Перед использованием данной настройки, проверьте командой commit check. А при наличии следующей ошибки, следует учесть следующее: [edit class-of-service interfaces] 'ge-*' One or more "strict-high" priority queues have lower queue-numbers than priority "low" queues in custom-maps for ge-*. Ifd ge-* supports strict-high priority only on higher numbered queues. error: configuration check-out failed В итоге мы не можем указать приоритет "strict-high" только для 5-ой очереди, когда у 7-ой останется приоритет "low". При этом можно решить проблему следующим образом: настроить для network-control приоритет "strict-high". Применив конфигурацию, определенный процент фреймов в очередях будет потеряна. Требуется обнулить счетчики, проверить счетчики дропов через некоторое время, где переменные значения не равны нулю. clear interfaces statistics all show interfaces queue | match dropped | except " 0$" При росте счетчиков дропа в конфигурации есть ошибка. Если вы пропустили описание в class-of-service interfaces шаблоном или в явном виде, то трафик в классах со стопроцентной вероятностью дропнется. Правильная работа выглядит следующим образом: ex2200> show interfaces queue ge-0/0/22 Physical interface: ge-0/0/22, Enabled, Physical link is Up Interface index: 151, SNMP ifIndex: 531 Forwarding classes: 16 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queued: Transmitted: Packets : 320486 Bytes : 145189648 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Queue: 1, Forwarding classes: assured-forwarding Queued: Transmitted: Packets : 317 Bytes : 169479 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Queue: 5, Forwarding classes: expedited-forwarding Queued: Transmitted: Packets : 624 Bytes : 138260 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Queue: 7, Forwarding classes: network-control Queued: Transmitted: Packets : 674 Bytes : 243314 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Переход к заводским настройкам Если вам избавится от вашей конфигурации, которая работает некорректно вы можете сбросить настройки до заводских параметров. Советуем использовать данную функции, предусмотренную производителем оборудования, в случае реальной сложности в поиске ошибки, выполнив конфигурацию заново, вы можете заметно сэкономить свое время. Самый простой способ, это ввод следующей команды: load factory defaults После ввода команды, система оповестит Вас о том, что в данный момент будет осуществлена активация заводских настроек по умолчанию. А с помощью привычной команды "commit" активируем настройки и перезагружаемся. Мы рассмотрели базовые настройки коммутаторов Juniper, позволяющих создание надежной и гибкой сети для различных нужд.
img
Это продолжение статьи про пакетную коммутацию. Первая часть тут. Схемы агрегации каналов берут несколько физических каналов и объединяют их в один виртуальный канал. В целях протоколов маршрутизации и алгоритмов предотвращения петель, таких как связующее дерево, виртуальный канал обрабатывается, как если бы он был одним физическим каналом. Агрегирование каналов используется для увеличения пропускной способности между узлами сети без необходимости замены более медленных физических каналов на более быстрые. Например, два канала 10 Гбит/с можно объединить в один канал 20 Гбит/с, тем самым удвоив потенциальную полосу пропускания между двумя узлами, как показано на рисунке 6. Слово «потенциал» было выбрано тщательно, поскольку агрегированные каналы на практике не масштабируются линейно. Проблема, с которой сталкивается агрегация каналов, заключается в определении, какие пакеты должны быть отправлены по какому элементу связи. Интуитивно это может показаться не проблемой. В конце концов, казалось бы, имеет смысл использовать группу каналов связи в циклическом режиме. Первоначальный фрейм будет отправлен по первому элементу связки, второй фрейм - по второму элементу и так далее, в конечном итоге возвращаясь к первому элементу связки. Таким образом, канал должен использоваться идеально равномерно, а пропускная способность - линейно. В реальной жизни существует очень мало подобных реализаций, в которых агрегированные каналы используются на такой циклической основе, как эта, потому что они рискуют доставить неупорядоченные пакеты. Предположим, что первый кадр Ethernet отправляется первому звену нисходящего канала, а второй кадр - второму элементу нисходящего канала сразу после него. По какой-то причине второй кадр попадает на другой конец раньше первого кадра. Пакеты, содержащиеся в этих кадрах, будут доставлены принимающим узлам в неупорядоченном порядке - пакет два перед пакетом один. Это проблема, потому что теперь на хост возлагается вычислительная нагрузка по переупорядочению пакетов, чтобы можно было правильно собрать всю дейтаграмму. Поэтому большинство поставщиков реализуют хеширование потоков, чтобы гарантировать, что весь поток трафика использует один и тот же элемент пакета. Таким образом, нет никакого риска того, что хост получит пакеты не по порядку, так как они будут отправляться последовательно через один и тот же элемент канала. Хеширование потока работает путем выполнения математической операции над двумя или более статическими компонентами потока, такими как MAC-адреса источника и получателя, IP-адреса источника и получателя, протокол управления передачей (TCP) или протокол дейтаграмм пользователя (UDP). номера портов для вычисления элемента связи, который будет использовать поток. Поскольку характеристики потока статичны, алгоритм хеширования приводит к идентичным вычислениям для каждого кадра или пакета в потоке трафика, гарантируя, что один и тот же канал будет использоваться в течение всего срока службы потока. Хотя хеширование потока решает проблему неупорядоченных пакетов, оно создает новую проблему. Не все потоки имеют одинаковый размер. Некоторые потоки используют большую полосу пропускания, например те, которые используются для передачи файлов, резервного копирования или хранения. Их иногда называют «слоновьими потоками» (elephant flows). Другие потоки довольно малы, например, те, которые используются для загрузки веб-страницы или связи с использованием передачи голоса по IP. Их иногда называют «мышиными потоками» (mouse flows). Поскольку потоки имеют разные размеры, некоторые элементы связи могут работать на полную мощность, а другие - недостаточно. Это несоответствие в использовании возвращает нас к вопросу о линейном масштабировании. Если бы фреймы были сбалансированы по нагрузке через агрегированный набор каналов совершенно равномерно, то добавление новых каналов в набор равномерно увеличило бы емкость. Однако алгоритмы хэширования в сочетании с непредсказуемым объемом потоков трафика означают, что связанные каналы не будут загружаться равномерно. Задача сетевого администратора - понять тип трафика, проходящего через агрегированный канал, и выбрать доступный алгоритм хеширования, который приведет к наиболее равномерному распределению нагрузки. Например, некоторые соображения по этому поводу: Обмениваются ли многие хосты в одном широковещательном домене друг с другом через агрегированный канал? Хеширование против MAC-адресов, найденных в заголовке кадра Ethernet, является возможным решением, потому что MAC-адреса будут разными. Обменивается ли небольшое количество хостов с одним сервером через агрегированный канал? В этом сценарии может не хватить разнообразия MAC-адресов или IP-адресов. Вместо этого хеширование по номерам портов TCP или UDP может привести к наибольшему разнообразию и последующему распределению трафика по агрегированным ссылкам. Протокол управления агрегацией каналов (LACP) При объединении каналов связи необходимо учитывать сетевые устройства на обоих концах канала связи и проявлять особую осторожность, чтобы обеспечить формирование пакета каналов связи при сохранении топологии без петель. Наиболее распространенным способом решения этой проблемы является использование отраслевого стандарта Link Aggregation Control Protocol (LACP), кодифицированного как стандарт 802.3 ad института инженеров электротехники и электроники (IEEE). На каналах, обозначенных сетевым администратором, LACP объявляет о своем намерении сформировать агрегированный канал с другой стороной. Другая сторона, также выполняющая LACP, принимает это объявление, если объявленные параметры действительны, и формирует канал. Как только группа каналов сформирована, агрегированный канал переводится в состояние пересылки. Затем операторы сети могут запросить LACP для получения информации о состоянии агрегированного канала и о состоянии его членов. LACP также знает, когда элемент связки выходит из строя, так как управляющие пакеты больше не проходят через сбойный канал. Эта возможность полезна, так как позволяет процессу LACP уведомлять сетевую операционную систему о необходимости пересчета хэшей потока. Без LACP сетевой операционной системе может потребоваться больше времени, чтобы узнать о сбойном канале, что приведет к хешированию трафика к элементу связи, который больше не является допустимым путем. Существуют и другие протоколы управления агрегацией каналов. В некоторых случаях также возможно создавать пакеты каналов вручную без защиты управляющего протокола. Однако LACP доминирует в качестве стандарта, используемого сетевыми поставщиками, а также ведущими операционными системами и поставщиками гипервизоров для агрегации каналов. Multichassis Link Aggregation Multichassis Link Aggregation (MLAG) - это функция, предлагаемая некоторыми сетевыми поставщиками, позволяющая одному агрегированной связке каналов охватывать два или более сетевых коммутатора. Чтобы облегчить это, специальный протокол управления поставщика будет работать между коммутаторами-членами MLAG, заставляя несколько сетевых коммутаторов действовать так, как если бы они были одним коммутатором, в отношении LACP, протокола связующего дерева (STP) и любых других протоколов. Обычным обоснованием для MLAG является физическая избыточность, когда сетевому инженеру требуется более низкий уровень (например, Ethernet) смежности между сетевыми устройствами (вместо маршрутизируемого соединения), а также требуется, чтобы связка каналов оставалась включенной, если удаленная сторона канала выходит из строя. Распространение связки каналов между двумя или более коммутаторами позволяет выполнить это требование. Рисунок 7 демонстрирует это. В то время как многие сети используют некоторые разновидности MLAG в производстве, другие уклоняются от этой технологии, по крайней мере частично, потому что MLAG является собственностью. Нет такой вещи, как multivendor MLAG. Тенденции к лучшему проектированию сети в сторону от широко рассредоточенных коммутируемых доменов, сценарий, который выигрывает у MLAG. Вместо этого при проектировании сети наблюдается тенденция к ограниченным коммутируемым доменам, взаимосвязанным посредством маршрутизации, что устраняет необходимость в технологиях MLAG. Маршрутизированные параллельные каналы Маршрутизируемые плоскости управления, называемые протоколами маршрутизации, иногда вычисляют набор нескольких путей через сеть с равными затратами. В случае маршрутизации несколько каналов с одинаковой стоимостью могут даже не подключать одну пару устройств; Рисунок 8 демонстрирует это. На рисунке 8 есть три пути: [A, B, D] общей стоимостью 10 [A, D] общей стоимостью 10 [A, C, D] общей стоимостью 10 Поскольку эти три пути имеют одинаковую стоимость, все они могут быть установлены в локальной таблице переадресации в точках A и D. Маршрутизатор A, например, может пересылать трафик по любому из этих трех каналов в направлении D. Когда маршрутизатор имеет несколько вариантов. чтобы добраться до того же пункта назначения, как он решает, какой физический путь выбрать? Как и в случае с ECMP нижнего уровня, ответ - хеширование. Маршрутизированное хеширование ECMP может выполняться в различных областях. Общие поля для хеширования включают IP-адреса источника или назначения и номера портов источника или назначения. В результате хеширования выбирается согласованный путь на протяжении потока L3. Только в случае сбоя канала потребуется перестроить поток и выбрать новый канал пересылки. Механизмы обработки пакетов Шаги, связанные с маршрутизацией одного пакета, могут показаться очень простыми—найдите пункт назначения в таблице, создайте (или извлеките) перезапись заголовка MAC, перепишите заголовок MAC, а затем поместите пакет в правильную очередь для исходящего интерфейса. Как бы просто это ни было, все равно требуется время, чтобы обработать один пакет. На рисунке 9 показаны три различных пути, по которым пакет может быть коммутироваться в сетевом устройстве. Рисунок 9 иллюстрирует три различных пути коммутации через устройство; это не единственные возможные пути коммутации, но они являются наиболее распространенными. Первый путь обрабатывает пакеты через программное приложение, работающее на универсальном процессоре (GPP), и состоит из трех этапов: Пакет копируется с физического носителя в основную память Физический сигнальный процессор, чип PHY, посылает сигнал на GPP (вероятно, но не обязательно, главный процессор в сетевом устройстве), называемый прерыванием. Прерывание заставляет процессор останавливать другие задачи (вот почему это называется прерыванием) и запускать небольшой фрагмент кода, который будет планировать запуск другого процесса, приложения коммутации, для выполнения позже. Когда приложение коммутации запустится, оно выполнит соответствующий поиск и внесет соответствующие изменения в пакет. После коммутации пакета он копируется из основной памяти исходящим процессором. Такое переключение пакета через процесс часто называется коммутацией процесса (по понятным причинам) или иногда медленным путем. Независимо от того, насколько быстрым является GPP, для достижения полной линейной скорости коммутации на высокоскоростных интерфейсах требуется большая настройка - до такой степени, что это практически невозможно. Второй путь коммутации, показанный на рисунке 9, был разработан для более быстрой обработки пакетов: Пакет копируется с физического носителя в основную память Микросхема PHY прерывает GPP; код обработчика прерывания, а не вызов другого процесса, фактически обрабатывает пакет. После коммутации пакета, пакет копируется из основной памяти в процесс вывода, как описано ниже. По понятным причинам этот процесс часто называют interrupt context switching; многие процессоры могут поддерживать коммутацию пакетов достаточно быстро, чтобы передавать пакеты между интерфейсами с низкой и средней скоростью в этом режиме. Сам код коммутации, конечно же, должен быть сильно оптимизирован, потому что коммутация пакета заставляет процессор прекращать выполнение любых других задач (например, обработки обновления протокола маршрутизации). Первоначально это называлось - и до сих пор иногда называется fast switching path. Для действительно высокоскоростных приложений процесс коммутации пакетов должен быть выгружен с главного процессора или любого типа GPP на специализированный процессор, предназначенный для конкретной задачи обработки пакетов. Иногда эти процессоры называются сетевыми процессорами (Network Processing Units -NPU), подобно тому, как процессор, предназначенный для обработки только графики, называется графическим процессором (Graphics Processing Unit-GPU). Эти специализированные процессоры являются подмножеством более широкого класса процессоров, называемых специализированными интегральными схемами (Application-Specific Integrated Circuits -ASIC), и инженеры часто просто называют их ASIC. Переключение пакета через ASIC показано как шаги с 7 по 9 на рисунке 9: Пакет копируется с физического носителя в память ASIC Микросхема PHY прерывает работу ASIC; ASIC обрабатывает прерывание путем переключения пакета. После коммутации пакета пакет копируется из памяти ASIC в процесс вывода, как описано ниже. Многие специализированные ASIC для обработки пакетов имеют ряд интересных функций, в том числе: Структуры внутренней памяти (регистры) настроены специально для обработки различных типов адресов, используемых в сетях. Специализированные наборы команд, предназначенные для выполнения различных требований к обработке пакетов, таких как проверка внутренних заголовков, переносимых в пакете, и перезапись заголовка MAC. Специализированные структуры памяти и наборы инструкций, предназначенные для хранения и поиска адресов назначения для ускорения обработки пакетов Возможность повторного использования пакета через конвейер пакетов для выполнения операций, которые не могут поддерживаться за один проход, таких как глубокая проверка пакетов или специализированные задачи фильтрации.
img
На самом деле, чего только не происходит в компьютерных сетях. Разобраться сложно, а особенно сложно, когда речь заходит об адресации и приеме/передаче данных. Вопрос усложняется тем, что каждый из адресов функционирует на своем уровне модели OSI (Open Systems Interconnection). Но, не нужно переживать. В этой статье, мы самым простым, но профессиональным языком объясним, что такое Media Access Control, или как сокращенно его называют MAC - адрес. Этот тип адреса живет на втором (канальном, или Data Link) уровне модели OSI и является главным адресом на этом уровне.Устраивайтесь поудобнее, наливайте "чайковского" - будем разбираться. Если вы не слышали про модель OSI ранее, то мы очень рекомендуем прочитать сначала статью про OSI, а потом уже приступать к изучению MAC - адреса. Media Access Control (MAC) Address - я выбираю тебя! MAC - адрес представляет собой уникальную комбинацию цифр и букв длиной 48 символов. Фактически, это аппаратный номер оборудования (компьютера, сервера, роутера, порта коммутатора, да чего угодно), который, внимание, присваивается сетевой карте устройства еще на фабрике, то есть в момент производства. Да - да, MAC - адрес устройства это вам не IP - адрес устройства, который можно легко поменять. Этот адрес вшит аппаратно. Хотя, конечно, надо быть честными - как специалисты из Мытищ в гаражных условиях "перебьют" VIN номер автомобиля, так и MAC - адрес можно "перебить". MAC - адрес еще называют уникальным физическим адресом устройства, помогающим идентифицировать устройство среди миллионов других устройств. В стандарте IEEE 802, канальный (второй, Data Link) уровень модели OSI разделен на два подуровня: Logical Link Control (LLC) или подуровень управления логической связью Media Access Control (MAC) или подуровень управления доступом к среде И как раз, как можно догадаться, MAC - адрес используется на втором подуровне, Media Access Control, который является частью канального уровня модели OSI. А теперь поговорим про то, как выглядит MAC - адрес из из чего он состоит. Берем лист А4 и маркер - начинаем рисовать. Форма MAC - адреса "Я нарисоваль!" Вот картинка. Мы правда старались: Стандартный MAC выглядит примерно вот так: 00-50-B6-5B-CA-6A. Смотрите: мак - адрес это 12 - значное шестнадцатеричное число, или 6 - байтовое двоичное число. Чаще всего MAC - адрес представляют именно в шестнадцатеричной системе. На картинки мы изобразили 6 октетов (неких групп), из которых состоит MAC. Каждый из октетов состоит из 2 знаков, итого получается 12 - значное число. Первые 6 цифр (к примеру 00-50-B6) обозначают производителя сетевой карты. Его также называют OUI (Organizational Unique Identifier) - мы отобразили эту часть на картинке выше. Вот, например, известные MAC OUI популярных вендоров: CC:46:D6 - Cisco 3C:5A:B4 - Google, Inc. 3C:D9:2B - Hewlett liackard 00:9A:CD - HUAWEI TECHNOLOGIES CO.,LTD И, собственно, вторые 6 цифр (6 цифр справа) уникальны и идентифицируют NIC (Network Interface Controller). Часто, MAC адреса записывают по-разному: через тире, двоеточие, или точки. Например: 00-50-B6-5B-CA-6A - самая распространенная и привычная для всех форма записи; 00:50:B6:5B:CA:6A - форма записи используется части всего в Linux системах; 005.0b6.5bc.a6a - такой формат записи MAC - адреса используется компанией Cisco. Как узнать MAC - адрес? Итак, чтобы узнать MAC - адрес в UNIX/Linux системах, подключитесь по SSH к вашему серверу и дайте команды: ifconfig -a ip link list ip address show Чтобы узнать MAC - адрес в Windows системах, откройте командную строку машины/сервера. Сделать это можно нажав комбинацию клавиш Win + R, ввести cmd и нажать Enter. Как только откроется консоль, дайте следующие команду: ipconfig /all А если вы обладатель Macbook да и вообще OS X устройства (любите посидеть в Starbucks и здорово провести время на заводе "Флакон"), то сделать нужно следующее: Откройте в Launchliad "Терминал". Введите команду ifconfig. В строке ether будет указан MAC-адрес
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59