Multiprotocol Label Switching (MPLS) : MPLS

Funcionalidade unificada, características, e exemplo de configuração MPLS

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve o Multiprotocol Label Switching (MPLS) unificado, que é toda sobre a escamação. Fornece uma estrutura das soluções de tecnologia para trazer o tráfego de ponta a ponta e/ou serviços simples através de uma infraestrutura tradicionalmente segmentada. Utiliza os benefícios de uma infraestrutura hierárquica enquanto melhora a escalabilidade e a simplicidade do projeto de rede.

Contribuído por Atahar Khan e por Sudhir Kumar, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

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.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Configurar

Evolução da rede

Quando você olha a história dos serviços com base em pacotes da rede, a seguir uma mudança em valores de negócio da rede pode ser observada. Isto vai das melhorias de conectividade discretas a fim fazer aplicativos tão fluentes como possível, às Tecnologias da Colaboração a fim apoiar a Colaboração móvel. Finalmente, os serviços por encomenda da nuvem são introduzidos com os serviços de aplicativo a fim aperfeiçoar as ferramentas usadas com uma organização e melhorar a estabilidade e os custos de propriedade.


Figura 1

Este realce contínuo do valor e da funcionalidade da rede conduz a uma necessidade muito mais patente para a simplicidade, a viabilidade, a integração, e a estabilidade da rede onde as redes foram segmentadas em consequência das ilhas operacionais separadas e de nenhum controle real do caminho de ponta a ponta. Agora há uma necessidade de trazê-la que toda junto com uma única arquitetura que seja fácil de controlar, fornece a escalabilidade a 100,000's dos Nós, e usa as Tecnologias atuais de Alta disponibilidade e de convergência rápida. Este é o que o MPLS unificado traz à tabela, que é a rede segmentada em uma visibilidade do plano e do caminho de ponta a ponta do único controle.

Exigências da rede de modem

  • Aumente a procura da largura de banda (o vídeo)
  • Aumente a complexidade do aplicativo (nuvem e a virtualização)
  • Aumente a necessidade para a convergência (a mobilidade)

Como pode você simplificar operações MPLS em redes cada vez mais maiores com mais exigências de aplicativo complexo?

Desafios tradicionais MPLS com Tecnologias diferentes do acesso

  • Complexidade a fim conseguir a convergência do milissegundo dos 50 pés com Fast ReRoute da engenharia de tráfego (TE FRR)
  • Precise para protocolos de roteamento e interação sofisticados com protocolos da camada 2
  • Rache redes grandes em domínios quando os serviços forem fim-a-fim entregado
  • Mecanismos fim-a-fim comuns da convergência e da elasticidade
  • Pesquise defeitos e provision fim-a-fim através dos domínios múltiplos

A atração unificada MPLS é resumida nesta lista:

  • Número reduzido de pontos operacionais.
    • Em Plataformas gerais do transporte, um serviço tem que ser configurado em cada elemento de rede através dos pontos operacionais. O sistema de administração tem que conhecer a topologia.
    • No MPLS unificado, com a integração de todas as ilhas MPLS, o número mínimo de pontos operacionais é conseguido.
  • Possibilidade para provision facilmente serviços: Mergulhe 3 (L3) VPN, agência de notícias privada virtual (VPWS), serviço virtual da LAN privada (VPL), sem pseudowire-costura (Picowatt-costura) ou mecanismos de InterAS. Com a introdução de MPLS dentro da agregação, alguma configuração estática é evitada que cria ilhas MPLS.
  • Forneça o transporte fim-a-fim MPLS.
  • Mantenha áreas do Interior Gateway Protocol (IGP) tabelas de roteamento separadas e pequenas.
  • Convergência rápida.
  • Fácil configurar e pesquisar defeitos.
  • Capacidade para integrar com alguma tecnologia do acesso.
  • Prontidão do IPv6.

Cisco unificou o MPLS

