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 configuradas. Com esse recurso, os LSPs são otimizados com base nas restrições configuradas e no tipo métrica (engenharia de tráfego ou IGP). Os LSPs são computados para utilizar os caminhos ECMP disponíveis até 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 de CSPF

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

O recurso de computação CSPF distribuído oferece suporte ao seguinte subconjunto de restrições especificado no draft 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 de salto soltos ou rigorosos.

    Nota:

    Você pode especificar apenas IDs de roteador nas restrições de salto soltas ou rigorosas. Rótulos e outros endereços IP não podem ser especificados como restrições de hop soltas ou rigorosas 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 candidatos.

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 inter domínio (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.

Habilitado para compressão de pilhas de rótulos

Uma pilha de rótulos comprimido representa um conjunto de caminhos de uma fonte até um destino. Geralmente consiste em SIDs de nó 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.

Compressão de pilha de rótulos desabilitada

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

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

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

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

  • Nenhuma lista de segmentos é idêntica.

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

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

O banco de dados usado para computação SR-TE tem todos os links, nós, prefixos e suas características, independentemente de a engenharia de tráfego ser 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 de enlace IGP de todos os domínios que o nó de computação aprendeu. Como resultado, para que o CSPF funcione, você deve incluir a igp-topology declaração no nível de [edit protocols isis traffic-engineering] hierarquia.

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

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

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

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

  • Administrative groups

    Você pode configurar grupos administrativos sob o nível de [edit protocols mpls] hierarquia. O Junos OS aplica a configuração do 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 em caminhos individuais de candidatos.

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

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

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

  • 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 dos candidatos ao SR-TE . Cada hop precisa ser um endereço IPv4 e pode ser do tipo rigoroso ou solto. Se o tipo de hop não estiver configurado, é usado rigoroso. Você deve incluir a opção compute na declaração da lista de segmentos ao especificar a restrição de caminho explícita.

  • Maximum number of segment lists (ECMP paths)

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

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

  • Maximum segment list depth

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

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

  • Protected or unprotected adjacency SIDs

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

  • Metric type

    Você pode especificar o tipo de métrica no link a ser usado para computação. Por padrão, os LSPs SR-TE usam métricas de engenharia de tráfego dos links para computação. A métrica de engenharia de tráfego para links é anunciada por extensões de engenharia de tráfego de protocolos de 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 esse atributo usando a opção metric-type (igp | te) na declaração de configuração de perfil de computação .

Computação CSPF distribuída

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

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

Para quaisquer LSPs com resultado de computação mal-sucedido, a computação é revarinada com alterações no banco de dados de engenharia de tráfego (TED).

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

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

Você pode configurar pesos em relação a caminhos de SR-TE computados e estáticos, que contribuem para os próximos saltos da rota. No entanto, 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 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 da BFD

Você pode configurar a detecção de linhas de vida 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 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 seguirem, o caminho secundário pré-programado (se fornecido) se tornar ativo.

herdou-label-nexthops

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

Recurso de tradução automática

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

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

Exemplo 1

No exemplo 1,

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

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

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

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

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

Next-Hop

Peso

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Exemplo 2

No exemplo 2, os caminhos primários e secundários podem ser do tipo 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 comutador de rótulos de roteamento por segmentos estático

A arquitetura de roteamento por segmentos permite que os dispositivos de entrada em uma rede principal 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 LSP de roteamento por segmentos estático nas redes MPLS

O 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 por 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 seguir.

Introdução aos LSPs de roteamento por segmentos

O roteamento por segmentos aproveita o paradigma de roteamento de origem. Um dispositivo orienta um pacote através de uma lista ordenada de instruções, chamada segmentos. Um segmento pode representar qualquer instrução, topologia ou serviço baseado. Um segmento pode ter uma semântica local 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 é retirado 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 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 dinâmico 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 como LSPs coloridos e não coloridos com base na configuração da color declaração no nível de [edit protocols source-packet-routing source-routing-path lsp-name] 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 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 nos roteadores de trânsito. Assim, eliminando a necessidade de provisionamento e manutenção por estado de encaminhamento de LSP no núcleo.

  • Ofereça maior escalabilidade às redes MPLS.

LSP de roteamento por segmentos estáticos coloridos

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

Entender LSPs de roteamento por segmentos estáticos coloridos

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

Um LSP de roteamento por segmentos de cor estática pode ter um SID de ligação, para o mpls.0 qual uma rota é instalada na tabela de roteamento. Este rótulo SID vinculante é usado para mapear o tráfego rotulado para o LSP de roteamento por segmentos. Os gateways da rota são derivados das configurações da lista de segmentos nos caminhos principal 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 first hop label de resolução de um LSP. No entanto, o modo IP first hop não é suportado para LSPs de roteamento por segmentos coloridos. A partir do Junos OS Release 19.1R1, um recurso de verificação de compromisso é 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. Se esse requisito não for atendido, o compromisso será bloqueado.

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

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

O Junos OS oferece suporte a LSPs de roteamento estático não coloridos em roteadores de entrada. Você pode provisionar LSP de roteamento estático não colorido 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 colorido tem um nome exclusivo e um endereço IP de destino. Uma rota de ingresso 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 ingresso, a rota de entrada pode ser desabilitada. Um LSP de roteamento por segmentos não colorido usa rótulo SID de ligação para alcançar pontos LSP de roteamento por segmentos. Esse 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 maneira 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 por segmentos não coloridos configurados no dispositivo de entrada 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 esse rótulo SID vinculante na pilha de rótulos para provisionar caminhos LSP iniciados por segmentos iniciados por PCE.

Um LSP de roteamento por segmentos não colorido pode ter um máximo de 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 pelos 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 a falha de 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 [edit protocols source-packet-routing source-routing-path lsp-name] para suas rotas de entrada e encadernação de SID. Vários LSPs de roteamento por segmentos não coloridos têm o mesmo endereço de destino que contribui para o próximo salto da rota de entrada.

Vários LSPs de roteamento por segmentos não coloridos têm o mesmo endereço de destino que contribui para o próximo salto da rota de entrada. Cada caminho ,principal ou secundário, de cada LSP de roteamento por segmentos é considerado como um candidato de gateway, se o caminho for 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 next-hop pode reter 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, em seguida, 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. Nesse caso, existem vários gateways, cada um com um ID de túnel LSP exclusivo de roteamento por segmentos. Esses gateways são distintos, embora tenham uma interface e pilha de rótulos 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, pois o roteamento por segmentos coloridos do endereço de destino do LSP é 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 um LSP de roteamento por segmentos criado por PCEP coexistam e têm o mesmo que abordar 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 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 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. Um máximo de 128 caminhos primários são suportados por LSP de roteamento por segmentos estáticos. Você pode configurar o limite máximo da lista de segmentos no nível de [edit protocols source-packet-routing] hierarquia.

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

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

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

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

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

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

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

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

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

Especificação do First Hop

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.

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 é resolvida usando rótulos SID.

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

Por exemplo:

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

Por padrão, a lista de segmentos é resolvida usando endereço IP.

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

Por exemplo:

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

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

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

Por exemplo:

Nota:

O primeiro tipo de lista de segmentos de um LSP estático de roteamento por segmentos pode fazer com que um compromisso falhe, 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á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 no primeiro tipo de resolução hop no momento da computação do caminho.

    Por exemplo:

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

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

    Por exemplo:

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

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 de identificador de serviço exclusivo (SID) é alocado em um pool de rótulos desejado que pode ser do pool de rótulos dinâmico para um rótulo SID de adjacência ou do bloco global de roteamento por segmentos (SRGB) para um SID 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 de rótulos estático local (SRLB). Uma rota para o rótulo SID é então instalada na tabela mpls.0.

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

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

  • Atualmente, o Junos OS tem uma limitação de que o próximo 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 (excluindo o rótulo SID do primeiro hop que é usado para resolver o encaminhamento do next-hop) 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 enlace ou nó. Em todos os casos, o número total de rótulos de serviço, rótulos SID e rótulos de proteção contra 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 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 é 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 independentemente em outro LSP de roteamento por segmentos não colorido em um ponto de pontos. Um LSP de roteamento por segmentos não colorido dedicado à costura pode desativar a instalação de rotas de entrada configurando no-ingress a declaração em [edit protocols source-packet-routing source-routing-path lsp-name] nível de hierarquia.

  • Um máximo de 128 caminhos primários e 1 caminho secundário são suportados por LSP de roteamento estático por segmentos não coloridos. Se houver uma violação na configuração, a verificação de confirmação falhará 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. Um máximo de 128 caminhos primários são suportados por LSP de roteamento por segmentos estáticos. Como limitação, o suporte máximo do sensor para o caminho LSP é apenas 32000.

  • Se alguma lista de segmentos for configurada com mais rótulos do que a profundidade máxima da lista de segmentos, a verificação de compromisso 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 configurar os caminhos comutados por rótulos (LSPs) de roteamento por segmentos, embora apenas alguns caminhos projetados por roteamento por segmentos (SR-TE) possam ser usados. Você pode habilitar a criação dinâmica trigerred BGP desses LSPs para reduzir a quantidade de configuração nessas implantações.

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

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

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

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

Resolvendo 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 com a comunidade de cores, eles são inicialmente resolvidos por meio da 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. O SID dos destinos é então derivado do atributo next-hop do 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 o fundo da pilha. O prefixo de carga útil BGP é resolvido em um modo somente para cores, onde o nó-SID do Dispositivo A está na parte inferior da pilha de rótulos final, e os rótulos 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 em formato hexadecimal, e o formato do nome do túnel é semelhante ao que o RSVP acionou nomes LSP de túnel.

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

Resolvendo LSPs de roteamento dinâmico por segmentos não corados

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

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

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

O modelo de LSP de roteamento dinâmico por segmentos sempre tem um caminho parcial. O SID do nó de último salto é derivado automaticamente no momento da criação do túnel, dependendo do SID de endereço 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 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 nele. 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 mencionada acima, as entradas de rota são as seguintes:

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

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

  3. BGP prefix to tunnel mapping:

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

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

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

  4. inetcolor.0 tunnel route:

    10. 22.44.55-101/64 --> <next-hop>

    10. 22,44,55-124/64 -- > <next-hop>

  5. inetcolor6.0 tunnel route:

    ffff:10. 22.44.55-101/160 -- > <next-hop>

    ffff:10. 22.44.55-124/160 --> <next-hop>

LSPs de roteamento dinâmico de 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 mencionada acima, as entradas de rota são as seguintes:

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

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

  3. BGP prefix to tunnel mapping:

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

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

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

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

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 mencionada acima, 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. inetcolor6.0 tunnel route: ffff:10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff:10.1.1.0 - 0/24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: O túnel R1(prefixo) -> 10.33.44.55-124(PNH) não 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 spring-te inclui um modelo com um objeto colorido, você deve configurar todos os outros modelos com objetos coloridos também. Todos os destinos são considerados coloridos nessa configuração.

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

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

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

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

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

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

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

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

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

  • VPN de Camada 3

  • BGP EVPN

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

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

  • VPN de Camada 3

  • VPN de Camada 2

  • Configurações multicaminho

Comportamento com 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 estáticos e dinâmicos), a preferência por roteamento por segmentos é usada para escolher a entrada ativa da rota. 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 de LSPs de roteamento dinâmico 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.

  • 6PE não é suportado.

  • CSPF distribuído.

  • o tunelamento sBFD e LDP não tem suporte 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 resolver túneis de transporte em LSPs de roteamento por segmentos estáticos e BGP projetados por tráfego (SR-TE). Isso é chamado de próxima resolução de próxima resolução do protocolo IP colorido, onde você é obrigado a configurar um mapa de resolução e aplicar aos serviços de VPN. Com esse recurso, você pode habilitar o direcionamento de tráfego baseado em cores dos 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 a uma cor no roteador de saída onde o VPN NLRI é anunciado, ou em um roteador de entrada onde o VPN NLRI é recebido e processado.

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

  • Por instância de roteamento.

  • Por grupo BGP.

  • Por 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 meio de várias políticas na ordem a seguir:

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

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

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

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

