Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Configuração LSP de roteamento por segmentos

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

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

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

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

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

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

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

    Nota:

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

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

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

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

  • Endereços IPV6.

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

  • Interfaces não numeradas.

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

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

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

Algoritmo de computação CSPF distribuído

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

Compressão de pilha de rótulos habilitada

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

Desabilitação de pilha de rótulos

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

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

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

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

  • Nenhuma lista de segmentos é idêntica.

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

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

O banco de dados usado para computação SR-TE tem todos os links, nós, prefixos e suas características, independentemente de a engenharia de tráfego estar habilitada nesses nós de publicidade. Em outras palavras, é a união do banco de dados de engenharia de tráfego (TED) e do banco de dados de estado do enlace IGP de todos os domínios que o nó de computação aprendeu. Como resultado, para que o CSPF funcione, você deve incluir a declaração no nível de hierarquia.igp-topology[edit protocols isis traffic-engineering]

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

Você pode usar um perfil de computação para agrupar logicamente as restrições de computação. Esses perfis de computação são referenciados pelos caminhos de roteamento por segmentos para computação dos LSPs de roteamento por segmentos primários e secundários.

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

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

  • Administrative groups

    Você pode configurar grupos administrativos sob o nível de hierarquia.admin-groups[edit protocols mpls] O Junos OS aplica a configuração de grupo administrativo às interfaces de engenharia de tráfego de roteamento por segmentos (SR-TE).

    Para configurar as restrições de computação, você pode especificar três categorias para um conjunto de grupos administrativos. A configuração de restrição de computação pode ser comum a todos os caminhos de roteamento por segmentos de candidatos, ou pode estar nos caminhos individuais do candidato.

    • include-any— Especifica que qualquer link com pelo menos um dos grupos administrativos configurados da lista é aceitável para o caminho a percorrer.

    • include-all— Especifica que qualquer link com todos os grupos administrativos configurados da lista é aceitável para o caminho a percorrer.

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

  • Explicit path

    Você pode especificar uma série de IDs de roteador no perfil de computação como uma restrição para a computação dos caminhos do candidato SR-TE . Cada salto precisa ser um endereço IPv4 e pode ser do tipo rigoroso ou solto. Se o tipo de salto não estiver configurado, é usado rigoroso. Você deve incluir a opção na declaração da lista de segmentos ao especificar a restrição explícita do caminho.computesegment-list

  • Maximum number of segment lists (ECMP paths)

    Você pode associar um caminho de candidato a uma série de listas dinâmicas de segmentos. Os caminhos são caminhos ECMP, onde cada lista de segmentos se traduz em um gateway de salto próximo com peso ativo. Esses caminhos são resultado da computação de caminhos com ou sem compressão.

    Você pode configurar este atributo usando a opção na declaração de configuração de perfil de computação .maximum-computed-segment-lists maximum-computed-segment-listscompute-profile Essa configuração determina o número máximo dessas listas de segmentos computadas para um determinado LSP primário e secundário.

  • Maximum segment list depth

    O parâmetro máximo de computação de profundidade da lista de segmentos garante que, entre os caminhos ECMP que satisfaçam todas as outras restrições, como grupo administrativo, apenas os caminhos que têm listas de segmentos menores ou iguais à profundidade máxima da lista de segmentos são usados. Quando você configura esse parâmetro como uma restrição sob o perfil de computação, ele substitui a configuração sob o nível de hierarquia, se presente.maximum-segment-list-depth[edit protocols source-packet-routing]

    Você pode configurar este atributo usando a opção na declaração de configuração de perfil de computação .maximum-segment-list-depth maximum-segment-list-depthcompute-profile

  • Protected or unprotected adjacency SIDs

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

  • Metric type

    Você pode especificar o tipo de métrica no link a ser usado para computação. Por padrão, os LSPs SR-TE usam métricas de engenharia de tráfego dos links para computação. A métrica de engenharia de tráfego para links é anunciada por extensões de engenharia de tráfego dos protocolos IGP. No entanto, você também pode optar por usar a métrica de IGP para computação usando a configuração do tipo métrica no perfil de computação.

    Você pode configurar este atributo usando a opção na declaração de configuração de perfil de computação .metric-type (igp | te)compute-profile

Computação CSPF distribuída

Os caminhos do candidato SR-TE são computados localmente de modo que satisfaçam as restrições configuradas. Quando a compressão da pilha de rótulos é desativada, o resultado de computação CSPF multi-caminho é um conjunto de pilhas SID de adjacência. Quando a compressão da pilha de rótulos é habilitada, o resultado é um conjunto de pilhas de rótulos compactadas (compostas por SIDs adjacentes e SIDs de nós).

