Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração do PCEP

Visão geral do PCEP

Um elemento de computação de caminho (PCE) é uma entidade (componente, aplicativo ou nó de rede) que é capaz de computar um caminho ou rota de rede com base em um gráfico de rede e aplicar restrições computacionais. Um cliente de computação de caminho (PCC) é qualquer aplicativo do cliente que solicita uma computação de caminho a ser realizada por um PCE. O Protocolo de Elemento de Computação de Caminho (PCEP) permite comunicações entre um PCC e um PCE, ou entre dois PCEs (definidos em RFC 5440).

PCEP é um protocolo baseado em TCP definido pelo IETF PCE Working Group, e define um conjunto de mensagens e objetos usados para gerenciar sessões de PCEP e solicitar e enviar caminhos para LSPs projetados em tráfego multidomain (TE LSPs). Ele fornece um mecanismo para que um PCE realize a computação de caminhos para os LSPs externos de um PCC. As interações do PCEP incluem relatórios de status de LSP enviados pelo PCC para o PCE e atualizações de PCE para os LSPs externos.

Figura 1 ilustra o papel do PCEP na implementação no lado cliente de uma arquitetura PCE stateful em uma rede habilitada para RSVP-TE MPLS.

Figura 1: Sessão do PCEPSessão do PCEP

Uma sessão de PCEP baseada em TCP conecta um PCC a um PCE externo. O PCC inicia a sessão de PCEP e permanece conectado ao PCE durante a sessão do PCEP. Durante a sessão do PCEP, o PCC solicita parâmetros LSP do PCE stateful. Ao receber um ou mais parâmetros LSP do PCE, o PCC re-sinaliza o TE LSP. Quando a sessão do PCEP é terminada, a conexão TCP subjacente é fechada imediatamente, e o PCC tenta restabelecer a sessão do PCEP.

Assim, as funções do PCEP incluem:

  • Sincronização do estado do túnel LSP entre um PCC e um PCE stateful — Quando uma conexão PCE stateful ativa é detectada, um PCC tenta delegar todos os LSPs a este PCE em um procedimento chamado sincronização de estado LSP. O PCEP permite a sincronização do estado LSP do PCC para o PCE.

  • Delegação de controle sobre túneis LSP para um PCE stateful — um PCE stateful ativo controla um ou mais atributos LSP para caminhos de computação, como largura de banda, caminho (ERO) e prioridade (configuração e espera). O PCEP permite essa delegação de LSPs para computação de caminhos.

  • Controle stateful pce de temporização e sequência de computação de caminho dentro e entre sessões PCEP — um PCE stateful ativo modifica um ou mais atributos LSP, como largura de banda, caminho (ERO) e prioridade (configuração e espera). O PCEP comunica esses novos atributos LSP do PCE ao PCC, após os quais o PCC re-sinaliza o LSP no caminho especificado.

Suporte ao protocolo de elementos de computação de caminhos para visão geral do RSVP-TE

Entendendo o MPLS RSVP-TE

A engenharia de tráfego (TE) lida com a otimização de desempenho das redes operacionais, mapeando principalmente fluxos de tráfego em uma topologia física existente. A engenharia de tráfego oferece a capacidade de mover o fluxo de tráfego para longe do caminho mais curto selecionado pelo protocolo de gateway interior (IGP) e para um caminho físico potencialmente menos congestionado em uma rede.

Para a engenharia de tráfego em redes grandes e densas, os recursos MPLS podem ser implementados porque eles potencialmente fornecem a maior parte das funcionalidades disponíveis a partir de um modelo overlay, de forma integrada e a um custo menor do que as alternativas concorrentes atualmente. A principal razão para a implementação da engenharia de tráfego MPLS é o controle de caminhos ao longo dos quais o tráfego flui por uma rede. A principal vantagem da implementação da engenharia de tráfego MPLS é que ela fornece uma combinação dos recursos de engenharia de tráfego do ATM, juntamente com a diferenciação de classe de serviço (CoS) do IP.

Em uma rede MPLS, as informações do plano de dados são encaminhadas usando comutação de rótulos. Um pacote que chega em um roteador de borda (PE) do roteador de borda do cliente (CE) tem rótulos aplicados a ele, e depois é encaminhado para o roteador PE de saída. As etiquetas são removidas no roteador de saída e depois são encaminhadas para o destino apropriado como um pacote IP. Os roteadores de comutação de rótulos (LSRs) no domínio MPLS usam protocolos de distribuição de rótulos para comunicar o significado de rótulos usados para encaminhar tráfego entre e através dos LSRs. RSVP-TE é um protocolo de distribuição de rótulos que permite que um peer LSR aprenda sobre os mapeamentos de rótulos de outros pares.

Quando o MPLS e o RSVP são habilitados em um roteador, o MPLS torna-se um cliente do RSVP. O objetivo principal do software RSVP do Junos OS é oferecer suporte à sinalização dinâmica dentro de caminhos comuados por rótulos (LSPs). O RSVP reserva recursos, como fluxos IP unicast e multicast, e solicita parâmetros de qualidade de serviço (QoS) para aplicativos. O protocolo é estendido na engenharia de tráfego MPLS para permitir que o RSVP configure LSPs que possam ser usados para engenharia de tráfego em redes MPLS.

Quando o MPLS e o RSVP são combinados, os rótulos são associados a fluxos RSVP. Uma vez estabelecido um LSP, o tráfego pelo caminho é definido pelo rótulo aplicado no nó de entrada do LSP. O mapeamento do rótulo para o tráfego é realizado usando critérios diferentes. O conjunto de pacotes que recebem o mesmo valor de rótulo por um nó específico pertence à mesma classe de equivalência de encaminhamento (FEC) e definem efetivamente o fluxo de RSVP. Quando o tráfego é mapeado em um LSP dessa forma, o LSP é chamado de túnel LSP.

Os túneis LSP são uma maneira de estabelecer caminhos unidirecionais comutadores de rótulos. O RSVP-TE se baseia no protocolo de núcleo do RSVP, definindo novos objetos e modificando objetos existentes usados nos objetos PATH e RESV para o estabelecimento de LSP. Os novos objetos — objeto DE SOLICITAÇÃO DE RÓTULO (LRO), objeto DE ROTA DE REGISTRO (RRO), objeto LABEL e objeto EXPLICIT-ROUTE (ERO) — são opcionais em relação ao protocolo RSVP, com exceção dos objetos LRO e LABEL, ambos obrigatórios para a criação de túneis LSP.

Em geral, o RSVP-TE estabelece um caminho comuído por rótulos que garante a entrega de quadros do roteador de entrada à saída. No entanto, com os novos recursos de engenharia de tráfego, as seguintes funções são suportadas em um domínio MPLS:

  • Possibilidade de estabelecer um caminho comutada por rótulos usando uma rota explícita completa ou parcial (RFC 3209).

  • Estabelecimento de LSP baseado em restrições em links que atendem a requisitos, como largura de banda e propriedades de link.

  • Controle de endpoint, associado à criação e gerenciamento de túneis LSP nos roteadores de entrada e saída.

  • Gerenciamento de enlaces, que gerencia recursos de enlaces para fazer roteamento consciente de recursos de LSPs de engenharia de tráfego e para programar rótulos MPLS.

  • O MPLS redireciona rapidamente (FRR), que gerencia os LSPs que precisam de proteção e atribui informações de túnel de backup a esses LSPs.

Limitações atuais do MPLS RSVP-TE

Embora as extensões RSVP para engenharia de tráfego permitam uma melhor utilização da rede e atendam aos requisitos das aulas de tráfego, o conjunto de protocolos MPLS RSVP-TE de hoje tem vários problemas inerentes à sua natureza distribuída. Isso causa uma série de problemas durante a disputa pela capacidade de bisação, especialmente dentro de uma classe prioritária de LSP, onde um subconjunto de LSPs compartilha a configuração comum e detém valores prioritários. As limitações do RSVP-TE incluem:

  • Falta de visibilidade individual por LSP, demandas de largura de banda por dispositivo — Os roteadores de entrada em uma rede MPLS RSVP-TE estabelecem LSPs sem ter uma visão global da demanda de largura de banda na rede. As informações sobre a utilização de recursos de rede só estão disponíveis como capacidade total reservada por classe de tráfego por interface. O estado LSP individual está disponível localmente em cada roteador de borda de rótulo (LER) apenas para seus próprios LSPs. Como resultado, surgem uma série de problemas relacionados ao padrão de demanda, particularmente dentro de uma configuração comum e de manter a prioridade.

  • Natureza assíncronos e independente da sinalização RSVP — No RSVP-TE, as restrições para o estabelecimento de caminhos são controladas por um administrador. Como tal, a largura de banda reservada a um túnel LSP é definida pelo administrador e não implica automaticamente qualquer limite no tráfego enviado pelo túnel. Portanto, a largura de banda disponível em um link de engenharia de tráfego é a largura de banda configurada para o link, excluindo a soma de todas as reservas feitas no link. Assim, as demandas não assinadas em um túnel LSP levam à degradação de serviço do LSP exigindo excesso de largura de banda, bem como os outros LSPs que atendem aos requisitos de largura de banda do link de engenharia de tráfego.

  • LSPs estabelecidos com base em opções de caminho dinâmicas ou explícitas na ordem de preferência — os roteadores de entrada em uma rede MPLS RSVP-TE estabelecem LSPs para demandas com base na ordem de chegada. Como os roteadores de entrada não têm uma visão global da demanda de largura de banda na rede, usar a ordem de preferência para estabelecer LSPs pode fazer com que o tráfego seja descartado ou os LSPs não sejam estabelecidos quando há um excesso de demanda de largura de banda.

Como exemplo, Figura 2 é configurado com MPLS RSVP-TE, no qual A e G são os roteadores de borda de rótulo (LERs). Esses roteadores de entrada estabelecem LSPs de forma independente com base na ordem das demandas e não têm conhecimento ou controle sobre os LSPs uns dos outros. Os roteadores B, C e D são roteadores intermediários ou de trânsito que se conectam aos roteadores de saída E e F.

Figura 2: Exemplo mpls engenharia de tráfegoExemplo mpls engenharia de tráfego

Os roteadores de entrada estabelecem LSPs com base na ordem em que as demandas chegam. Se o Roteador G receber duas demandas de capacidade 5 cada para G-F, g sinaliza dois LSPs — LSP1 e LSP2 — através do G-B-D-F. Da mesma forma, quando o Roteador A recebe a terceira demanda de capacidade 10 para A-E, então ele sinaliza um LSP, LSP3, por A-B-C-E. No entanto, se a demanda no A-E LSP aumentar de 10 para 15, o roteador A não pode sinalizar LSP3 usando o mesmo caminho (A-B-C-E), porque o enlace B-C tem uma capacidade menor.

O roteador A deveria ter sinalizado o aumento da demanda por LSP3 usando o caminho A-B-D-C-E. Como o LSP1 e o LSP2 utilizam o link B-D com base na ordem das demandas recebidas, o LSP3 não é sinalizado.

Assim, embora a largura de banda máxima de fluxo máximo esteja disponível para todos os LSPs, o LSP3 está sujeito a degradação de serviço potencialmente prolongada. Isso se deve à falta de visibilidade da demanda global do Roteador A e à falta de coordenação sistêmica na colocação da demanda pelos roteadores de entrada A e G.

Uso de uma entidade de computação de caminho externo

Como uma solução para as limitações atuais encontradas na computação de caminhos MPLS RSVP-TE, uma entidade de computação de caminhos externos com uma visão global de cada LSP, é necessária uma demanda por dispositivo na rede independentemente da capacidade disponível.

Atualmente, apenas a computação de caminhos de roteamento baseada em restrições em tempo real e on-line é fornecida em uma rede MPLS RSVP-TE. Cada roteador realiza cálculos de roteamento baseados em restrições independentemente dos outros roteadores da rede. Esses cálculos são baseados em informações de topologia disponíveis atualmente — informações geralmente recentes, mas não completamente precisas. As colocações de LSP são otimizadas localmente, com base no status da rede atual. Os túneis MPLS RSVP-TE são configurados usando o CLI. Um operador configura o TE LSP, que é então sinalizado pelo roteador de entrada.

Além dos recursos existentes de engenharia de tráfego, a funcionalidade MPLS RSVP-TE é estendida para incluir uma entidade de computação de caminho externo, chamada de Elemento de Computação de Caminho (PCE). O PCE computa o caminho para os LSPs TE de roteadores de entrada que foram configurados para controle externo. O roteador de entrada que se conecta a um PCE é chamado de cliente de computação de caminho (PCC). O PCC está configurado com o Protocolo de Cliente de Computação de Caminho (PCEP) para facilitar a computação de caminhos externos por um PCE.

Para obter mais informações, veja Componentes da computação de caminhos externos.

Para permitir a computação de caminhos externos para os LSPs TE de um PCC, inclua a lsp-external-controller pccd declaração nos [edit mpls] níveis de hierarquia.[edit mpls lsp lsp-name]

Componentes da computação de caminhos externos

Os componentes que compõem um sistema de computação de caminho externo são:

Elemento de computação de caminhos

Um elemento de computação de caminho (PCE) pode ser qualquer entidade (componente, aplicativo ou nó de rede) que seja capaz de computar um caminho ou rota de rede com base em um gráfico de rede e aplicar restrições computacionais. No entanto, um PCE pode computar o caminho apenas para os LSPs TE de um PCC que foram configurados para controle externo.

Um PCE pode ser stateful ou stateless.

  • PCE stateful — um PCE stateful mantém uma sincronização rigorosa entre o PCE e os estados de rede (em termos de topologia e informações de recursos), juntamente com o conjunto de caminhos computados e recursos reservados em uso na rede. Em outras palavras, um PCE stateful utiliza informações do banco de dados de engenharia de tráfego, bem como informações sobre caminhos existentes (por exemplo, TE LSPs) na rede ao processar novas solicitações do PCC.

    Um PCE stateful é de dois tipos:

    • PCE stateful passivo — mantém a sincronização com o PCC e aprende os estados LSP do PCC a otimizar melhor os cálculos de caminhos, mas não tem controle sobre eles.

    • PCE stateful ativo — modifica ativamente os LSPs do PCC, além de aprender sobre os estados LSP do PCC.

      Nota:

      Em uma configuração redundante com PCEs stateful ativos e principais, o PCE ativo de backup não pode modificar os atributos dos LSPs delegados até que ele se torne o PCE principal no momento de um failover. Não há preempência de PCEs no caso de uma mudança de switch. O PCE principal é apoiado por um PCE de backup, e quando o PCE principal cai, o PCE de backup assume a função do PCE principal e continua a ser o PCE principal mesmo depois do PCE que anteriormente era o PCE principal estar operacional novamente.

    Um PCE stateful fornece as seguintes funções:

    • Oferece computação de caminhos LSP offline.

    • Aciona a re-roteamento LSP quando há a necessidade de re-otimizar a rede.

    • Muda a largura de banda do LSP quando há um aumento na demanda de largura de banda de um aplicativo.

    • Modifica outros atributos LSP no roteador, como ERO, prioridade de configuração e prioridade de manutenção.

    Um PCE tem uma visão global da demanda de largura de banda na rede e mantém um banco de dados projetado para o tráfego para realizar computação de caminhos. Ele realiza coletas de estatísticas de todos os roteadores do domínio MPLS usando SNMP e NETCONF. Isso fornece um mecanismo para o controle offline dos LSPs TE do PCC. Embora um sistema de computação de caminhoSP offline possa ser incorporado em um controlador de rede, o PCE age como um controlador de rede completo que fornece controle sobre os LSPs TE do PCC, além de caminhos de computação.

    Embora um PCE stateful permita a computação de caminhos ideal e o aumento do sucesso da computação de caminhos, ele requer mecanismos de sincronização de estado confiáveis, com sobrecarga de plano de controle potencialmente significativa e a manutenção de uma grande quantidade de dados em termos de estados, como no caso de uma malha completa de LSPs TE.

  • PCE apátrida — um PCE apátrida não se lembra de nenhum caminho computado, e cada conjunto de solicitações é processado independentemente entre si (RFC 5440).

Cliente de computação de caminhos

Um cliente de computação de caminho (PCC) é qualquer aplicativo do cliente que solicita uma computação de caminho a ser realizada por um PCE.

Um PCC pode se conectar a no máximo 10 PCEs ao mesmo tempo. A conexão PCC para PCE pode ser uma rota estática configurada ou uma conexão TCP que estabelece a acessibilidade. O PCC atribui a cada PCE conectado um número de prioridade. Ele envia uma mensagem a todos os PCEs conectados com informações sobre seus LSPs atuais, em um processo chamado sincronização de estado LSP. Para os LSPs TE que têm controle externo habilitado, o PCC delega esses LSPs ao PCE principal. O PCC elege, como o PCE principal, um PCE com o menor número de prioridade, ou o PCE a que se conecta ao primeiro na ausência de um número de prioridade.

O PCC re-sinaliza um LSP com base no caminho computado que recebe de um PCE. Quando a sessão do PCEP com o PCE principal é terminada, o PCC elege um novo PCE principal, e todos os LSPs delegados para o PCE anteriormente principal são delegados ao PCE principal recém-disponível.

Protocolo de elementos de computação de caminho

O protocolo de elementos de computação de caminho (PCEP) é usado para comunicação entre PCC e PCE (bem como entre dois PCEs) (RFC 5440). PCEP é um protocolo baseado em TCP definido pelo IETF PCE Working Group, e define um conjunto de mensagens e objetos usados para gerenciar sessões de PCEP e solicitar e enviar caminhos para LSPs multidomain TE. As interações do PCEP incluem mensagens pcc, bem como notificações de estados específicos relacionados ao uso de um PCE no contexto do MPLS RSVP-TE. Quando o PCEP é usado para comunicação PCE-to-PCE, o PCE solicitado assume a função de um PCC.

Assim, as funções do PCEP incluem:

  • Sincronização do estado do túnel LSP entre o PCC e um PCE stateful.

  • Delegação de controle sobre túneis LSP para um PCE stateful.

Interação entre um PCE e um PCC usando PCEP

Figura 3 ilustra a relação entre UM PCE, PCC e a função do PCEP no contexto do MPLS RSVP-TE.

Figura 3: PCC e RSVP-TEPCC e RSVP-TE

A comunicação PCE para PCC é habilitada pelo PCEP baseado em TCP. O PCC inicia a sessão de PCEP e permanece conectado a um PCE durante a sessão do PCEP.

Nota:

A partir do Junos OS Release 16.1, você pode garantir uma sessão de PCEP usando a autenticação TCP-MD5 de acordo com o RFC 5440. Para habilitar o mecanismo de segurança MD5 para uma sessão de PCEP, é recomendável que você defina e vincule a chave de autenticação MD5 no nível de [edit protocols pcep pce pce-id] hierarquia para uma sessão de PCEP. Você pode, no entanto, também usar um chaveiro predefinido do [edit security authentication-key-chains key-chain] nível de hierarquia para proteger uma sessão de PCEP. Neste caso, você deve vincular o chaveiro predefinido à sessão de PCEP no nível hierárquico [edit protocols pcep pce pce-id] .

O PCE e o PCC usam a mesma chave para verificar a autenticidade de cada segmento enviado na conexão TCP da sessão do PCEP, protegendo assim a comunicação do PCEP entre os dispositivos, que pode estar sujeita a ataques e pode interromper os serviços na rede.

Para obter mais informações sobre como proteger as sessões de PCEP usando a autenticação MD5, veja Autenticação TCP-MD5 para sessões de PCEP.

Uma vez estabelecida a sessão do PCEP, o PCC executa as seguintes tarefas:

  1. Sincronização de estado LSP — o PCC envia informações sobre todos os LSPs (locais e externos) para todos os PCEs conectados. Para LSPs externos, o PCC envia informações sobre qualquer mudança de configuração, mudança de RRO, mudança de estado e assim por diante para o PCE.

    Para LSPs iniciados por PCE, não há configuração de LSP presente no PCC. O PCE que inicia o LSP envia os parâmetros LSP para o PCC que indicou sua capacidade de suporte a LSPs iniciados por PCE.

    Nota:

    O suporte para LSPs iniciados por PCE é fornecido no Junos OS Release 13.3 e versões posteriores.

  2. Delegação LSP — Depois que as informações estaduais do LSP são sincronizadas, o PCC então delega os LSPs externos a um PCE, que é o principal PCE ativo stateful. Apenas o PCE principal pode definir parâmetros para o LSP externo. Os parâmetros que o PCE principal modifica incluem largura de banda, caminho (ERO) e prioridade (configuração e espera). Os parâmetros especificados na configuração local são substituídos pelos parâmetros que são definidos pelo PCE principal.

    Nota:

    Quando a sessão do PCEP com o PCE principal é terminada, o PCC elege um novo PCE principal, e todos os LSPs delegados para o PCE anteriormente principal são delegados ao PCE principal recém-disponível.

    No caso de LSPs iniciados por PCE, o PCC cria o LSP usando os parâmetros recebidos do PCE. O PCC atribui ao LSP iniciado por PCE um LSP-ID exclusivo e delega automaticamente o LSP para o PCE. Um PCC não pode revogar a delegação dos LSPs iniciados pela PCE para uma sessão de PCEP ativa.

    Quando uma sessão de PCEP termina, o PCC inicia dois temporizadors sem excluir imediatamente os LSPs iniciados por PCE – e lsp cleanup timerdelegation cleanup timeout para evitar interrupções nos serviços. Durante este tempo, um PCE stateful ativo pode adquirir o controle dos LSPs provisionados pelo PCE fracassado, enviando uma solicitação de criação para o LSP.

    O controle sobre os LSPs iniciados por PCE reverte para o PCC no término da delegation cleanup timeout. Quando o delegation cleanup timeout expira, e nenhum outro PCE adquiriu o controle sobre o LSP a partir do PCE fracassado, o PCC assume o controle local do LSP iniciado por PCE não delegado. Mais tarde, quando o PCE original ou um novo PCE ativo e stateful deseja adquirir o controle dos LSPs iniciados por PCE controlados localmente, o PCC delega esses LSPs para o PCE e o lsp cleanup timer temporizador é parado.

    Um PCE pode devolver a delegação do LSP iniciado pela PCE ao PCC para permitir a transferência de LSP entre PCEs. Isso aciona o lsp cleanup timer LSP iniciado por PCE. O PCC espera que o temporizador de limpeza LSP expire antes de remover os LSPs iniciados por PCE não delegados do PCE com falha.

    Quando o lsp cleanup timer expira, e nenhum outro PCE adquiriu o controle sobre os LSPs a partir do PCE fracassado, o PCC apaga todos os LSPs provisionados pelo PCE fracassado.

    Nota:

    Em conformidade com o rascunho-ietf-pce-stateful-pce-09, a revogação das delegações LSP iniciadas pela PCE por um PCC acontece de forma de fazer antes do intervalo antes que os LSPs sejam redelegados para um PCE alternativo. A partir do Junos OS Release 18.1R1, deve lsp-cleanup-timer ser maior ou igual ao delegation-cleanup-timeout pcc para revogar as delegações LSP. Se não, o intervalo de tempo de redentor para o PCC pode ser definido para o infinito, onde as delegações de LSP para esse PCE permanecem intactos até que medidas específicas sejam tomadas pelo PCC para alterar os parâmetros definidos pelo PCE.

  3. Sinalização LSP — Ao receber um ou mais parâmetros LSP do PCE stateful principal ativo, o PCC re-sinaliza o TE LSP com base no caminho fornecido pelo PCE. Se o PCC não configurar o LSP, ele notifica o PCE da falha de configuração e aguarda que o PCE principal forneça novos parâmetros para esse LSP e depois re-sinalize.

    Quando o PCE especifica um caminho incompleto ou com saltos soltos onde apenas os endpoints de caminho são especificados, o PCC não realiza roteamento local baseado em restrições para descobrir o conjunto completo de saltos. Em vez disso, o PCC fornece rsVP com o caminho fornecido pelo PCE, como ele é, para sinalização, e o caminho é configurado usando o roteamento IGP hop-by-hop.

Considerando a topologia usada Figura 2, Figura 4 ilustra a implementação parcial do PCE no lado do cliente na rede habilitada para RSVP-TE DO MPLS. Os roteadores de entrada A e G são os PCCs que estão configurados para se conectar ao PCE stateful externo por meio de uma conexão TCP.

O PCE tem uma visão global da demanda de largura de banda na rede e realiza computação de caminhos externos depois de analisar o banco de dados de engenharia de tráfego. O PCE stateful ativo então modifica um ou mais atributos LSP e envia uma atualização para o PCC. O PCC usa os parâmetros que recebe do PCE para re-sinalizar o LSP.

Figura 4: Exemplo PCE para MPLS RSVP-TEExemplo PCE para MPLS RSVP-TE

Dessa forma, o PCE stateful oferece uma operação cooperativa de funcionalidade distribuída usada para enfrentar desafios específicos de uma computação de caminho restringida entre domínios mais curto. Ela elimina cenários de congestionamento em que os fluxos de tráfego são mapeados ineficientemente em recursos disponíveis, causando a superutilização de alguns subconjuntos de recursos de rede, enquanto outros recursos permanecem subutilizados.

