Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

  • 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.

Figura 1: Domínio intra-AS: Cenários de antes e depois para a implementação de planos de transporte com classe BGPDomínio intra-AS: Cenários de antes e depois para a implementação de planos de transporte com classe BGPDomínio intra-AS: Cenários de antes e depois para a implementação de planos de transporte com classe BGP

Para classificar os túneis de transporte na classe de transporte BGP em uma configuração intra-AS:

  1. 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:

  2. Associe o túnel de transporte a uma classe de transporte específica no nó de entrada dos túneis.

    Configuração da amostra:

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 configuração.[edit routing-options resolution scheme]

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:

  1. 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:

  2. 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

    Para algoritmos flxáveis IS-IS

  3. 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:

  4. Anuncie rotas de serviço a partir do dispositivo PE de saída com a comunidade de cores estendida apropriada.

    Configuração da amostra:

Funcionalidade de plano de transporte com classe BGP entre AS:

  1. 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.
  2. 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.

  3. 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.
  4. 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.
  5. 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.
  6. 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).
  7. Os nós de fronteira usam esquemas de resolução predefinidos para a resolução de PNH da rota de transporte.
  8. 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.
  9. 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 declaração no nível de hierarquia.use-transport-class[edit protocols source-packet-routing]

Nota:
  1. Habilite a declaraçãouse-transport-class

    no nível hierárquicos .[edit protocols source-packet-routing]

    juntamente com a declaração no nível hierárquica .auto-create[edit routing-options transport-class]
  2. Não oferecemos suporte a grupos RIB para SR-TE colorido com túneis SR-TE coloridos e coloridos com este recurso.use-transport-class

Exemplo: Configuração de planos de transporte com classe (Intra-Domain)

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 BGPhttps://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/mpls-traffic-engineering-configuration.html#id_awl_rhp_2pb

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.https://jlabs.juniper.net/vlabs/portal/bgp-ct-intra-domain/

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.

Tabela 1: Visão geral funcional dos planos de transporte com classe

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:

  • Ouro

  • Bronze

  • Melhor esforço

    Esta é a classe de transporte padrão. Essa classe oferece serviço de nível de melhor esforço (BE). Clientes que não são mapeados para nenhuma classe de transporte específica, ou aqueles que são mapeados para uma classe de transporte que está baixa, padrão para a classe de serviços BE e o caminho LSP associado.

Família de serviços

VPN de camada 3 (family inet-vpn unicast

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
  • Confirme a operação geral da rede.
Verifique o trabalho de IGP, RSVP, MPLS, BGP e L3VPN.
  • Verifique o mapeamento do tráfego de clientes VPN de Camada 3 para uma aula de transporte.

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 informações de fundo sobre a operação e configuração de uma L3VPN baseada em MPLS.Example: Configure a Basic MPLS-Based Layer 3 VPN

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 declaração.protocols mpls icmp-tunneling 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.

Tabela 2: Visão geral da topologia de planos de transporte com classe intra-domínio
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 serviços VPN de Camada 3 com TCs mapeados por cores.inet-vpn
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

Figura 2: Mapeamento de serviços usando planos de transporte com classe dentro de um domínio de redeMapeamento de serviços usando planos de transporte com classe dentro de um domínio de rede

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çãohttps://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/cli-editor-configuration-mode-quick-reference-using.html

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.

  1. Primeiro, provisione a VPN geral de Camada 3:

    1. Configure e numera as interfaces de loopback, voltado para o núcleo e voltadas para CE para IPv4. Certifique-se de habilitar a família nas interfaces voltadas para o núcleo que se conectam aos dispositivos P para oferecer suporte à comutação MPLS.mpls

    2. Configure um número de sistema autônomo.

    3. Configure o OSPF de área única nas interfaces de loopback e voltadas para o núcleo.

    4. Configure o RSVP nas interfaces de loopback e voltadas para o núcleo.

    5. Configure a sessão de peering do IBGP para o dispositivo PE remoto, PE2. Inclua a família de endereços para oferecer suporte a uma VPN de Camada 3 IPv4.inet-vpn

    6. Configure uma instância de roteamento baseada em VRF para o dispositivo CE1. Use o EBGP como protocolo de roteamento PE-CE.

  2. 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.

  3. 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 classes de transporte.goldbronze 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.

  4. 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:

  5. 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.

Verifique planos de transporte com classe

Nota:

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.

Tabela 3: Comandos de verificação de planos de transporte com classe
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çãohttps://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/command/show-route-receive-protocol.htmlpe2-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 rotashttps://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/command/show-route.htmlhttps://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/command/show-route-forwarding-table-mpls-ex-series.htmlvpn 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 https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/command/show-mpls-lsp.htmlshow 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

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 comando.show route 192.168.0.2

Significado

A saída confirma que o PE1 aprendeu três caminhos para o loopback de PE2 por OSPF. Essas rotas estão na mesa.inet.0 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.3 para gold_lsp_to_pe2

  • junos-rti-tc-200.inet.3 para bronze_lsp_to_pe2

  • inet.3 para 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 comando.show route resolution scheme all

Significado

Focando nas partes IPv4 da saída, você vê que a classe de transporte tem dois esquemas de resolução - e - usados para as rotas de serviço e transporte, respectivamente.junos-tc-100 (gold)junos-resol-schem-tc-100-v4-servicejunos-resol-schem-tc-100-v4-transport

O esquema de resolução de rotas de serviços de ouro () oferece resolução tanto nas tabelas de roteamento quanto nas tabelas de roteamento (destacadas na saída de amostra).junos-resol-schem-tc-100-v4-servicejunos-rti-tc-100.inet.3inet.3 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).

