Ошибки на порту juniper

Недавно начал изучать с нуля оборудование Juniper Networks. К нам в контору пришли 3 Juniper SRX240 и SRX650. Вот собрал список команд которые мне больше всего пригодились при первоначальной настройке оборудования Juniper.

Оборудование Juniper работает на основе OS FreeBSD, при включении и прохождении аутентификации вы можете увидеть такие строки приглашения в режимы пользователя:

root@juniper% — это сам shell OS FreeBSD
после ввода команды cli мы попадаем в
root@juniper> — операционный режим, после ввода команды edit попадаем в
root@juniper# — конфигурационный режим

О назначении всех режимов я останавливаться не буду.

Команды операционного режима

Команды мониторинга и устранения неисправностей:
root@juniper> clear — очистка чего-либо
root@juniper> monitor — просмотр чего либо в реальном времени
root@juniper> ping — проверка доступности узлов ICMP-пакетами
root@juniper> show — просмотр конфигурации
root@juniper> test — тестирование сохраненных конфигураций и интерфейсов
root@juniper> traceroute — трассировка маршрута

Отображение состояния интерфейсов
root@juniper> show interface description
root@juniper> show interface terse {кратко о состоянии интерфейсов}
root@juniper> show interface detail {полная информация о интерфейсах}

Сохранение резервной конфигурации
root@juniper> request system configuration rescue save

Чтобы возвратиться к спасательной конфигурации, загрузите её следующей командой:
root@juniper# rollback rescue

Удаляет не примененные команды
root@juniper> clear system commit

Показывает CPU, Mem and Temperature
root@juniper> show chassis routing-engine

Показывает статистику на интерфейсе в реальном времени
root@juniper> monitor traffic interface ge-0/0/1 {какие пакеты и куда идут на интерфейсе}
root@juniper> monitor interface traffic {трафик на всех интерфейсах}

Рестарт процесса
root@juniper> restart {process} gracefully

Перегрузка оборудования
root@juniper> request system reboot

Удаление ненужных файлов
root@juniper> request system storage cleanup

Команды конфигурационного режима

Отключение ветки конфигурации
root@juniper# deactivate {interfaces ge-0/0/10}

Загрузка заводской конфигурации
root@juniper# load factory-default

Установка пароля на root-пользователя
root@juniper# set system root-authentication plain-text-password

Установка нового пользователя
root@juniper# set system login user {имя пользователя} class {тип пользователя: operator, read-only, super-user} authentication plain-text-password

Настройка WEB-интерфейса
root@srx# set system services web-management http interface {vlan.0} {включение интерфейсов}

Включение ssh-доступ к роутеру
root@srx# set system services ssh

Переключение с одного порта на другой
(порт на который переключаешься не должен быть активен)
root@juniper# rename interfaces ge-0/0/0 to ge-0/0/1

Возвращение портов — обратная операция
root@juniper# rename interfaces ge-0/0/1 to ge-0/0/0

Что бы не удалять IP-адрес с интерфейса и присваивать другой используй команду rename
[edit interfaces]
root@juniper# rename ge-0/0/1 unit 0 family inet address 192.168.0.1/28 to address 192.168.0.2/28

Копирование части конфигурации на другую ветку
(ветка на которую копируется не должна быть создана)
root@juniper# copy interfaces ge-0/0/0 to ge-0/0/1

Возвращение на верхний уровень иерархии конфигурационного режима [edit]
[edit interfaces ge-0/0/1]
root@juniper# top

Ввод операционных команд из конфигурационного режима
root@juniper# run {show route} {любая операционная команда}

Команды на применение, сохранение и откат конфигурации.

Проверка конфигурации на ошибки до коммита
root@juniper# commit check

Применение конфигурации по времени
root@juniper# commit at 12:00 {по системному времени}

Чтобы отменить операцию по времени
root@juniper> clear system commit

Применение конфигурации с откатом по времени
root@juniper# commit confitmed 100 {время в минутах}

Откат конфигураций
root@juniper# rollback {откат на последнюю конфигурацию}
root@juniper# rollback? {просмотр откатов конфигурации}

Просмотр изменений в конфигурации до ее применения
root@juniper# show | compare

Коммутация портов

Сделать нужные порты членами одной виртуальной локальной сети (VLAN).
root@juniper# set interfaces interface-range interfaces-trust member-range ge-0/0/1 to ge-0/0/7

Этой командой мы сказали, что интерфейсы являются портами коммутатора и принадлежат к одному VLAN под названием vlan-trust.
root@juniper# set interfaces interface-range interfaces-trust unit 0 family ethernet-switching vlan members vlan-trust

Далее создаем собственно сам vlan-trust и говорим, что данный VLAN терминируется и имеет IP-адрес
root@juniper# set vlans vlan-trust vlan-id 3
root@juniper# set vlans vlan-trust l3-interface vlan.0
root@juniper# set interfaces vlan unit 0 family inet address 192.168.0.1/24

Настройка зон безопасности {Названия зон могут любыми}

Разрешаем все сервисы в зоне trust
root@juniper# set security zones security-zone trust host-inbound-traffic system-services all

Разрешаем все протоколы в зоне trust
root@juniper# set security zones security-zone trust host-inbound-traffic protocols all

Добавляем интерфейсы в зону trust
root@juniper# set security zones security-zone trust interfaces vlan.0
root@juniper# set security zones security-zone trust interfaces lo0.0
root@juniper# set security zones security-zone trust interfaces ge-0/0/1.0

Создаем переход от зоны trust к зоне trust {в этих политиках мы разрешаем всё}
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust match source-address any
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust match destination-address any
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust match application any
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust then permit

Описывать зону untrast и переходы от этой к другим зонам не стал, т.к. у меня нету такой необходимости.

Оборудование Juniper работает на основе OS FreeBSD, при включении и прохождении аутентификации вы можете увидеть такие строки приглашения в режимы пользователя:

root@juniper% — это сам shell OS FreeBSD
после ввода команды cli мы попадаем в
root@juniper> — операционный режим, после ввода команды edit попадаем в
root@juniper# — конфигурационный режим

Команды операционного режима

Команды мониторинга и устранения неисправностей:

root@juniper> clear — очистка чего-либо
root@juniper> monitor — просмотр чего либо в реальном времени
root@juniper> ping — проверка доступности узлов ICMP-пакетами
root@juniper> show — просмотр конфигурации
root@juniper> test — тестирование сохраненных конфигураций и интерфейсов
root@juniper> traceroute — трассировка маршрута

Отображение состояния интерфейсов

root@juniper> show interface description
root@juniper> show interface terse {кратко о состоянии интерфейсов}
root@juniper> show interface detail {полная информация о интерфейсах}

Сохранение резервной конфигурации

root@juniper> request system configuration rescue save

Чтобы возвратиться к спасательной конфигурации, загрузите её следующей командой:

root@juniper# rollback rescue

Удаляет не примененные команды

root@juniper> clear system commit

Показывает CPU, Mem and Temperature

root@juniper> show chassis routing-engine

Показывает статистику на интерфейсе в реальном времени

root@juniper> monitor traffic interface ge-0/0/1 {какие пакеты и куда идут на интерфейсе}
root@juniper> monitor interface traffic {трафик на всех интерфейсах}

Рестарт процесса

root@juniper> restart {process} gracefully

Перегрузка оборудования

root@juniper> request system reboot

Удаление ненужных файлов

root@juniper> request system storage cleanup

Команды конфигурационного режима

Отключение ветки конфигурации

root@juniper# deactivate {interfaces ge-0/0/10}

Загрузка заводской конфигурации

root@juniper# load factory-default

Установка пароля на root-пользователя

root@juniper# set system root-authentication plain-text-password

Установка нового пользователя

root@juniper# set system login user {имя пользователя} class {тип пользователя: operator, read-only, super-user} authentication plain-text-password

Настройка WEB-интерфейса

root@srx# set system services web-management http interface {vlan.0} {включение интерфейсов}

Включение ssh-доступ к роутеру

root@srx# set system services ssh

Переключение с одного порта на другой
(порт на который переключаешься не должен быть активен)

root@juniper# rename interfaces ge-0/0/0 to ge-0/0/1

Возвращение портов — обратная операция

root@juniper# rename interfaces ge-0/0/1 to ge-0/0/0

Что бы не удалять IP-адрес с интерфейса и присваивать другой используй команду rename

[edit interfaces]
root@juniper# rename ge-0/0/1 unit 0 family inet address 192.168.0.1/28 to address 192.168.0.2/28

Копирование части конфигурации на другую ветку
(ветка на которую копируется не должна быть создана)

root@juniper# copy interfaces ge-0/0/0 to ge-0/0/1

Возвращение на верхний уровень иерархии конфигурационного режима [edit]

[edit interfaces ge-0/0/1]
root@juniper# top

Ввод операционных команд из конфигурационного режима

root@juniper# run {show route} {любая операционная команда}

Команды на применение, сохранение и откат конфигурации.

Проверка конфигурации на ошибки до коммита

root@juniper# commit check

Применение конфигурации по времени

root@juniper# commit at 12:00 {по системному времени}

Чтобы отменить операцию по времени

root@juniper> clear system commit

Применение конфигурации с откатом по времени

root@juniper# commit confitmed 100 {время в минутах}

Откат конфигураций

root@juniper# rollback {откат на последнюю конфигурацию}
root@juniper# rollback? {просмотр откатов конфигурации}

Просмотр изменений в конфигурации до ее применения

root@juniper# show | compare

Коммутация портов

Сделать нужные порты членами одной виртуальной локальной сети (VLAN).

root@juniper# set interfaces interface-range interfaces-trust member-range ge-0/0/1 to ge-0/0/7

Этой командой мы сказали, что интерфейсы являются портами коммутатора и принадлежат к одному VLAN под названием vlan-trust.

root@juniper# set interfaces interface-range interfaces-trust unit 0 family ethernet-switching vlan members vlan-trust

Далее создаем собственно сам vlan-trust и говорим, что данный VLAN терминируется и имеет IP-адрес

root@juniper# set vlans vlan-trust vlan-id 3
root@juniper# set vlans vlan-trust l3-interface vlan.0
root@juniper# set interfaces vlan unit 0 family inet address 192.168.0.1/24

Настройка зон безопасности {Названия зон могут любыми}

Разрешаем все сервисы в зоне trust

root@juniper# set security zones security-zone trust host-inbound-traffic system-services all

Разрешаем все протоколы в зоне trust

root@juniper# set security zones security-zone trust host-inbound-traffic protocols all

Добавляем интерфейсы в зону trust

root@juniper# set security zones security-zone trust interfaces vlan.0
root@juniper# set security zones security-zone trust interfaces lo0.0
root@juniper# set security zones security-zone trust interfaces ge-0/0/1.0

Создаем переход от зоны trust к зоне trust {в этих политиках мы разрешаем всё}

root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust match source-address any
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust match destination-address any
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust match application any
root@juniper# set security policies from-zone trust to-zone trust policy trust-to-trust then permit

Что делать когда Juniper сам по себе перезагрузился? Каким образом проверить использование системных ресурсов на устройстве? Как выполнять Troubleshooting работы Juniper?

1. Самое первое, что стоит проверить после перезагрузки устройства — show chassis routing-engine значение «Last reboot reason» в котором в штатном режиме должно быть — «Router rebooted after a normal shutdown» Но, стоит понимать, что это определение не говорит о том, что проблем не было, это лишь поможет понять, увидел ли проблему JunOS или нет, что может упростить процесс анализа.
Я на своей практике замечал следующие состояние: «could not be determined«, «panic:ehci_abort_xfer: not in process context«, «0x1:power cycle/failure«.

На правах

рекламы

совета, большинство падений оборудования связано с недавно внесенными изменениями в сеть/работу устройства и т.д. Какие действия выполнялись на Juniper можно проверить по commits (история внесений изменений в конфигурацию устройства):
show system commit  — кто и когда коммитил
show configuration | compare rollback 2 — сравнить текущую конфигурацию системы с конфигурацией в файле  rollback 2
show system rollback compare 4 3 — сравнить 2 файла конфигурации

2. Проверим файлы с логами: show log messages | find «FreeBSD Project». Не забываем, что если у нас устройство генерирует большое количество записей, то просматриваем все имеющиеся файлы логов (messages.0.gz, messages.1.gz и тд.) пока не найдем желаемое. Читаем логи за 15 минут до падения устройства и анализируем.
Для того чтобы удобно работать с логами, необходимо использовать достаточный уровень логирования, например — set system syslog file messages any notice. Рекомендуется не включать полное логирование «any any», такое логирование со временем просто «убьет» flash drive на routing-engine. Если мы хотим логировать всё-всё-всё — syslog сервер нам в помощь.

Заметим, что в случае, если устройство перезагружено администратором в логах будет следующие записи:
May 17 17:15:04  EX3200 mgd[45517]: UI_REBOOT_EVENT: System rebooted by ‘admin’
May 17 17:15:10  EX3200 shutdown: reboot by admin:

В случае, если мы замечаем, что устройство жалуется на конкретный процесс (daemon), в KB Juniper мы можем найти описание процессов: List of Junos OS Processes

Не мало важный момент это — использование traceoptions на Juniper (debug). Включение traceoptions для сервисов, протоколов, процессов и тд. значительно помогает в настройке/troubleshooting, но, это может вылезть «боком», трейсы довольно трудоемкий процесс и кушает много системных ресурсов. Поэтому, в штатном режиме использовать traceoptions не стоит и + это убьет flash drive в 10 раз быстрее… Когда flash drive плохо, возникает похожая ошибка — g_vfs_done():da1s1f[WRITE(offset=962772992, length=16384)]error = 5, она может возникнуть в процессе работы, загрузки устройства, либо работы с файловой системой.
Проверяем не было ли создано системой core-dumps файлов (это дампы памяти, которая система может сделать в случаи crash определенного демона rpd, etc).
show system core-dumps

Содержание данных файлов трудно проанализировать самостоятельно, поэтому, зачастую создается тикет в JTAC и данные файлы заливаются на FTP Juniper, в последующем анализируются инженерам. FAQ в KB Juniper по добавления файлов.
TT (trouble ticket) можно открыть при наличии активного сервисного контракта у Juniper Networks — Serial Number Entitlement Search

3. Проверим версию установленного JunOS:
show version

Не нужно гнаться за самой последней веткой и версией софта а использовать recommend (http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=search)
Важный момент, возможно уже существует описание бага по причине которого и произошла перезагрузка оборудования, данную информацию можно проверить в в PROBLEM REPORT SEARCH — https://prsearch.juniper.net/InfoCenter/index?page=prsearch. Для входа требуется регистрация.
Информация и FAQ по обновлению JunOS

3. Большинство устройств Juniper имеют модульную архитектуру и разделение по плоскости управления и обработки трафика (control & data plane), правда это разделение не всегда аппаратное. Выполняем типичную проверку состояния компонентов устройства (Routing-engine, Flexible PIC Concentrator, tfeb, ethernet-switch, компоненты и функции устройства могут отличаться в зависимости от серии и модели устройства). Таким образом мы попытаемся локализовать проблему.

show chassis hardware — список всех компонентов (само шасси, платы (модуля), блоки питания, фаны). Это исключительно список активных компонентов. Если карта сейчас упала или перезагружается здесь она отображена не будет, пока она полностью не загрузиться и не будет инициализирована.

show chassis routing-engine  — состояние Routing-engine (мозгов устройства), если используется резервирование, одна RE в состоянии Master, вторая RE в состоянии Backup. Здесь обращаем внимание на использование оперативной памяти и CPU.
Рекомендации по настройка отказоустойчивость по RE — Configuring Routing Engine Redundancy

show chassis alarms и show system alarms — комментарии излишни, система сама может показать проблему, если она ее заметила.

show chassis fpc detail — информация о состоянии и нагрузки линейных карт.

show chassis fpc pic-status — информация о состоянии pic модулей, которые вставлены в fpc карты.

show chassis pic fpc-slot 0 pic-slot 2 — информация о состоянии и загрузки конкретной pic карты, в примере это MS-MIC-16G на mx10-t.

show chassis environment — температура ASIC чипов (LU (XL), MQ (XM), QX (XQ) — это типы чипов на Juniper Trio Chipset для MX) тип чипа зависит от модели и архитектуры устройства). При нормальных условиях функционирования устройства температура не должна превышать 60 градусов по Цельсию. Если все блоки питания подключены к сети, напротив PEM будет указано — OK, если блок питания присутствует, но питание не подается — Absent. В штатном режиме, все fan должны крутиться на нормальной скорости, это отображается как — Spinning at normal speed.

На больших железках MX240 +  все участвующие в обработке трафика компоненты связываются между собой через встроенный в SCB ethernet-switch. Выполнив команду show chassis ethernet-switch statistics мы можем посмотреть нет ли ошибок на служебных интерфейсах.

5. Настройки защиты control plane. По умолчанию, Juniper MX например, не имеет никаких ограничений по протоколам, портам, к которым могут обращаться снаружи. Учитывая тот факт, что существует большое количество уязвимостей как JunOS CVE Vulnerability Juniper, так и уязвимостей в протоколах. Правильное решение данной проблемы — настроить фильтры для трафика, который может обращаться к control plane нашего устройства.
Официально у Juniper есть следующая литература:
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/

Table of Contents

Анализ проблемы с pppoe

В одном офисе перестал работать pppoe канал в интернет.

Со стороны провайдера было видно srx, но не проходила аутентификация.

При установлении pppoe соединения маршрутизаторы общаются по протоколу LCP — Link Control Protocol.

Что бы разобраться в проблеме надо посмотреть обмен LCP сообщениями.

Смотрим трафик на интерфейсе к которому подключен провайдер.

root@srx> monitor traffic interface pp0.0 extensive count 100

Начало новой сессии, srx послылает запрос на согласование (Conf-Request) параметров (опций) подключения.

18:03:52.248235 Out 
        ...
        -----original packet-----
        54:e0:32:00:00:01 > 00:1e:67:00:00:02, ethertype PPPoE S (0x8864), length 36: PPPoE  [ses 37713]LCP (0xc021), length 16: LCP, Conf-Request (0x01), id 70, length 16
        encoded length 14 (=Option(s) length 10)
        0x0000: c021 0146 000e 
          MRU Option (0x01), length 4: 1492
            0x0000: 05d4 
          Magic-Num Option (0x05), length 6: 0x5665bd0c
            0x0000: 5665 bd0c 

Провайдер согласился с предложенными значениям параметров (Conf-Ack).

18:03:52.268010  In 
        ...
        -----original packet-----
        00:1e:67:00:00:02 > 54:e0:32:00:00:01, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 37713]LCP (0xc021), length 16: LCP, Conf-Ack (0x02), id 70, length 16
        encoded length 14 (=Option(s) length 10)
        0x0000: c021 0246 000e 
          MRU Option (0x01), length 4: 1492
            0x0000: 05d4 
          Magic-Num Option (0x05), length 6: 0x5665bd0c
            0x0000: 5665 bd0c 

Провайдер предложил следующую пачку опций, в т.ч. и метот аутентификации — PAP (Auth-Prot Option).

18:03:54.132155  In 
        ...
        -----original packet-----
        00:1e:67:00:00:02 > 54:e0:32:00:00:01, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 37713]LCP (0xc021), length 37: LCP, Conf-Request (0x01), id 2, length 37
        encoded length 35 (=Option(s) length 31)
        0x0000: c021 0102 0023 
          PFC Option (0x07), length 2: 
          MRU Option (0x01), length 4: 1492
            0x0000: 05d4 
          Magic-Num Option (0x05), length 6: 0x2840ee38
            0x0000: 2840 ee38 
          Auth-Prot Option (0x03), length 4: PAP
            0x0000: c023 
          MRRU Option (0x11), length 4: 2048
            0x0000: 0800 
          12-Bit seq # Option (0x12), length 2: 
          End-Disc Option (0x13), length 9: MAC 00:1e:67:00:00:03
            0x0000: 0300 1e67 0278 27

SRX не согласился (Conf-Reject) с предложенными провайдером значениями папаметров, и послал список неугодных опций.

18:03:54.132528 Out 
        ...
        -----original packet-----
        54:e0:32:00:00:01 > 00:1e:67:00:00:02, ethertype PPPoE S (0x8864), length 43: PPPoE  [ses 37713]LCP (0xc021), length 23: LCP, Conf-Reject (0x04), id 2, length 23
        encoded length 21 (=Option(s) length 17)
        0x0000: c021 0402 0015 
          PFC Option (0x07), length 2: 
          MRRU Option (0x11), length 4: 2048
            0x0000: 0800 
          12-Bit seq # Option (0x12), length 2: 
          End-Disc Option (0x13), length 9: MAC 00:1e:67:00:00:03
            0x0000: 0300 1e67 0278 27

Провайдер еще раз предлагает метот аутентификации PAP (Auth-Prot Option)

18:03:54.134273  In 
        ...
        -----original packet-----
        00:1e:67:00:00:02 > 54:e0:32:00:00:01, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 37713]LCP (0xc021), length 20: LCP, Conf-Request (0x01), id 3, length 20
        encoded length 18 (=Option(s) length 14)
        0x0000: c021 0103 0012 
          MRU Option (0x01), length 4: 1492
            0x0000: 05d4 
          Magic-Num Option (0x05), length 6: 0x2840ee38
            0x0000: 2840 ee38 
          Auth-Prot Option (0x03), length 4: PAP
            0x0000: c023 

SRX поправляет и предлагает CHAP (Auth-Prot Option).

18:03:54.134654 Out 
        ...
        -----original packet-----
        54:e0:32:00:00:01 > 00:1e:67:00:00:02, ethertype PPPoE S (0x8864), length 31: PPPoE  [ses 37713]LCP (0xc021), length 11: LCP, Conf-Nack (0x03), id 3, length 11
        encoded length 9 (=Option(s) length 5)
        0x0000: c021 0303 0009 
          Auth-Prot Option (0x03), length 5: CHAP, MD5
            0x0000: c223 05

Последние два сообщения еще раз десять ходят в обе стороны и потом согласование параметров начинается заново.

После осозная проблемы связались с провайдером и попросили переделать аутентификацию на CHAP.


TCP-RST в настройках зоны безопасности

tcp-rst — Send RST for NON-SYN packet not matching TCP session

[edit]
root@bluebox# set security zones security-zone TRUST ?   
Possible completions:
  <[Enter]>            Execute this command
> address-book         Address book entries
  application-tracking  Enable Application tracking support for this zone
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  description          Text description of zone
> host-inbound-traffic  Allowed system services & protocols
> interfaces           Interfaces that are part of this zone
  screen               Name of ids option object applied to the zone
  tcp-rst              Send RST for NON-SYN packet not matching TCP session
  |                    Pipe through a command

Посмотреть тип железа и серийник

show chassis hardware

[edit security utm]
root@msk-02-srx2# run show chassis hardware
Hardware inventory:
Item             Version  Part number  Serial number     Description
Chassis                                AU3911AF0XXX      SRX100H
Routing Engine   REV 18   750-021773   AT3911AF0XXX      RE-SRX100H
FPC 0                                                    FPC
  PIC 0                                                  8x FE Base PIC
Power Supply 0

dhcp helper

[edit]
admin@nsk-01-srx2# show forwarding-options
...
helpers {
    bootp {
        server 192.168.10.22;
        server 192.168.9.12;
        vpn;
        interface {
            vlan.502;
            vlan.504;
            vlan.501;
            vlan.506;
        }
    }
}

host inbound traffic — bootp, dhcp

[edit security zones security-zone trust]
admin@msk-04-srx1# show
interfaces {
    vlan.501 {
        host-inbound-traffic {
            system-services {
                ping;
                traceroute;
                ssh;
                dhcp;
            }
        }
    }
    vlan.502 {
        host-inbound-traffic {
            system-services {
                ping;
                traceroute;
                bootp;
            }
        }
    }

bootp — надо использовать когда на srx настроен dhcp хелпер ([edit forwarding-options helpers bootp]).

dhcp — надо использовать когда на самом srx настроен dhcp сервер.

Juniper open dns server

name-server {
    208.67.222.222;
    208.67.220.220;
}

Схема прохождения пакета через srx

Подрезать скорость

Скрыть часть конфига

Что бы скрыть часть конфига надо уровнем ниже дать скрытую команду “apply-flags omit”.

[edit firewall]
admin@srx2# set family inet filter TEST apply-flags omit       

[edit firewall]
admin@srx2# show
...
    filter TEST { /* OMITTED */ };
}
...

Что бы посмотреть надо через пайп дать команду “display omit”

[edit firewall]
admin@srx2# show | display omit
...
   filter TEST {
        apply-flags omit;
        term DENY-ANY {
            then {
                discard;
            }
        }
    }
...      

Задать shell при логине пользователя

Что бы при логине обычный пользователь попадал не в консоль CLI, а сразу в unix-шелл надо дать скрытую команду “shell sh” (UNIX Bourne shell) или “shell csh” (UNIX C shell).

Заход сразу в шелл можно использовать когда надо вытащить логи srx которые не попадают в syslog.

{primary:node0}[edit system login user scp]
root@srxmaster# show
apply-flags omit;
uid 2000;
class super-user;
shell sh;
authentication {
    encrypted-password "XXX"; ## SECRET-DATA
}

Ошибка комита при достижении максимального количества зон безопасности на srx100

root@srx100B# commit check 
error: zone quota exceeded (usage 11 > max 10)
error: configuration check-out failed

Ошибки на физическом интерфейсе

Carrier transitions

Вывод “show interface”:

Input errors:
 Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0

Output errors:
 Carrier transitions: 5, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0

Carrier transitions just mean the link has flapped. See the exact description from Juniper:

Carrier transitions—Number of times the interface has gone from down
to up. This number does not normally increment quickly,