O MPLS unificado é definido pela adição de recursos extras com MPLS clássico/tradicional e dá mais escalabilidade, Segurança, simplicidade e viabilidade. A fim entregar os serviços MPLS fim-a-fim, o trajeto etiquetado fim-a-fim do Switches (LSP) é precisado. O objetivo é manter os serviços MPLS (MPLS VPN, MPLS L2VPN) porque são, mas introduzir a maior escalabilidade. A fim fazer isto, mova alguns dos prefixos IGP no Border Gateway Protocol (BGP) (os prefixos do laço de retorno do Roteadores da ponta de provedor (PE)), que distribuem então os prefixos fim-a-fim.


Figura 2

Antes que a arquitetura unificada Cisco MPLS esteja discutida, é importante compreender os recursos chaves usados a fim fazer a isto uma realidade.

Características e componentes

Leve a informação da etiqueta em BGP-4 (o RFC 3107)

É uma condição prévia para ter um método escalável a fim trocar prefixos entre segmentos de rede. Você poderia simplesmente fundir os IGP (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), ou o Enhanced Interior Gateway Routing Protocol (EIGRP)) em um único domínio. Contudo um IGP não é projetado levar 100,000s dos prefixos. O protocolo da escolha para essa finalidade é BGP. É um protocolo bem-provado o que apoia o Internet com o 100,000's das rotas e dos ambientes MPLS-VPN com milhões de entradas. Cisco unificou os usos BGP-4 MPLS com intercâmbio de informação da etiqueta (RFC3107). Quando o BGP distribui uma rota, pode igualmente distribuir uma etiqueta MPLS que seja traçada a essa rota. A informação de mapeamento da etiqueta MPLS para a rota é levada dentro a mensagem da atualização BGP que contém a informação sobre a rota. Se o salto seguinte não é mudado, a etiqueta está preservada e as mudanças da etiqueta se o salto seguinte muda. No MPLS unificado, o salto seguinte muda nos roteadores de borda de área (ABR).

Quando você permite o RFC 3107 em ambos os BGP Router, o Roteadores anuncia entre si que pode então enviar etiquetas MPLS com as rotas. Se o Roteadores negocia com sucesso sua capacidade para enviar etiquetas MPLS, o Roteadores adiciona etiquetas MPLS a todas as atualizações BGP que parte.

A troca da etiqueta é precisada a fim manter a informação de caminho de ponta a ponta entre segmentos. Em consequência, cada segmento torna-se pequeno bastante para ser controlado por operadores e ao mesmo tempo há uma informação de circuito distribuída para uma conscientização do trajeto entre dois oradores diferentes IP.

Como trabalha?


Figura 3

Em figura 3 você pode ver que há três segmentos com o trajeto etiquetado protocolo de descoberta do Switches da etiqueta (LDP LSP) e a rede de acesso não tem o LDP permitido. O objetivo é juntar-se junto lhe de modo que haja um único trajeto MPLS (Internal BGP (iBGP) LSP hierárquico) entre Nós da PRE-agregação (PRE-Agg). Porque a rede é um único sistema autônomo BGP, todas as sessões são sessões do iBGP. Cada segmento executa seus próprios trajetos IGP (OSPF, IS-IS, ou EIGRP) e LDP LSP dentro do domínio IGP. Dentro de Cisco unificou o MPLS, o Roteadores (ABR) que se junta aos segmentos deve ser refletores de rota inline BGP com o Seguinte-Salto-auto e o RFC 3107 a fim levar um IPv4 + a etiqueta configurados nas sessões. Estes auto-falantes de BGP estão dentro da arquitetura unificada Cisco MPLS provida como aos ABR.

Por que são os ABR refletores de rota inline?

Um dos objetivos do MPLS unificado é ter uma infraestrutura fim-a-fim altamente escalável. Assim, cada segmento deve ser mantido simples a fim operar-se. Todos os peerings são peerings do iBGP, consequentemente há uma necessidade para um full-mesh dos peerings entre todos os alto-falantes iBGP dentro da rede completa. Isso conduz a um ambiente de rede muito pouco prático se há uns milhares de auto-falantes de BGP. Se os ABR são feitos a refletores de rota, o número de ibgp peering está reduzido ao número do por-segmento dos auto-falantes de BGP” em vez entre “de todos os” auto-falantes de BGP do completo COMO.

