Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração de LSP do roteamento por segmentos

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.

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 1 descreve o modo de resolução de LSP do roteamento por segmentos com base na especificação do primeiro hop.

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

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

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

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

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

A arquitetura do roteamento por segmentos permite a entrada de nós em uma rede de núcleo para orientar 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 segmento (SIDs). Essas listas de segmentos representam os caminhos na rede que você deseja que o tráfego de entrada pegue. O tráfego de entrada pode ser identificado 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 orientar o tráfego nesses caminhos de roteamento por segmentos TE no caminho do encaminhamento.

Você pode executar BFD (S-BFD) ininterrupto em LSPs de roteamento por segmentos estáticos não coloridos e de cores com resolução de rótulos de primeiro hop e usar S-BFD como um mecanismo rápido para detectar falhas de caminho e acionar a convergência global. O S-BFD requer menos alterações de estado do que o BFD requer, acelerando assim o relatório de falhas de caminho.

Dado um túnel de roteamento por segmentos com um ou vários LSPs principais e, opcionalmente, um LSP secundário, você pode habilitar o S-BFD em qualquer um desses LSPs. Se uma sessão de S-BFD for abaixo, o software atualizará a rota do túnel de roteamento por segmentos deletando os próximos hops dos LSPs com falha. Se o rótulo de primeiro hop do LSP apontam para mais de um salto imediato, o kernel continuará a enviar pacotes S-BFD se pelo menos um próximo hop estiver disponível (a detecção de falha de alcance do next-hop subjacente deve ser mais rápida do que a duração do temporizador de detecção S-BFD).

Nota:

Esse modelo é suportado para LSPs auto-traduzidos.

S-BFD no nível LSP

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

Nota:

Certifique-se de que o endereço de origem escolhido seja discutível.

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

Parâmetros S-BFD

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

  • Discriminador remoto

  • Intervalo mínimo

  • Multiplicador

  • Nenhuma opção de alerta do roteador

No S-BFD, cada socorrista pode ter vários discriminadores. Os discriminadores podem ser anunciados por IGP a outros roteadores, ou podem estar configurados estaticamente nesses roteadores. Em um iniciador, um discriminador específico é escolhido como o discriminador 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 é ativado 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 discriminador, o menor valor é considerado como mais agressivo. Da mesma forma, para a opção de alerta do roteador, se uma das configurações não tiver nenhum alerta de roteador configurado, o parâmetro S-BFD derivado não terá opção de alerta do roteador.

Limitações

  • Somente os reparos globais são suportados.

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

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

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

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 first-hop:

  • As etapas imediatamente abaixo descreverão 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 first-hop para um túnel estático de roteamento por segmentos a ser usado como caminhos principais e secundários.

    2. No roteador de entrada, você configura o túnel estático de roteamento por segmentos, com vários caminhos principais (para balanceamento de carga), ou um caminho principal e um caminho secundário (para proteção do caminho). Cada caminho principal ou secundário (LSP) refere-se a uma das listas de segmentos que você já configurou, criando rotas usando os próximos hops derivadas dos rótulos de first-hop que contribuíram com LSPs.

    3. No roteador de entrada, você habilita o balanceamento de carga por pacote para que as rotas que resolvem as rotas de entrada e a rota SID de encadernação (que todos têm rótulos de first-hop) instalam todos os caminhos ativos no Mecanismo de Encaminhamento de Pacotes. Uma sessão S-BFD em 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 responder S-BFD com um discriminador D local, criando uma sessão de ouvinte S-BFD distribuída para D em cada FPC.

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

    As etapas imediatamente abaixo descreverão 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 acompanha a sessão de S-BFD em estados de cima e para baixo.

    2. Quando o estado S-BFD passa 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 sessão-down é enviada ao daemon de roteamento (RPD), e o RPD elimina o próximo hop dos LSPs com falha na rota do túnel do roteamento por segmentos.

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

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

    1. O LSP em especial é separado da sessão S-BFD existente. Se a sessão S-BFD existente tiver pelo menos um LSP referente a ela, a sessão BFD antiga será preservada, mas os parâmetros S-BFD são reavaliados para que os valores de parâmetro agressivos entre as sessões de LSP existentes sejam selecionados. Além disso, o nome da sessão S-BFD é atualizado para o menor caso haja uma mudança. Se a sessão S-BFD antiga não tiver mais LSPs conectados a ela, essa sessão S-BFD será removida.

    2. O software tenta encontrar uma sessão BFD existente que corresponde ao valor da combinação nova label-stack+address-family; se essa combinação existir, o LSP refere-se à sessão S-BFD existente. A sessão S-BFD é reavaliada para qualquer alteração nos parâmetros ou nome da sessão, da mesma forma com as reavaliaçãos na etapa 1.

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

    Nota:

    O intervalo mínimo e o multiplicador de uma sessão S-BFD determinam o tempo de detecção de falha da sessão. O tempo de reparo depende, além disso, do tempo global de reparo.

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