Quando os caminhos secundários são computados, os links, nós e SRLGs tomados pelos caminhos primários não são evitados para a computação. Para obter mais informações sobre caminhos primários e secundários, consulte Configuração de LSPs primários e secundários.Configuração de LSPs primários e secundários

Para qualquer LSPs com resultado de computação mal-sucedido, a computação é retried à medida que o banco de dados de engenharia de tráfego (TED) muda.

Interação entre a computação distribuída de CSPF e os recursos SR-TE

Pesos associados a caminhos de uma política SR-TE

Você pode configurar pesos em relação a caminhos SR-TE computados e estáticos, que contribuem para os próximos saltos da rota. No entanto, um único caminho que tenha a computação habilitada pode resultar em várias listas de segmentos. Essas listas de segmentos computados são tratadas como ECMP entre si. Você pode atribuir pesos ECMP hierárquicos a esses segmentos, considerando os pesos atribuídos a cada uma das primárias configuradas.

Detecção de linhas de vida do BFD

Você pode configurar a detecção de linhas de vida da BFD para os caminhos primários ou secundários computados. Cada caminho primário ou secundário computado pode resultar em várias listas de segmentos, como resultado, os parâmetros de BFD configurados em relação às listas de segmentos são aplicados a todas as listas de segmentos computados. Se todos os caminhos primários ativos forem trilhados, o caminho secundário pré-programado (se fornecido) ficará ativo.

nexthops herdados de rótulo

Você não é obrigado a habilitar explicitamente a configuração sob a hierarquia para os caminhos primários ou secundários computados, pois é um comportamento padrão.inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name]

Recurso de tradução automática

Você pode configurar o recurso de tradução automática nas listas de segmentos e os caminhos primários ou secundários com a referência automática de recursos dessas listas de segmentos. Por outro lado, o principal ou secundário em que o recurso de computação está habilitado não pode fazer referência a nenhuma lista de segmentos. Como resultado, você não pode habilitar tanto o recurso de computação quanto o recurso de tradução automática para um determinado caminho primário ou secundário. No entanto, você pode ter um LSP configurado com um caminho primário com tipo de computação e outro com tipo de tradução automática.

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

Exemplo 1

No exemplo 1,

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

  • Um primário computado deve ter um nome configurado, e este nome não deve fazer referência a nenhuma lista de segmentos configurada. Neste exemplo, não é uma lista de segmentos configurada.compute_segment1

  • O perfil de computação é aplicado ao caminho principal com o nome .compute_profile_redcompute_segment1

  • O perfil de computação inclui uma lista de tipos de segmentos, que é usada para especificar a restrição explícita do caminho para a computação.compute_profile_redcompute

Os pesos para o próximo salto de caminho computado e próximo salto estático são 2 e 3, respectivamente. Supondo que os próximos saltos para caminhos computados sejam , e , e o próximo salto para o caminho estático seja , os pesos são aplicados da seguinte forma:comp_nh1comp_nh2comp_nh3static_nh

Próximo salto

Peso

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Exemplo 2

No exemplo 2, tanto os caminhos primários quanto secundários podem ser do tipo de computação e podem ter seus próprios perfis de computação.

Exemplo 3

No exemplo 3, quando a computação é mencionada em um caminho primário ou secundário, ela resulta na computação local de um caminho até o destino sem quaisquer restrições ou outros parâmetros para a computação.

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

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

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

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

Introdução aos LSPs de roteamento por segmentos

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

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

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

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

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

Por exemplo:

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

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

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

Benefícios do uso de LSPs de roteamento por segmentos

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

  • Ofereça maior escalabilidade às redes MPLS.

LSP de roteamento por segmentos estáticos coloridos

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

Entendendo os LSPs de roteamento por segmentos estáticos coloridos

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

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

Lista de segmentos de LSPs de roteamento por segmentos coloridos

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

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

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

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

Entendendo os LSPs de roteamento por segmentos não coloridos

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

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

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

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

Nota:

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

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

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

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

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

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

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

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

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

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

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

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

Especificação do primeiro salto

Modo de resolução de LSP

Somente endereço IP

Por exemplo:

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

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

Apenas SID

Por exemplo:

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

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

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

Por exemplo:

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

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

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

Por exemplo:

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

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

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

Por exemplo:

Nota:

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

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

    Por exemplo:

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

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

    Por exemplo:

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

Provisionamento LSP de roteamento por segmentos estático

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LSPs coloridos de roteamento dinâmico por segmentos

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

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

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

  2. BGP prefix to tunnel mapping:

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

  3. inetcolor.0 tunnel route:

    10.22.44.55-101/64 --> &lt;next-hop>

    10.22.44.55-124/64 --> &lt;next-hop>

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

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

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

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

  2. BGP prefix to tunnel mapping:

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

  3. inet.3 tunnel route: 10.33.44.55/32 -- > &lt;next-hop>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • VPN de Camada 3

  • BGP EVPN

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

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

  • VPN de Camada 3

  • VPN de Camada 2

  • Configurações multicaminho

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

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

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

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

  • Túneis de roteamento por segmentos IPv6.

  • Túneis estáticos.

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

  • CSPF distribuído.

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

  • Instale e rotas B-SID em um modelo.