increasing only when the cable is unplugged, the far-end system is
powered down and then up, or another problem occurs. If the number
of carrier transitions increments quickly (perhaps once every 10 seconds),
the cable, the far-end system, or the PIC or PIM is malfunctioning.
You would need to do basic troubleshooting to find out why the link is flapping. Those steps would be different >if it was a telco circuit or an P2P ethernet cable.

Framing errors

KB27597

Вывод “show interface”:

Input errors:
 Errors: 468, Drops: 0, Framing errors: 468, Runts: 0, Policed discards: 71, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0 

KB27597

Framing errors — это ошибка в контрольнной сумме пришедшего на интерфейс пакета, пакет “бьется” и контрольные суммы отправленного и полученно пакета не совпадают.

Решение проблемы с Framing errors заключается в:

  • проверить, что с обоих концов правильно настроены скорость и дуплекс порта.

  • поменять патч-корд

  • поменять порт оборудования

Policed discards

Policed discards — дропаются служебные пакеты протоков которык нет в “security interface host-inbound-traffic protocols”.

При случае проверить с ospf.

“Frames that the incoming packet match code discarded because they were not recognized or of interest. Usually, this field reports protocols that the JUNOS software does not handle, such as CDP.”


Скорость создания сессий.

KB23428

CLI

 root@srx2> show security monitoring fpc ?
 Possible completions:
   <fpc-slot>           FPC slot number (0..0)
 root@srx2> show security monitoring fpc 0 ?
 Possible completions:
   <[Enter]>            Execute this command
   |                    Pipe through a command
 admin@msk-01-srx2> show security monitoring fpc 0   
 FPC 0
   PIC 0
     CPU utilization          :    3 %
     Memory utilization       :   57 %
     Current flow session     :  469
     Current flow session IPv4:  469
     Current flow session IPv6:    0
     Max flow session         : 524288
Total Session Creation Per Second (for last 96 seconds on average):   15
IPv4  Session Creation Per Second (for last 96 seconds on average):   15
IPv6  Session Creation Per Second (for last 96 seconds on average):    0

SNMP OID

root@srx2> show snmp mib walk .1.3.6.1.4.1.2636.3.39.1.12.1.4.1.5 
jnxJsNodeSessionCreationPerSecond.0 = 15

Когда два srx работают в режиме кластера в выводе появится строка “jnxJsNodeSessionCreationPerSecond.1 = ”

root@srx2> show snmp mib walk .1.3.6.1.4.1.2636.3.39.1.12.1.4.1      
jnxJsClusterMonitoringNodeIndex.0 = 0
jnxJsClusterMonitoringNodeDescr.0 = single
jnxJsNodeCurrentTotalSession.0 = 485
jnxJsNodeMaxTotalSession.0 = 0
jnxJsNodeSessionCreationPerSecond.0 = 15
jnxJsNodeSessCreationPerSecIPv4.0 = 15
jnxJsNodeSessCreationPerSecIPv6.0 = 0
jnxJsNodeCurrentTotalSessIPv4.0 = 485
jnxJsNodeCurrentTotalSessIPv6.0 = 0

Бэкап и восстановление конфигурации

Часто возникает задача синхронизировать конфиги основного и резервного srx.

Пока опустим момент как мы оба srx ставим в сеть.

Идея:

  • с основного srx1 по ssh скачиваем текущий конфиг juniper.conf.gz

  • переименовываем juniper.conf.gz в juniper.conf.new.gz

  • закачиваем на резервный srx2 конфиг juniper.conf.new.gz

  • на srx2 накатываем новый конфиг

Скачиваем текущий конфиг

# scp root@10.13.1.254:/config/juniper.conf.gz ./
Password:
juniper.conf.gz                    100%   11KB  10.7KB/s   00:00

переименовываем

# mv juniper.conf.gz juniper.conf.new.gz

закачиваем на резервный srx2

# scp juniper.conf.new.gz root@10.13.1.254:/config/
Password:

накатываем новый конфиг

[edit]
admin@srx2# load override /config/juniper.conf.new.gz

Потом проверяем его, меняем где надо адреса на интерфесах и название и комитим.


MOTD

Message of the day

admin@srx2# set system login message “Privet Serega! NE PEREGRUZHAI srx! Lozhis` spat`=) WBR EKS and Levin.”


Залить текущий junos на бэкапный раздел

root@srx-master> request system snapshot slice alternate
node0:


Formatting alternate root (/dev/ad0s1a)…

Copying ‘/dev/ad0s2a’ to ‘/dev/ad0s1a’ .. (this may take a few minutes)
The following filesystems were archived: /

node1:


Formatting alternate root (/dev/ad0s2a)…
Copying ‘/dev/ad0s1a’ to ‘/dev/ad0s2a’ .. (this may take a few minutes)
The following filesystems were

На кластере можно дать команду только на активной ноде.


Перенести кусок конфигурации с одного srx на другой

Будем переносить записи в address book.

Отображаем конфирацию в set стиле

 [edit security address-book UNTRUST-BOOK]
 root@srx-old# show | display set     
 set security address-book UNTRUST-BOOK address perevod-korona.ru dns-name perevod-korona.ru ipv4-only
 set security address-book UNTRUST-BOOK address wupos.westernunion.com dns-name wupos.westernunion.com ipv4-only
...

Подгружаем конфигурацию

У команды load есть ключ relative который подкружает set не от корня конфигуации, а от текущего места.

{primary:node1}[edit security address-book]
root@srx-new# load set terminal 
[Type ^D at a new line to end input]
set security address-book UNTRUST-BOOK address perevod-korona.ru dns-name perevod-korona.ru ipv4-only
set security address-book UNTRUST-BOOK address wupos.westernunion.com dns-name wupos.westernunion.com ipv4-only
...
^D

Нюансы

Если сразу переносить много конфига, то RE возможно будет не успевать его отрабатывать и будут появляться ошибки вида — “terminal:2:(4) syntax error: address”.

Проблема описана в KB15472. Как решить в линуксовом терминале пока не придумал.

Если сидеть на srx через череp minicom, то заливаться будет без ошибок — скорость соединения маленькая.


Обновить софт в srx

 root> request system software add ?               
 Possible completions:
   <package-name>       URL or pathname of package
   best-effort-load     Load succeeds if at least one statement is valid
   delay-restart        Don't restart processes
   no-copy              Don't save copies of package files
   no-validate          Don't check compatibility with current configuration
   partition            Format and re-partition the media before installation
   reboot               Reboot system after adding package
   unlink               Remove the package after successful installation
   validate             Check compatibility with current configuration

root> request system software add no-copy http://192.168.10.12/junos/junos-srxsme-12.1X47-D25.4-domestic.tgz

KB25265

http://kb.juniper.net/InfoCenter/index?page=content&id=KB25265

Проблема.

 root@srx> ping ocsp.comodoca.com       
 PING6(56=40+8+8 bytes) :: --> 2a02:1788:2fd::b2ff:5301
 ping: sendmsg: No route to host
 ping6: wrote ocsp.comodoca.com 16 chars, ret=-1
 ^C
 --- ocsp.comodoca.com ping6 statistics ---
 1 packets transmitted, 0 packets received, 100% packet loss

Решение.

root@srx> ping ocsp.comodoca.com inet 
 PING ocsp.comodoca.com (178.255.83.1): 56 data bytes
 64 bytes from 178.255.83.1: icmp_seq=0 ttl=57 time=79.415 ms
 ^C
 --- ocsp.comodoca.com ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 79.415/79.415/79.415/0.000 ms

Записать вывод команды в файл

root@srx> show services application-identification application detail | save ai-app-detail

Файл запишется в домашнюю директорию пользователя.


Истекли лицензии appid-sig и idp-sig

 root@srx> show system license
 License usage:
                                  Licenses     Licenses    Licenses    Expiry
   Feature name                       used    installed      needed
   av_key_kaspersky_engine               1            0           1    28 days
   dynamic-vpn                           0            2           0    permanent
   ax411-wlan-ap                         0            2           0    permanent
   appid-sig                             1            0           1    invalid
         - APPID Signature

Все ранее настроенные политики продолждают работать.

Нельзя обновить сигнатуры и верме комита увеличилось секунд на 40.

 root@srx# commit
 [edit security idp idp-policy Recommended rulebase-ips rule 1 match attacks]
   'predefined-attack-groups "[Recommended]IP - Critical"'
     Security Package is being used, however license is not valid/has expired. This may be in violation of policy.
 commit complete

Смысл maximum-transactions в настройках вложенных приложений (nested applications)

 nested-application my:XAKEP-SSL {
     type XAKEP;
     protocol SSL;
     signature NestedApplication:XAKEP-SSL {
         member m01 {
             context ssl-server-name;
             pattern xakep.ru;
             direction client-to-server;
         }
         maximum-transactions 1;
     }
 }

maximum-transactions — максимальное количество совпадений с “подписью” при при достижении которого считается, что это именно это приложение.


Посмотреть список и детальную информацию по типам приложений с которыми работает AppFW и IDP на srx

 root@srx> show services application-identification application summary
 Application(s): 800
 Nested Application(s): 981
   Applications                                 Disabled         ID      Order
   junos:ZENGUARD-SSL                            No               1987    33799 
   junos:FACEBOOK-TIMELINE                       No               1986    33793 
   junos:FACEBOOK-STATUS-UPDATE                  No               1985    33794 
   junos:GOLFZON-MEMBERS-SSL                     No               1984    33792 
   junos:AFREECA-HTTP-STREAM                     No               1982    33790 
....

root@srx> show services application-identification application summary | match HTTP    
  junos:AFREECA-HTTP-STREAM                     No               1982    33790   
  junos:WECHAT-HTTP                             No               1932    33751   
  junos:SSH-OVER-HTTP                           No               1907    33586   
  junos:YAHOO-FINANCE-HTTP                      No               1896    33722   
  junos:AIM-HTTP-API                            No               1865    33700   
  junos:ALIWANGWANG-HTTP                        No               1863    33704   
  junos:BAIDU-HI-HTTP                           No               1859    33703   
  junos:GROOVE-HTTP                             No               1264    33669   
...

 root@srx> show services application-identification application detail junos:YAHOO-FINANCE-HTTP
 Application Name: junos:YAHOO-FINANCE-HTTP                                   
 Application type: YAHOO-FINANCE-HTTP                                         
 Description: This signature detects Yahoo! finance, a site from Yahoo! that provides financial news and information.
 Application ID: 1896   
 Disabled: No               
 Number of Parent Group(s): 1     
 Application Groups:
     junos:web:finance                           
 Application Tags:
     characteristic        : Bandwidth Consumer                               
     characteristic        : Loss of Productivity                             
     risk                  : 2                                               
     subcategory           : Finance                                         
     category              : Web                                             
 Signature NestedApplication:YAHOO-FINANCE-HTTP                           
     Layer-7 Protocol: HTTP                                               
     Chain Order: no       
     Maximum Transactions: 1                 
     Order: 33722           
     Member(s): 1           
         Member 0       
             Context: http-header-host     
             Pattern: (.*.)?finance.yahoo.com                         
             Direction: CTS                                 

Посмотреть настройки стантардных junos application

root> show configuration groups junos-defaults applications

Посмотреть кто залогинился

root> show system users no-resolve   
  5:38PM  up 28 days,  2:04, 4 users, load averages: 0.10, 0.06, 0.04
 USER     TTY      FROM                              LOGIN@  IDLE WHAT
 root     p0                                                          3:17PM   2:04 cli         
 root     p1                                                          3:03PM     55 cli         
 root     p2                                                          4:21PM     56 cli         
 root     p3                                                          5:31PM      - cli 

Поставить таймаут на ssh/telnet сессию

root> set cli idle-timeout 60
 Idle timeout set to 60 minutes

 root> show cli
 CLI complete-on-space set to on
CLI idle-timeout set to 60 minutes
 CLI restart-on-upgrade set to on
 CLI screen-length set to 55
 CLI screen-width set to 207
 CLI terminal is 'xterm'
 CLI is operating in enhanced mode
 CLI timestamp disabled
 CLI working directory is '/cf/root'

Передернуть руками ноду в кластере

root> request chassis cluster failover redundancy-group [0|1] node [0|1]

Увести RG0 на node1:

root> request chassis cluster failover redundancy-group 0 node 1

После этого приоритет node1 для RG0 станет равным 255.

Что бы привести приоритет в соответствие со штатными настройками надо дать комануду:

root> request chassis cluster failover reset redundancy-group 0

После этого, в зависимости от настройки “Preempt”, RG0 останется или на node1 или вернется на node0.


Сброс конфигурации junos

 [edit]
 root# load factory-default   
 warning: activating factory configuration

Посмотреть загрузку cpu