Por que Seguinte-Salto-auto?

O BGP opera sobre a base de consultas do roteamento recursivo. Isto é feito a fim acomodar a escalabilidade dentro do IGP subjacente que é utilizado. Para a consulta recursivo, o BGP usa o salto seguinte anexado a cada entrada da rota de BGP. Assim, por exemplo, se um nó de origem deseja enviar um pacote a um nó de destino e se o pacote bate o BGP Router, a seguir o BGP Router faz uma consulta do roteamento em sua tabela de roteamento de BGP. Encontra uma rota para o nó de destino e encontra o salto seguinte como uma próxima etapa. Este salto seguinte deve ser sabido pelo IGP subjacente. Como a etapa final, o BGP Router para a frente o pacote baseado avante informação na etiqueta IP e MPLS anexados a esse salto seguinte.

A fim certificar-se de que dentro de cada segmento somente os saltos seguintes estão precisados de ser sabidos pelo IGP, precisa-se que o salto seguinte anexado à entrada de BGP está dentro do segmento de rede e não dentro de um vizinho ou mais distante de um segmento. Se você reescreve o salto seguinte BGP com a característica do Seguinte-Salto-auto, assegure-se de que o salto seguinte esteja dentro do segmento local.

Una-o todo


Figura 4

Figura 4 fornece um exemplo de como o prefixo “A” L3 VPN e a troca da etiqueta se operam e de como a pilha de rótulo MPLS é criada para ter a informação de caminho de ponta a ponta para o fluxo de tráfego entre ambos os PE.

A rede é dividida como três domínios independentes IGP/LDP. O tamanho reduzido do roteamento e das tabelas do forwarding no Roteadores é permitir a melhor estabilidade e uma convergência mais rápida. O LDP é usado para construir o intradomain LSP dentro dos domínios. As etiquetas do RFC 3107 BGP IPv4+ são usadas como protocolo da distribuição de rótulo do interdomain a fim construir BGP hierárquico LSP através dos domínios. BGP3107 introduz uma etiqueta extra na pilha de rótulo de transmissão na arquitetura unificada MPLS.

Intradomain - LDP LSP

Interdomain - BGP LSP hierárquico


Figura 5

O VPN prefixa “A” é anunciado por PE31 a PE11 com etiqueta 30 do serviço L3VPN e salto seguinte como o laço de retorno PE31 através do interdomain fim-a-fim BGP hierárquico LSP. Agora, olhar no trajeto de encaminhamento para o prefixo “A” VPN de PE11 a PE31.

  • Em PE11, prefixe A é sabido através da sessão de BGP com PE31 porque o salto seguinte PE31 e PE31 é recursively alcançável através do P1 com etiqueta 100 BGP. PE11 recebeu a informação do IPv4 + da etiqueta do P1 como atualizações BGP porque é permitido com a característica do RFC 3107 a fim enviar a informação do IPv4 + da etiqueta.
  • O P1 é alcançável de PE11 através do intradomain LDP LSP e adiciona uma outra etiqueta LDP sobre a etiqueta BGP. Finalmente, o pacote sai do nó PE11 com três etiquetas. Por exemplo, a etiqueta do serviço 30 L3VPN, a etiqueta de 100 BGP, e a etiqueta de 200 LDP IGP.
  • A etiqueta da parte superior LDP continua a trocar dentro o intradomain LDP LSP e o pacote alcança o P1 com duas etiquetas após o Penultimate Hop Popping (PHP).
  • O P1 está configurado enquanto o refletor de rota inline (RR) com auto e ele do salto seguinte se junta a dois domínios IGP ou LDP LSP.
  • No P1, o salto seguinte para PE31 é mudado ao P2 e a atualização é recebida através do BGP com IPv4 + etiqueta (RFC3107). A etiqueta BGP é trocada com etiqueta nova porque o salto seguinte é mudado e a etiqueta IGP é empurrada na parte superior.
  • O pacote sai do nó P1 com três etiquetas e a etiqueta 30 do serviço é sem tocar. Isto é, a etiqueta do serviço 30 L3VPN, etiqueta de 101 BGP, e etiqueta de 201 LDP.
  • A etiqueta da parte superior LDP troca dentro o intradomain LDP LSP e o pacote alcança o P2 com duas etiquetas após o PHP.
  • No P2, o salto seguinte para PE31 é mudado outra vez e é alcançável através do IGP. A etiqueta BGP é removida enquanto uma etiqueta implícito-nula BGP é recebida de PE31 para o PHP.
  • As folhas do pacote com duas etiquetas. Por exemplo, a etiqueta do serviço 30 L3VPN e a etiqueta de 110 LDP.
  • Em PE31, o pacote chega com uma etiqueta após o PHP da etiqueta LDP e baseado na etiqueta 30 do serviço. O pacote sem rótulo é enviado ao destino CE31 sob o roteamento virtual e a transmissão (VRF).