Mapeamento baseado em cores de serviços VPN

Você pode especificar a cor como uma restrição de próximo salto de protocolo (além do endereço IPv4 ou IPv6) para a resolução de túneis de transporte em LSPs de roteamento por segmentos estáticos e BGP projetados para tráfego (SR-TE). Isso é chamado de resolução de próximo salto do protocolo IP colorido, onde você é obrigado a configurar um mapa de resolução e aplicar-se aos serviços de VPN. Com esse recurso, você pode habilitar o direcionamento de tráfego baseado em cores de serviços VPN de Camada 2 e Camada 3.

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

Coloração de serviços VPN

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

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

  • Por instância de roteamento.

  • De acordo com o grupo BGP.

  • De acordo com o vizinho BGP.

  • Por prefixo.

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

Você pode atribuir várias cores a um serviço VPN, chamado de serviços VPN multicoloridos. Nesses casos, a última cor anexada é considerada como a cor do serviço vpn, e todas as outras cores são ignoradas.

Várias cores são atribuídas por dispositivos de saída e/ou entrada por várias políticas na ordem a seguir:

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

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

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

Os dois modos de coloração de serviços VPN são:

Atribuição de cores de saída

Nesse modo, o dispositivo de saída (ou seja, o anunciante da VPN NLRI) é responsável por colorir o serviço VPN. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la na instância de roteamento do serviço VPN, na exportação de grupos ou na exportação de vizinhos do grupo no nível hierárquico.vrf-export[edit protocols bgp] A VPN NLRI é anunciada pelo BGP com a comunidade estendida de cores especificada.

Por exemplo:

Ou

Nota:

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

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

Atribuição de cores de entrada

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

Por exemplo:

Ou

Especificando o modo de mapeamento de serviços VPN

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

Por exemplo:

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

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

Nota:

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

Resolução next hop do protocolo IP de cores

O processo de resolução de próximo salto de protocolo é aprimorado para oferecer suporte à resolução do próximo salto do protocolo IP colorido. Para um serviço VPN colorido, o processo de resolução do próximo salto de protocolo leva uma cor e um mapa de resolução, cria um protocolo IP colorido no próximo salto na forma de , e resolve o protocolo próximo salto na tabela de roteamento inet6color.0.IP-address:color

Você deve configurar uma política para oferecer suporte à resolução multicaminho de VPN de Camada 2 colorida, VPN de Camada 3 ou serviços EVPN em LSPs coloridos. A política deve então ser aplicada com a tabela RIB relevante conforme a política de importação de resolver.

Por exemplo:

Revés à resolução next hop do protocolo IP

Se um serviço VPN colorido não tiver um mapa de resolução aplicado a ele, o serviço de VPN ignora sua cor e volta ao protocolo IP de resolução de próximo salto. Por outro lado, se um serviço de VPN não colorido tiver um mapa de resolução aplicado a ele, o mapa de resolução é ignorado e o serviço vpn usa o protocolo IP de resolução de próximo salto.

O fallback é um processo simples, desde LSPs SR-TE coloridos até LSPs LDP, usando um grupo RIB para LDP para instalar rotas em tabelas de roteamento inet{6}color.0. Uma combinação de prefixo mais longa para um próximo salto de protocolo IP colorido garante que, se uma rota SR-TE LSP colorida não existir, uma rota LDP com um endereço IP correspondente deve ser devolvida.

Mapeamento baseado em cores unicast rotulado do BGP sobre SR-TE

A partir do Junos OS Release 20.2R1, o BGP Labeled Unicast (BGP-LU) pode resolver rotas IPv4 ou IPv6 por roteamento por segmentos — engenharia de tráfego (SR-TE) para famílias de endereços IPv4 e IPv6. O BGP-LU oferece suporte para mapear a cor da comunidade BGP e definir um para SR-TE.resolution map Um protocolo colorido próximo salto é construído e é resolvido em um túnel SR-TE colorido na ou mesa.inetcolor.0inet6color.0 O BGP usa e tabelas para mapeamento não colorido.inet.3inet6.3 Isso permite que você anuncie prefixos BGP-LU IPv6 e IPv4 com um endereço IPv6 de próximo salto em redes somente IPv6, onde os roteadores não têm nenhum endereço IPv4 configurado. Com esse recurso, atualmente oferecemos suporte ao BGP IPv6 LU sobre SR-TE com underlay IS-IS.

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

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

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

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

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

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

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

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

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

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