Comportamento de LSP com computação externa

Tipos de LSP

Em uma implementação PCE do lado do cliente, existem três tipos de LSPs TE:

  • LSPs controlados por CLI — os LSPs que não têm a lsp-external-controller pccd declaração configurada são chamados de LSPs controlados por CLI. Embora esses LSPs estejam sob controle local, o PCC atualiza os PCEs conectados com informações sobre os LSPs controlados por CLI durante o processo inicial de sincronização de LSP. Após a sincronização inicial do LSP, o PCC informa o PCE de quaisquer LSPs novos e excluídos também.

  • LSPs controlados por PCE — os LSPs que têm a lsp-external-controller pccd declaração configurada são chamados de LSPs controlados por PCE. O PCC delega os LSPs iniciados pelo PCC ao PCE principal para computação de caminhos externos.

    O PCC informa o PCE sobre os parâmetros configurados de um LSP controlado por PCE, como largura de banda, ERO e prioridades. Ele também informa o PCE sobre os valores reais usados para esses parâmetros para configurar o LSP, incluindo o RRO, quando disponível.

    O PCC envia tais relatórios de status de LSP para o PCE apenas quando ocorre uma reconfiguração ou quando há uma mudança no ERO, RRO ou status dos LSPs controlados por PCE sob controle externo.

    Existem dois tipos de parâmetros que vêm da configuração CLI de um LSP para um PCE:

    • Parâmetros que não são substituídos por um PCE e que são aplicados imediatamente.

    • Parâmetros que são substituídos por um PCE. Esses parâmetros incluem largura de banda, caminho e prioridade (valores de configuração e retenção). Quando o modo de controle muda de externo para local, os valores configurados por CLI para esses parâmetros são aplicados na próxima oportunidade de re-sinalizar o LSP. Os valores não são aplicados imediatamente.

  • LSPs provisionados externamente (ou LSPs iniciados por PCE) — Os LSPs que têm a lsp-provisioning declaração configurada são chamados de LSPs iniciados por PCE. Um LSP iniciado por PCE é criado dinamicamente por um PCE externo; como resultado, não há configuração de LSP presente no PCC. O PCC cria o LSP iniciado pela PCE usando os parâmetros fornecidos pelo PCE e delega automaticamente o LSP ao PCE.

    Nota:

    O suporte para LSPs iniciados por PCE é fornecido no Junos OS Release 13.3 e versões posteriores.

Os LSPs controlados por CLI, LSPs controlados por PCE e LSPs iniciados por PCE podem coexistir em um PCC.

Os LSPs controlados por CLI e os LSPs controlados por PCE podem coexistir em um PCC.

Modo de controle LSP

Em uma implementação PCE do lado do cliente, existem dois tipos de modos de controle para um LSP controlado por PCC:

  • Externo — Por padrão, todos os LSPs controlados por PCE estão sob controle externo. Quando um LSP está sob controle externo, o PCC usa os parâmetros fornecidos pelo PCE para configurar o LSP.

  • Local — um LSP controlado por PCE pode ficar sob controle local. Quando o LSP muda de controle externo para controle local, a computação de caminhos é feita usando os parâmetros configurados por CLI e o roteamento baseado em restrições. Tal switchover só acontece quando há um gatilho para re-sinalizar o LSP. Até lá, o PCC usa os parâmetros fornecidos por PCE para sinalizar o LSP controlado por PCE, embora o LSP permaneça sob controle local.

Um LSP controlado por PCE muda para controle local a partir de seu modo de controle externo padrão em casos como sem conectividade a um PCE ou quando um PCE retorna a delegação de LSPs de volta ao PCC.

Para obter mais informações sobre LSPs controlados por CLI e LSPs controlados por PCE, veja Tipos de LSP.

Declarações de configuração suportadas para computação externa

Tabela 1 lista as declarações de configuração de LSP e MPLS existentes que se aplicam a um LSP controlado por PCE.

Tabela 1: Aplicabilidade de MPLS e configurações LSP existentes a um LSP controlado por PCE

Suporte para LSP controlado por PCE

Declarações de configuração LSP aplicáveis

Declarações de configuração MPLS aplicáveis

Essas declarações de configuração podem ser configuradas junto com a configuração do PCE. No entanto, elas só entram em vigor quando a configuração local está em uso. Durante o controle do PCE, essas declarações de configuração permanecem inativas.

  • grupo de administradores

  • largura de banda automática

  • hop-limit

  • menos preenchimento

  • mais preenchimento

  • aleatório

  • grupo de administradores

  • grupos administrativos

  • estendido por grupo de administradores

  • hop-limit

  • sem cspf

  • smart-optimize-timer

Essas declarações de configuração podem ser configuradas junto com a configuração do PCE, mas são anuladas pelos atributos LSP controlados por PCE. No entanto, quando a configuração local está em uso, os valores configurados para essas declarações de configuração são aplicados.

Nota:

Alterações na configuração local usando o CLI enquanto o LSP está sob o controle de um PCE stateful não têm nenhum efeito sobre o LSP. Essas mudanças só entram em vigor quando a configuração local é aplicada.

  • largura de banda

  • primário

  • prioridade

  • prioridade

Essas declarações de configuração não podem ser configuradas junto com a configuração do PCE.

  • p2mp

  • modelo

  • p2mp-lsp-next-hop

O restante das declarações de configuração de LSP são aplicáveis da mesma forma que para os LSPs existentes. Ao configurar qualquer uma das declarações de configuração acima para um LSP controlado por PCE, uma mensagem de log MPLS é gerada para indicar quando os parâmetros configurados entrarão em vigor.

Proteção LSP controlada por PCE

Os caminhos de proteção, incluindo o redirecionamento rápido e o desvio de LSPs, são computados localmente pelo PCC usando roteamento baseado em restrições. Um PCE stateful especifica apenas o caminho primário (ERO). Um PCE também pode acionar um caminho secundário sem standby, mesmo que a configuração local não tenha um caminho secundário sem standby para a proteção de LSP.

ERO LSP controlado por PCE

Para LSPs controlados por PCE (LSPs delegados por PCC e LSPs initados por PCE), apenas um objeto de rota explícita (ERO) completo precisa ser enviado do PCE para o PCC; caso contrário, o PCC rejeita a mensagem PCUpdate ou PCCreate para essa sessão de PCEP.

A partir do Junos OS Release 17.2, além de external cspf, dois novos tipos de computação de caminho são introduzidos para os LSPs controlados por PCE: local cspf e no cspf...

  • local cspf— Um PCC usa o local cspf tipo de computação apenas quando o PCE envia um TLV de fornecedor da Juniper (número da empresa: 0x0a4c) do tipo 5.

  • no cspf— Nem o PCE nem o PCC realizam um cálculo de caminho limitado. Os endpoints e restrições são dados ao módulo RSVP para a configuração do LSP com o caminho IGP.

    Um PCC usa no cspf tipo de computação nos seguintes casos:

    • Quando o PCE envia local cspf tlv, e quando a configuração do Junos OS ou modelo de correspondência para este LSP incluído no-cspf no LSP delegado por PCC.

    • Quando o PCE envia local cspf tlv, e quando o modelo de configuração do Junos OS para este LSP incluído no-cspf no LSP iniciado por PCE.

    • Quando o PCE não envia local cspf TLV com um ERO vazio ou ERO solto (com um bit solto definido no objeto ERO).

Com esses novos tipos de computação, um PCC pode aceitar um objeto ERO, seja como um ERO solto, ou como um ERO vazio. Uma entidade de computação de caminho externo que não é capaz de computar um caminho pode modificar parâmetros como largura de banda e cor, com base nas análises. Nesses casos, é usado um objeto ERO vazio ou ERO solto e o caminho a ser trilhado é decidido pelo PCC.

LSPs RSPs de RSVP-TE controlados por PCE

Após uma sessão de PCEP ser estabelecida entre um PCE e um PCC, o PCC informa todos os LSPs do sistema ao PCE para sincronização de estado de LSP. Isso inclui LSPs ponto a ponto controlados por PCC, delegados por PCE e iniciados por PCE. Começando pelo Junos OS Release 15.1F6 e 16.1R1, esse recurso é estendido para relatar LSPs ponto a multiponto também. Para um PCE, o LSP de ponto a multiponto é semelhante ao RSVP de LSP ponto a multiponto, onde o LSP ponto a multiponto é tratado como coleta de LSPs ponto a ponto agrupados sob um identificador ponto a multiponto.

Por padrão, o controle PCE de LSPs ponto a multiponto não é suportado em um PCC. Para adicionar esse recurso, inclua a p2mp-lsp-report-capability declaração nos [edit protocols pcep pce pce-name] níveis de hierarquia.[edit protocols pcep pce-group group-id] Após a configuração do recurso de relatório ponto a multiponto em um PCC, o PCC anuncia esse recurso para o PCE. Se o PCE anunciar o mesmo recurso de relatório de ponto a multiponto em troca, o PCC reportará a árvore LSP completa de ponto a multiponto ao PCE para sincronização de estado de LSP.

Um PCC com o recurso de LSP TE de ponto a multiponto oferece suporte a relatórios de LSPs TE de ponto a multiponto para PCEs stateful, atualização de ponto a multiponto e banco de dados LSP com suporte ao nome LSP ponto a multiponto como chave. No entanto, os seguintes recursos e funções não são suportados para o Junos OS Release 15.1F6 e 16.1:

  • LSPs estáticos de ponto a multiponto

  • LSPs de ponto a multiponto delegados por PCE e iniciados por PCE

  • Largura de banda automática

  • TE++

  • Mensagem de solicitação e resposta do PCE

  • Criação de LSPs ponto a multiponto usando templates

  • Configuração da entrada avançada nos LSPs de ponto a multiponto iniciados por PCE

  • Configuração da entrada avançada no roteador apontando para um LSP provisionado.

LSPs de ponto a ponto iniciados por PCE

A partir do Junos OS Release 16.1, a funcionalidade PCEP é estendida para permitir que um PCE stateful inicie e provisione LSPs de engenharia de tráfego por meio de um PCC. Anteriormente, os LSPs foram configurados no PCC e o PCC delegou o controle sobre os LSPs externos a um PCE. A propriedade do estado LSP foi mantida pelo PCC. Com a introdução dos LSPs iniciados por PCE, um PCE pode iniciar e provisionar dinamicamente um LSP de engenharia de tráfego ponto a ponto sem a necessidade de um LSP configurado localmente no PCC. Ao receber uma mensagem PCCreate de um PCE, o PCC cria o LSP iniciado pela PCE e delega automaticamente o LSP para o PCE.

Por padrão, um PCC rejeita a solicitação de provisionamento de LSPs ponto a ponto iniciados por PCE de um PCE. Para permitir o suporte de LSPs initados por PCE no PCC, inclua a declaração de provisionamento lsp nos [edit protocols pcep pce pce-id] níveis de hierarquia.[edit protocols pcep pce-group group-id]

Um PCC indica sua capacidade de oferecer suporte a LSPs ponto a ponto iniciados por PCE, ao mesmo tempo em que estabelece a sessão do Protocolo de Elementos de Computação de Caminho (PCEP) com o PCE. Um PCE seleciona um PCC com esse recurso para iniciar um LSP. O PCE fornece ao PCC os parâmetros LSP iniciados por PCE. Ao receber os parâmetros de LSP ponto a ponto iniciados pelo PCE, o PCC configura o LSP, atribui um ID LSP e delega automaticamente o LSP ao PCE.

Quando o PCE que inicia o LSP não fornece os parâmetros de LSP ponto a ponto iniciados por PCE, o PCC usa os parâmetros padrão. Um modelo de LSP opcional também pode ser configurado para especificar valores para o LSP ponto a ponto iniciado por PCE quando os parâmetros LSP não forem fornecidos pelo PCE. Para configurar um modelo LSP para LSPs de ponto a ponto iniciados por PCE no PCC, inclua a declaração de modelo de caminho comutada por rótulos no nível de [edit protocols mpls lsp-external-controller lsp-external-controller] hierarquia.

Quando uma sessão de PCEP termina, o PCC inicia dois temporizadors sem excluir imediatamente osLSPs iniciados por PCE edelegation cleanup timeoutlsp cleanup timerevitar interrupções nos serviços. Durante este tempo, um PCE stateful ativo pode adquirir o controle dos LSPs provisionados pelo PCE com falha.

Um PCE pode devolver a delegação do LSP ponto a ponto iniciado pela PCE ao PCC para permitir a transferência de LSP entre PCEs. O controle sobre os LSPs iniciados pela PCE reverte para o PCC no término do tempo limite de limpeza da delegação. Quando o tempo limite de limpeza da delegação expira, e nenhum outro PCE adquiriu o controle sobre o LSP a partir do PCE fracassado, o PCC assume o controle local do LSP iniciado por PCE não delegado. Mais tarde, quando o PCE original ou um novo PCE ativo e stateful deseja obter o controle dos LSPs ponto a ponto iniciados localmente controlados pela PCE, o PCC delega esses LSPs para o PCE e o temporizador de limpeza LSP é parado.

O PCC espera que o temporizador de limpeza LSP expire antes de excluir os LSPs ponto a ponto iniciados por PCE não delegados do PCE com falha no PCE. Quando o temporizador de limpeza LSP expira, e nenhum outro PCE adquiriu o controle sobre os LSPs a partir do PCE com falha, o PCC exclui todos os LSPs provisionados pelo PCE fracassado.

A partir do Junos OS Release 21.1R1, oferecemos suporte ao roteamento ativo ininterrupto (NSR) para LSPs ponto a ponto e ponto a multiponto iniciados por RSVP iniciados por PCE. Apenas o mecanismo de roteamento primário mantém a sessão de PCEP com o controlador. Ele sincroniza todos os LSPs RSVP iniciados por PCEs, incluindo especificações de fluxo multicast para quaisquer LSPs P2MP iniciados por PCE, com o mecanismo de roteamento de backup. Durante uma troca, a sessão de PCEP cai e se restabelecerá quando o mecanismo de roteamento de backup se torna o mecanismo de roteamento principal. Isso reduz a perda de tráfego para o tráfego transportado por LSPs RSVP iniciados por PCE durante as transições do mecanismo de roteamento. Esse recurso é habilitado quando o NSR é configurado.

LSP de bypass iniciado por PCE

Entendendo os LSPs de bypass iniciados por PCE

Pode haver interrupções de tráfego no momento de uma falha de link ou nó, pois os caminhos de proteção de backup na rede não têm largura de banda suficiente para lidar com o tráfego. Nessas redes, embora um PCE possa ser usado para computar todos os caminhos, para otimizar o desempenho da rede, os caminhos de proteção local também precisam ser controlados pelo PCE.

O Junos OS Release 19.2R1 e versões posteriores fornecem suporte parcial para o draft da Internet draft-cbrt-pce-stateful-local-protection-01 (expira dezembro de 2018), extensões PCEP para RSVP-TE Local-Protection com PCE-Stateful, onde a funcionalidade PCEP é estendida para permitir que um PCE stateful inicie, provisione e gerencie LSPs de bypass para uma interface protegida. LSPs de bypass múltiplos com reserva de largura de banda podem ser iniciados pelo PCE para proteger um link ou nó. Espera-se que a largura de banda no LSP de bypass seja menor do que a largura de banda total dos LSPs primários que ele pode proteger.

O mecanismo de seleção de bypass existente, que prefere LSPs de bypass manual (se disponíveis) em vez de LSPs dinâmicos de bypass, é estendido para preferir LSPs de bypass provisionados por PCE (se disponíveis) em vez de LSPs dinâmicos de bypass. Os LSPs de bypass provisionados por PCE têm uma preferência maior em relação aos LSPs dinâmicos de bypass, mas são menos preferidos em relação aos LSPs de bypass manual.

O conjunto de operações que são usadas para executar em qualquer LSPs de bypass operacional, como clear rsvp session, também pode ser executado nos LSPs de bypass iniciados pela PCE. Você pode usar comandos como show path-computation-client status extensive e show path-computation-client lsp visualizar estatísticas LSP de bypass iniciadas por PCE.

Com o suporte do LSP de bypass iniciado por PCE, você pode:

  • Crie um desvio de RSVP LSP por PCEP a partir de um controlador externo, onde o LSP de bypass:

    • pode ser para proteção de enlaces ou nós.

    • deve ter uma largura de banda não zero.

    • deve ter um ERO rigoroso especificado.

  • Atualize a largura de banda e o ERO para um LSP de bypass criado por PCE.

  • Inscreva-se em excesso na largura de banda LSP de bypass para controle de admissão de LSPs primários. Este deve ser um parâmetro por bypass e deve permitir a atualização da assinatura por LSP de bypass.

Benefícios do LSP de bypass iniciado por PCE

Os LSPs de bypass iniciados pela PCE oferecem os seguintes benefícios:

  • Melhor controle sobre o tráfego após uma falha e uma computação de caminhos mais determinística de caminhos de proteção.

  • Atenda a restrições complexas e requisitos de diversidade, como a manutenção de caminhos diversos para LSPs, bem como seus caminhos de proteção local.

  • Certifique-se de que os links não estejam sobrecarregados durante eventos de falha.

Comportamento dos LSPs de bypass iniciados por PCE durante a falha na sessão do PCEP

No momento de uma falha na sessão do PCEP, os LSPs de bypass iniciados por PCE ficam órfãos até o término do temporizador de estado. Os LSPs de bypass iniciados por PCE são limpos na expiração do temporizador de estado. Para obter o controle de um LSP de bypass iniciado por PCE (após a sessão do PCEP falhar), um PCE (seja o PCE primário ou qualquer PCE secundário) envia uma mensagem pcInitiate antes do término do tempo limite do estado.

LSPs de ponto a multiponto iniciados por PCE

Com a introdução de LSPs iniciados por PCE de ponto a multiponto, um PCE pode iniciar e provisionar um LSP ponto a multiponto dinamicamente sem a necessidade de configuração de LSP local no PCC. Isso permite que o PCE controle o tempo e a sequência das computação de caminhos de ponto a multiponto dentro e por todas as sessões do Protocolo de Elementos de Computação de Caminho (PCEP), criando assim uma rede dinâmica que é controlada e implantada centralmente.

Para obter mais informações, consulte Understanding Path Computation Element Protocol para MPLS RSVP-TE com suporte para LSPs de ponto a multiponto iniciados por PCE.

SRv6 LSP em PCEP

O roteamento por segmentos pode ser aplicado ao plano de encaminhamento MPLS e IPv6. O elemento de computação de caminho (PCE) computa caminhos SR para o plano de encaminhamento MPLS e IPv6. O roteamento por segmentos para PCEP oferece suporte a LSPs SR, como PCE iniciado, criado localmente e LSPs SR delegados no plano de encaminhamento IPv6.

Benefícios dos LSPs SRv6 no PCEP

  • Permite que você crie SRv6 LSPs iniciados por PCE.
  • Delegar os LSPs SRv6 criados no roteador para o controlador.
  • Reporte os LSPs criados localmente no roteador para o controlador.
  • A programação de rede SRv6 oferece a flexibilidade para aproveitar o roteamento por segmentos sem implantar o MPLS.

O PCEP oferece suporte à criação, updation e exclusão de LSPs SRv6 coloridos e não coloridos. Quando o PCE iniciou o SRv6 LSP coexiste junto com um SRv6 LSP estático para o mesmo IP ou IP baseado em cores, então a rota de contribuição SRv6 TE LSP estática é preferida em relação à rota de contribuição SRv6 TE LSP iniciada pelo PCE.

Para configurar uma sessão de PCEP para ser capaz de SRv6, você precisa habilitar a srv6-capability declaração de configuração nos [protocolos de edição pcep pce pce-id] ou nos níveis [edit protocols pcep pce-group pce-id] de hierarquia. Se a srv6-capability declaração de configuração estiver habilitada, você também deve habilitar a declaração de configuração srv6 no nível [edit protocols source-packet-routing] de hierarquia de outra forma durante o compromisso e o erro será exibido.

Para configurar o SRv6 para SR-TE, você precisa adicionar a declaração de configuração srv6 no nível de hierarquia [editar protocolos de roteamento de pacotes de origem].