Do lado do socorrista, você deve configurar o discriminador correto:

Por padrão, os alertas de roteador estão configurados para pacotes S-BFD. Quando o MPLS de dados é removido na ponta do responder, o pacote é enviado ao host para processamento sem que o pacote procure um endereço de destino. Se você habilitar a opção sem alerta do roteador no roteador de entrada, a opção de alerta do roteador será removida das opções de IP e, portanto, do lado de saída. Você deve configurar o endereço de destino explicitamente em lo0; caso contrário, o pacote é descartado e o S-BFD permanece ino mesmo.

Você pode usar um novo sinal de rastreamento bfd para rastrear atividades de BFD:

Exemplo

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

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

Propósito

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

Ação

Como muitos LSPs podem compartilhar a mesma sessão BFD, quando surge o primeiro LSP com uma combinação exclusiva de família de endereços+pilha de rótulos, o nome da sessão S-BFD usa endereço-família+nome de lsp. Se mais LSPs mais tarde compartilharem a mesma sessão, o nome da sessão pode mudar para address-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 show bfd session extensive do comando. A saída para cada LSP mostra o status S-BFD e o nome S-BFD a que se refere como 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 no nível de LSP não são exibidos.

Verificar a rota do túnel do roteamento por segmentos com um Next Hop principal e um next hop secundário

Propósito

Na Mecanismo de Roteamento do roteador de entrada, verifique a rota do túnel de roteamento por segmentos com um próximo hop principal e um próximo hop secundário.

Ação

Verificar a sessão S-BFD do caminho principal

Propósito

Na Mecanismo de Roteamento do roteador de entrada, verifique a sessão S-BFD do caminho principal.

Ação

Nota:

Na Mecanismo de Roteamento do roteador de entrada, verifique também a sessão S-BFD do caminho secundário.

Atraso de computação Caminhos de Roteamento de segmentos otimizados e intradomínios

Visão geral de métricas baseadas em atraso para caminhos projetados por 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 um PCE (Path Computation Element, Elemento de computação de caminho) computar caminhos projetados por tráfego. Você pode usar métricas baseadas em atraso para orientar pacotes nos caminhos de menor latência ou no caminho de menor atraso. Para isso, você precisa medir o atraso em todos os enlaces e anuiá-lo usando um protocolo de roteamento adequado (IGP ou BGP-LS), para que a entrada tenha as propriedades de atraso por enlace em seu TED.

Para entender como anunciar o atraso em cada enlace ou ativar as medições do enlace, consulte Como habilitar a medição e a publicidade do atraso do enlace no ISIS.

A sequência de eventos a seguir acontece quando você mede, anuncia e calcula a detecção de alterações na rede e calcula o caminho da engenharia de tráfego com a menor latência:

  • Detecte alterações na rede ao medir a latência, com sondas sintéticas, roteador para roteador.
  • Inunde os resultados para nós de entrada IGP extensões TE métricas estendidas.
  • Anunva os resultados para controladores centralizados com extensões BGP-LS correspondentes.
  • Os caminhos métricos de latência acumulada mais IGP com base em computação (Flex-algo).
  • Computação de caminhos explícitos projetados por tráfego (de origem para destino) com as menores métricas de latência acumulada ou atraso (SR-TE).

