Traceroute лжет! Типичная неверная интерпретация результата.

Иногда пользователи с проблемами доступности определенных узлов, с гордостью предоставляют мне результаты трассировки маршрута (traceroute) и указывают на определенный узел, обвиняя его в высокой задержке соединения. В одном случае из тысячи это действительно так. Однако в остальных 999... Пожалуйста, позвольте мне объяснить.

Вывод traceroute
Перед вами типичный вывод traceroute, который может быть отправлен пользователем (IP и имена хостов изменены, чтобы не подвергать опасности непричастных):

$ traceroute www-europe
traceroute to www-europe (18.9.4.17), 64 hops max, 52 byte packets
 1  gateway (57.239.196.133)          11.447 ms   18.371ms    25.057 ms
 2  us-atl-edge (137.16.151.202)      13.338 ms   20.070 ms   19.119 ms
 3  us-ga-core (57.239.129.37)       103.789 ms  105.998 ms  103.696 ms
 4  us-nyc-core (57.239.128.189)     107.601 ms  103.116 ms  103.934 ms
 5  us-east-core (57.239.13.42)      103.099 ms  104.215 ms  109.042 ms
 6  us-east-bb1 (57.239.111.58)      107.824 ms  104.463 ms  103.482 ms
 7  uk-south-bb1 (57.240.117.81)     106.439 ms  111.156 ms  104.761 ms
 8  uk-south-core (57.240.117.61)    103.408 ms  104.430 ms  103.277 ms
 9  uk-london-core (57.240.132.178)  131.883 ms  104.071 ms  104.161 ms
10  uk-london-edge (99.88.4.133)     104.642 ms  105.685 ms  106.011 ms
11  www-europe (18.9.4.17)           103.465 ms  103.630 ms  104.228 ms

Смотрите! Пользователь негодует, причина явно между узлами us-alt-edge и us-ga-core (узлы #2 и #3), потому что задержка между ними возрастает с 20 мс до 105 мс!

Нет, это не так.

Разве не странно, между двумя узлами находящимися в региональной близости задержка увеличивается на 90 мс, а между узлами 6 и 7 разделенными океаном(зачастую исходя из названия узлов можно судить о их региональной принадлежности) задержка практически не увеличивается? На самом деле, разве не странно, что задержка после третьего узла примерно одинаковая?

Я знаю, многие читатели уже поняли почему так получается, но для тех, кто не понял(и в этом нет ничего позорного): такие результаты трассировки говорят о том, что на пути маршрута встречается MPLS сеть, а MPLS Provider edge (PE) является маршрутизатор на втором узле.

Почему так?
Помните, что одно из преимуществ MPLS сети в том, что ядро MPLS сети (PE или P узел) ничего не должно знать о конечных точках маршрута. Есть всего две вещи о которых должны знать P узлы MPLS сети:
1. Где все остальные узлы MPLS сети (обычно для этого используют OSPF или IS-IS протоколы маршрутизации)
2. Куда пересылать входящие фреймы MPLS на основании указанных меток.
Обычно это довольного "глупое" активное оборудование, но это позволяет им гораздо быстрее передавать трафик, нежели роутерам с IP маршрутизацией. Так в чем же проблема?

В своей работе traceroute полагается на отправленные пакеты с включенным TTL; когда TTL истекает, обычно устройство на котором он истек отправляет ICMP-сообщение источнику, предупреждая, что TTL истек в пути, именно так traceroute узнает о каждом узле в пути маршрута. Посмотрев на иллюстрацию MPLS сети предоставленную выше, что происходит когда TTL истекает на Р-маршрутизаторе? Р-маршрутизаторы ничего не знают о пограничных сетях(за пределами MPLS сети), поэтому никак не сможет направить ICMP-сообщение обратно к источнику, о котором не знает. Метки MPLS несут в себе информацию только об одном направлении(к месту назначения), поэтому P-маршрутизатор делает единственное, что может: добавляет к исходящей метке, которую собирается использовать и создает новый MPLS фрейм содержащий ICMP TTL Exiped и этот фрейм полностью(без именений в TTL) передается на PE-маршрутизатор (в указанном примере это PE-B).
PE-B получает фрейм, просматривает ICMP-сообщение внутри него и просматривает адрес получателя, т.е. моего компьютера(адрес машины на которой запущен traceroute). Как полагается PE-маршрутизатору, он знает, как добраться до моего компьютера(т.е. какой ярлык использовать для отправки пакета в сеть MPLS), упаковывает ICMP-пакет внутри MPLS и отправляет его обратно.
Другими словами, любые сообщения ICMP TTL Expired, сгенерированные в сети MPLS, фактически проходят все узлы MPLS сети, а затем назад, без изменений. В указанном примере они одинаково большие, потому что приходится пройти из США в Великобританию, а затем из Великобритании в США, чтобы вернуться на мой компьютер.

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

Замечание: не все MPLS-сети будут передавать TTL входящего пакета в MPLS фрейм, поэтому TTL не всегда истекает в глубине MPLS сети. В таком случае, MPLS сеть может выглядеть как один скачок (hop) ICMP-пакета, поэтому не всегда будет понятен путь прохождения запроса внутри MPLS сети.

Перевод статьи: http://movingpackets.net/2017/10/06/misinterpreting-traceroute

JunOS — полезные команды

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

https://t.me/shell_podcast

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 OSPF конфигурация GNS3.

Введение.

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

Инструменты.

Debian 3.16.36-1+deb8u2

GNS3 v. 0.8.7

c7200-adventerprisek9-mz.152-4.S3.image

GNS3 project OSPF routing

Juniper.img

Схема сети.

Конфигурация.

Для начала сохраняем конфигурацию на всех роутерах задействованных в коммерческой сети. Приступаем к настройке Junos3 роутера, пока не подключая его к RoA и RoC.

root
cli
configure
set system host-name RouterB
exit
edit interface em2 unit 0 family inet address 10.1.1.1/30
exit
edit interface em1 unit 0 family inet address 10.1.1.5/30
exit

edit protocols ospf area 0.0.0.0 interface em2
exit
edit protocols ospf area 0.0.0.0 interface em1
exit
commit check
commit

Конфигурация роутеров A и C не изменилась, ее можно посмотреть здесь.

Разрываем связи роутеров RouterA и RouterC с RouterB и подключаем на его место наш новый маршрутизатор juniper(см. схему выше). Сеть полностью сохраняет свою топологию и логику.

Так же можно снять дамп с любого интерфейса участвующего в ospf и убедиться, что между интерфейсами ходят hello пакеты в протоколе OSPF:

OSPF v2, hello interval 10 sec: