JUNOS
Материал из Xgu.ru
Содержание
[править] Control Plane и Forwarding Plane
[править] Иерархическая структура интерфейса командной строки JUNOS
Работа с командной строкой в JUNOS разделяется на 2 режима:
[править] Operational Mode
Команды, которые нам доступны в Operational Mode:
[править] Configuration Mode
В JUNOS используется 2 конфигурации:
Для того, чтобы конфигурация-кандидат стала активной, в режиме конфигурирования нужно ввести команду «Commit»:
Чтобы зайти в определенный контекст для настройки используется команда «Edit»:
Доступные контексты для редактирования:
[править] Настройка интерфейсов
Для того, чтобы настроить интерфейс нужно перейти в контекст «Interfaces»:
Иерархия настройки интерфейсов:
[править] L3 настройки интерфейса
Можно сразу из Configuration Mode посмотреть, что мы настроили набрав команду «show»:
Применим наши настройки командой «Commit»:
Проверим доступность IP на другой стороне канала:
[править] L2 настройки интерфейса
L2 настройки задаются в следующем контексте:
Задать дуплекс на интерфейсе:
Посмотреть состояние интерфейсов и назначенные IP адреса (аналог sh ip int bri в Cisco):
[править] Именования интерфейсов в JUNOS
В JUNOS используется следующая схема именования интерфейсов:
[править] Таблица маршрутизации в JUNOS
В JUNOS можно создавать несколько таблиц маршрутизации. Главная таблица называется inet.0 и содержит ipv4 юникаст маршруты. По-умолчанию созданы следующие таблицы:
Как читать вывод команды «show route»:
[править] Forwarding Table
Посмотреть, что в ней находится можно командой «show route forwarding-table»:
[править] Route Preference
| Протокол | Приоритет по умолчанию |
|---|---|
| Directly connected network | 0 |
| Local | 0 |
| Static Route | 5 |
| OSPF internal route | 10 |
| RIP | 100 |
| OSPF AS external routes | 150 |
| eBGP и iBGP | 170 |
[править] Настройка OSPF в JUNOS
[править] Настройка BGP в JUNOS
[править] Пакетная фильтрация (Stateless Firewall Filter) в JUNOS
Блоки, из которых строятся правила фильтрации:
В «From» можно указывать следующие значения и их связки:
В «Then» можно указывать следующие значения:
Настройка выглядит следующим образом:
Теперь применяем фильтр на интерфейс:
Не забудьте правильно выбрать направление для фильтра:
[править] Настройка коммутаторов под управлением JUNOS
Настройка порта в режим access:
Настройка порта в режим trunk:
Настройка native vlan на trunk порту:
Ассоциация RVI и VLAN:
[править] Настройка VLAN
[править] Дополнительная информация
На сайте Juniper Networks есть курс на русском языке «JUNOS как второй язык», рассказывающий о сравнении языка командной строки Cisco IOS и Juniper JUNOS. Может быть очень полезен для инженеров, которые уже освоили Cisco IOS, но впервые столкнулись с оборудованием Juniper.
Более подробную информацию о настройке сетевого оборудования под управлением JUNOS можно получить из официальной документации Juniper.
Junos OS Overview
Junos OS is the single operating system that powers Juniper’s broad portfolio of physical and virtual networking and security products.
Junos OS Overview
Juniper Networks provides high-performance network devices that create a responsive and trusted environment for accelerating the deployment of services and applications over a single network. The JunosВ® operating system (Junos OS) is the foundation of these high-performance networks.
Junos OS includes the following architecture variations:
Junos OS FreeBSD 6 on bare metal. This is Junos OS based on a FreeBSD 6 kernel.
Junos OS FreeBSD 10 on bare metal. This is Junos OS based on an upgraded FreeBSD kernel. Starting with Junos OS Release 15.1, certain hardware platforms run Junos OS with upgraded FreeBSD. Starting in Junos OS Release 16.1, Junos OS with upgraded FreeBSD can run as a guest virtual machine (VM) on a Linux VM host. For more on which platforms run Junos OS with upgraded FreeBSD, see Release Information for Junos OS with Upgraded FreeBSD.
Junos OS Evolved. See Introducing JunosВ® OS Evolved and the JunosВ® OS Evolved Software Installation and Upgrade Guide for more information about Junos OS Evolved.
Unlike other complex, monolithic software architectures, Junos OS incorporates key design and developmental differences to deliver increased network availability, operational efficiency, and flexibility. The following are key advantages to this approach:
One Operating System
Unlike other network operating systems that share a common name but splinter into many different programs, Junos OS is a single, cohesive operating system that is shared across all network devices and product lines. This allows Juniper Networks engineers to develop software features once and share these features across all product lines simultaneously. Because features are common to a single source, they generally are implemented the same way for all product lines, thus reducing the training required to learn different tools and methods for each product. Because all Juniper Networks products use the same code base, interoperability between products is not an issue.
One Modular Software Architecture
Although individual modules of Junos OS communicate through well-defined interfaces, each module runs in its own protected memory space, preventing one module from disrupting another. This separation enables the independent restart of each module as necessary. This is in contrast to monolithic operating systems where a malfunction in one module can ripple to other modules and cause a full system crash or restart. This modular architecture then provides for high performance, high availability, security, and device scalability not found in other operating systems.
The Junos OS is preinstalled on your Juniper Networks device when you receive it from the factory. Thus, when you first power on the device, all software starts automatically. You simply need to configure the software so that the device can participate in the network.
You can upgrade the device software as new features are added or software problems are fixed. You normally obtain new software by downloading the software installation packages from the Juniper Networks Support Web page onto your device or onto another system on your local network. You then install the software upgrade onto the device.
Juniper Networks routing platforms run only binaries supplied by Juniper Networks, and currently do not support third-party binaries. Each Junos OS image includes a digitally signed manifest of executables that are registered with the system only if the signature can be validated. Junos OS will not execute any binary without a registered signature. This feature protects the system against unauthorized software and activity that might compromise the integrity of your device.
Secure Boot
Secure Boot is a significant system security enhancement based on the UEFI standard (see www.uefi.org). It works by safeguarding the BIOS itself from tampering or modification and then maintaining that protection throughout the boot process.
The Secure Boot process begins with Secure Flash, which ensures that unauthorized changes cannot be made to the firmware. Authorized releases of Junos OS carry a digital signature produced by either Juniper Networks directly or one of its authorized partners. At each point of the boot-up process, each component verifies the next link is sound by checking the signature to ensure that the binaries have not been modified. The boot process cannot continue unless the signature is correct. This «chain of trust» continues until the operating system takes control. In this way, overall system security is enhanced, increasing resistance to some firmware-based persistent threats.
Figure 1 shows a simplified version of this “chain of trust.”
Secure Boot requires no actions on your part to implement. It is implemented on supported hardware by default.
FIPS 140-2 Security Compliance
For advanced network security, a special version of Junos OS, called Junos-FIPS 140-2, is available. Junos-FIPS 140-2 provides customers with software tools to configure a network of Juniper Networks devices in a FIPS environment. FIPS support includes:
Upgrade package to convert Junos OS to Junos-FIPS 140-2
Revised installation and configuration procedures
Enforced security for remote access
FIPS user roles (Crypto Officer, User, and Maintenance)
FIPS-specific system logging and error messages
IPsec configuration for Routing Engine–to–Routing Engine communication
Enhanced password creation and encryption
Starting in Junos OS Release 15.1, Junos-FIPS is packaged in a domestic image only: a single Junos OS image supports both domestic and FIPS features. Users that have the FIPS credentials and permission to login can flip between a regular Junos image and FIPS image.
Junos-FIPS has special password requirements. FIPS passwords must be between 10 and 20 characters in length. Passwords must use at least three of the five defined character sets (uppercase letters, lowercase letters, digits, punctuation marks, and other special characters). If Junos-FIPS is installed on the device, you cannot configure passwords unless they meet this standard.
Junos как универсальный язык
В данный момент на рынке телекоммуникационного оборудования существует не один, и даже не два вендора, которые предлагают свои собственные разработки в области управления своим оборудованием, предоставляя пользователю различные варианты операционных систем установленных повсеместно на предложенных ими решениях.
Компания Juniper Networks так же представляет свою собственную операционную систему Junos, которая является их личной разработкой и устанавливается на все оборудование Juniper networks.
Чем же таким примечательна система Junos? Ответ на этот вопрос можно начать с того, что данная ОС ставится практически без изменений на любое оборудование компании, поэтому какую бы железку вы не получили в свое распоряжение, вы всегда найдете знакомый синтаксис команд, и всегда поймете, на какой уровень иерархии системы стоит переместиться, что бы настроить нужный вам функционал. Это очень удобно, потому что зачастую у других вендоров, можно встретить различные приложения их ОС на разных типах оборудования, что усложняет их настройку и добавляет проблем администраторам и инженерам.
Хотелось бы подробнее остановиться на особенностях самой ОС, рассказать о фишках и принципах работы.
ОС Junos является модульной системой, основанной на OS FreeBSD, и доработанной инженерами корпорации под собственные цели и нужды. Что такое модульная система? Это означает что вся работа ОС разбита на отдельные процессы, которые работают независимо друг от друга, и в случае сбоя какого либо процесса, нам вовсе не придется полностью перезапускать всю систему, нарушая работу оборудования на длительный срок, а всего лишь перезапустить этот процесс, что является несомненным плюсом и очень важным при работе на живой сети, с заданными требованиями к времени восстановления и отказоустойчивой работой.
С самого начала хотелось бы показать общий вид конфигурации ОС Junos, просто для общего ознакомления.
!
lab@mxA-1> show configuration
## Last commit: 2012-05-10 14:33:27 UTC by root
version 11.2R1.10;
system <
host-name mxA-1;
root-authentication <
encrypted-password «$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1″; ## SECRET-DATA
ssh-dsa «ssh-dss AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gChVuBCB+ERULMdgRvM5uGhC/gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/Jle4Uqnjv7DAAAAFQDZaqA6QAgbW3O/zveaLCIDj6p0dwAAAIB1iL+krWrXiD8NPpY+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBHx9elwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF2KHBSIxL51lmIDW8Gql9hJfD/Dr/NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu2C8UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= configurator@server1.he»; ## SECRET-DATA
>
login <
user lab <
uid 2000;
class super-user;
authentication <
encrypted-password»$1$84J5Maes$cni5Hrazbd/IEHr/50oY30″; ## SECRET-DATA
>
>
>
services <
ftp;
ssh;
telnet;
>
syslog <
user * <
any emergency;
>
file messages <
any notice;
authorization info;
>
file interactive-commands <
interactive-commands any;
>
>
>
interfaces <
fxp0 <
description «MGMT INTERFACE — DO NOT DELETE»;
unit 0 <
family inet <
address 10.210.14.131/27;
>
>
>
>
!
Это простейший пример настроек необходимых для начала работы с устройством Juniper Networks, которые мы обсудим дальше.
Рассмотреим командного интерфейса системы, описания основных режимов и принципов работы.
Вторым видом системы помощи в OS Junos является очень сильный раздел помощи по применению различных команд, и настройки сервисов. Данный раздел можно просмотреть с помощью команды help:
!
!
lab@mxA-1> help topic bgp examples
Examples: Configuring BGP Groups, Peers, and Confederations
Enable BGP and define an EBGP group that recognizes all BGP systems in AS
56 as peers:
[edit]
routing-options <
autonomous-system 23;
>
protocols <
bgp <
group 23 <
type external;
peer-as 56;
!
!
Можно увидеть, что мы получили подсказку по настройке протокола BGP с простыми примерами. Это очень сильный инструментарий встроенный в ОС, о котором не стоит забывать.
Давайте рассмотрим саму структуру конфигурации оборудования фирмы Juniper network.
OS Junos имеет иерархическую и очень логичную структуру. Для того что бы описать настройки какого либо сервиса, будь то протоколы, безопасность, системные настройки, необходимо перейти на соответствующий уровень иерархии и осуществить все настройки там,не перемещаясь по всей конфигурации туда суда. Для перехода на необходимой уровень иерархии надо воспользоваться командой «edit»
Например нам надо настроить протоколы на PE оборудовании нашей сети. Мы заходим на уровень: protocols
!
!
lab@mxA-1> configure
Entering configuration mode
[edit]
lab@mxA-1# edit protocols
[edit protocols]
lab@mxA-1#
!
!
на данном примере видно, что мы находимся на уровне настройки протоколов и можем осуществить настройки данного уровня. Так же дела обстоят с любыми другими настройками OS. Для перемещения на уровень иерерахии вверх необходимо воспользоваться командой up
!
!
lab@mxA-1# edit protocols
[edit protocols]
lab@mxA-1# edit ospf
[edit protocols ospf]
lab@mxA-1# up
[edit protocols]
lab@mxA-1#
!
!
Из примера видно как работает эта команда. Для поднятия на самый верхний уровень необходимо воспользовать командой top.
!
!
[edit protocols]
lab@mxA-1# edit ospf area 0.0.0.0
[edit protocols ospf area 0.0.0.0]
lab@mxA-1# top
[edit]
lab@mxA-1#
!
!
Мы видим что с помощью команды top осуществили переход на самый верхний уровень конфигурации.
Помимо конфигурирования по уровням иерархии, перемещаясь с помощью команд: top, up, edit возможно осуществлять конфигурирование «от корня» т.е. постоянно находясь на верхнем уровне иерархии, просто пользуясь командой »set», и забирвая команды с полным набором пути до необходимого уровня иерархии:
!
!
lab@mxA-1# set protocols ospf area 0.0.0.0 interface all
[edit]
lab@mxA-1#
!
!
мы так и остались на верхнем уровне иерархии не опускаясь до уровня протоколов.
Так же необходимо рассказать о команде «run».
Команда run используется для того что бы выполнять команды оперативного режима из режима конфигурирования. Это очень удобно во время работы, когда очень надоедает прыгать туда сюда без остановки, что бы проверить работу ваших новых настроек.
!
!
[edit]
lab@mxA-1# run show interfaces ge-1/1/9
Physical interface: ge-1/1/9, Enabled, Physical link is Up
Interface index: 159, SNMP ifIndex: 531
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
Device flags: Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags: None
CoS queues: 8 supported, 8 maximum usable queues
Current address: 80:71:1f:c2:ec:81, Hardware address: 80:71:1f:c2:ec:81
Last flapped: 2012-05-07 18:07:16 UTC (2d 11:24 ago)
Input rate: 0 bps (0 pps)
Output rate: 0 bps (0 pps)
Active alarms: None
Active defects: None
!
!
Как видно из примера, мы посмотрели свойства интерфейса ge — 1/1/9 из режима конфигурирования. Команда «run» в отличае от подобных команд аналогов, у других OS позволяет выполнять любые действия, доступные из операционного режима OS.
Для просмотра настройк того или иного уровня мы просто указываем что нам необходимо увидеть:
!
!
lab@mxA-1> show configuration protocols
!
!
После более длительного общения с Junos вы привыкните к тому как удобно располагаются настройки и как приятно читать конфигурацию.
Давайте рассмотрим по порядку варианты:
2. Compare. Очень удобная функция что бы проверить результаты настроек конфига, который недавно был добавлен. С помощью этой команды можно посмотреть как изменился конфиг после того как вы туда что либо добавили.
!
lab@mxA-1# show | compare
[edit]
+ protocols <
+ ospf <
+ area 0.0.0.0 <
+ interface all;
+ >
+ >
+ >
[edit]
lab@mxA-1#
!
Видно что мы добавили к конфигурации раздел ospf где сказали что все интерфейсы маршрутизатора задействованы в процессе ospf.
3. Команды find match exept count используются для анализа вывода информации на экран терминала, в основном для поиска необходимых значений, среди того множества информации что зачастую выпадает на экран.
4. С помощью команды save мы можем сохранить запрошенные данные в файл для дальнейшего использования. Файл будет храниться на жестком диске нашего оборудования, доступ к которому осуществляется через ftp сервер.
В конце статьи хотелось бы привести основной список быстрых клавиш для работы в ОС Junos:
Это основные особенности и принципы работы с OS Junos, которые должны помочь всем в работе с оборудованием компании Juniper network.
Juniper Hardware Architecture
Тот же вышеупомянутый Микротик при навешивании на его интерфейсы порядка 25 фильтров теряет в производительности почти в 20 раз (кому интересно, можно посмотреть тут), в то время как тот же MX80 реализует выполнение фильтров аппаратно, что позволяет ему не терять в производительности. Еще одним жирным минусом софтоварных решений является то, что CPU обрабатывает и control plane и участвует в обработке data plane одновременно. Если, к примеру, загрузка процессора в следствии высокой утилизации интерфейсов поднимется до критического значения (у разных моделей по разному — для кого то 80 процентов норма, кто то при 35 уже захлебывается — свичи Nokia при загрузке 33-35 процентов по 2-3 секунды думают после введения команды или нажатия на tab), то control plane может начать рассыпаться.
Маршрутизаторы Juniper относятся к hardware-based решениям. Помимо вышесказанного, маршрутизаторы Juniper имеют раздельный control и data plane, о чем мы поговорим чуть позже.
Немного поговорим о софте: JunOS OS
JunOS OS — это FreeBSD, которую переработали инженеры Juniper. JunOS, в отличии от IOS (не IOS XR) имеет модульную архитектуру — состоит из ядра и процессов, которые отвечают только за свою отдельную функцию. Под каждый процесс выделяется часть памяти. Что это нам дает? Если у нас ломается какой то из процессов, предположим процесс, отвечающий за vrrp, то он не тянет за собой все остальные процессы и тот же rpd или ppmd процессы будут работать. Естественно для отказоустойчивого оборудования это огромный плюс.
Примечание: Если посмотреть на тот же IOS XR, то он, в отличии от первоначальной IOS, тоже построен по модульной схеме.
Итак, одним из самых важных элементов JunOS OS является ядро, как и у FreeBSD оно монолитное. Плюсы и минусы монолитного ядра мы рассматривать здесь не будем, если кому интересно то можно почитать например на википедии. Ядро выполняет базовые функции ОС — управление процессами и взаимодействие между ними, за разделение доступа процессов к памяти, процессору и другим ресурсам RE. За остальные функции — управление оборудованием, маршрутизацию, мониторинг состояния железа и т.д. отвечают специальные процессы (daemons), которые стартуют при загрузке системы.
Если какой-то из процессов при загрузке не может запуститься по каким либо причинам, то он будет перезапущен. Если перезапуск не приведет к положительному результату, то информация о проблеме с данным процессом будет сгенерирована в лог для того, что бы инженеры могли разобраться с причиной возникновения проблемы и пофиксить ее.
В JunOS OS очень много различных процессов, поэтому мы разберем самые важные из них: 
mgd — management daemon. Данный процесс отвечает за управление оборудованием и другими процессами, CLI является его клиентом. Именно благодаря mgd мы можем пользоваться такими функциями, как rollback, private conguration mode, выводить часть конфигурации в inacive или применять apply-группы.
dсd — Device control daemon. Данный процесс отвечает за конфигурацию интерфейсов. Именно он позволяет нам сконфигурировать несуществующий интерфейс. Данный демон передаст в routing socket информацию о сконфигурированном интерфейсе, что бы rpd впоследствии смог добавить маршрут в таблицу маршрутизации.
К примеру когда мы вводим команду:
set interfaces xe-0/0/0 unit 0 family inet address 10.0.0.1/30
то dcd передает в routing socket значения IFD, IFL, IFF и IFA, маску сети, бродкатный адрес.
IFD — interface device — физический порт на маршрутизаторе (xe-0/0/0);
IFL — interface logical — номер логического интерфейса (unit 0);
IFF — interface family — семейство адресов (family inet);
IFA — interface address — сам адрес (10.0.0.1).
chassisd — chassis daemon. Один из самых важных процессов в JunOS. Именно он отвечает за мониторинг состояния всех компонентов маршрутизатора (от напряжения на различных узлах маршрутизатора до скорости вращения вентиляторов). В случае каких либо проблем данный демон отключит плату или/и маршрутизатор во избежании поломки или передаст информацию о проблеме alarmd/craftd демонам, а они в свою очередь, сгенерируют сообщения в лог и включат какой либо индикатор craft-панеле маршрутизатора.
rpd — routing protocol daemon. Данный процесс отвечает за все протоколы маршрутизации, от rip до bgp. Он отвечает за поддержание соседства между устройствами и обмен между ними маршрутной информацией, выбор лучшего маршрута, составление таблиц маршрутизации и таблицы форвардинга, которая используется непосредственно для продвижения пакетов.
Примечание: у rpd есть помощник ppmd, процесс, который отвечает за генерацию и прием периодических сообщений — например протокола BFD. К нему мы вернемся в следующей статье, когда будем говорить об отказоустойчивости оборудования Juniper.
Другие процессы мы рассматривать не будем, если интересно, то список всех процессов с кратким описанием JunOS представлен тут. Естественно описания процессов на английском языке.
Теперь рассмотрим из чего же состоит маршрутизатор Juniper (рассматривать будем на примере MX серии):
И так, маршрутизаторы Juniper состоят из нескольких основных частей:
— RE (routing engine)
— PFE (packet forwarding engine)
— SCB (Switch and Control Board)
— Midplane
Естественно, маршрутизатор не сможет работать без блока вентиляторов или например блоков питания. Но данные части выполняют строго определенную функцию и не являются интеллектуальными устройствами.
Рассмотрим назначение и состав каждого элемента отдельно.
Routing Engine
RE — является мозгом маршрутизатора. Он отвечает за работу протоколов маршрутизации (поддержание соседства, обмен маршрутной информацией, выбор лучшего маршрута и т.д.); за управление маршрутизатором; за сбор и хранение статистики по интерфейсам, сбор логов и хранение необходимых фалов.
Спецификации RE можно посмотреть на сайте Juniper.
В JunOS очень мощным инструментом является политики, но так как в подавляющем большинстве случаев политики связаны с протоколами маршрутизации — что принимаем, что анонсируем — то и исполняются они на RE. Так же RE обрабатывает пакеты, обработку которых нельзя (либо очень сложно) реализовать в железе — это IP пакеты с опциями, mpls фреймы с меткой 1, ICMP запросы к маршрутизатору, управление по telnet или ssh.
По сути RE является полноценным сервером, который имеет CPU, RAM, HDD/SSD, Ethernet port, USB port и т. д. Зачем нужен CPU и RAM я думаю пояснять не надо, назначение остальных компонентов необходимо пояснить:
CF card — карта памяти. Данная карта предназначена для хранения актуальной конфигурации и используемой версии JunOS OS.
HDD/SSD — жесткий или твердотельный накопитель. Данный носитель предназначен для хранения логов и файлов.
USB-port. Данный порт предназначен для подключения внешнего носителя, используется например для загрузки и восстановлении системы. Порядок загрузки JunOS имеет следующий вид: сначала USB-flash disk, далее CF-card и в последнюю очередь HDD/SSD. На некоторых RE есть два USB порта, к примеру на RE MX104.
Ethernet-port. Назначение это порта — управление маршрутизатором. Как правило на RE не один, а целых три порта:
— ethernet
— console
— AUX
Ethernet — порт используется для управления оборудованием (out-of-band management). Данный порт помечается в системе как fxp0.
Если воспользоваться командой show interfaces terse, то помимо интерфейса fxp0, можно увидеть и интерфейсы em0 и em1. Эти интерфейсы предназначены для связи RE с остальными элементами маршрутизатора (сервисные карты, линейные карты).
Интерфейс fxp0 не всегда используется — как видите на тестовом маршрутизаторе fxp0 интерфейс в down, так как в данный порт не подключен патчкорд, о чем свидетельствует предупреждение:
Console — порт предназначен для консольного доступа.
Auxulary — вспомогательный порт. По сути является подобием console порта, но имеет существенное отличие: если вы подключитесь к маршрутизатору в консольный порт во время загрузки, то увидите лог загрузки JunOS OS. Auxulary порт в момент загрузки ОС не доступен, доступ к оборудованию вы получите только после загрузки маршрутизатора. К тому же с помощью данного порта можно подключиться к другому устройству в консольный порт.
На маршрутизатора серии MX (за исключением младшей линейки MX5-MX80), RE устанавливается в фабрику коммутации (SCB — о ней будет ниже). Как правило для высокой отказоустойчивости RE устанавливают по два — одни мастер, второй бекап (как это работает будет описано в следующей статье). Если RE в данный момент является мастером, то он не поддерживает горячую замену (точнее сказать вы можете его вытащить и вставить “на живую”, но если у вас не настроен GRES/GR или GRES/NSR — вы получите потерю трафика). А вот бекапный RE поддерживает горячую замену.
В процессе работы вы можете перейти с мастер RE на бекапный. Хранящиеся на жестком диске файлы между RE не синхронизируются и при удалении или добавлении файла на жесткий диск одного RE, вы не удаляете или не добавляете файл на второй RE. Это стоит учитывать например при обновлении софта (может быть что на одном из RE места нет, когда на втором его полно и т. д.).
Packet Forwarding Engine
Если RE является мозгом маршрутизатора, то PFE руками и ногами. Именно через PFE обрабатывает весь трафик, включая и трафик управления (если управление производится не через console или management порт на самом RE). PFE состоит из программируемых чипов, которые позволяют производить аппаратано:
— поиск next-hop;
— выполнять ip/mpls/mac lookup;
— применять QoS;
— применять полисеры;
— применять фильтрацию;
— тyннелирование.
PFE установлен на интерфейсной карте. Есть платы с 1-м, 2-мя или 4-мя PFE, каждый PFE обслуживает только свою группу интерфейсов и взаимодействует с другими PFE через SCB. В составе интерфейсной карты есть CPU, который управляет всеми PFE. Связь между PFE и RE производится через встроенный в плату SCB гигабитный свич.
Примечание: все интерфейсные карты поддерживают горячую замену.
Мы рассмотрим состав PFE на примере Trio чипсета. Логически чипсет состоит из нескольких блоков:
Memory and Buffering block — данный блок обеспечивает взаимодействие между всеми другими блоками. В обычных платах (без индекса Q) выполняет и функции блока очередей (естественно в более урезанно варианте), а в платах с большой емкостью выполняет функцию блока интерфейсов.
Lookup block — многоядерный чип, который выполняет ip или mpls lookup, производит изменение заголовков пакета, применение фильтров, шейперов, QoS. Именно данный блок является сердцем PFE. Блок работает с заголовками пакетов и может анализировать заголовки размером до 256 байт (что позволяет реализовать различные сервисы, типа защиты от DDOS).
Interface block – данный блок присутствует на платах с малой пропускной способностью и выполняет функцию предварительной классификации входящих пакетов. Если данный блок отсутствует, то эту функцию выполняет блок буферизации.
Dense Queuing block – блок расширенных очередей. Представлен на платах с индексом Q и позволяет реализовать H-QoS. При отсутствии данного блока его функции(естественно в урезанном формате) ложатся на блок буферизации.
Аппаратно данные блоки представлены следующими чипами:
Блоки связаны между собой HSL2 линками, что позволяет им быстро обмениваться данными.
На рынке существует большой выбор линейных карт MPC, от MPC1 до MPC9E.
Полный список всех линейных карт представлен на сайте Juniper. Версии отличаются количеством установленных PFE (MPC1 — 1 PFE, MPC2 — 2 PFE, MPC3E — 1 PFE но расширенной версии). Сами же PFE, установленные в данные платы отличаются по версиям установленных чипов (стандартный или расширенный) и количеством установленных чипов (например карта MPC4E использует два PFE, в котором установлено по 4 LU блока). Конечно, помимо улучшения установленных чипов и их количества, изменяется и количество памяти SRAM/DRAM, иначе пакеты просто некуда будет буферизировать. Максимальное количество PFE на одной плате 4, всего может быть 1, 2 или 4 PFE в составе одной линенйной карты.
Switch and Control Board
Но пропускная способность маршрутизатора в целом зависит не только от PFE, еще одним важным звеном является SCB. Иногда именно эта плата может стать узким местом. Данная плата отвечает за коммутацию пакетов между различными PFE и связность между RE и PFE. Ко всему прочему RE устанавливается в SCB. Если данная плата не содержит мастер RE, то она поддерживает горячую замену (потерю трафика можно получить, если карты работают в режиме без резервирования 3+0).
В составе SCB есть три главных компонента: две фабрики коммутации и встроенный гигабитный свич. Поговорим о каждом по отдельности.
Встроенный гигабитный свичпредназначен для организации связи между всеми элементами маршрутизатора. У каждой платы в составе MX-маршрутизатора есть два гигабитных внутренних интерфейса (в выводе выше были представлены два em интерфейса на RE), которыми они подключаются к двум свичам (один на основной, второй на резервный SCB). Именно через этот интерфейс происходит передача информации между RE и PFE (и между RE). Если PFE принимает пакет, который должен быть обработан в RE, то именно через этот гигабитный линк пакет передается в RE, через него же происходит передача например forwarding table от RE к PFE или обратная передача значений счетчиков с интерфейсов от PFE к RE. На SCB есть гигабитный внешний интерфейс, через который можно подключиться к любой из установленных плат.
Из вывода ниже видно, что у нас установлены две линейные карты в слот 0 и 1:
Теперь если посмотреть на состояние линков встроенного свича, видно, что 0 и 1 линк подключены к линейным картам 0 и 1, а 12 и 13 к RE1 и RE0.
Фабрика коммутации (Switch fabric)
Фабрика коммутации предназначена для передачи трафика между PFE. Она соединяет все PFE в full mesh топологию. В настоящее время существует три поколения SCB: SCB, SCBE и SCBE2. Данные платы отличаются по пропускной способности. По данным с сайта производителя SCB поддерживает пропускную способность не менее 120Гбитс на слот, SCBE — 160Гбитс и SCBE2 — 340Гбитс на слот. Данные платы построены на чипе SF(SCB) и XF (SCBE, SCBE2).
Примечание: Хоть SCBE2 и предоставляет нам пропускную способность 340 Гбитс/слот, не стоит забывать о количестве PFE на плате и количество обслуживаемых каждым PFE интерфейсов. Если для примера взять плату MPC4E 8x10GE+2x100GE, то общая пропускная способность данной платы равна 280 Гбит/с. Но так как на ней установлены только два расширенных PFE (пропускная способность 130Гбит/с), то пропускная способность данной платы равна 2×130Гбит/с= 260Гбит/с. Тут важно появляется концепция WAN-групп. Интерфейсы объединяются в группы. На данной плате два встроенных PIC: на одном 8х10GE интерфейсов и на втором на 2x100GE. Для PFE они объединены в WAN группы 0 и 1 (8х10GE — группа 0, 2x100GE — группа 1). Первый PFE обслуживает первые 4GE интерфейса из группы 0 и первый 100GE интерфейс из группы 1. Аналогично и для PFE1. То есть один PFE обслуживает 140Гбит/с, но имеет пропускную способность 130Гбит/с. Итого мы получаем, что все порты, кроме двух 10GE могут работать на скорости интерфейса.
Логически схема подключения PFE к SCB выглядит так:
Для MX960 
Для MX240/480 
Как видно из рисунков каждая SCB разделена на plane-ы. Что же такое plane? Почему, если SCB вставить в mx480 у нас будет 4 плейна, но если эту же плату вставить в MX960, то у нас будет всего два плейна? Что бы это понять, надо представить фабрику коммутации как коммутатор с N-ым количеством портов. Сколько же портов должно быть? Максимальное количество PFE на карту равно 4-м. Теперь посчитаем сколько портов нужно:
Итак, получается, что максимально возможное количество PFE — 48. Значит одна фабрика коммутации должна иметь 48 портов для создания полносвязной топологии между всем PFE. Выходит, что если мы устанавливаем SCB в MX960, то все 48 интерфейсов задействованы (могу быть задействованы), но если мы вставим плату в MX480, то нам понадобится только 24 порта из 48 — значит 24 порта будут простаивать. (Если взять MX240 — то тут соотношение будет еще больше). Поэтому было введено понятие плейна. Одни плейн — это виртуальный свич, который обеспечивает полносвязную топологию между всеми PFE. Надеюсь, теперь понятно, почему одна фабрика коммутации при установке в MX960 имеет только один плейн, а в MX480/240 уже два. Так как на одной SCB две фабрики коммутации, то получаем, что одна плата обеспечивает 2 плейна для MX960 и 4 плейна на MX480/240. В итоге, с учетом резервирования получаем вот такое количество плейнов:
Как видно из вывода ниже на MX960 мы имеем 6 плейнов:
Но только 4-ре плейна в данный момент активны: а 2 плейна с SCB3 предназанчены для повышения отказоустройчивости (2+1)
Примечание: может быть что все 6 плейнов будут онлайн, что необходимо, если пропускной способности 2-х SCB не хватает для обслуживания всех установленных карт. Тогда резервирования не будет (3+0).
Для MX480 и MX240 выоды выглядят несколько иначе:
Мы видим 8 плейнов на 2-х картах. Тут используется резервирование 1+1, поэтому только 4 плейна в онлайн.
Midplane
Midplane установлен на задней стенке шасси и обеспечивает электрическую связность между всеми платами и подачу питания на каждый элемент маршрутизатора от блоков питания.
Отдельно хотелось бы сказать о младшей линейке MX5-MX80. В данной линейке представлены 4 маршрутизатора — MX5, MX10, MX40 и MX80. Аппаратно это полностью идентичные маршрутизаторы, то есть начинка у них всех как у MX80, различия только в цвете (они серые на манер MX104) и шильдике. В любой момент, купив лицензию, вы можете превратить MX5 в MX80, так как порты и функции заблокированы программно. Данная практика есть у многих производителей, например так же поступает Cisco с их ASR или Huawei.
Сам же MX80 отличается от своих старших братьев. В силу своей архитектуры он имеет встроенный PFE на базе Trio чипсета (имеет один MQ, один QX и одни LU блок) и встроенный RE. Так как функция SCB теперь свелась бы к созданию линка между RE и PFE, то от него, как от отдельной платы SCB разработчик отказался. Грубо говоря, MX80 — это линейная карта и RE, собранные в двухюнитовый корпус. Естественно данный маршрутизатор не имеет механизмов повышенной отказоустойчивости, но и стоимость его на много ниже, чем у его ближайшего брата MX240.
Хотелось бы добавить, что маршрутизаторы Juniper серии MX не умеют «из коробки» делать например NAT. Для этих целей существует специальные сервисные платы Multiservices DPC (MS-DPC), которые могут вставлять в любой из слотов, предназначенных для линейных карт (есть ограничения по количеству карт на одну коробку). MS-DPC могут обеспечивать следующие сервисы:
— NAT (во всех его видах);
— Session border control (SBC);
— Deep packet inspection (DPI);
— Функции межсетевого экрана.
Сервисные карты поддерживают все маршрутизаторы MX серии (включая и MX80 — слот под специальную карту есть на тыльной стороне маршрутизатора). О данных картах можно почитать на сайте производителя.
Путешествие пакета по внутреннему миру Juniper MX
по мотивам книги This Week: An Expert Packet Walkthrough on the MX Series 3D
Мы разобрались из чего состоит маршрутизатор, но как же происходит передача пакета с одно интерфейса на другой? Как будет обрабатываться пакет зависит от его типа:
— транзитный пакет, входящий и исходящий интерфейс на одном PFE;
— транзитный пакет, входящий и исходящий интерфейс на разных PFE;
— пакет, обработка которого будет производиться на CPU RE;
— пакет, обработка которого будет производиться на CPU интерфейсной карты;
— пакет, сгенерированный CPU RE;
— пакет, сгенерированный CPU PFE.
Мы разберем наиболее сложный случай, когда транзитный пакет имеет входящий интерфейс в зоне ответственности одного PFE, а исходящий — другого.
Итак, пакет принят на входящем интерфейсе. Пакет попадает на MAC контроллер, который по сути является прослойкой между физическим уровнем и канальным (подуровень MAC). Данный контроллер связывает между собой физический интерфейс и PFE. Одной из важных функций контроллера является проверка контрольной суммы полученного фрейма (если сумма посчитанная сумма не соответствует указанной в FCS, то пакет дропается.
Далее в работу включается Trio чипсет. Если у нас плата с малой пропускной способностью ( к примеру двадцать гигабитных портов), то в составе PFE будет присутствовать интерфейсный блок (IX chip). Данный блок производит предварительную классификацию пакетов. Данная классификация является очень грубой, так как имеет только три класса на каждый интерфейс — real time (RT), best effort (BE) и control. К последнему классу относится трафик управления (протоколы маршрутизации, vrrp и т.д.). Если же у нас более емкая плата (к примеру 16-ть десяток), то данного блока на плате не будет. Поэтому задача интерфейсного блока ложится на блок буферизации.
Блок буферизации состоит из нескольких блоков (их функции будем рассматривать по мере продвижения пакета). После предварительной классификации пакет попадает в WAN input block. Данный блок связывает все остальные блоки меду собой и отвечает за сегментацию полученного пакета с последующей буферизацией и отделение заголовка для отправки его в Lookup блок. Теперь подробнее. Попав в данный блок, от пакета отделяется заголовок, который помещается в специальный контейнер — parcel, а оставшаяся часть пакета буферизируется в быстрой памяти OnChip memory (SRAM).
Parcel представляет собой контейнер размером от 256 до 320 байт. Чаше всего длина пакета равна 256 байтам. Если на WI блок попал пакет, размер которого менее или равен 320 байтам, то данный пакет полностью помещается в parcel. Если же пакет имеет размер более 320 байт, то от пакета отделяются первые 256 байт, а остальная часть пакета буферизируется в OnChip-memory (SRAM).
Parcel, при передаче от блока буферизации в lookup блок имеет специальный заголовок M2L (MQ to LU), в котором указывается номер класса (к которому данный пакет был отнесен при предварительной классификации). Сразу встает вопрос — зачем делить пакет на две части и генерировать parcel? Не проще ли использовать исходный пакет? В таком случае внутри чипсета будет ходить слишком большой объем данных (например от блока буферизации к lookup блоку и обратно). Возникнут сложности с буферизацией пакетов между элементами чипсета и увеличится нагрузка на соединения между ними. В нашем же случае содержимое пакета хранится в буфере, в то время как parcel проходит обработку в остальных блоках чипсета.
Примечание: блоку WI неизвестно какие и сколько заголовков в полученном пакете. Отделяя 256 байт, вместе с заголовками в parcel будут помещаться часть данных. Изменениям подвергаются только заголовки, сами данные пользователя не изменяются.
Подведем краткий итог — в данный момент наш входящий пакет разбит на две части: заголовок помещен в parcel и отправлен в lookup блок (точнее сказать первые 256 байт пакета), а остальная часть помещена в буфер (SRAM).
Двигаемся дальше. Lookup блок является многоядерным чипом и состоит из нескольких PPE — packet processor engine и имеет специальную память RLDRAM, в которой и хранится таблица форвардинга. Lookup блок производит балансировку входящих данных по всем имеющимcя в его составе PPE. Получив parcel, lookup блок отправляет parcel на PPE (предварительно сняв с него M2L заголовок), где начинается его обработка (в данном случае можно сказать обработка заголовка исходного пакета).
Сначала маршрутизатор для IPv4 пакетов проверяет контрольную сумму (вспоминаем, что в IPv6 поле с контрольной суммой отсутствует), если контрольная сумма, указанная в пакете и сумма, посчитанная самим PPE не совпадают, то пакет дропается. (Сам Lookup блок не дропает пакеты, он их помечает и отправляет в блок буферизации, который уже будет производить дроп пакета). Если контрольная сумма верна, то обработка заголовка продолжается: производится применение фильтров (firewall filters), ограничений скорости (policers), класcификация трафика по DSCP/EXP (трафик может раскрашиваться согласно конфигурации администратора или переписывать поля DSCP/EXP), поиск next-hop, выполняет RPF check, в случае использования LAG или ECMP высчитывается хеш для определения исходящего интерфейса. В конечном итоге исходный заголовок пакета, который находился в parcel, подвергается изменениям (обязательно меняется поле ttl и пересчитывается контрольная сумма ipv4 заголовка), и parcel отправляется обратно в блок буферизации. К parcel добавляется новый заголовок L2M (LU to MQ), в котором содержится номер очереди, в которую должен встать пакет.
Очередь может быть в сторону фабрики коммутации или в сторону выходного интерфейса. В нашем случае выходной интерфейс находится в зоне ответственности другого PFE, поэтому в L2M заголовке указан номер очереди на отправку в сторону фабрики коммутации.
Когда исходящий интерфейс находится на другом PFE, помимо L2M заголовка появляется еще одни заголовок – FAB. Данный заголовок несет информацию о классе пакета, приоритете сброса и ID next-hop. Эта информация необходима для постановки пакета в очередь в сторону фабрики коммутации а так же Lookup блоку удаленного PFE (в противном случае PFE пришлось бы снова производить поиск next-hop и т.д.).
Далее, Lookup блок передает parcel, L2M и FAB заголовки обратно в блок буферизации. Эти данные попадают в блок LI – lookup input блок (субблок блока буферизации), который помещает FAB и parcel в OffChip memory (DRAM) и переносит относящийся к ним сегмент исходного пакета из OnChip в OffChip memory, а указатель на расположение этих данных в OffChip memory ставится в очередь на отправку в сторону фабрики коммутации.
Передача данных на уделенный PFE производится по схеме запрос-ответ. Сначала исходящий PFE отправляет удаленному PFE запрос на передачу данных. После получения согласия на прием данных от удаленного PFE, исходящий PFE начинает передавать данные производя балансировку по всем линкам в сторону фабрики коммутации. Данные через фабрику коммутации передаются в виде J-cell (64-байтные ячейки). Перед тем как начать передачу, исходящий PFE разбивает хранящийся в OffChip memory пакет, parcel и FAB на J-cell и прикрепляет к ним заголовок. В заголовке содержится информация об исходящем PFE, о PFE назначения (PFE ID), номер последовательности (что бы удаленный PFE мог заново собрать из данной последовательности исходный пакет и контрольная сумма. Передачу потока J-cell в фабрику коммутации производит Fabric output блок. Перед отправкой каждой ячейки, FO отправляет запрос на передачу и только после получения ответа начинает передачу. Этот механизм предназначен для предотвращения перегрузки фабрики коммутации (передача не будет вестись, пока не будет получен ответ на запрос).
Мы разобрались, какой путь проходит пакет от входящего интерфейса до фабрики коммутации. Теперь перейдем ко второй части – от фабрики коммутации к исходящему интерфейсу, поэтому будем говорить уже об исходящем PFE.
PFE имеет Fabric input блок, именно он получает J-cell из фабрики коммутации. FI производится обратную сборку parcel, FAB и остальной части пакета из J-cell, после чего parcel, FAB и M2L заголовки отправляются в lookup блок, а оставшаяся часть исходного пакета записывается в OffChip memory.
Lookup блок из FAB узнает ID next-hop, анализируя заголовок пакета в parcel и по arp записи выясняет реальный адрес next-hop, после чего создает новый L2 заголовок, при необходимости добавляет vlan-tag (или два тега), навешивает mpls метку (метки). Естественно, исходящий Lookup блок применяет правила QOS, filters, policers и т. д. и может так же внести изменения в заголовок исходящего пакета. После этих манипуляций, Lookup блок создает новый L2M заголовок, в котором указывает, в какую очередь должен встать пакет, и отправляет parcel и L2M заголовок в блок буферизации.
От Lookup блока parcel и L2M заголовок попадают в LI (lookup input) субблок блока буферизации, который пересылает parcel в OffChip memory (где уже хранится остальная часть пакета), а указатель на них ставит в очередь на отправку в интерфейсу. В какую очередь поставить данный пакет указано в L2M заголовке, полученном от lookup блока.
Как только походит очередь на отправку пакета в сеть, Wan output (WO) блок забирает Parcel и оставшуюся часть пакета из OffChip memory, собирает их в одни пакет и отправляет на контроллер исходящего интерфейса. Контроллер производит подсчет контрольной суммы пакета и отправляет его в сеть.
Для пакетов, направленных к/от RE, обработка будет несколько иначе — вместо отправки в сторону фабрики коммутации пакет будет вставать в очередь к CPU линейной карты, где к пакету снова будут применены фильтры и полисеры, и только потом пакет будет отправлен на RE через внутренний гигабитный свич.
Если есть какие то дополнения, прошу писать в личку. Спасибо за внимание!
