Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração PCEP

Visão geral do PCEP

Um elemento de computação de caminho (PCE) é uma entidade (componente, aplicativo ou nó de rede) capaz de computar um caminho ou rota de rede com base em um gráfico de rede e aplicar restrições computacionais. Um PcC (Path Computation Client, Cliente de computação de caminho) é qualquer aplicativo cliente solicitando que uma computação de caminho seja executada por um PCE. O Path Computation Element Protocol (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 para solicitar e enviar caminhos para LSPs com engenharia de tráfego multidomain (TE LSPs). Ele fornece um mecanismo para que uma PCE realize a computação de caminho para LSPs externos de um PCC. As interações PCEP incluem relatórios de status de LSP enviados pelo PCC ao PCE e atualizações de PCE para LSPs externos.

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

Figura 1: Sessão PCEPSessão PCEP

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

Assim, as funções PCEP incluem:

  • Sincronização de estado do túnel LSP entre um PCC e uma PCE stateful — Quando uma conexão PCE com estado ativo é 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 ao PCE.

  • Delegação de controle sobre túneis LSP para uma PCE stateful — um PCE ativo com estado 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 capacita essa delegação de LSPs para a computação de caminhos.

  • Controle de PCE com estado de tempo e sequência de computação de caminho dentro e em todas as sessões do PCEP– Uma PCE com estado ativo modifica um ou mais atributos de LSP, como largura de banda, caminho (ERO) e prioridade (configuração e espera). O PCEP comunica esses novos atributos de LSP da PCE para o PCC, após o qual o PCC re-indica o LSP no caminho especificado.

Suporte ao protocolo de elemento de computação de caminho para visão geral TE RSVP

Entender MPLS RSVP-TE

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

Para a engenharia de tráfego em redes grandes e densas, recursos de MPLS podem ser implementados porque eles potencialmente fornecem a maior parte da funcionalidade disponível a partir de um modelo de sobreposição, de maneira integrada e a um custo menor do que as alternativas atualmente concorrentes. O principal motivo para implementar a tecnologia engenharia de tráfego de MPLS é controlar os caminhos pelos quais o tráfego flue por uma rede. A principal vantagem da implementação engenharia de tráfego de MPLS é que ela fornece uma combinação dos recursos de engenharia de tráfego do ATM, junto com a diferenciação de classe de serviço (CoS) de IP.

Em uma MPLS, as informações do plano de dados são encaminhadas usando a comação de rótulos. Um pacote chegando em um roteador de borda do provedor (PE) da borda do cliente (CE) tem rótulos aplicados a ele, e ele é encaminhado para o roteador PE de saída. Os rótulos são removidos no roteador de saída e depois encaminhados para o destino apropriado como um pacote de IP. Os roteadores de com switching 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 transmitir tráfego entre e por meio dos LSRs. RSVP-TE é um desses protocolos de distribuição de rótulos que permite a um LSR a aprender sobre os mapeamentos de rótulos de outros peers.

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

Quando MPLS e RSVP são combinados, os rótulos estão associados aos fluxos de RSVP. Uma vez estabelecido um LSP, o tráfego pelo caminho é definido pelo rótulo aplicado no nó de ingresso do LSP. O mapeamento do rótulo para o tráfego é realizado usando diferentes critérios. O conjunto de pacotes que são atribuídos pelo 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.

Túneis LSP são uma maneira de estabelecer caminhos unidirecionais comutado por rótulos. O RSVP-TE é construído no protocolo de núcleo RSVP definindo novos objetos e modificando os objetos existentes usados nos objetos PATH e RESV para estabelecimento de LSP. Os novos objetos — objeto LABEL-REQUEST (LRO), RRO (RECORD-ROUTE, objecto LABEL) e ERO (EXPLICIT-ROUTE) são opcionais em relação ao protocolo RSVP, exceto os objetos LRO e LABEL, que são obrigatórios para estabelecer túneis LSP.

Em geral, o RSVP-TE estabelece um caminho comutado por rótulos que garante a entrega do quadro desde a entrada até o roteador de saída. Entretanto, com os novos recursos de engenharia de tráfego, as seguintes funções são suportadas em um MPLS de segurança:

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

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

  • Controle de endpoint, que está associado ao estabelecimento e gerenciamento de túneis LSP nos roteadores de entrada e saída.

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

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

Limitações MPLS RSVP-TE atuais

Embora as extensões de RSVP para engenharia de tráfego possibilitem melhor utilização da rede e atendem aos requisitos de classes de tráfego, o conjunto de protocolos MPLS RSVP-TE atual tem vários problemas inerentes à sua natureza distribuída. Isso causa vários problemas durante a disputa pela capacidade de biseação, especialmente dentro de uma classe de prioridade LSP, na qual um subconjunto de LSPs compartilha a configuração comum e mantém valores de prioridade. As limitações do RSVP-TE incluem:

  • Falta de visibilidade das demandas individuais por LSP e por dispositivo de largura de banda — 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. Informações sobre a utilização de recursos de rede só estão disponíveis como capacidade total reserva por classe de tráfego por interface. O estado de LSP individual está disponível localmente em cada roteador de borda de rótulo (LER) apenas para seus próprios LSPs. Como resultado, surgem vários problemas relacionados ao padrão de demanda, especialmente dentro de uma configuração comum e que têm prioridade.

  • Natureza assíncrona e independente da sinalização de RSVP — No RSVP-TE, as restrições para o estabelecimento de caminhos são controladas por um administrador. Dessa forma, a largura de banda reserva para um túnel LSP é definida pelo administrador e não implica automaticamente nenhum limite no tráfego enviado pelo túnel. Portanto, a largura de banda disponível em um enlace de engenharia de tráfego é a largura de banda configurada para o enlace, exceto a soma de todas as reservas feitas no enlace. Assim, as demandas não reivindicadas em um túnel LSP conduzem à degradação do serviço do LSP, exigindo excesso de largura de banda, bem como os outros LSPs que cumprem os requisitos de largura de banda do enlace de engenharia de tráfego.

  • LSPs estabelecidas com base em opções de caminho dinâmicos ou explícitos 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 LSPs não estar estabelecido quando houver um excesso de demanda de largura de banda.

Como exemplo, está configurado com MPLS RSVP-TE, no qual A e G são os roteadores de borda de rótulo Figura 2 (LERs). Esses roteadores de entrada estabelecem LSPs independentemente com base na ordem das demandas e não têm conhecimento ou controle sobre os LSPs um do outro. 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áfego Exemplo MPLS Engenharia de Tráfego

Os roteadores de entrada estabelecem LSPs com base na ordem na qual as demandas chegam. Se o roteador G receber duas demandas de capacidade 5 cada para G-F, em seguida, G indica dois LSPs – LSP1 e LSP2 – por meio de G-B-D-F. Da mesma forma, quando o Roteador A recebe a terceira demanda de capacidade 10 para A-E, ele sinaliza um LSP, LSP3, por meio de A-B-C-E. No entanto, se a demanda no LSP A-E 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 inferior.

O roteador A deveria ter sinalização da demanda aumentada no LSP3 usando o caminho A-B-D-C-E. Como lSP1 e LSP2 utilizaram o enlace B-D com base na ordem das demandas recebidas, o LSP3 não está sinalização.

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

Uso de uma entidade de computação de caminhos externos

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

No momento, apenas a computação de caminho de roteamento baseada em restrições e em tempo real é 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 nas informações de topologia disponíveis atualmente, informações que geralmente são recentes, mas não são completamente precisas. Os posicionamentos de LSP são otimizados localmente, com base no status atual da rede. Os MPLS RSVP-TE são definidos usando a CLI. Um operador configura o TE LSP, que é sinalização pelo roteador de entrada.

Além dos recursos de engenharia de tráfego existentes, a funcionalidade MPLS RSVP-TE é estendida para incluir uma entidade de computação de caminhos externos, chamada de Path Computation Element (PCE). O PCE calcula o caminho para TE LSPs de roteadores de entrada configurados para controle externo. O roteador de entrada que se conecta a um PCE é chamado de Path Computation Client (PCC). O PCC está configurado com o Path Computation Client Protocol (PCEP) para facilitar a computação de caminho externo por um PCE.

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

Para habilitar a computação de caminho externo para os LSPs TE PCC, inclua a lsp-external-controller pccd instrução nos níveis [edit mpls] e na [edit mpls lsp lsp-name] hierarquia.

Componentes da computação de caminhos externos

Os componentes que compoem um sistema de computação de caminhos externos são:

Elemento de computação de caminho

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

Uma PCE pode ser stateful ou stateless.

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

    Uma PCE com estado é de dois tipos:

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

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

      Nota:

      Em uma configuração redundante com PCEs com estado ativo principal e de backup, o PCE ativo de backup não pode modificar os atributos de LSPs delegadas até que se torne o PCE principal no momento de um failover. No caso de comover, não há previsão de PCEs. O PCE principal é apoiado por um PCE de backup, e quando o PCE principal cai, o PCE de backup assume o papel do PCE principal e continua a ser o PCE principal, mesmo depois do PCE anteriormente o PCE principal voltar a funcionar.

    Uma PCE com estado fornece as seguintes funções:

    • Oferece computação de caminho LSP offline.

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

    • Muda a largura de banda do LSP quando há um aumento na demanda de largura de banda de uma aplicação.

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

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

    Embora uma PCE com estado permita a computação de caminho ideal e maior sucesso na computação de caminho, ela 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 TE LSPs.

  • PCE stateless — uma PCE stateless não lembra nenhum caminho computado, e cada conjunto de solicitações é processada independentemente uma da outra (RFC 5440).

Cliente de computação de caminho

Um PcC (Path Computation Client, Cliente de computação de caminho) é qualquer aplicativo cliente solicitando que uma computação de caminho seja executada 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 alcance. O PCC atribue a cada PCE conectado um número de prioridade. Ele envia uma mensagem a todos os PCEs conectados com informações sobre os LSPs atuais, em um processo chamado sincronização de estado LSP. Para as TE LSPs que têm controle externo ativado, o PCC delega esses LSPs ao PCE principal. O PCC elege, como o PCE principal, uma PCE com o número de menor prioridade ou a PCE à que se conecta primeiro na falta de um número de prioridade.

O PCC re-indica um LSP com base no caminho computação que ele recebe de um PCE. Quando a sessão pcep com o PCE principal é terminada, o PCC escolhe um novo PCE principal, e todos os LSPs delegados para o PCE principal anteriormente são delegarados ao PCE principal recém disponível.

Protocolo de elementos da computação de caminho

O Path Computation Element Protocol (PCEP) é usado para a 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 para solicitar e enviar caminhos para LSPs multioma TE in. As interações PCEP incluem mensagens PCC, bem como notificações de estados específicos relacionados ao uso de uma PCE no contexto de MPLS RSVP-TE. Quando o PCEP é usado para comunicação PCE-para-PCE, o PCE solicitante assume a função de um PCC.

Assim, as funções PCEP incluem:

  • Sincronização de estado do túnel LSP entre PCC e uma PCE com estado.

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

Interação entre uma PCE e um PCC que usa PCEP

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

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

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

Nota:

A partir da versão 16.1 do Junos OS, você pode proteger uma sessão PCEP usando autenticação TCP-MD5 de acordo com a RFC 5440. Para habilitar o mecanismo de segurança MD5 para uma sessão PCEP, recomenda-se definir e vincular a chave de autenticação MD5 no nível da hierarquia para uma sessão [edit protocols pcep pce pce-id] de PCEP. No entanto, você também pode usar um chaveiro predefinido do nível da hierarquia para [edit security authentication-key-chains key-chain] proteger uma sessão pcEP. Nesse caso, você deve vincular o chaveiro predefinido à sessão PCEP em nível [edit protocols pcep pce pce-id] de hierarquia.

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

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

Uma vez estabelecida a sessão PCEP, o PCC realiza 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 de LSP para o PCC que indicaram sua capacidade de dar suporte a LSPs iniciados por PCE.

    Nota:

    O suporte a LSPs iniciados por PCE é fornecido na Versão 13.3 do Junos OS e nas versões posteriores.

  2. delegação LSP — Depois que as informações de estado do LSP são sincronizadas, o PCC delega os LSPs externos para um PCE, que é o PRINCIPAL PCE com estado ativo. Somente 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 anulados pelos parâmetros definidos pelo PCE principal.

    Nota:

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

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

    Quando uma sessão PCEP termina, o PCC inicia dois temporizadores sem excluir imediatamente os LSPs iniciados por PCE e, para evitar delegation cleanup timeoutlsp cleanup timer interrupções dos serviços. Durante esse período, uma PCE com estado ativo pode adquirir o controle dos LSPs provisionados pelo PCE com falha, enviando uma solicitação de criação para o LSP.

    O controle sobre LSPs iniciados por PCE volta para o PCC no vencimento do delegation cleanup timeout . Quando o pce expira, e nenhum outro PCE adquiriu controle sobre o LSP do PCE com falha, o PCC toma o controle local do delegation cleanup timeout LSP não-delegado iniciado por PCE. Mais tarde, quando o PCE original ou um novo PCE ativo deseja adquirir o controle dos LSPs iniciados por PCE controlados localmente, o PCC delega esses LSPs ao PCE e o temporizador é lsp cleanup timer interrompido.

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

    Quando expirar, e nenhum outro PCE tiver adquirido controle sobre os LSPs do PCE com falha, o PCC elimina todos os LSPs provisionados pelo PCE com lsp cleanup timer falha.

    Nota:

    Em conformidade com o draft-ietf-pce-stateful-pce-09,a revocação de delegações LSP iniciadas por PCE por um PCC acontece de forma "make-before-break" antes que os LSPs sejam relegados para uma PCE alternativa. A partir da versão 18.1R1 Junos OS, é necessário ser maior ou igual ao PCC a fim de revogar as delegações lsp-cleanup-timerdelegation-cleanup-timeout de LSP. Caso não, o intervalo de tempo de redelegação para PCC pode ser definido como infinito, no qual as delegações de LSP para esse PCE permanecem intactas até que o PCC adote medidas específicas para alterar os parâmetros definidos pelo PCE.

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

    Quando o PCE especifica um caminho que está incompleta ou com hops soltos onde apenas os endpoints do caminho são especificados, o PCC não realiza o roteamento local baseado em restrições para descobrir o conjunto completo de hops. Em vez disso, o PCC fornece RSVP com o caminho fornecido pelo PCE, como é, para sinalização, e o caminho é definido usando IGP roteamento hop-by-hop.

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

A PCE tem uma visão global da demanda de largura de banda na rede e realiza cálculos de caminho externos depois de procurar o banco de dados de engenharia de tráfego. O PCE com estado ativo modifica um ou mais atributos de 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 de PCE para MPLS RSVP-TE Exemplo de PCE para MPLS RSVP-TE

Dessa forma, a PCE estatal fornece uma operação cooperativa da funcionalidade distribuída usada para atender a desafios específicos de uma computação de caminho entre domínios mais curto e restrito. Ele elimina cenários de congestionamento nos quais fluxos de tráfego são pouco aproveitados nos recursos disponíveis, causando sobreutilização de alguns subconjuntos de recursos de rede, enquanto outros recursos continuam subutilizados.

Comportamento de LSP com computação externa

Tipos de LSP

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

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

  • LSPs controlados por PCE — Os LSPs que configuram a declaração lsp-external-controller pccd são chamados LSPs controlados por PCE. O PCC delegará os LSPs iniciados por PCC ao PCE principal para a computação de caminho externo.

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

    O PCC envia relatórios de status de LSP para a PCE somente quando ocorre uma reconfiguração ou quando ocorre 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 de CLI de um LSP para pcE:

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

    • Parâmetros que são anulados por uma PCE. Esses parâmetros incluem largura de banda, caminho e prioridade (valores de configuração e espera). 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 externos (ou LSPs iniciados por PCE)— Os LSPs que configuram a instrução são chamados lsp-provisioning LSPs iniciados por PCE. Um LSP iniciado por PCE é criado dinamicamente por uma PCE externa; como resultado, não há configuração de LSP presente no PCC. O PCC cria o LSP iniciado por PCE usando os parâmetros fornecidos pela PCE e delegará automaticamente o LSP ao PCE.

    Nota:

    O suporte a LSPs iniciados por PCE é fornecido na Versão 13.3 do Junos OS e nas 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 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 os switches LSP do controle externo para o controle local, a computação de caminho é feita usando os parâmetros configurados por CLI e o roteamento baseado em restrições. Essa comover só acontece quando há um gatilho para re-sinalização do LSP. Até lá, o PCC usa os parâmetros fornecidos pelo PCE para sinalizar o LSP controlado por PCE, embora o LSP permaneça sob controle local.

Um LSP controlado por PCE comuta para controle local a partir de seu modo de controle externo padrão, em casos como sem conectividade com 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, consulte Tipos de LSP .

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

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

Tabela 1: Aplicabilidade das MPLS e das configurações de 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 MPLS de configuração aplicáveis

Essas declarações de configuração podem ser configuradas junto com a configuração PCE. Entretanto, eles só fazem efeito quando a configuração local está em uso. Durante o controle PCE, essas declarações de configuração continuam inativas.

  • grupo de administradores

  • largura de banda automática

  • hop-limit

  • menor preenchimento

  • mais preenchida

  • Aleatório

  • grupo de administradores

  • grupos de administrador

  • estendido em grupo de administrador

  • hop-limit

  • no-cspf

  • smart-optimize-timer

Essas declarações de configuração podem ser configuradas junto com a configuração PCE, mas são superadas pelos atributos LSP controlados por PCE. Entretanto, 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 que usam a CLI enquanto o LSP está sob o controle de uma PCE stateful não têm qualquer efeito sobre o LSP. Essas alterações só entrarão em vigor quando a configuração local for aplicada.

  • Banda

  • primário

  • Prioridade

  • Prioridade

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

  • p2mp

  • Modelo

  • p2mp-lsp-next-hop

O resto das declarações de configuração de LSP são aplicáveis da mesma maneira que 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 surtiram efeito.

Proteção LSP controlada por PCE

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

LSP ERO controlado por PCE

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

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

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

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

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

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

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

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

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

LSPs RSVP-TE PCE controlados por PCE

Depois que uma sessão pcep é estabelecida entre um PCE e um PCC, o PCC informa todos os LSPs do sistema ao PCE para sincronização de estado LSP. Isso inclui LSPs controlados por PCC, delegados por PCE e LSPs de ponto a ponto iniciados por PCE. A começar pelo Junos OS Release 15.1F6 e 16.1R1, essa capacidade é estendida para relatar LSPs ponto a multipoint também. Para uma PCE, o LSP ponto a multipoint é semelhante ao LSP de RSVP ponto a multipoint, onde o LSP ponto a multipoint é tratado como coleta de LSPs ponto a ponto agrupados sob um identificador ponto a multipoint.

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

Um PCC com a capacidade de TE ponto a multipoint é compatível com relatórios de LSPs ponto a multipoint para TE PCEs com estado, atualização de ponto a multipoint e banco de dados LSP compatível com nome LSP ponto a multipoint como chave. Entretanto, os seguintes recursos e funções não são suportados para o Junos OS Release 15.1F6 e 16.1:

  • LSPs estáticos ponto-a-multipoint

  • LSPs de ponto a multipoint iniciados por PCE e com delegação PCE

  • Largura de banda automática

  • TE++

  • Mensagem de resposta e solicitação de PCE

  • Criação de LSPs point-to-multipoint usando modelos

  • Configurando a entrada para a frente nos LSPs de ponto a multipoint iniciados por PCE

  • Configurando a entrada de encaminhamento no roteador que indica um LSP provisionado.

LSPs ponto a ponto iniciados por PCE

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

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

Um PCC indica sua capacidade de dar suporte a LSPs de ponto a ponto iniciados por PCE enquanto estabelece a sessão Path Computation Element Protocol (PCEP) com o PCE. Uma PCE escolhe um PCC com essa capacidade de iniciar um LSP. O PCE fornece ao PCC os parâmetros LSP iniciados por PCE. Ao receber os parâmetros LSP de ponto a ponto iniciados por PCE, o PCC configura o LSP, atribue uma ID de LSP e delegará o LSP automaticamente ao PCE.

Quando o PCE que inicia o LSP não fornece os parâmetros LSP iniciados por PCE, ponto a ponto, o PCC usa os parâmetros padrão. Um modelo LSP opcional também pode ser configurado para especificar valores do LSP de ponto a ponto iniciado pela PCE quando os parâmetros LSP não são fornecidos pelo PCE. Para configurar um modelo de LSP para LSPs de ponto a ponto iniciados por PCE no PCC, inclua a instrução label-switched-path-template no nível [edit protocols mpls lsp-external-controller lsp-external-controller] da hierarquia.

Quando uma sessão PCEP termina, o PCC inicia dois temporizadores sem excluir imediatamente osLSPs iniciados por PCE e, para evitar interrupções delegation cleanup timeoutlsp cleanup timer dos serviços. Durante esse tempo, uma PCE com estado ativo pode adquirir o controle dos LSPs provisionados pelo PCE com falha.

Uma 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 dos LSPs iniciados por PCE reversão ao PCC no fim do tempo de limpeza da delegação. Quando o tempo de limpeza da delegação expirar, e nenhum outro PCE tiver adquirido controle sobre o LSP do PCE com falha, o PCC assume o controle local do LSP não-delegado iniciado por PCE. Mais tarde, quando o PCE original ou um novo PCE ativo deseja adquirir o controle dos LSPs locaismente controlados, iniciados ponto a ponto, o PCC delega esses LSPs ao PCE e o temporizador de limpeza LSP é interrompido.

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

A partir da versão 21.1R1 do Junos OS, temos suporte para NSR (Nonstop Active Routing, roteamento ativo sem escalas) para LSPs RSPs baseados em RSVP e com base em PCE, ponto a ponto e ponto a multipoint. Somente a Mecanismo de Roteamento principal mantém a sessão 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 a Mecanismo de Roteamento. Durante uma comover, a sessão PCEP é reencontrada quando a Mecanismo de Roteamento de backup se torna a Mecanismo de Roteamento. Isso reduz a perda de tráfego do tráfego realizado por LSPs RSVP iniciados por PCE durante Mecanismo de Roteamento comovers. Esse recurso é ativado quando o NSR está configurado.

Bypass LSP iniciado por PCE

Compreender LSPs de bypass iniciados por PCE

Pode haver paralisações de tráfego no momento de uma falha no enlace ou no nó, porque os caminhos de proteção de backup na rede não têm largura de banda suficiente para tratar o tráfego. Nesses redes, embora um PCE possa ser usado para computar todos os caminhos, para otimizar o desempenho da rede, os caminhos de proteção locais também precisam ser controlados por meio do PCE.

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

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

O conjunto de operações usadas para realizar em qualquer LSPs de bypass operacional, como, também pode ser realizado nos LSPs de bypass iniciados por clear rsvp session PCE. Você pode usar comandos, como e para exibir estatísticas de LSP de bypass iniciadas show path-computation-client status extensiveshow path-computation-client lsp por PCE.

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

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

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

    • deve ter uma largura de banda sem zero.

    • deve ter um ERO rígido especificado.

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

  • Sobrescreve a largura de banda de bypass LSP para controlar a admissão de LSPs principais. Esse deve ser um parâmetro por bypass, e deve permitir a atualização da assinatura por LSP de bypass.

Benefícios do BYPASS LSP iniciado por PCE

Os LSPs de bypass iniciados por PCE fornecem os seguintes benefícios:

  • Controle melhor do tráfego após uma falha e computação mais determinista dos caminhos de proteção.

  • Atender a requisitos complexos de restrições e diversidade, como manter diversos caminhos para LSPs e seus caminhos de proteção locais.

  • Garanta que os links não sejam sobrecarregados durante eventos de falha.

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

No momento em que um PCEP falha na sessão, os LSPs de bypass iniciados por PCE tornam-se órfãos até o expirar o tempo de expiração do tempo de expiração. Os LSPs de bypass iniciados por PCE são limpos após o vencimento do temporizador de tempo de expiração do estado. Para obter controle de um LSP de bypass iniciado por PCE (após a sessão pcep falhar), uma PCE (a PCE primária ou qualquer PCE secundário) envia uma mensagem PCInitiate antes do expirar o tempo de expiração do tempo de expiração do estado.

LSPs point-to-multipoint iniciados por PCE

Com a introdução de LSPs iniciados por PCE point-to-multipoint, um PCE pode iniciar e provisionar um LSP point-to-multipoint 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 caminho ponto a multipoint dentro e em sessões do Path Computation Element Protocol (PCEP), criando assim uma rede dinâmica que é centralmente controlada e implantada.

Para obter mais informações, consulte Understanding Path Computation Element Protocol para MPLS RSVP-TE com suporte para LSPs point-to-multipoint iniciados por PCE.

Largura de banda automática e LSP controlado por PCE

A partir da versão 14.2R4 Junos OS, o suporte à largura de banda automática é fornecido para LSPs controlados por PCE. Nas versões anteriores, a opção de largura de banda automática não se aplicava a LSPs controlados por PCE, embora os LSPs sob o controle do auto-bandwdith e do roteamento baseado em restrições pudessem coexistir com LSPs controlados por PCE. A coleta de estatísticas para largura de banda automática só surtiu efeito quando o modo de controle de um LSP controlado por PCE muda de externo para local. Isso acontecia em casos como sem conectividade com uma 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 com estado automatiza a criação de caminhos de engenharia de tráfego na 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 de LSP para um servidor PCE, e os LSPs do PCE são atualizados ou provisionam LSPs de volta ao PCC. Os dados enviados por uma sessão PCEP são essenciais para que um servidor PCE realize a computação de caminho externo. Como resultado, um ataque à comunicação PCEP pode interromper os serviços de rede. Se mensagens PCEP alteradas são enviadas a um PCC, LSPs não apropriados podem ser configuradas. Da mesma forma, se mensagens PCEP alteradas são enviadas para uma PCE, uma visualização incorreta da rede é aprendida pelo PCE.

Considerando a importância da comunicação do PCEP entre pcE e PCC na execução eficaz das funcionalidades PCE, o Junos OS Release 16.1 introduz o recurso de proteger uma sessão PCEP usando a autenticação TCP-MD5 de acordo com a RFC 5440. Esse recurso protege a comunicação entre PCE e PCC em uma sessão 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 PCEP, recomenda-se definir e vincular a chave de autenticação MD5 no nível da hierarquia para uma sessão [edit protocols pcep pce pce-id] de PCEP. No entanto, você também pode usar um chaveiro predefinido do nível da hierarquia para [edit security authentication-key-chains key-chain] proteger uma sessão pcEP. Nesse caso, você deve vincular o chaveiro predefinido à sessão PCEP em nível [edit protocols pcep pce pce-id] de hierarquia.

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

  • Usando a chave de autenticação MD5:

  • Usando o 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 PCEP.

Nota:
  • A Versão 16.1 do Junos OS tem suporte apenas para autenticação TCP-MD5 para sessões PCEP, sem estender o suporte a TLS e TCP-AO, como proteção contra escutas, manipulação e falsificação de mensagens.

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

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

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

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

  • Use o comando para exibir o número de pacotes que são largados show system statistics tcp | match auth pelo TCP por causa de erros de autenticação.

  • A operação do chaveiro pode ser verificada usando-se 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 com estado pode ser não trivial. Em um ambiente PCE centralizado único, uma PCE com estado simplesmente precisa lembrar todos os LSPs de TE que o PCE computou, os LSPs de TE que foram realmente definidos (se isso puder ser conhecido) e quando os LSPs TE foram derrubados. Entretanto, esses requisitos podem causar sobrecarga substancial no protocolo de controle em termos de estado, uso e processamento da rede e otimização de links em toda a rede. Assim, as preocupações de uma implementação de PCE com estado incluem:

  • Qualquer mecanismo de sincronização confiável resulta em sobrecarga significativa do plano de controle. As PCEs podem sincronizar o estado comunicando-se entre si, mas quando TE LSPs são configuradas usando a computação distribuída executada entre vários PCEs, os problemas de sincronização e evitação das condições de corrida tornam-se maiores e mais complexos.

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

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

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

Exemplo: Configurando o protocolo de elemento de computação de caminho para MPLS RSVP-TE

Este exemplo mostra como habilitar a computação de caminho externo por um PcE (Path Computation Element) para caminhos comutado por rótulos (TE LSPs) em um cliente de computação de caminho (PCC). Ele também mostra como configurar o Path Computation Element Protocol (PCEP) no PCC para permitir a comunicação PCE a PCC.

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, roteadores de borda multisserviço Série M, 5G da Série MX Plataformas de roteamento universal, roteadores de núcleo Série T ou Roteador de transporte da série PTX, um deles configurado como um PCC.

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

  • Junos OS Release 12.3 ou posteriormente executado no PCC junto com o pacote add-on JSDN.

Nota:

O pacote add-on JSDN precisa ser instalado junto com o pacote de instalação do Junos OS de núcleo.

Antes de começar:

  1. Configure as interfaces de dispositivo.

  2. Configure MPLS e RSVP-TE.

  3. Configure IS-IS ou qualquer outro protocolo IGP de segurança.

Visão geral

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

Nota:

A implementação parcial do lado do cliente da arquitetura PCE stateful é baseada na versão 2 do draft da Internet-ietf-pce-stateful-pce. A partir da versão 16.1 do Junos OS, essa implementação é atualizada para dar suporte à versão 7, conforme definido no draft da Internet-ietf-pce-stateful-pce-07. As versões anteriores a 16.1 são de suporte para a versão mais antiga do draft pcE, causando problemas de interoperabilidade entre um PCC que executa uma versão anterior e um servidor PCE com estado que adere ao draft da Internet-ietf-pce-stateful-pce-07.

Para habilitar a computação de caminho externo por um PCE, inclua a lsp-external-controller instrução no PCC nos níveis [edit mpls] e na [edit mpls lsp lsp-name] hierarquia.

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

Para permitir a comunicação PCE a PCC, configure o PCEP no PCC em [edit protocols] nível de hierarquia.

Ao configurar o PCEP em um PCC, saiba das seguintes considerações:

  • O pacote add-on JSDN precisa ser instalado junto com o pacote de instalação do Junos OS de núcleo.

  • A versão 12.3 do Junos OS tem suporte apenas para PCEs stateful.

  • Um PCC pode se conectar a no máximo 10 PCEs estatais. Em qualquer ponto do tempo, só pode haver uma PCE principal (a PCE com o menor valor de prioridade, ou a PCE que se conecta ao PCC primeiro na falta de uma prioridade PCE) à qual o PCC delega LSPs para a computação de caminho.

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

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

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

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

  • LSPs controlados por PCE não são suportados por GRES.

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

  • LSPs controlados por PCE não podem ser LSPs point-to-multipoint.

  • LSPs bidirecionais não são suportados.

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

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

  • O tempo de configuração e o tempo de convergência (reroute, MBB) para exilar LSPs é o mesmo das versões anteriores, na falta de LSPs controlados por PCE. Entretanto, 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 de PCEP para MPLS RSVP-TEConfiguração de 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 configurada usando a CLI. Assumindo que a configuração recebida esteja habilitada com computação de caminho externo, o Roteador PCC torna-se consciente de que alguns dos atributos LSP – largura de banda, caminho e prioridade – estão sob o controle do PCE stateful e delegam o LSP ao PCE.

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

  2. O Roteador PCC tenta recuperar os atributos LSP controlados por PCE. Para isso, o Roteador PCC envia uma mensagem PCRpt ao PCE stateful informando 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 delegadas e envia os novos parâmetros LSP para o Roteador PCC pela mensagem PCUpd.

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

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

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

Configuração

Configuração rápida CLI

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

Pcc

R0

R1

R2

R3

Procedimento

Procedimento passo a passo

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

Para configurar o roteador PCC:

Nota:

Repetir esse procedimento para todos os Juniper Networks de entrada no MPLS, depois de modificar os nomes, endereços e quaisquer outros parâmetros de interface apropriados para cada roteador.

  1. Configure as interfaces.

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

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

  3. Configure o caminho comutado por rótulos (LSP) do roteador PCC para o roteador R2 e possibilite 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. Ative MPLS em todas as interfaces do Roteador PCC, exceto a interface de gerenciamento.

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

  7. Defina o PCE com que 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 uma 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 show interfaces os comandos e os show protocols comandos. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

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

Verificação do status da sessão PCEP

Propósito

Verificar o status da sessão PCEP entre o PCE e o Roteador PCC quando o status PCE estiver ativo.

Ação

Do modo operacional, execute o show path-computation-client active-pce comando.

Significado

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

Para, o status da sessão PCEP é , o que indica que a sessão PCEP foi pce1 estabelecida entre os colegas PCE_STATE_UP pcep.

As estatísticas indicam o número de mensagens enviadas pelo Roteador PCC ao PCE para PCRpts 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 de PCE para LSPs controlados por PCE.

Verificar o status de LSP controlado por PCE quando o controle LSP for externo

Propósito

Verificar o status do LSP controlado por PCE do Roteador PCC ao Roteador R2 quando o LSP estiver sob controle externo.

Ação

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

Significado

Na saída, os campos LSPtype e a saída mostram que o LSP Control Status 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 PCEP entre o PCE e o roteador PCC está ativo, e o Roteador PCC recebe os seguintes parâmetros LSP controlados por PCE:

  • ERO (caminho)— 20.31.4.2 e 20.31.5.2

  • Bandwidth—8Mbps

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

Verificar o status de LSP controlado por PCE quando o controle LSP estiver local

Propósito

Verificar o status do LSP controlado por PCE do Roteador PCC ao Roteador R2 quando o controle LSP se tornar local.

Ação

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

Significado

Na saída, o campo LSP Control Status 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 configurados usando a CLI junto com os parâmetros fornecidos por PCE usados para estabelecer o LSP como os valores reais de uso.

  • Largura de banda — 10 Mbps (ActualBandwidth: 8 Mbps)

  • Prioridades — 4 4 (Valores reais 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.

O Computed ERO é de 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: Configurando o protocolo de elemento de computação de caminho para MPLS RSVP-TE com suporte a LSPs point-to-point iniciados por PCE

Este exemplo mostra como configurar o PcC (Path Computation Client, Cliente de computação de caminho) com a capacidade de oferecer suporte aos caminhos de computação de caminho (PCE) iniciados por tráfego e comutada por rótulos ponto a ponto (LSPs).

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

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

  • Uma conexão TCP a duas PCEs com estado externo do roteador de entrada (PCC).

  • Junos OS Release 16.1 ou posteriormente executado no PCC.

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure MPLS e RSVP-TE (RSVP-Engenharia de tráfego).

  • Configure OSPF ou qualquer outro protocolo IGP de segurança.

Visão geral

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

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

  • A versão 13.3 do Junos OS tem suporte apenas para PCEs stateful.

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

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

  • Os LSPs iniciados por PCE não são suportados por Mecanismo de Roteamento com switchover (GRES).

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

  • LSPs iniciados por PCE não podem ser LSPs point-to-multipoint.

  • LSPs bidirecionais não são suportados.

  • O RSVP-TE para links sem número não é suportado. Os LSPs iniciados por PCE têm suporte para apenas links numerados.

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

    A partir da versão 18.2R1 Junos OS, LSPs de roteamento por segmentos não-coloridos configurados estaticamente no dispositivo de ingresso são reportados a um PCE por meio de uma sessão PCEP. Esses LSPs de roteamento por segmentos não coloridos podem ter rótulos SID vinculantes associados a eles. Com esse recurso, a PCE pode usar esse rótulo SID obrigatório na pilha de rótulos para provisionar caminhos LSP de roteamento por segmentos iniciados por PCE.

Topologia

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

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

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

  1. Uma 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 da PCE e delegará automaticamente o LSP iniciado por PCE ao PCE que o inicia.

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

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

  3. Caso o PCE2 tenha controle sobre o LSP iniciado por PCE antes do vencimento do temporizador de limpeza LSP, o PCC delegará o LSP iniciado por PCE ao PCE2, e o temporizador de limpeza LSP e o tempo de limpeza da delegação serão interrompidos.

  4. Se o tempo de limpeza da delegação expirar, e nem PCE1 nem PCE2 adquiriram controle sobre o LSP iniciado por PCE, o PCC assumirá o controle local do LSP não-delegado iniciado por PCE até o vencimento do temporizador de limpeza LSP.

  5. Após o vencimento do temporizador de limpeza LSP, o PCC elimina o LSP iniciado por PCE provisionado pelo PCE1.

Configuração

Configuração rápida CLI

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

Pcc

R1

R2

Procedimento

Procedimento passo a passo

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

Para configurar o roteador PCC:

Nota:

Repetir esse procedimento para todos os Juniper Networks de entrada no MPLS, depois de modificar os nomes, endereços e quaisquer outros parâmetros de interface apropriados para cada roteador.

  1. Configure as interfaces.

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

  2. Ative o RSVP em todas as interfaces do PCC, exceto na interface de gerenciamento.

  3. Ative o controle externo de LSPs pelos PCEs.

  4. Habilita MPLS todas as interfaces do PCC, exceto a interface de gerenciamento.

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

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

  7. Defina os PCEs que se conectam ao PCC.

Resultados

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

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

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

Verificação do status do PCC

Propósito

Verificar o status da sessão pcep e o resumo de LSP entre o PCC e as PCEs conectadas.

Ação

Do modo operacional, execute o show path-computation-client status comando.

Significado

A saída exibe o status da sessão PCEP entre as PCEs com estado ativo 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 delegadas a eles.

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

Verificação do status do PCE1

Propósito

Verificar o status da PCE principal com estado ativo.

Ação

Do modo operacional, execute o show path-computation-client active-pce detail comando.

Significado

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

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

Verificar o status de LSP iniciado por PCE quando o LSP for provisionado externamente

Propósito

Verificar o status do LSP iniciado por PCE.

Ação

Do modo operacional, execute o show mpls lsp externally-provisioned detail comando.

Significado

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

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

  • ERO (caminho)— 10.0.102.10 e 10.0.101.9

  • Largura de banda — 8 Mbps

  • Prioridade — 70 (valores de configuração e espera)

Configurando o protocolo de elemento de computação de caminho para MPLS RSVP-TE com suporte a LSPs point-to-point iniciados por PCE

Você pode configurar um Cliente de Computação de Caminho (PCC) com a capacidade de dar suporte a caminhos comutado de rótulos (LSPs) criados dinamicamente a partir de uma entidade de computação de caminhos externos centralizada. Um elemento PCE (Path Computaiton Element) com estado pode ser usado para realizar computação de caminho externo e gerar LSPs dinâmicos quando houver um aumento na demanda.

Um PCC cria o LSP ponto a ponto iniciado pelo PCE usando os parâmetros LSP fornecidos por PCE ou parâmetros de um modelo LSP pré-configurado quando a PCE não provisiona o LSP e delega automaticamente o LSP de ponto a ponto iniciado pela PCE para o pce respectivo. 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 um LSP iniciado por PCE podem coexistir entre si em um PCC.

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure MPLS e RSVP-TE.

  • Configure OSPF ou qualquer outro protocolo IGP de segurança.

Para configurar o PCC para dar suporte a LSPs de ponto a ponto iniciados pelo PCE, complete 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 comuados de rótulos provisionados externamente (LSPs) em todos os PCEs conectados que o PCC pode aceitar no máximo.
  4. Especifique a ID definida pelo usuário exclusivo para o PCE conectado para configurar os parâmetros PCE.
  5. Especifique a quantidade de tempo (em segundos) que o PCC deve esperar antes de retornar o controle de LSPs ao processo de protocolo de roteamento depois que uma sessão PCEP for 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 qualquer LSPs não-deletado iniciado por PCE do PCE com falha após o fim de uma sessão do PCEP.
  9. Configure o PCC para aceitar SPs que sejam 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 sessão pcep ser fechada.

    O valor pode variar de 1 a 16384, e o valor padrão é 0 (inválido 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 terminação da sessão PCEP.

    O valor pode variar de 0 a 16384, e o valor padrão é 5. Um valor de 0 desativa essa 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 reender uma solicitação.

    O valor pode variar de 0 a 65535 segundos.

  14. Verificar e confirmar a configuração.

Saída de amostra

Exemplo: Configurando o protocolo de elemento de computação de caminho para MPLS RSVP-TE com suporte para LSPs de ponto para multipoint controlados por PCE

Este exemplo mostra como configurar o Cliente de Computação de Caminho (PCC) com a capacidade de relatar caminhos comutado de rótulo (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 ACX, Série M, Série MX ou Série T roteadores.

  • Uma máquina virtual configurada com o recurso VrR (Virtual Route Reflector, Refletor de rotas virtuais).

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

  • Junos OS Release 16.1 ou posteriormente executado no PCC.

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure MPLS e RSVP-TE.

  • Configure OSPF ou qualquer outro protocolo IGP de segurança.

Visão geral

Depois que uma sessão pcep é estabelecida entre um PCE e um PCC, o PCC informa todos os LSPs do sistema ao PCE para sincronização de estado LSP. Isso inclui LSPs controlados por PCC, delegados por PCE e LSPs de ponto a ponto iniciados por PCE. A começar pelo Junos OS Release 15.1F6 e 16.1R1, essa capacidade é estendida para relatar LSPs ponto a multipoint também.

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

Topologia

Figura 7: Por exemplo LSPs de ponto para multipoint controlados por PCEPor exemplo LSPs de ponto para multipoint 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 ponto a multipoint entre PCC, Roteador R1 e Roteador R2.

O relatório de LSPs point-to-multipoint é executado da seguinte forma:

  1. Se o Roteador PCC estiver configurado com LSPs ponto a ponto e ponto-a-multipoint sem o suporte para recursos de relatórios ponto a multipoint, somente os LSPs ponto a ponto são reportados ao PCE conectado. Por padrão, um PCC não aceita recursos de emissão de relatórios LSP ponto a multipoint.

  2. Quando o Roteador PCC está configurado com o recurso de relatórios LSP point-to-multipoint, o PCC anuncia inicialmente essa capacidade ao PCE por meio de uma mensagem de relatório.

  3. Por padrão, um PCE fornece suporte para a capacidade de LSP point-to-multipoint. Ao receber o anúncio do PCC sobre a capacidade de LSP point-to-multipoint, o PCE, em troca, anuncia sua capacidade ao PCC.

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

  5. Depois que todos os LSPs são reportados ao PCE, o estado LSP é sincronizado entre o PCE e o PCC.

Configuração

Configuração rápida CLI

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

Pcc

R1

R2

R3

Procedimento

Procedimento passo a passo

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

Para configurar o roteador PCC:

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

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

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

  4. Ative MPLS em todas as interfaces do Roteador PCC, exceto a interface de gerenciamento.

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

  6. Configure LSPs point-to-multipoint e defina entidade de computação de caminho externo para o LSP.

  7. Ative a computação de caminho externo para MPLS LSPs 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 MPLS de grupo administrativo para computação LSP de caminho restrito.

  10. Atribua as políticas de grupo administrativo configuradas às interfaces pcC do roteador.

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

  12. Configure um BGP interno.

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

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

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

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

  17. Defina o PCE com que o Roteador PCC se conecta e configure os parâmetros PCE.

  18. Configure o Roteador PCC para habilitar a capacidade de LSP ponto a multipoint para computação de caminho externo.

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

Resultados

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

Verificação

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

Verificação da configuração de LSP no PCC

Propósito

Verificar o tipo de LSP e o estado em execução do LSP point-to-multipoint.

Ação

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.

Verificação da configuração de PCE no PCC

Propósito

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

Ação

Do modo operacional, execute o show path-computation-client active-pce comando.

Significado

A saída exibe o PCE ativo a que o Roteador PCC está conectado, e os parâmetros e estado pce1 PCE.

Entender o protocolo de elemento de computação de caminho para MPLS RSVP-TE com suporte para LSPs de ponto para multipoint iniciados por PCE

Com a introdução de LSPs iniciados por PCE point-to-multipoint, um PCE pode iniciar e provisionar um LSP point-to-multipoint 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 caminho ponto a multipoint dentro e em sessões do Path Computation Element Protocol (PCEP), criando assim uma rede dinâmica que é centralmente controlada e implantada.

Benefícios dos LSPs point-to-multipoint iniciados por PCE

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

Sinalização de LSPs point-to-multipoint iniciados por PCE

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

  • When a new branch is added (Grafting)— Somente o novo sub-LSP de filial está sinalização e não resulta na re sinalização de toda a árvore ponto-a-multipoint.

    Caso ocorreram alterações de topologia antes do provisionamento do novo sub-LSP, o Servidor de computação de caminho (PCS) re computa toda a árvore ponto-a-multipoint e atualiza o LSP ponto a multipoint usando uma mensagem de atualização do PC.

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

  • When a branch sub-LSP parameter is changed— Alterações nos parâmetros sub-LSP, como ERO (Explicit Route Object), largura de banda ou prioridade, podem ocorrer por causa da otimização ou da solicitação do usuário. Se houver uma solicitação de re sinalização para um sub-LSP, toda a árvore ponto-a-multipoint é reencontrada e, em seguida, a comutar para a nova instância acontece quando as novas instâncias de todas as filiais estão ativas.

  • When a branch sub-LSP path fails— Um erro é reportado ao PCS para o sub-LSP da filial com falha. Ao receber o novo ERO do PCS, toda a árvore ponto-a-multipoint é reenviada junto com o sub-LSP da filial que falhou, e a comutagem para a nova instância acontece de forma make-before-break (MBB).

Comportamento dos LSPs point-to-multipoint iniciados por PCE após falha na sessão PCEP

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

Para obter controle de um LSP ponto a multipoint iniciado por PCE após uma falha na sessão PCEP, o PCE principal ou secundário envia uma mensagem antes do PCInitiatestate timeout tempo expirar.

Configurando a capacidade de LSP ponto-a-multipoint iniciada por PCE

Por padrão, a criação e o provisionamento de LSPs point-to-multipoint por um PCE não são suportados em um PCC. Para habilitar esse recurso, inclua as p2mp-lsp-init-capability e declarações nos níveis ou na p2mp-lsp-update-capability[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 LSVP-TE ponto a multipoint por um PCE. A p2mp-lsp-update-capability declaração fornece a capacidade de atualizar parâmetros de RSVP-TE LSP point-to-multipoint por um PCE.

Recursos suportados e não suportados para LSPs point-to-multipoint iniciados por PCE

Os seguintes recursos são suportados por LSPs de ponto a ponto iniciados por PCE:

  • Conformidade parcial com a proposta de Internet draft-ietf-pce-stateful-pce-p2mp (expira em outubro de 2018), Extensões de protocolo Path Computation Element (PCE) para uso stateful pcE para caminhos com rótulos de engenharia de tráfego point-to-multipoint.

  • A partir da versão 21.1R1 do Junos OS, temos suporte para NSR (Nonstop Active Routing, roteamento ativo sem parar) para LSPs RSPs baseados em RSVP com base em PCE. Somente a Mecanismo de Roteamento principal mantém a sessão 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 a Mecanismo de Roteamento. Durante uma comover, a sessão PCEP é reencontrada quando a Mecanismo de Roteamento de backup se torna a Mecanismo de Roteamento. Isso reduz a perda de tráfego do tráfego realizado por LSPs RSVP iniciados por PCE durante Mecanismo de Roteamento comovers. Esse recurso é ativado quando o NSR está configurado.

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

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

  • Delegação de controle do LSP.

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

  • Mensagens de solicitação/resposta.

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

    O mesmo pode ser obtido com a exclusão de um sub-LSP de filial da primeira árvore ponto-a-multipoint e reatingá-la a outra depois que a mensagem indicar a remoção do LSP do PCReport dispositivo.

  • O IPv6 não é suportado.

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

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

  • A proteção do enlace não é suportada.

Mapeamento de LSPs point-to-Multipoint iniciados por PCE para MVPN

Você pode associar uma única ou uma variedade de fluxos de multicast MVPN (S,G) a um caminho comutado de rótulo (LSP) iniciado por PCE com início dinâmico de PCE. Você pode especificar apenas tipos de fluxos seletivos para que esse recurso funcione. Isso inclui:

  • Diferencial de roteamento (RD), mapeado para a instância de roteamento MVPN.

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

  • LSP ponto a multipoint usado para enviar tráfego que corresponde à especificação de fluxo acima mencionado.

Para obter mais detalhes, consulte o draft 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 da proposta:

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

  • Seção 3.2 — mensagem PCReq e PCRep

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

Para habilitar o mapeamento de LSPs de ponto a multipoint iniciados por PCE para MVPN:

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

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

    A presença na configuração de túnel de provedor para MVPN indica que o external-controller LSP ponto-a-multipoint e (S,G) para esta instância de MVPN podem ser fornecidos pelo controlador externo. Com isso, o controlador externo pode configurar dinamicamente (S,G) e LSP ponto a multipoint para MVPN.

Leve em consideração o mapeamento de LSPs point-to-multipoint iniciados por PCE para MVPN:

  • Caso você não ative a instrução para uma instância de MVPN específica, o processo external-controller pccd PCCD não configura (S,G) dinamicamente.

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

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

  • Se algum (S,G) específico for aprendido com o controlador externo dinamicamente e você configurar a mesma (S,G) para a mesma instância de MVPN, o aprender dinamicamente (S,G) será excluído e comunicado ao controlador externo por meio do PCC.

  • Se o processo de protocolo de roteamento for reinicializado, o processo PCCD reconfigura todo o (S,G) novamente.

  • Se o processo PCCD for reinicializado, o MVPN informa todo o PCCD configurado (S,G) ao controlador externo.

  • Se o usuário habilita para uma instância de MVPN em especial, o MVPN solicita que o external-controller pccd processo PCCD configure (S,G), se estiver presente.

  • Se houver alterações de configuração importantes em uma instância MPVN específica, a MVPN solicita que o processo PCCD reconfigure tudo (S,G) para essa instância de MVPN específica.

  • Todas as especificações de fluxo associadas a qualquer LSP ponto a multipoint iniciado por PCE devem ter o mesmo RD. Durante o início do PC, se todas as especificações de fluxo não tiver o mesmo RD, a mensagem de início do PC é lançada com um erro.

  • Você pode associar um LSP ponto a multipoint apenas com especificações de tipo de fluxo seletivas, caso contrário, a mensagem de início do PC é lançada com um erro.

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

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

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

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

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

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

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

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

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

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

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

    • Relatórios de LSP ponto a multipoint configurado por CLI mapeados para fluxos de multicast MVPN (S,G).

Habilitar o roteamento por segmentos para o protocolo de elemento de computação de caminho

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

Roteamento por segmentos para a visão geral do protocolo do elemento de computação de caminho

Benefícios do roteamento por segmentos para PCEP

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

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

  • Um Cliente de computação de caminho (PCC, que é um roteador da Série MX de ingresso) com capacidade de delegação pode reassucar o controle dos LSPs de roteamento por segmentos delegados do PCE quando a sessão do PCEP for final; os LSPs seriam excluídos do PCC. Assim, você pode garantir a proteção de dados LSP com a reversão de uma situação em que os pacotes sejam descartados ou lançados de forma silenciosa (também conhecida 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 ter suporte para multicamados de custo igual (ECMP). Com IGP extensões integradas a ela, o roteamento por segmentos se integra aos ricos recursos multisserviços da MPLS, incluindo VPN de Camada 3, Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS) e Ethernet VPN (EVPN).

Alguns dos componentes de alto nível da solução de roteamento por segmentos (SR TE) incluem:

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

  • Uso do CSPF (Shortest Path First, caminho mais curto restrito) no dispositivo de ingresso ou no PCE.

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

    Na funcionalidade SR-TE:

    1. O dispositivo de ingresso constrói um LSP empilhando os rótulos dos links que deseja atravessar.

    2. O anúncio de IGP por enlace é combinado à pilha de rótulos para criar LSPs roteados por origem no dispositivo de entrada, de forma que os dispositivos de trânsito não estão conscientes dos LSPs de ponta a ponta.

    3. LSPs são criadas entre nós de borda sem colocar quaisquer requisitos de memória por LSP nos dispositivos de trânsito. (A criação desses LSPs está habilitada porque não há sinalização por LSP no SR-TE.)

    4. Rótulos por vizinho são empilhados, o que resulta no gerenciamento de um grande número de rótulos, o que leva 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 aqueles LSPs que a PCE cria para os segmentos de adjacência e nós

A PCE executa as seguintes funções:

  1. Calcula o caminho do LSP do roteamento por segmentos.

  2. Provisiona o LSP no PcC (Path Computation Client, Cliente de computação de caminhos) usando extensões de roteamento por segmentos PCEP.

  3. Avalia as extensões de roteamento por segmentos 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 tráfego e serviços IP, como qualquer outra rota de túnel.

O PCC realiza as seguintes funções:

  1. Escolhe a interface de saída com base no primeiro identificador de acesso à rede (NAI) no objecto de roteação explícito de origem (S-ERO).

    O Junos OS tem suporte para S-EROs que contêm o primeiro hop como um salto rígido; O Junos OS não aceita a seleção da interface de saída no PCC com base em uma ID (Node Segment ID, ID) de nó de salto livre (SID). No entanto, os hops restantes podem ser soltos. Nenhum processamento específico é feito para os S-EROs que vão além do primeiro hop, além de simplesmente usar o rótulo para criação de next-hop.

  2. Recusa o S-ERO se:

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

    • O S-ERO transporta mais de seis hops.

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

  3. Espera que o PCE processe qualquer evento que leve a uma mudança no LSP do roteamento por segmentos depois de provisionado, por exemplo, se o rótulo for alterado ou retirado ou se uma das interfaces atravessadas pelo LSP for baixa.

Quando a sessão PCEP vai para baixo, o LSP de roteamento por segmentos iniciado por PCE:

  1. Permanece por 300 segundos.

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

Para obter mais detalhes, consulte as rascunhos da Internet draft-ietf-pce-lsp-setup-type-03.txt (expira em 25 de dezembro de 2015), Transmitir o tipo de configuração do caminho nas 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 aqueles LSPs que o PCC configura localmente e, em seguida, delegam a um controlador PCE.

Nota:

A versão do Junos OS 20.1R1 aceita:

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

  • Delegação e relatórios apenas do primeiro segmento de uma lista de segmentos para um controlador externo. Vários segmentos não são suportados para a delegação de 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 não estão 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 depois que o caminho do roteamento de origem está configurado. Ou seja, a capacidade de delegação está habilitada para LSPs de roteamento por segmentos existentes.

Depois de delegar um LSP de roteamento por segmentos, o PCE controla os LSPs delegados e pode modificar os atributos LSP para computação de caminho. O controle LSP volta para o PCC quando a sessão PCEP entre o PCC e o PCE acontece. Os LSPs delegados por PCE têm uma vantagem sobre LSPs iniciados por PCE caso a sessão do PCEP seja final. No caso dos LSPs iniciados por PCE, quando a sessão PCEP está inovada, os LSPs são excluídos do PCC. No entanto, no caso dos LSPs delegados por PCE, quando a sessão do PCEP for final, o PCC reassuma o controle dos LSPs delegados da PCE. Como resultado, com os LSPs delegados por PCE, evitamos uma situação em que os pacotes são descartados de forma silenciosa (também conhecida como uma condição de rota nula) quando a sessão for realizada.

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

  • Static LSPs— Caminhos de roteamento de origem configurados estaticamente que têm toda a pilha de rótulos configurada estaticamente.

  • Auto-translated LSPs— Caminhos de roteamento de origem configurados estáticamente que são traduzidos automaticamente.

  • Computed LSPs— Caminhos de roteamento de origem configurados estaticamente que são computados com O caminho mais curto (CSPF) distribuído.

  • Dynamic LSPs— Túneis criados dinamicamente acionados pelo Módulo de Túnel Dinâmico que têm resolução ERO de última elevação.

Dependendo da origem do LSP do 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 na [edit protocols source-packet-routing] hierarquia.

Tabela 2 mostra um mapeamento da origem LSP até o nível de hierarquia de configuração correspondente no qual a capacidade de delegação está ativada.

Nota:

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

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

Origem do roteamento por segmentos LSP

Hierarquia de configuração

  • LSPs traduzidos automaticamente

  • LSPs estáticos

Lista de segmentos principais em [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSPs computados (CSPF distribuído)

Lista de segmentos principais do caminho do 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 de segmentos principais do modelo de caminho do 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 TE SR a partir da saída do comando show spring-traffic-engineering.

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

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

Hierarquia de configuração do controlador externo-lsp

Estado de delegação de caminho de roteamento de origem

Interação pcep entre PCC e PCE

Lista primária de segmentos do caminho do roteamento de origem

Delegação inicial

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

  2. A PCE calcula o caminho para LSP e o caminho dos relatórios para o estado de baixo.

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

O mesmo comportamento é visto quando o processo de protocolo de roteamento (rpd) é reinicializado ou ocorre uma Mecanismo de Roteamento switchover.

Lista primária de segmentos do caminho do roteamento de origem

Delegação do caminho existente

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

  2. Um segmento principal correspondente é delegar ao PCE.

  3. A PCE calcula o caminho para o LSP.

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

    • Se o BFD ininterrupto (S-BFD) não estiver configurado para o segmento principal, não haverá mais atualização na rota e o estado LSP também não seja monitorado e comunicado ao PCE. O estado de LSP neste ponto é informado como para cima ou para baixo, dependendo se a computação de caminho tinha tido sucesso naquele ponto.

    • Se o S-BFD estiver configurado para o segmento principal, o estado do segmento principal será monitorado e informado ao PCE. Caso o BFD detecte que o segmento principal está em baixo, o caminho principal correspondente é removido da rota. A mesma rota previamente calculada é reprogramada se esse caminho estiver em alta agora.

  5. Caso uma mensagem PCUpdate seja recebida do PCE, o SR-TE usa o parâmetro recebido para configurar o caminho pelo qual a mensagem PCReport foi enviada. O caminho programado inclui apenas a lista de segmentos recebidos da PCE, e todas as outras listas de segmentos previamente programadas são removidas. Essa reprogramação da rota acontece de forma "make-before-break".

Segmento principal do caminho do roteamento de origem

A delegação não está configurada ou foi eliminada.

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 da lista de segmentos está disponível, a lista de segmentos correspondente é usada para programar a rota de maneira make-before-break.

Lista de segmentos do caminho do roteamento de origem

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

A funcionalidade de delegação é acionada para a lista de segmentos principais no caminho do roteamento de origem.

Lista de segmentos do caminho do roteamento de origem

A delegação não está configurada ou foi eliminada.

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

Lista primária de segmentos do modelo de caminho do roteamento de origem

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

  • No modelo do caminho do roteamento de origem, a funcionalidade da delegação é acionada para todo o caminho do 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 do roteamento de origem, a funcionalidade da delegação é acionada para esse caminho principal específico de acordo com a configuração.

Lista primária de segmentos do modelo de caminho do roteamento de origem

A delegação não está configurada ou foi eliminada.

A funcionalidade da delegação é removida de todos os caminhos de roteamento de origem e caminhos principais que se igualam à configuração do modelo.

Roteamento por segmentos para limitações de PCEP e recursos não compatíveis

O suporte do roteamento por segmentos para PCEP não acrescenta à carga de desempenho do sistema. Entretanto, ele tem as seguintes limitações:

  • Um LSP TE SR não é protegido localmente no PCC. Quando o LSP tem mais de seis hops, nenhum serviço é fornecido no LSP que não seja para transportar tráfego IP simples.

  • Não Mecanismo de Roteamento switchover (GRES) e upgrade unificado de software no serviço (ISSU unificada) não são suportados.

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

  • O IPv6 não é suportado.

  • Os LSPs delegados por PCE não suportam as seguintes condições:

    • LSPs coloridos TE SR

    • IPv6 LSPs

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

    • Padrão multisegment. Somente o primeiro segmento da lista de segmentos é delegar e relatar ao controlador.

Exemplo: Configurar o roteamento por segmentos para o protocolo de elemento de computação de caminho

Este exemplo mostra como configurar o roteamento por segmentos ou o Roteamento de pacotes de origem na engenharia de tráfego (SPRING) (SR-TE) para o Protocolo de Elemento de Computação de Caminho (PCEP). Na configuração, aproveitamos as vantagens do roteamento por segmentos com os benefícios da computação de caminho externo para uma engenharia de tráfego eficiente.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Quatro 5G da série MX Plataformas de roteamento universal, onde o roteador da Série MX de entrada é o Path Computation Client (PCC).

  • Uma conexão TCP do PCC a um Elemento de Computação de Caminho (PCE) com estado externo.

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

    Para a funcionalidade da delegação PCE, você deve executar o Junos OS Release 20.1R1 ou uma versão posterior.

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure MPLS.

  • Configure IS-IS.

Visão geral

A implementação do Junos OS do roteamento por segmentos para PCEP inclui LSPs iniciados por PCE e sr-TE 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 iniciados por um PCE. A PCE cria os LSPs para os 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 do SR-TE PCE iniciados por PCE.

  • A implementação de LSPs delegadas por PCE é introduzida no Junos OS Release 20.1R1, onde os LSPs de roteamento por segmentos não-corados IPv4 localizados no PCC podem ser delegar a um controlador PCE. Em seguida, o PCE controla o LSP e pode modificar atributos de LSP para computação de caminho.

Os LSPs delegados por PCE têm uma vantagem sobre LSPs iniciados por PCE no momento em que a sessão PCEP é realizada. No caso dos LSPs iniciados por PCE, quando a sessão PCEP está inovada, os LSPs são excluídos do PCC. No entanto, no caso dos LSPs delegados por PCE, quando a sessão do PCEP for final, o PCC reassuma o controle dos LSPs delegados da PCE. Como resultado, com LSPs delegados por PCE, evitamos uma situação em que os pacotes são descartados de forma silenciosa (também conhecida como uma condição de rota nula) quando a sessão do PCEP é realizada.

Para habilitar o roteamento por segmentos para PCEP:

Para LSPs de roteamento por segmentos iniciados por PCE:

  1. Ative a computação de caminho externo para MPLS, incluindo a lsp-external-controller instrução em [edit protocols mpls] nível de hierarquia.

    Essa configuração é necessária para PCEP com TE RSVP. Você não pode desativar o PCEP com RSVP-TE quando o roteamento por segmentos para PCEP está ativado.

  2. Ative a computação de caminho externo para SR-TE incluindo lsp-external-controller pccd a instrução em [edit protocols spring-traffic-engineering] nível de hierarquia.

  3. Habilitar o roteamento por segmentos para o PCE, incluindo a spring-capability instrução em [edit protocols pcep pce pce-name] nível de hierarquia.

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

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

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

    O valor de preferência indica a ordem na qual um caminho é selecionado como o formulário de caminho ativo entre os caminhos do candidato, onde um valor maior tem uma preferência maior. Quando não está configurado, um valor de preferência padrão de 8 é aplicado.

  6. Opcionalmente, configure o registro do roteamento por segmentos para fins de solução de problemas, incluindo traceoptions a declaração em nível de [edit protocols spring-te] hierarquia.

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

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

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

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

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

    • Para túneis criados dinamicamente acionados pelo Módulo de Túnel Dinâmico que têm resolução ERO de última [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name] elevação e níveis [edit protocols source-packet-routing source-routing-path-template template-name] 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 ingresso). 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 roteamento para a rota estática.

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

Configuração

Configuração rápida CLI

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

Embora apresentemos a configuração de todos os dispositivos (PCC e 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ê navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar 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 verificação e não afeta a funcionalidade do recurso.

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

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

  6. Ative o recurso de computação de caminhos externos para MPLS.

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

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

  9. Ative o recurso de computação de caminhos externos para o SR-TE.

  10. Configure os parâmetros pcE e possibilite o provisionamento do LSP pelo PCE e pela capacidade de roteamento por segmentos.

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

  12. Ative o recurso de roteamento por segmentos para o PCE.

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

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

  15. Habilitar a capacidade de delegação para o caminho static_srte_lsp_1 do roteamento de origem.

    Ao completar as Etapas 13, 14 e 15, você permite que o PCC delegar os LSPs do roteamento por segmentos ao PCE.

  16. Compromete a configuração.

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show routing-options comandos , e . show protocols Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo (o PCC), entre commit no modo de configuração.

Verificação

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

Verificar IS-IS Adjacency e rótulos
Propósito

Verificar a IS-IS de adjacência no PCC. Observe os valores dos segmentos de rótulos do SRGB, adjacência e nós e os campos de capacidade de saída SPRING.

Ação

Do modo operacional, execute os show isis adjacency extensiveshow isis database extensive comandos , e . show isis overview

Significado

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

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

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

Ação

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 caminho externo para o PCC.

Verificar LSPs TE SR
Propósito

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

Ação

Do modo operacional, execute os show path-computation-client lspshow spring-traffic-engineering lsp detail comandos , e . show route protocol spring-te

Significado

As saídas mostram que dois LSPs sr-TE foram criados pela PCE para os segmentos de adj_sid_lspnode_sid_lsp adjacência e nós, respectivamente.

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

Criação de rota de túnel de verificação
Propósito

Verificar as rotas de túnel criadas para os LSPs TE SR 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 o SR-TE como rótulo de protocolo.

Verificar entradas da tabela de encaminhamento
Propósito

Verificar se o destino do 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 é instalado como uma entrada de encaminhamento.

Verificar o uso de rotas de túnel para encaminhamento estático de rotas
Propósito

Verificar se a rota estática está tomando a rota do túnel criada para os LSPs TE SR.

Ação

Do modo operacional, execute os show route ip-address comandos show route forwarding-table destination ip-address e os 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 comutado de rótulo de roteamento por segmentos estáticos

A arquitetura do roteamento por segmentos permite que os dispositivos de entrada em uma rede de núcleo 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 identificado 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 no destino.

Entender o roteamento por segmentos estáticos LSP em MPLS redes

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

Introdução aos LSPs do roteamento por segmentos

O roteamento por segmentos utiliza o paradigma do roteamento de origem. Um dispositivo orienta um pacote por meio de uma lista ordenada de instruções, chamadas segmentos. Um segmento pode representar qualquer instrução, topologia ou base de serviço. Um segmento pode ter uma semântica local para um nó de roteamento por segmentos ou para um nó global em um domínio de roteamento por segmentos. O roteamento por segmentos aplica um fluxo por qualquer caminho topológico e cadeia de serviços, ao mesmo tempo em que mantém o estado por fluxo apenas no dispositivo de ingresso no domínio do roteamento por segmentos. O roteamento por segmentos pode ser diretamente aplicado à arquitetura MPLS sem alterações no plano de encaminhamento. Um segmento é codificado como um MPLS rótulo. 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 é lançado da pilha.

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

Dynamic segment routing LSPs— Quando um LSP de roteamento por segmentos é criado por um controlador externo e baixado para um dispositivo de entrada por meio de extensões do Path Computation Element Protocol (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 de roteamento por segmentos dinâmicos está contida no ERO (Explicit Route Object) do PCEP ou na BGP de roteamento por segmentos 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áticos ainda pode ser classificado como LSPs coloridos e não-coloridos com base na configuração da color instrução em [edit protocols source-packet-routing source-routing-path lsp-name] nível de hierarquia.

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 instruçã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 de usar LSPs de roteamento por segmentos

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

  • Forneça maior escalabilidade para MPLS redes.

LSP de roteamento por segmentos estáticos coloridos

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

Entender LSPs de roteamento por segmentos estáticos coloridos

Semelhante a uma BGP de roteamento por segmentos, a rota de entrada do LSP colorido está instalada nas tabelas ou nas tabelas de roteamento, com a chave para o mapeamento do inetcolor.0inet6color.0 tráfego DE destincation-ip-address, color IP.

Um LSP de roteamento por segmentos estático pode ter um SID encadernado, no qual uma rota é instalada na tabela mpls.0 de roteamento. Esse rótulo SID encadernado é usado para mapear tráfego etiquetado para o LSP de roteamento por segmentos. Os gateways da rota são derivadas das configurações da lista de segmentos nos caminhos principais e secundários.

Lista de segmentos de LSPs de roteamento por segmentos coloridos

Os LSPs de roteamento por segmentos estáticos coloridos já provam o suporte ao modo first hop label para resolver um LSP. No entanto, o modo IP first hop não é suportado para LSPs de roteamento por segmentos coloridos. A partir da versão 19.1R1 Junos OS, um recurso de verificação de confirmação é introduzido para garantir que todas as listas de segmentos que contribuem para as rotas coloridas tenham o rótulo mínimo presente para todos os hops. Caso esse requisito não seja atendido, o commit será bloqueado.

Roteamento por segmentos estáticos não-coloridos LSP

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

O Junos OS tem suporte para LSPs de roteamento por 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 por segmentos não-coloridos.

Entender LSPs de roteamento por segmentos não-coloridos

O LSP de roteamento por segmentos não-coloridos tem um nome exclusivo e um endereço IP de destino. Uma rota de entrada até 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 relacionados ao destino. Caso o roteamento por segmentos não coloridos LSP não exigir uma rota de entrada, a rota de ingresso pode ser desabilitada. Um LSP de roteamento por segmentos não coloridos usa rótulo SID obrigatório para obter costuraS LSP do roteamento por segmentos. Esse rótulo que pode ser usado para modelar o LSP do roteamento por segmentos como um segmento que pode ser usado para construir outros LSPs de roteamento por segmentos de maneira hierárquica. O trânsito do rótulo SID obrigatório, por padrão, tem preferência de 8 e uma métrica de 1.

A partir da versão 18.2R1 Junos OS, LSPs de roteamento por segmentos não-coloridos configurados estaticamente no dispositivo de entrada são reportados ao Elemento de Computação de Caminho (PCE) por meio de uma sessão pcep (Path Computation Element Protocol, Protocolo de Elemento de Computação de Caminho). Esses LSPs de roteamento por segmentos não coloridos podem ter rótulos de identificador de serviço (SID) obrigatórios associados a eles. Com esse recurso, a PCE pode usar esse rótulo SID obrigatório 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 principais. Se houver vários caminhos principais operacionais, o mecanismo de encaminhamento de pacotes (PFE) distribuirá tráfego pelos caminhos com base nos fatores de balanceamento de carga, como o peso configurado no caminho. Esse é o caminho multi-custo igual (ECMP) se nenhum dos caminhos tiver um peso configurado sobre eles ou UMEMP 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 rebalanceia o tráfego pelos caminhos restantes, o que leva automaticamente a alcançar a proteção do caminho. Um LSP de roteamento por segmentos não coloridos pode ter um caminho secundário para proteção de caminho dedicada. Após falha de um caminho principal, o PFE rebalanceia o tráfego para os caminhos principais funcionais restantes. Caso contrário, o PFE muda o tráfego para o caminho do backup, conseguindo assim a proteção do caminho. Um LSP de roteamento por segmentos não coloridos pode especificar uma métrica para suas rotas de ingresso [edit protocols source-packet-routing source-routing-path lsp-name] e SID obrigatório. Vários LSPs de roteamento por segmentos não-coloridos têm o mesmo endereço de destino que contribuem para o próximo salto da rota de ingresso.

Vários LSPs de roteamento por segmentos não-coloridos têm o mesmo endereço de destino que contribuem para o próximo salto da rota de ingresso. Cada caminho, principal ou secundário, de cada LSP de roteamento por segmentos é considerado um candidato a gateway, se o caminho estiver funcionando e o LSP do 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 next-hop pode manter não pode exceder o limite de multi-caminho RPD, que é de 128 por padrão. Caminhos extra são podados, em primeiro lugar os caminhos secundários e, em seguida, os caminhos principais. Uma determinada lista de segmentos pode ser referenciada várias vezes como caminhos principais ou secundários por esses LSPs de roteamento por segmentos. Nesse caso, existem vários gateways, cada um com uma ID de túnel LSP de roteamento por segmentos exclusiva. Esses gateways são distintos, embora tenham interface e pilha de rótulos de saída idênticos. Um LSP de roteamento por segmentos não coloridos e um LSP de roteamento por segmentos coloridos também podem ter o mesmo endereço de destino. No entanto, eles correspondem a endereços de destino diferentes para rotas de entrada, conforme o endereço de destino do LSP de roteamento por segmentos colorido é construído com seu endereço de destino e cor.

Nota:

No caso em que um LSP de roteamento por segmentos estático e não-colorido e uma co-existência de LSP de roteamento por segmentos criados por PCEP e tenham o mesmo endereço que contribui para a mesma rota de entrada, caso também tenham a mesma preferência. Caso contrário, o LSP de roteamento por segmentos com a melhor preferência é instalado na rota.

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

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

Antes do Junos OS Release 19.1R1, para que um LSP de roteamento estático não-colorido fosse usável, o primeiro salto da lista de segmentos precisava ser um endereço IP de uma interface de saída, e o segundo a nth hops poderia ser rótulos SID. A partir da versão 19.1R1 Junos OS, esse requisito não se aplica, pois o primeiro hop dos LSPs estáticos não-coloridos agora fornece suporte a rótulos SID, além de endereços IP. Com o suporte ao rótulo first hop, MPLS fast reroute (FRR) e multipath ponderado de custo igual é ativado para resolver os LSPs de roteamento por segmentos não-coloridos estáticos, semelhantes a LSPs estáticos coloridos.

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

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

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

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

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

Para LSPs estáticos dinâmicos não coloridos, ou seja, LSPs de roteamento por segmentos orientados por PCEP, a instrução deve ser habilitada globalmente, pois a configuração em nível de segmento não é inherit-label-nexthops aplicada.

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

Tabela 4: Resolução de LSP estático não colorida com base na especificação de First Hop

Especificação de First Hop

Modo de resolução LSP

Somente endereço IP

Por exemplo:

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

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

Somente 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 é solucionada 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.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Por padrão, a lista de segmentos é solucionada usando o 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.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

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

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

Por exemplo:

Nota:

O tipo de primeiro hop de listas de segmentos de um LSP de roteamento por segmentos estáticos pode causar uma falha no commit(

  • Diferentes listas de segmentos de um túnel têm diferentes tipos de resolução de primeiro hop. Isso é aplicável a LSPs de roteamento por segmentos estáticos 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 do tipo de resolução de primeiro hop no momento da computação do caminho.

    Por exemplo:

    O commit do túnel lsp1 falha, pois o caminho-1 é do modelo de endereço IP e o caminho-2 está no modo de rótulo.

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

    Por exemplo:

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

Provisionamento de LSP do roteamento por segmentos estáticos

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

O Junos OS permite LSPs de roteamento por segmentos estáticos configurando a segment instrução em nível [edit protocols mpls static-label-switched-path static-label-switched-path] de hierarquia. Um LSP do segmento estático é identificado por um rótulo SID exclusivo que se enquadra 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 em nível de [edit protocols mpls label-range] hierarquia.

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

  • No momento, o Junos OS tem uma limitação de que o próximo hop não pode ser construído para pressionar mais do que os rótulos máximos de profundidade da lista de segmentos. Assim, uma lista de segmentos com mais do que os rótulos SID máximos (exceto o rótulo SID do primeiro hop usado para resolver o encaminhamento do next-hop) não é usável para LSPs de roteamento por segmentos coloridos ou não. Além disso, o número real permitido para um determinado LSP de roteamento por segmentos pode ser ainda inferior ao limite máximo, se um serviço MPLS estiver no LSP do roteamento por segmentos ou se o LSP do roteamento por segmentos estiver em um enlace ou em um caminho de proteção do nó. Em todos os casos, o número total de rótulos de serviço, rótulos de 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 em [edit protocols source-packet-routing] nível de hierarquia. Vários LSPs de roteamento por segmentos não coloridos com menos ou igual a rótulos SID máximos podem ser costurados juntos para construir um LSP de roteamento por segmentos mais longo. Isso é chamado de costura LSP do roteamento por segmentos. Ela pode ser conquistada usando o rótulo SID de encadernação.

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

  • Um máximo de 12 8 caminhos principais 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, verifique se há falha no check-in com um erro.

  • A encadernação máxima da lista de segmentos a um túnel LSP é aumentada de 8 para 128, com no máximo 1.000 túneis por sistema. Um máximo de 128 caminhos principais são suportados por LSP de roteamento por segmentos estáticos. Como limitação, o suporte máximo do sensor para o caminho LSP é de apenas 32.000.

  • Se qualquer 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 falha com um erro.

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

Nas redes de roteamento por segmentos que tenham cada dispositivo de borda do provedor (PE) conectado a todos os outros dispositivos PE, uma grande quantidade de configuração é necessária para configurar os caminhos comutado por rótulos (LSPs) do roteamento por segmentos, embora apenas alguns caminhos de engenharia de tráfego de roteamento por segmentos (SR-TE) possam ser usados. Você pode habilitar BGP criação dinâmica trigerada desses LSPs para reduzir a quantidade de configuração nessas implantações.

Configurando o modelo de LSP do roteamento por segmentos dinâmicos

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

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

  • A seguir, uma configuração de amostra para um modelo LSP de roteamento por segmentos dinâmicos sem cores:

Resolvendo LSPs de roteamento por segmentos dinâmicos
Resolvendo o roteamento por segmentos dinâmicos coloridos LSP

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

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

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 por meio do color-any modelo. Sem um mapeamento válido, o túnel não é criado, e a BGP de pedidos de resolução permanece não resolvido.

Resolvendo LSPs de roteamento por segmentos dinâmicos sem cor

Todas as rotas de captura para LSPs não coloridas são adicionadas à tabela de roteamento inet.3. O destino do túnel não-colorido deve estar configurado em uma configuração diferente com apenas spring-te um nome de modelo na lista de mapeamento. Esse nome do modelo é usado em todas as rotas de túnel que correspondênciam qualquer uma das redes de destino configuradas na mesma spring-te configuração. Esses túneis são semelhantes aos túneis de RSVP na funcionalidade.

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

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

O modelo de LSP de roteamento por segmentos dinâmicos sempre transporta um caminho parcial. O SID do nó de último hop é obtido automaticamente no tempo de criação do túnel, dependendo do endereço de next-hop (PNH) do protocolo. O mesmo modelo pode ser usado por vários túneis para destinos diferentes. Nesses casos, o caminho parcial permanece o mesmo, e somente as alterações de último hop, dependendo da PNH. Modelos de LSP de roteamento por segmentos dinâmicos não são comuns a um único túnel, pois um caminho completo não pode ser realizado nele. Você pode usar uma lista de segmentos para utilizar um caminho completo.

LSPs de roteamento por segmentos dinâmicos coloridos

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

Para a configuração da amostra acima citada, as entradas de rota são as seguinte:

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

  2. inetcolor6.0 tunnel route: ffff::22.33.44.0-0/120 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    Nome do túnel LSP R1(prefixo) -> 22.33.44.55-101 (PNH) = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefixo) -> ff::22.33.44.55-101 (PNH) nome do túnel LSP = 22.33.44.55:65:dt-srte-tunnel1

    Nome do túnel de R1(prefixo) -> ff::22.33.44.55-124 (PNH) nome do túnel LSP = 22.33.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

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

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

  5. inetcolor6.0 tunnel route:

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

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

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

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

Para a configuração da amostra acima citada, as entradas de rota são as seguinte:

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

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

  3. BGP prefix to tunnel mapping:

    Nome do modelo LSP (PNH) -> 22.33.44.55 (PNH) = LSP1 --- 22.33.44.55:dt-srte-tunnel2

    R1(prefixo) -> ff::22.33.44.55 (PNH) nome do modelo LSP = LSP1 --- 22.33.44.55:dt-srte-tunnel2

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

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

Roteamento por segmentos dinâmicos não resolvidos LSP

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

Para a configuração da amostra acima citada, as entradas de rota são as seguinte:

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

  2. inetcolor6.0 tunnel route: ffff::22.33.44.0 - 0/120 -> RT_NH_TUNNEL ffff::1.1.1.0 - 0/24 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: O túnel R1(prefixo) -> 22.33.44.55-124 (PNH) não será criado. (Modelo não encontrado para a cor).

Considerações sobre a configuração da criação dinâmica de LSPs do roteamento por segmentos

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

  • Um modelo pode ser atribuído a um objeto de cores. Quando a configuração do túnel dinâmico inclui um modelo com um objeto de cor, você também deve configurar todos os outros modelos com spring-te objetos de cores. Assume-se que todos os destinos sejam coloridos nessa configuração.

  • Um modelo pode ter uma lista de cores definida nele ou configurar-se com a color-any opção. Ambas essas 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 color-any opção.

  • O mapeamento de cores para modelo é feito de um para um. Uma cor não pode ser mapeada para vários modelos.

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

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

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

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

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

Os seguintes serviços são suportados em LSPs de roteamento por segmentos dinâmicos e coloridos:

  • VPN de Camada 3

  • BGP EVPN

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

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

  • VPN de Camada 3

  • VPN de Camada 2

  • Configurações multipath

Comportamento com várias 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 de origem estática e dinâmica), a preferência do roteamento por segmentos é usada para escolher a entrada da rota ativa. Um valor maior tem maior preferência. Caso a preferência continue a mesma, a origem do túnel é usada para determinar a entrada da rota.

Limitações de LSPs do roteamento por segmentos dinâmicos

Os LSPs dinâmicos TE SR não suportam os seguintes recursos e funcionalidades:

  • Túneis de roteamento por segmentos IPv6.

  • Túneis estáticos.

  • 6PE não é suportado.

  • CSPF distribuído.

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

  • Instalar e rotas B-SID em um modelo.

Mapeamento baseado em cores de serviços de VPN

Você pode especificar a cor como uma restrição de salto seguinte do protocolo (além do endereço IPv4 ou IPv6) para resolver túneis de transporte em LSPs com cores estáticas e BGP LSPs do roteamento por segmentos (SRTE). Esse é o protocolo color-IP next hop resolution, no qual você precisa configurar um mapa de resolução e aplicar-se aos serviços de VPN. Com esse recurso, você pode habilitar a direção de tráfego baseada em cores dos serviços VPN de Camada 2 e Camada 3.

O Junos OS tem suporte para LSPs SRTE coloridos associados a uma única cor. O mapeamento baseado em cores do recurso de serviços VPN é suportado em LSPs estáticos e BGP LSPs SRTE.

Coloração de serviços de VPN

Em geral, um serviço VPN pode ser atribuído a uma cor no roteador de saída onde o NLRI vpn é anunciado ou em um roteador de entrada no qual o NLRI vpn é recebido e processado.

Você pode atribuir uma cor aos serviços de VPN em diferentes níveis:

  • Por instância de roteamento.

  • Por BGP grupo.

  • Por BGP vizinho.

  • Por prefixo.

Uma vez que você atribua uma cor, a cor é conectada a um serviço VPN na forma de BGP comunidade estendida por cores.

Você pode atribuí-lo a várias cores a um serviço de VPN, chamado de serviços VPN multi-color. Nesses casos, a última cor conectada é 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 de entrada por meio de várias políticas na seguinte ordem:

  • BGP de exportação no dispositivo de saída.

  • BGP política de importação no dispositivo de entrada.

  • Política de importação de VRF no dispositivo de entrada.

Os dois modos de coloração de serviço 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 pela coloração do serviço de VPN. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la na instância de roteamento do serviço VPN, na exportação de grupo ou no nível da hierarquia vrf-export[edit protocols bgp] do vizinho. O NLRI vpn é anunciado pela BGP com a comunidade estendida de cores especificada.

Por exemplo:

Ou

Nota:

Quando você aplica a política de roteamento como uma política de exportação de um grupo de BGP ou vizinho BGP, você deve incluir a declaração no BGP, no grupo BGP ou no nível do vizinho BGP para que a política adote um efeito no vpn-apply-export NLRI da VPN.

As políticas de roteamento são aplicadas a NLRIs de prefixo VPN de Camada 3, NRLIs VPN de Camada 2 e NLRIs de EVPN. A comunidade estendida por cores é herdada por todas as rotas de VPN, importadas e instaladas nos VRFs alvo em um ou vários dispositivos de ingresso.

Atribuição de cores de entrada

Nesse modo, o dispositivo de ingresso (ou seja, o receptor da VPN NLRI) é responsável pela coloração do serviço de VPN. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la à instância de roteamento do serviço VPN, à importação de grupo ou à importação de vizinho de grupo no nível vrf-import[edit protocols bgp] da hierarquia. Todas as rotas de VPN correspondentes à política de roteamento estão conectadas à comunidade estendida por cores especificada.

Por exemplo:

Ou

Especificando o modo de mapeamento de serviços de VPN

Para especificar modos de mapeamento de serviço VPN flexíveis, você deve definir uma política usando a declaração e indicar a política na instância de roteamento de um serviço VPN, na importação de grupo ou no nível da resolution-mapvrf-import[edit protocols bgp] hierarquia. Todas as rotas de VPN correspondentes à política de roteamento estão conectadas ao mapa de resolução especificado.

Por exemplo:

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

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

Nota:

Cada modo de mapeamento de serviço VPN deve ter um nome exclusivo definido no mapa de resolução. Apenas uma única entrada de IP-color é suportada no mapa de resolução, no qual a rota(s) VPN é solucionada usando-se um protocolo IP colorido no próximo salto na forma de ip-address:color .

Resolução de next hop do protocolo Color-IP

O processo de resolução do próximo hop do protocolo é aprimorado para dar suporte ao protocolo IP de cores próxima resolução de hop. Para um serviço VPN de cor, o processo de resolução do próximo hop do protocolo leva uma cor e um mapa de resolução, cria um próximo hop de protocolo IP colorido na forma de endereço IP:colore resolve o protocolo no próximo hop na tabela de roteamento inet6color.0.

Você deve configurar uma política para dar suporte à resolução multipath de serviços vpn de Camada 2, VPN de Camada 3 ou EVPN em LSPs coloridos. A política deve ser aplicada à tabela RIB relevante como política de importação de resolver.

Por exemplo:

Reação ao protocolo IP Próxima Resolução de hop

Caso um serviço VPN de cor não tenha um mapa de resolução aplicado a ele, o serviço VPN ignora sua cor e volta ao protocolo IP na próxima resolução de hop. Por outro lado, se um serviço 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 da próxima resolução de hop.

O rebaixamento é um processo simples, desde LSPs SRTE coloridos até LSPs LDP, usando um grupo RIB para LDP para instalar rotas em tabelas de roteamento inet{6}color.0. Uma correspondência de prefixo mais longa para um protocolo IP colorido no próximo hop garante que, se uma rota LSP do SRTE colorida não existir, uma rota LDP com um endereço IP correspondente deve ser retornada.

BGP mapeamento baseado em cores da Unicast pelo SR-TE

A partir do Junos OS Release 20.2R1, a BGP Unicast (BGP-LU) pode resolver rotas IPv4 ou IPv6 por meio de engenharia de tráfego e roteamento por segmentos (SR-TE) para famílias de endereços IPv4 e IPv6. BGP-LU aceita o mapeamento de uma BGP da comunidade e a definição de um para resolution map SR-TE. Um próximo hop de protocolo de cores é construído e ele é resolvido em um túnel TE SR-TE na inetcolor.0 ou inet6color.0 tabela. BGP e inet.3 tabelas inet6.3 para mapeamento sem cores. Com isso, você pode anunciar prefixos BGP-LU IPv6 e IPv4 com um endereço next-hop IPv6 em redes somente IPv6 onde os roteadores não tenham endereços IPv4 configurados. Com esse recurso, atualmente, temos suporte para BGP IPv6 LU sobre SR-TE com IS-IS underlay.

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

Figura 9: BGP IPv6 LU sobre IPv6 SR-TEBGP IPv6 LU sobre IPv6 SR-TE

BGP-LU aceita os seguintes cenários:

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

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

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

  • BGP IPv6 LU sobre IPv6 SR-TE de cores estáticas e não coloridas, com extensões ISIS IPv6 SR.

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

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

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

Recursos suportados e não suportados para mapeamento baseado em cores de serviços DE VPN

Os seguintes recursos e funcionalidades são suportados com mapeamento baseado em cores de serviços VPN:

  • BGP VPN de Camada 2 (VPN Kompella Camada 2)

  • BGP EVPN

  • Mapa de resolução com uma única opção de cores de IP.

  • Protocolo IPv4 e IPv6 coloridos próxima resolução de hop.

  • Reação baseada em grupo da base de informações de roteamento (também conhecida como tabela de roteamento) para LDP LSP na tabela de roteamento inetcolor.0.

  • LSP do SRTE de cor.

  • Plataformas virtuais.

  • Junos OS de 64 bits.

  • Sistemas lógicos.

  • BGP unicast.

Os seguintes recursos e funcionalidades não são suportados por mapeamento baseado em cores de serviços VPN:

  • LSPs MPLS cores, como RSVP, LDP, BGP-LU, estática.

  • Circuito de Camada 2

  • FEC-129 BGP VPN de Camada 2 descobertas e com sinal de 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 de LDP.

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

Para configurar um modelo:

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

  2. Inclua a instrução source-routing-path-template-map no nível da hierarquia para listar as declarações de política nas quais o LSP iniciado [edit protocols source-packet-routing] por PCE deve ser verificado.

  3. Defina uma política para listar os LSPs nos quais o modelo deve ser aplicado.

    A from declaração pode incluir o nome LSP ou a expressão regular LSP usando as condições e as condições de lsplsp-regex combinação. Essas opções são mutuamente exclusivas, portanto, você pode especificar apenas uma opção em um determinado ponto de tempo.

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

Leve em consideração o seguinte 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 a LSPs de roteamento por segmentos de qualquer outro cliente.

  • A configuração fornecida pelo 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: Configurando o caminho comutado do rótulo do roteamento por segmentos estáticos

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

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

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

  • Junos OS Release 18.1 ou posterior em execução em todos os roteadores

Antes de começar, configure as interfaces do dispositivo.

Visão geral

Um conjunto de caminhos de roteamento por segmentos explícitos do Junos OS está configurado no roteador de entrada de um túnel de roteamento por segmentos estáticos não-coloridos configurando a instrução em nível segment-list [edit protocols source-packet-routing] de hierarquia. Você pode configurar o túnel de roteamento por segmentos configurando a source-routing-path declaração em nível de [edit protocols source-packet-routing] hierarquia. O túnel de roteamento por segmentos tem um endereço de destino e um ou mais caminhos principais e, opcionalmente, caminhos secundários que se referem à lista de segmentos. Cada lista de segmentos consiste em uma sequência de hops. Para túnel de roteamento por segmentos estáticos não-coloridos, o primeiro hop da lista de segmentos especifica um endereço IP próximo hop imediato e o segundo ao Nth hop especifica os rótulos de segmento (SID) correspondentes ao enlace ou nó pelo qual o caminho atravessa. A rota até 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 MPLS de segurança em todos os roteadores. O túnel de roteamento por segmentos está configurado do roteador PE1 ao roteador PE5 com um caminho principal configurado no roteador PE1 e no roteador PE5 . O roteador PE1 também está configurado com caminho secundário para proteção de caminho. Os roteadores de trânsito PE2 a PE4 estão configurados com rótulos SID de adjaência com rótulos pop e uma interface de saída.

Figura 10: Caminho comutado de rótulo de roteamento por segmentos estáticosCaminho comutado de rótulo de roteamento por segmentos estáticos

Configuração

Configuração rápida CLI

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuração do dispositivo PE1
Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar 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 opções de roteamento de encaminhamento de pacotes.

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

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

  5. Configure as interfaces da área de protocolo.

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

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

  8. Configure as opções de política.

  9. Configure BGP da comunidade.

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

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show interfacesshow policy-options comandos, show protocols , show routing-optionsshow routing-instances Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Configuração do dispositivo PE2
Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar 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.

  3. Configure interfaces e intervalo de rótulos estáticos para a MPLS.

  4. Configure interfaces para OSPF.

Resultados

Do modo de configuração no roteador PE2, confirme sua configuração inserindo show interfaces os comandos e os show protocols comandos. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

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

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

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

Ação

Do modo operacional, insira o show route table inet.3 comando.

Significado

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

Verificar entradas da tabela de roteamento mpls.0 do roteador PE1
Propósito

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

Ação

Do modo operacional, insira o show route table mpls.0 comando.

Significado

A saída exibe os rótulos de SID de túneis de roteamento por segmentos.

Verificar o tráfego SPRING Engineered LSP do Roteador PE1
Propósito

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

Ação

Do modo operacional, insira o show spring-traffic-engineering overview comando.

Significado

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

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

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

Ação

Do modo operacional, insira o show spring-traffic-engineering lsp detail comando.

Significado

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

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

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

Ação

Do modo operacional, insira o show route table mpls.0 comando.

Verificar o status dos segmentos de MPLS LSP estáticos do Roteador PE2
Propósito

Verificar o status dos segmentos MPLS LSP do roteador PE2.

Ação

Do modo operacional, insira o show mpls static-lsp comando.

Significado

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

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

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

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

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

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

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

  • Inclusão de endereços IP de hop frouxos ou rígidos.

    Nota:

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

  • Número máximo de IDs por 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 dá 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 (SRTE).

  • Interfaces sem número.

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

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

  • Incluindo e excluindo endereços IP da 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 da pilha de rótulos com CSPF.

Compactação da pilha de rótulos habilitada

Uma pilha de rótulos comprimidos representa um conjunto de caminhos de uma origem até um destino. Ele geralmente consiste em SIDs de nós e SIDs de adjaceência. Quando a compressão da pilha de rótulos está ativada, 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, enquanto se conformam a restrições.

Compactação da pilha de rótulos desabilitada

A computação CSPF multipath com compactação de pilha de rótulos desabilitada encontra até N listas de segmentos até o destino, onde:

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

  • Cada lista de segmentos é formada por SIDs de adjabilidade.

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

  • Nenhuma lista de segmentos é igual a outra.

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

Banco de dados distribuído de computação CSPF

O banco de dados usado para computação SRTE tem todos os links, nós, prefixos e suas características, independentemente de a engenharia de tráfego ser ativada nesses nós de publicidade. Em outras palavras, é a união do banco de dados de engenharia de tráfego (TED) e IGP banco de dados de estados de enlace de todos os domínios que o nó de computação aprenderam.

Configurando restrições de computação CSPF distribuída

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 a computação dos LSPs de roteamento por segmentos principais e secundários.

Para configurar um perfil de computação, inclua a instrução de perfil de computação em nível [edit protocols source-packet-routing] de hierarquia.

A configuração para as restrições de computação suportadas incluem:

  • Administrative groups

    Você pode configurar grupos de administrador no nível da [edit protocols mpls] hierarquia. O Junos OS aplica a configuração de grupo administrativo às interfaces de engenharia de tráfego (SRTE) do roteamento por segmentos.

    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 do candidato ou em caminhos individuais de candidato.

    • include-any— Especifica que qualquer enlace com pelo menos um dos grupos administrativos configurados na lista é aceitável para o caminho atravessar.

    • include-all— Especifica que qualquer enlace com todos os grupos administrativos configurados na lista é aceitável para o caminho atravessar.

    • exclude— Especifica que qualquer enlace que não tenha nenhum dos grupos administrativos configurados na lista é aceitável para o caminho atravessar.

  • Explicit path

    Você pode especificar uma série de IDs de roteador no perfil da computação como uma restrição para a computação dos caminhos de candidatos do SRTE. Cada hop tem que ser um endereço IPv4 e pode ser do tipo rigoroso ou solto. Se o tipo de hop não estiver configurado, será usado um rigoroso. Você deve incluir a opção na instrução da lista de segmentos compute ao especificar a restrição de caminho segment-list explícito.

  • Maximum number of segment lists (ECMP paths)

    Você pode associar um caminho do candidato a várias listas de segmentos dinâmicos. Os caminhos são caminhos de ECMP, nos quais cada lista de segmentos se traduz em um gateway de salto seguinte com peso ativo. Esses caminhos são resultado da computação de caminho com ou sem compactação.

    Você pode configurar esse atributo usando a maximum-computed-segment-lists maximum-computed-segment-lists opção na instrução de configuração do perfil de computação. Essa configuração determina o número máximo de listas de segmentos computadas para determinado LSP principal e secundário.

  • Maximum segment list depth

    O parâmetro de computação de profundidade da lista de segmentos máximo garante que, entre os caminhos de ECMP que atendam a todas as outras restrições, como o grupo administrativo, apenas os caminhos que tenham 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 no perfil da computação, ele sobrepõe a configuração no nível maximum-segment-list-depth[edit protocols source-packet-routing] da hierarquia, se presente.

    Você pode configurar esse atributo usando a maximum-segment-list-depth maximum-segment-list-depth opção na instrução de configuração do perfil de computação.

  • Protected or unprotected adjacency SIDs

    Você pode configurar SID de adjaceência protegido ou compute-profile desprotegido como uma restrição no perfil de computação para evitar links com o tipo SID especificado.

  • Metric type

    Você pode especificar o tipo de métrica no enlace a ser usado para computação. Por padrão, os LSPs TE SR 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 de IGP protocolos. No entanto, você também pode escolher usar a IGP de cálculo usando a configuração do tipo métrica no perfil de computação.

    Você pode configurar esse atributo usando a metric-type (igp | te) opção na instrução de configuração do perfil de computação.

Computação CSPF distribuída

Os caminhos de candidatos ao SRTE são computados localmente para que atendam às restrições configuradas. Quando a compressão da pilha de rótulos é desabilitada, o resultado da computação CSPF de vários caminhos é um conjunto de pilhas DEDS de adjacência. Quando a compressão da pilha de rótulos é ativada, o resultado é um conjunto de pilhas de rótulos comprimidos (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 principais não são evitados para a computação. Para obter mais informações sobre os caminhos principais e secundários, consulte Configurar LSPs primárias e secundárias.

Para quaisquer LSPs com resultado de computação mal-sucedido, a computação é recuperada conforme o banco de dados de engenharia de tráfego (TED) muda.

Interação entre recursos distribuídos de computação de CSPF e SRTE

Pesos associados a caminhos de uma política srte

Você pode configurar pesos contra caminhos SRTE computação e estáticos, o que contribui para os próximos saltos da rota. Entretanto, um único caminho habilitado para computação pode resultar em várias listas de segmentos. Essas listas de segmentos computados são tratadas como ECMP entre si. Você pode designar pesos de ECMP hierárquico a esses segmentos, considerando os pesos atribuídos a cada uma das primárias configuradas.

Detecção de liveliness BFD

Você pode configurar a detecção de vivacência de BFD para os caminhos principais ou secundários computados. Cada caminho principal ou secundário computado pode resultar em várias listas de segmentos, como resultado, os parâmetros BFD configurados contra as listas de segmentos são aplicados a todas as listas de segmentos computados. Se todos os caminhos principais ativos descerem, o caminho secundário pré-programado (se fornecido) torna-se ativo.

herd-label-nexthops

Você não precisa habilitar explicitamente a configuração na hierarquia para os caminhos principais ou secundários computados, pois ele inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name] é 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 principais ou secundários com o recurso de tradução automática referenciam essas listas de segmentos. Por outro lado, o principal ou secundário no qual o recurso de computação está ativado não pode referenciar nenhuma lista de segmentos. Como resultado, você não pode habilitar o recurso de computação e o recurso de tradução automática para um determinado caminho principal ou secundário. No entanto, você pode ter um LSP configurado com um caminho principal com tipo de computação e outro com tipo de tradução automática.

Configurações de amostra de computação CSPF distribuídas

Exemplo 1

No exemplo 1,

  • O caminho principal não computado faz referência a uma lista de segmentos configurada. Neste exemplo, a lista de segmentos configurada static_sl1 é referenciada e também serve como o nome desse caminho principal.

  • Um principal computado deve ter um nome configurado, e esse nome não deve referenciar nenhuma lista de segmentos configurada. Neste exemplo, compute_segment1 não é uma lista de segmentos configurada.

  • O compute_profile_red de computação é aplicado ao caminho principal com o nome compute_segment1.

  • O compute_profile_red de computação inclui uma lista de segmentos do tipo, usada para especificar a restrição compute de caminho explícito para a computação.

Os pesos para os next-hops computados e os next-hops estáticos são de 2 e 3, respectivamente. Assumindo que os próximos hops para caminhos computados sejam comp_nh1,comp_nh2e comp_nh3,e que o next-hop para caminho estático seja static_nh,os pesos são aplicados da seguinte forma:

Next-Hop

Peso

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Exemplo 2

No Exemplo 2, os caminhos principais e 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 é citada em um caminho principal ou secundário, ela resulta na computação local de um caminho até o destino sem restrições ou outros parâmetros para a computação.

Exemplo: Configuração CoS encaminhamento baseado em CoS e roteamento baseado em políticas para LSPs TE SR

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 não-coloridos de roteamento por segmentos (SR-TE) para orientar o tráfego seletivo por um caminho sr-TE explícito, oferecendo a você o benefício de atender o tráfego com base na classe de serviço ou em uma política.

Encaminhamento CoS baseado em TE SR e roteamento baseado em políticas

Benefícios do CoS Com Base em Encaminhamento (CBF) e Roteamento baseado em políticas (PBR) para LSPs sr-TE LSPs

Com a CBF e o PBR, você pode:

  • Use combinações de caminhos de engenharia de tráfego de roteamento por segmentos (SR-TE) para orientar o tráfego de serviço no núcleo.

  • Escolha os serviços de suporte para resolver sobre os caminhos TE SR selecionados.

Fontes de caminho do roteamento por segmentos com suporte para CBF e PBR

As seguintes fontes de caminho de roteamento por segmentos CoS o encaminhamento baseado em políticas e o encaminhamento baseado em políticas:

  • Static SR–TE paths— Caminhos de roteamento de origem configurados estaticamente que têm toda a pilha de rótulos configurada estaticamente.

  • PCEP— Provisionamento dinâmico de caminhos de roteamento de origem criados em um controlador e baixados para um roteador de entrada em um ERO por meio de extensões de roteamento por segmentos PCEP ou em uma política de roteamento por segmentos BGP por meio de extensões de roteamento por segmentos BGP.

  • Dynamic LSPs— Túneis criados dinamicamente acionados pelo Módulo de Túnel Dinâmico que têm resolução ERO de última elevação.

  • Auto-translated paths— Caminhos de roteamento de origem configurados estáticamente que são traduzidos automaticamente.

Considerações sobre a configuração de CBF e PBR para LSPs sr-TE

Lembrar:

  • O CBF e o PBR só são habilitados em LSPs não-coloridos TE QUE sejam configurados estaticamente ou dinamicamente.

  • As configurações de CBF e PBR para SR-TE LSPs podem co-existir em um dispositivo; a ordem de configuração determina o tipo de encaminhamento das rotas.

  • Para o PBR, se o primeiro hop do SR-TE LSP for um rótulo, você deve incluir a resolution preserve-nexthop-hiearchy instrução no nível [edit routing-options] da hierarquia.

  • O encaminhamento baseado na categoria das rotas para a CBF fica 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 saída show route de comando.

Configure CoS encaminhamento baseado em CoS e roteamento baseado em políticas para LSPs TE SR

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 orientar o tráfego seletivo usando um caminho explícito para o tráfego de roteamento por segmentos (SR-TE). Somente LSPs de roteamento por segmentos não coloridos que tenham o próximo hop configurado como rótulo de primeiro hop ou endereço IP com suporte a CBF e PBR.

antes de começar

  • Você deve estar executando as versões 20.1 e posteriores do Junos OS para habilitar o CBF e o PBR para LSPs não-coloridos TE SR.

  • Configure as interfaces do dispositivo e garanta que os dispositivos sejam conectados à rede.

  • Defina listas de segmentos e configure LSPs TE SR e seus parâmetros associados.

Para configurar um SR-TE LSP, faça o seguinte:

  1. Defina a lista de segmentos com parâmetros de rótulo.

    Por exemplo:

  2. Configure o caminho de roteamento de origem para os LSPs TE SR e especifique o valor de preferência e o segmento principal do caminho.

    Por exemplo:

Agora você pode configurar CBF e PBR para os LSPs TE SR configurados.

Para configurar a CBF, faça o seguinte

  1. Defina classificadores de ponto de código de serviços diferenciados (DSCP) para tratar pacotes IPv4, classes de encaminhamento e valores de opção.

    Por exemplo:

  2. Defina classes de encaminhamento (FCs) para o grupo de pacotes para transmissão e atribua pacotes às filas de saída.

    Por exemplo:

  3. Atribua os classificadores configurados às interfaces de dispositivo.

    Por exemplo:

  4. Defina CoS políticas de encaminhamento baseadas em CoS LSP com o LSP next-hop como o SR-TE LSP.

    Por exemplo:

  5. Elitra tráfego que não encontre nenhuma classe de encaminhamento no mapa de next-hop.

    Por exemplo:

  6. Configure uma instrução de política que especifica que as rotas que correspondênciam o filtro de roteamento estão sujeitas ao CoS mapeamento next-hop especificado pelo nome do mapa.

    Por exemplo:

  7. Aplique a política às rotas que estão sendo exportadas da tabela de roteamento para a tabela de encaminhamento. Isso capacita o CBF para LSPs TE SR.

    Por exemplo:

  8. Compromete 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 baseado em classes de rotas fica visível apenas na tabela de encaminhamento, ao contrário do PBR, onde as rotas filtradas são visíveis na saída show route de comando.

Para configurar o PBR, faça o seguinte

  1. Configure uma instrução de política que especifica que as rotas que correspondênciam o protocolo e o filtro de roteamento estão sujeitas ao LSP next-hop ou são balanceadas como multicamadas de custo igual (ECMP) na tabela de encaminhamento.

    Por exemplo:

  2. Configure o dispositivo para realizar a resolução personalizada da rota no protocolo nos próximos saltos de rotas.

    Nota:

    A declaração é obrigatório para que o PBR funcione quando o primeiro hop do resolution preserve-nexthop-hierarchy SR-TE LSP for um rótulo.

  3. Aplique a política às rotas que estão sendo exportadas da tabela de roteamento para a tabela de encaminhamento. Com isso, o PBR pode ser TE LSPs.

    Por exemplo:

  4. Compromete 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 next-hops para o prefixo de destino, 4.0.0.1. As expanded-nh extensive opções exibem os next-hops filtrados no campo Krt_inh de saída.

Para o show route PBR, a saída de comando faz a filtragem de rotas baseada em políticas.

Tabela de histórico de liberação
Versão
Descrição
21.R1
A partir da versão 21.1R1 do Junos OS, o Junos OS tem suporte para NSR (Nonstop Active Routing, roteamento ativo sem parar) para LSPs RSVP iniciados por PCE baseados em RSVP e LSPs ponto a ponto e ponto a multipoint.
21.R1
A partir da versão 21.1R1 do Junos OS, o Junos OS tem suporte para NSR (Nonstop Active Routing, roteamento ativo sem parar) para LSPs baseados em RSVP com base em PCE.
20.2R1
A partir do Junos OS Release 20.2R1, a BGP Unicast (BGP-LU) pode resolver rotas IPv4 ou IPv6 por meio de engenharia de tráfego e roteamento por segmentos (SR-TE) para famílias de endereços IPv4 e IPv6.
19.4R1
Você pode associar uma única ou uma variedade de fluxos de multicast MVPN (S,G) a um caminho comutado de rótulo (LSP) iniciado por PCE com início dinâmico de 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 de LDP.
19.1R1
A partir da versão 19.1R1 Junos OS, um recurso de verificação de confirmação é introduzido para garantir que todas as listas de segmentos que contribuem para as rotas coloridas tenham o rótulo mínimo presente para todos os hops.
19.1R1
A partir da versão 19.1R1 Junos OS, esse requisito não se aplica, pois o primeiro hop dos LSPs estáticos não-coloridos agora fornece suporte a rótulos SID, além de endereços IP. Com o suporte ao rótulo first hop, MPLS fast reroute (FRR) e multipath ponderado de custo igual é ativado para resolver os LSPs de roteamento por segmentos não-coloridos estáticos, semelhantes a LSPs estáticos coloridos.
18.2R1
A partir da versão 18.2R1 Junos OS, LSPs de roteamento por segmentos não-coloridos configurados estaticamente no dispositivo de entrada são reportados ao Elemento de Computação de Caminho (PCE) por meio de uma sessão pcep (Path Computation Element Protocol, Protocolo de Elemento de Computação de Caminho).
17.2R1
A partir da versão 17.2 do Junos OS, além de dois novos tipos de computação de caminho são introduzidos para external cspf LSPs controlados por PCE: local cspf e no cspf .
16.1
A partir da versão 16.1 do Junos OS, você pode proteger uma sessão PCEP usando autenticação TCP-MD5 de acordo com a RFC 5440.
16.1
A Versão 16.1 do Junos OS introduz o recurso de proteger uma sessão PCEP usando a autenticação TCP-MD5 de acordo com o RFC 5440.
14.2R4
A partir da versão 14.2R4 Junos OS, o suporte à largura de banda automática é fornecido para LSPs controlados por PCE.