Nota:

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 comando.show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail

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 comando.show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive

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 rótulo é usado para identificar o serviço VRF.299808 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 comandoshow rsvp session detail name bronze_lsp_to_pe2

As partes destacadas indicam que o LSP de bronze é roteado pelo dispositivo P2 e está associado ao rótulo de transporte RSVP indicado () que você confirmou anteriormente na tabela de encaminhamento de VPN para o endereço loopback CE2.299856

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 comando.ping

A partir do modo operacional no PE1, entre no comando.show mpls lsp statistics

Ação

Trace a rota do CE1 até o loopback do CE2. Nossa configuração inclui a declaração para oferecer suporte a uma rota de rastreamento baseada em ICMP com saltos MPLS no núcleo do provedor.icmp-tunneling

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.

Uma vez que a mudança é comprometida, o túnel de bronze é mostrado para baixo:

Repita os comandos de rota e trace do CE1 ao loopback do CE2.ping

Exibir novamente as estatísticas do MPLS no PE1.

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.

Nota:

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.

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.

Nota:

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 modo operacional em todos os dispositivos logo após o compromisso com o novo RID.restart routing

Tabela 4: Etapas de solução de problemas
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 modo operacional.show ospf interfacesshow 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 declaração.traffic-engieering Se o IS-IS for usado como IGP, esta declaração não será necessária.

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 família com um comando.mplsshow interfaces terse Verifique também se todas as interfaces de provedores estão habilitadas sob as hierarquias.protocols mplsprotocols RSVP Use os comandos e os comandos.show mpls interfacesshow rsvp interfaces
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 comandos e os comandos.show mpls lspshow rsvp session

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 configuração.traffic-engieering Alternativamente, considere usar a declaração na definição de LSP para remover o CSPF da equação.no-cspf
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 comando 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.show bgp summary 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 declaração.local-address Para o EBGP, especifique os próximos saltos conectados diretamente e confirme o número de AS local, abaixo e o número de AS remoto, sob o grupo de pares EBGP, estão especificados.edit routing-options

Confirme que a sessão de PE-PE está habilitada para a família.inet-vpn unicast Use o comando para confirmar o recebimento da rota ce remota no PE local.show route Use o switch para confirmar o anexo adequado da comunidade de cores.detail

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/0

A 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 suporte a rotas.family inet-vpn 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_pe2

Confirme 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

CE2

PE1 (DUT)

PE2

P1

P2

P3

Apêndice 3: Mostrar saída de configuração em PE1

A configuração pe1 completa no formato Curly Brace

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 declaração no nível de hierarquia.use-transport-class[edit protocols source-packet-routing]

Nota:
  1. Habilite a declaraçãouse-transport-class

    no nível hierárquicos .[edit protocols source-packet-routing]

    juntamente com a declaração no nível hierárquica .auto-create[edit routing-options transport-class]
  2. Não oferecemos suporte a grupos RIB para SR-TE colorido com túneis SR-TE coloridos e coloridos com este recurso.use-transport-class

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

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:

OU

Nota:

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 declaração no nível bgp, grupo BGP ou vizinho BGP para que a política entre em vigor no VPN NLRI.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 de roteamento do serviço VPN, importação de grupos ou importação de vizinhos de grupo no nível hierárquico. vrf-import[edit protocols bgp] Todas as rotas de VPN correspondentes à política de roteamento são anexadas à comunidade estendida de cores especificada.

Por exemplo:

OU

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:

Você pode aplicar a política de importação na instância de roteamento do serviço VPN.

Você também pode aplicar a política de importação a um grupo BGP ou vizinho BGP.

Nota:

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 , e resolve o protocolo próximo salto nas tabelas de roteamento inetcolor.0 e inet6color.0.ip-address:color

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:

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 para SR-TE.resolution map Um protocolo colorido próximo salto é construído e é resolvido em um túnel SR-TE colorido na ou mesa.inetcolor.0inet6color.0 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 para mapeamento não colorido.inet.3inet6.3

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.