[Veja como entender a política SR-TE para túnel SRv6 para obter mais informações.

Para configurar a profundidade máxima da lista de segmentos para SRv6 LSP, você precisa habilitar a declaração de maximum-srv6-segment-list-depth configuração no nível [edit protocols pcep] de hierarquia.

Largura de banda automática e LSP controlado por PCE

A partir do Junos OS Release 14.2R4, o suporte à largura de banda automática é fornecido para LSPs controlados por PCE. Em versões anteriores, a opção de largura de banda automática não se aplicava aos LSPs controlados por PCE, embora os LSPs sob o controle de auto-bandwdith e roteamento baseado em restrições pudessem coexistir com LSPs controlados por PCE. A coleta de estatísticas para largura de banda automática só estava surtindo efeito quando o modo de controle de um LSP controlado por PCE muda de externo para local. Isso estava acontecendo em casos como nenhuma conectividade a um PCE ou quando um PCE retorna a delegação de LSPs de volta ao PCC.

Autenticação TCP-MD5 para sessões de PCEP

Um servidor PCE stateful automatiza a criação de caminhos de engenharia de tráfego por toda a rede, aumentando a utilização da rede e permitindo uma experiência de rede programável personalizada com o uso da comunicação pcep com um PCC. Um PCC envia relatórios LSP para um servidor PCE, e o PCE atualiza ou provisiona LSPs de volta ao PCC. Os dados enviados em uma sessão de PCEP são cruciais para que um servidor PCE realize a computação de caminhos externos. Como resultado, um ataque à comunicação do PCEP pode interromper os serviços de rede. Se as mensagens PCEP alteradas forem enviadas a um PCC, LSPs inapropriados podem ser configurados. Da mesma forma, se as mensagens PCEP alteradas forem enviadas a um PCE, uma visão incorreta da rede é aprendida pelo PCE.

Considerando a importância da comunicação do PCEP entre um PCE e o PCC na execução efetiva das funcionalidades pce, o Junos OS Release 16.1 apresenta o recurso de proteger uma sessão pcep usando autenticação TCP-MD5 de acordo com RFC 5440. Esse recurso protege a comunicação entre um PCE e o PCC durante uma sessão de PCEP, que pode estar sujeita a um ataque, e pode interromper os serviços de rede.

Para habilitar o mecanismo de segurança MD5 para uma sessão de PCEP, é recomendável que você defina e vincule a chave de autenticação MD5 no nível de [edit protocols pcep pce pce-id] hierarquia para uma sessão de PCEP. Você pode, no entanto, também usar um chaveiro predefinido do [edit security authentication-key-chains key-chain] nível de hierarquia para proteger uma sessão de PCEP. Neste caso, você deve vincular o chaveiro predefinido à sessão de PCEP no nível hierárquico [edit protocols pcep pce pce-id] .

A configuração a seguir é executada no PCC para estabelecer uma sessão de PCEP segura com um PCE:

  • Usando a chave de autenticação MD5:

  • Usando chaveiro de autenticação predefinido:

Para que sessões de PCEP seguras sejam estabelecidas com sucesso, a autenticação MD5 deve ser configurada com a chave de autenticação pré-compartilhada no servidor PCE e no PCC. O PCE e o PCC usam a mesma chave para verificar a autenticidade de cada segmento enviado na conexão TCP da sessão do PCEP.

Nota:
  • O Junos OS Release 16.1 oferece suporte apenas à autenticação TCP-MD5 para sessões de PCEP, sem estender o suporte para TLS e TCP-AO, como proteção contra espionagem, adulteração e falsificação de mensagens.

  • A aplicação inicial do mecanismo de segurança em uma sessão de PCEP faz com que a sessão seja reiniciada.

  • Se o MD5 estiver mal configurado ou não estiver configurado em um lado da sessão do PCEP, a sessão não será estabelecida. Verifique se as configurações no PCC e PCE estão combinando.

  • Esse recurso não oferece suporte para nenhum mecanismo de autenticação de sessão.

  • Para visualizar o keychain de autenticação usado pela sessão do PCEP, use as show path-computation-client status saídas e show protocols pcep comandos.

  • Use o show system statistics tcp | match auth comando para visualizar o número de pacotes que são descartados pelo TCP devido a erros de autenticação.

  • A operação do chaveiro pode ser verificada usando a show security keychain detail saída de comando.

Impacto da implementação de PCE do lado do cliente no desempenho da rede

A manutenção de um banco de dados stateful pode não ser trivial. Em um único ambiente PCE centralizado, um PCE stateful simplesmente precisa lembrar todos os LSPs TE que o PCE computou, os LSPs TE que foram realmente configurados (se isso pode ser conhecido) e quando os LSPs TE foram demolidos. No entanto, esses requisitos causam sobrecarga substancial do protocolo de controle em termos de estado, uso e processamento de rede e otimização de links globalmente em toda a rede. Assim, as preocupações de uma implementação de PCE stateful incluem:

  • Qualquer mecanismo de sincronização confiável resulta em sobrecarga significativa do plano de controle. Os PCEs podem sincronizar o estado comunicando-se entre si, mas quando os LSPs TE são configurados usando computação distribuída realizada entre vários PCEs, os problemas de sincronização e prevenção da condição racial se tornam maiores e mais complexos.

  • A sincronização de banco de dados de engenharia de tráfego fora de banda pode ser complexa com vários PCEs configurados em um modelo de computação PCE distribuído, e pode ser propensa a condições de corrida, preocupações com escalabilidade e assim por diante.

  • Os cálculos de caminho que incorporam o estado total da rede são altamente complexos, mesmo que o PCE tenha informações detalhadas sobre todos os caminhos, prioridades e camadas.

Apesar das preocupações acima, a implementação parcial do PCE stateful no lado do cliente é extremamente eficaz em grandes sistemas de engenharia de tráfego. Ele oferece convergência rápida e benefícios significativos em termos de uso ideal de recursos, fornecendo o requisito de visibilidade global de um estado LSP TE e para o controle ordenado de reservas de caminho em dispositivos dentro do sistema que está sendo controlado.

Exemplo: Configuração do protocolo de elementos de computação de caminho para MPLS RSVP-TE

Este exemplo mostra como permitir a computação de caminhos externos por um elemento de computação de caminho (PCE) para caminhos comuados por rótulos projetados em tráfego (TE LSPs) em um cliente de computação de caminho (PCC). Ele também mostra como configurar o Protocolo de Elementos de Computação de Caminho (PCEP) no PCC para permitir a comunicação do PCE ao PCC.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Três roteadores que podem ser uma combinação de roteadores da Série ACX, roteadores de borda multisserviço da Série M, plataformas de roteamento universal 5G da Série MX, roteadores de núcleo da Série T ou roteador de transporte da Série PTX, um dos quais é configurado como um PCC.

  • Uma conexão TCP com um PCE stateful externo do PCC.

  • Junos OS Release 12.3 ou posterior no PCC, juntamente com o pacote complementar JSDN.

Nota:

O pacote complementar JSDN é necessário para ser instalado junto com o pacote de instalação núcleo do Junos OS.

Antes de começar:

  1. Configure as interfaces do dispositivo.

  2. Configure MPLS e RSVP-TE.

  3. Configure o IS-IS ou qualquer outro protocolo IGP.

Visão geral

A partir do Junos OS Release 12.3, a funcionalidade MPLS RSVP-TE é estendida para fornecer uma implementação parcial no lado cliente da arquitetura PCE stateful (draft-ietf-pce-stateful-pce) em um PCC.

Nota:

A implementação parcial do lado cliente da arquitetura PCE stateful é baseada na versão 2 do draft da Internet draft-ietf-pce-stateful-pce. A partir do Junos OS Release 16.1, esta implementação é atualizada para oferecer suporte à versão 7, conforme definido no draft da Internet draft-ietf-pce-stateful-pce-07. Versões anteriores ao 16.1 suportam a versão mais antiga do draft do PCE, causando problemas de interoperabilidade entre um PCC executando uma versão anterior e um servidor PCE stateful que adere ao rascunho da Internet draft-ietf-pce-stateful-pce-07.

Para permitir a computação de caminhos externos por um PCE, inclua a lsp-external-controller declaração sobre o PCC nos [edit mpls] níveis de hierarquia.[edit mpls lsp lsp-name]

Um LSP configurado com a lsp-external-controller declaração é referido como um LSP controlado por PCE e está sob o controle externo de um PCE por padrão. Um PCE stateful ativo pode substituir os parâmetros definidos a partir da CLI, como largura de banda, caminho (ERO) e prioridade, para tais LSPs controlados por PCE do PCC.

Para permitir a comunicação do PCE para PCC, configure o PCEP no PCC no nível hierárquico [edit protocols] .

Ao configurar o PCEP em um PCC, fique atento às seguintes considerações:

  • O pacote complementar JSDN é necessário para ser instalado junto com o pacote de instalação núcleo do Junos OS.

  • O Junos OS Release 12.3 oferece suporte apenas a PCEs stateful.

  • Um PCC pode se conectar a no máximo 10 PCEs stateful. Em qualquer momento, pode haver apenas um PCE principal (o PCE com o menor valor de prioridade, ou o PCE que se conecta ao PCC primeiro na ausência de uma prioridade pce) ao qual o PCC delega LSPs para computação de caminhos.

  • Para o Junos OS Release 12.3, o PCC sempre inicia as sessões de PCEP. As sessões de PCEP iniciadas por PCEs remotos não são aceitas pelo PCC.

  • Os recursos LSP existentes, como a proteção de LSP e o make-before-break, funcionam para LSPs controlados por PCE.

  • A opção de largura de banda automática é desativada para LSPs controlados por PCE, embora os LSPs sob o controle de auto-bandwdith e roteamento baseado em restrições possam coexistir com LSPs controlados por PCE.

  • Os LSPs controlados por PCE podem ser referidos por outras configurações de CLI, como lsp-nexthop para rotas, encaminhamento de adjacências, conexões CCC e túneis lógicos.

  • Os LSPs controlados por PCE não oferecem suporte ao GRES.

  • Os LSPs controlados por PCE sob sistemas lógicos não são suportados.

  • Os LSPs controlados por PCE não podem ser LSPs ponto a multiponto.

  • Os LSPs bidirecionais não são suportados.

  • Os LSPs controlados por PCE não podem ter caminhos secundários sem um caminho primário.

  • Os LSPs controlados por PCE dependem da computação de caminhos externos, o que afeta o tempo de configuração geral, redirecionamentos e recursos de make-before-break.

  • O tempo de configuração e o tempo de convergência (redirecionamento, MBB) para exisiting de LSPs é o mesmo que em versões anteriores, na ausência de LSPs controlados por PCE. No entanto, um pequeno impacto é visto na presença de LSPs controlados por PCE.

  • Espera-se que o tempo de computação de ERO seja significativamente maior do que o CSPF local.

Topologia

Figura 5: Configuração do PCEP para MPLS RSVP-TEConfiguração do PCEP para MPLS RSVP-TE

Neste exemplo, o PCC é o roteador de entrada que se conecta ao PCE ativo externo.

Os LSPs externos do Roteador PCC são computados da seguinte forma:

  1. O Roteador PCC recebe a configuração de túnel LSP que foi configurada usando o CLI. Assumindo que a configuração recebida seja habilitada com computação de caminhos externos, o Roteador PCC passa a perceber que alguns dos atributos LSP — largura de banda, caminho e prioridade — estão sob o controle do PCE stateful e delegam o LSP para o PCE.

    Neste exemplo, o LSP externo é chamado PCC-to-R2 e está sendo configurado do Roteador PCC ao Roteador R2. O ERO configurado por CLI é PCC-to-R2 PCC-R0-R1-R2. A largura de banda é de PCC-to-R2 10m, e tanto os valores de configuração quanto de prioridade de manutenção são 4.

  2. O ROTEADOR PCC tenta recuperar os atributos LSP controlados por PCE. Para isso, o Roteador PCC envia uma mensagem PCRpt para o PCE stateful afirmando que o LSP foi configurado. A mensagem PCRpt comunica o status do LSP e contém os parâmetros de configuração locais do LSP.

  3. O PCE stateful modifica um ou mais dos atributos LSP delegados e envia os novos parâmetros LSP para o Roteador PCC por meio da mensagem PCUpd.

  4. Ao receber os novos parâmetros LSP, o Roteador PCC configura um novo LSP e re-sinaliza usando o caminho fornecido por PCE.

    Neste exemplo, o ERO fornecido por PCC-to-R2 PCE é PCC-R3-R2. A largura de banda é de PCC-to-R2 8m, e tanto os valores de configuração quanto de prioridade de manutenção são 3.

  5. O Roteador PCC envia um PCRpt com o novo RRO para o PCE stateful.

Configuração

Configuração rápida da CLI

Para configurar este exemplo rapidamente, 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 [edit] hierarquia.

PCC

R0

R1

R2

R3

Procedimento

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração.

Para configurar o Roteador PCC:

Nota:

Repita este procedimento para todos os roteadores de entrada da Juniper Networks no domínio MPLS, depois de modificar os nomes, endereços e quaisquer outros parâmetros apropriados para cada roteador.

  1. Configure as interfaces.

    Para habilitar o MPLS, inclua a família de protocolo na interface para que a interface não descarte o tráfego MPLS de entrada.

  2. Habilite o RSVP em todas as interfaces do Roteador PCC, sem a interface de gerenciamento.

  3. Configure o caminho comuto de rótulo (LSP) do ROTEADOR PCC para o Roteador R2 e habilite o controle externo de LSPs pelo PCE.

  4. Configure o LSP do Roteador PCC para o Roteador R2, que tem controle local e é substituído pelos parâmetros LSP fornecidos por PCE.

  5. Habilite o MPLS em todas as interfaces do Roteador PCC, sem a interface de gerenciamento.

  6. Configure o IS-IS em todas as interfaces do Roteador PCC, sem a interface de gerenciamento.

  7. Defina o PCE ao qual o ROTEADOR PCC se conecta e configure o endereço IP do PCE.

  8. Configure a porta de destino para o Roteador PCC que se conecta a um PCE usando o PCEP baseado em TCP.

  9. Configure o tipo PCE.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show interfaces comandos e show protocols os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Confirme se a configuração está funcionando corretamente.

Verificando o status da sessão do PCEP

Propósito

Verifique o status da sessão do PCEP entre o PCE e o Roteador PCC quando o status do PCE estiver em alta.

Ação

A partir do modo operacional, execute o show path-computation-client active-pce comando.

Significado

A saída exibe informações sobre o PCE ativo e ativo ao qual o PCC do roteador está conectado. O PCE status campo de saída indica o status atual da sessão de PCEP entre o PCE e o Roteador PCC.

Para pce1, o status da sessão de PCEP é PCE_STATE_UP, o que indica que a sessão do PCEP foi estabelecida entre os pares do PCEP.

As estatísticas PCRpts indicam o número de mensagens enviadas pelo Roteador PCC ao PCE para relatar o status atual dos LSPs. As PCUpdates estatísticas indicam o número de mensagens recebidas pelo Roteador PCC do PCE. As PCUpdates mensagens incluem os parâmetros modificados do PCE para os LSPs controlados por PCE.

Verificando o status de LSP controlado por PCE quando o controle de LSP é externo

Propósito

Verifique a situação do LSP controlado por PCE do Roteador PCC ao Roteador R2 quando o LSP estiver sob controle externo.

Ação

A partir do modo operacional, execute o show mpls lsp name PCC-to-R2 extensive comando.

Significado

Na saída, os LSPtype campos de saída mostram LSP Control Status que o LSP é controlado externamente. A saída também mostra um log das mensagens PCEP enviadas entre o Roteador PCC e o PCE.

A sessão de PCEP entre o PCE e o Roteador PCC está ativa, e o Roteador PCC recebe os seguintes parâmetros LSP controlados por PCE:

  • ERO (caminho)— 20.31.4.2 e 20.31.5.2

  • Largura de banda — 8Mbps

  • Prioridades — 3 3 (valores de configuração e retenção)

Verificando o status de LSP controlado por PCE quando o controle de LSP é local

Propósito

Verifique a situação do LSP controlado por PCE do Roteador PCC ao Roteador R2 quando o controle LSP se tornar local.

Ação

A partir do modo operacional, execute o show mpls lsp name PCC-to-R2 extensive comando.

Significado

Na saída, o LSP Control Status campo de saída mostra que o LSP está sob controle local. Embora o LSP controlado por PCE esteja sob controle local, o Roteador PCC continua a usar os parâmetros fornecidos pelo PCE até a próxima oportunidade de re-sinalizar o LSP.

A saída agora exibe os parâmetros LSP que foram configurados usando o CLI juntamente com os parâmetros fornecidos por PCE usados para estabelecer o LSP como os valores reais em uso.

  • Largura de banda — 10Mbps (largura de banda real: 8Mbps)

  • Prioridades — 4 4 (RealPriorities 3 3)

No gatilho para re-sinalizar o LSP, o Roteador PCC usa os parâmetros de configuração locais para estabelecer o LSP controlado por PCE.

São Computed ERO 20,31,1,2, 20,31,2,2 e 20,31,8,2. O LSP controlado por PCE é estabelecido usando os parâmetros de configuração locais.

Exemplo: Configuração do protocolo de elementos de computação de caminhos para MPLS RSVP-TE com suporte de LSPs de ponto a ponto iniciados por PCE

Este exemplo mostra como configurar o cliente de computação de caminho (PCC) com a capacidade de oferecer suporte a caminhos comutados de rótulos de ponto a ponto (LSPs) iniciados pelo elemento de computação de tráfego (PCE).

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Três roteadores que podem ser uma combinação de roteadores série ACX, Série M, Série MX ou Série T.

  • Uma conexão TCP com dois PCEs stateful externos do roteador de entrada (PCC).

  • Junos OS Release 16.1 ou posterior no PCC.

Antes de começar:

  • Configure as interfaces do dispositivo.

  • Configure MPLS e RSVP-TE (RSVP-Traffic Engineering).

  • Configure o OSPF ou qualquer outro protocolo IGP.

Visão geral

A partir do Junos OS Release 16.1, a funcionalidade PCEP é estendida para permitir que um PCE stateful inicie e provisione LSPs de engenharia de tráfego por meio de um PCC. Anteriormente, os LSPs foram configurados no PCC e o PCC delegou o controle sobre os LSPs externos a um PCE. A propriedade do estado LSP foi mantida pelo PCC. Com a introdução dos LSPs iniciados por PCE, um PCE pode iniciar e provisionar dinamicamente um LSP de engenharia de tráfego ponto a ponto sem a necessidade de um LSP configurado localmente no PCC. Ao receber uma mensagem PCCreate de um PCE, o PCC cria o LSP iniciado pela PCE e delega automaticamente o LSP para o PCE.

Ao configurar o suporte de LSPs ponto a ponto iniciados por PCE para um PCC, esteja ciente das seguintes considerações:

  • O Junos OS Release 13.3 oferece suporte apenas a PCEs stateful.

  • Para o Junos OS Release 13.3, o PCC sempre inicia as sessões de PCEP. As sessões de PCEP iniciadas por PCEs remotos não são aceitas pelo PCC.

  • Os recursos LSP existentes, como a proteção contra LSP e o make-before-break, funcionam para LSPs iniciados por PCE.

  • Os LSPs iniciados por PCE não oferecem suporte a switchover gracioso do Mecanismo de Roteamento (GRES).

  • Os LSPs iniciados por PCE sob sistemas lógicos não são suportados.

  • Os LSPs iniciados por PCE não podem ser LSPs de ponto a multiponto.

  • Os LSPs bidirecionais não são suportados.

  • O RSVP-TE para links não numerados não é suportado. Os LSPs iniciados por PCE oferecem suporte apenas a links numerados.

  • O PCE que inicia um LSP de roteamento por segmentos pode usar os rótulos de ID de segmentos de ligação (SID) associados a LSPs de roteamento por segmentos não coloridos para provisionar os caminhos LSP de roteamento por segmentos iniciados por PCE.

    A partir do Junos OS Release 18.2R1, LSPs de roteamento de segmentos não coloridos configurados na entrada do dispositivo são relatados a um PCE por meio de uma sessão de PCEP. Esses LSPs de roteamento por segmentos não coloridos podem ter rótulos SID de ligação associados a eles. Com esse recurso, o PCE pode usar este rótulo SID de ligação na pilha de rótulos para provisionar caminhos LSP de roteamento por segmentos iniciados por PCE.

Topologia

Figura 6: Exemplo de LSP ponto a ponto com pce initado para MPLS RSVP-TEExemplo de LSP ponto a ponto com pce initado para MPLS RSVP-TE

Neste exemplo, o PCC é o roteador de entrada que se conecta a dois PCEs stateful externos: PCE1 e PCE2.

Quando há uma nova demanda, o PCE stateful ativo inicia dinamicamente um LSP para atender ao requisito. Como o PCC está configurado com a capacidade de dar suporte ao LSP iniciado pelo PCE, a computação de caminhos no PCC é realizada da seguinte forma:

  1. Um PCE envia uma mensagem PCCreate ao PCC para iniciar e provisionar um LSP. O PCC configura o LSP iniciado por PCE usando os parâmetros recebidos do PCE, e delega automaticamente o LSP iniciado pela PCE para o PCE que o iniciou.

    Neste exemplo, o PCE1 é o PCE stateful ativo que inicia e provisiona o LSP iniciado por PCE no PCC. Ao receber os parâmetros LSP iniciados pela PCE, o PCC configura o LSP e delega automaticamente o LSP iniciado pela PCE ao PCE1.

  2. Quando a sessão de PCEP entre PCC e PCE1 é terminada, o PCC inicia dois temporizadores para o LSP iniciado pelo PCE1: tempo limite de limpeza de delgação e o tempor de limpeza LSP. Durante esse período, PCE1 ou PCE2 podem adquirir o controle do LSP iniciado por PCE.

  3. Se o PCE2 adquirir o controle sobre o LSP iniciado pela PCE antes da expiração do temporizador de limpeza LSP, o PCC delega o LSP iniciado pela PCE para PCE2, e o temporizador de limpeza de LSP e o tempo limite de limpeza da delegação serão interrompidos.

  4. Se o tempo limite de limpeza da delegação expirar, e nem o PCE1 nem o PCE2 adquiriram o controle sobre o LSP iniciado pela PCE, o PCC assume o controle local do LSP iniciado por PCE não delegado até o término do temporizador de limpeza LSP.

  5. Após a expiração do temporizador de limpeza LSP, o PCC apaga o LSP iniciado por PCE provisionado pelo PCE1.

Configuração

Configuração rápida da CLI

Para configurar este exemplo rapidamente, 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 [edit] hierarquia.

PCC

R1

R2

Procedimento

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração.

Para configurar o roteador PCC:

Nota:

Repita este procedimento para todos os roteadores de entrada da Juniper Networks no domínio MPLS, depois de modificar os nomes, endereços e quaisquer outros parâmetros apropriados para cada roteador.

  1. Configure as interfaces.

    Para habilitar o MPLS, inclua a família de protocolo na interface para que a interface não descarte o tráfego MPLS de entrada.

  2. Habilite o RSVP em todas as interfaces do PCC, excluindo a interface de gerenciamento.

  3. Habilite o controle externo dos LSPs pelos PCEs.

  4. Habilite o MPLS em todas as interfaces do PCC, excluindo a interface de gerenciamento.

  5. Configure o OSPF em todas as interfaces do PCC, excluindo a interface de gerenciamento.

  6. Defina o grupo PCE e habilite o suporte de LSPs iniciados por PCE para o grupo PCE.

  7. Definir os PCEs que se conectam ao PCC.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show interfaces comandos e show protocols os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Confirme se a configuração está funcionando corretamente.

Verificação do status do PCC

Propósito

Verifique o status da sessão do PCEP e o resumo do LSP entre o PCC e os PCEs conectados.

Ação

A partir do modo operacional, execute o show path-computation-client status comando.

Significado

A saída exibe o status da sessão de PCEP entre os PCEs stateful ativos e o PCC. Ele também exibe informações sobre os diferentes tipos de LSPs no PCC, e o número de LSPs provisionados pelos PCEs conectados e delegados a eles.

PCE1 é o PCE ativo principal e tem um LSP iniciado por PCE que foi automaticamente delegado a ele pelo PCC.

Verificando o status do PCE1

Propósito

Verifique o status do PCE stateful ativo principal.

Ação

A partir do modo operacional, execute o show path-computation-client active-pce detail comando.

Significado

A saída exibe informações sobre o PCE ativo e ativo atual ao qual o PCC está conectado. O PCE status campo de saída indica o status atual da sessão de PCEP entre um PCE e o PCC.

Para PCE1, o status da sessão do PCEP é PCE_STATE_UP, o que indica que a sessão do PCEP foi estabelecida com o PCC.

Verificando o status de LSP iniciado pela PCE quando o LSP está provisionado externamente

Propósito

Verifique a situação do LSP iniciado por PCE.

Ação

A partir do modo operacional, execute o show mpls lsp externally-provisioned detail comando.

Significado

Na saída, o LSPtype campo de saída mostra que o LSP está provisionado externamente.

A sessão de PCEP entre PCC e PCE1 está ativa, e o PCC recebe os seguintes parâmetros de LSP iniciados por PCE:

  • ERO (caminho)— 10.0.102.10 e 10.0.101.9

  • Largura de banda — 8 Mbps

  • Prioridade — 7 0 (valores de configuração e retenção)

Configuração do protocolo de elementos de computação de caminhos para MPLS RSVP-TE com suporte de LSPs de ponto a ponto iniciados por PCE

Você pode configurar um cliente de computação de caminho (PCC) com a capacidade de oferecer suporte a caminhos de comutação de rótulos (LSPs) criados dinamicamente a partir de uma entidade centralizada de computação de caminhos externos. Um elemento de computação de caminho (PCE) stateful pode ser usado para realizar a computação de caminhos externos e gerar LSPs dinâmicos quando há um aumento na demanda.

Um PCC cria o LSP ponto a ponto iniciado por PCE usando os parâmetros de LSP fornecidos por PCE, ou parâmetros de um modelo de LSP pré-configurado quando o PCE não provisiona o LSP e delega automaticamente o LSP de ponto a ponto iniciado por PCE para o respectivo PCE. Como resultado, para LSPs iniciados por PCE, não há necessidade de um LSP configurado localmente no PCC.

Um LSP controlado por CLI, LSP controlado por PCE e LSP iniciado por PCE podem coexistir entre si em um PCC.

Antes de começar:

  • Configure as interfaces do dispositivo.

  • Configure MPLS e RSVP-TE.

  • Configure o OSPF ou qualquer outro protocolo IGP.

Para configurar o PCC para oferecer suporte a LSPs ponto a ponto iniciados por PCE, preencha as seguintes tarefas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:
  2. Especifique o número de mensagens por minuto que o PCC pode receber no máximo.
  3. Especifique o número de caminhos de comutadas de rótulo (LSPs) provisionados externamente em todos os PCEs conectados que o PCC pode aceitar no máximo.
  4. Especifique o ID definido pelo usuário exclusivo para o PCE conectado para configurar os parâmetros do PCE.
  5. Especifique a quantidade de tempo (em segundos) que o PCC deve esperar antes de devolver o controle dos LSPs ao processo de protocolo de roteamento após uma sessão de PCEP ser desconectada.
  6. Especifique o endereço IPv4 do PCE para se conectar.
  7. Especifique o número de porta TCP que o PCE está usando

    O valor pode variar de 1 a 65535 e o valor padrão é 4189.

  8. Especifique a quantidade de tempo (em segundos) que o PCC deve esperar antes de excluir quaisquer LSPs iniciados por PCE não delegados do PCE com falha após o término de uma sessão de PCEP.
  9. Configure o PCC para aceitar SPs que são provisionados externamente por PCEs conectados. Por padrão, o PCC rejeita LSPs iniciados por PCE.
  10. Especifique o número de mensagens desconhecidas por minuto que o PCC pode receber no máximo após a qual a sessão do PCEP é fechada.

    O valor pode variar de 1 a 16384, e o valor padrão é 0 (desativado ou sem limite).

  11. Especifique o número de solicitações desconhecidas por minuto que o PCC pode receber no máximo após a qual a sessão do PCEP é terminada.

    O valor pode variar de 0 a 16384, e o valor padrão é 5. Um valor de 0 desativa esta declaração.

  12. Configure o tipo PCE.
  13. Especifique a quantidade de tempo (em segundos) que o PCC deve esperar por uma resposta antes de refazer uma solicitação.

    O valor pode variar de 0 a 65535 segundos.

  14. Verifique e confirme a configuração.

Saída de amostra

Exemplo: Configuração do protocolo de elementos de computação de caminhos para MPLS RSVP-TE com suporte para LSPs de ponto a multiponto controlados por PCE

Este exemplo mostra como configurar o cliente de computação de caminho (PCC) com a capacidade de relatar caminhos comutados por rótulos projetados de tráfego ponto a multiponto (TE LSPs) para um elemento de computação de caminho (PCE).

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Três roteadores que podem ser uma combinação de roteadores série ACX, Série M, Série MX ou Série T.

  • Uma máquina virtual configurada com recurso Virtual Route Reflector (VRR).

  • Uma conexão TCP com um PCE stateful externo do VRR.

  • Junos OS Release 16.1 ou posterior no PCC.

Antes de começar:

  • Configure as interfaces do dispositivo.

  • Configure MPLS e RSVP-TE.

  • Configure o OSPF ou qualquer outro protocolo IGP.

Visão geral

Após uma sessão de PCEP ser estabelecida entre um PCE e um PCC, o PCC informa todos os LSPs do sistema ao PCE para sincronização de estado de LSP. Isso inclui LSPs ponto a ponto controlados por PCC, delegados por PCE e iniciados por PCE. Começando pelo Junos OS Release 15.1F6 e 16.1R1, esse recurso é estendido para relatar LSPs ponto a multiponto também.

Por padrão, o controle PCE de LSPs ponto a multiponto não é suportado em um PCC. Para adicionar esse recurso, inclua a p2mp-lsp-report-capability declaração nos [edit protocols pcep pce pce-name] níveis de hierarquia.[edit protocols pcep pce-group group-id]

Topologia

Figura 7: Exemplo de LSPs de ponto a multiponto controlados por PCEExemplo de LSPs de ponto a multiponto controlados por PCE

Neste exemplo, o PCC é o roteador de entrada, o Roteador R1 é o roteador de trânsito, e o Roteador R2 é o roteador de saída. O PCC está conectado a um Refletor de Rota Virtual (VRR) conectado a um PCE. Existem muitas interfaces de ponto a multiponto entre PCC, Roteador R1 e Roteador R2.

O relatório dos LSPs ponto a multiponto é executado da seguinte forma:

  1. Se o ROTEADOR PCC estiver configurado com LSPs ponto a ponto e ponto a ponto sem o suporte para recursos de relatórios ponto a multiponto, apenas os LSPs ponto a ponto são relatados ao PCE conectado. Por padrão, um PCC não oferece suporte a recursos de relatórios de LSP ponto a multiponto.

  2. Quando o Roteador PCC é configurado com recursos de relatórios LSP de ponto a multiponto, o PCC anuncia primeiro esse recurso para PCE por meio de uma mensagem de relatório.

  3. Por padrão, um PCE oferece suporte para recursos de LSP ponto a multiponto. Ao receber o anúncio do PCC para recursos de LSP ponto a multiponto, o PCE em troca anuncia sua capacidade para o PCC.

  4. Ao receber o anúncio do PCE do recurso de ponto a multiponto, o PCC informa todas as filiais de LSPs ponto a multiponto para o PCE usando a mensagem de atualização.

  5. Uma vez que todos os LSPs são relatados ao PCE, o estado de LSP é sincronizado entre o PCE e o PCC.

Configuração

Configuração rápida da CLI

Para configurar este exemplo rapidamente, 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 [edit] hierarquia.

PCC

R1

R2

R3

Procedimento

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração.

Para configurar o roteador PCC:

  1. Configure as interfaces do Roteador PCC. Para habilitar o MPLS, inclua a família de protocolo na interface para que a interface não descarte o tráfego MPLS de entrada.

  2. Configure o número do sistema autônomo para o Roteador PCC.

  3. Habilite o RSVP em todas as interfaces do Roteador PCC, sem a interface de gerenciamento.

  4. Habilite o MPLS em todas as interfaces do Roteador PCC, sem a interface de gerenciamento.

  5. Configure um LSP dinâmico e desabile a computação automática de caminhos para o LSP.

  6. Configure LSPs de ponto a multiponto e defina a entidade de computação de caminho externo para o LSP.

  7. Habilite a computação de caminhos externos para os LSPs MPLS e atribua um modelo para LSPs provisionados externamente.

  8. Configure os LSPs que têm controle local e são substituídos pelos parâmetros LSP fornecidos por PCE.

  9. Configure as políticas do grupo administrativo MPLS para a computação LSP de caminho limitado.

  10. Atribua as políticas configuradas do grupo administrativo às interfaces do Roteador PCC.

  11. Configure uma política de importação de banco de dados de engenharia de tráfego (TED).

  12. Configure um grupo interno BGP.

  13. Configure a engenharia de tráfego para BGP e atribua a política de exportação.

  14. Configure a área 0 do OSPF em todas as interfaces de ponto a multiponto do Roteador PCC.

  15. Configure a área 0 do OSPF na interface ponto a ponto do Roteador PCC.

  16. Habilite a engenharia de tráfego para OSPF.

  17. Defina o PCE ao qual o Roteador PCC se conecta e configure os parâmetros do PCE.

  18. Configure o PCC do roteador para permitir a capacidade de LSP de ponto a multiponto para computação de caminhos externos.

  19. Configure a política de engenharia de tráfego.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show interfaces comandos e show protocols os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Confirme se a configuração está funcionando corretamente.

Verificando a configuração de LSP no PCC

Propósito

Verifique o tipo de LSP e o estado em execução do LSP ponto a multiponto.

Ação

A partir do modo operacional, execute o show mpls lsp extensive comando.

Significado

A saída exibe o LSP lsp2-pcc como o LSP controlado por PCE.

Verificando a configuração do PCE no PCC

Propósito

Verifique a configuração dos parâmetros PCE e o estado do PCE.

Ação

A partir do modo operacional, execute o show path-computation-client active-pce comando.

Significado

A saída exibe o PCE ativo ao qual o Roteador PCC está conectado e os parâmetros e estado do PCE pce1.

Entendendo o protocolo de elementos de computação de caminhos para MPLS RSVP-TE com suporte para LSPs de ponto a multiponto iniciados por PCE

Com a introdução de LSPs iniciados por PCE de ponto a multiponto, um PCE pode iniciar e provisionar um LSP ponto a multiponto dinamicamente sem a necessidade de configuração de LSP local no PCC. Isso permite que o PCE controle o tempo e a sequência das computação de caminhos de ponto a multiponto dentro e por todas as sessões do Protocolo de Elementos de Computação de Caminho (PCEP), criando assim uma rede dinâmica que é controlada e implantada centralmente.

Benefícios dos LSPs de ponto a multiponto iniciados por PCE

Atende aos requisitos da colocação LSP de engenharia de tráfego ponto a multiponto em resposta às demandas de aplicativos por meio da criação dinâmica e demolição de LSPs ponto a multiponto, criando assim uma rede dinâmica que é controlada e implantada centralmente.

Sinalização de LSPs de ponto a multiponto iniciados por PCE

A sinalização de LSPs de ponto a multiponto iniciados por PCE é a seguinte:

  • When a new branch is added (Grafting)— Apenas a nova filial sub LSP é sinalizada e não resulta em re-sinalização de toda a árvore de ponto a multiponto.

    Se alguma alteração de topologia ocorreu antes do provisionamento do novo sub-LSP, então o Servidor de Computação de Caminho (PCS) re computa toda a árvore de ponto a multiponto e atualiza o LSP de ponto a multiponto usando uma mensagem de atualização do PC.

  • When a branch is deleted (Pruning)— O sub LSP de filial excluído é demolido e não resulta em re-sinalização de toda a árvore de ponto a multiponto.

  • When a branch sub-LSP parameter is changed— A mudança nos parâmetros sub LSP, como objeto de rota explícita (ERO), largura de banda ou prioridade, pode acontecer por otimização ou solicitação do usuário. Se houver uma solicitação de re-sinalização para um sub-LSP, toda a árvore de ponto a multiponto é re-sinalizada e, em seguida, a mudança para a nova instância acontece assim que as novas instâncias de todos os galhos estiverem ativas.

  • When a branch sub-LSP path fails— Um erro é relatado ao PCS para o sub-LSP de filial com falha. Ao receber o novo ERO do PCS, toda a árvore de ponto a multiponto é re-sinalizada junto com o sub LSP de filial com falha, e a mudança para a nova instância acontece de forma make-before-break (MBB).

Comportamento dos LSPs de ponto a multiponto iniciados por PCE após falha na sessão do PCEP

Quando uma sessão de PCEP falha, os LSPs de ponto a multiponto iniciados por PCE ficam órfãos até o término do state timeout temporizador. Após o término do state timeout temporizador, os LSPs iniciados por PCE são limpos.

Para obter o controle de um LSP de ponto a multiponto iniciado por PCE após uma falha na sessão do PCEP, o PCE primário ou secundário envia uma PCInitiate mensagem antes que o state timeout temporizador expire.

Configuração do recurso de LSP de ponto a multiponto iniciado por PCE

Por padrão, a criação e o provisionamento de LSPs ponto a multiponto por um PCE não é suportado em um PCC. Para habilitar esse recurso, inclua as p2mp-lsp-init-capability declarações e p2mp-lsp-update-capability os níveis de [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] hierarquia.

A p2mp-lsp-init-capability declaração fornece a capacidade de provisionar LSPs RSVP-TE de ponto a multiponto por um PCE. A p2mp-lsp-update-capability declaração fornece a capacidade de atualizar parâmetros RSVP-TE LSP de ponto a multiponto por um PCE.

Recursos suportados e sem suporte para LSPs de ponto a multiponto iniciados por PCE

Os recursos a seguir são suportados com LSPs de ponto a multiponto iniciados por PCE:

  • Conformidade parcial com o rascunho do rascunho da Internet-ietf-pce-stateful-pce-p2mp (expira outubro de 2018), extensões de protocolo de elemento de computação de caminho (PCE) para uso de PCE stateful para caminhos comutação de rótulos de engenharia de tráfego de ponto a multiponto.

  • A partir do Junos OS Release 21.1R1, oferecemos suporte ao roteamento ativo ininterrupto (NSR) para LSPs de ponto a multiponto iniciados por RSVP iniciados por PCE. Apenas o mecanismo de roteamento primário mantém a sessão de PCEP com o controlador. Ele sincroniza todos os LSPs RSVP iniciados por PCEs, incluindo especificações de fluxo multicast para quaisquer LSPs P2MP iniciados por PCE, com o mecanismo de roteamento de backup. Durante uma troca, a sessão de PCEP cai e se restabelecerá quando o mecanismo de roteamento de backup se torna o mecanismo de roteamento principal. Isso reduz a perda de tráfego para o tráfego transportado por LSPs RSVP iniciados por PCE durante as transições do mecanismo de roteamento. Esse recurso é habilitado quando o NSR é configurado.

Os recursos a seguir não são suportados com LSPs de ponto a multiponto iniciados por PCE:

  • Delegação de LSP controlado localmente por ponto a multiponto.

  • Delegação de controle de LSP.

  • Extensão de protocolo de gateway interior (IGP) para descoberta de PCE em um domínio de roteamento IGP.

  • Mensagens de solicitação/resposta.

  • Movimento direto do sub LSP de filial de uma árvore de ponto a multiponto para outra.

    O mesmo pode ser conseguido excluindo um sub LSP de filial da primeira árvore de ponto a multiponto e reinstando-o a outro após a mensagem indicar a PCReport remoção de LSP do dispositivo.

  • O IPv6 não é compatível.

  • A sinalização baseada em SERO não é suportada.

  • O recurso Empty-ERO não é suportado.

  • A proteção de enlaces não é suportada.

Mapeamento de LSPs de ponto a multiponto iniciados por PCE para MVPN

Você pode associar um único ou intervalo de fluxos multicast MVPN (S,G) a um caminho de comutado por rótulos de ponto a multiponto (LSP) iniciado dinamicamente por PCE. Você pode especificar apenas tipos seletivos de fluxos para que esse recurso funcione. Isso inclui:

  • Diferenciador de rota (RD), que é mapeado para a instância de roteamento MVPN.

  • (S,G) que é a fonte de um pacote multicast e endereço de grupo multicast de destino. Isso é usado para filtrar o tráfego de entrada para mapeá-lo no túnel.

  • LSP de ponto a multiponto usado para enviar tráfego que corresponda à especificação de fluxo acima mencionada.

Para obter mais detalhes, veja o rascunho do rascunho da Internet-ietf-pce-pcep-flowspec-05 (expira em 16 de fevereiro de 2020) Extensão pcep para especificação de fluxo.

A implementação atual deste recurso não implementa as seguintes seções do rascunho:

  • Seção 3.1.2 — Recursos de publicidade PCE no IGP

  • Seção 3.2 — Mensagem pcReq e PCRep

  • Seção 7 — A maioria das especificações de fluxo, exceto distingu de rotaA implementação atual deste recurso não supporisher e especificações de fluxo multicast IPv4 não são suportadas.

Para permitir o mapeamento de LSPs de ponto a multiponto iniciados por PCE para MVPN:

  • Inclua a pce_traffic_steering declaração no nível de [edit protocols pcep pce pce-id] hierarquia para indicar o suporte para a capacidade de especificação de fluxo (também chamado de direcionamento de tráfego) pelo PCC.

  • Inclua a external-controller declaração no nível hierárquica [edit routing-instances routing-instance-name provider-tunnel] .

    A presença da configuração de external-controller túnel de provedor para MVPN indica que o LSP ponto a multiponto e (S,G) para esta instância MVPN podem ser fornecidos pelo controlador externo. Isso permite que o controlador externo configure dinamicamente (S,G) e LSP de ponto a multiponto para MVPN.

Leve o seguinte em consideração para o mapeamento de LSPs ponto a multiponto iniciados por PCE para MVPN:

  • Se você não habilitar a external-controller pccd declaração para uma determinada instância MVPN, então o processo PCCD não configura (S,G) dinamicamente.

  • Se você desativar a external-controller pccd configuração da CLI, então os fluxos multicast (S,G) aprendidos dinamicamente para essa instância MVPN em particular são excluídos e relatados ao controlador externo.

  • Quando (S,G) já está configurado a partir do CLI, o PCC não pode configurar (S,G) dinamicamente, pois a configuração local tem uma prioridade maior.

  • Se algum determinado (S,G) for aprendido com o controlador externo dinamicamente e então você configurar o mesmo (S,G) para a mesma instância MVPN, então o aprendizado dinâmico (S,G) é excluído e relatado ao controlador externo através do PCC.

  • Se o processo de protocolo de roteamento for reiniciado, o processo PCCD reconfigura todos os (S,G) novamente.

  • Se o processo PCCD for reiniciado, o MVPN informará todo o PCCD configurado (S,G) ao controlador externo.

  • Se o usuário permitir external-controller pccd uma determinada instância MVPN, o MVPN solicitará que o processo PCCD configure (S,G), se houver algum presente.

  • Se houver grandes mudanças de configuração em uma determinada instância MPVN, o MVPN solicitará ao processo PCCD que reconfigure todos (S,G) para essa instância MVPN em particular.

  • Todas as especificações de fluxo associadas a qualquer LSP de ponto a multiponto iniciado por PCE devem ter o mesmo RD. Durante a iniciação do PC, se todas as especificações de fluxo não tiverem o mesmo RD, a mensagem de iniciação do PC será descartada com um erro.

  • Você pode associar um LSP de ponto a multiponto apenas com especificações seletivas de tipo de fluxo, caso contrário, a mensagem de iniciação do PC é descartada com um erro.

  • Durante a atualização do PC se todas as especificações de fluxo não tiverem o mesmo RD, seja devido a uma nova adição de especificação de fluxo, ou devido à atualização de especificação de fluxo existente, então o PCC deixa cair a mensagem de atualização.

  • Durante a atualização do PC se todas as especificações de fluxo não atenderem à condição seletiva, seja devido à nova adição de especificação de fluxo, ou devido à atualização das especificações de fluxo existentes, o PCC deixa cair a mensagem de atualização.

  • O comportamento para mapeamento do LSP ponto a multiponto iniciado por PCE com instância de roteamento MVPN e mapeamento de LSP estático (configurado localmente) de ponto a multiponto com instância MVPN é o mesmo no nível do usuário.

  • Um ID de especificação de fluxo pode ser associado a apenas um LSP de ponto a multiponto. Para associar o mesmo RD e (S,G) a vários LSPs de ponto a multiponto, você pode adicionar várias especificações de fluxo com diferentes IDs e o mesmo RD &(S,G).

  • Para a dinâmica mapeada por PCEP (S,G), o valor limite é sempre o valor padrão de 0.

  • Não há limite no número de especificações de fluxo mapeadas para um único LSP de ponto a multiponto iniciado por PCE.

  • A implementação atual deste recurso não oferece suporte:

    • Relatórios de estados de encaminhamento associados ao LSP de ponto a multiponto.

    • Configuração dinâmica de túnel de provedor inclusivo

    • Mapeamento para túnel de replicação de entrada MVPN

    • Processo de protocolo de roteamento programável (prpd)

    • Relatórios de LSP configurado de ponto a multiponto da CLI que é mapeado para fluxos multicast MVPN (S,G).

Habilite o roteamento por segmentos para o protocolo de elementos de computação de caminhos

SUMMARY Você pode habilitar o roteamento por segmentos ou o roteamento de pacotes de origem em redes (SPRING) engenharia de tráfego (SR-TE) com o Protocolo de Elementos de Computação de Caminho (PCEP) para direcionamento de tráfego. Com esse suporte, as vantagens do roteamento por segmentos são estendidas para os caminhos comuados por rótulos (LSPs) que são controlados externamente por um elemento de computação de caminho (PCE).

Visão geral do protocolo de roteamento por segmentos para o protocolo de elementos de computação de caminho

Benefícios do roteamento por segmentos para PCEP

  • A configuração de LSPs por meio de um controlador externo oferece uma visão global da demanda por LSP e largura de banda por dispositivo na rede, permitindo a computação de caminhos on-line e em tempo real baseada em restrições.

    As vantagens do roteamento por segmentos são estendidas aos LSPs iniciados por um controlador externo, também conhecido como elemento de computação de caminho (PCE), aumentando os benefícios da computação de caminhos externos em uma rede MPLS.

  • Um cliente de computação de caminho (PCC, que é um roteador da Série MX de entrada) com capacidade de delegação pode retomar o controle dos LSPs de roteamento por segmentos delegados do PCE quando a sessão do PCEP cair; os LSPs seriam excluídos do PCC. Assim, você pode garantir a proteção de dados LSP evitando uma situação em que os pacotes são silenciosamente descartados ou descartados (também conhecido como uma condição de rota nula).

Roteamento por segmentos para engenharia de tráfego

O roteamento por segmentos pode operar em um plano de dados IPv4 ou IPv6 e oferece suporte a multicaminho de custo igual (ECMP). Com as extensões IGP integradas a ele, o roteamento por segmentos se integra com os ricos recursos de multisserviços do MPLS, incluindo VPN de Camada 3, Serviço de fio privado virtual (VPWS), Serviço de LAN privada virtual (VPLS) e VPN Ethernet (EVPN).

Alguns dos componentes de alto nível da solução de roteamento por segmentos — engenharia de tráfego (SR-TE) incluem:

  • Uso de um IGP para características de link de publicidade. Essa funcionalidade é semelhante ao RSVP-TE.

  • Uso do CSPF (Constrained Shortest Path First, caminho mais curto limitado) no dispositivo de entrada ou no PCE.

  • Uso de um IGP para rótulos de publicidade para links.

    Na funcionalidade SR-TE:

    1. O dispositivo de entrada constrói um LSP empilhando as etiquetas dos links que deseja atravessar.

    2. O anúncio de IGP por link é combinado com o empilhamento de rótulos para criar LSPs roteados de origem no dispositivo de entrada, para que os dispositivos de trânsito não estejam cientes dos LSPs de ponta a ponta.

    3. Os LSPs são criados entre nós de borda sem colocar nenhum requisito de memória por LSP nos dispositivos de trânsito. (A criação desses LSPs está habilitada, pois não há sinalização por LSP no SR-TE.)

    4. As etiquetas por vizinhos são empilhadas, o que resulta no gerenciamento de um grande número de rótulos, levando ao dimensionamento do plano de controle.

Implementação do Junos OS de roteamento por segmentos para PCEP

O Junos OS implementa o roteamento por segmentos para PCEP para dois tipos de LSPs — LSPs iniciados por PCE e LSPs delegados por PCE.

LSPs de roteamento por segmentos iniciados por PCE

Os LSPs de roteamento por segmentos iniciados por PCE são os LSPs que o PCE cria para os segmentos de adjacência e nós

O PCE executa as seguintes funções:

  1. Computa o caminho do LSP de roteamento por segmentos.

  2. Provisiona o LSP no cliente de computação de caminho (PCC) usando extensões de roteamento por segmentos PCEP.

  3. Analisa as extensões de roteamento por segmentos do PCEP.

  4. Cria uma rota de túnel no PCC que tem seu próprio valor de preferência e é disponibilizada na tabela de roteamento inet.3 para resolver o tráfego IP e serviços como qualquer outra rota de túnel.

O PCC executa as seguintes funções:

  1. Seleciona a interface de saída com base no primeiro identificador de acesso à rede (NAI) no objeto de rota explícita de origem (S-ERO).

    O Junos OS oferece suporte a S-EROs que contêm o primeiro salto como um salto rigoroso; O Junos OS não oferece suporte à seleção da interface de saída no PCC com base em um ID do segmento de nó de salto solto (SID). No entanto, os saltos restantes podem ser soltos. Nenhum processamento específico é feito para os S-EROs que estão além do primeiro salto, além de simplesmente usar o rótulo para a criação do next-hop.

  2. Rejeita o S-ERO se:

    • O S-ERO não tem rótulos.

    • O S-ERO leva mais de seis saltos.

    O PCC cria uma rota multicaminho de custo igual (ECMP) quando há vários LSPs para o mesmo destino com a mesma métrica.

  3. Aguarda o PCE processar qualquer evento que leve a uma mudança no LSP de roteamento por segmentos após o provisionamento — por exemplo, se o rótulo for alterado ou retirado, ou se uma das interfaces atravessadas pelo LSP cair.

Quando a sessão de PCEP cai, o LSP de roteamento por segmentos iniciado por PCE:

  1. Permanece ativa por 300 segundos.

  2. É excluído do PCC após 300 segundos.

Para obter mais detalhes, veja os rascunhos da Internet draft-ietf-pce-lsp-setup-type-03.txt (expira em 25 de dezembro de 2015), tipo de configuração de caminho de transporte em mensagens PCEP; e draft-ietf-pce-segment-routing-06.txt (expira em 10 de fevereiro de 2016), extensões PCEP para roteamento por segmentos.

LSPs de roteamento por segmentos delegados por PCE

Os LSPs de roteamento por segmentos delegados por PCE são os LSPs que o PCC configura localmente e depois delega a um controlador PCE.

Nota:

O Junos OS Release 20.1R1 oferece suporte:

  • Capacidade de delegação de PCE apenas para LSPs de roteamento por segmentos nãocolorizados com destinos IPv4.

  • Delegação e relatórios de apenas o primeiro segmento de uma lista de segmentos para um controlador externo. Vários segmentos não têm suporte para a delegação do PCE.

O PCC pode delegar um LSP de roteamento por segmentos a um controlador externo (o PCE) das seguintes maneiras:

  • Initial delegation— Os LSPs locais ainda estão para ser configurados no PCC, e a delegação do LSP acontece no momento em que o LSP está configurado.

  • Delegation of existing LSP— Os LSPs locais estão configurados no PCC, e a delegação do LSP acontece após a configuração do caminho de roteamento de origem. Ou seja, a capacidade da delegação é habilitada para LSPs de roteamento por segmentos existentes.

Após delegar um LSP de roteamento por segmentos, o PCE controla os LSPs delegados e pode modificar os atributos LSP para computação de caminhos. O controle de LSP volta para o PCC quando a sessão de PCEP entre o PCC e o PCE cai. Os LSPs delegados por PCE têm uma vantagem sobre os LSPs iniciados por PCE no caso da sessão do PCEP cair. No caso dos LSPs iniciados por PCE, quando a sessão do PCEP é baixa, os LSPs são excluídos do PCC. No entanto, no caso dos LSPs delegados por PCE, quando a sessão do PCEP cai, o PCC retoma o controle dos LSPs delegados do PCE. Como resultado, com os LSPs delegados por PCE, evitamos uma situação em que os pacotes são silenciosamente descartados (também conhecidos como uma condição de rota nula) quando a sessão cai.

Os seguintes tipos de LSPs de roteamento por segmentos oferecem suporte à capacidade de delegação de PCE:

  • Static LSPs— Configurou de forma estatística caminhos de roteamento de fonte que têm toda a pilha de rótulos configurada estaticamente.

  • Auto-translated LSPs— Caminhos de roteamento de fonte configurados de forma estatística que são traduzidos automaticamente.

  • Computed LSPs— Caminhos de roteamento de fonte configurados estaticamente que são computados com o CSPF (Constrained Shortest Path First, caminho mais curto restringido distribuído).

  • Dynamic LSPs— Túneis criados dinamicamente desencadeados pelo módulo de túnel dinâmico que têm resolução ERO de último salto.

Dependendo da fonte do LSP de roteamento por segmentos, você pode configurar o recurso de delegação no PCC. Para permitir a delegação de LSPs de roteamento por segmentos, inclua a lsp-external-controller pccd declaração no nível apropriado sob a [edit protocols source-packet-routing] hierarquia.

Tabela 2 mostra um mapeamento da fonte LSP para o nível de hierarquia de configuração correspondente no qual a capacidade da delegação é habilitada.

Nota:

Você deve incluir a lsp-external-controller pccd declaração nos [edit protocols source-packet-routing] níveis de hierarquia antes [edit protocols mpls] de configurar o recurso da delegação no PCC.

Tabela 2: Mapeamento da fonte LSP de roteamento por segmentos com hierarquia de configuração

Fonte de LSP de roteamento por segmentos

Hierarquia de configuração

  • LSPs traduzidos automaticamente

  • LSPs estáticos

Lista principal do segmento em [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSPs computados (CSPF distribuído)

Lista principal do segmento do caminho de roteamento de origem em:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSPs dinâmicos

Lista principal do segmento do modelo de caminho de roteamento de origem em:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

Você pode ver o status de controle dos LSPs SR-TE a partir da saída de comando de engenharia de tráfego de primavera .

Tabela 3 exibe a interação do PCEP quando a lsp-external-controller declaração está configurada para um caminho de roteamento de origem.

Tabela 3: Delegação LSP de interação do PCEP

Hierarquia de configuração de controlador externo lsp

estado de delegação de caminho de roteamento fonte

Interação do PCEP entre PCC e PCE

Lista principal do segmento de caminho de roteamento de origem

Delegação inicial

  1. Uma mensagem do PCReport é enviada ao PCE para delegação. O PCReport contém apenas restrições e detalhes do caminho (como ERO).

  2. O PCE calcula o caminho para o LSP e o caminho de relatórios para estar no estado em baixa.

  3. Nenhuma rota é programada pelo LSP local até que o controlador compute o ERO e notifique o resultado para o PCC por meio do PCUpdate.

O mesmo comportamento é visto quando o processo de protocolo de roteamento (rpd) é reiniciado ou acontece uma mudança de mecanismo de roteamento.

Lista principal do segmento de caminho de roteamento de origem

Delegação de caminho existente

  1. Um PCReport é enviado ao PCE para delegação. O PCReport contém apenas restrições e detalhes do caminho (como ERO).

  2. Um segmento primário correspondente é delegado ao PCE.

  3. O PCE calcula o caminho para o LSP.

  4. O segmento primário continua contribuindo para a rota conforme determinado pela configuração ou computação local até que um PCUpdate seja recebido do PCE.

    • Se o BFD contínuo (S-BFD) não estiver configurado para o segmento principal, então não haverá mais atualizações para a rota e o estado LSP também não é monitorado e relatado ao PCE. O estado de LSP neste momento é relatado como para cima ou para baixo, dependendo se a computação de caminhos teve sucesso naquele momento.

    • Se o S-BFD estiver configurado para o segmento primário, o estado do segmento primário será rastreado e relatado ao PCE. Se a BFD detectar a baixa do segmento principal, o caminho primário correspondente será removido da rota. A mesma rota que foi calculada anteriormente é reprogramada se esse caminho estiver em andamento agora.

  5. Se uma mensagem PCUpdate for recebida do PCE, o SR-TE usa o parâmetro recebido para configurar o caminho para o qual a mensagem de suporte do PC foi enviada. O caminho programado então inclui apenas a lista de segmentos recebida do PCE, e todas as outras listas de segmentos que foram programadas anteriormente são removidas. Essa reprogramação da rota acontece de uma forma de fazer antes do intervalo.

Segmento primário do caminho de roteamento de origem

A delegação não está configurada ou foi excluída.

A lista de segmentos do PCE (se disponível) não é mais usada e o resultado da computação da configuração local é usado. Quando o resultado local para a lista de segmentos está disponível, a lista de segmentos correspondente é usada para programar a rota de forma make-before-break.

Lista de segmentos de caminho de roteamento de origem

A delegação é habilitada após a configuração do LSP.

A funcionalidade da delegação é acionada para a lista principal do segmento no caminho de roteamento de origem.

Lista de segmentos de caminho de roteamento de origem

A delegação não está configurada ou foi excluída.

A funcionalidade da delegação é removida da lista principal do segmento no caminho de roteamento de origem.

Lista principal do segmento de modelo de caminho de roteamento de origem

A delegação é habilitada após a configuração do LSP.

  • Sob o modelo de caminho de roteamento de origem — a funcionalidade da delegação é acionada para todo o caminho de roteamento de origem.

    As configurações do modelo só podem ser aplicadas ao módulo de túnel dinâmico.

  • No caminho principal do modelo de caminho de roteamento de origem— a funcionalidade da delegação é acionada para esse caminho primário específico de acordo com a configuração.

Lista principal do segmento de modelo de caminho de roteamento de origem

A delegação não está configurada ou foi excluída.

A funcionalidade da delegação é removida de todos os caminhos de roteamento de origem e caminhos primários que combinam com a configuração do modelo.

Roteamento por segmentos para limitações de PCEP e recursos sem suporte

O suporte ao roteamento por segmentos para PCEP não aumenta a carga de desempenho do sistema. No entanto, ela tem as seguintes limitações:

  • Um LSP SR-TE não está protegido localmente no PCC. Quando o LSP tem mais de seis saltos, nenhum serviço é fornecido no LSP além de transportar tráfego IP simples.

  • O switchover gracioso do mecanismo de roteamento (GRES) e a atualização unificada de software em serviço (ISSU unificada) não são suportados.

  • O roteamento ativo sem parar (NSR) não é suportado.

  • O IPv6 não é compatível.

  • Os LSPs delegados por PCE não suportam o seguinte:

    • LSPs SR-TE coloridos

    • IPv6 LSPs

    • Lista de segmentos secundários do caminho de roteamento de origem. Apenas um caminho da lista de segmentos pode ser delegado.

    • Padrão multissegment. Apenas o primeiro segmento da lista do segmento é delegado e relatado ao controlador.

Exemplo: Configure o roteamento por segmentos para o protocolo de elementos de computação de caminhos

Este exemplo mostra como configurar o roteamento por segmentos ou o roteamento de pacotes de origem em redes (SPRING) engenharia de tráfego (SR-TE) para o protocolo de elementos de computação de caminho (PCEP). Na configuração, aproveitamos as vantagens do roteamento por segmentos com os benefícios da computação de caminhos externos para uma engenharia de tráfego eficiente.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Quatro plataformas de roteamento universal 5G da Série MX, onde o roteador da Série MX de entrada é o Cliente de Computação de Caminhos (PCC).

  • Uma conexão TCP do PCC a um elemento de computação de caminho (PCE) externo.

  • Junos OS Release 17.2 ou posterior no PCC para a implementação de LSPs iniciados por PCE.

    Para a funcionalidade pce-delegation, você deve executar o Junos OS Release 20.1R1 ou uma versão posterior.

Antes de começar:

  • Configure as interfaces do dispositivo.

  • Configure MPLS.

  • Configure IS-IS.

Visão geral

A implementação do Junos OS de roteamento por segmentos para PCEP inclui LSPs SR-TE iniciados por PCE e delegados por PCE.

  • A implementação de LSPs iniciados por PCE é introduzida no Junos OS Release 17.2R1, onde os recursos de engenharia de tráfego do roteamento por segmentos são suportados em sessões de PCEP para LSPs iniciadas por um PCE. O PCE cria os LSPs para segmentos de adjacência e nós. As rotas de túnel são criadas na tabela de roteamento inet.3 do PCC correspondente aos LSPs SR-TE iniciados por PCE.

  • A implementação de LSPs delegados por PCE é introduzida no Junos OS Release 20.1R1, onde os LSPs de roteamento de segmentos nãocolorizados IPv4 configurados localmente no PCC podem ser delegados a um controlador PCE. O PCE então controla o LSP e pode modificar atributos LSP para computação de caminhos.

Os LSPs delegados por PCE têm uma vantagem sobre os LSPs iniciados por PCE no momento em que a sessão do PCEP cai. No caso dos LSPs iniciados por PCE, quando a sessão do PCEP é baixa, os LSPs são excluídos do PCC. No entanto, no caso dos LSPs delegados por PCE, quando a sessão do PCEP cai, o PCC retoma o controle dos LSPs delegados do PCE. Como resultado, com os LSPs delegados por PCE, evitamos uma situação em que os pacotes são silenciosamente descartados (também conhecidos como condição de rota nula) quando a sessão do PCEP cai.

Para habilitar o roteamento por segmentos para PCEP:

Para LSPs de roteamento por segmentos iniciados por PCE:

  1. Habilite a computação de caminhos externos para MPLS, incluindo a lsp-external-controller declaração no nível de [edit protocols mpls] hierarquia.

    Essa configuração é necessária para PCEP com extensões RSVP-TE também. Você não pode desabilitar o PCEP com o RSVP-TE quando o roteamento por segmentos para PCEP está habilitado.

  2. Habilite a computação de caminhos externos para SR-TE, incluindo a lsp-external-controller pccd declaração no nível de [edit protocols spring-traffic-engineering] hierarquia.

  3. Habilite o roteamento por segmentos para o PCE incluindo a spring-capability declaração no nível de [edit protocols pcep pce pce-name] hierarquia.

  4. Opcionalmente, configure a profundidade de SID máxima para o PCE, incluindo a max-sid-depth number declaração no nível de [edit protocols pcep pce pce-name] hierarquia.

    A profundidade de SID máxima é o número de SIDs suportados por um nó ou um link em um nó. Quando não estiver configurado, é aplicado um valor DE SID máximo padrão de 5.

  5. Opcionalmente, configure o valor de preferência para o roteamento por segmentos, incluindo o preference preference-value nível de [edit protocol spring-te] hierarquia.

    O valor de preferência indica a ordem em que um caminho é selecionado como a forma de caminho ativo entre os caminhos do candidato, onde um valor mais alto tem uma preferência maior. Quando não estiver configurado, é aplicado um valor de preferência padrão de 8.

  6. Opcionalmente, configure o registro de roteamento por segmentos para a solução de problemas, incluindo a traceoptions declaração no nível hierárquica [edit protocols spring-te] .

Para a pce-delegação de LSPs de roteamento por segmentos, além das etapas acima mencionadas, faça o seguinte:

  1. Definir uma lista de segmentos com parâmetros de rótulo. Isso cria um LSP de roteamento por segmentos localmente no PCC.

  2. Habilite a capacidade de delegação do LSP configurado localmente no PCC, incluindo a lsp-external-controller pccd declaração em qualquer uma das seguintes hierarquias, dependendo da fonte LSP de roteamento por segmentos:

    • Para caminhos de roteamento de fonte configurados estaticamente que são computados com CSPF distribuído e[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name] níveis de hierarquia.

    • Para caminhos de roteamento de fonte configurados estaticamente que tenham toda a pilha de rótulos configurada estaticamente e caminhos de roteamento de origem que são automaticamente traduzidos:[edit protocols source-packet-routing source-routing-path lsp-name primary path-name] nível de hierarquia.

    • Para túneis criados dinamicamente desencadeados pelo módulo de túnel dinâmico que têm resolução[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name] ERO de último salto e [edit protocols source-packet-routing source-routing-path-template template-name] níveis de hierarquia.

Topologia

Figura 8 ilustra uma topologia de rede de amostra que tem uma sessão pcep em execução entre o PCE e o PCC (o roteador da Série MX de entrada). Os roteadores R1, R2 e R3 são os outros roteadores da Série MX na rede. Neste exemplo, configuramos o roteamento por segmentos para PCEP no PCC. Também configuramos uma rota estática no PCC para o Roteador R3 para verificar o uso de rotas de túnel SR-TE ao rotear o tráfego para a rota estática.

Figura 8: Roteamento por segmentos para PCEPRoteamento por segmentos para PCEP

Configuração

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Embora apresentemos a configuração de todos os dispositivos (PCC e os três roteadores) nesta seção, o procedimento passo a passo documenta apenas a configuração do PCC.

PCC

Roteador R1

Roteador R2

Roteador R3

Procedimento
Procedimento passo a passo

Neste exemplo, configuramos apenas o PCC.

As etapas a seguir exigem que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.

Para configurar o PCC:

  1. Configure as interfaces do PCC.

  2. Configure a ID do roteador e atribua um número de sistema autônomo para o PCC.

  3. Configure uma rota estática do PCC para o Roteador R3.

    A rota estática é criada apenas para fins de verificação e não afeta a funcionalidade do recurso.

  4. Configure o RSVP em todas as interfaces do PCC, sem a interface de gerenciamento.

  5. Configure o MPLS em todas as interfaces do PCC, excluindo a interface de gerenciamento.

  6. Habilite a capacidade de computação de caminhos externos para MPLS.

  7. Configure o nível IS-IS 2 em todas as interfaces do PCC, excluindo as interfaces de gerenciamento e loopback.

  8. Configure atributos do bloco global de roteamento por segmentos (SRGB) para roteamento por segmentos.

  9. Habilite a capacidade de computação de caminhos externos para SR-TE.

  10. Configure os parâmetros do PCE e habilite o provisionamento do LSP pelo PCE e pelo recurso de roteamento por segmentos.

  11. Habilite o provisionamento de LSPs de roteamento por segmentos pelo PCE.

  12. Habilite a capacidade de roteamento por segmentos para o PCE.

  13. Definir os parâmetros da lista static_seg_list_1 de segmentos estáticos.

  14. Configure um LSP de roteamento por segmentos estático do PCC para o Roteador R3 para a delegação do PCE.

  15. Habilite a capacidade da delegação para o static_srte_lsp_1 caminho de roteamento de origem.

    Ao concluir as Etapas 13, 14 e 15, você permite que o PCC delego os LSPs de roteamento por segmentos para o PCE.

  16. Confirmar a configuração.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show interfaces, show routing-optionse show protocols comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo (o PCC), entre no commit modo de configuração.

Verificação

Confirme se a configuração está funcionando corretamente.

Verifique a adjacência e rótulos IS-IS
Propósito

Verifique a adjacência is-IS no PCC. Observe a gama de rótulos SRGB, valores de segmentos de adjacência e nós e os campos de saída de recursos SPRING.

Ação

Do modo operacional, execute o show isis adjacency extensivee show isis database extensiveos show isis overview comandos.

Significado

A adjacência IS-IS entre o PCC e o PCE e que entre o PCC e o Roteador R1 estão ativas e operacionais. A saída também exibe as atribuições do rótulo para os segmentos adjacentes e de nós.

Verifique o banco de dados de engenharia de tráfego
Propósito

Verifique as entradas do banco de dados de engenharia de tráfego no PCC.

Ação

A partir do modo operacional, execute o show ted database extensive comando.

Significado

O banco de dados de engenharia de tráfego inclui entradas anunciadas dos roteadores R1, R2 e R3, que o PCE usa para computação de caminhos externos para o PCC.

Verifique os LSPs SR-TE
Propósito

Verifique a criação de LSPs SR-TE no PCC.

Ação

Do modo operacional, execute o show path-computation-client lspe show spring-traffic-engineering lsp detailos show route protocol spring-te comandos.

Significado

As saídas mostram que dois LSPs SR-TE —adj_sid_lsp e node_sid_lsp— foram criados pelo PCE para os segmentos de adjacência e nós, respectivamente.

O LSP de static_srte_lsp_1roteamento por segmentos é habilitado com a capacidade da delegação. O Delegation info campo mostra o status de controle e roteamento dos LSPs delegados por PCE. Externally controlled significa que o PCE tem controle sobre os LSPs. Externally routed significa que o PCE forneceu o ERO para o caminho de roteamento de origem.

Verificar a criação de rotas de túnel
Propósito

Verifique as rotas de túnel criadas para os LSPs SR-TE que estão incluídos na tabela de roteamento inet.3 no PCC.

Ação

Do modo de operação, execute o show route table inet.3 extensive comando.

Significado

Rotas de túnel foram criadas para o destino LSP controlado por PCE com SR-TE como rótulo de protocolo.

Verificar as entradas da tabela de encaminhamento
Propósito

Verifique se o destino SR-TE LSP para o Roteador R3 está instalado na tabela de encaminhamento do PCC.

Ação

Do modo de operação, execute o show route forwarding-table destination ip-address extensive comando.

Significado

O endereço IP de destino SR-TE LSP para o Roteador R3 está instalado como uma entrada de encaminhamento.

Verifique o uso de rotas de túnel para encaminhamento de rotas estáticas
Propósito

Verifique se a rota estática está tomando a rota de túnel criada para os LSPs SR-TE.

Ação

Do modo operacional, execute e show route ip-addressshow route forwarding-table destination ip-address comandos.

Significado

As saídas mostram que a rota estática para o Roteador R3 usa a rota de túnel criada para o SR-TE LSP.

Caminho comutada por rótulos de roteamento por segmentos estáticos

A arquitetura de roteamento por segmentos permite que os dispositivos de entrada em uma rede central guiem o tráfego por caminhos explícitos. Você pode configurar esses caminhos usando listas de segmentos para definir os caminhos que o tráfego de entrada deve seguir. O tráfego de entrada pode ser rotulado ou tráfego IP, fazendo com que a operação de encaminhamento no dispositivo de entrada seja uma troca de rótulos ou uma busca baseada em destino.

Entendendo o LSP de roteamento por segmentos estático nas redes MPLS

Roteamento de pacotes de origem ou roteamento por segmentos é uma arquitetura de plano de controle que permite que um roteador de entrada guie um pacote através de um conjunto específico de nós e links na rede sem depender dos nós intermediários na rede para determinar o caminho real que deve tomar.

Introdução aos LSPs de roteamento por segmentos

O roteamento por segmentos aproveita o paradigma de roteamento de fonte. Um dispositivo direciona um pacote através de uma lista ordenada de instruções, chamadas segmentos. Um segmento pode representar qualquer instrução, topológica ou baseada em serviços. Um segmento pode ter um nó local semântico para um nó de roteamento por segmentos ou para um nó global dentro de um domínio de roteamento por segmentos. O roteamento por segmentos impõe um fluxo por qualquer caminho topológico e cadeia de serviços, mantendo o estado por fluxo apenas no dispositivo de entrada para o domínio de roteamento por segmentos. O roteamento por segmentos pode ser aplicado diretamente à arquitetura MPLS sem alterações no plano de encaminhamento. Um segmento é codificado como um rótulo MPLS. Uma lista ordenada de segmentos é codificada como uma pilha de rótulos. O segmento a processar está no topo da pilha. Após a conclusão de um segmento, o rótulo relacionado é estourado da pilha.

Os LSPs de roteamento por segmentos podem ser dinâmicos ou estáticos.

Dynamic segment routing LSPs— Quando um LSP de roteamento por segmentos é criado por um controlador externo e baixado em um dispositivo de entrada por extensões de protocolo de elementos de computação de caminho (PCEP), ou de uma política de roteamento por segmentos BGP por extensões de roteamento por segmentos BGP, o LSP é provisionado dinamicamente. A lista de segmentos do LSP dinâmico de roteamento por segmentos está contida no PCEP Explicit Route Object (ERO), ou na política de roteamento por segmentos BGP do LSP.

Static segment routing LSPs— Quando um LSP de roteamento por segmentos é criado no dispositivo de entrada por meio da configuração local, o LSP é provisionado estaticamente.

Um LSP de roteamento por segmentos estático pode ser classificado ainda mais como LSPs coloridos e não coloridos com base na configuração da color declaração no [edit protocols source-packet-routing source-routing-path lsp-name] nível hierárquico.

Por exemplo:

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

Aqui, cada declaração primária e secundária refere-se a uma lista de segmentos.

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

Benefícios do uso de LSPs de roteamento por segmentos

  • O roteamento por segmentos estático não depende do estado de encaminhamento de LSP em roteadores de trânsito. Dessa forma, eliminando a necessidade de provisionamento e manutenção por estado de encaminhamento de LSP no núcleo.

  • Ofereça maior escalabilidade às redes MPLS.

LSP de roteamento por segmentos estáticos coloridos

Um LSP de roteamento por segmentos estático configurado com a color declaração é chamado de LSP colorido.

Entendendo os LSPs de roteamento por segmentos estáticos coloridos

Semelhante a uma política de roteamento por segmentos BGP, a rota de entrada do LSP colorido é instalada nas inetcolor.0 tabelas ou inet6color.0 roteamento, com destination-ip-address, color como chave para o mapeamento do tráfego IP.

Um LSP de roteamento por segmentos estático e colorido pode ter um SID de ligação, para o qual uma rota é instalada na mpls.0 tabela de roteamento. Este rótulo SID vinculante é usado para mapear o tráfego rotulado para o LSP de roteamento por segmentos. Os gateways da rota são derivados das configurações da lista de segmentos nos caminhos primário e secundário.

Lista de segmentos de LSPs de roteamento por segmentos coloridos

Os LSPs de roteamento por segmentos estáticos coloridos já oferecem suporte para o modo de rótulo de primeiro salto de resolução de um LSP. No entanto, o modo IP de primeiro salto não é suportado para LSPs coloridos de roteamento por segmentos. A partir do Junos OS Release 19.1R1, um recurso de verificação de confirmação é introduzido para garantir que todas as listas de segmentos que contribuam para as rotas coloridas tenham o rótulo mínimo presente para todos os saltos. Se esse requisito não for atendido, o compromisso será bloqueado.

LSP de roteamento por segmentos estáticos não coloridos

Um LSP de roteamento por segmentos estático configurado sem a color declaração é um LSP não colorido. Semelhante aos túneis de roteamento por segmentos PCEP, a rota de entrada é instalada nas inet.3 tabelas ou inet6.3 roteamento.

O Junos OS oferece suporte a LSPs de roteamento de segmentos estáticos não coloridos em roteadores de entrada. Você pode provisionar LSP de roteamento por segmentos estáticos não coloridos configurando um caminho roteado de origem e uma ou mais listas de segmentos. Essas listas de segmentos podem ser usadas por vários LSPs de roteamento de segmentos não coloridos.

Entendendo os LSPs de roteamento por segmentos não coloridos

O LSP de roteamento por segmentos não coloridos tem um nome único e um endereço IP de destino. Uma rota de entrada para o destino é instalada na tabela de roteamento inet.3 com uma preferência padrão de 8 e uma métrica de 1. Essa rota permite que serviços não coloridos sejam mapeados para o LSP de roteamento por segmentos relativos ao destino. Caso o LSP de roteamento por segmentos não colorido não exija uma rota de entrada, a rota de entrada pode ser desativada. Um LSP de roteamento por segmentos não colorido usa o rótulo SID de ligação para alcançar a costura LSP de roteamento por segmentos. Este rótulo que pode ser usado para modelar o LSP de roteamento por segmentos como um segmento que pode ser usado ainda mais para construir outros LSPs de roteamento por segmentos de forma hierárquica. O trânsito do rótulo SID vinculante, por padrão, tem uma preferência de 8 e uma métrica de 1.

A partir do Junos OS Release 18.2R1, LSPs de roteamento de segmentos não coloridos configurados na entrada do dispositivo são relatados ao Elemento de computação de caminho (PCE) por meio de uma sessão de protocolo de elementos de computação de caminho (PCEP). Esses LSPs de roteamento por segmentos não coloridos podem ter rótulos de identificador de serviço (SID) vinculantes associados a eles. Com esse recurso, o PCE pode usar este rótulo SID de ligação na pilha de rótulos para provisionar caminhos LSP de roteamento por segmentos iniciados por PCE.

Um LSP de roteamento por segmentos não colorido pode ter no máximo 8 caminhos primários. Se houver vários caminhos primários operacionais, o mecanismo de encaminhamento de pacotes (PFE) distribui tráfego pelos caminhos com base nos fatores de balanceamento de carga, como o peso configurado no caminho. Isso é igual custo multi caminho (ECMP) se nenhum dos caminhos tiver um peso configurado sobre eles ou ECMP ponderado se pelo menos um dos caminhos tiver um peso não zero configurado nos caminhos. Em ambos os casos, quando um ou alguns dos caminhos falham, o PFE reequilibra o tráfego sobre os caminhos restantes que automaticamente leva à obtenção da proteção de caminhos. Um LSP de roteamento por segmentos não colorido pode ter um caminho secundário para a proteção dedicada de caminhos. Após falha em um caminho primário, o PFE reequilibra o tráfego para os caminhos primários funcionais restantes. Caso contrário, o PFE muda o tráfego para o caminho de backup, alcançando assim a proteção do caminho. Um LSP de roteamento por segmentos não colorido pode especificar uma métrica para [edit protocols source-packet-routing source-routing-path lsp-name] suas rotas de entrada e encadernação de SID. Vários LSPs de roteamento por segmentos não coloridos têm o mesmo endereço de destino que contribui para o próximo salto da rota de entrada.

Vários LSPs de roteamento por segmentos não coloridos têm o mesmo endereço de destino que contribui para o próximo salto da rota de entrada. Cada caminho (principal ou secundário) de cada LSP de roteamento por segmentos é considerado como um candidato de gateway, se o caminho estiver funcional e o LSP de roteamento por segmentos tiver a melhor preferência de todos esses LSPs de roteamento por segmentos. No entanto, o número máximo de gateways que o próximo salto pode conter não pode exceder o limite de multi-caminho RPD, que é de 128 por padrão. Caminhos extras são podados, primeiro caminhos secundários e depois caminhos primários. Uma determinada lista de segmentos pode ser referida várias vezes como caminhos primários ou secundários por esses LSPs de roteamento por segmentos. Neste caso, existem vários gateways, cada um com um ID de túnel LSP de roteamento por segmentos exclusivo. Esses gateways são distintos, embora tenham uma interface e pilha de rótulo de saída idênticas. Um LSP de roteamento por segmentos não colorido e um LSP de roteamento por segmentos coloridos também podem ter o mesmo endereço de destino. No entanto, eles correspondem a diferentes endereços de destino para rotas de entrada, já que o endereço de destino do LSP de roteamento por segmentos coloridos é construído com seu endereço de destino e cor.

Nota:

No caso de um LSP de roteamento por segmentos não coloridos estático e um LSP de roteamento por segmentos criado por PCEP coexistirem e tiverem o mesmo que resolver que contribui para a mesma rota de entrada, se eles também tiverem a mesma preferência. Caso contrário, o LSP de roteamento por segmentos com a melhor preferência é instalado para a rota.

Lista de segmentos de LSPs de roteamento por segmentos não coloridos

Uma lista de segmentos consiste em uma lista de saltos. Esses saltos são baseados no rótulo SID ou em um endereço IP. O número de rótulos de SID na lista do segmento não deve exceder o limite máximo da lista de segmentos. A ligação máxima da lista de segmentos a um túnel LSP é aumentada de 8 para 128, com máximo de 1000 túneis por sistema. No máximo 128 caminhos primários são suportados por LSP de roteamento por segmentos estáticos. Você pode configurar o limite máximo da lista de segmentos no nível de [edit protocols source-packet-routing] hierarquia.

Antes do Junos OS Release 19.1R1, para que um LSP de roteamento por segmentos estáticos não colorido fosse utilizável, o primeiro salto da lista de segmentos tinha que ser um endereço IP de uma interface de saída e o segundo a nth hops poderia ser rótulos de SID. A partir do Junos OS Release 19.1R1, esse requisito não se aplica, pois o primeiro salto dos LSPs estáticos não coloridos agora oferece suporte para rótulos SID, além de endereços IP. Com o suporte do selo de primeiro salto, o mpLS de redirecionamento rápido (FRR) e multicaminho ponderado de igual custo é habilitado para resolver os LSPs de roteamento de segmentos estáticos não coloridos, semelhantes aos LSPs estáticos coloridos.

Para que o modo de rótulo de primeiro salto entre em vigor, você deve incluir a inherit-label-nexthops declaração global ou individualmente para uma lista de segmentos, e o primeiro salto da lista do segmento deve incluir endereço IP e rótulo. Se o primeiro salto incluir apenas endereço IP, a inherit-label-nexthops declaração não terá qualquer efeito.

Você pode configurar inherit-label-nexthops em qualquer uma das seguintes hierarquias. A inherit-label-nexthops declaração só entra em vigor se o primeiro salto da lista do segmento incluir endereço IP e rótulo.

  • Segment list level— No nível da [edit protocols source-packet-routing segment-list segment-list-name] hierarquia.

  • Globally— No nível da [edit protocols source-packet-routing] hierarquia.

Quando a inherit-label-nexthops declaração é configurada globalmente, ela tem precedência sobre a configuração do nível da lista de segmentos, e a inherit-label-nexthops configuração é aplicada a todas as listas de segmentos. Quando a inherit-label-nexthops declaração não está configurada globalmente, apenas listas de segmentos com rótulos e endereço IP presentes no primeiro salto, e configuradas com declaração são resolvidas usando inherit-label-nexthops rótulos SID.

Para LSPs estáticos dinâmicos não coloridos, que são os LSPs de roteamento por segmentos orientados por PCEP, a inherit-label-nexthops declaração deve ser habilitada globalmente, pois a configuração no nível do segmento não é aplicada.

Tabela 4 descreve o modo de resolução LSP de roteamento por segmentos com base na especificação do primeiro salto.

Tabela 4: Resolução LSP estática não colorida com base na especificação do first hop

Especificação do primeiro salto

Modo de resolução de LSP

Somente endereço IP

Por exemplo:

segment-list path-1 {
    hop-1 ip-address 172.16.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

A lista de segmentos é resolvida usando o endereço IP.

Apenas SID

Por exemplo:

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

A lista de segmentos é resolvida usando rótulos SID.

Endereço IP e SID (sem a inherit-label-nexthops configuração)

Por exemplo:

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Por padrão, a lista do segmento é resolvida usando endereço IP.

Endereço IP e SID (com a inherit-label-nexthops configuração)

Por exemplo:

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

A lista de segmentos é resolvida usando rótulos SID.

Você pode usar o show route ip-address protocol spring-te active-path table inet.3 comando para ver os LSPs de roteamento de segmentos não coloridos com várias listas de segmentos instaladas na tabela de roteamento inet.3.

Por exemplo:

Nota:

O primeiro tipo de lista de segmentos de um LSP de roteamento estático por segmentos pode causar uma falha no comprometimento, se:

  • Diferentes listas de segmentos de um túnel têm diferentes tipos de resolução de primeiro salto. Isso é aplicável a LSPs de roteamento estático de segmentos coloridos e não coloridos. No entanto, isso não se aplica a LSPs orientados por PCEP; uma mensagem de log do sistema é gerada para a incompatibilidade no tipo de resolução do primeiro salto no momento da computação do caminho.

    Por exemplo:

    O comprometimento do túnel lsp1 falha, já que o caminho 1 é do modo de endereço IP e o caminho 2 é do modo de rótulo.

  • O SID de ligação é habilitado para o LSP estático não colorido cujo tipo de lista de segmentos é o rótulo SID.

    Por exemplo:

    A configuração do SID vinculante sobre a lista de segmentos de rótulos é suportada apenas para LSPs estáticos coloridos e não para LSPs estáticos não coloridos.

Provisionamento LSP de roteamento por segmentos estático

O provisionamento por segmentos é realizado por roteador. Para um determinado segmento em um roteador, um rótulo exclusivo de identificador de serviços (SID) é alocado de um pool de rótulos desejado que pode ser do pool dinâmico de rótulos para um rótulo SID de adjacência ou do bloco global de roteamento por segmentos (SRGB) para um SID de prefixo ou SID de nó. O rótulo SID de adjacência pode ser alocado dinamicamente, que é o comportamento padrão, ou ser alocado em um pool local de rótulos estáticos (SRLB). Uma rota para o rótulo SID é então instalada na tabela mpls.0.

O Junos OS permite o roteamento estático por segmentos LSPs configurando a segment declaração no nível hierárquico [edit protocols mpls static-label-switched-path static-label-switched-path] . Um LSP de segmento estático é identificado por um rótulo SID exclusivo que se encaixa no pool de rótulos estáticos do Junos OS. Você pode configurar o pool de rótulos estáticos do Junos OS configurando a static-label-range static-label-range declaração no nível de [edit protocols mpls label-range] hierarquia.

Limitações de LSP de roteamento por segmentos estáticos

  • Atualmente, o Junos OS tem uma limitação de que o próximo salto não pode ser construído para empurrar mais do que os rótulos máximos de profundidade da lista de segmentos. Assim, uma lista de segmentos com mais do que as etiquetas SID máximas (excluindo o rótulo SID do primeiro salto que é usado para resolver o encaminhamento do próximo salto) não é utilizável para LSPs de roteamento por segmentos coloridos ou não coloridos. Além disso, o número real permitido para um determinado LSP de roteamento por segmentos pode ser ainda menor do que o limite máximo, se um serviço MPLS estiver no LSP de roteamento por segmentos ou o LSP de roteamento por segmentos estiver em um caminho de proteção de link ou nós. Em todos os casos, o número total de rótulos de serviços, rótulos SID e rótulos de proteção de enlaces ou nós não deve exceder a profundidade máxima da lista de segmentos. Você pode configurar o limite máximo da lista de segmentos no [edit protocols source-packet-routing] nível de hierarquia. LSPs de roteamento de segmentos não coloridos com menos ou igual aos rótulos de SID máximos podem ser costurados para construir um LSP de roteamento por segmentos mais longo. Isso é chamado de costura LSP de roteamento por segmentos. Ela pode ser alcançada usando o rótulo binding-SID.

  • A costura LSP de roteamento por segmentos é realmente realizada no nível do caminho. Se um LSP de roteamento por segmentos não colorido tiver vários caminhos que são várias listas de segmentos, cada caminho pode ser costurado de forma independente a outro LSP de roteamento por segmentos não colorido em um ponto de costura. Um LSP de roteamento por segmentos não colorido dedicado à costura pode desativar a instalação de rota de entrada configurando no-ingress a declaração no [edit protocols source-packet-routing source-routing-path lsp-name] nível de hierarquia.

  • No máximo 128 caminhos primários e 1 caminho secundário são suportados por LSP de roteamento por segmentos estáticos não coloridos. Se houver uma violação na configuração, a verificação de confirmação falha com um erro.

  • A ligação máxima da lista de segmentos a um túnel LSP é aumentada de 8 para 128, com máximo de 1000 túneis por sistema. No máximo 128 caminhos primários são suportados por LSP de roteamento por segmentos estáticos. Como limitação, o suporte máximo de sensor para caminho LSP é de apenas 32000.

  • Se alguma lista de segmentos estiver configurada com mais rótulos do que a profundidade máxima da lista de segmentos, a verificação de confirmação de configuração falhará com um erro.

Criação dinâmica de LSPs de roteamento por segmentos

Em redes de roteamento por segmentos que tenham cada dispositivo de borda (PE) de provedor conectado a todos os outros dispositivos PE, uma grande quantidade de configuração é necessária para a configuração dos caminhos de comutada por rótulos de roteamento por segmentos (LSPs), embora apenas alguns caminhos de roteamento por segmentos projetados por tráfego (SR-TE) possam ser usados. Você pode permitir a criação dinâmica trigerred de BGP desses LSPs para reduzir a quantidade de configuração em tais implantações.

Configuração do modelo LSP de roteamento dinâmico por segmentos

Para configurar o modelo para permitir a criação dinâmica de LSPs de roteamento por segmentos, você deve incluir a declaração spring-te na [edit routing-options dynamic-tunnels] hierarquia.

  • A seguir, uma configuração de amostra para o modelo LSP de roteamento dinâmico por segmentos coloridos:

  • A seguir, uma configuração de amostra para o modelo LSP de roteamento dinâmico de segmentos não colorido:

Resolução de LSPs dinâmicos de roteamento por segmentos
Resolução do LSP de roteamento dinâmico por segmentos coloridos

Quando os prefixos BGP são atribuídos à comunidade de cores, eles são inicialmente resolvidos pela política de catch-all-route-for-that-particular-color e, por sua vez, o modelo SR-TE no qual o prefixo BGP deve ser resolvido é identificado. Os destinos sid é então derivado do atributo de próximo salto de prefixo de carga BGP. Por exemplo, se o próximo salto do prefixo de carga BGP for um endereço IP que pertence ao Dispositivo A, então o nó-SID do Dispositivo A é tomado e um rótulo correspondente é preparado e empurrado para a parte inferior da pilha. O prefixo de carga BGP é resolvido em um modo somente para cores, onde o nó-SID do Dispositivo A está na parte inferior da pilha de rótulo final, e as etiquetas de caminho SR-TE estão por cima.

O nome final do modelo LSP é uma combinação de prefixo, cor e nome do túnel; por exemplo, <prefix>:<color>:dt-srte-<tunnel-name>. A cor do nome LSP é exibida no formato hexadecimal, e o formato do nome do túnel é semelhante ao que o RSVP acionou nomes LSP.

Para resolver com sucesso uma rede de destino colorida, a cor deve ter um mapeamento de modelo válido, seja para uma cor específica ou através do color-any modelo. Sem um mapeamento válido, o túnel não é criado e a solicitação de rota BGP para resolução permanece sem solução.

Resolução de LSPs de roteamento dinâmico por segmentos nãocolorizados

As rotas catch-all para LSPs não coloridos são adicionadas à tabela de roteamento inet.3. O destino do túnel não colorido deve ser configurado em uma configuração diferente spring-te com apenas um nome de modelo na lista de mapeamento. Este nome de modelo é usado para todas as rotas de túnel que correspondam a qualquer uma das redes de destino configuradas sob a mesma spring-te configuração. Esses túneis são semelhantes aos túneis RSVP em funcionalidade.

O nome final do modelo LSP é uma combinação de prefixo e nome do túnel; por exemplo, <prefix>:dt-srte-<tunnel-name>.

Configuração dinâmica de amostra LSP de roteamento por segmentos

O modelo de LSP dinâmico de roteamento por segmentos sempre traz um caminho parcial. O SID de nó de último salto é derivado automaticamente no momento da criação do túnel, dependendo do sid de endereço de próximo salto de protocolo (PNH). O mesmo modelo pode ser usado por vários túneis para destinos diferentes. Nesses casos, o caminho parcial permanece o mesmo, e apenas o último salto muda dependendo do PNH. Modelos de LSP de roteamento dinâmico por segmentos não são comuns a um único túnel, pois, como resultado, um caminho completo não pode ser realizado sobre ele. Você pode usar uma lista de segmentos se um caminho completo for usado.

LSPs coloridos de roteamento dinâmico por segmentos

Configuração de amostra para LSPs coloridos de roteamento dinâmico por segmentos:

Se o PNH do serviço BGP for de 10.22.44.0/24 com comunidade de cores 123/124/125, então ele usa o modelo SR-TE sr_lsp1 para criar túnel. Qualquer outra cor para o mesmo prefixo PNH usa sr_lsp2 modelo devido à color-any configuração.

Para a configuração de amostra acima mencionada, as entradas de rota são as seguintes:

  1. inetcolor.0 tunnel route: 10.22.44.0-0/24 -- > RT_NH_TUNNEL

  2. inet6color.0 tunnel route: ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(prefixo) -> 10,22,44,55-101(PNH) Nome do túnel LSP = 10,22,44,55:65:dt-srte-tunnel1

    R1(prefixo) -> ffff:10.22.44.55-101(PNH) Nome do túnel LSP = 10,22,44,55:65:dt-srte-tunnel1

    R1(prefixo) -> ffff:10.22.44.55-124(PNH) Nome do túnel LSP = 10,22,44,55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

    10.22.44.55-101/64 --> <next-hop>

    10.22.44.55-124/64 --> <next-hop>

  5. inet6color.0 tunnel route:

    ffff::10.22.44.55-101/160 -- > <next-hop>

    ffff::10.22.44.55-124/160 --> <next-hop>

O túnel 101 colorido (10.22.44.55:65:dt-srte-tunnel1) é criado devido à color-any configuração.

As rotas IPv6 em inet6color.0 são devido à mpls ipv6-tunneling configuração. Ele permite que rotas IPv6 com comunidade de cores sejam resolvidas na tabela inet6color.0 convertendo rotas SR-TE armazenadas na tabela de roteamento inetcolor.0 para endereços IPv4 mapeados com IPv4 e depois copiando-as na tabela de roteamento inet6color.0.

LSPs de roteamento dinâmico por segmentos não coloridos

Configuração de amostra para LSPs de roteamento dinâmico de segmentos não coloridos:

Para a configuração de amostra acima mencionada, as entradas de rota são as seguintes:

  1. inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL

  2. inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(prefixo) -> 10.33.44.55(PNH) Nome do modelo LSP = LSP1 --- 10.33.44.55:dt-srte-tunnel2

    R1(prefixo) -> ffff:10.33.44.55(PNH) Nome do modelo LSP = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 10.33.44.55/32 -- > <next-hop>

  5. inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>

O túnel não colorido (10.33.44.55:dt-srte-tunnel2) é criado usando túnel de túnel dinâmico2, pois não tem cor configurada. As rotas IPv6 em inet6.3 são devido à mpls ipv6-tunneling configuração. Ele permite que as rotas IPv6 sejam resolvidas em uma rede MPLS convertendo rotas SR-TE armazenadas na tabela de roteamento inet.3 para endereços IPv6 mapeados com IPv4 e depois copiando-as na tabela de roteamento inet6.3.

LSP de roteamento dinâmico por segmentos não resolvido

Configuração de amostra para LSPs de roteamento dinâmico por segmentos não resolvidos:

Para a configuração de amostra acima mencionada, as entradas de rota são as seguintes:

  1. inetcolor.0 tunnel route: 10.33.44.0 - 24/0 -> RT_NH_TUNNEL 10.1.1.0 - 0 /24 -> RT_NH_TUNNEL

  2. inet6color.0 tunnel route: ffff::10.33.44.0 - 0/120 -> RT_NH_TUNNEL ffff::10.1.1.0 - 0/24 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: O túnel R1(prefixo) -> 10,33,44,55-124(PNH) não foi criado. (Modelo não encontrado para a cor).

Considerações para configurar a criação dinâmica de LSPs de roteamento por segmentos

Ao configurar a criação dinâmica de LSPs de roteamento por segmentos, leve em consideração o seguinte:

  • Um modelo pode ser atribuído com um objeto colorido. Quando a configuração dinâmica do túnel spring-te inclui um modelo com um objeto colorido, você deve configurar todos os outros modelos com objetos coloridos também. Todos os destinos são considerados coloridos nessa configuração.

  • Um modelo pode ter uma lista de cores definidas nele, ou pode ser configurado com a opção color-any . Ambas as opções podem coexistir na mesma spring-te configuração. Nesses casos, os modelos atribuídos com cores específicas têm uma preferência maior.

  • Em uma spring-te configuração, apenas um modelo pode ser definido com a opção color-any .

  • O mapeamento de cor para modelo é feito de uma a uma base. Uma única cor não pode mapear vários modelos.

  • O nome do modelo deve ser configurado na spring-te declaração sob a [edit protocols] hierarquia e deve ter a opção primary habilitada.

  • Destinos coloridos e não coloridos não podem coexistir na mesma spring-te configuração.

  • Você não pode configurar as mesmas redes de destino, com ou sem cor, em diferentes spring-te declarações de configuração.

  • Na configuração não colorida spring-te , apenas um modelo pode ser configurado sem objeto colorido.

Serviços suportados por LSPs dinâmicos de roteamento por segmentos

Os serviços a seguir são suportados por LSPs coloridos de roteamento dinâmico por segmentos:

  • VPN de Camada 3

  • BGP EVPN

  • Serviços de política de exportação

Os serviços a seguir são suportados por LSPs de roteamento dinâmico de segmentos não coloridos:

  • VPN de Camada 3

  • VPN de Camada 2

  • Configurações multicaminho

Comportamento com múltiplas fontes de túnel no roteamento por segmentos

Quando duas fontes baixam rotas para o mesmo destino a partir do roteamento por segmentos (por exemplo, túneis estáticos e dinâmicos), a preferência por roteamento por segmentos é usada para escolher a entrada de rota ativa. Um valor mais alto tem maior preferência. Caso a preferência permaneça a mesma, a fonte do túnel é usada para determinar a entrada da rota.

Limitações dinâmicas de LSPs de roteamento por segmentos

Os LSPs dinâmicos SR-TE não oferecem suporte aos seguintes recursos e funcionalidades:

  • Túneis de roteamento por segmentos IPv6.

  • Túneis estáticos.

  • O 6PE não é compatível.

  • CSPF distribuído.

  • O tunelamento sBFD e LDP não é suportado para LSPs dinâmicos SR-TE e em um modelo.

  • Instale e rotas B-SID em um modelo.

Mapeamento baseado em cores de 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.

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, a última cor anexada é considerada 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 na instância vrf-exportde roteamento do serviço VPN, na exportação de grupos ou na exportação de vizinhos do grupo no [edit protocols bgp] nível hierárquico. 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 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.

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-importde 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:

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 resolution-map declaração e encaminhar a política na instância vrf-importde roteamento de um serviço VPN, importação de grupo ou importação de vizinhos de grupo no nível hierárquico [edit protocols 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(s) é resolvida usando um protocolo IP colorido próximo salto na forma de ip-address:color.

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 na tabela de roteamento 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:

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

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) 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. O BGP usa e tabelas inet.3inet6.3 para mapeamento não colorido. Isso permite que você anuncie prefixos BGP-LU IPv6 e IPv4 com um endereço IPv6 de próximo salto em redes somente IPv6, onde os roteadores não têm nenhum endereço IPv4 configurado. Com esse recurso, atualmente oferecemos suporte ao BGP IPv6 LU sobre SR-TE com underlay IS-IS.

In Figura 9, o controlador configura 4 túneis coloridos em uma rede de núcleo IPv6 configurada com SR-TE. Cada túnel colorido toma um caminho diferente para o roteador de destino D, dependendo do mapa de resolução definido. O controlador configura um túnel SR-TE colorido para 2001:db8:3701:2d05 interface no roteador D. O BGP importa políticas para atribuir um mapa de cor e resolução ao prefixo recebido 2001:db8:3700:6/128. Com base na cor da comunidade atribuída, o BGP-LU resolve o próximo salto colorido para o prefixo DE LU BGP IPv6 de acordo com a política de mapa de resolução atribuída.

Figura 9: BGP IPv6 LU sobre IPv6 SR-TE coloridoBGP IPv6 LU sobre IPv6 SR-TE colorido

O BGP-LU oferece suporte aos seguintes cenários:

  • BGP IPv4 LU sobre BGP IPv4 SR-TE colorido, com extensões ISIS/OSPF IPv4 SR.

  • BGP IPv4 LU em cores estáticas e IPv4 SR-TE não coloridos, com extensões ISIS/OSPF IPv4 SR.

  • BGP IPv6 LU sobre BGP IPv6 SR-TE colorido, com extensões ISIS IPv6 SR.

  • BGP IPv6 LU sobre IPv6 SR-TE estático e não colorido, com extensões ISIS IPv6 SR.

  • Serviços de VPN de Camada 3 IPv6 com endereço local IPv6 e endereço vizinho IPv6.

  • Serviços de VPN de Camada 3 IPv6 no BGP IPv6 SR-TE, com extensões ISIS IPv6 SR.

  • Serviços de VPN de Camada 3 IPv6 sobre IPv6 SR-TE de cor estática e não colorida, com extensões ISIS IPv6 SR.

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 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) com base em fallback para LDP LSP na tabela de roteamento inetcolor.0.

  • LSP SR-TE colorido.

  • Plataformas virtuais.

  • Junos OS de 64 bits.

  • Sistemas lógicos.

  • BGP rotulado de 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.

Modelos de túnel para LSPs de roteamento por segmentos iniciados por PCE

Você pode configurar um modelo de túnel para LSPs de roteamento por segmentos iniciados por PCE para repassar dois parâmetros adicionais para esses LSPs — detecção bidirecional de encaminhamento (BFD) e tunelamento LDP.

Quando um LSP de roteamento por segmentos iniciado por PCE está sendo criado, o LSP é verificado em relação às declarações de política (se houver) e, se houver correspondência, a política aplica o modelo configurado para esse LSP. A configuração do modelo só será herdada se não for fornecida pela fonte LSP (PCEP); por exemplo, métrica.

Para configurar um modelo:

  1. Inclua a declaração de modelo de caminho de roteamento de origem no nível de [edit protocols source-packet-routing] hierarquia. Você pode configurar os parâmetros adicionais de tunelamento BFD e LDP aqui.

  2. Inclua a declaração de mapa-modelo de caminho de roteamento de origem no nível de [edit protocols source-packet-routing] hierarquia para listar as declarações de política contra as quais o LSP iniciado pelo PCE deve ser verificado.

  3. Definir uma política para listar os LSPs em que o modelo deve ser aplicado.

    A from declaração pode incluir o nome LSP ou a expressão regular de LSP usando as lsp condições e lsp-regex as condições de correspondência. Essas opções são mutuamente exclusivas, para que você possa especificar apenas uma opção em um determinado ponto no momento.

    A then declaração deve incluir a opção sr-te-template com uma ação de aceitação. Isso aplica o modelo ao LSP iniciado por PCE.

Leve o seguinte em consideração ao configurar um modelo para LSPs iniciados por PCE:

  • A configuração do modelo não é aplicável a LSPs de roteamento por segmentos configurados estáticamente ou ao LSP de roteamento por segmentos de qualquer outro cliente.

  • A configuração fornecida por PCEP tem precedência sobre a configuração do modelo.

  • O PCEP LSP não herda a configuração da lista de segmentos do modelo.

Exemplo: Configuração de caminho comutada por rótulos de roteamento por segmentos estáticos

Este exemplo mostra como configurar caminhos comuados de rótulos de roteamento por segmentos estáticos (LSPs) em redes MPLS. Essa configuração ajuda a trazer maior escalabilidade às redes MPLS.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Sete plataformas de roteamento universal 5G da Série MX

  • Junos OS Release 18.1 ou posterior em todos os roteadores

Antes de começar, certifique-se de configurar as interfaces do dispositivo.

Visão geral

O Junos OS é um conjunto de caminhos explícitos de roteamento por segmentos configurados no roteador de entrada de um túnel de roteamento por segmentos estáticos não coloridos, configurando a segment-list declaração no nível de [edit protocols source-packet-routing] hierarquia. Você pode configurar o túnel de roteamento por segmentos configurando a source-routing-path declaração no [edit protocols source-packet-routing] nível de hierarquia. O túnel de roteamento por segmentos tem um endereço de destino e um ou mais caminhos primários e caminhos opcionalmente secundários que se referem à lista de segmentos. Cada lista de segmentos consiste em uma sequência de saltos. Para o túnel de roteamento por segmentos estáticos não coloridos, o primeiro salto da lista de segmentos especifica um endereço IP imediato de próximo salto e o segundo para Nth hop especifica os rótulos de segmento identificado (SID) correspondentes ao link ou nó que o caminho atravessa. A rota para o destino do túnel de roteamento por segmentos está instalada na tabela inet.3.

Topologia

Neste exemplo, configure a VPN de camada 3 nos roteadores de borda do provedor PE1 e PE5. Configure o protocolo MPLS em todos os roteadores. O túnel de roteamento por segmentos é configurado do roteador PE1 ao roteador PE5 com um caminho primário configurado no roteador PE1 e no roteador PE5. O Roteador PE1 também está configurado com caminho secundário para a proteção de caminhos. Os roteadores de trânsito PE2 a PE4 são configurados com rótulos SID de adjacência com rótulo pop e uma interface de saída.

Figura 10: Caminho comutada por rótulos de roteamento por segmentos estáticosCaminho comutada por rótulos de roteamento por segmentos estáticos

Configuração

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuração do dispositivo PE1
Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.

Para configurar o dispositivo PE1:

  1. Configure as interfaces.

  2. Configure o número e as opções do sistema autônomo para controlar as opções de roteamento de encaminhamento de pacotes.

  3. Configure as interfaces com o protocolo MPLS e configure a gama de rótulos MPLS.

  4. Configure o tipo de grupo de pares, endereço local, família de protocolo para NLRIs em atualizações e endereço IP de um vizinho para o grupo de pares.

  5. Configure as interfaces de área de protocolo.

  6. Configure o endereço IPv4 e os rótulos de caminhos primários e secundários para políticas de engenharia de tráfego de roteamento de origem (TE) de roteamento de pacotes de origem de protocolo (SPRING).

  7. Configure o endereço IPv4 de destino, rótulo SID de ligação, caminho de roteamento primário e de origem secundária para o protocolo SPRING.

  8. Configure opções de políticas.

  9. Configure as informações da comunidade BGP.

  10. Configure a instância de roteamento VRF1 com tipo de instância, interface, diferenciador de roteador, importação de VRF, exportação e rótulo de tabela. Configure a política de exportação e a interface de área para OSPF de protocolo.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show interfacesshow routing-optionsshow policy-optionsshow protocolscomandos e show routing-instances os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Configuração do dispositivo PE2
Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.

  1. Configure as interfaces.

  2. Configure o LSP estático para MPLS de protocolo.

  3. Configure interfaces e alcance de rótulo estático para MPLS de protocolo.

  4. Configure interfaces para OSPF de protocolo.

Resultados

A partir do modo de configuração no roteador PE2, confirme sua configuração inserindo o show interfaces e show protocols comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Confirme se a configuração está funcionando corretamente.

Verificação da entrada de rota da tabela de roteamento inet.3 do roteador PE1
Propósito

Verifique a entrada de rota da tabela de roteamento inet.3 do roteador PE1.

Ação

A partir do modo operacional, entre no show route table inet.3 comando.

Significado

A saída exibe as rotas de entrada de túneis de roteamento por segmentos.

Verificação das entradas da tabela de roteamento mpls.0 do roteador PE1
Propósito

Verifique as entradas de rota da tabela de roteamento mpls.0

Ação

A partir do modo operacional, entre no show route table mpls.0 comando.

Significado

A saída exibe as etiquetas SID de túneis de roteamento por segmentos.

Verificação do LSP projetado para tráfego spring do roteador PE1
Propósito

Verifique os LSPs projetados por tráfego SPRING nos roteadores de entrada.

Ação

A partir do modo operacional, entre no show spring-traffic-engineering overview comando.

Significado

A saída exibe a visão geral dos LSPs projetados por tráfego SPRING no roteador de entrada.

Verificação de LSPs projetados por tráfego SPRING no roteador de entrada PE1
Propósito

Verifique os LSPs projetados por tráfego SPRING no roteador de entrada.

Ação

A partir do modo operacional, entre no show spring-traffic-engineering lsp detail comando.

Significado

A saída exibe detalhes dos LSPs projetados por tráfego SPRING no roteador de entrada

Verificação das entradas da tabela de roteamento mpls.0 do roteador PE2
Propósito

Verifique as entradas da tabela de roteamento mpls.0 do roteador PE2.

Ação

A partir do modo operacional, entre no show route table mpls.0 comando.

Verificando o status de segmentos LSP MPLS estáticos do roteador PE2
Propósito

Verifique a situação dos segmentos LSP MPLS do roteador PE2.

Ação

A partir do modo operacional, entre no show mpls static-lsp comando.

Significado

A saída exibe o status de segmentos MPLS LSP estáticos do roteador PE2.

Habilitação de CSPF distribuído para LSPs de roteamento por segmentos

Antes do Junos OS Release 19.2R1S1, para a engenharia de tráfego de caminhos de roteamento por segmentos, você pode configurar explicitamente caminhos estáticos ou usar caminhos computados de um controlador externo. Com o CSPF (Constrained Shortest Path First) distribuído para o recurso LSP de roteamento por segmentos, você pode computar um LSP de roteamento por segmentos localmente no dispositivo de entrada de acordo com as restrições que você configurou. Com esse recurso, os LSPs são otimizados com base nas restrições configuradas e tipo de métrica (engenharia de tráfego ou IGP). Os LSPs são computados para utilizar os caminhos ECMP disponíveis para o destino com a compressão da pilha de rótulos de roteamento por segmentos habilitada ou desabilitada.

Restrições distribuídas de computação CSPF

Os caminhos LSP de roteamento por segmentos são computados quando todas as restrições configuradas são atendidas.

O recurso de computação CSPF distribuído oferece suporte ao seguinte subconjunto de restrições especificado no rascunho da Internet, draft-ietf-spring-segment-routing-policy-03.txt, Política de roteamento por segmentos para engenharia de tráfego:

  • Inclusão e exclusão de grupos administrativos.

  • Inclusão de endereços IP soltos ou rigorosos.

    Nota:

    Você pode especificar apenas IDs de roteador nas restrições de salto frouxas ou rigorosas. Rótulos e outros endereços IP não podem ser especificados como restrições de salto frouxas ou rigorosas no Junos OS Release 19.2R1-S1.

  • Número máximo de IDs de segmentos (SIDs) na lista de segmentos.

  • Número máximo de listas de segmentos por caminho de roteamento por segmentos do candidato.

O recurso de computação CSPF distribuído para LSPs de roteamento por segmentos não oferece suporte aos seguintes tipos de restrições e cenários de implantação:

  • Endereços IPV6.

  • LSPs de engenharia de tráfego de roteamento por segmentos entre domínios (SR-TE).

  • Interfaces não numeradas.

  • Vários protocolos de roteamento, como OSPF, ISIS e BGP-LS, habilitados ao mesmo tempo.

  • Computação com prefixos ou endereçoscast como destinos.

  • Incluindo e excluindo endereços IP de interface como restrições.

Algoritmo de computação CSPF distribuído

O recurso de computação CSPF distribuído para LSPs de roteamento por segmentos usa o algoritmo de compressão de pilha de rótulos com CSPF.

Compressão de pilha de rótulos habilitada

Uma pilha de rótulos compactada representa um conjunto de caminhos desde uma fonte até um destino. Geralmente consiste em SIDs de nós e SIDs de adjacência. Quando a compressão da pilha de rótulos é habilitada, o resultado da computação é um conjunto de caminhos que maximizam o ECMP até o destino, com número mínimo de SIDs na pilha, ao mesmo tempo em que está em conformidade com as restrições.

Desabilitação de pilha de rótulos

A computação CSPF multicaminho com compressão de pilha de rótulos desativada encontra listas N de segmentos até o destino, onde:

  • O custo de todas as listas de segmentos é igual e o mesmo que a menor métrica de engenharia de tráfego para chegar ao destino.

  • Cada lista de segmentos é composta por SIDs de adjacência.

  • O valor N é o número máximo de listas de segmentos permitidas para o caminho do candidato por configuração.

  • Nenhuma lista de segmentos é idêntica.

  • Cada lista de segmentos satisfaz todas as restrições configuradas.

Banco de dados distribuído de computação CSPF

O banco de dados usado para computação SR-TE tem todos os links, nós, prefixos e suas características, independentemente de a engenharia de tráfego estar habilitada nesses nós de publicidade. Em outras palavras, é a união do banco de dados de engenharia de tráfego (TED) e do banco de dados de estado do enlace IGP de todos os domínios que o nó de computação aprendeu. Como resultado, para que o CSPF funcione, você deve incluir a igp-topology declaração no nível de [edit protocols isis traffic-engineering] hierarquia.

Configuração de restrições distribuídas de computação CSPF

Você pode usar um perfil de computação para agrupar logicamente as restrições de computação. Esses perfis de computação são referenciados pelos caminhos de roteamento por segmentos para computação dos LSPs de roteamento por segmentos primários e secundários.

Para configurar um perfil de computação, inclua a declaração de perfil de computação no nível de [edit protocols source-packet-routing] hierarquia.

A configuração para as restrições de computação suportadas incluem:

  • Administrative groups

    Você pode configurar grupos administrativos sob o nível de [edit protocols mpls] hierarquia. O Junos OS aplica a configuração de grupo administrativo às interfaces de engenharia de tráfego de roteamento por segmentos (SR-TE).

    Para configurar as restrições de computação, você pode especificar três categorias para um conjunto de grupos administrativos. A configuração de restrição de computação pode ser comum a todos os caminhos de roteamento por segmentos de candidatos, ou pode estar nos caminhos individuais do candidato.

    • include-any— Especifica que qualquer link com pelo menos um dos grupos administrativos configurados da lista é aceitável para o caminho a percorrer.

    • include-all— Especifica que qualquer link com todos os grupos administrativos configurados da lista é aceitável para o caminho a percorrer.

    • exclude— Especifica que qualquer link que não tenha nenhum dos grupos administrativos configurados na lista é aceitável para o caminho a percorrer.

  • Explicit path

    Você pode especificar uma série de IDs de roteador no perfil de computação como uma restrição para a computação dos caminhos do candidato SR-TE . Cada salto precisa ser um endereço IPv4 e pode ser do tipo rigoroso ou solto. Se o tipo de salto não estiver configurado, é usado rigoroso. Você deve incluir a opção compute na declaração da lista de segmentos ao especificar a restrição explícita do caminho.

  • Maximum number of segment lists (ECMP paths)

    Você pode associar um caminho de candidato a uma série de listas dinâmicas de segmentos. Os caminhos são caminhos ECMP, onde cada lista de segmentos se traduz em um gateway de salto próximo com peso ativo. Esses caminhos são resultado da computação de caminhos com ou sem compressão.

    Você pode configurar este atributo usando a opção maximum-computed-segment-lists maximum-computed-segment-lists na declaração de configuração de perfil de computação . Essa configuração determina o número máximo dessas listas de segmentos computadas para um determinado LSP primário e secundário.

  • Maximum segment list depth

    O parâmetro máximo de computação de profundidade da lista de segmentos garante que, entre os caminhos ECMP que satisfaçam todas as outras restrições, como grupo administrativo, apenas os caminhos que têm listas de segmentos menores ou iguais à profundidade máxima da lista de segmentos são usados. Quando você configura esse parâmetro como uma restrição sob o perfil de computação, ele substitui a maximum-segment-list-depth configuração sob o nível de [edit protocols source-packet-routing] hierarquia, se presente.

    Você pode configurar este atributo usando a opção maximum-segment-list-depth maximum-segment-list-depth na declaração de configuração de perfil de computação .

  • Protected or unprotected adjacency SIDs

    Você pode configurar o SID de adjacência protegido ou desprotegido como uma restrição sob o perfil de computação para evitar links com o tipo SID especificado.

  • Metric type

    Você pode especificar o tipo de métrica no link a ser usado para computação. Por padrão, os LSPs SR-TE usam métricas de engenharia de tráfego dos links para computação. A métrica de engenharia de tráfego para links é anunciada por extensões de engenharia de tráfego dos protocolos IGP. No entanto, você também pode optar por usar a métrica de IGP para computação usando a configuração do tipo métrica no perfil de computação.

    Você pode configurar este atributo usando a opção metric-type (igp | te) na declaração de configuração de perfil de computação .

Computação CSPF distribuída

Os caminhos do candidato SR-TE são computados localmente de modo que satisfaçam as restrições configuradas. Quando a compressão da pilha de rótulos é desativada, o resultado de computação CSPF multi-caminho é um conjunto de pilhas SID de adjacência. Quando a compressão da pilha de rótulos é habilitada, o resultado é um conjunto de pilhas de rótulos compactadas (compostas por SIDs adjacentes e SIDs de nós).

Quando os caminhos secundários são computados, os links, nós e SRLGs tomados pelos caminhos primários não são evitados para a computação. Para obter mais informações sobre caminhos primários e secundários, consulte Configuração de LSPs primários e secundários.

Para qualquer LSPs com resultado de computação mal-sucedido, a computação é retried à medida que o banco de dados de engenharia de tráfego (TED) muda.

Interação entre a computação distribuída de CSPF e os recursos SR-TE

Pesos associados a caminhos de uma política SR-TE

Você pode configurar pesos em relação a caminhos SR-TE computados e estáticos, que contribuem para os próximos saltos da rota. No entanto, um único caminho que tenha a computação habilitada pode resultar em várias listas de segmentos. Essas listas de segmentos computados são tratadas como ECMP entre si. Você pode atribuir pesos ECMP hierárquicos a esses segmentos, considerando os pesos atribuídos a cada uma das primárias configuradas.

Detecção de linhas de vida do BFD

Você pode configurar a detecção de linhas de vida da BFD para os caminhos primários ou secundários computados. Cada caminho primário ou secundário computado pode resultar em várias listas de segmentos, como resultado, os parâmetros de BFD configurados em relação às listas de segmentos são aplicados a todas as listas de segmentos computados. Se todos os caminhos primários ativos forem trilhados, o caminho secundário pré-programado (se fornecido) ficará ativo.

nexthops herdados de rótulo

Você não é obrigado a habilitar explicitamente a inherit-label-nexthops configuração sob a [edit protocols source-packet-routing segment-list segment-list-name] hierarquia para os caminhos primários ou secundários computados, pois é um comportamento padrão.

Recurso de tradução automática

Você pode configurar o recurso de tradução automática nas listas de segmentos e os caminhos primários ou secundários com a referência automática de recursos dessas listas de segmentos. Por outro lado, o principal ou secundário em que o recurso de computação está habilitado não pode fazer referência a nenhuma lista de segmentos. Como resultado, você não pode habilitar tanto o recurso de computação quanto o recurso de tradução automática para um determinado caminho primário ou secundário. No entanto, você pode ter um LSP configurado com um caminho primário com tipo de computação e outro com tipo de tradução automática.

Configurações distribuídas de amostra de computação CSPF

Exemplo 1

No exemplo 1,

  • O caminho primário não computado faz referência a uma lista de segmentos configurada. Neste exemplo, a lista static_sl1 de segmentos configurada é referenciada, e também serve como nome para este caminho primário.

  • Um primário computado deve ter um nome configurado, e este nome não deve fazer referência a nenhuma lista de segmentos configurada. Neste exemplo, compute_segment1 não é uma lista de segmentos configurada.

  • O compute_profile_red perfil de computação é aplicado ao caminho principal com o nome compute_segment1.

  • O compute_profile_red perfil de computação inclui uma lista de tipos computede segmentos, que é usada para especificar a restrição explícita do caminho para a computação.

Os pesos para o próximo salto de caminho computado e próximo salto estático são 2 e 3, respectivamente. Supondo que os próximos saltos para caminhos computados sejam comp_nh1, comp_nh2e comp_nh3, e o próximo salto para o caminho estático seja static_nh, os pesos são aplicados da seguinte forma:

Próximo salto

Peso

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Exemplo 2

No exemplo 2, tanto os caminhos primários quanto secundários podem ser do tipo de computação e podem ter seus próprios perfis de computação.

Exemplo 3

No exemplo 3, quando a computação é mencionada em um caminho primário ou secundário, ela resulta na computação local de um caminho até o destino sem quaisquer restrições ou outros parâmetros para a computação.

Exemplo: Configuração do encaminhamento baseado em coS e roteamento baseado em políticas para LSPs SR-TE

SUMMARY O encaminhamento baseado em CoS (CBF) e o roteamento baseado em políticas (PBR, também conhecido como encaminhamento baseado em filtro) podem ser habilitados para LSPs projetados para roteamento de segmentos não coloridos (SR-TE) para direcionar o tráfego seletivo por um caminho SR-TE explícito, proporcionando-lhe o benefício de atender tráfego com base em classe de serviço ou política.

Encaminhamento baseado em coS e roteamento baseado em políticas para visão geral dos LSPs SR-TE

Benefícios do encaminhamento baseado em CoS (CBF) e roteamento baseado em políticas (PBR) para LSPs SR-TE

Com A CBF e a PBR, você pode:

  • Use combinações de caminhos de engenharia de tráfego de roteamento por segmentos (SR-TE) para direcionar o tráfego de serviços no núcleo.

  • Escolha os serviços de suporte para resolver nos caminhos SR-TE selecionados.

Fontes de caminho de roteamento por segmentos que oferecem suporte à CBF e ao PBR

As seguintes fontes de caminho de roteamento por segmentos oferecem suporte ao encaminhamento baseado em CoS e ao roteamento baseado em políticas:

  • Static SR–TE paths— Configurou de forma estatística caminhos de roteamento de fonte que têm toda a pilha de rótulos configurada estaticamente.

  • PCEP— Provisionamento dinâmico de caminhos de roteamento de fonte criados em um controlador e baixados em um roteador de entrada em um ERO, seja por extensões de roteamento por segmentos PCEP ou em uma política de roteamento por segmentos BGP por extensões de roteamento por segmentos BGP.

  • Dynamic LSPs— Túneis criados dinamicamente desencadeados pelo módulo de túnel dinâmico que têm resolução ERO de último salto.

  • Auto-translated paths— Caminhos de roteamento de fonte configurados de forma estatística que são traduzidos automaticamente.

Considerações para configuração de CBF e PBR para LSPs SR-TE

Lembrar:

  • A CBF e o PBR são habilitados apenas em LSPs SR-TE não coloridos que são configurados de forma estatica ou dinâmica.

  • As configurações da CBF e do PBR para LSPs SR-TE podem coexistir em um dispositivo; a ordem de configuração decide o tipo em que as rotas são encaminhadas.

  • Para PBR, se o primeiro salto do SR-TE LSP for um rótulo, então você deve incluir a resolution preserve-nexthop-hiearchy declaração no nível de [edit routing-options] hierarquia.

  • O encaminhamento de rotas com base em classe para a CBF é visível apenas na tabela de encaminhamento e não nas rotas.

  • O encaminhamento baseado em políticas de rotas para PBR é feito nas rotas e é visto na show route saída de comando.

Configure o encaminhamento baseado em CoS e o roteamento baseado em políticas para LSPs SR-TE

SUMMARY O encaminhamento baseado em CoS (CBF) e o roteamento baseado em políticas (PBR, também conhecido como FBF de encaminhamento baseado em filtro) podem ser usados para direcionar tráfego seletivo usando um caminho explícito de engenharia de tráfego de roteamento por segmentos (SR-TE) (LSP). Apenas LSPs de roteamento por segmentos não coloridos que tenham o próximo salto configurado como rótulo de primeiro salto ou endereço IP de suporte a CBF e PBR.

Antes de começar

  • Você deve estar executando o Junos OS Release 20.1 e versões posteriores para habilitar CBF e PBR para LSPs SR-TE não coloridos.

  • Configure as interfaces do dispositivo e garanta que os dispositivos estejam conectados à rede.

  • Definir listas de segmentos e configurar LSPs SR-TE e seus parâmetros associados.

Para configurar um LSP SR-TE, faça o seguinte:

  1. Definir a lista de segmentos com parâmetros de rótulo.

    Por exemplo:

  2. Configure o caminho de roteamento de origem para os LSPs SR-TE e especifique o valor de preferência e o segmento primário para o caminho.

    Por exemplo:

Agora, você pode configurar a CBF e o PBR para os LSPs SR-TE configurados.

Para configurar a CBF, faça o seguinte

  1. Definir classificadores de ponto de código de serviços diferenciados (DSCP) para lidar com pacotes IPv4 de entrada, aulas de encaminhamento e valores de opção.

    Por exemplo:

  2. Defina as aulas de encaminhamento (FCs) para pacotes de agrupamento para transmissão e atribua pacotes a filas de saída.

    Por exemplo:

  3. Atribua os classificadores configurados às interfaces do dispositivo.

    Por exemplo:

  4. Definir opções de política de encaminhamento baseadas em CoS com o next-hop LSP como o SR-TE LSP.

    Por exemplo:

  5. Descarte o tráfego que não atende a nenhuma aula de encaminhamento no mapa de próximo salto.

    Por exemplo:

  6. Configure uma declaração de política que especifica que as rotas correspondentes ao filtro de rota estão sujeitas ao mapeamento de próximo salto cos especificado pelo nome do mapa.

    Por exemplo:

  7. Aplicar a política às rotas que estão sendo exportadas da tabela de roteamento para a tabela de encaminhamento. Isso permite a CBF para LSPs SR-TE.

    Por exemplo:

  8. Confirmar a configuração.

Verify CBF Configuration

Você pode verificar a configuração da CBF usando o show route forwarding-table destination ip-address vpn vpn-name extensive comando.

Para a CBF, o encaminhamento de rotas baseado em classe é visível apenas na tabela de encaminhamento, ao contrário do PBR, onde as rotas filtradas são visíveis na saída de show route comando.

Para configurar o PBR, faça o seguinte

  1. Configure uma declaração de política que especifica que as rotas correspondentes ao protocolo e ao filtro de rota estão sujeitas ao next-hop LSP ou são balanceadas como multicaminho de custo igual (ECMP) na tabela de encaminhamento.

    Por exemplo:

  2. Configure o dispositivo para realizar a resolução de rotas personalizada no protocolo próximo salto de rotas.

    Nota:

    A resolution preserve-nexthop-hierarchy declaração é obrigatória para que o PBR funcione quando o primeiro salto do SR-TE LSP for um rótulo.

  3. Aplicar a política às rotas que estão sendo exportadas da tabela de roteamento para a tabela de encaminhamento. Isso permite PBR para LSPs SR-TE.

    Por exemplo:

  4. Confirmar a configuração.

Verify PBR Configuration

Você pode verificar a configuração do PBR usando o show route destination-prefix comando.

A saída exibe todos os próximos saltos para o prefixo de destino, 4.0.0.1. As expanded-nh extensive opções exibem os próximos saltos filtrados sob o Krt_inh campo de saída.

Para PBR, a show route saída de comando faz a filtragem baseada em políticas de rotas.

Habilitando vários caminhos para LSPs SR-TE no PCEP

Você pode configurar vários caminhos (primários ou secundários) para PCEP SR-TE LSPs (configurados estaticamente, delegados e iniciados por PCE) conforme definido no draft-ietf-pce-multipath-06. Apenas uma configuração de caminho secundário é suportada e apenas para LSPs SR-TE configurados estaticamente. As extensões PCEP definidas em draft-ietf-pce-multipath-06 permitem que o PCEP propagasse vários caminhos (multicaminho) para os LSPs entre endpoints PCEP.

Benefícios de vários caminhos para PCEP SR-TE LSPs

  • Os LSPs podem ter vários conjuntos de EROs até um destino

  • Oferece recursos de balanceamento de carga configurando pesos para EROs individuais

  • Alinha-se com o rascunho da arquitetura SR-TE para definir caminhos do candidato

Os recursos de caminho múltiplos PCEP a seguir são suportados:

  • Quando o PCEP para vários caminhos é habilitado (padrão), você pode configurar vários caminhos primários (ou secundários) em um caminho de candidato configurado e controlado pelo PCC.

  • Quando o PCEP para vários caminhos é desativado, você pode configurar apenas um caminho primário em um caminho de candidato. A configuração do caminho secundário não é permitida.

Se você habilitar multicaminhos PCEP, compute-profile agora pode ser configurado com número máximo de listas de segmentos (maximum-computed-segment-lists) superiores a 1.

Nota:

Quando o PCEP para vários caminhos for habilitado, o PCCD não enviará restrições para caminhos de candidato controlados pelo PCC.

Quando o recurso multicaminho pcep é habilitado, a configuração de caminho secundário é permitida para um caminho de candidato PCC não delegado, o objeto DE ROTA EXPLÍCITA (EROs) específico para o caminho secundário é enviado para o PCE com a bandeira de backup definida para o ERO. Os caminhos primários não incluem o MULTIPATH-BACKUP-TLV na mensagem PCRpt. O caminho secundário inclui MULTIPATH-BACKUP-TLV com conjunto de bandeiras de backup.

As seguintes funcionalidades multicaminho pcep são suportadas:

  • Objeto de TLV de peso multicaminho (MULTIPATH-WEIGHT-TLV) em objeto de atributo de caminho (PATH-ATTRIB)

  • Multipath-BACKUP TLV no objeto atributo de caminho (PATH-ATTRIB) apenas para LSPs SR-TE controlados pelo PCC

  • MULTIPATH-CAP TLV em objeto LSP do PCEP

  • Restringe vários caminhos primários e secundários no caminho do candidato SR quando o multicaminho PCEP é desativado

  • Múltiplos caminhos primários e caminhos secundários no caminho do candidato SR quando o multicaminho PCEP é habilitado para LSPs controlados por PCC

  • Listas de segmentos computadas máximas (max-computed-segment-lists) mais de 1 em perfil de computação SR-TE para LSPs delegados e iniciados por PCE

  • Vários EROs para o caminho de candidato iniciado por PCE no SR-TE e no PCCD

  • SRv6 LSPs

  • SR MPLS (IPv4)

  • Túneis dinâmicos SR MPLS (IPv4)

  • Suporte a vários controladores

  • Múltiplos caminhos de ERO para caminhos de candidato coloridos e não coloridos para PCE iniciados, configurados e controlados por PCC

  • Compatível para trás com versões anteriores do Paragon Pathfinder. Para uma compatibilidade retrógrada, você precisa configurar disable-multipath-capability a declaração de configuração no nível [edit protocols pcep] de hierarquia.

  • Suporte a código de erro para falha na validação de caminhos de candidatos iniciados por PCE

    • O total de caminhos de sub candidatos por candidato é limitado a 127. Para LSPs iniciados pelo PCE, se o número de caminhos de ERO se cruzar 127, o SR-TE lançar ERRO para PCCD (e o PCCD enviar mensagem de erro de PCEP para PCE) e os caminhos ERO correspondentes forem rejeitados.

As seguintes mensagens de erro de PCEP são suportadas:

Tabela 5: Mensagens de erro do PCEP
Tipo de erro Valor do erro Significado Uso
19 20 Caminho de backup não suportado Isso ocorre quando o MULTIPATH-BACKUP TLV é recebido pelo PCC.
24 1 Parâmetros de instanciação inaceitáveis Isso ocorre quando o PCE tenta adicionar mais de 127 caminhos de sub-candidato por caminho de candidato.

Limitações

As seguintes limitações de PCEP aplicam-se:

  • As TLVs a seguir mencionadas no draft-ietf-pce-multipath-06 não são suportadas:

    • TLV de backup multicaminho

    • Caminho de direção oposta multicaminho TLV

    • Caminho do candidato do Composto

  • Quando o recurso multicaminho é desativado no PCEP, a configuração de vários caminhos de sub-candidato não é permitida. No entanto, em dispositivos Junos sem recursos multicaminho (versões do Junos OS antes de 22.4R1), é permitida a configuração de caminho de vários sub-candidatos. Quando o multissegmento PCEP é habilitado (por padrão), vários caminhos primários são permitidos para LSPs controlados por PCC com a finalidade de relatar. No entanto, apenas um caminho primário é suportado para o caminho do candidato delegado quando o multi-segmento pcep é habilitado.

  • Grupos administrativos e quaisquer outras restrições não serão notificados ao PCE para pcc configurados e controlados caminhos de candidato SR-MPLS e SRv6 (com configurações primárias individuais ou múltiplas). Não há impacto para caminhos de candidatos delegados e iniciados pela PCE.

  • Quando o recurso multicaminho PCEP é habilitado, a configuração de caminho secundário é permitida para caminhos de candidatos não delegados. Quando o recurso multicaminho PCEP é desativado, a configuração de caminho secundário não é permitida.

  • Os caminhos do candidato não podem ter uma mistura de LSPs iniciados e delegados por PCE.

  • Vários caminhos de sub-candidatos para um caminho de candidato colorido iniciado pela PCE não são suportados.

  • Recursos de delegado com vários caminhos de sub-candidato em um caminho de candidato não são suportados.

Configuração

Para permitir que o PCCD envie recursos multicaminho tlv em objeto LSP para notificar a lista máxima de segmentos computados para um caminho de candidato específico, inclua a propagate-max-segmentlist declaração de configuração no nível [edit protocols pcep] hierarquia. Por padrão, o TLV não é enviado em objeto LSP.

Para desativar a sessão de vários recursos do PCEP para todos os PCEs, inclua a disable-multipath-capability declaração de configuração no nível [edit protocols pcep] de hierarquia.

Você pode habilitar os seguintes traceoptions de protocolo para diagnóstico:

  • user@host# set protocols pcep traceoptions

  • user@host# set protocols pcep pce pce1 traceoptions

  • user@host# set protocols source-packet-routing traceoptions

Você pode usar os seguintes comandos de exibição para exibir o estado dos LSPs no PCC:

  • user@host> show path-computation-client lsp— Exibir o estado dos caminhos comuados por rótulos (LSPs) conhecidos pelo Cliente de Computação de Caminho (PCC).

  • user@host> show path-computation-client lsp extensive— Exibir um nível de saída extensivo sobre cada LSP conhecido — LSPs ponto a ponto e ponto a multiponto.

  • user@host> show path-computation active-pce— Exibir o status do multicaminho nas sessões.

  • user@host> show spring-traffic-engineering lsp detail— Exibir detalhes de entrada da engenharia de tráfego SPRING.

Habilitando a segurança da camada de transporte para sessões de PCEP

A segurança de camada de transporte (TLS) oferece suporte para autenticação por pares, criptografia de mensagens e integridade. Você pode habilitar o TLS no Path Computation Client (PCC) para estabelecer conexão TCP com o elemento de computação de caminho (PCE), conforme definido no RFC 8253. Isso cria uma sessão de PCEP segura (PCEPS) para transportar mensagens PCEP.

Este documento descreve como permitir que o TLS para sessões de PCEP proteja interações com PCE, incluindo o início dos procedimentos de TLS, o mecanismo de aperto de mão do TLS, os métodos TLS para autenticação por pares. O transporte seguro para PCEP sobre TLS também é conhecido como PCEPS.

Benefícios de habilitar o TLS para sessões de PCEP

  • Protege as sessões de PCEP contra ataques como spoofing (imitação de PCC ou PCE), espionagem (interceptação de mensagens), falsificação e negação de serviço.

  • Aproveita os benefícios de segurança do TLS.

Habilitação de TLS no cliente de computação de caminhos (PCC)

Para habilitar o TLS no PCC e estabelecer a sessão PCEPS, definir a tls-strict declaração de CLI no nível [edit protocols pcep] de hierarquia.

Depois de habilitar uma declaração de configuração rigorosa, os seguintes eventos acontecem:

  1. Flaps de sessão do PCEP. Qualquer conexão TCP existente é terminada e uma reconexão é feita usando TLS.

  2. O PCC estabelece a conexão TCP com o PCE.

  3. Os procedimentos de TLS são iniciados pela StartTLS mensagem do PCE ao PCC e do PCC ao PCE. A StartTLS mensagem é enviada pelo PCC e o StartTLSWait timer é iniciado. Você pode configurar o StartTLSWait temporizador configurando a start-tls-wait-timer seconds declaração de CLI no nível [edit protocols pcep pce pce-id] de hierarquia.

    Nota:

    O valor recomendado para o StartTLSWait temporizador é de 60 segundos e não deve ser menor do que o OpenWait temporizador. O valor padrão OpenWait do timer é definido em 60 segundos.

    • Se a mensagem aberta for recebida pelo PCC em vez de mensagem, PCErr mensagem com tipo de StartTLS erro definida para 1 (falha no estabelecimento de sessão do PCEP) e valor de erro definido para 1 (recepção de uma mensagem aberta inválida ou uma mensagem não aberta), e a sessão do TCP será fechada.

    • Se StartTLS a mensagem não for recebida do PCE, o StartTLSWait PCC enviará uma PCErr mensagem com o tipo de erro definido para 25 (falha no PCEP StartTLS ) e o valor de erro definido para 5 (sem StartTLS mensagem (nem PCErr/Open) antes StartTLSWait do término do temporizador, e a sessão do TCP será fechada.

  4. A negociação e o estabelecimento da conexão TLS acontecem.

  5. A troca de mensagens PCEP é iniciada conforme RFC5440.

Nota:

Se você não habilitar a tls-strict declaração de CLI sob o [edit protocols pcep] nível de hierarquia, então, ao estabelecer uma sessão de PCEP, se a StartTLS mensagem for recebida pelo PCC em vez de Open mensagem, PCErr mensagem com tipo de erro definida para 1 (falha no estabelecimento da sessão do PCEP) e valor de erro definido para 1 (recepção de uma mensagem aberta inválida ou uma mensagem não aberta), então a sessão de TCP está fechada.

Nota:

Para estabelecer uma sessão PCEPS bem-sucedida, o TLS deve ser habilitado tanto no PCC quanto no PCE.

Atualização de certificados usando a infraestrutura de chave pública (PKI)

O PKI não notifica o PCC sobre o término do certificado. Você deve atualizar manualmente o certificado usando o seguinte comando CLI. Neste método, você deve acompanhar a data de expiração do certificado.

Estabelecendo a conexão TLS

As etapas a seguir descrevem como uma conexão TLS (usando TLS v1.2) é estabelecida:

  1. Gere certificados para os nós (dispositivos junos OS/pce-server). Você pode gerar os certificados usando um dos seguintes métodos:

    • Method 1— Gere o key-pair e o CSR no dispositivo e envie este CSR para a CA para obter o certificado. Assim que o certificado for emitido, ele é copiado para a caixa e instalado.

    • Method 2— Gere o key-pair e o certificado fora da caixa. Tanto o certificado quanto a chave privada são copiados no dispositivo e instalados juntos.

  2. Carregue a autoridade de certificação (CA) no PCC para que o certificado de servidor PCE possa ser validado em relação ao CA carregado.

    Nota:

    Os CAs podem ser carregados em hierarquia plana como um CA independente. Se um CA é um sub-CA de outro CA, a cadeia é construída internamente pelo PKI.

    Nota:

    O certificado do servidor deve ser assinado por um CA. Certificados auto-assinados não são permitidos.

  3. Habilite o TLS no PCC.

  4. A sessão do PCEP está estabelecida sobre o TLS com o mecanismo de dissíduo de TLS.

  5. O servidor PCE ouve a porta 4189 para solicitações de conexão de PCC por meio do TLS.

  6. O PCC inicia a solicitação de conexão à porta de destino 4189.

  7. Após a conclusão de um aperto de mão de três vias, o aperto de mão do TLS começa usando os certificados e a autenticação de ida é feita (o PCC autentica o certificado do servidor). Tanto o servidor quanto o cliente aguardam tempo para StartTLSWait receber a StartTLS mensagem. Você pode configurar o StartTLSWait temporizador configurando a start-tls-wait-timer seconds declaração de CLI no nível [edit protocols pcep pce pce-id] de hierarquia.

    Nota:

    O valor recomendado para o StartTLSWait temporizador é de 60 segundos e não deve ser menor do que o OpenWait temporizador. O valor padrão OpenWait do timer é definido em 60 segundos.

  8. Após a sessão bem-sucedida do TLS, o PCC e o PCE iniciam o estabelecimento de sessões de PCEP sobre TLS durante as quais os parâmetros da sessão são negociados.

    • Se a validação do certificado falhar, o PCC encerrará a conexão TCP.

  9. A mensagem PCEP é enviada pela conexão TLS como dados do aplicativo.

  10. A criptografia e a descriptografia acontecem tanto no PCC quanto no PCE após um sucesso no TLS.

  11. Quando a sessão do PCEP é fechada, a sessão do TLS é removida.

Nota:

Se o certificado estiver expirado, revogado ou recarregado durante um PCEP em andamento durante a sessão de TLS, a sessão em curso não será afetada.

Entendendo o mecanismo básico de aperto de mão do TLS

O aperto de mão é uma série de mensagens trocadas entre um servidor e um cliente. As etapas exatas do aperto de mão variam dependendo do algoritmo de troca de chave, pacote de cifras etc. A seguir, as etapas básicas do mecanismo de dissibilimento do TLS:

  1. Client Hello— O cliente inicia o aperto de mão enviando esta mensagem. Esta mensagem contém versão TLS, lista de algoritmos criptográficos suportados ou suíte de cifras e outros detalhes do cliente.

  2. Server Hello— O servidor responde ao Client Hello enviando uma mensagem de Sever Hello. Esta mensagem contém certificado de servidor, algoritmo criptográfico selecionado, id de sessão e chave pública do servidor.

  3. Authentication— O cliente em segundo plano verifica o certificado do servidor com a Autoridade de Certificado configurada que havia emitido o certificado. Em verificação bem-sucedida, o cliente confirma que o servidor é genuíno e continua interagindo.

  4. Optional Client Certificate— Se o servidor tiver solicitado um certificado ao cliente na mensagem Server Hello, o cliente enviará o certificado de cliente (apenas em caso de TLS mútuo).

  5. Client Key Exchange— O cliente envia uma chave secreta criptografada com a chave pública do servidor (adquirida na mensagem Server Hello).

  6. Decrypt secret key— O servidor descriptografa a chave secreta usando a chave privada.

  7. Client Finished— O cliente envia uma mensagem de finalização criptografada com a chave secreta compartilhada e sinais completos.

  8. Server Finished— O servidor responde com uma mensagem de finalização criptografada com a chave secreta compartilhada e os sinais estão completos.

  9. Exchange Messages— As mensagens após a conclusão do aperto de mão são simetricamente criptografadas.

Diagnóstico e validação de TLS para sessões de PCEP

Para diagnósticos, use as seguintes declarações de traceoptions CLI:

Habilite logs PKI usando a configuração a seguir e capture o mesmo arquivo de /var/log/<filename>

Verifique o certificado ca carregado usando o seguinte comando:

Saída de amostra

O seguinte é uma saída amostra de show path-computation-client statistics comando:

Esta saída de amostra fornece as seguintes informações:

  • O TLS está habilitado no PCC.

  • O PCE é capaz de TLS.

  • A sessão de TLS está estabelecida. Isso também indica que o certificado de servidor PCE é válido.

  • O status da sessão do PCEPS está em funcionamento.

Otimização de caminhos de relatórios e métricas computadas no PCEP

O objeto métrico no PCEP é usado para várias finalidades. O objeto métrico indica o tipo métrica usado para otimização de caminhos. O objeto métrico também indica um limite no custo do caminho que não deve ser excedido para que o caminho seja considerado aceitável. O objeto métrico também indica a métrica computada.

Oferecemos suporte a objetos métricas para otimização de caminhos (protocolo de gateway interior, engenharia de tráfego e atraso de caminho) e relatórios de métrica computada para RSVP e LSPs SR-TE.

Nota:

O objeto métrico para otimização de caminhos e relatórios de métrica computada não é aplicável para LSPs SRv6-TE.

Benefícios da otimização do caminho de relatórios e métricas computadas no PCEP

  • Relatórios de métricas de otimização de caminho configurados no PCC ajuda o PCE a estar ciente das restrições usadas para a computação de caminhos.

  • Relatórios de métricas computadas para o PCE. Isso ajuda o PCE a analisar se o LSP requer otimização adicional.

Entendendo as métricas de otimização

A seção a seguir descreve as métricas de otimização pretendidas e reais para LSPs RSVP e SR-TE (SR MPLS) em PCEP.

LSP RSP criado localmente

Para otimizar os LSPs RSVP criados localmente com métricas, configure as métricas de otimização (IGP, TE e atraso de caminho) para que a métrica configurada seja relatada através do PCEP. A métrica computada é enviada como uma métrica real no PCEP por meio da mensagem PCRpt.

RSVP LSP delegado

Para relatar as métricas de otimização para LSPs RSVP delegados, configure as métricas de otimização (IGP, TE e atraso no caminho).

Intended Metric:

  • Quando a métrica de otimização é configurada no momento da delegação do LSP, as informações são enviadas ao PCE por mensagem PCRpt.

  • Quando a métrica de otimização é configurada após a delegação do LSP, a mudança é aplicada no LSP/comunicado ao PCE quando o status de controle de LSP se torna controlado localmente.

  • Quando a mensagem PCUpd é recebida, se a métrica de otimização estiver presente na mensagem, a métrica é usada como métrica pretendida em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCUpd é recebida, se a métrica de otimização não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm a métrica pretendida.

  • Quando o status de controle de LSP mudar para controlado localmente, a métrica de otimização configurada a partir do Junos CLI será a métrica pretendida na mensagem PCRpt.

Actual Metric:

  • Ao delegar o LSP, a mensagem do PCRpt não contém métrica real.

  • Quando a mensagem PCUpd é recebida, se a métrica computada estiver presente na mensagem, a métrica é usada como métrica real em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCUpd é recebida, se a métrica computada não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm métrica real.

  • Quando o status de controle de LSP muda para controlado localmente, a métrica computada pelo PCC é enviada como métrica real na mensagem PCRpt.

LSP RSP de RSVP iniciado por PCE

Para relatar as métricas de otimização para LSPs RSVP iniciados por PCE, configure as métricas de otimização (IGP, TE e atraso de caminho) em um modelo. O modelo é então aplicado ao LSP initado por PCE quando o status de controle de LSP se torna controlado localmente.

Intended Metric:

  • Quando um LSP iniciado por PCE é mapeado em um modelo com métrica de otimização, a configuração é aplicada ao LSP e enviada ao PCE quando o status de controle de LSP muda para controlado localmente.

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica de otimização estiver presente na mensagem, a métrica é usada como métrica pretendida em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica de otimização não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm a métrica pretendida.

  • Quando o status de controle de LSP se torna controlado localmente, a métrica de otimização presente no modelo é usada como métrica pretendida na mensagem PCRpt.

Actual Metric:

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica computada estiver presente na mensagem, a métrica é usada como métrica real em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica computada não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm métrica real.

  • Quando o status de controle de LSP muda para controlado localmente, a métrica computada pelo PCC é enviada como métrica real na mensagem PCRpt.

LSP sr-TE delegado

Para relatar as métricas de otimização para LSPs delegados SR-TE (SR MPLS), configure as métricas de otimização (IGP, TE e atraso no caminho).

Intended Metric:

  • Quando a métrica de otimização é configurada no momento da delegação do LSP, as informações são enviadas ao PCE por meio da mensagem PCRpt.

  • Quando a métrica de otimização é configurada após a delegação do LSP, a mudança é aplicada no LSP/comunicado ao PCE quando o status de controle de LSP se torna controlado localmente.

  • Quando a mensagem PCUpd é recebida, se a métrica de otimização estiver presente na mensagem, a métrica é usada como métrica pretendida em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCUpd é recebida, se a métrica de otimização não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm a métrica pretendida.

  • Quando o status de controle de LSP mudar para controlado localmente, a métrica de otimização configurada a partir do Junos CLI será a métrica pretendida na mensagem PCRpt.

Actual Metric:

  • Quando o LSP é delegado após a criação, no momento da delegação de LSP se o LSP tiver 1 ERO, os valores computados de IGP, TE e métricas de atraso são enviados como métricas reais na mensagem PCRpt.

  • Quando o LSP é delegado após a criação, no momento da delegação de LSP, se o LSP tiver vários EROs, a métrica computada/real não é enviada na mensagem PCRpt, pois a métrica real precisa ser enviada por LSP (não por ERO) no PCEP.

  • Quando a mensagem PCUpd é recebida, se a métrica computada estiver presente na mensagem, a métrica é usada como métrica real em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCUpd é recebida, se a métrica computada não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm métrica real.

  • Quando o status de controle de LSP muda para métricas de controle local, IGP, TE e atraso computadas no PCC são enviadas como métricas reais na mensagem PCRpt.

LSP SR-TE iniciado por PCE

As métricas pretendidas ou a métrica real enviada pelo PCE em mensagens PCInit/PCUpd são relatadas de volta ao PCE por mensagem PCRpt até que o LSP seja controlado externamente.

Intended Metric:

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica de otimização estiver presente na mensagem, a métrica é usada como métrica pretendida em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica de otimização não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm a métrica pretendida.

  • Quando o status de controle de LSP se tornar controlado localmente, a métrica pretendida não será enviada.

Actual Metric:

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica computada estiver presente na mensagem, a métrica é usada como métrica real em mensagens PCRpt subseqüentes até que o status de controle de LSP seja controlado externamente.

  • Quando a mensagem PCInit/PCUpd é recebida, se a métrica computada não estiver presente na mensagem, as mensagens PCRpt subseqüentes não contêm métrica real.

  • Quando o status de controle de LSP muda para mensagens PCRpt controladas localmente, as mensagens PCRpt subseqüentes não contêm métrica real.

Envio de métrica de otimização em mensagem PCRpt

A métrica de otimização é enviada ao PCE por meio da intended-attributes-list mensagem do PCRpt. O valor métrica está definido para 0 e B, as bandeiras C estão definidas para 0. Tipo métrica indica a métrica a ser otimizada.

Envio de métrica computada em mensagem pcrpt

A métrica computada é enviada ao PCE por meio da actual-attributes-list mensagem do PCRpt. O valor métrica é o valor métrica e o tipo de métrica computado indica o tipo de métrica computada. A bandeira B está definida para 0, a bandeira C está definida para 1.

Incompatibilidade para trás para métrica de rota

Como a métrica de rota é suportada usando o fornecedor TLV, o PCC não processará a métrica de rota enviada em objeto métrica pelo PCE da Juniper com suporte ao Northstar e versões mais antigas do paragon pathfinder.

Configuração de métricas de otimização para LSPs

Você pode configurar métricas de otimização (IGP, TE e atraso de caminho) para RSVP LSPs e SR-TE LSP.

Para configurar as métricas de otimização de IGP, TE e atraso de caminho para LSPs RSVP, inclua a metric-type <igp|te|delay|delay minimum> declaração CLI no nível [edit protocols mpls label-switched-path <lsp-name>] de hierarquia.

Para configurar as métricas de otimização de IGP, TE e atraso de caminho para LSPs SR-TE, inclua a metric-type <igp|te|delay|delay minimum> declaração CLI no nível [edit protocols source-packet-routing compute-profile <compute-profile-name>] de hierarquia.

Saída de amostra

Você pode usar os show path-computation-client lsp comandos e show path-computation-client lsp extensive CLI para exibir o estado dos caminhos comuados por rótulos (LSPs) conhecidos pelo Cliente de Computação de Caminho (PCC).

A seguir, uma saída amostral de show path-computation-client lsp extensive:

A saída mostra que o LSP é otimizado com o IGP do tipo métrica. O valor computado da métrica de IGP é de 50. A métrica de rota instalada na tabela de rotas é de 50.

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
21.R1
A partir do Junos OS Release 21.1R1, o Junos OS oferece suporte ao roteamento ativo ininterrupto (NSR) para LSPs ponto a ponto e ponto a multiponto iniciados por RSVP.
21.R1
A partir do Junos OS Release 21.1R1, o Junos OS oferece suporte ao roteamento ativo ininterrupto (NSR) para LSPs de ponto a multiponto iniciados por RSVP iniciados por PCE.
20.2R1
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) para famílias de endereços IPv4 e IPv6.
19.4R1
Você pode associar um único ou intervalo de fluxos multicast MVPN (S,G) a um caminho de comutado por rótulos de ponto a multiponto (LSP) iniciado dinamicamente por PCE.
19.4R1
Você pode configurar um modelo de túnel para LSPs de roteamento por segmentos iniciados por PCE para repassar dois parâmetros adicionais para esses LSPs — detecção bidirecional de encaminhamento (BFD) e tunelamento LDP.
19.1R1
A partir do Junos OS Release 19.1R1, um recurso de verificação de confirmação é introduzido para garantir que todas as listas de segmentos que contribuam para as rotas coloridas tenham o rótulo mínimo presente para todos os saltos.
19.1R1
A partir do Junos OS Release 19.1R1, esse requisito não se aplica, pois o primeiro salto dos LSPs estáticos não coloridos agora oferece suporte para rótulos SID, além de endereços IP. Com o suporte do selo de primeiro salto, o mpLS de redirecionamento rápido (FRR) e multicaminho ponderado de igual custo é habilitado para resolver os LSPs de roteamento de segmentos estáticos não coloridos, semelhantes aos LSPs estáticos coloridos.
18.2R1
A partir do Junos OS Release 18.2R1, LSPs de roteamento de segmentos não coloridos configurados na entrada do dispositivo são relatados ao Elemento de computação de caminho (PCE) por meio de uma sessão de protocolo de elementos de computação de caminho (PCEP).
17.2R1
A partir do Junos OS Release 17.2, além de external cspf, dois novos tipos de computação de caminho são introduzidos para os LSPs controlados por PCE: local cspf e no cspf...
16.1
A partir do Junos OS Release 16.1, você pode garantir uma sessão de PCEP usando a autenticação TCP-MD5 de acordo com o RFC 5440.
16.1
O Junos OS Release 16.1 apresenta o recurso de proteger uma sessão de PCEP usando a autenticação TCP-MD5 de acordo com o RFC 5440.
14.2R4
A partir do Junos OS Release 14.2R4, o suporte à largura de banda automática é fornecido para LSPs controlados por PCE.