Quando você olha a pilha de rótulo MPLS, o interruptor do pacote entre um dispositivo de origem e de destino baseado no prefixo precedente e a troca da etiqueta está observado dentro do ambiente de switching MPLS.


Figura 6

Convergência Prefixo-independente BGP (BGP PIC)

Esta é uma tecnologia de Cisco que seja usada em cenários de falha BGP. A rede convirge sem uma perda dos segundos tradicionais na reconvergência BGP. Quando o BGP PIC é usado, a maioria de cenários de falha podem ser reduzidos a uma estadia da reconvergência abaixo de 100 milissegundos.

Como isto é feito?

Tradicionalmente quando o BGP detecta uma falha, volta a calcular para cada entrada de BGP para o melhor caminho. Quando há uma tabela de roteamento com milhares de entradas da rota, este pode tomar uma quantidade de tempo considerável. Além, este BGP Router precisa de distribuir todos aqueles melhores caminhos novos a cada um de seus vizinhos a fim informá-los da topologia de rede mudada e dos melhores caminhos mudados. Como a etapa final, cada um das necessidades destinatárias dos auto-falantes de BGP de fazer um cálculo do melhor caminho a fim encontrar os melhores caminhos novos.

Cada vez que o primeiro auto-falante de BGP detecta algo erradamente, começa o cálculo do melhor caminho até que todos seus auto-falantes de BGP vizinhos façam seu novo cálculo, o fluxo de tráfego pôde ser deixado cair.


Figura 7

O BGP PIC para a característica IP e de MPLS VPN melhora a convergência de BGP após uma falha de rede. Esta convergência é aplicável às falhas do núcleo e da borda e pode ser usada no IP e nas redes MPLS. O BGP PIC para o IP e a característica do MPLS VPN cria e armazena um alternativo/caminho alternativo no Routing Information Base (RIB), no banco de informação de encaminhamento (FIB), e no Cisco Express Forwarding (CEF) de modo que quando uma falha é detectada, o alternativo/caminho alternativo possa imediatamente tomar sobre, assim permite o Failover rápido.

Com uma única reescrita da informação do salto seguinte o fluxo de tráfego é restaurado. Adicionalmente a convergência de BGP da rede acontece no fundo, mas os fluxos de tráfego não são impactados anymore. Esta reescrita acontece dentro dos 50 pés milissegundo. Se você usa esta tecnologia, a convergência de rede está reduzida dos segundos aos 50 pés milissegundo mais a convergência IGP.

BGP Adicionar-PATH

O BGP Adicionar-PATH é uma melhoria em como as entradas de BGP são comunicadas entre auto-falantes de BGP. Se em um determinado auto-falante de BGP há mais do que uma única entrada para um determinado destino, a seguir que o auto-falante de BGP envia somente a entrada que é seu melhor caminho para esse destino a seus vizinhos. O resultado é que nenhuma disposição está feita a fim permitir a propaganda dos caminhos múltiplos para o mesmo destino.

