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

Общие сведения о наложении меток Многопротокольной коммутации по меткам (MPLS) в среде ATM

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


Содержание


Введение

Этот документ описывает путь, используемый пакетом IP, когда это перемещается через Ядро ATM с включением MPLS и описывает главные команды показа.

Примечание: Маршрутизаторы в этом документе от серий Cisco 3600, которые выполняют Cisco Версия 12.0 (7) T IOS� и используют интерфейсы OC-3. LSR ATM 8540MSR.

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

Требования

Для этого документа отсутствуют особые требования.

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

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

Схема сети

Сценарии в этом документе основываются на этой настройке. Для просмотра конфигураций для этих устройств обратитесь к этому примеру конфигурации.

/image/gif/paws/10477/MPLSoATM-1.gif

Команды "show"

Guilder

Guilder является представляющим интересом маршрутизатор в этой настройке, так как это налагает метки к пакетам IP, которые прибывают из Стороны Ethernet. Так как мы работаем на ATM-интерфейс, который связан с Ядром ATM с включением MPLS, наложенная метка означает переданный пакет IP на Tag VC (TVC).

В этом сценарии Pound передает пакеты IP к Lira. Например, если вы пропинговываете 125.125.0.2 от Pound, он работает как ожидалось:

Pound#ping 125.125.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 125.125.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

От таблицы маршрутизации Guilder мы можем легко видеть, что назначение может быть достигнуто через облако ATM:

Guilder#show ip route 125.125.0.2
Routing entry for 125.125.0.0/16
  Known via "ospf 1", distance 110, metric 12, type inter area
  Redistributing via ospf 1
  Last update from 129.129.0.2 on ATM1/0.1, 01:15:26 ago
  Routing Descriptor Blocks:
  * 129.129.0.2, from 120.120.0.1, 01:15:26 ago, via ATM1/0.1
      Route metric is 12, traffic share count is 1

Мы настроили подчиненного интерфейс ATM 1/0.1 для маркировки исходящих пакетов IP, таким образом, мы можем получить больше подробных данных через таблицу пересылки Метки:

Guilder#show tag-switching forwarding-table 125.125.0.2 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
30     2/36        125.125.0.0/16    0          AT1/0.1    point2point
        MAC/Encaps=4/8, MTU=4470, Tag Stack{2/36(vcd=299)}
        012B0900 0012B000

Мы видим теперь, когда Guilder налагает исходящий TVC VPI 2, VCI 36, который соответствует VCD 299. Эта информация сохранена в таблице пересылки CEF:

Guilder#show ip cef 125.125.0.2 detail
125.125.0.0/16, version 143, cached adjacency to ATM1/0.1
0 packets, 0 bytes
  tag information set
    local tag: 30
    fast tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}
  via 129.129.0.2, ATM1/0.1, 0 dependencies
    next hop 129.129.0.2, ATM1/0.1
    valid cached adjacency
    tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}

Пакеты IP действительно переданы на правильном VC:

Guilder#show atm vc 299
ATM1/0.1: VCD: 299, VPI: 2, VCI: 36
UBR, PeakRate: 155000
AAL5-MUX, etype:0x8847, Flags: 0x40C84, VCmode: 0x0
OAM frequency: 0 second(s)
InARP DISABLED
Transmit priority 0
InPkts: 0, OutPkts: 5, InBytes: 0, OutBytes: 540
InPRoc: 0, OutPRoc: 0
InFast: 0, OutFast: 5, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 
0OAM cells received: 
0OAM cells sent: 0
Status: UP
Tag VC: local tag: 0

Как вы видите, только пять пакетов IP были переданы. Это синхронизируется с простой проверкой связи с помощью команды ping, которую мы инициировали. В то же время можно задаться вопросом, почему мы не видим пять входящих пакетов. Другими словами, почему исходящее и входящие пути являются другими? Это обычно, так как существует один VC на запись маршрута (на префикс), и, в результате TVC однонаправлены.

Capri

Удивительно, нет очень, мы можем добраться от коммутатора, когда все маршруты/VC стабильны; это просто переключает ячейки ATM. Рассмотрим следующий пример:

Capri#show tag atm-tdp bindings 125.125.0.0 16
 Destination: 125.125.0.0/16
    Transit ATM3/0/3 2/36 Active -> ATM3/0/0 2/38 Active

Нужно указать на некоторые подробные данные. Исследуйте эти выходные данные:

Capri#show atm vc conn-type tvc int atm 3/0/3
Interface         VPI  VCI   Type   X-Interface      X-VPI X-VCI Encap  Status 
ATM3/0/3          2    33    TVC(I) ATM3/0/0          2    36           UP
ATM3/0/3          2    33    TVC(O) ATM3/0/0          2    53           UP
ATM3/0/3          2    34    TVC(I) ATM0              0    317   MUX    UP
ATM3/0/3          2    34    TVC(O) ATM3/0/0          2    54           UP
ATM3/0/3          2    35    TVC(I) ATM3/0/0          2    37           UP
ATM3/0/3          2    35    TVC(O) ATM3/0/0          2    55           UP
ATM3/0/3          2    36    TVC(I) ATM3/0/0          2    38           UP
ATM3/0/3          2    37    TVC(I) ATM0              0    318   MUX    UP

Поскольку мы видим, некоторый конец TVC на интерфейсном ATM0. На 8540MSR, интерфейсный ATM0 соответствует ЦПУ. Те TVC соответствуют IP-адресам, локальным для 8540MSR, таким как локальная возвратная петля.

Мы знаем, что Guilder передает пакеты IP с назначением 125.125.0.2 на TVC 2/36. На стороне LSR этот TVC является входящим (I) TVC только.

Damme

Для достижения 125.125.0.2, мы ожидаем, что пакеты IP будут переданы Интерфейсу Fast Ethernet 0/0 в соответствии со схемой сети. Мы знаем, что не настроили Коммутацию по меткам на этом Интерфейсе Fast Ethernet. Это - результат:

damme#show tag-switching forwarding-table 125.125.0.2 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface
damme#

В результате нет никакой метки для добавления. Только информация таблицы маршрутизации используется:

damme#show ip route 125.125.0.2
 Routing entry for 125.125.0.0/16
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 1
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/0
      Route metric is 0, traffic share count is 1

Эта информация сохранена еще раз в пересылающей в режиме CEF таблице:

damme#show ip cef 125.125.0.2 detail
125.125.0.2/32, version 62, connected, cached adjacency 125.125.0.2
0 packets, 0 bytes
  via 125.125.0.2, FastEthernet0/0, 0 dependencies
    next hop 125.125.0.2, FastEthernet0/0
    valid cached adjacency 

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

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


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


Document ID: 10477