Recursos suportados e sem suporte para mapeamento baseado em cores de serviços VPN

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

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

  • BGP EVPN

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

  • Resolução de próximo salto do protocolo IPv4 e IPv6 colorido.

  • Base de informações de roteamento (também conhecida como tabela de roteamento) com base em fallback para LDP LSP na tabela de roteamento inetcolor.0.

  • LSP SR-TE colorido.

  • Plataformas virtuais.

  • Junos OS de 64 bits.

  • Sistemas lógicos.

  • BGP rotulado de unicast.

Os recursos e funcionalidades a seguir não são suportados com mapeamento baseado em cores dos serviços de VPN:

  • LSPs MPLS coloridos, como RSVP, LDP, BGP-LU, estáticos.

  • Circuito de camada 2

  • FEC-129 BGP auto-descoberta e VPN de Camada 2 sinalizada por LDP.

  • VPLS

  • MVPN

  • IPv4 e IPv6 usando mapa de resolução.

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

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

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

Para configurar um modelo:

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

  2. Inclua a declaração de mapa-modelo de caminho de roteamento de origem no nível de hierarquia para listar as declarações de política contra as quais o LSP iniciado pelo PCE deve ser verificado.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/source-routing-path-template-map-edit-protocols-source-packet-routing.html[edit protocols source-packet-routing]

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

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

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

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

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

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

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

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

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

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

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

  • Junos OS Release 18.1 ou posterior em todos os roteadores

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

Visão geral

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

Topologia

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

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

Configuração

Configuração rápida da CLI

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuração do dispositivo PE1
Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar o dispositivo PE1:

  1. Configure as interfaces.

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

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

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

  5. Configure as interfaces de área de protocolo.

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

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

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

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

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

Resultados

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

Configuração do dispositivo PE2
Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

  1. Configure as interfaces.

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

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

  4. Configure interfaces para OSPF de protocolo.

Resultados

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

Verificação

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

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

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

Ação

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

Significado

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

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

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

Ação

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

Significado

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

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

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

Ação

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

Significado

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

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

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

Ação

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

Significado

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

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

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

Ação

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

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

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

Ação

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

Significado

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

S-BFD baseado em mecanismos de roteamento para engenharia de tráfego de roteamento por segmentos com resolução de rótulos first-hop

Você pode executar a detecção perfeita de encaminhamento bidirecional (S-BFD) em caminhos não coloridos e coloridos comutada por rótulos (LSPs) com resolução de rótulos de primeiro salto, usando o S-BFD como um mecanismo rápido para detectar falhas de caminho.

Entendendo a S-BFD baseada em RE para engenharia de tráfego de roteamento por segmentos com resolução de rótulos first-hop

Túneis estáticos de roteamento por segmentos S-BFD para rótulos de primeiro salto

A arquitetura de roteamento por segmentos permite que nós de entrada em uma rede central guiem o tráfego por caminhos explícitos pela rede. O próximo salto da engenharia de tráfego de roteamento por segmentos (TE) é uma lista ou lista de identificadores de segmentos (SIDs). Essas listas de segmentos representam caminhos na rede que você deseja que o tráfego de entrada tome. O tráfego de entrada pode ser rotulado ou tráfego IP e a operação de encaminhamento no nó de entrada pode ser uma troca de rótulos ou uma busca baseada em destino para direcionar o tráfego para esses caminhos TE de roteamento por segmentos no caminho de encaminhamento.

Você pode executar BFD (S-BFD) perfeito em LSPs estáticos não coloridos e coloridos com resolução de rótulos de primeiro salto e usar o S-BFD como um mecanismo rápido para detectar falhas de caminho e desencadear a convergência global. A S-BFD requer menos mudanças de estado do que a BFD exige, acelerando assim os relatórios de falhas de caminho.

Dado um túnel de roteamento por segmentos com um ou vários LSPs primários e opcionalmente um LSP secundário, você pode habilitar o S-BFD em qualquer um desses LSPs. Se uma sessão de S-BFD cair, o software atualiza a rota do túnel de roteamento por segmentos excluindo os próximos saltos dos LSPs com falha. Se o rótulo de primeiro salto do LSP aponta para mais de um salto imediato, o kernel continua a enviar pacotes S-BFD se pelo menos um próximo salto estiver disponível (a detecção de falha de acessibilidade no próximo salto deve ser mais rápida do que a duração do temporização de detecção de S-BFD).

Nota:

Esse modelo é compatível com LSPs derivados de tradução automática.
S-BFD no nível de LSP

Uma sessão S-BFD é criada para cada combinação exclusiva de família de rótulos+endereços. Você pode configurar listas de segmentos idênticas e habilitar o S-BFD para todos eles. As listas de segmentos que têm combinações idênticas de pilha de rótulos+família de endereços compartilham a mesma sessão de S-BFD. O endereço fonte da sessão S-BFD está definido para o endereço de loopback menos configurado (exceto os endereços especiais) na instância principal.