Atribuição de cores de saída

Nesse modo, o dispositivo de saída (ou seja, o anunciante da VPN NLRI) é responsável por colorir o serviço vpn. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la na instância vrf-exportde roteamento do serviço VPN, na exportação de grupos ou na exportação de vizinhos do grupo no nível hierárquico [edit protocols bgp] . O VPN NLRI é anunciado pelo 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 BGP ou vizinho BGP, você deve incluir a vpn-apply-export declaração no nível bgp, grupo BGP ou vizinho BGP para que a política faça um efeito no VPN NLRI.

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

Atribuição de cores de ingresso

Nesse modo, o dispositivo de entrada (ou seja, o receptor da VPN NLRI) é responsável por colorir o serviço vpn. Para habilitar esse modo, você pode definir uma política de roteamento e aplicá-la à instância vrf-importde roteamento do serviço VPN, importação de grupos ou importação de vizinhos de grupo no nível hierárquico [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 resolution-map declaração e encaminhar a política em uma instância vrf-importde roteamento de um serviço VPN, importação de grupo ou importação de vizinhos de grupo no nível de [edit protocols bgp] hierarquia. Todas as rotas de VPN correspondentes à política de roteamento são anexadas 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 vizinho BGP.

Nota:

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

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

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

Por exemplo:

Recaia na 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 da próxima resolução hop. 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 próxima resolução hop.

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 LSP SR-TE colorida não existir, uma rota LDP com um endereço IP correspondente deve ser devolvida.

Mapeamento baseado em cores da BGP com rótulo Unicast 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 uma cor da comunidade BGP e definir um resolution map para SR-TE. Um próximo salto de protocolo colorido é construído e resolvido em um túnel SR-TE colorido na inetcolor.0 ou inet6color.0 tabela. O BGP usa e tabelas inet.3inet6.3 para mapeamento não colorido. Isso permite anunciar prefixos BGP-LU IPv6 e IPv4 com um endereço IPv6 next-hop em redes somente IPv6, onde os roteadores não têm nenhum endereço IPv4 configurado. Com esse recurso, atualmente temos suporte para BGP IPv6 LU sobre SR-TE com underlay IS-IS.

Em Figura 1, o controlador configura 4 túneis coloridos em uma rede de núcleo IPv6 configurada com SR-TE. Cada túnel colorido toma um caminho diferente até 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 hop colorido para o prefixo BGP IPv6 LU de acordo com a política de mapa de resolução atribuída.

Figura 1: BGP IPv6 LU sobre IPv6 SR-TE colorido BGP 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 sobre IPv4 LU estático e não colorido IPv4 SR-TE, 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 em cores estáticas e IPv6 SR-TE 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 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 de serviços 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.

  • IPv4 colorido e protocolo IPv6 próxima resolução hop.

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

  • LSP SR-TE colorido.

  • Plataformas virtuais.

  • Junos OS de 64 bits.

  • Sistemas lógicos.

  • BGP chamada unicast.

Os recursos e funcionalidades a seguir não são suportados com mapeamento baseado em cores de serviços 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 passar 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 contra 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ó é herdada se não for fornecida pela fonte LSP (PCEP); por exemplo, métrica.

Para configurar um modelo:

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

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

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

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

    A then declaração deve incluir a opção sr-te-template com uma ação de aceitação. Isso aplica o modelo ao LSP iniciado pelo 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 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.

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

Este exemplo mostra como configurar caminhos comutados 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 Versão 18.1 ou posterior em todos os roteadores

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

Visão geral

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

Figura 2: Caminho comutador de rótulos de roteamento por segmentos estático Caminho comutador de rótulos de roteamento por segmentos estático

Cópia de

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 sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuração do dispositivo PE1
Procedimento passo a passo

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

Para configurar o dispositivo PE1:

  1. Configure as interfaces.

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

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

  4. Configure o tipo de grupo de peer, 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 da á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) do roteamento de pacotes de origem de protocolo (SPRING).

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

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

  9. Configure informações da comunidade BGP.

  10. Configure a instância de roteamento VRF1 com tipo de instância, interface, distinguidor 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 os OSPF de protocolo.

