Иногда пользователи с проблемами доступности определенных узлов, с гордостью предоставляют мне результаты трассировки маршрута (traceroute) и указывают на определенный узел, обвиняя его в высокой задержке соединения. В одном случае из тысячи это действительно так. Однако в остальных 999... Пожалуйста, позвольте мне объяснить.
Вывод traceroute
Перед вами типичный вывод traceroute, который может быть отправлен пользователем (IP и имена хостов изменены, чтобы не подвергать опасности непричастных):
Смотрите! Пользователь негодует, причина явно между узлами 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
Перед вами типичный вывод 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 маршрутизацией. Так в чем же проблема?
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
Комментариев нет:
Отправить комментарий