Nota:

Garanta que o endereço de origem escolhido seja roteável.

A família de endereços de um LSP é derivada com base na família de endereços do endereço "a" no túnel TE de roteamento por segmentos. O estado do LSP com S-BFD configurado também depende se a BFD está ativa — se o S-BFD estiver configurado para um LSP, a rota LSP não é calculada até que a S-BFD informe que o caminho está vivo.

Parâmetros de S-BFD

Os seguintes parâmetros S-BFD são suportados para caminhos TE de roteamento por segmentos:

  • Discriminação remota

  • Intervalo mínimo

  • Multiplicador

  • Sem opção de alerta de roteador

No S-BFD, cada respondente pode ter vários discriminatórios. Os discriminatórios podem ser anunciados pelo IGP para outros roteadores, ou podem ser configurados estaticamente nesses roteadores. Em um iniciador, um discriminatório em particular é escolhido como discriminatório remoto para uma sessão S-BFD por configuração estática, com base na decisão ou resolução feita por você ou por um controlador central. Quando vários LSPs são criados com a mesma pilha de rótulos chave e o S-BFD é habilitado em cada um deles com parâmetros diferentes, o valor agressivo de cada parâmetro é usado na sessão S-BFD compartilhada. Para o parâmetro discriminatório, o menor valor é considerado mais agressivo. Da mesma forma para a opção de alerta do roteador, se uma das configurações nenhum alerta de roteador estiver configurado, o parâmetro S-BFD derivado não terá opção de alerta de roteador.

Limitações

  • Apenas o reparo global é suportado.

  • Embora a S-BFD detecte falhas dependendo dos valores configurados do temporizador, o tempo de convergência depende do tempo de reparo global ().seconds

Derivação automática de discriminação remota (RD) para sessão SBFD

A partir do Junos OS Release 22.4R1, você pode usar o discriminatório remoto derivado automático para sessões de SBFD para os caminhos SR-TE. Com este recurso, você não precisa configurar uma configuração SFBD na entrada ou dispositivo de trânsito e uma discriminação local correspondente em seu respectivo endpoint.remote-discriminator Em vez disso, o dispositivo pe de saída agora aceitará endereços IP como seu discriminatório local. Para permitir que o endereço IP seja discriminatório local em BFD, use a configuração.set protocols bfd sbfd local-discriminator-ip

Você também pode usar um modelo SBFD comum com as configurações SBFD em políticas SR-TE provisionadas por vários controladores. Nessas sessões de SBFD, o Junos OS deriva automaticamente do discriminatório remoto do endpoint do túnel para combinar políticas SR-TE.

Nota:

  • Oferecemos suporte à derivação automática de RD apenas para endpoints IPv4, não para endpoints IPv6.

  • Não oferecemos suporte a derivação automática de RD para túneis somente para cores. Se o RD não estiver configurado (por derivação automática de RD) para túneis somente coloridos SR-TE configurados estaticamente, o sistema exibirá um erro de confirmação. Se o RD não estiver configurado (por derivação automática de RD) para túneis dinâmicos somente de cores usando a configuração de modelo SR-TE, o Junos OS ignora a configuração ofuscada para esse túnel.

Configuração de S-BFD baseada em RE para engenharia de tráfego de roteamento por segmentos com resolução de rótulos first-hop

Para habilitar o S-BFD de nível LSP para uma lista de segmentos, você configura a declaração de configuração na hierarquia e na hierarquia.bfd-liveness-detection [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name]

