По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Компания 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, позволяющих создание надежной и гибкой сети для различных нужд.
В этой статье рассмотрим как решить следующие неисправности:
Виртуальная машина не может подключиться к сети
Нет связи между сетью и одной виртуальной машиной
Невозможно подключиться к сети Интернет
Сбой подключения к или от одной виртуальной машины через TCP/IP
Вы видите одну или более из ошибок:
Destination Host Unreachable
Network error: Connection Refused
Network cable is unplugged
Ping request could not find host (IP address/hostname). Please check the name and try again
Unable to resolve target system name (IP address/hostname).
Решение
Убедитесь, что каждый из последующих шагов подходит для вашей среды. Шаги включают в себя инструкции для выполнения и ссылки на документы для подтверждения шагов и дополнительных корректирующих мер, если они потребуются. Шаги выстроены в наиболее подходящем порядке для выявления и решения проблем. Не пропускайте шаги.
Проверьте, что имя или имена Port Group, связанные с сетевыми адаптерам(и) виртуальной машины, существует и задано правильно. Если нет, то исправьте это с помощью Edit Settings на виртуальной машине, проверьте есть ли галочка напротив Connected.
Удостоверьтесь в отсутствии проблем с хранилищем или ресурсами, так как это может вызывать неполадки с сетью на виртуальной машине. Это можно проверить на консоли виртуальной машины в ESX/ESXi or Virtual Center/vCenter Server через VI/vSphere Client.
Убедитесь, что виртуальный сетевой адаптер присутствует и подключён.
Проверьте правильно ли настроена сеть в гостевой системе на виртуальной машине.
Проверьте правильно ли работает стек TCP/IP.
Если данная виртуальная машина была создана из физической системы, то следует убедиться в отсутствии скрытых сетевых адаптеров.
Убедитесь, что vSwitch на достаточно портов для виртуальной машины.
Убедитесь, что конфигурация IPSec виртуальной машины выполнена правильно и не повреждена.
Наличие двух виртуальных сетевых интерфейсных карт (vNIC) на виртуальной машине поможет исключить проблемы с сетевой интерфейсной картой (NIC) и физической конфигурацией. Чтобы найти возможную проблему:
Если политика балансировки загрузки в режиме Default Virtual Port ID на уровне vSwitch и vDS - оставьте одну виртуальную сетевую интерфейсную карту (vNIC) подключённой к vSwitch или vDS и протестируйте различные комбинации виртуальных(vNIC) и физических (pNIC) сетевых интерфейсных карт, чтобы найти виртуальную машину с отсутствующим соединением.
Если политика балансировки загрузки в режиме IP Hash:
Убедитесь, что порты физического коммутатора настроены как порт-канал.
Прты, к которым подключены сетевые интерфейсные карты (NICs), кроме одного и переключайтесь между всеми портами, включая за раз только один порт. Обратите внимание на комбинации портов и сетевых интерфейсных карт (NIC) при которых виртуальные машины теряют соединение.
Также вы можете проверить выходные данные о работе сети с помощью команды esxtop с параметром n, чтобы найти используемую виртуальной машиной физическую сетевую интерфейсную карту (pNIC). Попробуйте отключать порты физического свитча по одному, чтобы определить, когда виртуальная машина теряет подключение к сети. Это также исключает неправильные настройки физического порта(-ов).
Перед тем как начать чтение этой статьи, советуем ознакомиться с материалом про расчет пути по алгоритму Bellman - ford.
Алгоритм диффузного обновления (Diffusing Update Algorithm -DUAL) - один из двух обсуждаемых здесь алгоритмов, изначально предназначенных для реализации в распределенной сети. Он уникален тем, что также удаляет информацию о достижимости и топологии, содержащуюся в конечном автомате алгоритма. Другие обсуждаемые здесь алгоритмы оставляют удаление информации на усмотрение реализации протокола, а не рассматривают этот аспект работы алгоритма внутри самого алгоритма.
К 1993 году Bellman-Ford и Dijkstra были реализованы как распределенные алгоритмы в нескольких протоколах маршрутизации. Опыт, полученный в результате этих ранних реализаций и развертываний, привел ко "второй волне" исследований и размышлений о проблеме маршрутизации в сетях с коммутацией пакетов, что привело к появлению вектора пути и DUAL.
Поскольку DUAL разработан как распределенный алгоритм, лучше всего описать его работу в сети. Для этой цели используются рисунки 8 и 9. Чтобы объяснить DUAL, в этом примере будет прослеживаться поток A, изучающего три пункта назначения, а затем обрабатываются изменения в состоянии доступности для этих же пунктов назначения. В первом примере будет рассмотрен случай, когда есть альтернативный путь, но нет downstream neighbor, второй рассмотрит случай, когда есть альтернативный путь и downstream neighbor.
На рисунке 8 изучение D с точки зрения A:
A узнает два пути к D:
Через H стоимостью 3.
Через C стоимостью 4.
A не узнает путь через B, потому что B использует A в качестве своего преемника:
A - лучший путь B для достижения D.
Поскольку B использует путь через A для достижения D (пункта назначения), он не будет анонсировать маршрут, который он знает о D (через C) к A.
B выполнит split horizon своего объявления D на A, чтобы предотвратить образование возможных петель пересылки.
A сравнивает доступные пути и выбирает кратчайший путь без петель:
Путь через H помечен как преемник.
Возможное расстояние устанавливается равным стоимости кратчайшего пути, равной 3.
A проверяет оставшиеся пути, чтобы определить, являются ли какие-либо из них downstream neighbors:
Стоимость C составляет 3.
A знает это, потому что C объявляет маршрут к D со своей локальной метрикой, равной 3.
A сохраняет локальную метрику C в своей таблице топологии.
Следовательно, A знает локальную стоимость в C и локальную стоимость в A.
3 (стоимость в C) = 3 (стоимость в A), поэтому этот маршрут может быть петлей, следовательно, C не удовлетворяет условию выполнимости. C не помечен как downstream neighbors.
Downstream neighbors в DUAL называются возможными преемниками. Предположим, что канал [A, H] не работает. DUAL не полагается на периодические обновления, поэтому A не может просто ждать другого обновления с достоверной информацией. Скорее A должен активно следовать альтернативному пути. Таким образом, это диффузный процесс обнаружения альтернативного пути. Если канал [A, H] не работает, учитывая только D:
A проверяет свою локальную таблицу на предмет возможных преемников (Downstream neighbors).
Возможных преемников нет, поэтому A должен найти альтернативный путь без петель к D (если он существует).
A отправляет запрос каждому соседу, чтобы определить, есть ли какой-либо альтернативный путь без петель к D.
В C:
Преемником C является E (не A, от которого он получил запрос).
Стоимость E ниже, чем стоимость A для D. Следовательно, путь C не является петлей.
C отвечает со своей текущей метрикой 3 на A.
В B:
А - нынешний преемник Б.
Посредством запроса B теперь обнаруживает, что его лучший путь к D потерпел неудачу, и он также должен найти альтернативный путь.
Обработка B здесь не расписывается, а предоставляется выполнить самостоятельно.
B отвечает A, что у него нет альтернативного пути (отвечает бесконечной метрикой).
A получает эти ответы:
Путь через C - единственный доступный, его стоимость 4.
A отмечает путь через C как его преемника.
Других путей к D нет. Следовательно, нет подходящего преемника (downstream neighbor).
На рисунке 9 пункт назначения (D) был перемещен с H на E. Это будет использоваться во втором примере.
В этом примере есть возможный преемник (downstream neighbor).
Изучение D с точки зрения A:
A узнает два пути к D:
Через H стоимостью 4.
Через C стоимостью 3.
A не узнает никакого пути через B:
У B есть два пути к D.
Через C и A стоимостью 4.
В этом случае B использует как A, так и C.
B выполнит split horizon свого объявления D на A, потому что A помечен как преемник.
A сравнивает доступные пути и выбирает кратчайший путь без петель:
Путь через C отмечен как преемник.
Возможное расстояние устанавливается равным стоимости кратчайшего пути, равной 3.
A проверяет оставшиеся пути, чтобы определить, являются ли какие-либо из них downstream neighbors:
Стоимость H составляет 2.
2 (стоимость в H) = 3 (стоимость в A), поэтому этот маршрут не может быть петлей. Следовательно, H удовлетворяет условию выполнимости.
H отмечен как возможный преемник (downstream neighbors).
Если канал [A, C] не работает, просто рассматривая A:
A проверит свою таблицу локальной топологии на предмет возможного преемника.
Возможный преемник существует через H.
A переключает свою локальную таблицу на H как лучший путь.
Распространяющееся обновление не запускалось, поэтому пути не были проверены или пересчитано.
Следовательно, допустимое расстояние изменить нельзя. Он остается на 3.
A отправляет обновление своим соседям, отмечая, что его стоимость достижения D изменилась с 3 до 4.
Как вы можете видеть, обработка, когда существует возможный преемник, намного быстрее и проще, чем без него. В сетях, где был развернут протокол маршрутизации с использованием DUAL (в частности, EIGRP), одной из основных целей проектирования будет ограничение объема любых запросов, генерируемых в случае отсутствия возможного преемника. Область запроса является основным определяющим фактором того, как быстро завершается двойной алгоритм и, следовательно, как быстро сходится сеть.
На рисунке 10 показан базовый законченный автомат DUAL.
Вещи, входящие в route gets worse (ухудшение маршрута), могут представлять собой:
Отказ подключенного канала или соседа
Получение обновления для маршрута с более высокой метрикой
Получение запроса от текущего преемника
Получение нового маршрута от соседа
Обнаружен новый сосед, а также маршруты, по которым он может добраться
Получение всех запросов, отправленных соседям, когда маршрут ухудшается