Routing Engine

 user@srx> show chassis routing-engine
 Routing Engine status:
     Temperature                 57 degrees C / 134 degrees F
     Total memory              1024 MB Max   655 MB used ( 64 percent)
       Control plane memory     544 MB Max   457 MB used ( 84 percent)
       Data plane memory        480 MB Max   202 MB used ( 42 percent)
     CPU utilization:
       User                       4 percent
       Background                 0 percent
       Kernel                    10 percent
       Interrupt                  0 percent
       Idle                      85 percent
     Model                       
     Serial ID                   
     Start time                     2015-02-04 19:03:18 GMT-3
     Uptime                         26 minutes, 6 seconds
     Last reboot reason             0x200:normal shutdown
     Load averages:                 1 minute   5 minute  15 minute
                                        0.07       0.17       0.61

Forwarding Plane

Смотреть “Real-time threads CPU utilization”

 user@srx> show chassis forwarding       
 FWDD status:
   State                                 Online   
   Microkernel CPU utilization        14 percent
   Real-time threads CPU utilization   0 percent
   Heap utilization                   42 percent
   Buffer utilization                  1 percent
   Uptime:                               22 minutes, 39 seconds

Сетевое оборудование Juniper — c англ. «можжевельник» (коммутаторы, маршрутизаторы, межсетевые экраны и др.) базируется на операционной системе Junos OS (основана на FreeBSD). CLI Junos OS отличается от привычного многим CLI Cisco IOS. Ниже рассмотрим примеры настройки базового функционала устройств на основе Junos OS.



Основы CLI Junos OS/Базовая настройка устройства (Part1):

Junos OS имеет UNIX shell и 2 основных режима CLI: 1) Operational mode 2) Configuration mode

UNIX shell

— UNIX составляющая Junos OS, в ней доступен только стандартный набор unix/linux команд.

Operational mode

— основной режим CLI Junos OS, служит для вывода информации о состоянии устройства, протоколов и т.д. — аналог Cisco user/exec modes.

Configuration mode

— режим конфигурации устройства.

Обозначение разных режимов в консоли устройства:

% — UNIX shell
> — Operational mode
# — Configuration mode

После загрузки устройства Junos OS попросит ввести логин и пароль:

Все платформы «из коробки» имеют только пользователя root, без пароля. После ввода логина мы попадаем в UNIX shell (root@%). Слово Amnesiac говорит о том, что устройство имеет конфигурацию по умолчанию (не настроено).

Переход из UNIX shell в CLI Junos OS (Operational mode) выполняется командой «cli»:

root@% cli
root>

Переход из Operational mode в Configuration mode выполняется командой «configure»:

root> configure
Entering configuration mode

[edit]
root#

Для того, чтобы вносить и сохранять конфигурации на устройстве

обязательно

требуется настроить пароль для root пользователя (без него не получится выполнить commit):

root# set system root-authentication plain-text-password
New password:
Retype new password:

[edit]
root#

Настройка hostname (имя устройства) выполняется командой «set system host-name»:

root# set system host-name SRX

Создание нового пользователя (admin) с root правами (class super-user):

root# set system login user admin authentication plain-text-password
root# set system login user admin class super-user

Настройка временной зоны и NTP (имя NTP сервера должно «резолвиться», в противном случае нужно настраивать IP адрес):

root# set system time-zone Europe/Moscow
root# set system ntp server 0.pool.ntp.org
root# set system ntp boot-server 0.pool.ntp.org

Настройка доступа по SSH:

root# set system services ssh
root# set system services ssh protocol-version v2

Настройка DNS(Google DNS, например):

root# set system name-server 8.8.8.8

Основная особенность Junos OS в том, что вся конфигурация не применяется на лету, как у Cisco, например, её обязательно нужно применять командой «commit»:

root# commit
commit complete

[edit]
root@SRX#

Выход из режима конфигурации осуществляется командой «quit configuration-mode» или «exit configuration-mode»(с любого уровня конфигурации):

root@SRX# quit configuration-mode
Exiting configuration mode

root@SRX>

Перезагрузка и выключение устройства:

/Перезагрузка
root@SRX> request system reboot
/Выключение
root@SRX> request system halt

Сброс настроек к заводским:

root@SRX# load factory-default
/т.к. после введения команды все настройки сбросятся, то необходимо заново настроить root password. Так же обязательно необходимо выполнить commit

 Основы CLI Junos OS (Part2):

1. Configuration mode:

Есть 2 вида конфигурации в Junos:
1) Active configuration — в терминологии Cisco это running-config.
2) Candidate configuration — конфигурация с неподтвержденными изменениями в ней (Uncommitted changes).

Посмотреть внесенную, но не примененную конфигурацию (uncommitted changes) в режиме конфигурации можно с использованием команды «show | compare«, где «+» это конфигурация, которая будет добавлена в активную после выполнения commit, а «-» которая будет удалена.

Применение конфигурации, как уже было показано выше, выполняется командой «commit». У этой команды существуют дополнительные опции:

«commit check» — позволяет проверить внесенную конфигурацию на предмет ошибок, без применения. Junos в процессе конфигурации никогда не скажет, что что-то нельзя настроить, или что-то некорректно, все ошибки он проверяет только когда конфигурация применяется или производится проверка через «commit check».

root@SRX# commit check
configuration check succeeds

[edit]
root@SRX#

Каждый успешный «commit» сохраняет копию конфигурации в т.н. commit database, которая хранит до 50 последних конфигураций. Это позволяет откатиться на одну из сохраненных конфигураций позднее, используя команду «rollback» и номер конфигурации (0-49). Посмотреть commit database (покажет когда был выполнен commit, а так же кем и когда):

> show system commit 

Для просмотра конфигурации отдельного rollback используется команда «show system rollback» далее указывается его номер.

/покажет конфигурацию rollback 2
> show system rollback 2

rollback 0 (или просто rollback) откатит конфигурацию к последнему успешному commit (т.е. rollback 0 — вернет конфигурацию к current active configuration):

root@SRX# rollback 0
load complete

[edit]
root@SRX#

«commit confirmed» — полезная команда, особенно когда настройка осуществляется удаленно. Применяет конфигурацию, но автоматически откатится (Junos фактически сделает rollback 1), если не будет дополнительно введена команда «commit» в течение определенного времени (по умолчанию через 10 минут)

root@SRX# commit confirmed
configuration check succeeds
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete

# commit confirmed will be rolled back in 10 minutes
[edit]
root@SRX#

Scheduled commit позволяет производить commit в определенное время, выполняется командой «commit at«. Полезно, когда необходимо синхронизировать применение новой конфигурации на нескольких устройствах. Пример:

root@SRX# commit at 23:55:00                  
configuration check succeeds
commit at will be executed at 2016-06-08 23:55:00 MSK
Exiting configuration mode

root@SRX>

«clear system commit» отменяет scheduled commit:

root@SRX> clear system commit
Pending commit cleared

root@SRX>

«commit synchronize» — производит commit на всех доступных RE (для устройств с несколькими RE) — по умолчанию синхронизации между RE при выполнении простого «commit» не происходит. Можно включить синхронизацию конфигурации между RE по умолчанию:

# set system commit synchronize
/теперь, при выполнении простого commit, конфигурация будет синхронизироваться между RE

Rescue configuration  — позволяет сохранить текущую конфигурацию (active configuration) в commit database, к которой в любое время можно откатиться (не перезаписывается другими commit, живет отдельно). Данная конфигурация должна содержать root password.

 — Создание rescue configuration:

user@SRX> request system configuration rescue save

— Откат к rescue configuration:

root@SRX# rollback rescue  
load complete

[edit]
root@SRX#

—  Удаление rescue configuration:

root@SRX> request system configuration rescue delete

Rescue configuration рекомендуется сохранять с минимальным набором необходимых настроек!

Выход из режима конфигурации можно выполнять отдельными командами («quit configuration- mode»;»exit configuration-mode»), или можно совместить commit и выход из режима конфигурации командой «commit and-quit»:

root@SRX# commit and-quit
commit complete
Exiting configuration mode

root@SRX>

В режиме конфигурации Junos OS в квадратных скобках всегда показывает на каком уровне иерархии мы находимся, в отличие от Cisco IOS, что очень удобно при настройке:

/Вся конфигурация устройства
[edit]
root@SRX# edit system

/Конфигурация параметров системы
[edit system]
root@SRX# top edit interfaces

/Конфигурация всех интерфейсов
[edit interfaces]
root@SRX# edit ge-0/0/0

/Конфигурация интерфейса ge-0/0/0
[edit interfaces ge-0/0/0]
root@SRX#

Основные команды конфигурационного режима:

— «show» — зависит от того, в каком режиме выполняется.
В Configuration mode показывает конфигурацию для того уровня иерархии в котором сейчас находимся, например show, выполненный на уровне [edit], покажет всю конфигурацию устройства —

candidate configuration

(аналог «do show run» в Cisco IOS)
— «edit» — служит для перемещения внутрь иерархии конфигурации
— «up» — подняться в иерархии конфигурации на уровень вверх, up 2 — на два уровня, и т.д.
— «top» — подняться с любого уровня в конфигурации до корня [edit]
— «set» — внести изменения в конфигурацию (добавить конфигурацию)
— «delete» — внести изменения в конфигурацию (удалить конфигурацию)
— «deactivate» — позволяет временно отключить часть конфигурации (сделать её неактивной), без удаления:

# deactivate protocols stp

— «activate» — сделать конфигурацию активной вновь (# activate interfaces ge-0/0/0)
— «disable» — отключить протокол или интерфейс (admin down):

# set interface ge-0/0/0 disable 

— «copy» — скопировать часть конфигурации, например с одного интерфейса на другой:

# delete interfaces ge-0/0/4
# copy interfaces ge-0/0/3 to ge-0/0/4

— «rename» — позволяет перемещать часть конфигурацию из одной секции в другую, например с одного интерфейса на другой:

# delete interfaces ge-0/0/4
# rename interfaces ge-0/0/3 to ge-0/0/4
/Вся конфигурация с ge-0/0/3 переместится на ge-0/0/4, интерфейса ge-0/0/3 больше не будет существовать в конфигурации.

Другой пример — поменять один IP адрес на интерфейсе на другой:

# rename interfaces ge-0/0/3 unit 0 family inet address 192.168.1.1/24 to address 192.168.2.1/24 

— «commit» — применение конфигурации (работает с любого уровня иерархии, если вы не в режиме configure private — «can only commit from top of private configuration»)

— «rollback» — откатиться до одной из предыдущих конфигураций

— «run» — позволяет выполнять operational mode команды из configuration mode (#run show route, например)

Опции входа в режим конфигурации:

По умолчанию несколько пользователей могут входить в режим конфигурации устройства и выполнять «commit».

«configure exclusive» — позволяет только одному пользователю править и применять конфигурацию. В этом режиме все изменения в candidate configuration которые не были сохранены пропадают: «uncommitted changes will be discarded on exit». Второй пользователь, вошедший на устройство сможет выполнять правки в конфигурации, но при попытке выполнить «commit» получит сообщение: «error: configuration database locked by:».

«configure private» — позволяет нескольким пользователям править и применять конфигурацию независимо друг от друга — у каждого будет своя приватная копия конфигурация, а  «commit» и «rollback» не будет затрагивать конфигурацию другого пользователя.  В этом режиме так же все изменения в candidate configuration которые не были сохранены пропадают: «uncommitted changes will be discarded on exit».

! Если пользователь находится в режиме configure private, то второй, вошедший в режим конфигурации с помощью команды «configure» не сможет производить «commit»:»error: private edits in use. Try ‘configure private’ or ‘configure exclusive’.»

! Если пользователь находится в режиме configure и уже произвел изменения в конфигурации, то второй пользователь не сможет зайти в режим конфигурации ни как «configure exclusive», ни как «configure private»:»error: shared configuration database modified»

2. Operational mode:

Команда «show» в Operational mode показывает статус системы, интерфейсов, протоколов и т.д., «show configuration» покажет конфигурацию устройства — 

active configuration

 (аналог «show run» в Cisco IOS)

Уровни детализации вывода команд в Operational mode от самого краткого до наиболее подробного:

«terse«
«brief«
«detail«
«extensive«

Пример:

> show interfaces terse

Фильтрация вывода show команд:

| match  — аналог include в Cisco IOS
| except — аналог exclude в Cisco IOS
| find — аналог begin в Cisco IOS
| display set — показывает плоскую конфигурацию устройства с использованием набора set команд:

> show configuration | display set

 Help команды Operational mode:

«help apropos» — покажет все доступные команды, содержащие ключевое слово (# help apropos ospf)
«help tip cli» — покажет случайную подсказку по конфигурации JunOS
«help reference» — инструкция по конфигурации той или иной команды, синтаксис и прочее
«help topic» — инструкция по применению той или иной команды (# help topic interfaces address)

Аутентификация:

Настройка порядка аутентификации на устройстве:

# set system authentication order [tacplus | radius | password]

tacplus — TACACS+ server
radius — RADIUS server
password — local DB of device (всегда рекомендуется оставлять)

Local DB будет проверятся даже в том случае, если настроено authentication-order [radius tacplus], но ни один из серверов не отвечает. Если хотя бы 1 сервер отвечает (отправляет устройству accept или reject) то local DB проверяться не будет!

Базовая настройка TACACS+/RADIUS:

# set system tacplus-server 10.0.0.254
# set system radius-server 10.0.0.254

Авторизация пользователей (управление правами):

Класс пользователя (login class) — именованный контейнер, который группирует набор разрешающих правил. По умолчанию доступно 4:

1) super-user: All permissions
2) operator: clear, network, reset, trace, view
3) read-only: view
4) unauthorized: no permissions