As etapas a seguir dão a configuração básica e, em seguida, a operação do S-BFD com resolução de rótulos de primeiro salto:

  • As etapas imediatamente abaixo descrevem os contornos da configuração básica:

    1. Em um roteador de entrada, você configura uma ou mais listas de segmentos com rótulos de primeiro salto para um túnel estático de roteamento por segmentos a ser usado como caminhos primários e secundários.

    2. No roteador de entrada, você configura o túnel estático de roteamento por segmentos, com vários caminhos primários (para balanceamento de carga) ou um caminho primário e um caminho secundário (para proteção de caminho). Cada caminho primário ou secundário (LSP) refere-se a uma das listas de segmentos que você já configurou, criando rotas usando os próximos saltos derivados dos rótulos de primeiro salto dos LSPs contribuintes.

    3. No roteador de entrada, você permite o balanceamento de carga por pacote para que as rotas que resolvem rotas de entrada e a rota de encadernação-SID (que todas têm rótulos de primeiro salto) instalem todos os caminhos ativos no Mecanismo de encaminhamento de pacotes. Uma sessão S-BFD sob um LSP protege todas as rotas que usam esse LSP.

    4. No roteador de saída do túnel de roteamento por segmentos, você configura o modo S-BFD responder com um D discriminatório local, criando uma sessão distribuída de escuta S-BFD para D em cada FPC.

    5. No roteador de entrada, você configura o S-BFD para qualquer LSP para o qual você deseja ver a detecção de falha de caminho. Você especifica um D discriminatório remoto para combinar com o discriminatório local de S-BFD do roteador de saída. Uma sessão de iniciação S-BFD é criada com a combinação LSP label-stack+address-family como a chave, se uma sessão de iniciação ainda não existir para a chave LSP atual. Os parâmetros S-BFD no caso de uma sessão de BFD correspondente são reavaliados com os novos LSPs compartilhados levados em consideração. Quando os parâmetros S-BFD são derivados, o valor agressivo de cada parâmetro é escolhido.

    As etapas imediatamente abaixo descrevem a operação básica:

    1. A sessão de iniciação S-BFD é executado em um modo centralizado no Mecanismo de Roteamento. O software rastreia a sessão S-BFD para cima e para baixo em estados.

    2. Quando o estado S-BFD se move para UP, o LSP é considerado para as rotas relevantes.

    3. No roteador de entrada, se o software detectar uma sessão S-BFD DOWN, uma notificação de baixa sessão é enviada para o daemon de roteamento (RPD), e o RPD apaga o próximo salto dos LSPs com falha na rota do túnel de roteamento por segmentos.

    4. A perda total de tráfego no procedimento está vinculada ao tempo de detecção de falhas S-BFD e ao tempo de reparo global. O tempo de detecção de falha do S-BFD é determinado pelos parâmetros de intervalo mínimo e multiplicador S-BFD. O tempo de reparo global depende do tempo de processo de TE de roteamento por segmentos e da reescarga das rotas para o encaminhamento.

    As pilhas de rótulo LSP são alteradas da seguinte forma:

    1. O LSP em particular está desvinculado da sessão S-BFD existente. Se a sessão S-BFD existente tiver pelo menos um LSP referente a ela, a sessão de BFD antiga será preservada, mas os parâmetros S-BFD são reavaliados para que os valores agressivos dos parâmetros entre as sessões LSP existentes sejam escolhidos. Além disso, o nome da sessão S-BFD é atualizado para o mínimo se houver uma mudança. Se a sessão S-BFD antiga não tiver mais LSPs ligados a ela, essa sessão de S-BFD será removida.

    2. O software tenta encontrar uma sessão de BFD existente que corresponda ao valor de combinação da família de endereços+label-stack+; se tal correspondência existir, o LSP refere-se à sessão S-BFD existente. A sessão S-BFD é reavaliada para qualquer mudança nos parâmetros ou nome da sessão de forma semelhante às reavaliações da etapa 1.

    3. Se não houver uma sessão de BFD correspondente no sistema, uma nova sessão de BFD será criada e os parâmetros S-BFD são derivados deste LSP.

    Nota:

    O intervalo e o multiplicador mínimos de uma sessão S-BFD determinam o tempo de detecção de falhas para a sessão. O tempo de reparo também depende do tempo de reparo global.

A saída a seguir mostra declarações de configuração que você usaria para um LSP colorido com LSPs primários:

No lado do respondente, você deve configurar o discriminatório correto:

Por padrão, os alertas do roteador são configurados para pacotes S-BFD. Quando o cabeçalho MPLS é removido no final do respondente, o pacote é enviado ao host para processamento sem uma busca de endereço de destino para o pacote. Se você habilitar a opção sem alerta de roteador no roteador de entrada, a opção de alerta de roteador é removida das opções de IP e, portanto, do lado da saída. Você deve configurar o endereço de destino explicitamente no lo0; caso contrário, o pacote é descartado, e o S-BFD permanece desativado.

Você pode usar uma nova bandeira de rastreamento para rastrear atividades de BFD:bfd

Exemplo

A configuração a seguir é um exemplo de um túnel de roteamento por segmentos estático não colorido com proteção LSP.

Verifique se os LSPs estão configurados para túneis estáticos de roteamento por segmentos e que o status da sessão S-BFD é visível

Propósito

Use o comando para mostrar LSPs para túneis estáticos de roteamento por segmentos, com status de sessão S-BFD.how spring-traffic-engineering lsp detail

Ação

Como muitos LSPs podem compartilhar a mesma sessão de BFD, quando o primeiro LSP com uma combinação exclusiva de label-stack+família de endereços aparece, o nome da sessão S-BFD usa endereço-família+lsp-name. Se mais LSPs compartilharem a mesma sessão mais tarde, o nome da sessão pode mudar para endereço-family+least-lsp-name, sem afetar o estado da sessão S-BFD. O nome da sessão S-BFD também aparece na saída do comando.show bfd session extensive A saída para cada LSP mostra o status de S-BFD, bem como o nome S-BFD a que se refere, conforme mostrado no exemplo anterior como .BFD status: Up BFD name: V4-sl2 Como pode não haver uma sessão S-BFD por LSP, os contadores S-BFD de nível LSP não são exibidos.