Resultados

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

Configuração do dispositivo PE2
Procedimento passo a passo

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

  1. Configure as interfaces.

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

  3. Configure interfaces e alcance de rótulos estáticos 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 entrando nos show interfaces comandos e show protocols ingressando. 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 que a configuração está funcionando corretamente.

Verificando a entrada de rota da tabela de roteamento inet.3 do ROTEADOR PE1
Propósito

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

Ação

Do modo operacional, entre no show route table inet.3 comando.

Significado

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

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

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

Ação

Do modo operacional, entre no show route table mpls.0 comando.

Significado

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

Verificando o LSP projetado para tráfego spring do roteador PE1
Propósito

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

Ação

Do modo operacional, entre no show spring-traffic-engineering overview comando.

Significado

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

Verificação de LSPs projetados por tráfego spring no roteador de ingresso do PE1
Propósito

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

Ação

Do modo operacional, entre no show spring-traffic-engineering lsp detail comando.

Significado

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

Verificando a tabela de roteamento Entradas da tabela de roteamento mpls.0 do ROTEADOR PE2
Propósito

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

Ação

Do modo operacional, entre no show route table mpls.0 comando.

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

Verifique o status dos segmentos MPLS LSP do roteador PE2.

Ação

Do modo operacional, entre no show mpls static-lsp comando.