Benefícios de métricas baseadas em atraso para computação de caminho

  • Implante serviços de valor agregado com base na menor latência em toda a rede.
  • Mede por latência de caminho (mínimo, máximo, média) usando métricas baseadas em atraso.
  • Orientar serviços confidenciais de atraso (como serviços de VPN ou 5G) em caminhos otimizados para SR de latência ultrabaixa.

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

Usando o CSPF (Shortest Path First, caminho mais curto e restrito distribuído) distribuído para o recurso LSP de 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.

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

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

  • minimum— Valor métrico de atraso mínimo do TED para cálculo acumulado do caminho de menor latência.
  • average— Valor métrico de atraso médio do TED para cálculo acumulado do caminho de menor latência.
  • maximum— Valor métrico de atraso máximo do TED para cálculo acumulado do caminho de menor latência.
  • delay-variation-threshold— Limiar de variação do atraso do enlace (1.16777215). Qualquer enlace que exceda o limiar de variação de atraso seria excluído do cálculo do caminho. O limiar de variação do atraso é independente de você estar fazendo otimização para o mínimo, o máximo ou a média. A delay-variation-threshold instrução de configuração aparece nesses níveis de hierarquia:
    • [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 de CLI:

Visão geral dos casos de uso entre domínios e domínios de atraso

Para o caso intra-domínio (o caminho reside em um único domínio), o atraso do enlace é levado em consideração ao fazer a computação de caminho. As métricas de atraso para computação do caminho do roteamento por segmentos são suportadas em SIDs comprimidos e SIDs não comprimidos. Se tiver SIDs não comprimidos, segmentos de adjabilidade para listas de segmentos são usados para produzir várias listas de segmentos se houver custos iguais. Você pode configurar SIDs não comprimidos usando a instrução no-label-stack-compression de configuração no nível edit protocols source-packet-routing compute-profile profile-name [ ] da hierarquia. Isso fornece um caminho totalmente expandido usando SIDs de adjaceência. Consulte o perfil da computação para obter mais informações.

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

Nota:

Para a computação de caminho óptico, recomenda-se usar as métricas de atraso no mínimo. O mínimo é a configuração padrão.

Para um caso de uso entre domínios (multidomínio), onde existem vários sistemas autônomos, você pode usar segmentos expressos para configurar atrasos de enlace para computação de caminho. Segmentos Express são links que conectam nós de borda ou ASBRs. Consulte Express Segment LSP Configuration para saber mais sobre segmentos expressos. Você pode configurar o atraso ou herdar o atraso do LSP subjacente no segmento expresso. Você pode configurar em nível [ ] de hierarquia e definir os valores para delayedit protocols express-segments segment-template template-name metric atrasos mínimos, máximos e médios.

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

Para a computação de caminho entre domínios, você pode designar métricas de atraso em BGP links EPE. Você pode configurar um valor no delay-metric nível da hierarquia [ ] como mostrado edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute abaixo:

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

A topologia a seguir mostra um exemplo de um caso de uso óptico. Soluções de proteção óptica e restauração resultam nos atributos físicos subjacentes, principalmente o comprimento do caminho, mudando devido a falhas no enlace e à DWDM otimização da rede. Na figura A, o enlace entre A e C é por meio dos nós ópticos O1 e O3 e tem uma latência de 10 microssegundos. Na figura B, é possível ver uma falha de enlace entre nós ópticos O1 e O3 e que a conexão óptica real é reroutada pelo nó óptico O2. Isso aumenta a latência de 15 microssegundos. A métrica do enlace que conecta A e B muda dinamicamente entre tempo=0 e tempo=1.

Quando uma mudança no atraso por enlace é detectada pela entrada, a entrada aciona a recomputação do caminho otimizado para atraso e o roteador de headend reroute o caminho pelo próximo caminho de menor latência disponível. A mudança no atraso do enlace pode resultar na entrada de outro conjunto de enlaces com o caminho de menor latência. Na figura B, dá para ver que existe uma mudança no enlace entre o caminho A e C e o roteador de headend reroutes e escolhe o caminho A-B-C como mostrado na topologia.

Tabela de histórico de liberação
Versão
Descrição
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 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).