Verifique a rota do túnel de roteamento por segmentos com um próximo salto primário e um próximo salto secundário

Propósito

No mecanismo de roteamento do roteador de entrada, verifique a rota do túnel de roteamento por segmentos com um próximo salto primário e um próximo salto secundário.

Ação

Verifique a sessão S-BFD do caminho primário

Propósito

No mecanismo de roteamento do roteador de entrada, verifique a sessão S-BFD do caminho principal.

Ação

Nota:

No mecanismo de roteamento do roteador de entrada, verifique a sessão S-BFD do caminho secundário também de maneira semelhante.

Atraso na computação Otimizado caminhos de roteamento por segmentos entre domínios e intradomain

Visão geral das métricas baseadas em atraso para caminhos projetados de tráfego

Aproveitar métricas dinâmicas baseadas em atraso está se tornando um atributo desejável nas redes modernas. Métricas baseadas em atraso são essenciais para que um elemento de computação de caminho (PCE) compute caminhos projetados para o tráfego. Você pode usar métricas baseadas em atraso para direcionar pacotes nos caminhos de menor latência ou no caminho de menor atraso. Para isso, você precisa medir o atraso em cada link e anunciá-lo usando um protocolo de roteamento adequado (IGP ou BGP-LS), para que a entrada tenha as propriedades de atraso por link em seu TED.

Para entender como anunciar o atraso em cada link ou ativar medições de link, veja como habilitar a medição de atraso do link e a publicidade no ISIS.

A sequência de eventos a seguir acontece quando você mede, anuncia e computa a detecção de mudanças na rede e calcula o caminho projetado de tráfego com latência mais curta:

  • Detecte mudanças na rede medindo a latência, com sondas sintéticas, roteador para roteador.
  • Inunde os resultados para nós de entrada por meio de extensões métricas de TE estendidas por IGP.
  • Anuncie os resultados para controladores centralizados com extensões BGP-LS correspondentes.
  • Computação baseada em IGP caminhos métricas de latência cumulativos mais curtos (Flex-algo).
  • Compute caminhos explícitos projetados por tráfego (fonte a destino) com menor latência acumulada ou métricas de atraso (SR-TE).

Benefícios das métricas baseadas em atraso para a computação de caminhos

  • Implante serviços de valor agregado com base na menor latência em toda a rede.
  • Meça a latência por caminho (mínimo, máximo, médio) usando métricas baseadas em atraso.
  • Guie serviços sensíveis a atraso (como VPN ou serviços 5G) em caminhos otimizados para SR de latência ultraba baixa.

Computação baseada em DCSPF com métricas de atraso para visão geral do caminho SR

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

Você pode configurar o CSFP distribuído para ser executado em vários headends e fazer a computação de caminho de forma independente em cada headend. Você pode aplicar o perfil de computação no caminho de origem (caminho de roteamento de pacotes de origem). Se você tiver o perfil de computação configurado otimizado para a média de atraso, você também pode aplicar também uma restrição chamada .delay-variation-threshold Quando você configura um valor para , qualquer link que exceda o valor limite seria excluído da computação de caminhos.delay-variation-threshold

Para configurar métricas de atraso para computação baseada em DCSPF para o caminho SR, você precisa habilitar a declaração de configuração no nível [] de hierarquia.delayedit protocols source-packet-routing compute-profile profile-name metric-type delay Você pode configurar as métricas de atraso, como limite mínimo, máximo, médio e de variação de atraso para cálculo do caminho.

  • minimum— Valor mínimo de métrica de atraso do TED para cálculo de caminho de latência mais baixo cumulativo.
  • average— Valor médio da métrica de atraso do TED para cálculo de caminho de latência mais baixo cumulativo.
  • maximum— Valor máximo da métrica de atraso do TED para cálculo de caminho de latência mais baixo cumulativo.
  • delay-variation-threshold— Limite de variação de atraso do enlace (1,16777215). Qualquer link que excedesse o limite de variação de atraso seria excluído do cálculo do caminho. O limite de variação de atraso é independente de você estar fazendo otimização para o mínimo, máximo ou médio. A declaração de configuração aparece nesses níveis de hierarquia:delay-variation-threshold

    • []edit protocols source-packet-routing compute-profile profile-name metric-type delay

    • []edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum

    • []edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum

    • []edit protocols source-packet-routing compute-profile profile-name metric-type delay average

Você pode configurar métricas de atraso na seguinte hierarquia CLI:

Métricas de atraso para visão geral do caso de uso entre domínios e intradomínio