O BGP Adicionar-PATH é uma característica BGP para reservar mais como somente o melhor caminho, e permite caminhos múltiplos para o mesmo destino sem os trajetos novos que substituem implicitamente o precedentes. Esta extensão ao BGP é particularmente importante a fim ajudar com BGP PIC, quando os refletores de rota BGP são usados, de modo que os auto-falantes de BGP diferentes dentro do COMO têm o acesso a mais trajetos BGP como apenas o “melhor trajeto BGP” de acordo com o refletor de rota.

Substituições sem loop e rLFA para a convergência rápida IGP

Operações para conseguir uma restauração de 50 pés-milissegundo depois que um link ou uma falha de nó podem ser simplificados dramaticamente com a introdução de uma nova tecnologia chamada as substituições sem loop (LFAs). O LFA aumenta os protocolos de roteamento de estado de enlace (IS-IS e OSPF) a fim encontrar trajetos do roteamento alternativo em uma maneira sem loop. O LFA permite que cada roteador defina e use um caminho backup predeterminado se uma adjacência (nó de rede ou link) falha. A fim entregar um tempo de restauração milissegundo dos 50 pés em caso do link ou das falhas de nó, o MPLS TE FRR pode ser distribuído. Contudo, isto exige a adição de um outro protocolo (protocolo de reserva de recursos, ou de um RSVP) para a instalação e o Gerenciamento dos túneis TE. Quando isto pôde ser necessário para o gerenciamento de largura de banda, a operação da proteção e da restauração não exige o gerenciamento de largura de banda. Daqui, o associado aéreo com a adição de RSVP TE é considerado elevação para a proteção simples dos links e dos Nós.

O LFA pode fornecer uma técnica simples e fácil sem o desenvolvimento de RSVP TE em tais encenações. Em consequência destas técnicas, o Roteadores interconectado de hoje nas redes em larga escala pode entregar a restauração milissegundo dos 50 pés para o link e as falhas de nó sem um requisito de configuração para o operador.


Figura 8

O LFA-FRR é um mecanismo que forneça a proteção local para o tráfego de unicast no IP, no MPLS, no Ethernet sobre MPLS (EoMPLS), no Multiplexação Inversa sobre ATM (IMA) sobre o MPLS, nos serviços de emulação de circuitos sobre a rede de pacote comutado (CESoPSN) sobre o MPLS, e na divisão de tempo Estrutura-agnóstica multiplexando sobre o pacote (SAToP) sobre redes MPLS. Contudo, algumas topologias (tais como a topologia em anel) exigem a proteção que não é tida recursos para por LFA-FRR apenas. A característica remota LFA-FRR é útil em tais situações.

O LFA-FRR remoto estende o comportamento básico de LFA-FRR a toda a topologia. Ele para a frente o tráfego em torno de um nó falho a um LFA remoto que seja mais de um salto afastado. Na figura 9, se o link entre o C1 e o C2 não alcança o A1 então o C2 envia o pacote sobre uma sessão LDP dirigida ao C5 que tem a alcançabilidade ao A1.


Figura 9

Em LFA-FRR remoto, um nó computa dinamicamente seu nó LFA. Depois que o nó alternativo é determinado (que não está conectado diretamente), o nó estabelece automaticamente uma sessão dirigida do protocolo de distribuição de rótulo (LDP) ao nó alternativo. A sessão LDP dirigida troca etiquetas pela correção de erros de encaminhamento particular (FEC).

Quando o link falha, os usos do nó etiquetam o empilhamento a fim escavar um túnel o tráfego ao nó remoto LFA, a fim enviar o tráfego ao destino. Todas as trocas e Tunelamento da etiqueta ao nó remoto LFA são dinâmicos na natureza e preprovisioning não é exigido. A troca e o mecanismo de tunelamento da etiqueta do todo são dinâmicos e não envolvem nenhum abastecimento manual.

Para o intradomain LSP, o LFA remoto FRR é utilizado para o tráfego do unicast MPLS nas topologias em anel. Precalculates remotos LFA FRR um caminho backup para cada prefixo na tabela de roteamento IGP, que permite que o nó comute rapidamente ao caminho backup quando uma falha for encontrada. Isto fornece o tempo de recuperação na ordem dos 50 pés milissegundo.

