NESTA PÁGINA
Proteção de largura de banda para links e nós (dinâmica e estática)
Redirecionamento rápido, proteção de nós e proteção de links
Configuração da proteção de enlace em interfaces usadas por LSPs
Configuração da proteção de nós ou da proteção de enlaces para LSPs
Configuração de LSPs de bypass com reconhecimento de restrição
Proteção de enlaces para LSPs MPLS
Proteção de links
A proteção de enlace ajuda a garantir que o tráfego que passa por uma interface específica para um roteador ou switch vizinho possa continuar a alcançar esse roteador (switch) se essa interface falhar. Quando a proteção de enlace é configurada para uma interface e um LSP que atravessa essa interface, é criado um LSP de bypass que lidará com esse tráfego se a interface falhar. O LSP de bypass usa uma interface e um caminho diferentes para alcançar o mesmo destino. O caminho usado pode ser configurado explicitamente ou você pode contar com o CSPF. A métrica RSVP para o LSP de bypass é definida no intervalo de 20.000 a 29.999 (esse valor não é configurável pelo usuário).
Se uma interface protegida por enlace falhar, o tráfego é rapidamente comutado para o LSP de bypass. Observe que um LSP de bypass não pode compartilhar a mesma interface de saída com os LSPs que monitora.
Na Figura 1, a proteção de enlace é habilitada na Interface B entre o Roteador 1 e o Roteador 2. Ele também é habilitado no LSP A, um LSP que atravessa o enlace entre o Roteador 1 e o Roteador 2. Se o enlace entre o Roteador 1 e o Roteador 2 falhar, o tráfego do LSP A é rapidamente comutado para o LSP de bypass gerado pela proteção do enlace.
protegida
Embora os LSPs que atravessam uma interface possam ser configurados para aproveitar a proteção de enlace, é importante observar que é especificamente a interface que se beneficia da proteção de enlace. Se a proteção de enlace estiver habilitada em uma interface, mas não em um LSP específico que atravessa essa interface, se a interface falhar, esse LSP também falhará.
A proteção de enlace não funciona em interfaces não numeradas.
Para proteger o tráfego em toda a rota percorrida por um LSP, você deve configurar o fast reroute. Para obter mais informações, consulte Configurando o redirecionamento rápido.
LSPs de bypass múltiplo para proteção de enlaces
Por padrão, a proteção de enlace depende de um único LSP de bypass para fornecer proteção de caminho para uma interface. No entanto, você também pode especificar vários LSPs de bypass para fornecer proteção de enlace para uma interface. Você pode configurar individualmente cada um desses LSPs de bypass ou criar uma única configuração para todos os LSPs de bypass. Se você não configurar os LSPs de bypass individualmente, todos eles compartilharão as mesmas restrições de caminho e largura de banda.
O algoritmo a seguir descreve como e quando um LSP de bypass adicional é ativado para um LSP:
Se algum bypass ativo no momento puder atender aos requisitos do LSP (largura de banda, proteção de link ou proteção de link de nó), o tráfego será direcionado para esse bypass.
Se nenhum LSP de bypass ativo estiver disponível, verifique os LSPs de bypass manual na ordem FIFO (primeiro a entrar, primeiro a sair), ignorando aqueles que já estão ativos (cada bypass manual só pode ser ativado uma vez). O primeiro desvio manual inativo que pode atender aos requisitos é ativado e o tráfego é direcionado para esse desvio.
Se nenhum LSP de bypass manual estiver disponível e se a
max-bypassesdeclaração ativar vários LSPs de bypass para proteção de enlace, determine se um LSP de bypass configurado automaticamente pode atender aos requisitos. Se um LSP de bypass configurado automaticamente estiver disponível e se o número total de LSPs de bypass configurados automaticamente ativos não exceder o limite máximo de LSP de bypass (configurado com amax-bypassesdeclaração), ative outro LSP de bypass.
Para obter informações sobre como configurar vários LSPs de bypass para proteção de enlace, consulte Configuração de LSPs de bypass.
Proteção de nós
A proteção de nós amplia os recursos de proteção de links. A proteção de enlace ajuda a garantir que o tráfego que passa por uma interface específica para um roteador vizinho possa continuar a alcançar esse roteador se essa interface falhar. A proteção de nó garante que o tráfego de um LSP que atravessa um roteador vizinho possa continuar a chegar ao seu destino mesmo que o roteador vizinho falhe.
Ao habilitar a proteção de nó para um LSP, você também deve habilitar a proteção de enlace. Uma vez habilitadas, a proteção de nó e a proteção de enlace estabelecem os seguintes tipos de LSPs de bypass:
LSP de bypass de próximo salto — fornece uma rota alternativa para um LSP alcançar um roteador vizinho. Esse tipo de LSP de bypass é estabelecido quando você habilita a proteção de nó ou a proteção de link.
LSP de bypass next-next-hop — Fornece uma rota alternativa para um LSP contornar um roteador vizinho a caminho do roteador de destino. Esse tipo de LSP de bypass é estabelecido exclusivamente quando a proteção do nó é configurada. Se um LSP de bypass next-next-hop não puder ser criado, será feita uma tentativa de sinalizar um LSP de bypass next-hop.
Na Figura 2, a proteção de nó está habilitada na Interface B do Roteador 1. A proteção de nó também é habilitada no LSP A, um LSP que atravessa o link que transita pelo Roteador 1, Roteador 2 e Roteador 3. Se o Roteador 2 sofrer uma falha de hardware ou software, o tráfego do LSP A é comutado para o LSP de bypass next-next-hop gerado pela proteção do nó.
de bypass next-next-hop
O tempo necessário para a proteção de nós mudar o tráfego para um LSP de bypass next-next-hop pode ser significativamente maior do que o tempo necessário para a proteção de enlace mudar o tráfego para um LSP de bypass next-hop. A proteção de enlace depende de um mecanismo de hardware para detectar uma falha de enlace, permitindo que ele alterne rapidamente o tráfego para um LSP de bypass de próximo salto.
As falhas de nó geralmente são devidas a problemas de software no roteador de nó. A proteção de nó depende do recebimento de mensagens de saudação de um roteador vizinho para determinar se ele ainda está funcionando. O tempo que a proteção do nó leva para desviar o tráfego depende em parte da frequência com que o roteador do nó envia mensagens de olá e quanto tempo leva para o roteador protegido por nó reagir ao não ter recebido uma mensagem de olá. No entanto, uma vez detectada a falha, o tráfego pode ser rapidamente desviado para o LSP de bypass next-next-hop.
A proteção de nó fornece proteção de tráfego no caso de um erro ou interrupção do enlace físico entre dois roteadores. Ele não oferece proteção em caso de erros do plano de controle. Veja a seguir um exemplo de erro de plano de controle:
Um roteador de trânsito muda o rótulo de um pacote devido a um erro de plano de controle.
Quando o roteador de entrada recebe o pacote, ele considera a mudança de rótulo como um evento catastrófico e exclui tanto o LSP principal quanto o LSP de bypass associado.
Proteção de largura de banda para links e nós (dinâmica e estática)
Visão geral
Ao configurar um LSP, você pode especificar uma largura de banda a ser reservada para proteção para esse caminho. Isso garante que o LSP tenha a capacidade necessária em seus links que atravessa durante o reparo local. O Junos OS oferece suporte à configuração de LSPs de bypass (backup) que protegem o LSP primário contra falhas de enlace ou nó. Esses LSPs de backup podem ter sua largura de banda reservada, garantindo que largura de banda suficiente esteja disponível para tráfego redirecionado durante falhas.
Por exemplo, se sua rede tiver um LSP que está passando por alguns saltos (nós) e se 100% de proteção de largura de banda for desejada, então cada salto reservará idealmente um bypass para 100% da capacidade do LSP protegido. Nesse caso, a capacidade total de rede necessária será significativamente alta. Você precisa decidir quantos LSPs de bypass você precisa, a capacidade para cada LSP de bypass e a proporção de tráfego (ou porcentagem de largura de banda) que precisa de proteção. Você pode escolher um caminho ou saltos específicos que o bypass deve atravessar configurando LSPs de bypass estático ou usar um ou mais bypass dinâmicos criados automaticamente configurando LSPs de bypass dinâmico.
Use a seguinte fórmula para configurar LSPs de bypass para proteção de largura de banda:
-
interface-subscription[i] * interface-link-bandwidth[i] <= bypass-n-bandwidth[i] * bypass-n-subscription [i]—Quando você configura LSPs de bypass estático, a soma da assinatura da interface e da largura de banda do link da interface não deve exceder a soma da largura de banda do bypass e da assinatura do bypass-n configurada. Por exemplo, (bypass-1-bandwidth, bypass-1-subscription, bypass-2-bandwidth, bypass-2-subscription e assim por diante).
-
interface-subscription[i] * interface-link-bandwidth[i] <= max-bypasses[i] * bypass-bandwidth[i] * bypass-subscription[i]—Quando você configura LSPs de bypass dinâmico, a soma da assinatura da interface e da largura de banda do link da interface não deve exceder a soma do bypass máximo configurado, da largura de banda do bypass e da assinatura do bypass.
| Valor |
Descrição |
|---|---|
| assinatura de interface |
Largura de banda total da interface |
| largura de banda do link de interface |
Largura de banda do link da interface |
| max-bypasses |
O número máximo de desvios que serão criados para LSPs de bypass dinâmico. O valor de largura de banda configurado será distribuído igualmente entre LSPs, de acordo com o valor max-bypass. |
| largura de banda de desvio |
A largura de banda (em Mbps) você pode configurar para um determinado LSP de bypass. Se você estiver configurando LSPs de bypass manual, poderá configurar diferentes larguras de banda de bypass para cada LSP. |
| assinatura de desvio |
Defina a proporção total de tráfego para a qual você deseja ativar a proteção. Defina o valor bypass-bandwidth para se ajustar à assinatura de bypass planejada. |
Redirecionamento rápido, proteção de nós e proteção de links
Este documento discute as seguintes seções:
- Visão geral da proteção LSP
- Comparação de tipos de proteção LSP
- Implementação de backup individual
- Implementação de backup de instalações
Visão geral da proteção LSP
As extensões RSVP-TE estabelecem túneis LSP (label-switched path) de backup para reparo local de túneis LSP. Esses mecanismos permitem o redirecionamento imediato do tráfego para túneis LSP de backup, em caso de falha.
O RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels, descreve dois tipos diferentes de proteção de tráfego para LSPs sinalizados por RSVP:
Backup um-para-um — neste método, os LSPs de desvio para cada LSP protegido são criados em cada ponto potencial de reparo local.
Backup de instalação — Neste método, um túnel de bypass é criado para proteger um conjunto de LSPs que têm restrições de backup semelhantes em um ponto de falha potencial, aproveitando o empilhamento de rótulos MPLS.
O backup individual e os métodos de backup de instalação protegem links e nós durante falhas de rede e podem coexistir em uma rede mista.
Comparação de tipos de proteção LSP
No Junos OS, o backup individual da proteção de tráfego é fornecido pelo fast reroute. Cada LSP requer que um LSP de proteção seja sinalizado em cada salto, exceto o roteador de saída. Este método de proteção LSP não pode ser compartilhado.
No método de backup de facilidade, a proteção de tráfego LSP é fornecida no nó e no link. Ao contrário do fast reroute, esse LSP protetor pode ser compartilhado por outros LSPs.
A Tabela 2 resume os tipos de proteção de tráfego.
Comparação |
Backup individual |
Backup de instalações |
|---|---|---|
Nome do LSP de proteção |
Desvio LSP |
Ignorar LSP |
Compartilhamento do LSP protetor |
Não pode ser compartilhado |
Pode ser compartilhado por vários LSPs |
Declarações de configuração do Junos |
|
|
Implementação de backup individual
No método de backup individual, os pontos de reparo local mantêm caminhos de backup separados para cada LSP que passa por uma instalação. O caminho de backup termina mesclando-se novamente com o caminho principal em um nó chamado ponto de mesclagem. Nessa abordagem, o ponto de mesclagem pode ser qualquer nó a jusante da instalação protegida.
No método de backup um-para-um, é estabelecido um LSP que cruza o LSP original a jusante do ponto de falha de link ou nó. Um LSP de backup separado é estabelecido para cada LSP que é copiado.
O backup individual é apropriado nas seguintes circunstâncias:
Proteção de um pequeno número de LSPs em relação ao número total de LSPs.
Os critérios de seleção de caminho, como largura de banda, prioridade e coloração de links para caminhos de desvio, são essenciais.
O controle de LSPs individuais é importante.
Na Figura 3, os roteadores R1 e R5 são os roteadores de entrada e saída, respectivamente. Um LSP protegido é estabelecido entre os dois roteadores que transitam pelos roteadores R2, R3 e R4. O roteador R2 fornece proteção de tráfego do usuário criando um LSP de backup parcial que se funde com o LSP protegido no roteador R4. Esse LSP de backup individual parcial é chamado de desvio. Os desvios são sempre calculados para evitar o link e o nó downstream imediatos, evitando falhas de link e nó.
individual
No exemplo, o LSP protegido é R1-R2-R3-R4-R5, e os seguintes desvios são estabelecidos:
Roteador R1—
R1-R6-R7-R8-R3Roteador R2—
R2-R7-R8-R4Roteador R3—
R3-R8-R9-R5Roteador R4—
R4-R9-R5
Para proteger um LSP que atravessa N nós totalmente, pode haver até (N - 1) desvios. O ponto de reparo local envia mensagens de atualização periódicas para manter cada caminho de backup, como resultado, manter informações de estado para caminhos de backup que protegem LSPs individuais é uma carga de recursos significativa para o ponto de reparo local. Para minimizar o número de LSPs na rede, é desejável mesclar um desvio de volta ao seu LSP protegido, quando viável. Quando um LSP de desvio cruza seu LSP protegido em um LSR com a mesma interface de saída, ele é mesclado.
Implementação de backup de instalações
Na abordagem de backup da instalação, um ponto de reparo local mantém um único caminho de backup para proteger um conjunto de LSPs primários que atravessam o ponto de reparo local, a instalação e o ponto de mesclagem. O backup da instalação é baseado na interface e não no LSP. Enquanto o fast reroute protege interfaces ou nós ao longo de todo o caminho de um LSP, a proteção de backup da instalação pode ser aplicada em interfaces conforme necessário. Como resultado, menos estados precisam ser mantidos e atualizados, o que resulta em uma solução escalável. O método de backup de instalação também é chamado de backup de muitos para um.
O método de backup de instalação aproveita a pilha de rótulos MPLS. Em vez de criar um LSP separado para cada LSP de backup, é criado um único LSP que serve para fazer backup de um conjunto de LSPs. Esse túnel LSP é chamado de túnel de bypass. Nesse método, um roteador imediatamente upstream de uma falha de link usa uma interface alternativa para encaminhar o tráfego para seu vizinho downstream, e o ponto de mesclagem deve ser o nó imediatamente downstream para a instalação. Isso é feito pré-estabelecendo um caminho de desvio que é compartilhado por todos os LSPs protegidos que atravessam o link com falha. Um único caminho de desvio pode proteger um conjunto de LSPs protegidos. Quando ocorre uma interrupção, o roteador imediatamente a montante da interrupção do enlace comuta o tráfego protegido para o enlace de bypass e, em seguida, sinaliza a falha do enlace para o roteador de entrada.
O túnel de desvio deve cruzar o caminho do(s) LSP(s) original(is) em algum lugar a jusante do ponto de reparo local. Isso restringe o conjunto de LSPs que estão sendo apoiados por esse túnel de desvio para aqueles que passam por alguns nós downstream comuns. Todos os LSPs que passam pelo ponto de reparo local e por esse nó comum, e que também não usam as instalações envolvidas no túnel de desvio, são candidatos a esse conjunto de LSPs.
O método de backup de instalação é apropriado nas seguintes situações:
O número de LSPs a serem protegidos é grande.
Satisfazer os critérios de seleção de caminho (prioridade, largura de banda e coloração do link) para caminhos de desvio é menos crítico.
O controle na granularidade de LSPs individuais não é necessário.
Na Figura 4, os roteadores R1 e R5 são os roteadores de entrada e saída, respectivamente. O roteador R2 estabeleceu um túnel de desvio que protege contra a falha do enlace do roteador R2-R3 e do nó do roteador R3. Um túnel de desvio é estabelecido entre os roteadores R6 e R7. Existem três LSPs protegidos diferentes que estão usando o mesmo túnel de desvio para proteção.
instalação
O método de backup da instalação fornece uma melhoria de escalabilidade, em que o mesmo túnel de bypass também é usado para proteger os LSPs de qualquer um dos roteadores R1, R2 ou R8 para qualquer um dos roteadores R4, R5 ou R9.
Configuração da proteção de enlace em interfaces usadas por LSPs
Quando você configura a proteção de nó ou a proteção de enlace em um roteador para LSPs, conforme descrito na configuração da proteção de nó ou proteção de enlace para LSPs, você também deve configurar a link-protection declaração nas interfaces RSVP usadas pelos LSPs.
Para configurar a proteção de enlace nas interfaces usadas pelos LSPs, inclua a link-protection declaração:
link-protection {
disable;
admin-group
exclude group-names;
include-all group-names;
include-any group-names;
}
bandwidth bps;
bypass bypass-name {
bandwidth bps;
description text;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}
class-of-service cos-value;
hop-limit number;
max-bypasses number;
no-cspf;
no-node-protection;
optimize-timer seconds;
path address <strict | loose>;
priority setup-priority reservation-priority;
subscription percent {
ct0 percent;
ct1 percent;
ct2 percent;
ct3 percent;
}
}
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name]
Todas as instruções abaixo link-protection são opcionais.
As seções a seguir descrevem como configurar a proteção de link:
- Configuração de LSPs de bypass
- Configuração de grupos administrativos para LSPs de bypass
- Configurando a largura de banda para LSPs de bypass
- Configuração da classe de serviço para LSPs de bypass
- Configuração do limite de salto para LSPs de bypass
- Configurando o número máximo de LSPs de bypass
- Desativação do CSPF para LSPs de bypass
- Desativação da proteção de nó para LSPs de bypass
- Configuração do intervalo de otimização para LSPs de bypass
- Configuração da otimização de largura de banda não reservada para LSPs de bypass
- Configuração de um caminho explícito para LSPs de bypass
- Configurando a quantidade de largura de banda inscrita para LSPs de bypass
- Configuração de prioridade e preempção para LSPs de bypass
Configuração de LSPs de bypass
Você pode configurar restrições específicas de largura de banda e caminho para um LSP de bypass. Cada LSP de bypass manual em um roteador deve ter um endereço IP "para" exclusivo. Você também pode configurar individualmente cada LSP de bypass gerado ao habilitar vários LSPs de bypass. Se você não configurar os LSPs de bypass individualmente, todos eles compartilham as mesmas restrições de caminho e largura de banda (se houver).
Se você especificar as bandwidthinstruções , hop-limite path para o LSP de bypass, esses valores terão precedência sobre os valores configurados no nível de [edit protocols rsvp interface interface-name link-protection] hierarquia. Os outros atributos (subscription, no-node-protectione optimize-timer) são herdados das restrições gerais .
Para configurar um LSP de bypass, especifique um nome para o LSP de bypass usando a bypass declaração. O nome pode ter até 64 caracteres.
bypass bypass-name { bandwidth bps; description text; class-of-service cos-value; hop-limit number; no-cspf; path address <strict | loose>; priority setup-priority reservation-priority; to address; }
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name link-protection] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]
Configuração do endereço do nó next-hop ou next-next-hop para LSPs de bypass
Se você configurar um LSP de bypass, também deverá configurar a to declaração. A to instrução especifica o endereço para a interface do nó next-hop imediato (para proteção de link) ou do nó next-next-hop (para proteção de link de nó). O endereço especificado determina se isso é um bypass de proteção de link ou um bypass de proteção de link de nó. Em redes multiacesso (por exemplo, uma LAN), esse endereço também é usado para especificar qual nó de próximo salto está sendo protegido.
Configuração de grupos administrativos para LSPs de bypass
Grupos administrativos, também conhecidos como coloração de link ou classe de recurso, são atribuídos manualmente atributos que descrevem a "cor" dos links, de modo que os links com a mesma cor pertençam conceitualmente à mesma classe. Você pode usar grupos administrativos para implementar uma variedade de configurações de LSP baseadas em políticas. É possível configurar grupos administrativos para LSPs de bypass. Para obter mais informações sobre a configuração de grupos administrativos, consulte Configurando Grupos Administrativos para LSPs.
Para configurar grupos administrativos para LSPs de bypass, inclua a admin-group declaração:
admin-group { exclude group-names; include-all group-names; include-any group-names; }
Para configurar um grupo administrativo para todos os LSPs de bypass, inclua a admin-group declaração nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name link-protection] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]
Para configurar grupos administrativos para um LSP de bypass específico, inclua a admin-group declaração nos seguintes níveis de hierarquia:
Configurando a largura de banda para LSPs de bypass
Você pode especificar a quantidade de largura de banda alocada para LSPs de bypass gerados automaticamente ou pode especificar individualmente a quantidade de largura de banda alocada para cada LSP.
Se você habilitou vários LSPs de bypass, essa declaração é necessária.
Para especificar a alocação de largura de banda, inclua a bandwidth declaração:
bandwidth bps;
Para LSPs de bypass gerados automaticamente, inclua a bandwidth declaração nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name link-protection] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]
Para LSPs de bypass configurados individualmente, inclua a bandwidth declaração nos seguintes níveis de hierarquia:
Configuração da classe de serviço para LSPs de bypass
Você pode especificar o valor de classe de serviço para LSPs de bypass incluindo a class-of-service declaração:
class-of-service cos-value;
Para aplicar um valor de classe de serviço a todos os LSPs de bypass gerados automaticamente, inclua a class-of-service declaração nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name link-protection] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]
Para configurar um valor de classe de serviço para LSPs de bypass específicos, inclua a class-of-service declaração nos seguintes níveis de hierarquia:
Configuração do limite de salto para LSPs de bypass
Você pode especificar o número máximo de saltos que um bypass pode atravessar. Por padrão, cada desvio pode atravessar no máximo 255 saltos (os roteadores de entrada e saída contam como um salto cada, portanto, o limite mínimo de saltos é dois).
Para configurar o limite de salto para LSPs de bypass, inclua a hop-limit declaração:
hop-limit number;
Para LSPs de bypass gerados automaticamente, inclua a hop-limit declaração nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name link-protection] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]
Para LSPs de bypass configurados individualmente, inclua a hop-limit declaração nos seguintes níveis de hierarquia:
Configurando o número máximo de LSPs de bypass
Você pode especificar o número máximo de LSPs de bypass dinâmico permitidos para proteger uma interface usando a max-bypasses declaração no nível de [edit protocols rsvp interface interface-name link-protection] hierarquia. Quando essa declaração é configurada, vários desvios para proteção de enlace são habilitados. O controle de admissão de chamadas (CAC) também está habilitado.
Por padrão, essa opção está desabilitada e apenas um bypass é habilitado para cada interface. Você pode configurar um valor de between 0 through 99 para a max-bypasses instrução. A configuração de um valor de 0 impede a criação de qualquer LSPs de bypass dinâmico para a interface. Se você configurar um valor de para a max-bypasses declaração, precisará configurar um ou mais LSPs de bypass estático para habilitar a proteção de 0 enlace na interface.
Se você configurar a max-bypasses declaração, também deverá configurar a declaração (discutida bandwidth em Configurando a largura de banda para LSPs de bypass).
Para configurar o número máximo de LSPs de bypass para uma interface protegida, inclua a max-bypasses declaração:
max-bypasses number;
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
Desativação do CSPF para LSPs de bypass
Sob certas circunstâncias, pode ser necessário desabilitar a computação CSPF para LSPs de bypass e usar o Objeto de Rota Explícita (ERO) configurado, se disponível. Por exemplo, um LSP de bypass pode precisar atravessar várias áreas OSPF ou níveis de IS-IS, impedindo que a computação CSPF funcione. Para garantir que a proteção de link e nó funcione corretamente nesse caso, você precisa desabilitar a computação CSPF para o LSP de bypass.
Você pode desabilitar a computação CSPF para todos os LSPs de bypass ou para LSPs de bypass específicos.
Para desabilitar a computação CSPF para LSPs de bypass, inclua a no-cspf declaração:
no-cspf;
Para obter uma lista de níveis de hierarquia em que você pode incluir essa instrução, consulte o resumo da instrução para essa instrução.
Desativação da proteção de nó para LSPs de bypass
Você pode desativar a proteção de nó na interface RSVP. A proteção de enlaces permanece ativa. Quando essa opção é configurada, o roteador só pode iniciar um desvio de próximo salto, não um desvio de próximo salto.
Para desativar a proteção de nó para LSPs de bypass, inclua a no-node-protection declaração:
no-node-protection;
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
Configuração do intervalo de otimização para LSPs de bypass
Você pode configurar um intervalo de otimização para LSPs de bypass usando a optimize-timer declaração. No final desse intervalo, é iniciado um processo de otimização que tenta minimizar o número de desvios atualmente em uso, minimizar a quantidade total de largura de banda reservada para todos os desvios ou ambos. Você pode configurar um intervalo de otimização de 1 a 65.535 segundos. Um valor padrão de 0 desabilita a otimização de LSP de ignorância.
Quando você configura a declaração, os optimize-timer LSPs de bypass são reotimizados automaticamente quando você configura ou altera a configuração de qualquer um dos seguintes:
-
Grupo administrativo para um LSP de bypass — A configuração de um grupo administrativo foi alterada em um link ao longo do caminho usado pelo LSP de bypass. Configure um grupo administrativo usando a
admin-groupinstrução no nível de[edit protocols rsvp interface interface-name link-protection]hierarquia. -
Grupo de compartilhamento de destinos — A configuração de um grupo de compartilhamento de destinos foi alterada. Configure um grupo de compartilhamento de destinos usando a
groupdeclaração no nível de[edit routing-options fate-sharing]hierarquia. -
Sobrecarga de IS-IS — A configuração para sobrecarga de IS-IS foi alterada em um roteador ao longo do caminho usado pelo LSP de bypass. Configure a sobrecarga do IS-IS usando a
overloadinstrução no nível da[edit protocols isis]hierarquia. -
Métrica de IGP — A métrica de IGP foi alterada em um link ao longo do caminho usado pelo LSP de bypass.
Para configurar o intervalo de otimização para LSPs de bypass, inclua a optimize-timer declaração:
optimize-timer seconds;
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
Configuração da otimização de largura de banda não reservada para LSPs de bypass
A abordagem padrão de desvio de RSVP produz um método de desvio que otimiza a métrica de engenharia de tráfego (TE). O CSPF (Constrained Shortest Path First, Caminho mais curto restrito) pode, opcionalmente, usar uma abordagem diferente para proteger um link ou um nó aproveitando a computação baseada em larguras de banda não reservadas em links (TE).
Para habilitar esse recurso, use a optimize bandwidth declaração de configuração no nível da edit protocols rsvp interface interface link-protection hierarquia. Habilitar a nova declaração de configuração maximiza a largura de banda não reservada de ponta a ponta.
Para aplicar a declaração de configuração de otimização de largura de banda, habilite a configuração set protocols isis l3-unicast-topology .
link-protection {
optimize {
bandwidth;
}
}
Para configurar o algoritmo de otimização de largura de banda para LSPs de bypass, inclua a optimize bandwidth declaração nos seguintes níveis de hierarquia:
Configuração de um caminho explícito para LSPs de bypass
Por padrão, quando você estabelece um LSP de bypass para um vizinho adjacente, o CSPF é usado para descobrir o caminho de menor custo. A path declaração permite que você configure um caminho explícito (uma sequência de rotas estritas ou soltas), dando a você controle sobre onde e como o LSP de bypass é estabelecido. Para configurar um caminho explícito, inclua a path declaração:
path address <strict | loose>;
Para LSPs de bypass gerados automaticamente, inclua a path declaração nos seguintes níveis de hierarquia:
-
[edit protocols rsvp interface interface-name link-protection] -
[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]
Para LSPs de bypass configurados individualmente, inclua a path declaração nos seguintes níveis de hierarquia:
Configurando a quantidade de largura de banda inscrita para LSPs de bypass
Você pode configurar a quantidade de largura de banda inscrita para ignorar LSPs. Você pode configurar a assinatura de largura de banda para todo o LSP de bypass ou para cada tipo de classe que pode atravessar o LSP de bypass. Você pode configurar qualquer valor entre 1 % e 65.535%. Ao configurar um valor inferior a 100 por cento, você está subscrevendo os LSPs de bypass. Ao configurar um valor maior que 100 por cento, você está subscrevendo em excesso os LSPs de bypass.
A capacidade de subscrever em excesso a largura de banda para os LSPs de bypass possibilita o uso mais eficiente dos recursos da rede. Você pode configurar a largura de banda para os LSPs de bypass com base na carga média da rede em oposição à carga de pico.
Para configurar a quantidade de largura de banda inscrita para LSPs de bypass, inclua a subscription declaração:
subscription percentage { ct0 percentage; ct1 percentage; ct2 percentage; ct3 percentage; }
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
Configuração de prioridade e preempção para LSPs de bypass
Quando não há largura de banda suficiente para estabelecer um LSP mais importante, você pode querer derrubar um LSP existente menos importante para liberar a largura de banda. Você faz isso antecipando o LSP existente.
Para obter informações mais detalhadas sobre como configurar a prioridade de configuração e a prioridade de reserva para LSPs, consulte Configuração de prioridade e preempção para LSPs.
Para configurar as propriedades priority e preemption do LSP de bypass, inclua a priority declaração:
priority setup-priority reservation-priority;
Para obter uma lista de níveis de hierarquia nos quais você pode incluir essa instrução, consulte a seção de resumo da instrução para esta declaração.
Configuração da proteção de nós ou da proteção de enlaces para LSPs
Quando você configura a proteção de nó ou a proteção de enlace em um roteador ou switch, os LSPs de bypass são criados para os roteadores (switches) de next-hop ou next-next-hop para os LSPs que atravessam o roteador (switch). Você deve configurar a proteção de nó ou a proteção de enlace para cada LSP que deseja proteger. Para estender a proteção ao longo de todo o caminho usado por um LSP, você deve configurar a proteção em cada roteador que o LSP atravessa.
Você pode configurar a proteção de nó ou a proteção de enlace para LSPs estáticos e dinâmicos.
Para configurar a proteção de nó em um roteador para um LSP especificado, inclua a node-link-protection declaração:
node-link-protection;
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
Para configurar a proteção de enlace em um roteador para um LSP especificado, inclua a link-protection declaração:
link-protection;
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
Para concluir a configuração da proteção de nó ou enlace, você também deve configurar a proteção de enlace em todas as interfaces RSVP unidirecionais que os LSPs atravessam, conforme descrito na configuração da proteção de enlace em interfaces usadas por LSPs.
Configuração da proteção de enlaces e nós Inter-AS
Para interoperar com equipamentos de outros fornecedores, o Junos OS oferece suporte ao subobjeto de ID do nó do objeto de rota de registro (RRO) para uso em configurações de proteção de nó e link inter-AS. O subobjeto de ID do nó RRO é definido no RFC 4561, Definição de um subobjeto de ID do nó RRO (Record Route Object, objeto de rota de registro). Essa funcionalidade é habilitada por padrão no Junos OS versão 9.4 e posterior.
Se você tiver roteadores da Juniper Networks executando o Junos OS versão 9.4 e versões posteriores na mesma rede MPLS-TE que os roteadores que executam o Junos OS versão 8.4 e versões anteriores, talvez seja necessário desabilitar o subobjeto de ID do nó RRO configurando a no-node-id-subobject declaração:
no-node-id-subobject;
Você pode incluir essa instrução nos seguintes níveis de hierarquia:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Configuração de LSPs de bypass com reconhecimento de restrição
Você pode configurar LSPs de desvio de RSVP para estar ciente e herdar todas as restrições de caminho dos LSPs primários. Você também pode configurar explicitamente restrições de bypass para LSPs individuais.
Benefícios dos LSPs de desvio de RSVP com reconhecimento de restrições
-
Controle o caminho MPLS e evite que os LSPs de bypass atravessem uma área geográfica específica em uma rede global de RSVP MPLS
Você pode configurar LSPs de desvio de RSVP com reconhecimento de restrições com proteção de enlace, proteção de enlace de nó e conteinerizado para LSPs primários.
Para configurar LSPs de bypass com reconhecimento de restrições, as inherit-lsp constraints instruções and bypass-constraints são introduzidas nos [edit protocols mpls label-swithed-path lsp-name link-protection] níveis e hierárquico [edit protocols mpls label-swithed-path lsp-name node-link-protection] .
Para configurar LSPs de bypass com reconhecimento de restrições em um LER de entrada, você pode herdar as restrições de bypass ou definir explicitamente restrições separadas para bypass.
Para herdar as restrições de bypass, inclua a inherit-lsp constraints [edit protocols mpls label-swithed-path lsp-name link-protection] instrução nos níveis e na [edit protocols mpls label-swithed-path lsp-name node-link-protection] hierarquia.
Para definir restrições separadas para LSPs de bypass, inclua a bypass-constraints [edit protocols mpls label-swithed-path lsp-name link-protection] declaração nos níveis e nos [edit protocols mpls label-swithed-path lsp-name node-link-protection] níveis de hierarquia. Você pode configurar as opções dentro da bypass-constraints hierarquia de declarações para herdar todas as restrições do LSP principal ou restrições específicas para o bypass desse LSP.
A configuração da transport-class declaração não é obrigatória ao configurar LSPs de bypass com reconhecimento de restrições. O recurso LSP de bypass com reconhecimento de restrições funciona com ou sem a transport-class declaração configurada para o LSP.
Em PLRs, você precisa incluir a constraint-aware-bypass declaração no nível deedit protocols rsvp interface interface-name link-protection [] hierarquia para oferecer suporte a LSPs de bypass com reconhecimento de restrições.
Se você tiver vários LSPs em um LER de entrada específico e decidir habilitar o recurso de bypass com reconhecimento de restrição apenas em um pequeno subconjunto de LSPs, a bypass-constraints declaração ajudará a habilitar o recurso somente nesses LSPs específicos.
Se você não configurar bypass-constraints a declaração na entrada para um LSP específico, esse LSP continuará a ter a associação atual de bypass sem reconhecimento de restrições. Os LSRs e o PLR de trânsito estabelecem automaticamente LSPs de bypass com reconhecimento de restrição apenas para os LSPs para os quais a declaração está configurada bypass-constraints na entrada em MPLS e em PLR em RSVP.
Quando você modifica a configuração de LSPs de bypass com reconhecimento de restrição na entrada, essas alterações de configuração são tratadas no modo make before break (MBB) para o LSP. Ou seja, uma nova instância do LSP é sinalizada com os novos objetos de restrição de bypass. Quando o PLR recebe a mensagem de caminho para a nova instância do LSP, o PLR estabelece o LSP de bypass apropriado que satisfaz essas restrições.
Da mesma forma, quando você modifica a configuração de bypass com reconhecimento de restrição no PLR, todos os LSPs de bypass são recalculados e reassociados aos LSPs primários nesse PLR.
Os LSPs dinâmicos de bypass de proteção de enlace são criados ao longo do caminho nos PLRs que seguem as mesmas restrições CSPF, como a exclusão de um grupo de administradores específico.
O recurso LSP de bypass com reconhecimento de restrições não funciona quando:
-
Os LSPs são configurados com a no-cspf declaração na entrada.
-
Os LSPs são configurados com a funcionalidade pop-and-forward.
-
Os LSPs de bypass são configurados manualmente no PLR.
-
max-bypassesdeclaração está configurada no PLR
Se houver alguma alteração nas afinidades de recursos sinalizadas para o LSP, cada LSR individual ao longo do caminho do LSP recalculará automaticamente os desvios conforme necessário.
Quando a bypass-constraints declaração é configurada na entrada indicando a intenção de sinalizar LSPs de bypass com reconhecimento de restrições, o LER de entrada inclui o objeto FAST_REROUTE na mensagem de caminho RSVP para o LSP. Entrada define o campo Sinalizadores como 0x02 indicando Backup de Instalação como o tipo de proteção. A entrada também preenche todas as restrições configuradas para esse LSP de desvio.
Ao receber o objeto FAST_REROUTE na mensagem de caminho RSVP, cada roteador PLR cria e mantém um lsp-affinities-profile que armazena todas as restrições recebidas. O PLR realiza uma pesquisa entre os LSPs de bypass existentes para ver se algum dos LSPs de bypass existentes atende aos requisitos de restrição. Se os LSPs de bypass existentes satisfizerem as restrições, esse LSP de bypass estará associado ao LSP principal. Caso contrário, se as restrições não forem satisfeitas pelo LSP de bypass existente, o PLR continuará a estabelecer um novo bypass correspondente a todas as restrições recebidas na mensagem de caminho RSVP de entrada.
As saídas e show rsvp session show rsvp session bypass comandos foram aprimorados para exibir as restrições de desvio herdadas dos LSPs primários e as afinidades de recursos sinalizadas para o LSP.
Veja a seguir um exemplo de saída do comando que exibe as informações de show rsvp session extensive restrições de desvio:
user@host> show rsvp session extensive
8.8.8.8
From: 1.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp-R1-R8-1, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299984
Resv style: 1 SE, Label in: -, Label out: 299984
Time left: -, Since: Sun Nov 19 02:46:26 2023
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 3 receiver 18914 protocol 0
Link protection desired
Type: Link protected LSP, using Bypass->22.1.9.9
6 Nov 20 15:16:04 Link protection up, using Bypass->22.1.9.9
5 Nov 20 15:16:03 Bypass in down state, Bypass->22.1.9.9[3 times, first Nov 20 15:16:01 ]
Bypass constraints for LSP:
Hop Limit : 9
Include Any: green Include All: Brown Exclude: Red
Enhanced FRR: Enabled (Downstream), LP-MP is 9.9.9.9
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 22.1.9.9 (ge-0/0/2.0) 4 pkts
outgoing message state: refreshing, Message ID: 180, Epoch: 11062187
RESV rcvfrom: 22.1.9.9 (ge-0/0/2.0) 6 pkts, Entropy label: Yes
incoming message handle: R-82/6, Message ID: 170, Epoch: 11062161
Explct route: 22.1.9.9 22.9.10.10 22.8.10.8
Record route: <self> 9.9.9.9 (node-id) 22.1.9.9 10.10.10.10 (node-id) 22.9.10.10 8.8.8.8 (node-id) 22.8.10.8
Veja a seguir um exemplo de saída do comando que exibe as informações de show rsvp session bypass extensive restrições de desvio:
user@host> show rsvp session bypass extensive
9.9.9.9
From: 1.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->22.1.9.9
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 300048
Resv style: 1 SE, Label in: -, Label out: 300048
Time left: -, Since: Mon Nov 20 15:16:03 2023
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 40332 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
Number of protected LSP instances: 1
Bypass constraints for LSP:
Hop Limit : 9
Include Any: green Include All: Brown Exclude: Red
Enhanced FRR: Enabled (Downstream)
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 22.1.5.5 (ge-0/0/1.0) 1 pkts