Многопротокольная коммутация по меткам (MPLS) : MPLS

Команда traceroute в MLPS

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ объясняет работу команды traceroute в среде многопротокольной коммутации по меткам (MPLS).

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Основные сведения MPLS

Обратитесь к часто задаваемым вопросам MPLS Для Новичков для получения дополнительной информации.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Обычная Команда traceroute

В данном разделе описывается порядок работы стандартной команды traceroute. Эта схема показывает настройку поставщика услуг, где Маршрутизатор 1 (R1) и Маршрутизатор 4 (R4) являются маршрутизаторами Границы провайдера (PE), и Маршрутизатор 2 (R2) и Маршрутизатор 3 (R3) являются Поставщиком (P) маршрутизаторы.

/image/gif/paws/26585/mpls_traceroute1.gif

В этом примере проведена трассировка из R1 к возвратной петле 14 R4. R1 использует дейтаграмму Протокола UDP с произвольным значением порта назначения, больше, чем 32000. При выборе такого максимального значения для номера порта оно гарантирует, что такой порт не существует на целевом получателе. Это помещает эту дейтаграмму в пакет IP.

Примечание: В этом документе под IP-пакетом понимается IP-пакет, содержащий дейтаграмму UDP.

Это - последовательность событий для обычной команды traceroute:

  1. R1 передает пакет IP с адресом назначения (DA) 14 и Временем жизни (TTL) 1 через его интерфейс eth1.

  2. R2 получает пакет и обращает внимание, что это не целевой получатель, и TTL пакета равняется 1. Это отбрасывает пакет и передает сообщение Протокола ICMP срока действия TTL истек к R1. Адрес источника данного сообщения ICMP – это IP-адрес R2 eth0 (адрес интерфейса, получившего исходный пакет).

  3. По получении сообщения ICMP R1 передает другой пакет IP, предназначенный для 14 с TTL 2 через его интерфейс eth1.

  4. R2 получает пакет и обращает внимание, что это не целевой получатель, и целевой получатель может быть достигнут через R3. Это постепенно уменьшает TTL (от 2 до 1) и передает пакет к R3. R3 получает пакет и видит, что это не целевой получатель. TTL равняется 1. Это отбрасывает пакет и передает сообщение ICMP срока действия TTL истек к R1 с его адресом eth0 как адрес источника.

  5. R1 получает сообщение ICMP и передает другой пакет IP к 14 через его интерфейс eth1 со значением TTL 3. На пути R2 и R3 постепенно уменьшают TTL и передают его на R4. R4 получает пакет, обнаруживает, что является целевым получателем, и пытается подключиться к значению порта в датаграмме UPD. R4 находит, что этот порт не существует и передает ICMP сообщение об ошибках port unreachable к R1.

    Как прежде, адрес источника этого сообщения ICMP является eth0 R4. Программа трассировки теперь имеет все сообщения об ошибках ICMP с соответствующими адресами источника и имеет завершенный маршрут назначению.

Команда traceroute MPLS

Считайте этот тот же сценарий детализированным в Обычном Разделе команд traceroute, кроме всех маршрутизаторов, R1 через R4, теперь сделайте коммутацию по меткам вместо IP - переадресации. Настройку испытательного стенда показывают, эта схема. Все интерфейсы, показанные в испытательном стенде, находятся в 10.13.0.0 сетях.

mpls_traceroute2.gif

В целях этого документа предположите что:

  • R1 использует метку 47 для достижения R4 и передает пакеты к R2.

  • R2 использует метку 45 для достижения R4 и передает пакеты к R3.

  • R3 отображает метку и пересылает пакет R4.

  • R4 использует метку 28 для достижения R1 и передает пакеты R3.

  • R3 использует метку 26 для достижения R1 и передает пакеты к R2.

  • R2 сует метку и передает пакет к R1.