Cisco unificou o exemplo da arquitetura MPLS

Quando todas as ferramentas e características precedentes são unidas dentro de um ambiente de rede, cria o ambiente de rede MPLS unificado Cisco. Este é o exemplo da arquitetura para grandes provedores de serviços.


Figura 10

  • O núcleo e a agregação são organizados como domínios distintos IGP/LDP.
  • Interdomain os LSP hierárquicos baseado no RFC 3107, BGP IPv4+ etiqueta que são estendidos para fora ao PRE-agg.
  • Intradomain LSP baseado no LDP.
  • O núcleo do interdomain/agregação LSP é estendido nas redes de acesso pela distribuição do protocolo Interior Gateway Protocols de rádio das redes de acesso (RAN IGP) no iBGP do interdomain e distribui os prefixos etiquetados necessários do iBGP (gateway MPC (núcleo móvel do pacote)) em RAN IGP (através das comunidades do BGP).

Exemplo unificado da configuração de MPLS

Aqui ia um exemplo simplificado do MPLS unificado.

Roteador de borda de área do núcleo -½ XR do¿Â do Cisco IOSïÂ

Gateway router do local da PRE-agregação e da pilha - Cisco IOS


Figura 11

200:200A comunidade MPC
300:300A comunidade da agregação

Domínio IGP do núcleoNível 2 ISIS
Domínio IGP da agregaçãoNível 1 ISIS
Alcance o domínio IGPOSPF 0 áreas

Configuração do roteador de borda de área do núcleo


Figura 12

! IGP Configuration
router isis core-agg
net 49.0100.1010.0001.0001.00
address-family ipv4 unicast
metric-style wide
propagate level 1 into level 2 route-policy drop-all ! Disable L1 to L2 redistribution
!
interface Loopback0
ipv4 address 10.10.10.1 255.255.255.255
passive
!
interface TenGigE0/0/0/0                                              
!
interface TenGigE0/0/0/1                                             
circuit-type level-2-only                     ! Core facing ISIS L2 Link

!
interface TenGigE0/0/0/2                 
circuit-type level-1                         ! Aggregation facingis ISIS L1 Link

   !
route-policy drop-all
drop
end-policy
 
! BGP Configuration

router bgp 100
bgp router-id 10.10.10.1
address-family ipv4 unicast
allocate-label all                            ! Send labels with BGP routes
!
session-group infra
remote-as 100
cluster-id 1001
update-source Loopback0
!
neighbor-group agg                          
use session-group infra
address-family ipv4 labeled-unicast      
   route-reflector-client                                                                    

   route-policy BGP_Egress_Filter out         ! BGP Community based Egress filtering

   next-hop-self
!
neighbor-group mpc
use session-group infra
address-family ipv4 labeled-unicast      
   route-reflector-client
   next-hop-self
!
neighbor-group core
use session-group infra                                
address-family ipv4 labeled-unicast      
   next-hop-self

community-set Allowed-Comm
200:200,                        
300:300,                          
!
route-policy BGP_Egress_Filter
if community matches-any Allowed-Comm then      
   pass

Configuração da PRE-agregação


Figura 13

interface Loopback0
ipv4 address 10.10.9.9 255.255.255.255
!
interface Loopback1
ipv4 address 10.10.99.9 255.255.255.255

! Pre-Agg IGP Configuration

router isis core-agg
net 49.0100.1010.0001.9007.00
is-type level-1                                       !  ISIS L1 router
metric-style wide
passive-interface Loopback0                           !  Core-agg IGP loopback0

!RAN Access IGP Configuration

router ospf 1
router-id 10.10.99.9
redistribute bgp 100 subnets route-map BGP_to_RAN     !  iBGP to RAN IGP redistribution
network 10.9.9.2 0.0.0.1 area 0
network 10.9.9.4 0.0.0.1 area 0
network 10.10.99.9 0.0.0.0 area 0                
distribute-list route-map Redist_from_BGP in           Inbound filtering to prefer
      labeled BGP learnt prefixes


