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

Унифицированный пример конфигурации MPLS

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

Введение

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

Внесенный Люком Де Гееном, специалистом службы технической поддержки Cisco.

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

Требования

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

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

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

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Общие сведения

Цель Унифицированного MPLS - все о масштабировании. Для масштабирования сети MPLS, где существуют различные типы patforms и сервисов в частях сети, они целесообразны разделять сеть на различные области. Типичный дизайн представляет иерархию, которая имеет ядро в центре с агрегацией на стороне. Для масштабирования могут быть другие Протоколы внутреннего шлюза (IGPs) в ядро по сравнению с агрегацией. Для масштабирования вы не можете распределить префиксы IGP от одного IGP в другой. Если вы не распределяете префиксы IGP от одного IGP в другой IGP, сквозные Пути коммутации меток (LSP) не возможны.

Для предоставления услуг MPLS от начала до конца, вам нужен LSP, чтобы быть сквозными. Цель состоит в том, чтобы поддержать сервисы MPLS (MPLS VPN, L2VPN MPLS), как они, но представляют большую масштабируемость. Чтобы сделать это, переместите некоторые префиксы IGP в Протокол BGP (петлевые префиксы маршрутизаторов Границы провайдера (PE)), который тогда распределяет префиксы от начала до конца.

Архитектура

Рисунок 1 показывает сеть с тремя различными областями: одно ядро и две области агрегации на стороне. Каждая область выполняет свой собственный IGP без перераспределения между ними на Пограничном маршрутизаторе области (ABR). Использование BGP необходимо для обеспечения сквозного LSP MPLS. BGP объявляет loopback Периферийных маршрутизаторов с меткой через весь домен и предоставляет сквозной LSP. BGP развернут между PE и ABR с RFC 3107, что означает, что BGP передает префикс IPv4 + метка (AFI/САФИ 1/4).

Так как ядро и части агрегации сети интегрированы, и сквозные LSP предоставлены, Унифицированное решение MPLS также упоминается как "Бесшовный MPLS".

Новые технологии или протоколы не используются здесь, только MPLS, Протокол распределения меток (LDP), IGP и BGP. Так как вы не хотите распределять петлевые префиксы Периферийных маршрутизаторов от одной части сети в другую часть, необходимо нести префиксы в BGP. Внутренний протокол граничного шлюза (iBGP) используется в одной сети, таким образом, адрес следующего узла префиксов является петлевыми префиксами Периферийных маршрутизаторов, который не известен IGP в других частях сети. Это означает, что адрес следующего узла не может использоваться для рекурсивного вызова к префиксу IGP. Прием должен сделать Рефлекторы маршрута (RR) маршрутизаторов ABR и установить следующий переход в сам, даже для отраженных префиксов iBGP. Для этого для работы необходима новая кнопка.

Только RRs нужно более новое программное обеспечение для поддержки этой архитектуры. Так как RRs объявляют префиксы BGP с набором следующего перехода себе, они назначают локального MPLS label на префиксы BGP. Это означает, что в плоскости данных, пакеты, переданные на этих сквозных LSP, имеют дополнительного MPLS label в стеке меток. RRs находятся в пути переадресации.

Примечание: По этой архитектуре предоставлен любой сервис MPLS. Например, MPLS VPN или L2VPN MPLS предоставлены между Периферийными маршрутизаторами. Различие в плоскости данных для этих пакетов - то, что у них теперь есть три метки в стеке меток, тогда как у них было две метки в стеке меток, когда не использовался Унифицированный MPLS.

Существует два возможных сценария:

  • ABR делает "not set" следующий переход к сам для объявленных префиксов (отраженный BGP) ABR в часть агрегации сети. Из-за этого ABR должен перераспределить петлевые префиксы ABR от базового IGP в IGP агрегации. Если это сделано, существует все еще масштабируемость. Только петлевые префиксы ABR (от ядра) должны быть объявлены в часть агрегации, не петлевые префиксы от Периферийных маршрутизаторов от удаленных частей агрегации.

  • ABR устанавливает следующий переход в сам для объявленных префиксов (отраженный BGP) ABR в часть агрегации. Из-за этого ABR не должен перераспределять петлевые префиксы ABR от базового IGP в IGP агрегации.

В обоих сценариях ABR устанавливает следующий переход в сам для объявленных префиксов (отраженный BGP) ABR от части агрегации сети в базовую часть. Если это не сделано, ABR должен перераспределить петлевые префиксы PE от IGP агрегации в базовый IGP. Если это сделано, нет никакой масштабируемости.

Для установки следующего перехода в сам для отраженных маршрутов IBGP, необходимо настроить соседний x. x . x . x next-hop-self вся команда.

Настройка

Это - конфигурация Периферийных маршрутизаторов и ABR для сценария 2.

Примечание: toplogy показывают на рисунке 2. Сервис в качестве примера является xconnect (L2VPN MPLS). Между Периферийными маршрутизаторами и ABR, существует BGP для IPv4 + метка.

