Exemplo de configuração de MPLS unificado

Introduction

Este documento descreve a finalidade do Unified Multiprotocol Label Switching (MPLS) e fornece um exemplo de configuração.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background

A finalidade do Unified MPLS é dimensionar. Para escalar uma rede MPLS, onde há diferentes tipos de plataformas e serviços em partes da rede, faz sentido dividir a rede em áreas diferentes. Um projeto típico apresenta uma hierarquia que tem um núcleo no centro com agregação no lado. Para dimensionar, pode haver diferentes IGPs (Interior Gateway Protocols) no núcleo versus a agregação. Para dimensionar, você não pode distribuir os prefixos IGP de um IGP para o outro. Se você não distribuir os prefixos IGP de um IGP para o outro IGP, os Caminhos de Rótulo Comutado (LSPs - Label-Switched Paths) de ponta a ponta não serão possíveis.

Para fornecer os serviços MPLS de ponta a ponta, você precisa que o LSP seja de ponta a ponta. O objetivo é manter os serviços MPLS (VPN MPLS, L2VPN MPLS) como eles são, mas introduzir maior escalabilidade. Para fazer isso, mova alguns dos prefixos IGP para o Border Gateway Protocol (BGP) (os prefixos de loopback dos roteadores Provider Edge (PE)), que distribui os prefixos fim-a-fim.

Arquitetura

A Figura 1 mostra uma rede com três áreas diferentes: uma área central e duas áreas de agregação no lado. Cada área executa seu próprio IGP, sem redistribuição entre eles no roteador de borda de área (ABR). O uso do BGP é necessário para fornecer um LSP MPLS fim-a-fim. O BGP anuncia os loopbacks dos roteadores PE com um rótulo em todo o domínio e fornece um LSP de ponta a ponta. O BGP é implantado entre os PEs e ABRs com RFC 3107, o que significa que o BGP envia o prefixo IPv4 + rótulo (AFI/SAFI 1/4).

Como as partes de núcleo e agregação da rede são integradas e LSPs de ponta a ponta são fornecidos, a solução Unified MPLS também é conhecida como "MPLS sem falhas".

Novas tecnologias ou protocolos não são usados aqui, somente MPLS, Label Distribution Protocol (LDP), IGP e BGP. Como você não deseja distribuir os prefixos de loopback dos roteadores PE de uma parte da rede para outra parte, você precisa carregar os prefixos no BGP. O iBGP (Internal Border Gateway Protocol) é usado em uma rede, portanto, o endereço do próximo salto dos prefixos são os prefixos de loopback dos roteadores PE, que não são conhecidos pelo IGP nas outras partes da rede. Isso significa que o endereço do próximo salto não pode ser usado para recursar a um prefixo IGP. O truque é fazer os Refletores de Rota (RR - Route Reflectors) dos roteadores ABR e definir o próximo salto como auto, mesmo para os prefixos iBGP refletidos. Para que isso funcione, é necessário um novo botão.

Somente os RR precisam de software mais novo para suportar essa arquitetura. Como os RR anunciam os prefixos BGP com o próximo salto definido para eles mesmos, eles atribuem um rótulo MPLS local aos prefixos BGP. Isso significa que no plano de dados, os pacotes encaminhados nesses LSPs de ponta a ponta têm um rótulo MPLS extra na pilha de rótulos. Os RR estão no caminho de encaminhamento.

Note: Nesta arquitetura, qualquer serviço MPLS é fornecido. Por exemplo, VPN MPLS ou L2VPN MPLS são fornecidos entre os roteadores PE. A diferença no plano de dados para esses pacotes é que eles agora têm três rótulos na pilha de rótulos, enquanto tinham dois rótulos na pilha de rótulos quando o Unified MPLS não foi usado.

Há dois cenários possíveis:

• O ABR não define o salto seguinte como auto para os prefixos anunciados (refletidos pelo BGP) pelo ABR na parte de agregação da rede. Por causa disso, o ABR precisa redistribuir os prefixos de loopback dos ABRs do IGP central no IGP de agregação. Se isso for feito, ainda há escalabilidade. Somente os prefixos de loopback ABR (do núcleo) precisam ser anunciados na parte de agregação, não os prefixos de loopback dos roteadores PE das partes de agregação remota.
  
  
• O ABR define o salto seguinte como auto para os prefixos anunciados (refletidos pelo BGP) pelo ABR na parte de agregação. Por causa disso, o ABR não precisa redistribuir os prefixos de loopback dos ABRs do IGP central no IGP de agregação.

Em ambos os cenários, o ABR define o próximo salto para auto dos prefixos anunciados (refletidos pelo BGP) pelo ABR da parte de agregação da rede na parte central. Se isso não for feito, o ABR precisará redistribuir os prefixos de loopback dos PEs do IGP de agregação no IGP de núcleo. Se isso for feito, não há escalabilidade.

Para definir o salto seguinte como auto para rotas iBGP refletidas, você deve configurar o comando neighbor x.x.x.x next-hop-self all.

Configurar

Essa é a configuração dos roteadores PE e ABRs para o cenário 2.

Note: A topologia é mostrada na Figura 2. O exemplo de serviço é xconnect (MPLS L2VPN). Entre os roteadores PE e os ABRs, há BGP para IPv4 + label.

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

Note: A redistribuição do IGP central (ospf 1) no IGP de agregação (ospf2 ou ospf 3) é executada com um mapa de rota. Esse mapa de rota permite que os prefixos de loopback do RR redistribuam no IGP de agregação. A razão para isso é que o prefixo de loopback do RR é anunciado diretamente apenas no IGP central (ospf 1). No entanto, o prefixo de loopback do RR também deve ser conhecido no IGP de agregação, de modo que o BGP no roteador PE possa fazer peer com o loopback do RR.

Verificar

Consulte a Figura 2 para verificar a operação do plano de controle.

Veja a Figura 3 para verificar os anúncios de etiqueta MPLS.

Veja a Figura 4 para verificar o encaminhamento de pacotes.

É assim que os pacotes são encaminhados de PE1 para PE2. O prefixo de loopback de PE2 é 10.100.1.5/32, portanto esse prefixo é de interesse.

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

Note: O salto 5 mostra ?5 * * * ?. Isso ocorre porque o roteador P2 não tem uma rota para o endereço IP origem 10.100.1.4 (PE1) do traceroute. Assim, o roteador P2 não pode enviar a mensagem de erro ICMP (Internet Control Message Protocol) de volta para PE1. Isso é normal, já que o ponto do Unified MPLS é não ter os prefixos de loopback de todos os roteadores PE em uma parte de agregação para aparecer nos IGPs das outras partes de agregação. O roteador P2 não tenta encaminhar a mensagem de erro ICMP com a pilha de rótulos original. Isso ocorre porque a pilha de rótulos original tem apenas um rótulo. Se essa pilha de rótulos original do pacote tiver dois ou mais rótulos, a mensagem de erro ICMP será encaminhada ao longo do LSP e poderá voltar à origem do traceroute. Se a pilha de rótulos original tiver apenas um rótulo, o roteador que gera a mensagem de erro ICMP tentará uma pesquisa de rota e tentará roteá-la com o uso da tabela de roteamento (sem o uso da pilha de rótulos original).

P2#show ip route 10.100.1.4
% Subnet not in table

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas

• Arquitetura MPLS perfeita
• Suporte Técnico e Documentação - Cisco Systems