Significado

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

S-BFD baseada 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 contínua de encaminhamento bidirecional (S-BFD) em caminhos comutados por rótulos (LSPs) não coloridos 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 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 first-hop

A arquitetura de roteamento por segmentos permite que nós de entrada em uma rede principal 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) sem cores e LSPs estáticos de roteamento por segmentos com resolução de rótulos first-hop 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 alterações 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 S-BFD em qualquer um desses LSPs. Se uma sessão S-BFD cair, o software atualizará a rota do túnel de roteamento por segmentos excluindo os próximos saltos dos LSPs com falha. Se o rótulo de primeiro hop do LSP aponta para mais de um salto imediato, o kernel continua 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 deve ser mais rápida do que a duração do temporizador de detecção de S-BFD).

Nota:

Este modelo é suportado para LSPs derivados de tradução automática.
S-BFD de nível 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 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 S-BFD. O endereço de origem para a sessão S-BFD é 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 será calculada até que a S-BFD informe que o caminho está vivo.

Parâmetros 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 específico é 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 for 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 discriminatório remoto (RD) para sessão sBFD

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

Você também pode usar um modelo sBFD comum com as configurações sFBD em várias políticas SR-TE provisionadas por controladores, nas quais o RD pode ser derivado automaticamente do endpoint do túnel para diferentes políticas SR-TE correspondentes.

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 bfd-liveness-detection declaração de configuração na [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 primeiro hop:

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

    1. Em um roteador de entrada, você configura uma ou mais listas de segmentos com rótulos first-hop 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 de roteamento por segmentos estático, com vários caminhos primários (para balanceamento de carga) ou um caminho primário e um caminho secundário (para proteção de caminhos). 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 hops derivados dos rótulos de primeiro hop dos LSPs contribuintes.

    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 de ligação-SID (que todos 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 de resposta S-BFD com um D discriminatório local, criando uma sessão distribuída de ouvintes S-BFD para D em cada FPC.

    5. No roteador de entrada, você configura s-BFD para qualquer LSP para o qual você deseja ver a detecção de falhas de caminho. Você especifica um D discriminatório remoto para combinar com o discriminatório S-BFD local 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 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 abaixo descrevem imediatamente a operação básica:

    1. A sessão de iniciação S-BFD é realizada em um modo centralizado no Mecanismo de Roteamento. O software monitora a sessão S-BFD em estados altos e baixos.

    2. Quando o estado S-BFD muda 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 elimina 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 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ó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 é preservada, mas os parâmetros S-BFD são reavaliados para que os valores de parâmetro agressivos 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 conectados a ela, essa sessão 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+pilha de rótulos; se essa correspondência existir, o LSP se refere à 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 BFD correspondente no sistema, uma nova sessão de BFD é 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 depende ainda mais 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 na extremidade 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 de alerta sem 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 em lo0; caso contrário, o pacote é descartado, e s-BFD permanece baixo.

Você pode usar uma nova bandeira de bfdrastreamento para rastrear atividades de 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 parahow spring-traffic-engineering lsp detail mostrar LSPs para túneis estáticos de roteamento por segmentos, com status de sessão S-BFD.

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+address-family aparece, o nome da sessão S-BFD usa o nome address-family+lsp. 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 aparece na saída do show bfd session extensive comando também. 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 next hop 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 principal

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 e intradomain otimizados

Visão geral das 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. As métricas baseadas em atraso são essenciais para que um elemento de computação de caminhos (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 enlace em seu TED.

Para entender como anunciar o atraso em cada enlace ou ativar medições de enlace, veja como habilitar a medição e a publicidade de atraso do enlace 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 pelo tráfego com menor latência:

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

Benefícios das métricas baseadas em atraso para 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 do SR

Usando 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 no tipo métrica (engenharia de tráfego ou IGP). Os LSPs são computados para utilizar os caminhos ECMP disponíveis até 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 um perfil de computação configurado otimizado para a média de atraso, você também pode aplicar uma restrição chamada delay-variation-threshold. Quando você configura um valor para delay-variation-threshold, qualquer enlace que exceder o valor limite seria excluído da computação de caminhos.

Para configurar métricas de atraso para a computação baseada em DCSPF para o caminho do SR, você precisa habilitar a declaração de delay configuração no nível [edit protocols source-packet-routing compute-profile profile-name metric-type delay] de hierarquia. 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 da métrica de atraso do TED para cálculo cumulativo de caminho de latência mais baixo.
  • average— Valor métrico de atraso médio do TED para cálculo cumulativo de caminho de latência mais baixo.
  • maximum— Valor máximo da métrica de atraso do TED para cálculo cumulativo de caminho de latência mais baixo.
  • delay-variation-threshold— limite de variação de atraso do enlace (1,16777215). Qualquer enlace que exceder 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édia. A delay-variation-threshold declaraçã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:

Métricas de atraso para visão geral do caso de uso de interdomain e intradomain

Para o caso intra-domínio (o caminho reside em um único domínio), o atraso no enlace é levado em consideração ao fazer a computação de caminhos. As métricas de atraso para a computação de caminhos de roteamento por segmentos são suportadas em SIDs comprimidos e SIDs não compactados. Se você tiver SIDs não compactados, os 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 no-label-stack-compression configuração no nível [edit protocols source-packet-routing compute-profile profile-name] de hierarquia. Isso oferece um caminho totalmente expandido usando SIDs de adjacê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 computação de caminhos ópticos, recomenda-se usar as métricas de atraso como mínimo. O mínimo é a configuração padrão.

Para caso de uso de interdomain (multi-domínio), onde existem vários sistemas autônomos, você pode usar segmentos expressos para configurar atrasos de enlace para computação de caminhos. Segmentos expressos 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. Você pode configurar o atraso ou herdar o atraso do LSP subjacente no segmento expresso. Você pode configurar delay no nível [edit protocols express-segments segment-template template-name metric] de hierarquia e definir os valores para 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 computação de caminhos de interdomain, você pode atribuir métricas de atraso em links BGP EPE. Você pode configurar um valor para delay-metric o nível [edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute] de hierarquia, conforme mostrado abaixo:

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

As topologias a seguir mostram 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 latência de 10 microssegundos. 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. Isso aumenta a latência de 15 microssegundos. A métrica do enlace que conecta mudanças A e B dinamicamente entre o tempo=0 e o tempo=1.

Quando uma mudança no atraso por enlace é 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 menor latência disponível. A mudança no atraso do enlace pode resultar na entrada escolher outro conjunto de links que tenha o caminho de menor latência. Na figura B, você pode ver que há uma mudança na ligação entre o caminho A e C e o roteador headend reroutes e seleciona o caminho A-B-C conforme mostrado na topologia.

Tópicos relacionados

Tabela de histórico de liberação
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 passar 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 compromisso é 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 do Junos OS Release 19.1R1, esse requisito não se aplica, pois o primeiro salto dos LSPs estáticos não coloridos agora fornece suporte para rótulos SID, além de endereços IP. Com o suporte do primeiro rótulo hop, o MPLS reroute rápido (FRR) e o multicaminho de custo igual ponderado são habilitados para resolver os LSPs estáticos de roteamento por segmentos não coloridos, semelhantes aos LSPs estáticos coloridos.
18.2R1
A partir do Junos OS Release 18.2R1, LSPs de roteamento por segmentos não coloridos configurados no dispositivo de entrada 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).