Exemplo de funcionalidade, recursos e configuração do Unified MPLS
Contents
Introduction
Este documento descreve o Unified Multiprotocol Label Switching (MPLS), que é tudo sobre dimensionamento. Ele fornece uma estrutura de soluções de tecnologia para trazer tráfego e/ou serviços de ponta a ponta simples através de uma infraestrutura tradicionalmente segmentada. Ele usa os benefícios de uma infraestrutura hierárquica à medida que melhora a escalabilidade e a simplicidade do projeto de rede.
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.
Configurar
Evolução da rede
Quando você observa o histórico dos serviços baseados em pacotes de rede, uma alteração nos valores comerciais da rede pode ser observada. Isso vai de aprimoramentos de conectividade discretos para tornar os aplicativos o mais fluentes possível, até tecnologias de colaboração para dar suporte à colaboração móvel. Por fim, os serviços em nuvem sob demanda são apresentados com os serviços de aplicativos para otimizar as ferramentas usadas com uma empresa e melhorar a estabilidade e o custo de propriedade.
Figure 1
Esse valor contínuo e essa melhoria da funcionalidade da rede resultam em uma necessidade muito mais difundida de simplicidade, capacidade de gerenciamento, integração e estabilidade da rede, onde as redes foram segmentadas como resultado de ilhas operacionais desconectadas e nenhum controle de caminho real de ponta a ponta. Agora há uma necessidade de unir tudo isso com uma arquitetura única, fácil de gerenciar, que oferece escalabilidade para 100.000 de nós e usa as tecnologias atuais de alta disponibilidade e convergência rápida. Isso é o que o Unified MPLS traz à tabela, que é a rede segmentada em um único plano de controle e visibilidade de caminho de ponta a ponta.
Requisitos de rede modernos
- Aumentar a demanda de largura de banda (Vídeo)
- Aumentar a complexidade dos aplicativos (nuvem e virtualização)
- Aumento da necessidade de convergência (mobilidade)
Como você pode simplificar as operações de MPLS em redes cada vez maiores com requisitos de aplicativos mais complexos?
Desafios MPLS tradicionais com diferentes tecnologias de acesso
- Complexidade para alcançar a convergência de 50 milissegundos com o TE FRR (Traffic Engineering Fast Reroute, Reroteamento rápido de engenharia de tráfego)
- Necessidade de protocolos de roteamento sofisticados e interação com protocolos da camada 2
- Divida grandes redes em domínios enquanto os serviços são fornecidos de ponta a ponta
- Mecanismos comuns de convergência e resiliência de ponta a ponta
- Solucionar problemas e provisionar de ponta a ponta em vários domínios
A atração do Unified MPLS está resumida nesta lista:
- Número reduzido de pontos operacionais.
- Em geral, plataformas de transporte, um serviço deve ser configurado em cada elemento da rede através de Pontos Operacionais. O sistema de gerenciamento precisa conhecer a topologia.
- No Unified MPLS, com a integração de todas as ilhas MPLS, o número mínimo de pontos operacionais é atingido.
- Possibilidade de fornecer facilmente serviços: VPN de Camada 3 (L3), VPWS (Virtual Private Wire Service), VPLS (Virtual Private LAN Service), sem pseudowire-stitching (PW-stitching) ou mecanismos InterAS. Com a introdução do MPLS na agregação, alguma configuração estática é evitada, o que cria ilhas MPLS.
- Forneça transporte MPLS de ponta a ponta.
- Mantenha as áreas do Interior Gateway Protocol (IGP) separadas e pequenas tabelas de roteamento.
- Convergência rápida.
- Fácil de configurar e solucionar problemas.
- Capacidade de integração com qualquer tecnologia de acesso.
- Preparação para IPv6.
Cisco Unified MPLS
O Unified MPLS é definido pela adição de recursos extras com MPLS clássico/tradicional e oferece mais escalabilidade, segurança, simplicidade e gerenciabilidade. Para fornecer os serviços MPLS, é necessário um LSP (Label Switches Path, caminho de switches rotulados) fim-a-fim. 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.
Figure 2
Antes que a arquitetura do Cisco Unified MPLS seja discutida, é importante entender os principais recursos usados para tornar isso uma realidade.
Recursos e componentes
Informações de Rótulo de Transporte em BGP-4 (RFC 3107)
É um pré-requisito ter um método escalável para trocar prefixos entre segmentos de rede. Você pode simplesmente mesclar os IGPs (Open Shortest Path First, OSPF), IS-IS (Intermediate System-to-Intermediate System) ou EIGRP (Enhanced Interior Gateway Routing Protocol) em um único domínio. No entanto, um IGP não é projetado para transportar 100 mil prefixos. O protocolo preferido para essa finalidade é o BGP. É um protocolo bem comprovado que suporta a Internet com 100.000's de rotas e ambientes MPLS-VPN com milhões de entradas. O Cisco Unified MPLS usa o BGP-4 com RFC3107. Quando o BGP distribui uma rota, ele também pode distribuir um rótulo MPLS que é mapeado para essa rota. As informações de mapeamento de rótulo MPLS para a rota são transportadas na mensagem de atualização BGP que contém as informações sobre a rota. Se o salto seguinte não for alterado, o rótulo será preservado e o rótulo será alterado se o salto seguinte for alterado. No Unified MPLS, o próximo salto é alterado em Roteadores de borda de área (ABRs).
Quando você ativa o RFC 3107 em ambos os roteadores BGP, os roteadores anunciam uns aos outros que podem enviar rótulos MPLS com as rotas. Se os roteadores negociarem com êxito sua capacidade de enviar rótulos de MPLS, eles adicionarão rótulos de MPLS a todas as atualizações de BGP de saída.
A troca de rótulo é necessária para manter as informações de caminho de ponta a ponta entre os segmentos. Como resultado, cada segmento torna-se pequeno o suficiente para ser gerenciado pelos operadores e, ao mesmo tempo, há informações de circuito distribuídas para reconhecimento de caminho entre dois alto-falantes IP diferentes.
Como funciona?
Figure 3
Na Figura 3, você pode ver que há três segmentos com o Label Discovery Protocol Labeled Switches Path (LDP LSP) e que a rede de acesso não tem o LDP ativado. O objetivo é uni-los para que haja um único caminho MPLS (Internal BGP (iBGP) de LSP hierárquico) entre nós de pré-agregação (Pre-Agg). Como a rede é um sistema autônomo BGP (AS) único, todas as sessões são sessões iBGP. Cada segmento executa seus próprios caminhos IGP (OSPF, IS-IS ou EIGRP) e LDP LSP dentro do domínio IGP. No Cisco Unified MPLS, os roteadores (ABRs) que participam dos segmentos devem ser refletores de rota em linha BGP com o Next-Hop-Self e RFC 3107 para transportar um IPv4 + Label configurado nas sessões. Esses alto-falantes BGP estão dentro da arquitetura Cisco Unified MPLS referida como ABRs.
Por que os ABRs são refletores de rota em linha?
Um dos objetivos do Unified MPLS é ter uma infraestrutura de ponta a ponta altamente escalável. Assim, cada segmento deve ser mantido simples para operar. Todos os peerings são peerings iBGP, portanto, há necessidade de uma malha completa de peerings entre todos os alto-falantes iBGP dentro da rede completa. Isso resulta em um ambiente de rede muito impraticável se houver milhares de alto-falantes de BGP. Se os ABRs forem feitos refletores de rota, o número de peering do iBGP será reduzido ao número de alto-falantes BGP 'por segmento' em vez de entre 'todos' alto-falantes BGP do AS completo.
Por que o Next-Hop-Self?
O BGP opera com base em pesquisas de roteamento recursivas. Isso é feito para acomodar a escalabilidade dentro do IGP subjacente que é utilizado. Para a pesquisa recursiva, o BGP usa o Next-Hop anexado a cada entrada de rota BGP. Assim, por exemplo, se um nó de origem desejar enviar um pacote a um nó de destino e se o pacote atingir o roteador BGP, o roteador BGP realizará uma pesquisa de roteamento em sua tabela de roteamento BGP. Ele encontra uma rota em direção ao nó de destino e encontra o Next-Hop como uma próxima etapa. Esse Next-Hop deve ser conhecido pelo IGP subjacente. Como etapa final, o roteador BGP encaminha o pacote para a frente com base nas informações de rótulo IP e MPLS anexadas a esse Next-Hop.
Para garantir que dentro de cada segmento somente os Next-Hops sejam necessários para serem conhecidos pelo IGP, é necessário que o Next-Hop conectado à entrada BGP esteja dentro do segmento de rede e não dentro de um vizinho ou segmento distante. Se você regravar o Next-Hop do BGP com o recurso Next-Hop-Self, certifique-se de que o Next-Hop esteja dentro do segmento local.
Junte tudo
Figure 4
A Figura 4 fornece um exemplo de como o prefixo de VPN L3 'A' e a troca de rótulo operam e como a pilha de rótulo MPLS é criada para ter as informações de caminho fim-a-fim para o fluxo de tráfego entre os dois PEs.
A rede é particionada como três domínios IGP/LDP independentes. O tamanho reduzido das tabelas de roteamento e encaminhamento nos roteadores é permitir uma melhor estabilidade e convergência mais rápida. O LDP é usado para criar LSPs intradiários dentro de domínios. RFC 3107 Os rótulos de BGP IPv4+ são usados como protocolo de distribuição de rótulo entre domínios para criar LSPs de BGP hierárquicos entre domínios. O BGP3107 insere um rótulo extra na pilha de rótulos de encaminhamento na arquitetura Unified MPLS.
Intradomínio - LDP LSP
Interdomínio - LSP hierárquico de BGP
Figure 5
O prefixo de VPN 'A' é anunciado pelo PE31 para PE11 com o rótulo de serviço 30 da L3VPN e o salto seguinte como loopback do PE31 via LSP de BGP hierárquico entre domínios de ponta a ponta. Agora, examine o caminho de encaminhamento do prefixo de VPN 'A' de PE11 para PE31.
- No PE11, o Prefixo A é conhecido através da sessão BGP com PE31 como PE31 do próximo salto e PE31 é repetidamente alcançável via P1 com rótulo BGP 100. O PE11 recebeu informações de IPv4 + Rótulo de P1 como atualizações de BGP porque está ativado com o recurso RFC 3107 para enviar as informações de IPv4 + Rótulo.
- O P1 pode ser alcançado do PE11 por meio do LDP LSP intradomain e adiciona outro rótulo LDP na parte superior do rótulo BGP. Finalmente, o pacote sai do nó PE11 com três rótulos. Por exemplo, o rótulo de serviço 30 L3VPN, o rótulo 100 BGP e o rótulo 200 LDP IGP.
- O rótulo superior do LDP continua a ser trocado em LDP LSP intradomain e o pacote chega a P1 com duas etiquetas após o Penúltimo Hop Popping (PHP).
- P1 é configurado como Refletor de rota em linha (RR - Inline Route Reflector) com o próprio próximo salto e une dois domínios IGP ou LDP.
- No P1, o próximo salto para PE31 é alterado para P2 e a atualização é recebida via BGP com IPv4 + Rótulo (RFC3107). O rótulo BGP é trocado por um novo rótulo porque o próximo salto é alterado e o rótulo IGP é impresso no topo.
- O pacote sai do nó P1 com três rótulos e o rótulo de serviço 30 não é tocado. Ou seja, o rótulo de serviço 30 L3VPN, o rótulo 101 BGP e o rótulo 201 LDP.
- O LDP top label é alternado no LDP LSP do Intradomain e o pacote chega a P2 com dois rótulos depois do PHP.
- No P2, o próximo salto para PE31 é alterado novamente e pode ser alcançado via IGP. O rótulo BGP é removido como um rótulo de BGP implícito-nulo é recebido do PE31 para PHP.
- O pacote sai com dois rótulos. Por exemplo, o rótulo de serviço 30 L3VPN e o rótulo 110 LDP.
- No PE31, o pacote chega com um rótulo após o PHP da etiqueta LDP e baseado na etiqueta de serviço 30. O pacote não rotulado é encaminhado ao destino CE31 em Virtual Routing and Forwarding (VRF).
Quando você olha para a pilha de rótulos MPLS, a comutação do pacote entre um dispositivo de origem e de destino com base no prefixo anterior e na troca de rótulo é observada no ambiente de comutação MPLS.
Figura 6
Convergência independente de prefixo BGP (BGP PIC)
Essa é uma tecnologia da Cisco usada em cenários de falha de BGP. A rede converge sem perda dos segundos tradicionais na reconvergência de BGP. Quando o BGP PIC é usado, a maioria dos cenários de falha pode ser reduzida para um tempo de reconvergência abaixo de 100 ms.
Como isso é feito?
Tradicionalmente, quando o BGP detecta uma falha, ele recalcula para cada entrada de BGP para o melhor caminho. Quando há uma tabela de roteamento com milhares de entradas de rota, isso pode levar um tempo considerável. Além disso, esse roteador BGP precisa distribuir todos esses novos melhores caminhos para cada um de seus vizinhos para informá-los da topologia de rede alterada e dos melhores caminhos alterados. Como etapa final, cada um dos alto-falantes BGP do destinatário precisa fazer um cálculo do melhor caminho para encontrar os novos melhores caminhos.
Sempre que o primeiro locutor BGP detecta algo errado, ele inicia o cálculo do melhor caminho até que todos os seus locutores BGP vizinhos tenham feito seu recálculo, o fluxo de tráfego pode ser descartado.
Figura 7
O recurso BGP PIC para IP e VPN MPLS melhora a convergência de BGP após uma falha de rede. Essa convergência é aplicável a falhas de núcleo e borda e pode ser usada em redes IP e MPLS. O BGP PIC para IP e o recurso VPN MPLS cria e armazena um caminho alternativo/de backup na base de informações de roteamento (RIB), na base de informações de encaminhamento (FIB) e no Cisco Express Forwarding (CEF) de modo que quando uma falha é detectada, o caminho alternativo/de backup pode assumir imediatamente, permitindo assim um failover rápido.
Com uma única reescrita das informações do próximo salto, o fluxo de tráfego é restaurado. Além disso, a convergência do BGP de rede acontece em segundo plano, mas os fluxos de tráfego não são mais afetados. Esta reescrita acontece em 50 ms. Se você usar essa tecnologia, a convergência de rede será reduzida para de segundos para 50 ms mais a convergência IGP.
Add-Path BGP
O BGP Add-Path é uma melhoria em como as entradas BGP são comunicadas entre os alto-falantes BGP. Se em um determinado alto-falante BGP há mais de uma entrada para um determinado destino, então esse alto-falante BGP envia somente a entrada que é o melhor caminho para esse destino para seus vizinhos. O resultado é que não são feitas provisões para permitir o anúncio de vários caminhos para o mesmo destino.
O Add-Path BGP é um recurso BGP para permitir mais como o melhor caminho e permite vários caminhos para o mesmo destino sem os novos caminhos substituírem implicitamente os anteriores. Esta extensão para o BGP é particularmente importante para ajudar com o BGP PIC, quando os refletores de rota BGP são usados, para que os diferentes alto-falantes BGP dentro de um AS tenham acesso a mais caminhos BGP como apenas o 'Melhor caminho BGP' de acordo com o refletor de rota.
Alternativas sem loop e rLFA para convergência rápida IGP
As operações para alcançar a restauração de 50 milissegundos após uma falha de link ou nó podem ser simplificadas drasticamente com a introdução de uma nova tecnologia chamada alternados sem loops (LFAs). O LFA aprimora os protocolos de roteamento link-state (IS-IS e OSPF) para encontrar caminhos de roteamento alternativos sem loops. O LFA permite que cada roteador defina e use um caminho de backup predeterminado se uma adjacência (nó ou link de rede) falhar. Para fornecer um tempo de restauração de 50 ms em caso de falhas de link ou nó, o FRR TE MPLS pode ser implantado. No entanto, isso exige a adição de outro protocolo (Resource Reservation Protocol, ou RSVP) para a configuração e o gerenciamento de túneis TE. Embora isso possa ser necessário para o gerenciamento da largura de banda, a operação de proteção e restauração não exige o gerenciamento da largura de banda. Portanto, a sobrecarga associada à adição de TE RSVP é considerada alta para proteção simples de links e nós.
O LFA pode fornecer uma técnica simples e fácil sem a implantação do RSVP TE nesses cenários. Como resultado dessas técnicas, os roteadores interconectados atuais em redes de grande escala podem fornecer restauração de 50 ms para falhas de link e nó sem um requisito de configuração para o operador.
Figura 8
O LFA-FRR é um mecanismo que fornece proteção local para tráfego unicast em IP, MPLS, Ethernet sobre MPLS (EoMPLS), Multiplexação Inversa sobre ATM (IMA) sobre MPLS, Serviço de Emulação de Circuito sobre Rede Comutada de Pacotes (CESoPSN) sobre MPLS e Multiplexação por Divisão de Tempo Agnóstico sobre Pacotes (SAT) oP) em redes MPLS. No entanto, algumas topologias (como a topologia em anel) exigem proteção que não é oferecida somente pelo LFA-FRR. O recurso LFA-FRR remoto é útil nessas situações.
O LFA-FRR remoto estende o comportamento básico do LFA-FRR para qualquer topologia. Encaminha o tráfego em torno de um nó com falha para um LFA remoto que está a mais de um salto de distância. Na Figura 9, se o link entre C1 e C2 falhar ao acessar A1, o C2 envia o pacote por uma sessão LDP direcionada para o C5 que tem acessibilidade para A1.
Figura 9
No LFA-FRR remoto, um nó calcula dinamicamente seu nó LFA. Depois que o nó alternativo é determinado (que não está diretamente conectado), o nó estabelece automaticamente uma sessão de Protocolo de Distribuição de Rótulo (LDP - Label Distribution Protocol) direcionada para o nó alternativo. A sessão de LDP direcionada troca rótulos para a correção de erro de encaminhamento específica (FEC).
Quando o link falha, o nó usa empilhamento de rótulo para fazer o túnel do tráfego para o nó LFA remoto, a fim de encaminhar o tráfego para o destino. Todas as trocas de rótulo e o tunelamento para o nó LFA remoto são de natureza dinâmica e o pré-provisionamento não é necessário. Todo o mecanismo de troca de rótulo e tunelamento é dinâmico e não envolve nenhum provisionamento manual.
Para LSPs intradiários, o FRR LFA remoto é utilizado para tráfego MPLS unicast em topologias de anel. O FRR LFA remoto precalcula um caminho de backup para cada prefixo na tabela de roteamento IGP, o que permite que o nó mude rapidamente para o caminho de backup quando uma falha é encontrada. Isso fornece tempos de recuperação na ordem de 50 ms.
Exemplo de arquitetura do Cisco Unified MPLS
Quando todas as ferramentas e recursos anteriores são reunidos em um ambiente de rede, ele cria o ambiente de rede Cisco Unified MPLS. Este é o exemplo de arquitetura para grandes provedores de serviços.
Figura 10
- O núcleo e a agregação são organizados como domínios IGP/LDP distintos.
- LSPs hierárquicos entre domínios com base em RFC 3107, Rótulos IPv4+ BGP que são estendidos para o Pre-Agg.
- LSPs intradiários baseados em LDP.
- Os LSPs Núcleo/Agregação entre domínios são estendidos nas Redes de Acesso pela distribuição do Interior Gateway Protocol (RAN IGP) das Redes de Acesso de Rádio no iBGP entre domínios e distribuem os prefixos iBGP (gateway MPC (Mobile Packet Core) necessários) no IGP RAN (através de comunidades BGP).
Exemplo de configuração de MPLS unificado
Aqui está um exemplo simplificado do Unified MPLS.
Roteador de borda de área central - Cisco IOS® XR
Roteadores de Gateway de Local de Célula e Pré-Agregação - Cisco IOS
Figura 11
| 200:200 | Comunidade MPC |
| 300:300 | Comunidade de agregação |
| Domínio IGP central | ISIS Nível 2 |
| Domínio IGP de agregação | ISIS Nível 1 |
| Domínio IGP de acesso | Áreas OSPF 0 |
Configuração do roteador de borda de área central
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
ibgp policy out enforce-modifications
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 de pré-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
ibgp policy out enforce-modifications
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 (300:300)
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 Cell Site Gateway (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 de 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
ibgp policy out enforce-modifications
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 de loopback do Mobile Packet Gateway (MPG) é 10.10.11.1/32, portanto, esse prefixo é de interesse. Agora, veja como os pacotes são encaminhados do CSG para o MPG.
O prefixo MPC 10.10.11.1 é conhecido pelo roteador CSG de Pre-agg com a tag de rota 1000 e pode ser encaminhado como um pacote rotulado com a identificação LDP de saída 31 (LDP de domínio). A comunidade MPC 200:200 foi mapeada com a tag de rota 1000 no nó Pré-agregação enquanto a redistribuição está no OSPF.
Saída de 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 de nó pré-agregação
No nó de pré-agregação, o prefixo MPC é redistribuído do BGP para o processo de acesso de RAN OSPF com filtragem baseada na comunidade e o processo OSPF é redistribuído no BGP. Essa redistribuição controlada é necessária para tornar o IP acessível de ponta a ponta, ao mesmo tempo em que cada segmento tem rotas mínimas exigidas.
O prefixo 10.10.11.1/32 é conhecido por meio de um BGP hierárquico 100 com a comunidade MPC 200:200 anexada. O rótulo 16020 BGP 3107 recebido do Roteador de Borda de Área (ABR - Area Border Router) central e o rótulo LDP 22 é adicionado na parte superior para o encaminhamento intradomínio após a pesquisa recursiva do próximo salto.
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}
Principais saídas de nó ABR
O prefixo 10.10.11.1 é conhecido através do IGP intradomain (ISIS-L2) e de acordo com a tabela de encaminhamento MPLS. Ele pode ser acessado por meio do 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, é utilizado o BGP com o rótulo (RFC 3107). O que precisa residir ainda dentro das áreas segmentadas do IGP são os loopbacks dos PEs e endereços relacionados à infraestrutura central.
Os roteadores BGP que conectam diferentes áreas juntas são os ABRs que atuam como um Refletor de Rota BGP. Esses dispositivos usam o recurso Next-Hop-Self, para evitar a necessidade de ter todos os Next-Hops do Sistema Autônomo completo dentro do IGP, em vez de apenas os endereços IP dos PEs e da infraestrutura central. A detecção de loop é concluída com base nos IDs de cluster do BGP.
Para resiliência de rede, o BGP PIC com o recurso BGP Add Path deve ser usado com BGP e LFA com IGP. Esses recursos não são usados no exemplo anterior.
Troubleshoot
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.
Feedback