Эти шаги показывают последовательность событий для проведения traceroute от R1 до R4 loopback 10.13.1.51.

  1. R1 посылает пакет для коммутации меток с меткой 47 и TTL от 1 до R2. Поле TTL IP-пакета скопировано в поле TTL заголовка метки.

  2. R2 видит, что это не целевой получатель, и TTL равняется 1. Это отбрасывает пакет и создает сообщение ICMP срока действия TTL истек, как это было бы для обычного пакета IP. В этом случае пакет сообщений ICMP генерируется на расширения ICMP для MPLS.

  3. R2 добавляет метку 47 (входящая метка, которая истекла) к сообщению ICMP. Это не передает пакет к R1 непосредственно. Вместо этого это консультируется со своим Обозначением базы данных переадресации (LFIB) и находит, что должно использовать метку 45 для пакетов, полученных с меткой 47. Это помещает метку 45 на пакете и передает сообщение ICMP срока действия TTL истек к R3.

  4. R3 отбрасывает метку и отправляет ее на R4. R4 устанавливает, что местом назначения является R1, присваивает сообщению метку 28 и отправляет его в R1 через R3 и R2.

  5. Сообщение ошибки ICMP проходит по всему пути до другого и перед передачей возвращается к R1. Рисунок к этому примеру:

    /image/gif/paws/26585/mpls_traceroute3.gif

    Сниффинговые пакеты на Интерфейсе Ethernet в R4 подтверждают Шаги 1-5. В выходных данных анализатора Frame 1 является входящим пакетом, и Frame 2 является исходящим пакетом от R4. Формат вывода соответствует теме данного обсуждения, а важные пункты помечены жирным шрифтом.

    Frame 1 (182 on wire, 182 captured)
    Ethernet II 
    Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00)
    Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84)
    Type: IP (0x0800)
    Internet Protocol 
    Version: 4 
    Header length: 20 bytes 
    Time to live: 254 
    Protocol: ICMP (0x01) 
    Header checksum: 0x1b8e (correct)
    Source: 10.13.2.33 (10.13.2.33)
    Destination: 10.13.2.34 (10.13.2.34) 
    Internet Control Message Protocol
    Type: 11 (Time-to-live exceeded) 
    Code: 0 (TTL equals 0 during transit)
    Checksum: 0x0c88 (correct) 
    Data (140 bytes) 
    04500 001c 9e19 0000 0111 044a 0a0d 0222E..........J..."
    100a0d 0133 989d 829a 0008 cd37 0000 0000...3.......7....  
    200000 0000 0000 0000 0000 0000 0000 0000................  
    300000 0000 0000 0000 0000 0000 0000 0000................ 
    400000 0000 0000 0000 0000 0000 0000 0000................ 
    500000 0000 0000 0000 0000 0000 0000 0000................
    600000 0000 0000 0000 0000 0000 0000 0000................ 
    700000 0000 0000 0000 0000 0000 0000 0000................ 
    802000 edf2 0008 0101 0002 f101........... 
    
    Frame 2 (186 on wire, 186 captured) 
    Ethernet II 
    Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84)
    Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00) 
    Type: MPLS label switched packet (0x8847)
    MultiProtocol Label Switching Header 
    MPLS Label: Unknown (28) 
    MPLS Experimental Bits: 6 
    MPLS Bottom Of Label Stack: 1 
    MPLS TTL: 253 
    Internet Protocol 
    Version: 4 
    Header length: 20 bytes 
    Time to live: 253 
    Protocol: ICMP (0x01)
    Header checksum: 0x1c8e (correct)
    Source: 10.13.2.33 (10.13.2.33) 
    Destination: 10.13.2.34 (10.13.2.34) 
    Internet Control Message Protocol 
    Type: 11 (Time-to-live exceeded) 
    Code: 0 (TTL equals 0 during transit)
    Checksum: 0x0c88 (correct) 
    Data (140 bytes) 
    04500 001c 9e19 0000 0111 044a 0a0d 0222E..........J..." 
    100a0d 0133 989d 829a 0008 cd37 0000 0000...3.......7.... 
    200000 0000 0000 0000 0000 0000 0000 0000................ 
    300000 0000 0000 0000 0000 0000 0000 0000................ 
    400000 0000 0000 0000 0000 0000 0000 0000................ 
    500000 0000 0000 0000 0000 0000 0000 0000................ 
    600000 0000 0000 0000 0000 0000 0000 0000................ 
    700000 0000 0000 0000 0000 0000 0000 0000................ 
    802000 edf2 0008 0101 0002 f101........... 
    

    В Frame 1 выходных данных первый пакет, полученный R4, является сообщением ICMP срока действия TTL истек от R2 (10.13.2.33, интерфейс, на котором оригинальный пакет был получен) к R1 (10.13.2.34). В блоке данных сообщения ICMP, в байтах 0x89 и первое откусывание 0x8A, истекается MPLS label (20 байтов), и его значение является 0x02F, или 47. Это - входящая метка пакета с TTL 1. R2 добавляет эту метку в сообщении об ошибках ICMP.

    В Frame 2 выходных данных type показывают как MPLS label switched packet, что означает, что это - пакет MPLS. R4 помещает метку 28 для Формирования кадров 1 и вперед это к R1 через путь коммутации меток. Заголовок MPLS в кадре полужирным. Кроме того, если вы обращаетесь к части TTL пакета в Кадре, 1 его значение 254, и в Кадре 2 это 253. R4 постепенно уменьшил его 1.

  6. R1 получает сообщение ICMP и передает другой пакет с меткой 47 и TTL 2 к R2. R2 заменяет метки, уменьшает значение TTL (с 2 до 1) и пересылает к R3. Как в Шаге 2, R3 передает сообщение ICMP срока действия TTL истек, добавленное с входящей меткой, которая истекла к R4, и R4 тогда передает его обратно R1.

    Выходные данные анализатора в R4, показанном здесь, подтверждают Шаг 6:

    Frame 3 (182 on wire, 182 captured)
    Ethernet II 
    Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00) 
    Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84) 
    Type: IP (0x0800) 
    Internet Protocol 
    Version: 4 
    Header length: 20 bytes 
    Time to live: 255 
    Protocol: ICMP (0x01) 
    Header checksum: 0x146f (correct) 
    Source: 10.13.3.134 (10.13.3.134) 
    Destination: 10.13.2.34 (10.13.2.34) 
    Internet Control Message Protocol 
    Type: 11 (Time-to-live exceeded) 
    Code: 0 (TTL equals 0 during transit)
    Checksum: 0x0c88 (correct) 
    Data (140 bytes) 
    04500 001c 9e1b 0000 0211 0348 0a0d 0222E..........H..."  
    100a0d 0133 9292 829b 0008 d341 0000 0000...3.......A.... 
    200000 0000 0000 0000 0000 0000 0000 0000................ 
    300000 0000 0000 0000 0000 0000 0000 0000................ 
    400000 0000 0000 0000 0000 0000 0000 0000................ 
    500000 0000 0000 0000 0000 0000 0000 0000................ 
    600000 0000 0000 0000 0000 0000 0000 0000................ 
    700000 0000 0000 0000 0000 0000 0000 0000................
    802000 0df3 0008 0101 0002 d101........... 
    
    Frame 4 (186 on wire, 186 captured) 
    Ethernet II 
    Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84) 
    Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00) 
    Type: MPLS label switched packet (0x8847) 
    MultiProtocol Label Switching Header 
    MPLS Label: Unknown (28) 
    MPLS Experimental Bits: 6 
    MPLS Bottom Of Label Stack: 1 
    MPLS TTL: 254 
    Internet Protocol 
    Version: 4 
    Header length: 20 bytes 
    Time to live: 254 
    Protocol: ICMP (0x01) 
    Header checksum: 0x156f (correct) 
    Source: 10.13.3.134 (10.13.3.134) 
    Destination: 10.13.2.34 (10.13.2.34) 
    Internet Control Message Protocol 
    Type: 11 (Time-to-live exceeded) 
    Code: 0 (TTL equals 0 during transit) 
    Checksum: 0x0c88 (correct) 
    Data (140 bytes) 
    04500 001c 9e1b 0000 0211 0348 0a0d 0222E..........H..."
    100a0d 0133 9292 829b 0008 d341 0000 0000...3.......A....  
    200000 0000 0000 0000 0000 0000 0000 0000................ 
    300000 0000 0000 0000 0000 0000 0000 0000................ 
    400000 0000 0000 0000 0000 0000 0000 0000................  
    500000 0000 0000 0000 0000 0000 0000 0000................ 
    600000 0000 0000 0000 0000 0000 0000 0000................ 
    700000 0000 0000 0000 0000 0000 0000 0000................ 
    802000 0df3 0008 0101 0002 d101........... 
    

    От выходных данных Frame 3 можно решить, что Кадр 3 является пакетом ICMP от R3 до R1. Адрес источника (10.13.3.134) является адресом, на котором получен оригинальный пакет. Сообщение об ошибках ICMP содержит устаревшие сведения о метке в конце блока данных. Его значение является 0x02d, который равняется 45. Frame 4 является пакетом MPLS, который передается от R4 до R1.

  7. По получении сообщения ICMP R1 передает другой пакет с меткой 47 и TTL 3. Продвигающийся, R2 и R3 постепенно уменьшают TTL и передают пакет к R4. R4 определяет, что он является назначенным получателем, и обнаруживает, что порт датаграмм UDP недостижим. Это передает ICMP сообщение port unreachable к R1 через R3 и R2.

    В этих выходных данных анализатора важные моменты, на которые обратят внимание, находятся в полужирном шрифте:

    Frame 5 (60 on wire, 60 captured)
    Ethernet II 
    Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00)
    Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84) 
    Type: IP (0x0800) 
    Trailer: 00000000000000000000000000000000... 
    Internet Protocol 
    Version: 4 
    Header length: 20 bytes 
    Time to live: 1 
    Protocol: UDP (0x11) 
    Header checksum: 0x0446 (correct) 
    Source: 10.13.2.34 (10.13.2.34)
    Destination: 10.13.1.51 (10.13.1.51) 
    User Datagram Protocol 
    Source port: 37647 (37647) 
    Destination port: 33436 (33436) 
    Length: 8 
    Checksum: 0xd2c3 (correct) 
    
    Frame 6 (74 on wire, 74 captured) 
    Ethernet II 
    Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84) 
    Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00)
    Type: MPLS label switched packet (0x8847) 
    MultiProtocol Label Switching Header 
    MPLS Label: Unknown (28) 
    MPLS Experimental Bits: 6 
    MPLS Bottom Of Label Stack: 1 
    MPLS TTL: 255 
    Internet Protocol 
    Version: 4 
    Header length: 20 bytes 
    Time to live: 255 
    Protocol: ICMP (0x01) 
    Header checksum: 0x5694 (correct) 
    Source: 10.13.5.10 (10.13.5.10) 
    Destination: 10.13.2.34 (10.13.2.34) 
    Internet Control Message Protocol 
    Type: 3 (Destination unreachable) 
    Code: 3 (Port unreachable) 
    Checksum: 0x1485 (correct)
    Data (28 bytes) 
    04500 001c 9e1d 0000 0111 0446 0a0d 0222E..........F..." 
    100a0d 0133 930f 829c 0008 d2c3...3........ 
    

    Frame 5 показывает, что дейтаграмма UDP передается R1 R4. Значение порта назначения в дейтаграмме UDP 33436 (больше, чем 32000), как обсуждено в Обычном Разделе команд traceroute.

    В Frame 6 R4 передает тип ICMP destination unreachable и код port unreachable к R1. Всем более ранним сообщениям ICMP от R2 и R3 установили поле типа как time-to-live exceeded. Выход расширенной команды traceroute приведен ниже:

    R1#traceroute 
    Protocol [ip]:  
    Target IP address: 10.13.1.51 
    Source address: 10.13.2.34 
    Numeric display [n]:  
    Timeout in seconds [3]:
    Probe count [3]: 1 
    Minimum Time to Live [1]:
    Maximum Time to Live [30]:
    Port Number [33434]:  
    Loose, Strict, Record, Timestamp, Verbose[none]:
    Type escape sequence to abort. 
    Tracing the route to 10.13.1.51
    1 10.13.2.33 [MPLS: Label 47 Exp 0] 0 msec 
    2 10.13.3.134 [MPLS: Label 45 Exp 0] 0 msec
    3 10.13.5.10 4 msec 
    R1# 
    

    По умолчанию команда traceroute использует три зонда для каждого значения TTL. Это передает три пакета с TTL 1, три пакета с TTL 2, и т.д. Эта команда traceroute выполнена с одиночным зондом, таким образом, просто отследить и отладить. Как замечено в выходных данных, команда traceroute показывает значение метки с истекшим сроком, также.