PE1

interface Loopback0
 ip address 10.100.1.4 255.255.255.255

!
interface Ethernet1/0
 no ip address
 xconnect 10.100.1.5 100 encapsulation mpls
!
router ospf 2
 network 10.2.0.0 0.0.255.255 area 0
 network 10.100.1.4 0.0.0.0 area 0
!
router bgp 1
 bgp log-neighbor-changes
 network 10.100.1.4 mask 255.255.255.255
 neighbor 10.100.1.1 remote-as 1
 neighbor 10.100.1.1 update-source Loopback0
 neighbor 10.100.1.1 send-label

RR1


interface Loopback0
 ip address 10.100.1.1 255.255.255.255
router ospf 1
 network 10.1.0.0 0.0.255.255 area 0
 network 10.100.1.1 0.0.0.0 area 0
!
router ospf 2
 redistribute ospf 1 subnets match internal route-map ospf1-into-ospf2
 network 10.2.0.0 0.0.255.255 area 0
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.100.1.2 remote-as 1
 neighbor 10.100.1.2 update-source Loopback0
 neighbor 10.100.1.2 next-hop-self all
 neighbor 10.100.1.2 send-label
 neighbor 10.100.1.4 remote-as 1
 neighbor 10.100.1.4 update-source Loopback0
 neighbor 10.100.1.4 route-reflector-client
 neighbor 10.100.1.4 next-hop-self all
 neighbor 10.100.1.4 send-label

ip prefix-list prefix-list-ospf1-into-ospf2 seq 5 permit 10.100.1.1/32

route-map ospf1-into-ospf2 permit 10
 match ip address prefix-list prefix-list-ospf1-into-ospf2


RR2

interface Loopback0
 ip address 10.100.1.2 255.255.255.255

router ospf 1
 network 10.1.0.0 0.0.255.255 area 0
 network 10.100.1.2 0.0.0.0 area 0
!
router ospf 3
 redistribute ospf 1 subnets match internal route-map ospf1-into-ospf3
 network 10.3.0.0 0.0.255.255 area 0
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.100.1.1 remote-as 1
 neighbor 10.100.1.1 update-source Loopback0
 neighbor 10.100.1.1 next-hop-self all
 neighbor 10.100.1.1 send-label
 neighbor 10.100.1.5 remote-as 1
 neighbor 10.100.1.5 update-source Loopback0
 neighbor 10.100.1.5 route-reflector-client
 neighbor 10.100.1.5 next-hop-self all
 neighbor 10.100.1.5 send-label

ip prefix-list prefix-list-ospf1-into-ospf3 seq 5 permit 10.100.1.2/32

route-map ospf1-into-ospf3 permit 10
 match ip address prefix-list prefix-list-ospf1-into-ospf3


PE2

interface Loopback0
 ip address 10.100.1.5 255.255.255.255

interface Ethernet1/0
 no ip address
 xconnect 10.100.1.4 100 encapsulation mpls

router ospf 3
 network 10.3.0.0 0.0.255.255 area 0
 network 10.100.1.5 0.0.0.0 area 0

router bgp 1
 bgp log-neighbor-changes
 network 10.100.1.5 mask 255.255.255.255
 neighbor 10.100.1.2 remote-as 1
 neighbor 10.100.1.2 update-source Loopback0
 neighbor 10.100.1.2 send-label

Примечание: Перераспределение базового IGP (ospf 1) в IGP агрегации (ospf2 или ospf 3) выполнено с route-map. Этот route-map позволяет петлевым префиксам RR перераспределять в IGP агрегации. Причина для этого состоит в том, что петлевой префикс RR только непосредственно объявлен в базовый IGP (ospf 1). Однако петлевой префикс RR должен быть известен в IGP агрегации также, так, чтобы BGP на Периферийном маршрутизаторе мог взаимодействовать с loopback RR.

Проверка

Посмотрите рисунок 2 для проверки операции уровня управления.

Посмотрите рисунок 3 для проверки рекламных объявлений MPLS label.

Посмотрите рисунок 4 чтобы к сверению пересылки пакетов.

Это - то, как пакеты переданы от PE1 до PE2. Петлевой префикс PE2 является 10.100.1.5/32, так, чтобы префикс представлял интерес.

PE1#show ip route 10.100.1.5

Routing entry for 10.100.1.5/32
  Known via "bgp 1", distance 200, metric 0, type internal
  Last update from 10.100.1.1 00:11:12 ago
  Routing Descriptor Blocks:
  * 10.100.1.1, from 10.100.1.1, 00:11:12 ago
    Route metric is 0, traffic share count is 1
    AS Hops 0
    MPLS label: 22


PE1#show ip cef 10.100.1.5
10.100.1.5/32
  nexthop 10.2.2.6 Ethernet0/0 label 19 22