Para o caso de domínio intra (o caminho reside em um único domínio), o atraso no link é levado em consideração ao fazer a computação de caminhos. As métricas de atraso para computação de caminhos de roteamento por segmentos são suportadas em SIDs comprimidos e SIDs não compactados. Se você tem SIDs não compactados, então segmentos de adjacência para listas de segmentos são usados para produzir várias listas de segmentos se houver custos iguais. Você pode configurar SIDs não compactados usando a declaração de configuração no nível [] de hierarquia.no-label-stack-compressionedit protocols source-packet-routing compute-profile profile-name Isso oferece um caminho totalmente expandido usando SIDs de adjacência. Consulte o perfil de computação para obter mais informações.https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/statement/compute-profile-edit-protocols-source-packet-routing.html

A seguir, uma configuração de amostra para métricas de atraso:

Nota:

Para computação de caminhos ópticos, é recomendável usar as métricas de atraso como mínimo. O mínimo é a configuração padrão.

Para o caso de uso de interdomain (multi-domínio), onde existem vários sistemas autônomos, você pode usar segmentos expressos para configurar atrasos de enlaces para computação de caminhos. Segmentos express são links que conectam nós de borda ou ASBRs. Consulte a configuração LSP do segmento Express para saber mais sobre segmentos expressos.https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/express-segment-lsp-configuration.html Você pode configurar o atraso ou herdar o atraso do LSP subjacente no segmento expresso. Você pode configurar no nível [] de hierarquia e definir os valores para atrasos mínimos, máximos e médios.delayedit protocols express-segments segment-template template-name metric

Você pode configurar métricas de atraso em um segmento expresso na seguinte hierarquia CLI:

Para computação de caminhos de interdomain, você pode atribuir métricas de atraso em links BGP EPE. Você pode configurar um valor para o nível [] de hierarquia, conforme mostrado abaixo:delay-metricedit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute

Métricas de atraso no caso de uso de redes ópticas

As topologias a seguir retratam um exemplo de um caso de uso óptico. As soluções de proteção óptica e restauração resultam em atributos físicos subjacentes, principalmente o comprimento do caminho, mudando devido a falhas de enlace e posterior otimização de rede DWDM.

Na figura, a ligação entre A e C é através dos nós ópticos O1 e O3 e tem uma latência de 10 microssegundos.#id_yvq_j4d_xrb__d296e234 Na figura, você pode ver uma falha de ligação entre nós ópticos O1 e O3 e que a conexão óptica real é redirecionada através do nó óptico O2.#id_yvq_j4d_xrb__d296e237 Isso aumenta a latência de 15 microssegundos. A métrica do link que conecta A e B muda dinamicamente entre o tempo=0 e o tempo=1.

Quando uma mudança no atraso por link é detectada pela entrada, a entrada desencadeia a recomputação do caminho otimizado para atrasos e o roteador headend redireciona o caminho pelo próximo caminho de latência menor disponível. A mudança no atraso do enlace pode resultar na entrada da escolha de outro conjunto de links que tenha o caminho de menor latência. Na figura B, você pode ver que há uma mudança no enlace entre o caminho A e C e o roteador headend redireciona e seleciona o caminho A-B-C conforme mostrado na topologia.

Tópicos relacionados

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
20.2R1
A partir do Junos OS Release 20.2R1, o BGP Labeled Unicast (BGP-LU) pode resolver rotas IPv4 ou IPv6 por roteamento por segmentos — engenharia de tráfego (SR-TE) para famílias de endereços IPv4 e IPv6.
19.4R1
Você pode configurar um modelo de túnel para LSPs de roteamento por segmentos iniciados por PCE para repassar dois parâmetros adicionais para esses LSPs — detecção bidirecional de encaminhamento (BFD) e tunelamento LDP.
19.1R1
A partir do Junos OS Release 19.1R1, um recurso de verificação de confirmação é introduzido para garantir que todas as listas de segmentos que contribuam para as rotas coloridas tenham o rótulo mínimo presente para todos os saltos.
19.1R1
A partir do Junos OS Release 19.1R1, esse requisito não se aplica, pois o primeiro salto dos LSPs estáticos não coloridos agora oferece suporte para rótulos SID, além de endereços IP. Com o suporte do selo de primeiro salto, o mpLS de redirecionamento rápido (FRR) e multicaminho ponderado de igual custo é habilitado para resolver os LSPs de roteamento de segmentos estáticos não coloridos, semelhantes aos LSPs estáticos coloridos.
18.2R1
A partir do Junos OS Release 18.2R1, LSPs de roteamento de segmentos não coloridos configurados na entrada do dispositivo são relatados ao Elemento de computação de caminho (PCE) por meio de uma sessão de protocolo de elementos de computação de caminho (PCEP).