ip community-list standard MPC_Comm permit 200:200
!
route-map BGP_to_RAN permit 10                       ! Only redistribute prefixes
      marked with
MPC community
match community MPC_Comm
set tag 1000
route-map Redist_from_BGP deny 10
match tag 1000
!
route-map Redist_from_BGP permit 20


! BGP Configuration
router bgp 100
bgp router-id 10.10.9.10
bgp cluster-id 909
neighbor csr peer-group
neighbor csr remote-as 100
neighbor csr update-source Loopback100                ! Cell Site - Routers RAN IGP
      loopback100
as source
neighbor abr peer-group
neighbor abr remote-as 100
neighbor abr update-source Loopback0                  ! Core POP ABRs - core-agg IGP
      loopback0 as source

neighbor 10.10.10.1 peer-group abr
neighbor 10.10.10.2 peer-group abr
neighbor 10.10.13.1 peer-group csr
!
address-family ipv4
bgp redistribute-internal
network 10.10.9.10 mask 255.255.255.255 route-map AGG_Comm   ! Advertise with
      Aggregation Community (100:100)

redistribute ospf 1                                   !  Redistribute RAN IGP prefixes
neighbor abr send-community
neighbor abr next-hop-self

neighbor abr send-label                              !  Send labels with BGP routes
neighbor 10.10.10.1 activate
neighbor 10.10.10.2 activate
exit-address-family
!
route-map AGG_Comm permit 10
set community 300:300

Configuração do gateway do local da pilha (CSG)


Figura 14

interface Loopback0
ip address 10.10.13.2 255.255.255.255

! IGP Configuration
router ospf 1
router-id 10.10.13.2
network 10.9.10.0 0.0.0.1 area 0
network 10.13.0.0 0.0.255.255 area 0
network 10.10.13.3 0.0.0.0 area 0                

Configuração do MTG


Figura 15

Interface lookback0
ip address 10.10.11.1 255.255.255.255
 
! IGP Configuration
router isis core-agg
is-type level-2-only                         !  ISIS L2 router
net 49.0100.1010.0001.1001.00
address-family ipv4 unicast
metric-style wide
 
! BGP Configuration
router bgp 100
bgp router-id 10.10.11.1
address-family ipv4 unicast
network 10.10.11.1/32 route-policy MPC_Comm   ! Advertise Loopback-0 with MPC Community
allocate-label all                            ! Send labels with BGP routes
!
session-group infra

remote-as 100
update-source Loopback0
!
neighbor-group abr
use session-group infra
address-family ipv4 labeled-unicast
   next-hop-self
!
neighbor 10.10.6.1
use neighbor-group abr
!
neighbor 10.10.12.1
use neighbor-group abr
 
community-set MPC_Comm
200:200
end-set
!
route-policy MPC_Comm
set community MPC_Comm
end-policy

Verificar

O prefixo do laço de retorno do gateway móvel do pacote (MPG) é 10.10.11.1 /32, de modo que o prefixo seja do interesse. Agora, olhar em como os pacotes são enviados de CSG a MPG.

O prefixo 10.10.11.1 MPC é sabido ao roteador CSG do PRE-agg com etiqueta 1000 da rota e pode ser enviada como um pacote rotulado com etiqueta que parte 31 LDP (domínio intra LDP LSP). A comunidade MPC 200:200 esteve traçada com etiqueta 1000 da rota no nó PRE-agg quando a redistribução estiver no OSPF.

Saída do nó CSG

CSG#sh mpls forwarding-table 10.10.11.1 detail
Local     Outgoing   Prefix          Bytes Label  Outgoing   Next Hop  
Label     Label     or Tunnel Id     Switched     interface            
34         31        10.10.11.1/32   0            Vl40       10.13.1.0  
       MAC/Encaps=14/18, MRU=1500, Label Stack{31}

Saídas do nó PRE-Agg

No nó PRE-agg, o prefixo MPC é redistribuído do BGP ao processo de OSPF do acesso RAN com filtração comunidade-baseada e o processo de OSPF é redistribuído no BGP. Esta redistribução controlada é necessária a fim fazer o IP fim-a-fim reachabilty, ao mesmo tempo cada segmento tem rotas exigidas mínimo.