PE1#show ip cef 10.100.1.5 detail
10.100.1.5/32, epoch 0, flags rib defined all labels
  1 RR source [no flags]
  recursive via 10.100.1.1 label 22
    nexthop 10.2.2.6 Ethernet0/0 label 19

PE1#show bgp ipv4 unicast labels

  Network         Next Hop     In label/Out label
  10.100.1.4/32   0.0.0.0        imp-null/nolabel
  10.100.1.5/32   10.100.1.1     nolabel/22


P1#show mpls forwarding-table labels 19 detail
Local     Outgoing  Prefix          Bytes Label  Outgoing  Next Hop  
Label     Label     or Tunnel Id    Switched     interface            
19        Pop Label 10.100.1.1/32   603468       Et1/0     10.2.1.1  
       MAC/Encaps=14/14, MRU=1504, Label Stack{}
       AABBCC000101AABBCC0006018847
       No output feature configured


RR1#show mpls forwarding-table labels 22 detail
Local     Outgoing  Prefix          Bytes Label  Outgoing  Next Hop  
Label     Label     or Tunnel Id    Switched     interface            
22        21        10.100.1.5/32   575278       Et0/0     10.1.1.3  
       MAC/Encaps=14/22, MRU=1496, Label Stack{17 21}
       AABBCC000300AABBCC0001008847 0001100000015000
       No output feature configured


RR1#show bgp ipv4 unicast labels
  Network         Next Hop     In label/Out label
  10.100.1.4/32   10.100.1.4     19/imp-null
  10.100.1.5/32   10.100.1.2     22/21


P3#show mpls forwarding-table labels 17 detail
Local     Outgoing  Prefix          Bytes Label  Outgoing  Next Hop  
Label     Label     or Tunnel Id    Switched     interface            
17        Pop Label 10.100.1.2/32   664306       Et1/0     10.1.2.2  
       MAC/Encaps=14/14, MRU=1504, Label Stack{}
       AABBCC000201AABBCC0003018847
       No output feature configured


RR2#show mpls forwarding-table labels 21 detail
Local     Outgoing  Prefix          Bytes Label  Outgoing  Next Hop  
Label     Label     or Tunnel Id    Switched     interface            
21        17        10.100.1.5/32   615958       Et0/0     10.3.1.7  
       MAC/Encaps=14/18, MRU=1500, Label Stack{17}
       AABBCC000700AABBCC0002008847 00011000
       No output feature configured


RR2#show bgp ipv4 unicast labels
  Network         Next Hop     In label/Out label
  10.100.1.4/32   10.100.1.1     22/19
  10.100.1.5/32   10.100.1.5     21/imp-null


P2#show mpls forwarding-table labels 17 detail
Local     Outgoing  Prefix          Bytes Label  Outgoing  Next Hop  
Label     Label     or Tunnel Id    Switched     interface            
17        Pop Label 10.100.1.5/32   639957       Et1/0     10.3.2.5  
       MAC/Encaps=14/14, MRU=1504, Label Stack{}
       AABBCC000500AABBCC0007018847
       No output feature configured


PE1#trace
Protocol [ip]:
Target IP address: 10.100.1.5
Source address: 10.100.1.4

DSCP Value [0]:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
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.100.1.5
VRF info: (vrf in name/id, vrf out name/id)
 1 10.2.2.6 [MPLS: Labels 19/22 Exp 0] 3 msec 3 msec 3 msec
 2 10.2.1.1 [MPLS: Label 22 Exp 0] 3 msec 3 msec 3 msec
 3 10.1.1.3 [MPLS: Labels 17/21 Exp 0] 3 msec 3 msec 2 msec
 4 10.1.2.2 [MPLS: Label 21 Exp 0] 2 msec 3 msec 2 msec
 5 * * *
 6 10.3.2.5 4 msec * 4 msec

Примечание: Скачкообразно двиньтесь 5, показывает? 5 * * *?. Это вызвано тем, что маршрутизатор P2 не имеет маршрута для IP - адреса источника 10.100.1.4 (PE1) traceroute. Таким образом маршрутизатор P2 не может передать сообщение об ошибках Протокола ICMP назад к PE1. Это обычно, поскольку точка Унифицированного MPLS не должна иметь петлевых префиксов всех Периферийных маршрутизаторов в одной части агрегации для разоблачения в IGPs других частей агрегации. Маршрутизатор P2 не пытается передать сообщение об ошибках ICMP с исходным стеком меток. Это вызвано тем, что orginal стек меток только имеет одну метку. Если этот исходный стек меток пакета имеет две или больше метки, сообщение об ошибках ICMP передано вдоль LSP и может возвратиться к источнику traceroute. Если исходный стек меток имеет только одну метку, маршрутизатор, который генерирует сообщение об ошибках ICMP, делает попытку поиска маршрута и попыток направить его с использованием таблицы маршрутизации (без использования исходного стека меток).

P2#show ip route 10.100.1.4
% Subnet not in table

Устранение неполадок

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

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



Document ID: 116127