команда no mpls ip propagate-ttl

Когда пакет IP передан в домен MPLS, при настройке MPLS метка наложена маршрутизатором с коммутацией меток (LSR). На этой метке в поле TTL должно стоять значение. По умолчанию LSR читает поле TTL в IP - заголовке входящего пакета, постепенно уменьшает его 1 и копирует то, что оставляют в поле TTL заголовка MPLS. Базовые LSR только посмотрели на верхнюю метку. Если значение TTL не достигает 0, пакет передан. Выходной оконечный LSR, который извлекает из стека метку, копирует то, что осталось в TTL-поле метки, в TTL-поле IP-заголовка, а затем переадресует IP-пакет за пределы домена MPLS.

Это поведение не может быть изменено ни с какой командой настройки mpls ip propagate-ttl. Входной маршрутизатор LSR использует 255 в качестве значения TTL при назначении метки. Исходящий граничный маршрутизатор LSR не выполняет копирование значения метки TTL в заголовок IP при пересылке метки. Фактический результат - то, что TTL IP - заголовка не отражает переходы, взятые по ядру MPLS; поэтому, когда клиенты выполняют traceroute с одной стороны их сети другой стороне, маршрутизаторы в базовой сети MPLS не появляются в данных трассировки. Важно отключить TTL - распространение и во входе и в выходных маршрутизаторах Edge с коммутацией по меткам. В противном случае IP - заголовок может иметь более высокое значение, когда он оставляет домен MPLS, чем он имел, когда он ввел его.