O prefixo 10.10.11.1/32 é sabido através de BGP hierarichal 100 com a comunidade MPC 200:200 anexada. 16020 a etiqueta BGP 3107 recebida do roteador de borda de área do núcleo (ABR) e a etiqueta 22 LDP são adicionadas na parte superior para a transmissão do intradomain após a consulta recursivo do salto seguinte.

Pre-AGG1#sh ip route 10.10.11.1
Routing entry for 10.10.11.1/32
Known via "bgp 100", distance 200, metric 0, type internal
Redistributing via ospf 1
Advertised by ospf 1 subnets tag 1000 route-map BGP_TO_RAN
Routing Descriptor Blocks:
* 10.10.10.2, from 10.10.10.2, 1d17h ago
     Route metric is 0, traffic share count is 1
     AS Hops 0
     MPLS label: 16020

Pre-AGG1#sh bgp ipv4 unicast 10.10.11.1
BGP routing table entry for 10.10.11.1/32, version 116586
Paths: (2 available, best #2, table default)
Not advertised to any peer
Local
   <SNIP>
Local
   10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)
     Origin IGP, metric 0, localpref 100, valid, internal, best
     Community: 200:200
     Originator: 10.10.11.1, Cluster list: 0.0.3.233, 0.0.2.89
     mpls labels in/out nolabel/16020

Pre-AGG1#sh bgp ipv4 unicast labels
   Network         Next Hop     In label/Out label
   10.10.11.1/32 10.10.10.1   nolabel/16021
                   10.10.10.2   nolabel/16020

Pre-AGG1#sh mpls forwarding-table 10.10.10.2 detail
Local     Outgoing  Prefix           Bytes Label   Outgoing   Next Hop  
Label     Label     or Tunnel Id     Switched     interface            
79         22         10.10.10.2/32 76109369     Vl10       10.9.9.1  
       MAC/Encaps=14/18, MRU=1500, Label Stack{22}

Pre-AGG#sh mpls forwarding-table 10.10.11.1 detail
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop  
Label     Label     or Tunnel Id     Switched     interface            
530       16020     10.10.11.1/32 20924900800   Vl10       10.9.9.1  
       MAC/Encaps=14/22, MRU=1496, Label Stack{22 16020}

Saídas do nó do núcleo ABR

O prefixo 10.10.11.1 é sabido através do intradomain IGP (ISIS-L2) e conforme a tabela do forwarding MPLS. É alcançável com LDP LSP.

ABR-Core2#sh ip route 10.10.11.1
Routing entry for 10.10.11.1/32
Known via "isis core-agg", distance 115, metric 20, type level-2
Installed Sep 12 21:13:03.673 for 2w3d
Routing Descriptor Blocks
   10.10.1.0, from 10.10.11.1, via TenGigE0/0/0/0, Backup
     Route metric is 0
   10.10.2.3, from 10.10.11.1, via TenGigE0/0/0/3, Protected
     Route metric is 20
No advertising protos.

Para a distribuição dos prefixos entre as áreas segmentadas, o BGP com a etiqueta (RFC 3107) é utilizado. Que necessidades de residir ainda dentro das áreas segmentadas do IGP são os laços de retorno dos PE e dos endereços relativos à infraestrutura central.

Os BGP Router que conectam áreas diferentes junto são os ABR que atuam como um refletor de rota BGP. Estes dispositivos usam a característica do Seguinte-Salto-auto, a fim evitar a necessidade de ter todos os saltos seguintes do sistema autônomo completo dentro do IGP, em vez somente dos endereços IP de Um ou Mais Servidores Cisco ICM NT dos PE e da infraestrutura central. A detecção do laço é terminada baseou no BGP Conjunto-ID.

Para a resiliência da rede, o BGP PIC com o BGP adiciona a característica do trajeto deve ser usado com BGP e LFA com IGP. Estas características não são usadas no exemplo anterior.

Troubleshooting

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

Informações Relacionadas



Document ID: 118846