Каждый пользователь может находиться

только в одном

login class!

Настройка интерфейсов:

В Junos OS есть понятие unit — это некий аналог subinterface в Cisco IOS. Все интерфейсы обязательно должны иметь unit. По умолчанию на интерфейсы назначен unit 0 (это можно трактовать как простой L2/L3 интерфейс в IOS). В конфигурации устройства unit разделяет собой физические свойства интерфейса (скорость, дуплекс и т.д.) и логические (ip адрес, protocol family и т.д.):

(Физические характеристики интерфейса)
unit number {
(Логические характеристики интерфейса)

Если необходимо настроить IP-адрес на интерфейсе (сделать его как native L3 routed интерфейс), или настроить как простой L2 switchport интерфейс (не важно Trunk или Access), то это обязательно должен быть unit 0 (так же это касается PPP и HDLC), например:

/L3 interface
#set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.1/24
/L2 interface
#set interfaces ge-0/0/0 unit 0 family ethernet-switching 

Address Family Identifier (AFI) Junos OS (определяет протокол, который будет работать на интерфейсе — тип интерфейса):

  1. family ethernet-switching — L2 порт (switchport in Cisco IOS)
  2. family inet — L3 порт IPv4 (IPv4 routed port/no switchport in Cisco IOS)
  3. family inet6 — L3 порт IPv6 (IPv6 routed port/no switchport in Cisco IOS)
  4. family mpls — MPLS
  5. family iso — IS-IS routing 
Настройка L3 Routed интерфейса:

#set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.1/24
#set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.2/24 preffered
/
#set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24
#set interfaces ge-0/0/1 unit 0 family inet address 192.168.2.1/24 primary

На один интерфейс в Junos OS можно назначать несколько IP адресов, при настройке он не заменится на новый, как на оборудовании Cisco.

«preferred» — эта опция используется когда несколько IP адресов назначаются на 1 интерфейс и они принадлежат одной подсети. Preferred адрес будет использоваться как адрес источника для узлов в directly connected сети. По умолчанию (если опция не прописана) выбирается наименьший адрес из настроенных.

«primary» — эта опция позволяет помечать какой адрес будет использоваться для генерации broadcast и multicast сообщений, а так же будет использоваться когда пакет необходимо отправить в другую подсеть (не directly connected). По умолчанию (если опция не прописана) выбирается наименьший адрес из настроенных.

Настройка Router-on-a-stick:

/Включение тэгирования на интерфейсе
#set interfaces ge-0/0/0 vlan-tagging
/Привязка unit к vlan-id (номер юнита и vlan-id технически могут не совпадать)
#set interfaces ge-0/0/0 unit 10 vlan-id 10
#set interfaces ge-0/0/0 unit 20 vlan-id 20
/Назначение IP адреса на подинтерфейсы 
#set interfaces ge-0/0/0 unit 10 family inet address 192.168.10.1/24
#set interfaces ge-0/0/0 unit 20 family inet address 192.168.20.1/24

Если на интерфейсе настроен по умолчанию family ethernet-switching в unit 0, то его необходимо удалить, т.к. vlan-tagging и family ethernet-switching взаимоисключающие настройки.

Настройка Ethernet-Switching:

Создание VLAN в Junos OS:

#set vlans VLAN10 vlan-id 10
#set vlans VLAN20 vlan-id 20

1) Access port

/Режим портов по умолчанию на коммутаторах Juniper EX (access vlan 1 — default vlan)
#set interfaces ge-0/0/0 unit 0 family ethernet-switching

#set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
#set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan-members VLAN10

2) Trunk port

#set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode trunk
#set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members [name | all]

По умолчанию trunk порт не разрешает прохождение в нем никаких VLAN! Все VLAN в trunk порту тегируются, т.е. Native VLAN отсутствует, при необходимости (например, если trunk между коммутатором Cisco и Juniper) его можно настроить:

#set interfaces ge-0/0/0 unit 0 family ethernet-switching native-vlan-id 1

При этом native VLAN необходимо удалить из разрешенных в trunk «vlan members».

3) Routed Vlan Interface (RVI)

Аналог SVI в Cisco IOS. Но если в IOS при создании SVI номер VLAN автоматически ассоциируется с номером SVI интерфейса (interface vlan 10), то в Junos OS нужно отдельно привязывать номер VLAN к номеру RVI интерфейса, и они технически могут не совпадать (но лучше, чтобы они совпадали):

#set vlans VLAN10 l3-interface vlan.10
#set interfaces vlan unit 10 family inet address 192.168.10.10/24
#set vlans VLAN20 l3-interface vlan.20
#set interfaces vlan unit 20 family inet address 192.168.20.20/24

root@EX1> show configuration vlans
VLAN10 {
vlan-id 10;
l3-interface vlan.10;
}
VLAN20 {
vlan-id 20;
l3-interface vlan.20;
}

root@EX1> show configuration interfaces vlan
unit 10 {
family inet {
address 192.168.10.10/24;
}
}
unit 20 {
family inet {
address 192.168.20.20/24;
}
}

Проверки:

«show ethernet-switching interfaces» — покажет если это trunk порт(tagged) или access(untagged), STP статус порта.
«show vlans [brief]» — покажет список VLAN и участвующих интерфейсов.

Настройка Link Aggregation (LACP):

В Junos OS агрегированный интерфейс называется aggregated ethernet (ae). То же самое что и Port-channel в Cisco.

Для того, чтобы настраивать такие интерфейс, необходимо сначала их создать глобально:

/создание 2-х ae интерфейсов
#set chassis aggregated-devices ethernet device-count 2

Количество интерфейсов, которые можно создать, зависит от аппаратной платформы. Все агрегированные интерфейсы сразу появятся в списке интерфейсов устройства и будут доступны для настройки. Т.е. если device-count = 2, то будут созданы ae0 и ae1.

Добавление физических интерфейсов (перед добавлением рекомендуется удалить интерфейсы, т.к. в них не должно быть unit0 и других настроек: «logical unit is not allowed on aggregated links»):

#set interfaces ge-0/0/10 ether-options 802.3ad ae0
#set interfaces ge-0/0/11 ether-options 802.3ad ae0

Настройка LACP на агрегированном интерфейсе:

 #set interfaces ae0 aggregated-ether-options lacp [active | passive]

Настройка ethernet-switching на агрегированном интерфейсе (L2 LAG):

#set interfaces ae0 unit 0 family ethernet-switching
/настройки trunk/access так же выполняются на интерфейсе ae0

Настройка ip routing на агрегированном интерфейсе (L3 LAG):

#set interfaces ae0 unit 0 family inet address 20.0.0.1/30

Проверки:

«show lacp interfaces» — интерфейсы, участвующие в LACP, их роль (на локальном устройстве и на удаленной стороне)
«show spanning-tree interface» — агрегированный интерфейс с точки зрения STP (если настроен L2 LAG).

Spanning-tree в Junos OS:

По умолчанию на коммутаторах Juniper работает STP/RSTP протокол, но в отличие от Cisco c её PVST или Rapid-PVST, на Juniper 1 instance для всех VLAN. Для per-vlan spanning-tree необходимо настраивать протокол VSTP.

# set protocols stp
/или
# set protocols rstp
/или
# set protocols mstp
/или
# set protocols vstp vlan all

Настройка bridge priority:

/для STP
# set protocols stp bridge-priority 4k
/для RSTP
# set protocols rstp bridge-priority 4k
/для MSTP
# set protocols mstp msti 1 bridge-priority 4k
/для VSTP
# set protocols vstp vlan vlan10 bridge-priority 4k

Настройка STP cost:

/для STP
# set protocols stp interface ge-0/0/0 cost 10
/для RSTP
# set protocols rstp interface ge-0/0/0 cost 10
/для MSTP
# set protocols mstp msti 1 interface ge-0/0/0 cost 10
/для VSTP
# set protocols vstp vlan vlan10 interface ge-0/0/0 cost 10

Edge port (STP Portfast):

#set protocols rstp interface ge-0/0/0 edge

Проверки STP:

«show spanning-tree interfaces» — участвующие в STP интерфейсы, их cost, состояние и роль.
«show spanning-tree bridge» — настройки STP на коммутаторе в целом.

Особенности маршрутизации в Junos OS:

В Junos OS вместо AD — Administrative Distance используется термин Route Preference. Значения Route Preference по умолчанию:

Junos OS так же автоматически создает и поддерживает несколько таблиц маршрутизации (в зависимости от настроек):

inet.0 — IPv4 unicast routes
inet.1 — IPv4 multicast forwarding cache
inet.2 — Unicast routes that are used for multicast reverse-path-forwarding (RPF) lookup
inet.3 — IPv4 MPLS
inet6.0 — IPv6 unicast routes
inet6.1 — IPv6 multicast forwarding cache
mpls.0 — MPLS label switching operations
bgp.l2vpn.0 — Layer 2 VPN routes learned from BGP
bgp.l3vpn.0 — Layer 3 VPN routes learned from BGP

Просмотр отдельной таблицы маршрутизации (например inet.0):

> show route table inet.0

Просмотр forwarding-table:

> show route forwarding-table

Основные типы маршрутов в forwarding-table:

dest — Remote addresses directly reachable through an interface
intf — Installed as a result of configuring an interface
perm — Routes installed by the kernel
user — Routes installed by the routing protocol process or as a result of the configuration
iddn — Destination route for which the interface is unreachable

Router ID для динамических протоколов маршрутизации создается глобально на всё шасси и действует для всех протоколов:

# set routing-option router-id 1.1.1.1

 Настройка Static Routing:

Статическая маршрутизация настраивается в [edit routing-option]. Пример default route:

#set routing-option static route 0.0.0.0/0 next-hop 10.0.0.1

Вместо next-hop есть возможность прописать 2 опции для сброса маршрута (Null0 в терминологии Cisco):

1) reject — сбросить пакет и отправить ICMP сообщение отправителю (type 3, code 4)
2) discard — сбросить пакет «молча»

 — Опция «no-readvertise» — запрещает производить редистрибуцию этого статического маршрута в другие протоколы маршрутизации через Routing Policy (в OSPF, например).

#set routing-option static route 0.0.0.0/0 next-hop 10.0.0.1 no-readvertise

 — По умолчанию Junos OS не выполняет recursive lookup для статических маршрутов. Но можно в качестве next-hop добавить адрес не из direct connected сети, для этого необходима опция «resolve». Juniper тогда будет пытаться разрешить этот маршрут через другой статический или через протокол динамической маршрутизации.

#set routing-option static route 20.0.0.0/24 next-hop 30.0.0.1 resolve
/сеть 30.0.0.0 не directly-connected

 — Опция «qualified-next-hop» (floating static в терминах Cisco) — можно настроить второй next-hop с увеличенным (можно и со значением меньше 5) значением route preference, и когда основной next-hop станет недоступен, в таблицу маршрутизации будет инсталлирован этот же маршрут через запасной next-hop.

#set routing-option static route 0.0.0.0/0 qualified-next-hop 10.0.0.2

Проверки Static Routing:

«show route protocol static» — таблица маршрутизации, с выводом только статических маршрутов.

Настройка RIP:

Default Routing Policy для RIP:

Import — accept all RIP routes
Export — reject everything

Настройку добавлю при необходимости!

Настройка OSPF:Default Routing Policy для OSPF:

Import — accept all OSPF routes
Export — reject everything (but floods LSA by default !)

Routing Policy не может контролировать LSA flooding, reject everything в данном случае значит то, что из таблицы маршрутизации ничего не анонсируется соседям по умолчанию, но так как OSPF это Link-State протокол, то это не проблема для достижения полной сходимости и обмена OSPF маршрутами!

Основные настройки OSPF:

# set protocols ospf area 0 interface ge-0/0/0
# set protocols ospf area 0 interface ge-0/0/1
/настройка Hello/Dead интервалов
# set protocols ospf area 0 interface ge-0/0/0 hello-interval 1 dead-interval 4
/настройка интерфейса как Passive
# set protocols ospf area 0 interface ge-0/0/1 passive
/настройка reference-bandwidth (по умолчанию reference-bandwidth=100Mbps)
# set protocols ospf reference-bandwidth 10g
/настройка метрики вручную
# set protocols ospf area 0 interface ge-0/0/0 metric 10
/настройка интерфейса как point-to-point
# set protocols ospf area 0 interface ge-0/0/0 interface-type p2p
/настройка MD5 аутентификации
# set protocols ospf area 0 interface ge-0/0/0 authentication md5 0 key Juniper

Если unit не указывается при настройке, Junos OS полагает, что это unit 0 (т.е. ge-0/0/0.0)

Проверки OSPF:

«show ospf neigbor» — таблица соседей
«show route protocol ospf» — таблица маршрутизации с выводом только OSPF маршрутов
«show ospf interface ge-0/0/0 detail» — детальное описание интерфейса, на котором запущен OSPF

Настройка BGP:

Default Routing Policy для BGP:

Import — accept all BGP routes
Export — accept all active BGP routes

Первым делом необходимо настроить номер автономной системы устройства:

#set routing-options autonomous-system 65000

Так же рекомендуется заранее сконфигурировать router-id (настраивается глобально), если он не задан.

Минимальная настройка EBGP:

/название группы: external-peer, тип группы: external (EBGP), internal (IBGP)
#set protocols bgp group external-peer type external
/номер удаленной AS
#set protocols bgp group external-peer peer-as 65001
/IPv4 адрес пира в другой AS
#set protocols bgp group external-peer neighbor 192.168.0.2

В Junos OS, в отличие от Cisco IOS, BGP пиры должны обязательно присваиваться к группам.

Логирование:

Все логи хранятся в /var/log

Настройки логирования производятся в [edit system syslog]

host «ip-address» — удаленный syslog сервер
archive — как логи будут архивиться на устройстве
console — настройки логирования в консоль устройства

Обновление Junos OS:

Обновление рекомендуется производить путем предварительной загрузки новой версии ПО на само устройство (по протоколу SCP или FTP) в директорию /var/tmp

Проверка MD5 перед обновлением:

> file checksum md5 /var/tmp/jinstall-ex-2200-12.3R12.4-domestic-signed.tgz

Обновление:

> request system software add /var/tmp/jinstall-ex-2200-12.3R12.4-domestic-signed.tgz

После процедуры обновления нужно обязательно перезагрузить устройство!

Если после обновления имеются проблемы, можно загрузиться с backup раздела в предыдущую версию ПО (он по умолчанию не обновляется сразу):

> request system reboot slice alternate 

Обновление backup раздела, если всё работает отлично после обновления основного:

> request system snapshot slice alternate

Удаление старых файлов, старых log-сообщений:

/опция dry-run покажет файлы, которые будут удалены (list of files to be deleted)
> request system storage cleanup {dry-run} 

Сохранение и загрузка конфигурации:

Сохранение конфигурации в файл выполняется в режиме конфигурации:

# save «filename»
# save «path/filename»
# save ftp://; scp://

Если не указан путь сохранения, то конфигурация сохраняется в директорию пользователя (например, var/home/admin1)

Загрузка конфигурации выполняется при помощи команды «load»:

/сбросить устройство к заводским настройкам
# load factory-default

Другие опции load:

«merge» — слить текущую конфигурацию и загружаемую вместе (наложить друг на друга)
«override» — полностью заменить текущую конфигурацию (только из [edit])
«set» — позволяет загрузить конфигурацию в set командах из терминал или из файла
«terminal» — заливать конфигурацию из терминала

Troubleshooting:

System:

> show system alarms /показать системные alarm
> show system boot-messages /показать сообщения, которые выдавались в процессе загрузки устройства
> show system storage /показать информацию о подсистеме хранения
> show system snapshot media internal /показать информацию об основном и backup разделах
> show system storage partitions /показать разделы устройства

Chassis:

> show chassis alarms /показать alarm для устройства
> show chassis environment /показать температуру устройства
> show chassis hardware /показать информацию об устройстве, включая серийный номер
> show chassis firmware /показать версию загрузчика и ПО
> show chassis led /показать информацию о светодиодах на устройстве(работает не на всех)

Еcли chassis alarm горит из-за того, что management порт не подключен («Management Ethernet Link Down»), можно настроить игнорирование данного alarm:

# set chassis alarm management-ethernet link-down ignore

Обозначение интерфейсов в Junos OS:

Физические:

MM-FPC/PIC/Port (пример ge-0/0/10)

MM — Media Type (fe — Fast Ethernet; ge — Gigabit Ethernet; se — Serial)

FPC — Flexible PIC Controller (линейная карта, устанавливаемая в шасси (MX), либо всё устройство целиком, в случае фиксированной конфигурации (EX switch))

PIC — Physical Interface Card (портовая карта, устанавливаемая в FPC)

Port — Конкретный физический порт


Системные процессы Junos OS (daemons):

rpd — routing protocol daemon — отвечает все протоколы маршрутизации
mgd — management daemon — отвечает за управление оборудованием
dcd — device control daemon — отвечает за конфигурацию интерфейсов
chassisd — отвечает за мониторинг состояния всего шасси
snmpd — SNMP daemon

Архитектура Junos OS:

———
v.1.00

По snmp снимать входящие ошибки. В счетчике ifInErrors все подряд. Статус дуплекса есть в EtherLike-MIB как и множество других счетчиков.

input errors overrun

На шасси с установленной свичевой картой. Ошибки overrun вызваны недостаточной производительностью маршрутизатора. Причем ситуацию в конкретном случае можно усугубить. Для этого достаточно в таких маршрутизаторах использовать свичевые карты, чтобы трафик передавался через внутренний интерфейс Ba0/3. Cудя по таблице iftable, счетчики ошибок будут расти быстрее на этом интерфейсе при использовании свичевой карты с гигабитными портами.
В качестве примера вывод счетчиков с маршрутизатора cisco 1921

cisco1921# sh int | in overr|^GigabitEthernet0/[01]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
GigabitEthernet0/0 is up, line protocol is up
     48677539 input errors, 0 CRC, 0 frame, 48677539 overrun, 0 ignored
GigabitEthernet0/1 is up, line protocol is up
     4533642 input errors, 0 CRC, 0 frame, 4533642 overrun, 0 ignored

input errors ignored

Недостаточная производительность. От приоритезации толку нет, будут дропы в голосе и видео.

98559 input errors, 0 CRC, 0 frame, 0 overrun, 98559 ignored

input errors unknown protocol drops

Вероятно LLDP включен на коммутаторе и маршрутизатором не поддерживается.

2238654 unknown protocol drops

input errors CRC

Проверить физику, дуплекс. Возможно небольшое колво ошибок при включении интерфейса.

59 input errors, 59 CRC, 0 frame, 0 overrun, 0 ignored

output drops

При настроенных на ограничение скорости политиках счетчик малоинформативен.

Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 3354485

input errors runts

Порт настроен в access, а на удаленной в trunk если ошибки постоянно растут.

32 runts, 0 giants, 0 throttles
32 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

input errors FCS

Менять SFP, порт оборудование на удаленной стороне.
Но это не точно поможет, т.к. если коммутатор на удаленной стороне работает в Cut-Through режиме коммутации, то фрейм с ошибкой мог передаться с предыдущего сетевого оборудования.
Возможно не работает автосогласование дуплекса. На 100мбит оптических линках это возможно. /network/eltex/#negotiation

input errors CRC

Проверить физику, дуплекс. На оптических линках возникает при заломах пачкорда, поэтому не надо его наматывать на органайзеры.
Ошибки могут возникать, если на одномодовом участке волс есть многомодовый патчкорд или пигтейл.

output discards

  • если есть qos, смотреть очереди, буферы. Вот тут и начиаешь ценить коммутаторы со счетчиками очередей.
  • speed mismatch (аплинк 1Gbit/s, downlink 100Mbit/s). Потери из-за burst, который не смог буферизировать коммутатор. Большинство свичей с shared буфером на всех портах.

дропы из-за неудачной модели

При выключенном на всех портах flowcontrol на тестах работает все медленно.
Счетчика ошибок нет. Смотреть и сравнивать счетчики на аплинке и даунлике.
Если не одинаково, то ставить другую модель коммутатора.

дропы из-за переподписки

На модульных коммутаторах при использовании плат с переподпиской возможны ошибки. Обратить внимание, что порты сгруппированы и не испольовать часть портов.

Ошибки на интерфейсах есть двух разновидностей: ошибки входа и ошибки вывода.

Ошибки входа бывают следующие:

• Errors: Суммарное количество отмен входящих кадров и ошибок FCS.

• Drops: Количество пакетов, которые дропнул диспетчер ввода-вывода пакетов на ASIC’е. Если интерфейс перегружен, этот счётчик увеличивается на единицу каждрый раз, когда RED дропает пакет.

• Framing errors: Количество пакетов, полученных с неверной контрольной суммой (FCS).

• Runts: «Карлики».

• Policed discards: Количество отброшенных пакетов, так как они были не распознаны или не подпадали под выборку. Обычно, это поле показывает протоколы, которые не обрабатывает JUNOS

• L3 incompletes: Количество отброшенных пакетов с битыми L3-заголовками. Например, поле кадра «destination IP» меньше 32-х бит.

• L2 channel errors: Количество событий, когда конфигурация не смогла назначить логический интерфейс для входящего пакета.

• L2 mismatch timeouts: Количество искаженных или мелких пакетов, которые не смогли быть прочитаны.

• FIFO errors: Количество FIFO-ошибок на входе, о которых сообщил ASIC на контроллере интерфейса.
!!! Это значение должно быть строго НОЛЬ. Ненулевое значение указывает на аппаратный сбой контроллера.

• Resource errors: Суммарное количество дропнутых пакетов.

Ошибки вывода бывают следующие:

• Carrier transitions: Количество переключений интерфейса из состояния «выкл» в состояние «вкл». В норме вещей, эта цифра растёт ОЧЕНЬ медленно (по количеству выдёргиваний патч-кордов, отключений «ответного» устройства или перегрызаний кабеля крысами). Если это число растёт быстро, то у вас «флапает» интерфейс по причине некачественного кабеля, плохого контакта или аппаратного сбоя.

• Errors: Суммарное количество отмен исходящих кадров и ошибок FCS.

• Drops: Количество исходящих пакетов, которые дропнул диспетчер ввода-вывода пакетов на ASIC’е. Если интерфейс перегружен, этот счётчик увеличивается на единицу каждрый раз, когда RED дропает пакет.

• Collisions: Количество Ethernet-коллизий. Важное уточнение: интерфейс Gigabit Ethernet поддерживает работу ТОЛЬКО в режиме «full-duplex»! Соответственно, это для такого интерфейса это число должно ВСЕГДА равняться нулю. Если вы видите ненулевое значение — у вас аппаратный сбой интерфейса или баг в софте.

• Aged packets: Количество пакетов, которые оставались в оперативной памяти маршрутизатора слишком долго и были отброшены. В норме вещей, это число должно быть ВСЕГДА равно нулю. Ненулевое значение указывает на аппаратный сбой или баги в софте.

• FIFO errors: Количество FIFO-ошибок на выходе, о которых сообщил ASIC на контроллере интерфейса.
!!! Это значение должно быть строго НОЛЬ. Ненулевое значение указывает на аппаратный сбой контроллера.

• HS link CRC errors: Количество ошибок в высокоскоростных линиях внутренней связи между ASIC’ами внутри роутера.

• MTU errors: Количество пакетов, чей размер привысил MTU на интерфейсе.

• Resource errors: Суммарное количество дропнутых пакетов.

_

Interface Troubleshooting

Interfaces can have a variety of issues depending on the actual interface type,
and listing all the possibilities would require a separate book! Instead,
in this section, we will discuss a few common issues that illustrate the
types of troubleshooting commands available on the router.

Address Configuration Issues

Since Juniper Networks routers allow multiple IP addresses to be
configured on a single logical unit, configuration errors can occur if
care is not taken. Lager has an IP
address of 10.10.20.122 configured on its gigabit Ethernet interface
with a subnet mask of /24. This was noticed to be a configuration error,
as the mask should have been configured for /27:

[edit interfaces ge-2/0/1]
root@Lager# show
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.20.122/24;
    }
}

Here, the address of 10.10.20.122 is added with the correct subnet
of /27:

[edit interfaces ge-2/0/1]
root@Lager# set unit 100 family inet address 10.10.20.122/27

When you view the resultant interface configuration, the router
appears to contain the duplicate IP addresses with varying subnet masks.
This illustrates the fact that IP addresses are not overridden per
logical unit, but simply are added to the logical unit:

[edit interfaces ge-2/0/1]
root@Lager# show
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.20.122/24;
        address 10.10.20.122/27;
    }
}

To correct this, the old address with the /24 mask is removed by
use of the delete command:

[edit interfaces ge-2/0/1]
root@Lager# delete unit 100 family inet address 10.10.20.122/24

Another solution with the same result is to use the rename command to
change the subnet mask from /24 to /27:

[edit interfaces ge-2/0/1 unit 100]

root@Lager# rename address 10.10.20.122/24 to address 10.10.20.122/27

Since Juniper Networks routers allow placement of multiple
addresses on a single logical interface, care must also be taken to
allow for the router to choose the correct source IP address for
outgoing packets on that interface. By default, the source IP address is
chosen by using the primary and preferred addresses assigned to the
interface. Each unit can have only one primary address, but each
interface can have multiple preferred addresses. Simply put, a primary
address is the address chosen to source local packets out of the
interface destined for a remote network. As shown in the following
output, 10.20.20.122 is the only address on the interface, and as such,
it contains both a primary and a preferred flag:

root@Lager# run show interfaces ge-2/0/1.100
  Logical interface ge-2/0/1.100 (Index 67) (SNMP ifIndex 45)
   Flags: SNMP-Traps 0x4000 VLAN-Tag [0x8100.100] Encapsulation: ENET2
    Input packets : 2215
    Output packets: 23
    Protocol inet, MTU: 1500
      Flags: None
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 10.10.20.96/27, Local: 10.10.20.122,
        Broadcast: 10.10.20.127

Now configure two additional IP addresses, 6.6.6.6 and 6.6.6.4, on
the interface and observe the results:

root@Lager# set address 6.6.6.4/24
root@Lager# set address 6.6.6.6/24
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# commit
commit complete

[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# run show interfaces ge-2/0/1.100 | find protocol
    Protocol inet, MTU: 1500
      Flags: None
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 6.6.6/24, Local: 6.6.6.4, Broadcast: 6.6.6.255
      Addresses
        Destination: 6.6.6/24, Local: 6.6.6.6, Broadcast: 6.6.6.255
      Addresses, Flags: Is-Preferred
        Destination: 10.10.20.96/27, Local: 10.10.20.122,
        Broadcast: 10.10.20.127

The primary address has changed to 6.6.6.4, and now two addresses
contain the preferred flag: addresses 6.6.6.6 and 10.10.20.122. The
preferred address is used as the source IP address if you’re trying to
reach a network that is locally attached. In this case, if traffic is
destined for 172.16.1.2, the source IP address of 6.6.6.4 is used, but
if the destination address is 10.10.20.121, the source IP address of
10.10.20.122 will be used. Junos by default will choose the primary and
preferred addresses based on the lowest IP address that is configured.
The primary address will be the lower IP address configured on the
interface, and the preferred address will be the lowest IP address
configured for each local subnet. In the earlier example, traffic
destined to a host on the 6.6.6/24 subnet is sourced from 6.6.6.4. You
can modify these defaults by configuring the appropriate flag (primary
or preferred) to the address of choice:

[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# set address 10.10.20.122/27 primary

[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# commit
commit complete

The 10.10.20.122 address has now been configured for the primary
address of the interface, as indicated by the show interfaces
command:

[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# run show interfaces ge-2/0/1.100 | find protocol
    Protocol inet, MTU: 1500
      Flags: None
      Addresses, Flags: Is-Preferred
        Destination: 6.6.6/24, Local: 6.6.6.4, Broadcast: 6.6.6.255
      Addresses
        Destination: 6.6.6/24, Local: 6.6.6.6, Broadcast: 6.6.6.255
      Addresses, Flags: Primary Is-Preferred Is-Primary
        Destination: 10.10.20.96/27, Local: 10.10.20.122,
        Broadcast: 10.10.20.127
[edit interfaces ge-2/0/1 unit 100 family inet]
root@Lager# set address 6.6.6.6/24 preferred

Encapsulation Mismatches

For two routers’ interfaces to communicate properly, the same
Layer 2 encapsulation must be configured on each device; depending on
the type of encapsulation, this could be a difficult error to determine.
A common interface medium where this could occur is Ethernet. The
interface on router Lager is
configured to send VLAN tagged frames on the 10.10.20/24 subnet;
however, a ping to router Hangover in
that segment fails:

[edit interfaces ge-2/0/1 unit 100]
root@Lager# run ping 10.10.20.121
PING 10.10.20.121 (10.10.20.121): 56 data bytes
^C
--- 10.10.20.121 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Looking at the statistics on Lager’s Ethernet interface, a number of Layer
2 channel errors are recorded:

root@Lager# run show interfaces ge-2/0/1 extensive
Physical interface: ge-2/0/1, Enabled, Physical link is Up
  Interface index: 142, SNMP ifIndex: 37, Generation: 143
  Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex 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: 0x4000
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Hold-times     : Up 0 ms, Down 0 ms
  Current address: 00:12:1e:76:1e:29, Hardware address:
00:12:1e:76:1e:29
  Last flapped   : 2010-04-05 22:01:18 UTC (1w0d 10:11 ago)
  Statistics last cleared: 2010-04-13 08:10:48 UTC (00:02:18 ago)
  Traffic statistics:
   Input  bytes  :                    0                    0 bps
   Output bytes  :                  230                    0 bps
   Input  packets:                    0                    0 pps
   Output packets:                    5                    0 pps
  Input errors:
   Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards:
   0, L3 incompletes: 0, L2 channel errors: 42, L2 mismatch timeouts:
   ,0 FIFO errors: 0, Resource errors: 0
 Output errors:
   Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged
   packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0,
   Resource errors: 0
 Egress queues: 8 supported, 8 in use
.....

To see whether the Layer 2 channel errors are currently increasing
or whether they are older counters that have not been cleared,
the monitor interface
ge-2/0/1
command is issued. The second column in the following
code snippet shows the interface counter statistics, and the current
delta column indicates real-time statistics recorded since issuing the
monitor command. Layer 2 channel
errors are currently increasing, as the current delta counter
indicates:

Lager                            Seconds: 14         Time: 08:13:54
                                                   Delay: 0/0/50
Interface: ge-2/0/1, Enabled, Link is Up
Encapsulation: Ethernet, Speed: 1000mbps
Traffic statistics:                                   Current delta
  Input bytes:                    0 (0 bps)                     [0]
  Output bytes:                 230 (0 bps)                     [0]
  Input packets:                  0 (0 pps)                     [0]
  Output packets:                 5 (0 pps)                     [0]
Error statistics:
  Input errors:                   0                             [0]
  Input drops:                    0                             [0]
  Input framing errors:           0                             [0]
  Policed discards:               0                             [0]
  L3 incompletes:                 0                             [0]
  L2 channel errors:            105                            [18]
  L2 mismatch timeouts:           0  Carrier transit            [0]

An additional monitor command
is now used to verify that the router is sending out the correct
packets. The monitor traffic
command is the router’s tcpdump[1] utility that allows local router traffic to be observed on
a particular interface. Since Ethernet requires the IP address to MAC
address mapping before sending the FRAME, a series of ARP requests with
an 802.1Q (VLAN) header are sent out to the interface with no response
received. The layer2-header switch is
used to obtain some Ethernet header information as the monitor command is usually Layer 3 and Layer 4
only:

[edit interfaces ge-2/0/1 unit 100]
root@Lager# run monitor traffic interface ge-2/0/1 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-2/0/1, capture size 96 bytes.
....

08:18:09.764757 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:10.564781 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:12.214889 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:12.814634 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:13.414648 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
08:18:14.314858 Out 0:12:1e:76:1e:29 > Broadcast, ethertype 802.1Q (0x8100), length
46: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.121 tell 10.10.20.122
^C
7 packets received by filter
0 packets dropped by kernel

[edit interfaces ge-2/0/1 unit 100]
root@Lager#

Router Hangover is then
accessed and a ping command toward Lager is issued. The monitor traffic
command is issued at Hangover with
similar output, except for a single important difference. While router
Lager is sending out the ARP packets
with an 802.1Q header (0 × 8100), router Hangover appears to be sending a
non-VLAN-tagged Ethernet frame (0 × 0806), which is the cause of the
Layer 2 channel errors that were previously discovered:

doug@hangover> monitor traffic interface ge-2/0/0 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Listening on ge-2/0/0, capture size 96 bytes
....
08:20:32.901733 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:33.801530 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:34.601659 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:35.301622 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:36.001475 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
08:20:36.941611 Out 0:12:1e:75:fa:28 > Broadcast, ethertype ARP (0x0806), length 42:
arp who-has 10.10.20.122 tell 10.10.20.121
^C
7 packets received by filter
0 packets dropped by kernel

After correcting the configuration error on Hangover to allow for VLAN encapsulation with
the correct VLAN ID, the ping succeeds and is verified:

root@Lager# run monitor traffic interface ge-2/0/1 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Listening on ge-2/0/1, capture size 96 bytes
...

08:20:55.076174  In 0:12:1e:75:fa:28 > Broadcast, ethertype 802.1Q (0x8100), length
60: vlan 100, p 0, ethertype ARP, arp who-has 10.10.20.122 tell 10.10.20.121
08:20:55.076308 Out 0:12:1e:76:1e:29 > 0:12:1e:75:fa:28, ethertype 802.1Q (0x8100),
length 46: vlan 100, p 0, ethertype ARP, arp reply 10.10.20.122 is-at 0:12:1e:76:1e:
29
08:20:55.096237  In PFE proto 2 (ipv4): 10.10.20.121 > 10.10.20.122: ICMP echo
request seq 0, length 64
08:20:55.096272 Out 0:12:1e:76:1e:29 > 0:12:1e:75:fa:28, ethertype 802.1Q (0x8100),
length 102: vlan 100, p 0, ethertype IPv4, 10.10.20.122 > 10.10.20.121: ICMP echo
reply seq 0, length 64

Path MTU Issues

When an IP packet is transiting a network, it is often fragmented so
that it can transverse interfaces with varying sizes of MTUs. However,
some applications do not allow this fragmentation, so you must ensure
that the ingress MTU is not larger than a transit MTU for those
applications. One simple tool you can use to test whether the proper MTU
is assigned is the packet internet
groper
(ping) command.
Connectivity to a remote system is confirmed on router Lager by issuing a ping command to an address of
172.17.20.2:

root@Lager> ping 172.17.20.2
PING 172.17.20.2 (172.17.20.2): 56 data bytes
64 bytes from 172.17.20.2: icmp_seq=0 ttl=62 time=7.133 ms
64 bytes from 172.17.20.2: icmp_seq=1 ttl=62 time=10.375 ms
^C
--- 172.17.20.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.133/8.754/10.375/1.621 ms

Issue the traceroute command to
check the path these packets take to reach the destination. Router
Lager appears to be located two IP
systems away from the destination of 172.17.20.2:

root@Lager> traceroute 172.17.20.2
traceroute to 172.17.20.2 (172.17.20.2), 30 hops max, 40 byte packets
 1  10.10.20.121 (10.10.20.121)  18.572 ms  12.953 ms  35.782 ms
 2  172.17.20.2 (172.17.20.2)  9.804 ms  9.497 ms  10.003 ms

The application that is being tested requires an MTU of 1,508
bytes, so a ping of size 1,500 is sent with 8 bytes of overhead to the
remote station:

root@Lager> ping 172.17.20.2 size 1500 count 3
PING 172.17.20.2 (172.17.20.2): 1500 data bytes
1508 bytes from 172.17.20.2: icmp_seq=0 ttl=63 time=11.591 ms
1508 bytes from 172.17.20.2: icmp_seq=1 ttl=63 time=10.580 ms
1508 bytes from 172.17.20.2: icmp_seq=2 ttl=63 time=20.939 ms

--- 172.17.20.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.580/14.370/20.939/4.663 ms

The ping succeeds, and at first glance, all appears well, but
let’s not count our chickens before they hatch! Some examination into
the operation of the ping command is
needed before giving the green light of approval. By default, the ping
packet will be sent out with the do-not-fragment bit cleared in the IP header.
This means that although the ping packet will exit the router with a
size of 1,508 bytes, it could be fragmented along the way. So, now issue
the ping command with the do-not-fragment flag set and observe the
results:

root@Lager> ping 172.17.20.2 size 1500 count 3 do-not-fragment
PING 172.17.20.2 (172.17.20.2): 1200 data bytes
36 bytes from 10.10.20.121: frag needed and DF set (MTU 1119)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 04cc af90   2 0000  40  01 a809 10.10.20.122  172.17.20.2

36 bytes from 10.10.20.121: frag needed and DF set (MTU 1119)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 04cc af91   2 0000  40  01 a808 10.10.20.122  172.17.20.2

^C
--- 172.17.20.2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

It appears that the intermediate station cannot handle a packet
larger than 1,119 bytes on its outgoing interface toward the
destination, as observed by the ICMP message that is returned. Luckily,
we found this out before the application was deployed, so we were able
to correct this problem!

Note

If the outgoing interface on an
intermediate system did not contain the proper MTU size, an ICMP error
message will be generated. If the incoming
interface was configured with a smaller-than-needed MTU, the
observation will be different. Since the packet is dropped at input,
no ICMP MTU message will be received. Instead, oversize frame errors
would increase on the intermediate system’s input interface.

Looped Interfaces

Creating a physical loop on an interface has been a troubleshooting
tool for many years. Since the physical path of a leased line frequently
consists of multiple segments, often a problem can be localized by
testing the circuit segment by segment. The idea is to create a loop at
the endpoint of the circuit and send a series of tests toward that
endpoint that can determine whether packets are lost or corrupted during
transmission. Two types of loops are supported on most types of
interfaces: a remote loop and a local loop. A local loop creates a
loop toward the router, whereas a remote loop is a
line loop that is created toward the downstream network device (see
Figure 4-17).

Loopback types

Figure 4-17. Loopback types

Often, the local LEC will go through a series of tests during the
provisioning process to ensure that the circuit integrity includes
loopback testing. The circuit may also be left in the looped state to
avoid any local alarm generation. To see whether a loop is still in
place, issue a ping toward the remote end of the circuit. If the remote
end is looped (remote), the ping packets will continue until the Time to
Live (TTL) expires, resulting in ICMP TTL expiration messages:

[edit]
doug@PBR# run ping 10.200.8.10
PING 10.200.8.10 (10.200.8.10): 56 data bytes
36 bytes from 10.200.8.9: Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 30e2   0 0000  01  01 6325 10.200.8.9  10.200.8.10
36 bytes from 10.200.8.9: Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 30e3   0 0000  01  01 6324 10.200.8.9  10.200.8.10

36 bytes from 10.200.8.9: Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 30e6   0 0000  01  01 6321 10.200.8.9  10.200.8.10

^C
--- 10.200.8.10 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

On the remote device, a loop will be indicated (remote or local)
by examining the loopback
flag in the show interfaces
command:

dougl@closing_time# run show interfaces  t1-2/0/2
Physical interface: t1-2/0/2, Enabled, Physical link is Up
  Interface index: 139, SNMP ifIndex: 37
  Link-level type: Cisco-HDLC, MTU: 1504, Clocking: Internal, Speed: T1,
  Loopback: Remote, FCS: 16, Framing: ESF
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps 16384
  Link flags     : No-Keepalives
  CoS queues     : 8 supported
  Last flapped   : 2007-04-17 16:55:37 UTC (00:02:01 ago)
  Input rate     : 200 bps (0 pps)
  Output rate    : 224 bps (0 pps)
  DS1   alarms   : None
  DS1   defects  : None

Get Junos Enterprise Routing, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

  • Show Interfaces
  • Show Interfaces Detail
  • Show Interfaces Extensive
  • Input Errors
  • Output Errors
  • Output Field Definitions

show interfaces

Sample Output

 user@host> show interfaces t3-5/2/0 
 Physical interface: t3-5/2/0, Enabled, Physical link is Up
   Interface index: 30, SNMP ifIndex: 41
   Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal
   Speed: T3, Loopback: None, CRC: 16, Mode: C/Bit parity
   Device flags   : Present Running
   Interface flags: Point-To-Point SNMP-Traps
   Link flags     : No-Keepalives, DCE
   Input rate     : 35784 bps (1 pps), Output rate: 35792 bps (1 pps)
   Active alarms  : None
   Active defects : None
   Logical interface t3-5/2/0.0 (Index 11) (SNMP ifIndex 42)
     Flags: Point-To-Point SNMP-Traps, DLCI 10, Encapsulation: FR-NLPID
     Input packets: 54 Output packets: 54
     Protocol inet, MTU: 4470
       Addresses, Flags: Is-Preferred Is-Primary
         Destination: 192.168.2.200, Local: 192.168.2.225
     Protocol iso, MTU: 4470
 
   Logical interface t3-5/2/0.1 (Index 12) (SNMP ifIndex 52)
 ...

show interfaces detail (for T3 Interfaces)

Sample Output

 user@host> show interfaces t3-5/2/0 detail 
 Physical interface: t3-5/2/0, Enabled, Physical link is Up
   Interface index: 30, SNMP ifIndex: 41
   Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal
   Speed: T3, Loopback: None, CRC: 16, Mode: C/Bit parity
   Device flags   : Present Running
   Interface flags: Point-To-Point SNMP-Traps
   Link flags     : No-Keepalives, DCE
   Statistics last cleared: Never
   Traffic statistics:
    Input  bytes  :               232855                    0 bps
    Output bytes  :               232914                    0 bps
    Input  packets:                   59                    0 pps
    Output packets:                   59                    0 pps
   Active alarms  : None
   Active defects : None
   Logical interface t3-5/2/0.0 (Index 11) (SNMP ifIndex 42)
     Flags: Point-To-Point SNMP-Traps, DLCI 10, Encapsulation: FR-NLPID
     Traffic statistics:
      Input  bytes  :               233032
      Output bytes  :               233032
      Input  packets:                   59
      Output packets:                   59
     Local statistics:
      Input  bytes  :               233032
      Output bytes  :               233032
      Input  packets:                   59
      Output packets:                   59
     Transit statistics:
      Input  bytes  :                    0                    0 bps
      Output bytes  :                    0                    0 bps
      Input  packets:                    0                    0 pps
      Output packets:                    0                    0 pps
     Protocol inet, MTU: 4470, Flags: None
       Addresses, Flags: Is-Preferred Is-Primary
         Destination: 192.168.2.200, Local: 192.168.2.225, Broadcast:Unspecified
     Protocol iso, MTU: 4470, Flags: None
 
   Logical interface t3-5/2/0.1 (Index 12) (SNMP ifIndex 52)
 ...

show interfaces extensive (for T3 Interfaces)

Sample Output

 user@host> show interfaces t3-5/2/0 extensive 
 Physical interface: t3-5/2/0, Enabled, Physical link is Up
   Interface index: 30, SNMP ifIndex: 41
   Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal
   Speed: T3, Loopback: None, CRC: 16, Mode: C/Bit parity
   Device flags   : Present Running
   Interface flags: Point-To-Point SNMP-Traps
   Link flags     : No-Keepalives, DCE
   Statistics last cleared: Never
   Traffic statistics:
    Input  bytes  :               268676                    0 bps
    Output bytes  :               268744                    0 bps
    Input  packets:                   68                    0 pps
    Output packets:                   68                    0 pps
   Input errors:
     Errors: 0, Drops: 0, Framing errors: 0, Policed discards: 0
     L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0
     SRAM errors: 0, HS link CRC errors: 0
   Output errors:
     Carrier transitions: 1, Errors: 0, Drops: 0, Aged packets: 0
   Active alarms  : None
   Active defects : None
   DS3 Media:            Seconds        Count  State
     PLL Lock                  0            0  OK
     Reframing                 0            0  OK
     AIS                       0            0  OK
     LOF                       0            0  OK
     LOS                       0            0  OK
     IDLE                      0            0  OK
     YELLOW                    0            0  OK
     BPV                       0            0
     EXZ                       0            0
     LCV                       1        65535
     PCV                       0            0
     CCV                       0            0
     LES                       1
     PES                       0
     PSES                      0
     CES                       0
     CSES                      0
     SEFS                      0
     UAS                       0
   HDLC configuration:
     Policing bucket: Enabled, Bit rate:0 %, Threshold:0
     Shaping bucket : Enabled, Bit rate:0 %, Threshold:0
     Giant threshold: 4484, Runt threshold: 3
   DSU configuration:
     Compatibility mode: None, Scrambling: Disabled, Subrate: Disabled
     FEAC loopback: Inactive, Response: Disabled, Count: 0
     BERT time period: 10 seconds, Elapsed: 0 seconds
     Algorithm: 2^3 - 1, Pseudorandom (1), Error rate: 10e-0
   PFE configuration:
     Destination slot: 5, Stream number: 8, PLP byte: 1 (0x00)
     COS transmit queue bandwidth:
       Queue0: 100, Queue1: 0, Queue2: 0, Queue3: 0
     COS weighted round robin:
       Queue0: 100, Queue1: 0, Queue2: 0, Queue3: 0
  Logical interface t3-5/2/0.0 (Index 11) (SNMP ifIndex 42)
     Flags: Point-To-Point SNMP-Traps, DLCI 10, Encapsulation: FR-NLPID
     Traffic statistics:
      Input  bytes  :               268880
      Output bytes  :               268880
      Input  packets:                   68
      Output packets:                   68
     Local statistics:
      Input  bytes  :               268880
      Output bytes  :               268880
      Input  packets:                   68
      Output packets:                   68
     Transit statistics:
      Input  bytes  :                    0                    0 bps
      Output bytes  :                    0                    0 bps
      Input  packets:                    0                    0 pps
      Output packets:                    0                    0 pps
     Protocol inet, MTU: 4470, Flags: None
       Addresses, Flags: Is-Preferred Is-Primary
         Destination: 192.168.2.200, Local: 192.168.2.225, Broadcast:Unspecified
     Protocol iso, MTU: 4470, Flags: None
 
   Logical interface t3-5/2/0.1 (Index 12) (SNMP ifIndex 52)
 ...

Input Errors

The following paragraphs
explain the counters that are not obvious:

    • Errors
      Sum
      of the incoming frame aborts and FCS errors.

    • Policed
      Discards

      Frames that the incoming packet match code
      discarded because they were not recognized or of interest. Usually,
      this field reports protocols that the JUNOS software does not
      handle, such as CDP.

    • L3
      incompletes

      This counter is incremented when the incoming
      packet fails Layer 3 (usually IPv4) sanity checks of the header.
      For example, a frame with less than 20 bytes of available IP header
      would be discarded and this counter would be incremented.

    • L2
      channel errors

      This counter increments when the software
      could not find a valid logical interface (that is, something like
      t3-1/2/3.0) for an incoming frame.

    • L2
      mismatch timeouts

      Count of malformed or short packets that
      cause the incoming packet handler to discard the frame as
      unreadable.

    • SRAM
      errors

      The counter increments when a hardware error has
      occurred in the SRAM on the PIC. The value in this field should
      always be 0. If it increments, the PIC is broken.

    • HS
      link CRC errors

      Count of errors on the high-speed links
      between the ASICs responsible for handling the router interfaces.

Output Errors

    • Carrier transitions
      Number of times the interface has gone from down to up. This number should not increment quickly, increasing, for example, only when the cable is unplugged or the far end system is powered down and up. If it does increment quickly (perhaps, 1 every 10 seconds), then something is broken check the cable, the far end system, or the PIC.

    • Errors
      Sum of the outgoing frame aborts and FCS errors.

    • Drops
      Number of packets dropped by the output queue of the I/O Manager ASIC. If the interface is saturated, this number increment once for every packet that is dropped by the ASIC’s RED mechanism.

    • Aged packets
      Number of packets that remained in shared packet SDRAM for so long that the system automatically purged them. The value in this field should never increment. If it does, it is most likely a software bug or possible broken hardware.

Output Field Definitions

Active alarms and Active defects T3 media-specific defects that can render the interface unable to pass packets. When a defect persists for a certain amount of time, it is promoted to an alarm. Based on the router configuration, an alarm can ring the red or yellow alarm bell on the router, or the red or yellow alarm LED on the craft interface.

Addresses

Addresses
associated with the logical interface.

Broadcast The IP address for the broadcast of this interface.

Clocking

Reference clock
source.

CRC

Frame checksum on
the interface (either 16 or 32).

Destination

IP address of the
remote side of the connection.

Device Flags

Specific
information about the physical device. Possible values are
described in Device Flags Field.

DLCI

If Frame Relay
encapsulation is configured, the DLCI number of the logical
interface.

DS3 media

Counts of T3
media-specific errors.

DSU
configuration

Information about
the DSU configuration. The last three lines (Bit count, Error bit
count, and LOS information) are displayed only if a BERT test has
ever been run on the interface.

Enabled

State of the
interface. Possible values are described in Enabled Field.

Encapsulation

Encapsulation on
the logical interface.

HDLC
configuration

Information about
the HDLC configuration.

Input rate,
Output rate

The rate of bits
and packets received and transmitted on the interface.

Interface
Flags

Specific
information about the interface. Possible values are described in
Interface Flags Field.

Interface
index

Physical
interface’s index number, which reflects its initialization
sequence.

Link flags

Specific
information about the links.

Link level
type

Encapsulation
being used on the physical interface.

Local

IP address of the
logical interface.

Local
statistics

Statistics for
traffic received from and transmitted to the Routing Engine. When
a burst of traffic is received, the value in the output packet
rate field might briefly exceed the peak cell rate. It takes a
while (generally, less than 1 second) for this counter to
stabilize.

Logical
interface, Index, SNMP ifIndex

Name of the
logical interface, the logical interface’s index number (which
reflects its initialization sequence), and the logical interface’s
SNMP interface index number.

Loopback

Whether loopback
is enabled and the type of loopback (local or remote).

Mode

Indicates whether
or not C-bit parity mode is enabled.

MTU

MTU size on the
physical interface.

PFE
configuration

Information about
how the Packet Forwarding Engine is configured.

Physical
Interface

Name of the
physical interface.

Protocol

Protocol running
on the logical interface.

SNMP ifIndex

SNMP index number
for the interface.

Speed

Speed at which
the interface is running.

Statistics
Last Cleared

Time when the
statistics for the interface were last zeroed.

Traffic
Statistics

Number and rate
of bytes and packets received and transmitted on the physical
interface.

Transit statistics

Statistics for traffic transiting the router. When a burst of traffic is received, the value in the output packet rate field might briefly exceed the peak cell rate. It takes a while (generally, less than 1 second) for this counter to stabilize.

  • Ошибки на порту cisco outdiscards
  • Ошибки на приборке на бмв е39
  • Ошибки на поло седан на панели приборов фольксваген
  • Ошибки на приборке мерседес спринтер
  • Ошибки на приборке мазда 3