Это можно пояснить на примере:

mpls_traceroute4.gif

C1 выполняет traceroute к C2. С операцией TTL - распространения IP по-умолчанию traceroute в C1 похож на это:

C1#traceroute C2.cust.com

Tracing the route to C2.cust.com
  1 A.provider.net       44 msec  36 msec  32 msec
  2 B provider.net      164 msec  132 msec  128 msec
  3 C.provider.net	148 msec  156 msec  152 msec
  4 C2.cust.com         180 msec  *  181 msec

Данный результат иллюстрирует типичное поведение трассировки в сети MPLS. Поскольку заголовок метки помеченного пакета переносит значение TTL от исходного пакета IP, маршрутов в маршрутах на пути отбрасывают пакеты, для которых превышен TTL. Поэтому команда traceroute показывает все маршрутизаторы в пути. Поведение - это:

  1. Первый пакет является пакетом IP с TTL, равным 1. Маршрутизатор декременты TTL и отбрасывания пакет, потому что это достигает 0. ICMP превышенное TTL сообщение передается источнику.

  2. Второй посланный пакет – IP-пакет с TTL = 2. Маршрутизатор A уменьшает TTL, помечает пакет, и пересылает его на маршрутизатор B.

  3. Маршрутизатор B уменьшает значение TTL в заголовке MPLS, отбрасывает пакет и отправляет ICMP сообщение о превышении TTL к источнику. Поскольку это был пакет MPLS, который был утерян, адрес возврата для сообщения ICMP должен быть получен из исходного адреса в заголовке IP внутри пакета MPLS. Но тот IP-адрес фактически не может быть известен Маршрутизатору B, таким образом, Маршрутизатор B вперед сообщения ICMP вдоль того же пути коммутации меток (LSP), что отброшенный пакет перемещался (в направлении к маршрутизатору C). В конце LSP удалена метка, и сообщения ICMP переданы согласно адресу назначения (DA) в IP - заголовке (к Маршрутизатору C1).

  4. Для третьего пакета (TTL 3) выполняется такая же обработка, как и для предыдущих, за исключением того, что теперь маршрутизатор С отбрасывает пакет, основываясь на TTL заголовка IP. Маршрутизатор B, по причине вытеснения предпоследней пересылки, ранее удалил метку, а TTL был скопирован в IP-заголовок.

  5. Четвертый пакет (TTL 4) достигает адреса назначения, где проверяется TTL заголовка IP.

