Configuração de engenharia de tráfego baseada em cores
SUMMARY
Visão geral dos planos de transporte com classe BGP
- Benefícios dos planos de transporte com classe BGP
- Os planos de transporte com classe BGP da OMP
- Entenda os planos de transporte com classe BGP
- Implementação intra-AS de planos de transporte com classe BGP
- Implementação inter-AS de planos de transporte com classe BGP
- Transporte classful BGP (BGP-CT) com visão geral dos túneis SR-TE coloridos subjacentes
- Benefícios do BGP-CT com túneis SR-TE coloridos subjacentes
Benefícios dos planos de transporte com classe BGP
-
Fatiamento de rede — as camadas de serviço e transporte são desacopladas entre si, estabelecendo as bases para o fatiamento e a virtualização de rede com o fatiamento de ponta a ponta em vários domínios, reduzindo significativamente o CAPEX.
- Interoperabilidade entre domínios — estende a implantação da classe de transporte em domínios de cooperação para que os diferentes protocolos de sinalização de transporte em cada domínio interoperem. Concilia quaisquer diferenças entre namespaces estendidos da comunidade que podem estar em uso em cada domínio.
-
Resolução colorida com fallback — permite a resolução sobre túneis coloridos (RSVP, algoritmo flexível IS-IS) com opções flexíveis de fallback em túneis de melhor esforço ou qualquer outro túnel de cor.
- Qualidade de serviço — personaliza e otimiza a rede para alcançar os requisitos de SLA de ponta a ponta.
- Aproveitamento das implantações existentes — oferece suporte a protocolos de tunelamento bem implantados, como o RSVP, juntamente com novos protocolos, como o algoritmo flexível IS-IS, preservando o ROI e reduzindo o OPEX.
Os planos de transporte com classe BGP da OMP
Esta seção fornece um resumo dos termos comumente usados para entender o plano de transporte com classe BGP.
-
Nó de serviço — dispositivos de borda de provedor de entrada (PE) que enviam e recebem rotas de serviço (Internet e VPN de Camada 3).
-
Nó de borda — Dispositivo no ponto de conexão de diferentes domínios (áreas de IGP ou ASs).
-
Nó de transporte — Dispositivo que envia e recebe rotas Unicast (LU) com rótulo BGP.
-
BGP-VPN- VPNs criadas usando mecanismos RFC4364.
-
Alvo de rota (RT)— Tipo de comunidade estendida usada para definir a associação de VPN.
-
Route Distinguisher (RD)— Identificador usado para distinguir qual VPN ou serviço de LAN privada virtual (VPLS) pertence. Cada instância de roteamento deve ter um diferencial de rota único associado a ela.
- Esquema de resolução — usado para resolver o endereço de próximo salto (PNH) de protocolo em RIBs de resolução que fornecem fallback.
Eles mapeiam as rotas para os diferentes RIBs de transporte no sistema com base na comunidade de mapeamento.
-
Família de serviços — família de endereços BGP usada para rotas de publicidade para tráfego de dados, em vez de túneis.
-
Família de transporte — família de endereços BGP usada para túneis de publicidade, que por sua vez são usados por rotas de serviço para resolução.
-
Túnel de transporte — um túnel sobre o qual um serviço pode colocar tráfego, por exemplo, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.
-
Domínio de túnel — um domínio da rede que contém nós de serviço e nós de borda sob um único controle administrativo que tem um túnel entre eles. Um túnel de ponta a ponta que abrange vários domínios de túneis adjacentes pode ser criado costurando os nós usando rótulos.
-
Classe de transporte — um grupo de túneis de transporte que oferecem o mesmo tipo de serviço.
Classe de transporte RT- Um novo formato de alvo de rota usado para identificar uma classe de transporte específica.
Um novo formato de Route Target usado para identificar uma classe de transporte específica.-
Transporte RIB — No nó de serviço e nó de fronteira, uma classe de transporte tem uma RIB de transporte associada que detém suas rotas de túnel.
-
Instância de roteamento RTI de transporte; contêiner de transporte RIB, e categoria de transporte associada Route Target e Route Distinguisher.
-
Plano de transporte — Conjunto de RTIs de transporte importando RT da mesma classe de transporte. Estes são, por sua vez, costurados para abranger os limites do domínio do túnel usando um mecanismo semelhante à opção-b Inter-AS para trocar rótulos em nós de fronteira (nexthop-self), formando um plano de transporte de ponta a ponta.
-
Mapeamento da comunidade — Comunidade em uma rota de serviço que mapeia para resolver em uma aula de transporte.
Entenda os planos de transporte com classe BGP
Você pode usar planos de transporte com classe BGP para configurar aulas de transporte para classificar um conjunto de túneis de transporte em uma rede intra-AS com base nas características de engenharia de tráfego e usar esses túneis de transporte para mapear rotas de serviço com o SLA desejado e o recuo desejado.
Os planos de transporte com classe BGP podem estender esses túneis para redes entre domínios que se estendem por vários domínios (ASs ou áreas de IGP) ao mesmo tempo em que preservam a classe de transporte. Para isso, você deve configurar a família BGP de camada de transporte de transporte com classe BGP entre a borda e os nós de serviço.
Em implementações entre AS e intra-AS, pode haver muitos túneis de transporte (MPLS LSPs, algoritmo flexível IS-IS, SR-TE) criados a partir do serviço e nós de fronteira. Os LSPs podem ser sinalizados usando diferentes protocolos de sinalização em diferentes domínios e podem ser configurados com diferentes características de engenharia de tráfego (classe ou cor). O endpoint do túnel de transporte também atua como endpoint de serviço e pode estar presente no mesmo domínio de túnel que o nó de entrada de serviço, ou em um domínio adjacente ou não adjacente. Você pode usar planos de transporte com classe BGP para redirecionar serviços em LSPs com certas charaterísticas de engenharia de tráfego, seja dentro de um único domínio ou em vários domínios.
Os planos de transporte com classe BGP reutilizam a tecnologia BGP-VPN, mantendo os domínios de tunelamento livremente acoplados e coordenados.
- As informações de alcance da camada de rede (NLRI) são RD:TunnelEndpoint usado para ocultação de caminhos.
- O alvo da rota indica a classe de transporte dos LSPs, e vazamentos de rotas para o RIB de transporte correspondente no dispositivo de destino.
- Cada protocolo de tunelamento de transporte instala uma rota de entrada na tabela de roteamento transport-class.inet.3, modela a classe de transporte de túneis como um alvo de rota VPN e coleta os LSPs da mesma classe de transporte na tabela de roteamento transport-class.inet.3.
-
As rotas nesta instância de roteamento são anunciadas no plano de transporte com classe BGP (transporte de inet) AFI-SAFI seguindo procedimentos semelhantes ao RFC-4364.
-
Ao cruzar o limite do enlace entre AS, você deve seguir os procedimentos de Opção b para costurar os túneis de transporte nesses domínios adjacentes.
Da mesma forma, ao atravessar as regiões intra-AS, você deve seguir os procedimentos de Opção b para costurar os túneis de transporte nos diferentes domínios de TE.
-
Você pode definir esquemas de resolução para especificar a intenção na variedade de classes de transporte em uma ordem de recuo.
- Você pode resolver rotas de serviço e rotas de transporte com classe BGP nessas aulas de transporte, abordando a comunidade de mapeamento sobre elas.
A família de transporte com classe BGP é operada junto com a família de camada de transporte BGP-LU. Em uma rede MPLS perfeita que executa o BGP-LU, atender a requisitos SLA rigorosos do 5G é um desafio, pois as características de engenharia de tráfego dos túneis não são conhecidas ou preservadas em todos os limites do domínio. Os planos de transporte com classe BGP oferecem meios operacionais fáceis e escaláveis para anunciar vários caminhos para loopbacks remotos, juntamente com as informações da classe de transporte na arquitetura MPLS perfeita. Nas rotas familiares de transporto com classe BGP, diferentes caminhos SLA são representados usando a comunidade estendida Transport Route-Target, que leva a cor da classe de transporte. Este Transport Route-Target é usado pelos roteadores BGP que recebem para associar a rota de transporte com classe BGP à classe de transporte apropriada. Ao anunciar novamente as rotas de transporte com classe BGP, o MPLS troca rotas, inter conecta os túneis intra-AS da mesma classe de transporte, formando assim um túnel de ponta a ponta que preserva a classe de transporte.
Implementação intra-AS de planos de transporte com classe BGP
Figura 1 ilustra uma topologia de rede com cenários de antes e depois da implementação de planos de transporte com classe BGP em um domínio intra-AS. Os dispositivos PE11 e PE12 usam LSPs RSVP como túnel de transporte e todas as rotas de túnel de transporte estão instaladas no inet.3 RIB. A implementação de planos de transort com classe BGP permite que os túneis de transporte RSVP sejam conscientes de cores semelhantes aos túneis de roteamento por segmentos.
Para classificar os túneis de transporte na classe de transporte BGP em uma configuração intra-AS:
- Defina a classe de transporte no nó de serviço (dispositivos PE de entrada), por exemplo, ouro e bronze, e atribua valores de comunidade de cores à classe de transporte definida.
Configuração da amostra:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Associe o túnel de transporte a uma classe de transporte específica no nó de entrada dos túneis.
Configuração da amostra:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
Funcionalidade de plano de transporte com classe BGP intra-AS:
- O transporte com classe BGP cria RIBs de transporte predefinidos por classe de transporte nomeada (ouro e bronze) e automaticamente deriva a comunidade de mapeamento a partir de seu valor de cor (100 e 200).
- As rotas de transporte intra-AS são povoadas em RIBs de transporte pelo protocolo de tunelamento quando estão associadas a uma classe de transporte.
Neste exemplo, as rotas RSVP LSP associadas à classe de transporte ouro (cor 100) e bronze da classe de transporte (cor 200) são instaladas no transporte RIBs junos-rti-tc-<100>.inet.3 e junos-rti-tc-<200>.inet.3, respectivamente.
- O nó de serviço (PEs de entrada) combina com a comunidade de cores estendida (cor:0:100 e cor:0:200) da rota de serviço contra a comunidade de mapeamento em RIBs de resolução predefinida e resolve o protocolo next hop (PNH) em RIBs de transporte correspondentes (junos-rti-tc-<100>.inet.3, ou junos-rti-tc-<200>.inet.3).
- As rotas BGP se ligam a um esquema de resolução transportando a comunidade de mapeamento assiocato.
- Cada classe de transporte cria automaticamente dois esquemas de resolução predefinidos e deriva automaticamente da comunidade de mapeamento.
Um esquema de resolução é para a resolução de rotas de serviço que usam o Color:0:<val> como a comunidade de mapeamento.
O outro esquema de resolução é para a resolução de rotas de transporte que utilizam o Transport-Target:0:<val> como a comunidade de mapeamento.
- Se o PNH de rota de serviço não puder ser resolvido usando RIBs listados no esquema de resolução predefinido, ele pode voltar à tabela de roteamento inet.3.
- Você também pode configurar o fallback entre diferentes RIBs de transporte coloridos usando esquemas de resolução definidos pelo usuário sob a hierarquia de [edit routing-options resolution scheme] configuração.
Implementação inter-AS de planos de transporte com classe BGP
Em uma rede inter-AS, o BGP-LU é convertido em rede de transporte com classe BGP depois de configurar um mínimo de duas classes de transporte (ouro e bronze) em todos os nós de serviço ou dispositivos PE e nós de borda (ABRs e ASBRs).
Para converter os túneis de transporte em transporte com classe BGP:
- Defina a classe de transporte nos nós de serviço (dispositivos pe de entrada) e nos nós de borda (ABRs e ASBRs), por exemplo, ouro e broze.
Configuração da amostra:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Associe os túneis de transporte a uma classe de transporte específica no nó de entrada dos túneis (PEs de entrada, ABRs e ASBRs).
Configuração da amostra:
Para RSVP LSPs
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;Para algoritmos flxáveis IS-IS
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; } - Habilite uma nova família para o transporte com classe BGP (transporte de inet) e BGP-LU (inet labeled-unicast) na rede.
Configuração da amostra:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; } - Anuncie rotas de serviço a partir do dispositivo PE de saída com a comunidade de cores estendida apropriada.
Configuração da amostra:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
Funcionalidade de plano de transporte com classe BGP entre AS:
- Os planos de transporte com classe BGP criam RIBs de transporte predefinidos por classe de transporte nomeada (ouro e bronze) e automaticamente derivam a comunidade de mapeamento de seu valor de cor.
-
As rotas de transporte intra-AS são povoadas em RIBs de transporte por protocolos de tunelamento quando associadas a uma classe de transporte.
Por exemplo, as rotas de túnel de transporte associadas à classe de transporte ouro e bronze estão instaladas no junos-rti-tc-<100>.inet.3 e junos-rti-tc-<200>.inet.3, respectivamente.
- Os planos de transporte com classe BGP usam o diferencial de rota exclusivo e o alvo de rota quando ele copia as rotas de túnel de transporte de cada RIB de transporte para a tabela de roteamento bgp.transport.3.
- Nós de fronteira anunciam rotas da tabela de roteamento bgp.transport.3 para seus pares em outros domínios se o transporte de inet familiar for negociado na sessão BGP.
- Receber nó de borda instala essas rotas bgp-ct na tabela de roteamento bgp.transport.3 e copia essas rotas com base no alvo de rota de transporte para as RIBs de transporte apropriadas.
- O nó de serviço corresponde à comunidade de cores na rota de serviço em relação a uma comunidade de mapeamento nos esquemas de resolução e resolve PNH na RIB de transporte correspondente ( junos-rti-tc-<100>.inet.3 ou junos-rti-tc-<200>.inet.3).
- Os nós de fronteira usam esquemas de resolução predefinidos para a resolução de PNH da rota de transporte.
- Predefinidos ou definidos pelo usuário, ambos os esquemas de resolução oferecem suporte à resolução de PNH de rota de serviço. O inet.3 predefinido usa como fallback e o esquema de resolução definido pelo usuário permite que a lista de RIBs de transporte seja usada na ordem especificada enquanto resolve o PNH.
- Se o PNH de rota de serviço não puder ser resolvido usando RIBs listados no esquema de resolução definido pelo usuário, então a rota será descartada.
Transporte classful BGP (BGP-CT) com visão geral dos túneis SR-TE coloridos subjacentes
Benefícios do BGP-CT com túneis SR-TE coloridos subjacentes
- Resolve preocupações de escala que podem surgir no futuro à medida que a rede cresce.
- Oferece interconectividade para domínios que usam tecnologias diferentes.
- Desacopla serviços e as camadas de transporte que resultam em uma rede completamente distribuída.
- Oferece gerenciamento independente de largura de banda por meio de um controlador de engenharia de tráfego intra-domínio para SR-TE.
Redes de grande porte que estão crescendo e evoluindo continuamente exigem uma arquitetura de roteamento por segmentos consistente. A partir do Junos OS Release 21.2,R1 oferecemos suporte ao BGP-CT com transporte subjacente como túneis SR-TE coloridos. O BGP-CT pode resolver rotas de serviço usando as RIBs de transporte e computar o próximo salto. Os serviços que atualmente são suportados no BGP-CT também podem usar os túneis coloridos SR-TE subjacentes para resolução de rotas. Os serviços agora podem usar os túneis coloridos SR-TE subjacentes, como os túneis coloridos estáticos, BGP SR-TE, rpd programável e túneis coloridos de PCEP. O BGP-CT usa a acessibilidade de próximo salto para resolver rotas de serviço na classe de transporte desejada.
Para permitir a resolução de rota de serviço BGP-CT em túneis coloridos sr-TE subjacentes, inclua a use-transport-class declaração no nível de [edit protocols source-packet-routing] hierarquia.
- Habilite a
use-transport-classdeclaraçãono nível hierárquicos
juntamente com a[edit protocols source-packet-routing].auto-createdeclaração no nível hierárquica[edit routing-options transport-class]. - Não oferecemos suporte a grupos RIB para SR-TE colorido com
use-transport-classtúneis SR-TE coloridos e coloridos com este recurso.
Exemplo: Configuração de planos de transporte com classe (Intra-Domain)
- Antes de começar
- Visão geral funcional
- Visão geral da topologia
- Ilustrações de topologia
- Etapas de configuração do PE1
- Verifique planos de transporte com classe
- Apêndice 1: Solução de problemas
- Apêndice 2: Definir comandos em todos os dispositivos
- Apêndice 3: Mostrar saída de configuração em PE1
Antes de começar
| Requisitos de hardware e software |
Versão Junos OS 21.1R1 ou posterior. Nota:
Apenas os roteadores de borda do provedor (PE1 e PE2) exigem suporte de versão do Junos OS para o recurso BGP-CT. |
|
Tempo de leitura estimado |
45 minutos |
|
Tempo de configuração estimado |
1 hora |
|
O que esperar? |
Uma rede BGP-CT em funcionamento com três níveis de serviço que mapeiam caminhos LSP roteado de forma diversificada. Uma configuração do Junos que mapeia tráfego específico (rotas de clientes VPN) para a classe de transporte desejada usando atributos coloridos BGP de comunidades estendidas. Engenharia de tráfego LSP básica para forçar as aulas de tráfego a caminhos diversos na rede do provedor |
|
Impacto nos negócios |
Use este exemplo de configuração para configurar e verificar o recurso BGP Classful Transport (BGP-CT) em uma única rede autônoma (intra-domínio). O BGP-CT mapeia as rotas dos clientes para caminhos de rede que podem ser projetados para fornecer diferentes níveis de desempenho. Um caso de uso típico para BGP-CT intra-domínio é que um provedor de serviços implante o BGP-CT para oferecer níveis de serviço VPN hierárquicos aos seus clientes. |
|
Recursos úteis: |
|
|
Saiba mais |
Para entender melhor o BGP-CT, veja a visão geral dos planos de transporte com classe BGP |
|
Juniper vLabs |
Visite os laboratórios virtuais da Juniper (vLabs) para reservar uma sandbox pré-configurada. Use a caixa de areia para interagir e entender o recurso BGP-CT. Você encontrará a demonstração "Planos de transporte com classe (cenário intra-domínio)" na seção de roteamento. |
|
Saiba mais |
Classe de serviço (JCOS) do Junos sob demanda |
Visão geral funcional
Tabela 1 fornece um resumo rápido dos componentes de configuração implantados neste exemplo.
|
Protocolos de roteamento e sinalização |
|
|
OSPF |
Todos os roteadores executam OSPF como IGP. Todos os roteadores pertencem à área 0 (também chamada de área de backbone). O único domínio de roteamento OSPF oferece conectividade de loopback na rede do provedor. |
|
BGP interno e externo |
Os dispositivos de borda do cliente (CE) usam peering EBGP para trocar rotas com seu dispositivo de borda de provedor como parte de um serviço VPN de Camada 3. Os dispositivos PE usam o IBGP para trocar rotas de VPN de Camada 3 IPv4 com o PE remoto. Essas rotas também transportam uma comunidade de cores usada para mapear o tráfego para o túnel correto do plano de dados. Nosso exemplo não usa um refletor de rota, optando pelo peering direto de PE-PE. Nota:
O roteador de provedor (roteador P) não executa BGP. Faz parte de um núcleo sem BGP para promover o dimensionamento. O dispositivo P usa comutação baseada em rótulo MPLS para transportar o tráfego vpn do cliente entre os dispositivos PE. |
|
RSVP |
Cada dispositivo PE sinaliza três LSPs para o PE remoto. Esses LSPs mapeiam as classes de serviço correspondentes de ouro, bronze e melhor esforço (BE). O RSVP oferece suporte a uma engenharia de tráfego rica para forçar o tráfego em caminhos desejados na rede do provedor. Esses caminhos, por sua vez, podem ser projetados para fornecer tratamento de classe de serviço (CoS) variável que precisa para aplicar o SLA para cada classe de transporte. Nossa topologia básica oferece três caminhos entre os dispositivos pe. Usamos um caminho nomeado com um ERO para garantir um roteamento diversificado dos LSPs sobre o núcleo. O Junos oferece suporte a um amplo conjunto de recursos para a engenharia de tráfego. Para obter mais informações, veja Configuração da engenharia de tráfego MPLS Nota:
O recurso de transporte de classe também é suportado com LSPs estabelecidos por meio de roteamento por segmentos — engenharia de tráfego (SR-TE) e túneis flex-algoritmo IS-IS. |
|
MPLS |
A rede do provedor usa um plano de dados de comutação de rótulos baseado em MPLS. O uso de MPLS com caminhos TE garante que cada classe de serviço possa ser roteada em caminhos desarticulados com os níveis de desempenho desejados. Como observado acima, o MPLS também oferece suporte para um núcleo sem BGP. |
| Túneis de transporte | |
|
Três túneis MPLS (LSPs) estão estabelecidos entre os dispositivos PE: |
Cada túnel é atribuído às seguintes aulas de transporte:
|
| Família de serviços | |
|
VPN de camada 3 ( |
O BGP-CT também trabalha com outras famílias de serviços, como a Unicast, Flowspec ou VPN de Camada 2. |
| Tarefas primárias de verificação | |
|
Verifique o trabalho de IGP, RSVP, MPLS, BGP e L3VPN. |
|
Modifique a rede para efetivar o direcionamento de tráfego entre túneis de classe de transporte para simular a falha de um túnel de serviço e, posteriormente, falhar no caminho/classe BE. |
Visão geral da topologia
Este exemplo de configuração é baseado em uma VPN simples de Camada 3 baseada em MPLS com dois dispositivos de borda do cliente (CE) que se comunicam pela rede do provedor de serviços. O núcleo de rede tem três roteadores de provedor (P) que transportam o tráfego do cliente vpn usando comutação baseada em rótulos. Os dispositivos de borda (PE) de dois provedores oferecem um serviço VPN de Camada 3 aos seus CEs conectados. Os PEs usam RSVP sinalizado MPLS LSPs para transportar o tráfego de VPN pelo núcleo. Veja Example: Configure a Basic MPLS-Based Layer 3 VPN informações de fundo sobre a operação e configuração de uma L3VPN baseada em MPLS.
Focamos no fluxo de tráfego da esquerda para a direita do CE1 para o CE2, e como o PE1 usa uma comunidade de cores BGP anexada a rotas aprendidas com PE2 para mapear o tráfego enviado ao CE remoto sobre o encaminhamento de LSP desejado nos próximos saltos. Em nosso exemplo, o PE1 usa objetos de rota explícitos (ERO) para forçar o roteamento desses LSPs por diversos caminhos. Ignoramos essa etapa no PE2, permitindo que os LSPs sejam roteados com base no balanceamento de carga do IGP. Para ter fluxo de tráfego do CE1 para o CE2, o CE1 precisa ter uma rota para chegar ao CE2. As rotas para CE2 viajam na direção oposta do tráfego que atrai do CE1. Ou seja, a rota para o loopback do CE2 viaja da direita para a esquerda.
Em nosso exemplo, o LSP da classe de serviços de ouro está limitado ao caminho PE1-P1-PE2. A classe de serviços de bronze usa o caminho PE1-P2-PE2. O LSP de melhor esforço é roteado ao longo do caminho PE1-P3-PE2. O diagrama de topologia usa links coloridos para representar os três caminhos.
Em nosso exemplo, adicionamos a protocols mpls icmp-tunneling declaração. Isso é para permitir que os dispositivos CE rastreiem o caminho pela rede do provedor, mesmo quando esse caminho envolve a comutação MPLS, como é o caso do tráfego VPN de Camada 3. Essa opção ajuda você a confirmar o caminho de encaminhamento esperado em função da classe de transporte.
Tabela 2 descreve a função e a funcionalidade de cada dispositivo no contexto dessa topologia. Clique em qualquer nome do dispositivo para visualizar sua configuração rápida.
| Nome do dispositivo |
Função |
Função |
| CE1 | Dispositivo CE local (R1) . | Roteador EBGP peer para PE1 para anunciar e aprender endereços de loopback de dispositivo CE. Teste a conectividade de serviços com pings no endereço de loopback do CE2. |
| CE2 | Dispositivo CE remoto (R7) | Peering EBGP para roteador PE2 para anunciar e aprender endereços de loopback de dispositivo CE. Configura e conecta a comunidade de mapeamento de cores. |
| PE1 (DUT) | dispositivo PE local (R2). | O PE1 mapeia as rotas de serviço com tags coloridas que se originam no CE2 para uma classe de transporte de cosponsoring (TC). O PE1 recebe as rotas de tags de cor em sua sessão do IBGP para PE2. Neste exemplo, o PE1 usa restrições baseadas em ERO para forçar o roteamento diversificado de seus três LSPs sobre o núcleo do provedor. |
| PE2 | Dispositivo PE remoto (R6). | O PE2 anuncia novamente as rotas com tags coloridas recebidas pelo CE2 para PE1 usando o IBGP. Essas rotas usam a família para oferecer suporte a inet-vpn serviços VPN de Camada 3 com TCs mapeados por cores. |
| P1 P2 P3 | Dispositivos de provedores P1, P2 e P3 (R3, R4 e R5). | Os dispositivos P1-P3 representam a rede central do provedor de serviços. Estes são dispositivos de trânsito puros que executam comutação de rótulo MPLS para transportar o tráfego CE enviado pela VPN L3. |
Ilustrações de topologia
Etapas de configuração do PE1
Para obter informações sobre como navegar na CLI, veja Usando o Editor de CLI no modo de configuração
Para configuração completa em todos os dispositivos, veja:
Esta seção destaca as principais tarefas de configuração necessárias para configurar o dispositivo PE1 para este exemplo. A primeira etapa é comum configurar um serviço vpn básico de Camada 3. O conjunto de etapas a seguir é específico para adicionar o recurso BGP-CT à sua VPN de Camada 3. Ambos os dispositivos PE têm uma configuração semelhante, aqui nos concentramos no PE1.
-
Primeiro, provisione a VPN geral de Camada 3:
-
Configure e numera as interfaces de loopback, voltado para o núcleo e voltadas para CE para IPv4. Certifique-se de habilitar a
mplsfamília nas interfaces voltadas para o núcleo que se conectam aos dispositivos P para oferecer suporte à comutação MPLS. -
Configure um número de sistema autônomo.
-
Configure o OSPF de área única nas interfaces de loopback e voltadas para o núcleo.
-
Configure o RSVP nas interfaces de loopback e voltadas para o núcleo.
-
Configure a sessão de peering do IBGP para o dispositivo PE remoto, PE2. Inclua a família de
inet-vpnendereços para oferecer suporte a uma VPN de Camada 3 IPv4. -
Configure uma instância de roteamento baseada em VRF para o dispositivo CE1. Use o EBGP como protocolo de roteamento PE-CE.
[edit] set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32
[edit] set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12
[edit] set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0
[edit] set routing-options route-distinguisher-id 192.168.0.1 set routing-options autonomous-system 65412
-
-
Adicione planos de transporte com classe à VPN de Camada 3.
Configure as classes de transporte de ouro e bronze.
Esta é uma etapa crítica na configuração do recurso de transporte com classe. Essas aulas de transporte são mapeadas para LSPs sinalizados (e possivelmente projetados por tráfego) que atravessam o núcleo do provedor. As rotas remotas aprendidas com o CE2 são marcadas com comunidades coloridas que mapeiam essas aulas de transporte e, ao fazê-lo, para o LSP desejado entre os dispositivos PE.
[edit] set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set routing-options resolution preserve-nexthop-hierarchy
-
Configure três LSPs de PE1 a PE2 com roteamento limitado que força cada um a atravessar um roteador P diferente. Dois desses LSPs fazem o mapa para as gold classes de transporte.bronze O LSP de ouro é roteado por P1, o bronze por P2 e o melhor esforço pelo dispositivo P3.
Uma vez mapeado para as aulas de transporte, o provedor de serviços é capaz de colocar tráfego de clientes específicos, como indicado por uma comunidade de cores BGP, em um LSP específico. Com esse mapeamento de cor para LSP, o provedor de serviços pode oferecer um serviço hierárquico com diferentes SLAs.
Em nosso exemplo, usamos um ERO rigoroso para garantir que os três LSPs sejam roteados de forma diversificada pelos três caminhos disponíveis na topologia.
[edit] set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0
-
Para facilitar o retorno à classe de serviço padrão (melhor esforço) túnel, configuramos os túneis da classe de transporte de ouro e bronze com uma menor preferência global. Neste exemplo, o valor de preferência é alterado do padrão 7 para 5. Isso permite o uso do túnel de melhor esforço como um recuo caso os túneis de ouro ou bronze se tornem inutilizáveis. Definir uma preferência menor (mais preferida) nos túneis de ouro e bronze garante que eles sejam selecionados para o encaminhamento, embora a rota de serviço seja capaz de resolver para o túnel de melhor esforço.
Nota:Esta seção se concentrou na configuração necessária no dispositivo PE1. Deve-se notar que para que a função de seleção de próximo salto de transporte de classe funcione no PE1, as rotas remotas de dispositivo CE2 devem ser marcadas com uma comunidade de cores. Essa marcação pode ocorrer no dispositivo PE2 remoto ou no dispositivo CE2 remoto. Mostramos a última abordagem aqui para oferecer integridade:
-
Combine com as etiquetas da comunidade de cores adicionadas no CE2 remoto às definições de classe de transporte para os TCs de bronze e ouro.
[edit] set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100
Verifique planos de transporte com classe
Nesta seção, nos concentramos em comandos que demonstram um recurso de transporte de classe trabalhadora. Veja o apêndice 1: Solução de problemas para comandos usados para verificar a funcionalidade subjacente necessária pelo recurso de transporte com classe.
Você usará esses comandos para verificar se o transporte com classe BGP funciona corretamente.
| Comando |
Tarefa de verificação |
| classe de transporte de roteamento show | Verifique as aulas de transporte e seus atributos associados. Isso inclui a comunidade de mapeamento e a instância de roteamento.. |
| mostrar esquema de resolução de rotas | Exibir como as rotas de classe de serviço são resolvidas para o LSP no próximo salto. Verifique as tabelas de roteamento de resolução para obter uma rota específica. |
| bgp de protocolo de recebimento de rota de exibiçãope2-loopback-address | Verifique se as rotas de VPN recebidas pelo PE1 têm uma comunidade de cores BGP anexada. |
| mostrar rota e mostrar a vpn da tabela de encaminhamento de rotasvpn | Verifique a seleção de túneis de transporte visualizando o protocolo nexthop (PNH) para as rotas em PE1. |
| mostrar estatísticas lsp mpls e show route forwarding-table | Verifique o túnel de transporte usado por uma rota de classe de transporte específica. |
- Verifique as aulas de transporte e túneis de transporte
- Verifique os esquemas de resolução do próximo salto
- Verifique a marcação de cores e a seleção de próximo salto para rotas CE2
- Verifique a conectividade de ponta a ponta
- Confirme a falha com o melhor esforço
Verifique as aulas de transporte e túneis de transporte
Propósito
PE1 e PE2 usam túneis de transporte MPLS sinalizados por RSVP para oferecer suporte a um serviço VPN de Camada 3 que é capaz de oferecer níveis de serviço diferenciados. Essas rotas de serviço têm seus próximos saltos resolvidos em um túnel MPLS específico com base na classe de serviço correspondente. A classe de serviços é sinalizada anexando uma comunidade de cores BGP a rotas de clientes VPN.
Nesta parte, você confirma que todos os três LSPs do PE1 estão operacionais, que eles são mapeados para a classe de transporte correta e que são roteados corretamente pelo núcleo do provedor.
Ação
A partir do modo operacional, entre no show route 192.168.0.2 comando.
user@PE1 show route 192.168.0.2
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[OSPF/10] 00:27:20, metric 2
to 10.1.24.2 via ge-0/0/2.0
> to 10.1.25.2 via ge-0/0/3.0
to 10.1.23.2 via ge-0/0/1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/7/1] 00:13:09, metric 2
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:11, metric 2
> to 10.1.23.2 via ge-0/0/1.0, label-switched-path gold_lsp_to_pe2
junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:08, metric 2
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Significado
A saída confirma que o PE1 aprendeu três caminhos para o loopback de PE2 por OSPF. Essas rotas estão na inet.0 mesa. Você também observa que os três LSPs são representados como próximos saltos viáveis para chegar ao PE2. Observe que cada um desses LSPs está alojado em uma tabela de roteamento diferente. A parte destacada do próximo salto IP (e o nome da interface correspondente) confirma o roteamento LSP diversificado desejado sobre o núcleo. O tráfego mapeado para o caminho do ouro é enviado para 10,1,23,2, enquanto o tráfego para bronze e BE é enviado para 10,1,24,2 e 10,25,2, respectivamente.
Os SEGUINTEs RIBs de transporte e túneis de transporte são criados.
-
junos-rti-tc-100.inet.3para gold_lsp_to_pe2 -
junos-rti-tc-200.inet.3para bronze_lsp_to_pe2 -
inet.3para lsp_to_pe2
Verifique os esquemas de resolução do próximo salto
Propósito
Verifique os esquemas de resolução de rotas de serviço, a comunidade de mapeamento associada e como o próximo salto se resolve nas tabelas de roteamento contribuintes.
Ação
A partir do modo operacional, entre no show route resolution scheme all comando.
user@PE1> show route resolution scheme all Resolution scheme: junos-resol-schem-tc-100-v4-service References: 1 Mapping community: color:0:100 Resolution Tree index 1, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-100-v4-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 3, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 Resolution scheme: junos-resol-schem-tc-100-v6-service References: 1 Mapping community: color:0:100 Resolution Tree index 2, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-100-v6-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 4, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 Resolution scheme: junos-resol-schem-tc-200-v4-service References: 1 Mapping community: color:0:200 Resolution Tree index 5, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-200-v4-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 7, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 Resolution scheme: junos-resol-schem-tc-200-v6-service References: 1 Mapping community: color:0:200 Resolution Tree index 6, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-200-v6-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 8, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3
Significado
Focando nas partes IPv4 da saída, você vê que a junos-tc-100 (gold) classe de transporte tem dois esquemas de resolução - junos-resol-schem-tc-100-v4-service e junos-resol-schem-tc-100-v4-transport - usados para as rotas de serviço e transporte, respectivamente.
O esquema de resolução de rotas de serviços de ouro (junos-resol-schem-tc-100-v4-service) oferece resolução tantojunos-rti-tc-100.inet.3 nas tabelas de roteamento quanto nas inet.3 tabelas de roteamento (destacadas na saída de amostra). Listar as tabelas de resolução de serviços e BE é como o recuo ocorre quando a classe de serviços está baixa. Lembre-se disso é por que alteramos o valor de preferência dos LSPs de serviço (configurando a preferência para 5 em vez do 7 padrão), para garantir que a rota de serviço seja sempre preferida em vez do fallback BE.
Verifique a marcação de cores e a seleção de próximo salto para rotas CE2
Propósito
Confirme que o PE2 anuncia a rota de loopback para CE2 com uma comunidade de cores que seleciona a classe de serviços de bronze (cor 200).
Em nosso exemplo, configuramos o dispositivo CE2 para anexar a comunidade de cores. O PE2 deixa esta comunidade no local quando anuncia novamente a rota para PE1. Isso significa que o cliente VPN é capaz de realizar seus próprios mapeamentos de classe de serviço. Quando desejado, o roteador PE pode clarear ou retirar quaisquer comunidades recebidas do CE. Neste caso, o dispositivo PE precisa ser configurado para anexar a comunidade de mapeamento de cores desejada às rotas CE antes que ele os anuncie novamente ao PE1.
Ação
A partir do modo operacional, entre no show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail comando.
user@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299808
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
Exibir a entrada da tabela de encaminhamento para o loopback CE2 na instância de roteamento VPN no PE1. Confirme que o próximo salto de encaminhamento corresponde à classe de transporte desejada (bronze). Use o show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive comando.
user@PE1> show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive
Routing table: CE1_L3vpn.inet [Index 10]
Internet:
Destination: 172.16.255.2/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 1048574 Reference: 2
Nexthop:
Next-hop type: composite Index: 662 Reference: 2
Load Balance Label: Push 299808, None
Nexthop: 10.1.24.2
Next-hop type: Push 299872 Index: 653 Reference: 2
Load Balance Label: None
Next-hop interface: ge-0/0/2.0 Significado
As entradas destacadas confirmam que o tráfego correspondente à rota de loopback CE2 é enviado para 10.1.24.2 usando a interface ge-0/0/2. Lembre-se dos EROs usados para os LSPs, esta interface e o próximo salto estão associados com o LSP de bronze e a classe de transporte. O 299808 rótulo é usado para identificar o serviço VRF. O rótulo externo de transporte RSVP é 299872.
Você confirma rapidamente que este é o rótulo de transporte RSVP correto para a classe de bronze com um show rsvp session detail name bronze_lsp_to_pe2 comando
root@PE1> show rsvp session detail name bronze_lsp_to_pe2 Ingress RSVP: 3 sessions 192.168.0.2 From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0 LSPname: bronze_lsp_to_pe2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299872 Resv style: 1 FF, Label in: -, Label out: 299872 Time left: -, Since: Tue Aug 16 12:17:12 2022 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 23256 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.24.2 (ge-0/0/2.0) 1 pkts RESV rcvfrom: 10.1.24.2 (ge-0/0/2.0) 1 pkts, Entropy label: Yes Explct route: 10.1.24.2 10.1.46.2 Record route: <self> 10.1.24.2 10.1.46.2 Total 1 displayed, Up 1, Down 0
As partes destacadas indicam que o LSP de bronze é roteado pelo dispositivo P2 e está associado ao rótulo de transporte RSVP indicado (299856) que você confirmou anteriormente na tabela de encaminhamento de VPN para o endereço loopback CE2.
Verifique a conectividade de ponta a ponta
Propósito
Verifique a conectividade de ponta a ponta em todo o domínio do provedor, pingando entre CE1 e CE2. Você examina as estatísticas de tráfego MPLS para fornecer confirmação adicional de que a classe de transporte de bronze é usada.
Ação
A partir do modo operacional, entre no ping comando.
user@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid PING 172.16.255.2 (172.16.255.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.255.2 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.647/3.589/30.264/2.695 ms
A partir do modo operacional no PE1, entre no show mpls lsp statistics comando.
user@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 192.168.0.1 Up 100 8400 bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 lsp_to_pe2 Total 3 displayed, Up 3, Down 0 <output truncated for brevity>
Ação
Trace a rota do CE1 até o loopback do CE2. Nossa configuração inclui a icmp-tunneling declaração para oferecer suporte a uma rota de rastreamento baseada em ICMP com saltos MPLS no núcleo do provedor.
user@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.174 ms 1.775 ms 1.917 ms
2 10.1.24.2 5.171 ms 5.768 ms 4.900 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.46.2 4.707 ms 4.347 ms 4.419 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.640 ms 5.851 ms 44.777 ms
Significado
A troca de pings é bem sucedida e as estatísticas confirmam o uso do túnel de transporte de bronze. Isso é esperado, dado que a rota para o CE2 tem a comunidade de 200 cores anexada. Os resultados da rota de rastreamento confirmam que o tráfego é encaminhado por um LSP, e que este LSP está sendo encaminhado até 10.1.24.2. Este é o endereço IP atribuído ao dispositivo P2. O próximo salto e o valor do rótulo externo confirmam que este tráfego é enviado no LSP de classe de serviço de bronze.
Confirme a falha com o melhor esforço
Propósito
Leve o LSP de transporte de bronze para verificar se o tráfego enviado ao CE2 falha no caminho BE.
Ação
Digite o modo de configuração e especifique um próximo salto inválido como um ERO para o túnel de transporte de bronze. A incapacidade de satisfazer o requisito de ERO reduz o LSP relacionado.
[edit] user@PE1# set protocols mpls path bronze 10.1.66.6 strict
Uma vez que a mudança é comprometida, o túnel de bronze é mostrado para baixo:
root@PE1> show mpls lsp ingress Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 0.0.0.0 Dn 0 - bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2
Repita os ping comandos de rota e trace do CE1 ao loopback do CE2.
root@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid
PING 172.16.255.2 (172.16.255.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.16.255.2 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.164/5.345/12.348/1.240 ms
root@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.493 ms 1.766 ms 1.913 ms
2 10.1.25.2 5.211 ms 5.016 ms 5.514 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.56.2 4.216 ms 4.467 ms 4.551 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.492 ms 5.543 ms 5.112 msExibir novamente as estatísticas do MPLS no PE1.
user@PE1> show mpls lsp statistics root@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 0.0.0.0 Dn NA NA bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 100 8400 lsp_to_pe2 Total 3 displayed, Up 2, Down 1 . . .
Significado
A troca de pings ainda tem sucesso, embora agora em um caminho de melhor esforço. No PE, as estatísticas confirmam o uso do túnel de transporte de melhor esforço. A rota de rastreamento mostra que o PE1 agora avança para o próximo salto de 10.1.25.2 até PE3. Isso confirma a falha de uma classe de transporte colorida para a classe de melhor esforço em caso de falha no túnel de transporte.
Nesta seção, efetuamos o fail over para a classe BE, derrubando o LSP mapeado para a classe de serviços de bronze. Como alternativa, considere mudar a política de exportação de EBGP no dispositivo CE2 para que ele conecte a comunidade de cores de ouro (100). Com essa abordagem, você espera ver o tráfego de ping do CE1 para o CE2 tomando o LSP de ouro em vez de falhar no BE. O abaixo faz o truque no CE2 se você preferir essa abordagem. Certifique-se de confirmar as mudanças no CE2.
[edit] root@CE2# delete policy-options policy-statement adv_direct term 1 then community add map2bronze root@CE2# set policy-options policy-statement adv_direct term 1 then community add map2gold
Apêndice 1: Solução de problemas
Nossa seção de verificação é baseada em uma suposição de que você tem uma rede de trabalho, permitindo que o foco seja colocado na confirmação da operação do BGP-CT. O recurso BGP-CT, em um contexto VPN de Camada 3 baseado em MPLS, depende de uma rede com interfaces de trabalho, IGP, RSVP, MPLS e BGP.
Tabela 4 fornece orientações sobre o que procurar se sua solução BGP-CT não estiver funcionando como esperado. A tabela é estruturada da parte inferior até a parte superior, começando pela conectividade básica da interface e terminando com uma bem sucedida troca de rotas BGP entre os dispositivos PE.
Como parte deste exemplo, você configura um endereço de loopback e ID do roteador. Se o dispositivo anteriormente tivesse um RID diferente, pode levar algum tempo para que as coisas se estabilizem. Mudar o RID é muito disruptivo e não algo que acontece com frequência. Quando em um ambiente de laboratório, sugere-se que você emita o comando do restart routing modo operacional em todos os dispositivos logo após o compromisso com o novo RID.
| Camada funcional |
Abordagem de verificação |
| Interfaces e endereçamento ip | Verifique se todas as interfaces em sua topologia estão operacionais ativas. Verifique se você pode rastrear a extremidade local e remota de cada link. Como a maioria das redes, os protocolos e serviços neste exemplo exigem uma infraestrutura IPv4 em funcionamento.root@PE1> show interfaces terse | match "(ge-0/0/0|ge-0/0/1|ge-0/0/2|ge-0/0/3)"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.1.2/30
ge-0/0/1 up up
ge-0/0/1.0 up up inet 10.1.23.1/24
ge-0/0/2 up up
ge-0/0/2.0 up up inet 10.1.24.1/24
ge-0/0/3 up up
ge-0/0/3.0 up up inet 10.1.25.1/24
root@PE1> ping 10.1.23.2 count 1
PING 10.1.23.2 (10.1.23.2): 56 data bytes
64 bytes from 10.1.23.2: icmp_seq=0 ttl=64 time=2.951 ms
--- 10.1.23.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.951/2.951/2.951/0.000 ms
root@PE1> ping 172.16.1.1 routing-instance CE1_L3vpn count 1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=2.755 ms
--- 172.16.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.755/2.755/2.755/0.000 ms
|
| Roteamento OSPF (IGP) | Confirme que todos os dispositivos do provedor têm todas as adjacências OSPF esperadas. Use os comandos do show ospf interfaces modo operacional.show ospf neighbors Exibir as rotas para os endereços de loopback do provedor e confirmar caminhos OSPF válidos para todos os endereços de loopback remoto (show route protocol ospf | match 192.168.0). Ping do loopback local para os endereços de loopback remoto de todos os roteadores de provedor.Este exemplo usa LSPs baseados em CSPF. Isso exige que o OSPF seja configurado com a root@PE1> show ospf interface Interface State Area DR ID BDR ID Nbrs ge-0/0/1.0 BDR 0.0.0.0 192.168.0.11 192.168.0.1 1 ge-0/0/2.0 BDR 0.0.0.0 192.168.0.12 192.168.0.1 1 ge-0/0/3.0 DR 0.0.0.0 192.168.0.1 192.168.0.13 1 lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 root@PE1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 ge-0/0/1.0 Full 192.168.0.11 128 34 10.1.24.2 ge-0/0/2.0 Full 192.168.0.12 128 32 10.1.25.2 ge-0/0/3.0 Full 192.168.0.13 128 37 root@PE1> show route protocol ospf| match 192.168.0 192.168.0.2/32 *[OSPF/10] 00:10:15, metric 2 192.168.0.11/32 *[OSPF/10] 00:18:40, metric 1 192.168.0.12/32 *[OSPF/10] 00:18:35, metric 1 192.168.0.13/32 *[OSPF/10] 00:10:15, metric 1 root@PE1> ping 192.168.0.2 source 192.168.0.1 count 1 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=3.045 ms --- 192.168.0.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.045/3.045/3.045/0.000 ms |
| MPLS e RSVP | Verifique se todas as interfaces de núcleo estão habilitadas para a mpls família com um show interfaces terse comando. Verifique também se todas as interfaces de provedores estão habilitadas sob as protocols mpls hierarquias.protocols RSVP Use os show mpls interfaces comandos e os show rsvp interfaces comandos. Nota:
Certifique-se de confirmar que os números corretos da unidade de interface estão listados para a família MPLS e para cada protocolo. Este exemplo usa a unidade 0, que é o número padrão da unidade, em todas as interfaces. root@PE1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/1.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
root@PE1> show mpls interface
Interface State Administrative groups (x: extended)
ge-0/0/1.0 Up <none>
ge-0/0/2.0 Up <none>
ge-0/0/3.0 Up <none>Os roteadores PE confirmam que os LSPs estão corretamente definidos para saída no endereço loopback do dispositivo PE remoto. Verifique se as EROs e quaisquer outras restrições de TE são válidas. Use os Nota: Nossos exemplos usam LSPs baseados em CSPF. Isso exige que o IGP ofereça suporte a um banco de dados de TE (TED). Se o OSPF for o IGP, certifique-se de incluir a declaração de
traffic-engieering configuração. Alternativamente, considere usar a no-cspf declaração na definição de LSP para remover o CSPF da equação.root@PE1> show mpls lsp Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 192.168.0.1 Up 0 * bronze bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2 Total 3 displayed, Up 3, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - bronze_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - gold_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - lsp_to_pe1 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 |
| BGP | Use o show bgp summarycomando nos dispositivos pe para confirmar tanto sua sessão de EBGP para o CE, quanto a sessão do IBGP para o PE remoto estão estabelecidas. Se o BGP estiver desativado, apesar de ser capaz de ping, suspeite de uma definição ruim de peer. Lembre-se que o peering de loopback (para IBGP) requer a local-address declaração. Para o EBGP, especifique os próximos saltos conectados diretamente e confirme o número de AS local, abaixo edit routing-options e o número de AS remoto, sob o grupo de pares EBGP, estão especificados.Confirme que a sessão de PE-PE está habilitada para a root@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 64510 55 55 0 0 23:13 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.2 65412 57 56 0 0 23:11 Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 2/2/2/0
CE1_L3vpn.inet.0: 2/2/2/0A publicidade da rota do show e os comandos de protocolo de recebimento são úteis ao confirmar quais rotas um determinado orador BGP anuncia ou recebe, respectivamente. root@PE1> show route advertising-protocol bgp 192.168.0.2 CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/30 Self 100 I * 172.16.255.1/32 Self 100 64510 I root@PE1> show route receive-protocol bgp 192.168.0.2 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/30 192.168.0.2 100 I * 172.16.255.2/32 192.168.0.2 100 64520 I junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.0.2:12:172.16.2.0/30 * 192.168.0.2 100 I 192.168.0.2:12:172.16.255.2/32 * 192.168.0.2 100 64520 I |
| VPN de Camada 3 | Garanta que a sessão do IBGP ofereça family inet-vpn suporte a rotas. Confirme que as rotas anunciadas pelo PE remoto são importadas para a instância correta com base no alvo da rota. Garanta a política de importação e exportação usada na instância de roteamento de cada partida de PE e anuncie as rotas corretas. Alguns dos displays na seção de verificação do BGP confirmam o recebimento de rotas de CE remotas e a importação dessas rotas para a instância VRF. root@PE1> show bgp neighbor 192.168.0.2 | match nlri
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast inet-vpn-unicast
root@PE1> show route table CE1_L3vpn.inet
root@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
. . .
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299776
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
root@PE1> show route table CE1_L3vpn.inet
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 00:30:11
> via ge-0/0/0.0
[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.1.2/32 *[Local/0] 00:30:11
Local via ge-0/0/0.0
172.16.2.0/30 *[BGP/170] 00:21:26, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.255.2/32 *[BGP/170] 00:29:40, localpref 100, from 192.168.0.2
AS path: 64520 I, validation-state: unverified
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Confirme que o dispositivo CE está recebendo e anunciando as rotas esperadas usando os métodos discutidos para a solução de problemas do BGP. |
Apêndice 2: Definir comandos em todos os dispositivos
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de hierarquia [editar].
CE1
set interfaces ge-0/0/0 unit 0 description "Link from CE1 to PE1 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept set protocols bgp group ToPE1 type external set protocols bgp group ToPE1 export adv_direct set protocols bgp group ToPE1 peer-as 65412 set protocols bgp group ToPE1 neighbor 172.16.1.2 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 64510 set system host-name CE1
CE2
set interfaces ge-0/0/0 unit 0 description "Link from CE2 to PE2 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 64520 set system host-name CE2
PE1 (DUT)
set interfaces ge-0/0/0 unit 0 description "Link from PE1 to CE1" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.2/30 set interfaces ge-0/0/1 unit 0 description "Link from PE1 to P1" set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0 set routing-options route-distinguisher-id 192.168.0.1 set routing-options resolution preserve-nexthop-hierarchy set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE1
PE2
set interfaces ge-0/0/0 unit 0 description "Link from PE2 to P1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.36.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from PE2 to P2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE2 to P3" set interfaces ge-0/0/2 unit 0 family inet address 10.1.56.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE2 to CE2" set interfaces ge-0/0/3 unit 0 family inet address 172.16.2.2/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 64520 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn interface ge-0/0/3.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.2:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 transport-class gold set protocols mpls label-switched-path gold_lsp_to_pe1 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path bronze_lsp_to_pe1 transport-class bronze set protocols mpls label-switched-path bronze_lsp_to_pe1 preference 5 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set routing-options route-distinguisher-id 192.168.0.2 set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE2
P1
set interfaces ge-0/0/0 unit 0 description "Link from P1 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P1 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.36.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.11/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.11 set system host-name P1
P2
set interfaces ge-0/0/0 unit 0 description "Link from P2 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.24.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P2 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.12/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.12 set system host-name P2
P3
set interfaces ge-0/0/0 unit 0 description "Link from P3 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.25.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P3 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.56.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.13/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.13 set system host-name P3
Apêndice 3: Mostrar saída de configuração em PE1
A configuração pe1 completa no formato Curly Brace
user@PE1# show | no-more
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
unit 0 {
description "Link from PE1 to CE1";
family inet {
address 172.16.1.2/30;
}
}
}
ge-0/0/1 {
unit 0 {
description "Link from PE1 to P1";
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
description "Link from PE1 to P2";
family inet {
address 10.1.24.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
description "Link from PE1 to P3";
family inet {
address 10.1.25.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
instance-type vrf;
protocols {
bgp {
group CE1 {
type external;
peer-as 64510;
neighbor 172.16.1.1;
}
}
}
interface ge-0/0/0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
route-distinguisher-id 192.168.0.1;
resolution {
preserve-nexthop-hierarchy;
}
router-id 192.168.0.1;
autonomous-system 65412;
transport-class {
name gold {
color 100;
}
name bronze {
color 200;
}
}
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.0.2;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.2;
primary best-effort;
}
label-switched-path gold_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary gold;
transport-class gold;
}
label-switched-path bronze_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary bronze;
transport-class bronze;
}
path gold {
10.1.23.2 strict;
}
path bronze {
10.1.24.2 strict;
10.1.66.6 strict;
}
path best-effort {
10.1.25.2 strict;
}
icmp-tunneling;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}Transporte classful BGP (BGP-CT) com visão geral dos túneis SR-TE coloridos subjacentes
Benefícios do BGP-CT com túneis SR-TE coloridos subjacentes
- Resolve preocupações de escala que podem surgir no futuro à medida que a rede cresce.
- Oferece interconectividade para domínios que usam tecnologias diferentes.
- Desacopla serviços e as camadas de transporte que resultam em uma rede completamente distribuída.
- Oferece gerenciamento independente de largura de banda por meio de um controlador de engenharia de tráfego intra-domínio para SR-TE.
Redes de grande porte que estão crescendo e evoluindo continuamente exigem uma arquitetura de roteamento por segmentos consistente. A partir do Junos OS Release 21.2,R1 oferecemos suporte ao BGP-CT com transporte subjacente como túneis SR-TE coloridos. O BGP-CT pode resolver rotas de serviço usando as RIBs de transporte e computar o próximo salto. Os serviços que atualmente são suportados no BGP-CT também podem usar os túneis coloridos SR-TE subjacentes para resolução de rotas. Os serviços agora podem usar os túneis coloridos SR-TE subjacentes, como os túneis coloridos estáticos, BGP SR-TE, rpd programável e túneis coloridos de PCEP. O BGP-CT usa a acessibilidade de próximo salto para resolver rotas de serviço na classe de transporte desejada.
Para permitir a resolução de rota de serviço BGP-CT em túneis coloridos sr-TE subjacentes, inclua a use-transport-class declaração no nível de [edit protocols source-packet-routing] hierarquia.
- Habilite a
use-transport-classdeclaraçãono nível hierárquicos
juntamente com a[edit protocols source-packet-routing].auto-createdeclaração no nível hierárquica[edit routing-options transport-class]. - Não oferecemos suporte a grupos RIB para SR-TE colorido com
use-transport-classtúneis SR-TE coloridos e coloridos com este recurso.
Consulte também
Mapeamento baseado em cores da visão geral dos serviços VPN
Você pode especificar a cor como uma restrição de próximo salto de protocolo (além do endereço IPv4 ou IPv6) para a resolução de túneis de transporte em LSPs de roteamento por segmentos estáticos e BGP projetados para tráfego (SR-TE). Isso é chamado de resolução de próximo salto do protocolo IP colorido, onde você é obrigado a configurar um mapa de resolução e aplicar-se aos serviços de VPN. Com esse recurso, você pode habilitar o direcionamento de tráfego baseado em cores de serviços VPN de Camada 2 e Camada 3.
O Junos OS oferece suporte a LSPs SR-TE coloridos associados a uma única cor. O mapeamento baseado em cores do recurso de serviços VPN é suportado em LSPs coloridos estáticos e LSPs BGP SR-TE.
- Coloração de serviços VPN
- Especificando o modo de mapeamento de serviços VPN
- Resolução next hop do protocolo IP de cores
- Revés à resolução next hop do protocolo IP
- Mapeamento baseado em cores unicast rotulado do BGP sobre SR-TE e IS-IS Underlay
- Recursos suportados e sem suporte para mapeamento baseado em cores de serviços VPN
Coloração de serviços VPN
Em geral, um serviço vpn pode ser atribuído uma cor no roteador de saída onde a VPN NLRI é anunciada, ou em um roteador de entrada onde a VPN NLRI é recebida e processada.
Você pode atribuir uma cor aos serviços de VPN em diferentes níveis:
-
Por instância de roteamento.
-
De acordo com o grupo BGP.
-
De acordo com o vizinho BGP.
-
Por prefixo.
-
Conjunto de prefixos.
Uma vez que você atribui uma cor, a cor é anexada a um serviço VPN na forma de comunidade estendida de cores BGP.
Você pode atribuir várias cores a um serviço VPN, chamado de serviços VPN multicoloridos. Nesses casos, o menor valor de cor é considerado como a cor do serviço vpn, e todas as outras cores são ignoradas.
Várias cores são atribuídas por dispositivos de saída e/ou entrada por várias políticas na ordem a seguir:
-
Política de exportação de BGP no dispositivo de saída.
-
Política de importação de BGP no dispositivo de entrada.
-
Política de importação de VRF no dispositivo de entrada.
Os dois modos de coloração de serviços VPN são:
Atribuição de cores de saída
Nesse modo, o dispositivo de saída (ou seja, o anunciante da VPN NLRI) é responsável por colorir o serviço VPN. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la no nível de hierarquia vrf-export, exportação de grupo ou vizinho de grupo do serviço VPN no nível de hierarquia [editar protocolos bgp]. A VPN NLRI é anunciada pelo BGP com a comunidade estendida de cores especificada.
Por exemplo:
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}OU
Quando você aplica a política de roteamento como política de exportação de um grupo BGP ou vizinho BGP, você deve incluir a vpn-apply-export declaração no nível bgp, grupo BGP ou vizinho BGP para que a política entre em vigor no VPN NLRI.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}As políticas de roteamento são aplicadas às NLRIs de prefixo VPN de Camada 3, NRLIs VPN de Camada 2 e NLRIs EVPN. A comunidade estendida por cores é herdada por todas as rotas vpn, importadas e instaladas nos VRFs alvo em um ou vários dispositivos de entrada.
Atribuição de cores de entrada
Nesse modo, o dispositivo de entrada (ou seja, o receptor da VPN NLRI) é responsável por colorir o serviço VPN. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la à instância vrf-import de roteamento do serviço VPN, importação de grupos ou importação de vizinhos de grupo no [edit protocols bgp] nível hierárquico. Todas as rotas de VPN correspondentes à política de roteamento são anexadas à comunidade estendida de cores especificada.
Por exemplo:
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}OU
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}Especificando o modo de mapeamento de serviços VPN
Para especificar modos flexíveis de mapeamento de serviços vpn, você deve definir uma política usando a declaração do mapa de resolução e consultar a política no nível de hierarquia vrf-import, importação de grupo ou vizinho de grupo de um serviço VPN no nível de hierarquia [editar protocolos bgp]. Todas as rotas de VPN correspondentes à política de roteamento estão anexadas ao mapa de resolução especificado.
Por exemplo:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}Você pode aplicar a política de importação na instância de roteamento do serviço VPN.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}Você também pode aplicar a política de importação a um grupo BGP ou vizinho BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}Cada modo de mapeamento de serviços VPN deve ter um nome único definido no mapa de resolução. Apenas uma única entrada de cor ip é suportada no mapa de resolução, onde a(s) rota(s) VPN é resolvida usando um protocolo IP colorido próximo salto na forma de endereço ip:cor sobre as tabelas de roteamento inetcolor.0 e inet6color.0.
Resolução next hop do protocolo IP de cores
O processo de resolução de próximo salto de protocolo é aprimorado para oferecer suporte à resolução do próximo salto do protocolo IP colorido. Para um serviço VPN colorido, o processo de resolução do próximo salto de protocolo leva uma cor e um mapa de resolução, cria um protocolo IP colorido no próximo salto na forma de ip-address:color, e resolve o protocolo próximo salto nas tabelas de roteamento inetcolor.0 e inet6color.0.
Você deve configurar uma política para oferecer suporte à resolução multicaminho de VPN de Camada 2 colorida, VPN de Camada 3 ou serviços EVPN em LSPs coloridos. A política deve então ser aplicada com a tabela RIB relevante conforme a política de importação de resolver.
Por exemplo:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}Revés à resolução next hop do protocolo IP
Se um serviço VPN colorido não tiver um mapa de resolução aplicado a ele, o serviço de VPN ignora sua cor e volta ao protocolo IP de resolução de próximo salto. Por outro lado, se um serviço de VPN não colorido tiver um mapa de resolução aplicado a ele, o mapa de resolução é ignorado e o serviço vpn usa o protocolo IP de resolução de próximo salto.
O fallback é um processo simples, desde LSPs SR-TE coloridos até LSPs LDP, usando um grupo RIB para LDP para instalar rotas em tabelas de roteamento inet{6}color.0. Uma combinação de prefixo mais longa para um próximo salto de protocolo IP colorido garante que, se uma rota SR-TE LSP colorida não existir, uma rota LDP com um endereço IP correspondente deve ser devolvida.
Mapeamento baseado em cores unicast rotulado do BGP sobre SR-TE e IS-IS Underlay
A partir do Junos OS Release 20.2R1, o BGP Labeled Unicast (BGP-LU) pode resolver rotas IPv4 ou IPv6 por roteamento por segmentos — engenharia de tráfego (SR-TE) com underlay IS-IS para famílias de endereçoS IPv4 e IPv6. O BGP-LU oferece suporte para mapear a cor da comunidade BGP e definir um resolution map para SR-TE. Um protocolo colorido próximo salto é construído e é resolvido em um túnel SR-TE colorido na inetcolor.0 ou inet6color.0 mesa. Assim, o BGP-LU resolve o próximo salto de protocolo sobre túneis SR-TE para o transporte de pacotes. O BGP usa e tabelas inet.3inet6.3 para mapeamento não colorido.
Recursos suportados e sem suporte para mapeamento baseado em cores de serviços VPN
Os recursos e funcionalidades a seguir são suportados com mapeamento baseado em cores dos serviços de VPN:
-
VPN de camada 3 BGP
-
VPN de Camada 2 BGP (VPN de Camada 2 Kompella)
-
BGP EVPN
-
Mapa de resolução com uma única opção de cor IP.
-
Resolução de próximo salto do protocolo IPv4 e IPv6 colorido.
-
Base de informações de roteamento (também conhecida como tabela de roteamento) baseada em fallback para LDP LSP em inetcolor.0 ou tabelas de roteamento inet6color.0.
-
LSP SR-TE colorido.
-
Plataformas virtuais.
-
Junos OS de 64 bits.
-
Sistemas lógicos.
-
BGP Rotulado Unicast
Os recursos e funcionalidades a seguir não são suportados com mapeamento baseado em cores dos serviços de VPN:
-
LSPs MPLS coloridos, como RSVP, LDP, BGP-LU, estáticos.
-
Circuito de camada 2
-
FEC-129 BGP auto-descoberta e VPN de Camada 2 sinalizada por LDP.
-
VPLS
-
MVPN
-
IPv4 e IPv6 usando mapa de resolução.