Если распространение IP TTL не отключено ни с какой командой mpls ip propagate-ttl в режиме глобальной конфигурации, значение TTL не скопировано в IP - заголовке, и traceroute в C1 к C2 похож на это:

C1#traceroute C2.cust.com

Tracing the route to C2.cust.com
  1 A.provider.net   44 msec  36 msec  32 msec
  2 C2.cust.com     180 msec  *  181 msec

Когда команда traceroute используется в этой ситуации, Ответы ICMP только получены от тех маршрутизаторов, которые видят реальный TTL, сохраненный в IP - заголовке. В этой ситуации Маршрутизатор C1 выполняет команду traceroute (как показано), но центральные маршрутизаторы не копируют TTL к и от метки. Это приводит к этому поведению:

  1. Первый пакет является пакетом IP с TTL, равным 1. Маршрутизатор декременты TTL, отбрасывает пакет и передает ICMP превышенное TTL сообщение к источнику.

  2. Второй пакет является пакетом IP с TTL, равным 2. Маршрутизатор декременты TTL, маркирует пакет и устанавливает TTL в заголовке MPLS к 255.

  3. Маршрутизатор B decremetns theTTL в заголовке MPLS к 254, удаляет MPLS label и копирует значение TTL в заголовке MPLS в поле TTL IP - заголовка.

  4. C маршрутизатора постепенно уменьшает IP TTL и передает пакет к маршрутизатору следующего перехода C2. Пакет достиг точки назначения.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 26585