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 básica de LSP

Configuração de métricas de LSP

A métrica LSP é usada para indicar a facilidade ou a dificuldade de enviar tráfego por um LSP específico. Valores métricos menores de LSP (menor custo) aumentam a probabilidade de um LSP ser usado. Por outro lado, altos valores métricos de LSP (maior custo) diminuem a probabilidade de um LSP ser usado.

A métrica de LSP pode ser especificada dinamicamente pelo roteador ou explicitamente pelo usuário, conforme descrito nas seções a seguir:

Configuração de métricas de LSP dinâmicas

Caso nenhuma métrica específica seja configurada, um LSP tenta rastrear a IGP em direção ao mesmo destino (o endereço to do LSP). IGP inclui OSPF, IS-IS, Roteamento de informações (RIP) e rotas estáticas. BGP e outras rotas de RSVP ou LDP estão excluídas.

Por exemplo, se a métrica OSPF em direção a um roteador for de 20, todos os LSPs em direção a esse roteador herdam automaticamente a métrica 20. Se a OSPF em direção a um roteador mais tarde mudar para um valor diferente, todas as métricas de LSP mudarão de acordo. Se não houver rotas IGP em direção ao roteador, o LSP eleva sua métrica para 65.535.

Observe que, nesse caso, a métrica de LSP é completamente determinada por IGP; não tem relação com o caminho real que o LSP está atravessando no momento. Caso o LSP reencaminha (como por exemplo, por meio da reotimização), sua métrica não muda, e assim ela permanece transparente para os usuários. A métrica dinâmica é o comportamento padrão; nenhuma configuração é necessária.

Configuração de métricas de LSP estáticas

Você pode atribuir manualmente um valor métrico fixo a um LSP. Uma vez configurada com a metric instrução, a métrica LSP é fixa e não pode mudar:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

A métrica LSP tem vários usos:

  • Quando há LSPs paralelos com o mesmo roteador de saída, as métricas são comparadas para determinar qual LSP tem o menor valor métrico (o menor custo) e, portanto, o caminho preferido até o destino. Se as métricas são as mesmas, o tráfego é compartilhado.

    Ajustar os valores métricos pode obrigar o tráfego a preferir alguns LSPs em relação a outros, independentemente da métrica IGP subjacente.

  • Quando um atalho de IGP é ativado (consulte Como usar caminhos comutado de rótulo para aumentar o SPF para IGP Atalhos),uma rota de IGP pode ser instalada na tabela de roteamento com um LSP como o próximo salto, caso o LSP esteja no caminho mais curto até o destino. Nesse caso, a métrica de LSP é adicionada às outras IGP para determinar a métrica de caminho total. Por exemplo, se um LSP cujo roteador de entrada é X e o roteador de saída for Y, estiver no caminho mais curto até o destino Z, a métrica LSP será adicionada à métrica da rota de IGP de Y a Z para determinar o custo total do caminho. Se vários LSPs são potenciais próximos hops, as métricas totais dos caminhos são comparadas para determinar qual caminho é preferido (ou seja, tem a menor métrica total). Ou, IGP caminhos e LSPs que conduzem ao mesmo destino podem ser comparados por meio do valor métrico para determinar qual caminho é preferido.

    Ao ajustar a métrica de LSP, você pode obrigar o tráfego a preferir LSPs, preferir o IGP de segurança ou compartilhar a carga entre eles.

  • Se os roteadores X e Y BGP peers e se houver um LSP entre eles, a métrica LSP representa o custo total para chegar a Y a partir de X. Se, por qualquer motivo, o LSP reencaminhar, o custo do caminho subjacente pode mudar significativamente, mas o custo de X para chegar a Y continua a ser o mesmo (a métrica LSP), o que permite que BGP X reporte por meio de um discriminador de saída (MED) com várias saídas (MED) uma métrica estável para os vizinhos downstream. Enquanto Y permanecer alcançável pelo LSP, nenhuma mudança é perceptível para os vizinhos BGP downstream.

É possível configurar uma IS-IS para ignorar a métrica de LSP configurada incluindo a ignore-lsp-metrics instrução no nível [edit protocols isis traffic-engineering shortcuts] da hierarquia. Essa instrução elimina a dependência mútua entre IS-IS e MPLS para a computação de caminho. Para obter mais informações, consulte a Biblioteca de Protocolos de Roteamento do Junos OS para dispositivos de roteamento.

Configurando uma descrição de texto para LSPs

Você pode fornecer uma descrição textual para um LSP ao incluir qualquer texto descritivo que inclua espaços entre aspas (" "). O texto descritivo que você inclui é exibido na saída detalhada do show mpls lsp ou do show mpls container-lsp comando.

Adicionar uma descrição de texto para um LSP não tem efeito na operação do LSP. A descrição do texto LSP pode ter no máximo 80 caracteres de comprimento.

Para fornecer uma descrição textual para um LSP, inclua a description instrução em qualquer um dos seguintes níveis de hierarquia:

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure o dispositivo para comunicação de rede.

  • Ative MPLS nas interfaces de dispositivo.

  • Configure um LSP no domínio MPLS de segurança.

Para adicionar uma descrição de texto para um LSP:

  1. Insira qualquer texto que descreva o LSP.

    Por exemplo:

  2. Verificar e confirmar a configuração.

    Por exemplo:

  3. Veja a descrição de um LSP usando show mpls lsp detail o ou show mpls container-lsp detail o comando, dependendo do tipo de LSP configurado.

Configuração MPLS pré-configuração suave

Tentativas de preempção suaves para estabelecer um novo caminho para um LSP pré-candidato antes de derrubar o LSP original. O comportamento padrão é derrubar um LSP pré-candidato primeiro, sinalizar um novo caminho e reestabelecer o LSP pelo novo caminho. No intervalo entre quando o caminho é retirado e o novo LSP é estabelecido, qualquer tráfego que tenta usar o LSP é perdido. A prevenção branda impede esse tipo de perda de tráfego. A troca é que, durante o tempo em que um LSP está sendo pré-utilizado, dois LSPs com seus requisitos de largura de banda correspondentes são usados até o caminho original ser derrubado.

MPLS pré-adição suave é útil para a manutenção da rede. Por exemplo, você pode afastar todos os LSPs de uma interface específica e, em seguida, levar a interface para manutenção sem interromper o tráfego. MPLS preempção suave é descrita em detalhes na RFC 5712, MPLS Desaforode Engenharia de Tráfego .

A pré-adição suave é uma propriedade do LSP e é desabilitada por padrão. Você configurá-lo na entrada de um LSP incluindo a soft-preemption declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

Você também pode configurar um temporizador para pré-configuração suave. O temporizador designa o tempo de espera pelo roteador antes de iniciar uma pré-adição difícil do LSP. Ao final do tempo especificado, o LSP é derrubado e restituido. O temporizador de limpeza de pré-adição suave tem um valor padrão de 30 segundos; o intervalo de valores permitidos é de 0 a 180 segundos. Um valor de 0 significa que a pré-adição suave está desabilitada. O temporizador de limpeza de pré-adoção suave é global para todos os LSPs.

Configure o temporizador incluindo a cleanup-timer declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

Nota:

A pré-configuração suave não pode ser configurada em LSPs para os quais o rerrote rápido foi configurado. A configuração não se compromete. No entanto, você pode habilitar a pré-adição suave junto com a proteção de nó e enlace.

Nota:

O valor de conta para SoftPreemptionCnt inicializa com um valor de 0 (zero), visível na saída de show rsvp interface detail comando.

Configuração de prioridade e pré-configuração para LSPs

Quando não há largura de banda suficiente para estabelecer um LSP mais importante, é possível derrubar um LSP menos importante existente para liberar a largura de banda. Você faz isso com a pré-adoção do LSP existente.

Se um LSP pode ser pré-definido é determinado por duas propriedades associadas ao LSP:

  • Prioridade de configuração — Determina se um novo LSP que preempia um LSP existente pode ser estabelecido. Para que a pré-configuração ocorra, a prioridade de configuração do novo LSP deve ser maior do que a do LSP existente. Além disso, o ato de se opor ao LSP existente precisa produzir largura de banda suficiente para dar suporte ao novo LSP. Ou seja, a pré-adição só ocorre se o novo LSP puder ser criado com sucesso.

  • Prioridade de reserva — Determina o grau de reserva de um LSP após a configuração do LSP com sucesso. Quando a prioridade de reserva é alta, a LSP existente tem menos probabilidade de abrir mão de sua reserva, e, portanto, é pouco provável que o LSP possa ser pré-candidato.

Você não pode configurar um LSP com uma alta prioridade de configuração e uma prioridade de reserva baixa, porque loops de pré-adição permanentes podem resultar se dois LSPs puderem se pré-se pré-se. Você deve configurar a prioridade da reserva para ser maior ou igual à prioridade de configuração.

A prioridade de configuração também define a importância relativa dos LSPs no mesmo roteador de entrada. Quando o software é iniciado, quando um novo LSP é estabelecido ou durante a recuperação de falhas, a prioridade de configuração determina a ordem na qual LSPs são atendidos. LSPs de maior prioridade tendem a ser estabelecidas em primeiro lugar e, portanto, desfrutam de uma seleção de caminhos mais ideal.

Para configurar as propriedades de pré-adição do LSP, inclua a priority instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações para esta declaração.

Ambos setup-priority podem ser um valor de reservation-priority 0 a 7. O valor 0 corresponde à maior prioridade, e o valor de 7 a mais baixa. Por padrão, um LSP tem uma prioridade de configuração de 7 (ou seja, não pode preempá-la a nenhum outro LSPs) e uma prioridade de reserva de 0 (ou seja, outros LSPs não podem preempá-la). Esses padrões são para que a pré-adição não ocorra. Ao configurar esses valores, a prioridade de configuração sempre deve ser inferior ou igual à prioridade hold.

Configuração de grupos administrativos para LSPs

Grupos administrativos, também conhecidos como coloração de enlace ou classe de recursos, são atributos atribuídos manualmente que descrevem a "cor" dos enlaces, de maneira que os enlaces com a mesma cor pertencem conceitualmente à mesma classe. Você pode usar grupos administrativos para implementar uma variedade de configurações de LSP baseadas em políticas.

Grupos administrativos só são significativos quando a computação de LSP de caminho restrito está ativada.

Você pode designar até 32 nomes e valores (na faixa de 0 a 31), que definem uma série de nomes e seus valores correspondentes. Os nomes e valores administrativos devem ser idênticos em todos os roteadores em um único domínio.

Nota:

O valor administrativo é distinto da prioridade. Você configura a prioridade para um LSP usando a priority declaração. Consulte a configuração de prioridade e a pré-configuração para LSPs.

Para configurar grupos administrativos, siga essas etapas:

  1. Defina vários níveis de qualidade do serviço incluindo a admin-groups declaração:

    Você pode incluir essa declaração nos seguintes níveis de hierarquia:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    O exemplo de configuração a seguir ilustra como você pode configurar um conjunto de nomes e valores administrativos para um domínio:

  2. Defina os grupos administrativos aos quais uma interface pertence. Você pode designar vários grupos para uma interface. Inclua a interface declaração:

    Você pode incluir essa declaração nos seguintes níveis de hierarquia:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    Se você não incluir a admin-group declaração, uma interface não pertence a nenhum grupo.

    Os IGPs usam as informações de grupo para criar pacotes de estado de enlace, que são inundados por toda a rede, fornecendo informações a todos os nós da rede. Em qualquer roteador, a IGP de dados, bem como grupos administrativos de todos os links, está disponível.

    Alterar o grupo administrativo da interface afeta apenas novos LSPs. Os LSPs existentes na interface não são pré-excluídos ou recomputados para manter a rede estável. Caso os LSPs precisem ser removidos por causa de uma mudança de grupo, emirói o clear rsvp session comando.

    Nota:

    Ao configurar grupos administrativos e grupos administrativos estendidos juntos para um enlace, ambos os tipos de grupos administrativos precisam ser configurados na interface.

  3. Configure uma restrição de grupo administrativo para cada LSP ou para cada caminho LSP principal ou secundário. Inclua a label-switched-path declaração:

    Você pode incluir a label-switched-path declaração nos seguintes níveis de hierarquia:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    Se você omitir as declarações ou as declarações, a computação de caminho include-allinclude-anyexclude seguirá inalterada. A computação de caminho é baseada na computação LSP de caminho restrito. Para obter informações sobre como a computação LSP de caminho restrito é calculada, consulte Como o CSPF escolhe um caminho.

    Nota:

    Alterar o grupo administrativo do LSP faz com que a rota seja recomputada imediatamente; portanto, o LSP pode ser recaminhado.

Configuração de grupos administrativos estendidos para LSPs

Na engenharia de tráfego de MPLS, um enlace pode ser configurado com um conjunto de grupos administrativos (também conhecidos como classes de cores ou recursos). Os grupos administrativos são carregados no protocolo de gateway interior (IGP) (OSPFv2 e IS-IS) como um valor de 32 bits atribuído a cada enlace. Juniper Networks normalmente interpretam esse valor de 32 bits como uma máscara de bit com cada bit representando um grupo, limitando cada rede a um total de 32 grupos administrativos distintos (intervalo de valor de 0 a 31).

Você configura grupos administrativos estendidos, representados por um valor de 32 bits, expandindo o número de grupos administrativos suportados na rede para além de apenas 32. A variedade original de valores disponíveis para grupos administrativos ainda é compatível com compatibilidade reversa.

A configuração de grupos administrativos estendidos aceita um conjunto de interfaces com um conjunto correspondente de nomes de grupos administrativos estendidos. Ele converte os nomes em um conjunto de valores de 32 bits e propaga essas informações no IGP. Os valores de grupo administrativo estendido são globais e precisam ser configurados de maneira idenada em todos os roteadores suportados que participam da rede. O banco de dados de grupos administrativos estendidos em toda a área, aprendida com outros roteadores por meio de IGP flooding, é usado pelo CSPF (Shortest Path First, caminho mais curto restrito) para computação de caminhos.

O procedimento a seguir descreve como configurar grupos administrativos estendidos:

  1. Configure a admin-groups-extended-range declaração:

    Você pode incluir essa declaração nos seguintes níveis de hierarquia:

    • [edit routing-options]

    • [edit logical-systems logical-system-name routing-options]

    A admin-groups-extended-range declaração inclui as e as minimummaximum opções. O intervalo máximo deve ser maior do que o mínimo de alcance.

  2. Configure a admin-groups-extended declaração:

    Você pode incluir essa declaração nos seguintes níveis de hierarquia:

    • [edit routing-options]

    • [edit logical-systems logical-system-name routing-options]

    A admin-groups-extended declaração permite configurar um nome de grupo e valor de grupo para o grupo administrativo. O valor do grupo deve estar dentro do intervalo de valores configurados usando a admin-groups-extended-range instrução.

  3. Os grupos administrativos estendidos para MPLS interface de rede consistem no conjunto de nomes de grupos administrativos estendidos atribuídos à interface. Os nomes de grupos administrativos estendidos da interface precisam estar configurados para grupos administrativos globais estendidos.

    Para configurar um grupo administrativo estendido para uma interface MPLS, especifique o nome do grupo administrativo na configuração MPLS interface usando a admin-groups-extended instrução:

    Você pode incluir essa declaração nos seguintes níveis de hierarquia:

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

  4. Os grupos administrativos estendidos por LSP definem o conjunto de restrições de inclusão e exclusão de um LSP e dos caminhos principais e secundários de um caminho. Os nomes de grupos administrativos estendidos precisam estar configurados para os grupos administrativos globais estendidos.

    Para configurar grupos administrativos estendidos para um LSP, inclua a declaração em um nível de admin-group-extended hierarquia LSP:

    A admin-group-extended declaração inclui as seguintes opções: apply-groups, apply-groups-exceptexclude e include-allinclude-any . Cada opção permite configurar um ou mais grupos administrativos estendidos.

    Para a lista dos níveis de hierarquia nos quais você pode configurar esta declaração, consulte o resumo da declaração para esta declaração.

  5. Para exibir os grupos administrativos estendidos atualmente configurados, eminde o show mpls admin-groups-extended comando.
Nota:

Ao configurar grupos administrativos e grupos administrativos estendidos juntos para um enlace, ambos os tipos de grupos administrativos precisam ser configurados na interface.

Configurando valores de preferência para LSPs

Como opção, você pode configurar vários LSPs entre o mesmo par de roteadores de entrada e saída. Isso é útil para equilibrar a carga entre os LSPs, porque todos os LSPs, por padrão, têm o mesmo nível de preferência. Para preferir um PSL em vez de outro, dete diferentes níveis de preferência para LSPs individuais. O LSP com o menor valor de preferência é usado. A preferência padrão por LSPs de RSVP é de 7 e para LSPs LDP é de 9. Esses valores de preferência são mais baixos (mais preferidos) do que todas as rotas aprendidas, exceto rotas de interface diretas.

Para alterar o valor de preferência padrão, inclua a preference instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações para esta declaração.

Desativação da gravação da rota do caminho por LSPs

A implementação do Junos de RSVP tem suporte para o objeto Record Route, que permite a um LSP registrar ativamente os roteadores por onde ele passa. Você pode usar essas informações para solucionar problemas e evitar loops de roteamento. Por padrão, as informações de rota do caminho são registradas. Para desativar a gravação, inclua a no-record declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir as e declarações, consulte a seção resumo da declaração recordno-record para a declaração.

Conquista de uma switchover sem sucesso para LSPs

Os caminhos comutado de rótulo (LSPs) adaptáveis podem precisar estabelecer uma nova instância de LSP e transferir o tráfego de uma instância LSP antiga para a nova instância LSP antes de derrubar a antiga. Esse tipo de configuração é chamada de make before break (MBB).

RSVP-TE é um protocolo usado para estabelecer LSPs em MPLS redes. A implementação do Junos OS do RSVP-TE para alcançar uma comover MBB sem perda de tráfego (sem perda de tráfego) dependia da configuração dos valores do temporizador nas seguintes declarações de configuração:

  • optimize-switchover-delay— Tempo de espera antes de mudar para a nova instância LSP.

  • optimize-hold-dead-delay— Tempo de espera após a comover e antes da exclusão da instância LSP antiga.

As declarações e as declarações aplicam-se a todos os LSPs que usam o comportamento optimize-switchover-delay de make-before-break para configuração e rebaixamento de LSP, não apenas para LSPs para os quais a instrução também optimize-hold-dead-delayoptimize-timer foi configurada. Os recursos MPLS a seguir fazem com que LSPs sejam configuradas e destruídas usando-se o comportamento make-before-break:

  • LSPs adaptáveis

  • Alocação automática de largura de banda

  • BFD para LSPs

  • Switchover graceful Mecanismo de Roteamento

  • Proteção de enlaces e nós

  • Roteamento ativo sem parar

  • LSPs otimizados

  • LSPs ponto a multipoint (P2MP)

  • Pré-adição suave

  • Caminhos secundários em espera

As declarações optimize-switchover-delay e as declarações quando optimize-hold-dead-delay configuradas adicionam um atraso artificial ao processo MBB. O valor da declaração varia de acordo com o tamanho dos Objetos de Rota optimize-switchover-delay Explícitos (EROs). Um ERO é uma extensão para RSVP que permite que uma mensagem de CAMINHO RSVP atravesse uma sequência explícita de roteadores que é independente do roteamento IP de caminho mais curto convencional. O valor da optimize-switchover-delay instrução também depende da carga da CPU em cada um dos roteadores do caminho. Os clientes definiram optimize-switchover-delay a declaração por avaliação e erro.

O valor da declaração depende da rapidez com que o roteador de entrada move todos os prefixos de aplicativos para apontar optimize-hold-dead-delay para o novo LSP. Isso é determinado pela carga Mecanismo de Encaminhamento de Pacotes, que pode variar de plataforma para plataforma. Os clientes têm que definir a optimize-hold-dead-delay declaração por avaliação e erro.

Porém, a partir da versão 15.1, o Junos OS consegue conquistar uma comover MBB sem configurar os atrasos artificiais que esses valores de temporizador introduzem.

Este tópico sintetiza os três métodos para obter uma comover MBB de um LSP antigo para um novo LSP usando o Junos OS:

Especificando o tempo que o roteador espera para mudar para novos caminhos

Para especificar o tempo que o roteador espera para alternar as instâncias de LSP para os caminhos recém-otimizados, use a optimize-switchover-delay instrução. Você só precisa configurar essa instrução nos roteadores que atuam como a entrada para os LSPs afetados (você não precisa configurar essa instrução em roteadores de trânsito ou saída). O temporizador nesta declaração ajuda a garantir que os novos caminhos otimizados tenham sido estabelecidos antes que o tráfego seja comutado dos caminhos antigos. Esse temporizador só pode ser ativado ou inválido para todos os LSPs configurados no roteador.

Para configurar o tempo que o roteador espera para alternar as instâncias de LSP para os caminhos recém-otimizados, especifique o tempo em segundos usando a optimize-switchover-delay instrução:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Especificando a quantidade de tempo para retardar a derrubada de caminhos antigos

Para especificar a quantidade de tempo para retardar a desaforamento de caminhos antigos depois que o roteador alternou o tráfego para novos caminhos otimizados, use a optimize-hold-dead-delay declaração. Você só precisa configurar essa instrução nos roteadores que atuam como a entrada para os LSPs afetados (você não precisa configurar essa instrução em roteadores de trânsito ou saída). O temporizador nesta declaração ajuda a garantir que caminhos antigos não sejam derrubados antes de todas as rotas ter sido trocadas para os novos caminhos otimizados. Esse temporizador pode ser ativado para LSPs específicos ou para todos os LSPs configurados no roteador.

Para configurar a quantidade de tempo em segundos para retardar a derrubada de caminhos antigos depois que o roteador alternou o tráfego para novos caminhos otimizados, use a optimize-hold-dead-delay instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações para esta declaração.

Alcançar um switchover MBB sem sucesso sem atrasos artificiais

A partir da versão 15.1 do Junos OS, há outra maneira de abrir mão das instâncias LSP antigas após a comover MBB sem depender dos intervalos de tempo arbitrários definidos pela optimize-switchover-delay ou optimize-hold-dead-delay declaração. Por exemplo, se você usar a declaração, configurará uma hora em que considera seguro esperar antes de derrubar a instância optimize-hold-dead-delay LSP antiga após o MBB. Entretanto, algumas rotas ainda podem estar em processo de mudança para a nova instância. Derrubar a instância LSP antiga resulta precipitadamente em um dos nós de trânsito que rebate o tráfego para as rotas que não mudaram para a nova instância LSP.

Para evitar perda de tráfego, em vez de usar a instrução, você pode usar optimize-switchover-delay o MPLS-OAM (lsp ping), que confirma que o plano de dados LSP está estabelecido de ponta a ponta. Em vez de usar a instrução, você pode usar um mecanismo de feedback da infraestrutura rpd que confirma que todos optimize-hold-dead-delay os prefixos referentes ao LSP antigo foram repassados. O mecanismo de feedback é origem da biblioteca de tags e depende da infraestrutura do processo de protocolo de roteamento (rpd) para determinar quando todas as rotas que usam a instância LSP antiga mudaram totalmente para a nova instância LSP após a comover do MBB.

O mecanismo de feedback está sempre no local, e é opcional. Configure a optimize-adaptive-teardown declaração para que o mecanismo de feedback seja usado durante a comover MBB. Esse recurso não é suportado para instâncias de LSP de RSVP point-to-multipoint (P2MP). A configuração global da instrução afeta apenas os LSPs ponto a ponto optimize-adaptive-teardown configurados no sistema.

Você só precisa configurar a instrução nos roteadores que atuam como a entrada para os LSPs afetados (você não precisa configurar essa instrução em roteadores de trânsito ou optimize-adaptive-teardown saída). Esse mecanismo de feedback garante que os caminhos antigos não sejam derrubados antes de todas as rotas mudarem para os novos caminhos otimizados. A configuração global desta instrução de configuração afeta apenas os LSPs ponto a ponto configurados no sistema.

Você pode incluir essa declaração em nível [edit protocols mpls] de hierarquia.

Otimização de LSPs sinalização

Uma vez estabelecido um LSP, a topologia ou as mudanças de recursos podem, com o tempo, tornar o caminho suboportado. Um novo caminho pode ter se disponibilizado, que seja menos congestionado, tenha uma métrica inferior e atravesse menos hops. Você pode configurar o roteador para recomputar caminhos periodicamente para determinar se um caminho mais ideal se tornou disponível.

Se a reoptimização estiver ativada, um LSP pode ser recaminhado por caminhos diferentes por recomputações de caminho restrito. No entanto, se a reoptimização for desabilitada, o LSP terá um caminho fixo e não poderá se aproveitar dos novos recursos de rede disponíveis. O LSP fica fixo até que a próxima mudança de topologia rompa o LSP e força uma recomputação.

A reoptimização não está relacionada ao failover. Um novo caminho é sempre computado quando ocorrem falhas de topologia que rompem um caminho estabelecido.

Devido à sobrecarga potencial do sistema envolvida, você precisa controlar cuidadosamente a frequência de reoptimização. A estabilidade da rede pode sofrer quando a reotimização estiver ativada. Por padrão, optimize-timer a instrução é definida como 0 (ou seja, ela está desabilitada).

A otimização de LSP só é significativa quando a computação LSP de caminho restrito está ativada, que é o comportamento padrão. Para obter mais informações sobre a computação LSP de caminho restrito, consulte Desativação daComputação LSP de Caminho Restrito . Além disso, a otimização de LSP só é aplicável a LSPs de entrada, portanto, só é necessário configurar a instrução no roteador optimize-timer de entrada. Os roteadores de trânsito e de saída não precisam de configuração específica para dar suporte à otimização de LSP (além de MPLS ativados).

Para habilitar a reotimização do caminho, inclua a optimize-timer declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações para esta declaração.

Depois de configurar a instrução, o temporizador de reoptimização continua sua contagem regressiva para o valor configurado, mesmo se você excluir a optimize-timeroptimize-timer instrução da configuração. A próxima otimização usa o novo valor. Você pode obrigar o Junos OS a usar um novo valor imediatamente, excluindo o valor antigo, comprometendo a configuração, configurando o novo valor da instrução e, em seguida, comprometendo a configuração optimize-timer novamente.

Após a reoptimização ser executado, o resultado só será aceito se atender aos seguintes critérios:

  1. O novo caminho não é maior na IGP métrica. (A métrica do caminho antigo é atualizada durante a computação, portanto, se uma métrica de enlace recente mudou em algum lugar ao longo do caminho antigo, ela é contabilização.)

  2. Se o novo caminho tiver a mesma IGP, ele não terá mais saltos.

  3. O novo caminho não causa pré-adoção. (Isso reduz o efeito de onda da pré-adição causando mais preempção.)

  4. O novo caminho não piora o congestionamento no geral.

    O congestionamento relativo do novo caminho é determinado da seguinte forma:

    1. A porcentagem da largura de banda disponível em cada enlace atravessado pelo novo caminho é comparada com a do caminho antigo, a partir dos enlaces mais congestionados.

    2. Para cada caminho atual (antigo), o software armazena os quatro menores valores para disponibilidade de largura de banda para os links atravessados em ordem crescente.

    3. O software também armazena os quatro menores valores de disponibilidade de largura de banda para o novo caminho, correspondentes aos links atravessados em ordem crescente.

    4. Se algum dos quatro novos valores de largura de banda disponíveis for menor do que qualquer um dos valores de disponibilidade da largura de banda antigos correspondentes, o novo caminho terá pelo menos um enlace mais congestionado do que o link usado pelo caminho antigo. Como o uso do enlace causaria mais congestionamento, o tráfego não é comutado para esse novo caminho.

    5. Se nenhum dos quatro novos valores de largura de banda disponíveis for menor do que os valores de disponibilidade da largura de banda antigos correspondentes, o novo caminho ficará menos congestionado do que o antigo caminho.

Quando todas as condições acima são atendidas, então:

  1. Caso o novo caminho tenha uma métrica IGP inferior, ele é aceito.

  2. Caso o novo caminho tenha uma métrica IGP igual e uma contagem de hop inferior, ele é aceito.

  3. Se você escolher least-fill como um algoritmo de balanceamento de carga, os LSPs serão balanceados da seguinte forma:

    1. O LSP é transferido para um novo caminho que é usado pelo menos 10% menos do que o caminho atual. Isso pode reduzir o congestionamento no caminho atual em apenas uma pequena quantidade. Por exemplo, se um LSP com 1 MB de largura de banda for transferido de um caminho que transporta no mínimo 200 MB, o congestionamento no caminho original será reduzido em menos de 1%.

    2. Para random ou most-fill algoritmos, essa regra não se aplica.

    O exemplo a seguir ilustra como funciona o least-fill algoritmo de balanceamento de carga.

    Figura 1: Exemplo de algoritmo de balanceamento de carga de menos preenchimentoExemplo de algoritmo de balanceamento de carga de menos preenchimento

    Como mostrado em , existem dois caminhos em potencial para um LSP atravessar do roteador A ao roteador H, os links ímpares de L1 a L13 e os links mesmo de L2 a Figura 1 L14. No momento, o roteador está usando os links mesmo como o caminho ativo para o LSP. Cada enlace entre os mesmos dois roteadores (por exemplo, o roteador A e o roteador B) tem a mesma largura de banda:

    • L1, L2 = 10GE

    • L3, L4 = 1GE

    • L5, L6 = 1GE

    • L7, L8 = 1GE

    • L9, L10 = 1GE

    • L11, L12 = 10GE

    • L13, L14 = 10GE

    Os links 1GE têm mais probabilidade de serem congestionados. Neste exemplo, os links 1GE ímpares têm a seguinte largura de banda disponível:

    • L3 = 41%

    • L5 = 56%

    • L7 = 66%

    • L9 = 71%

    Os links mesmo 1GE têm a seguinte largura de banda disponível:

    • L4 = 37%

    • L6 = 52%

    • L8 = 61%

    • L10 = 70%

    Com base nas informações, o roteador calcularia a diferença na largura de banda disponível entre os links ímpares e os links mesmo assim:

    • L4 - L3 = 41% - 37% = 4%

    • L6 - L5 = 56% - 52% = 4%

    • L8 - L7 = 66% - 61% = 5%

    • L10 - L9 = 71% - 70% = 1%

    A largura de banda adicional total disponível nos links ímpares é de 14% (4% + 4% + 5% + 1%). Como 14% é maior que 10% (o limiar mínimo do algoritmo de menor preenchimento), o LSP é transferido para o novo caminho nos links ímpares do caminho original usando os links even.

  4. Caso contrário, o novo caminho é recusado.

Você pode desativar os seguintes critérios de reotimização (um subconjunto dos critérios indicados anteriormente):

  • Se o novo caminho tiver a mesma IGP, ele não terá mais saltos.

  • O novo caminho não causa pré-adoção. (Isso reduz o efeito de onda da pré-adição causando mais preempção.)

  • O novo caminho não piora o congestionamento no geral.

  • Caso o novo caminho tenha uma métrica IGP igual e uma contagem de hop inferior, ele é aceito.

Para desativá-los, emito clear mpls lsp optimize-aggressive o comando ou inclui a optimize-aggressive declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Incluindo a optimize-aggressive declaração na configuração, o processo de reoptimização deve ser acionado com mais frequência. Os caminhos são recaminhados com mais frequência. Ele também limita o algoritmo de reoptimização apenas IGP métrica.

Configurando o temporizador de otimização inteligente para LSPs

Devido às restrições aos recursos da rede e do roteador, normalmente é inadvisível configurar um intervalo curto para o temporizador otimizado. No entanto, em determinadas circunstâncias, pode ser desejável reotimizar um caminho antes do que normalmente seria fornecido pelo temporizador de otimização.

Por exemplo, um LSP está atravessando um caminho preferido que depois falha. Em seguida, o LSP é comutado para um caminho menos desejável para chegar ao mesmo destino. Mesmo que o caminho original seja rapidamente restabelecido, pode levar muito tempo para o LSP usá-lo novamente, porque ele precisa esperar o temporizador otimizado para reotimizar os caminhos de rede. Para essas situações, é possível configurar o temporizador de otimização inteligente.

Ao habilitar o temporizador de otimização inteligente, um LSP volta ao caminho original, desde que o caminho original seja restabelecido em 3 minutos após o lançamento. Além disso, se o caminho original voltar a acontecer em 60 minutos, o temporizador de otimização inteligente será desabilitado, e a otimização do caminho se comporta como normalmente faz quando o temporizador otimizado está ativado. Isso impede que o roteador use um enlace de agitação.

O temporizador de otimização inteligente depende de outros recursos MPLS funcionar corretamente. Para o cenário descrito aqui em que um LSP é comutado para um caminho alternativo no caso de falha no caminho original, assume-se que você tenha configurado um ou mais recursos de proteção de tráfego da MPLS, incluindo reroute rápido, proteção de enlace e caminhos secundários em espera. Esses recursos ajudam a garantir que o tráfego possa chegar ao seu destino no caso de uma falha.

No mínimo, você deve configurar um caminho secundário em espera para que o recurso de temporizador inteligente e otimizado funcione de maneira adequada. Reroute rápido e proteção de enlace são soluções mais temporárias para uma paralisação na rede. Um caminho secundário garante que haja um caminho alternativo estável no caso de o caminho principal falhar. Caso você não tenha configurado qualquer tipo de proteção de tráfego para um LSP, o próprio temporizador de otimização inteligente não garante que o tráfego possa chegar ao seu destino. Para obter mais informações sobre MPLS de tráfego, consulte MPLS proteção do tráfego.

Quando um caminho principal falha e o inteligente otimiza o tráfego de switches de temporizador para o caminho secundário, o roteador pode continuar a usar o caminho secundário mesmo após o caminho principal ter sido restaurado. Se o roteador de entrada concluir um cálculo de CSPF, ele pode determinar que o caminho secundário é o melhor.

Isso pode ser indesejável se o caminho principal for o caminho ativo e se o caminho secundário for usado apenas como backup. Além disso, se o caminho secundário estiver sendo usado como o caminho ativo (embora o caminho principal tenha sido restabelecido) e o caminho secundário falhar, o recurso de temporizador otimizado inteligente não alterna automaticamente o tráfego de volta ao caminho principal. No entanto, você pode habilitar a proteção para o caminho secundário configurando proteção de nó e enlace ou um caminho secundário em espera adicional, nesse caso, o temporizador de otimização inteligente pode ser eficaz.

Especifique o tempo em segundos para o temporizador de otimização inteligente usando a smart-optimize-timer declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Limitando o número de hops em LSPs

Por padrão, cada LSP pode atravessar um máximo de 255 hops, incluindo os roteadores de entrada e saída. Para modificar esse valor, inclua a hop-limit declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações para esta declaração.

O número de hops pode ser de 2 a 255. (Um caminho com dois hops consiste apenas nos roteadores de entrada e saída.)

Configurando o valor da largura de banda para LSPs

Cada LSP tem um valor de largura de banda. Esse valor está incluído no campo Tspec do remetente em mensagens de configuração de caminho RSVP. Você pode especificar um valor de largura de banda em bits por segundo. Se você configurar mais largura de banda para um LSP, ele deve ser capaz de transportar um maior volume de tráfego. A largura de banda padrão é de 0 bits por segundo.

Uma largura de banda não zero requer que os roteadores de trânsito e de saída reservem capacidade ao longo dos links de saída do caminho. O esquema de reserva de RSVP é usado para reservar essa capacidade. Qualquer falha na reserva de largura de banda (como falhas no controle de política de RSVP ou no controle de admissão) pode causar falha na configuração do LSP. Se não houver largura de banda insuficiente nas interfaces para roteadores de trânsito ou saída, o LSP não está estabelecido.

Para especificar um valor de largura de banda para um LSP sinalização, inclua a bandwidth instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações para esta declaração.

Alocação automática de largura de banda para LSPs

A alocação automática de largura de banda permite MPLS túnel para ajustar automaticamente sua alocação de largura de banda com base no volume de tráfego que flue pelo túnel. Você pode configurar um LSP com largura de banda mínima; esse recurso pode ajustar dinamicamente a alocação de largura de banda do LSP com base nos padrões de tráfego atuais. Os ajustes de largura de banda não interrompem o fluxo de tráfego pelo túnel.

Você configura um intervalo de amostra em um LSP configurado com alocação automática de largura de banda. A largura de banda média é monitorada durante esse intervalo. Ao final do intervalo, faz-se uma tentativa de sinalização de um novo caminho para o LSP, com a alocação de largura de banda definida como o valor médio máximo do intervalo amostral anterior. Se o novo caminho for estabelecido com sucesso e o caminho original for removido, o LSP será reatado para o novo caminho. Caso um novo caminho não seja criado, o LSP continuará a usar seu caminho atual até o final do próximo intervalo de amostra, quando outra tentativa é feita para estabelecer um novo caminho. Observe que você pode definir valores mínimos e máximos de largura de banda para o LSP.

Durante o intervalo de alocação automática de largura de banda, o roteador pode receber um aumento constante no tráfego (utilização crescente da largura de banda) em um LSP, o que pode causar congestionamento ou perda de pacote. Para evitar isso, você pode definir um segundo gatilho para expirar precipitadamente o temporizador de ajuste de largura de banda automático antes do fim do intervalo de ajuste atual.

Configurando a alocação automática de largura de banda para LSPs

A alocação automática de largura de banda permite MPLS túnel para ajustar automaticamente sua alocação de largura de banda com base no volume de tráfego que flue pelo túnel. Você pode configurar um LSP com largura de banda mínima, e esse recurso pode ajustar dinamicamente a alocação da largura de banda do LSP com base nos padrões de tráfego atuais. Os ajustes de largura de banda não interrompem o fluxo de tráfego pelo túnel.

Ao final do intervalo de tempo de alocação automática de largura de banda, a utilização da largura de banda média atual é comparada à largura de banda alocada para o LSP. Se o LSP precisar de mais largura de banda, uma tentativa é criar um novo caminho onde a largura de banda seja igual à média de uso atual. Se a tentativa for bem-sucedida, o tráfego do LSP é roteado pelo novo caminho e o caminho antigo é removido. Se a tentativa der errado, o LSP continuará a usar o caminho atual.

Nota:

Ao calcular o valor (em relação à LSP de entrada), a amostra coletada durante o make antes da ruptura (MBB) é ignorada para evitar resultados Max AvgBW imprecisos. A primeira amostra após um ajuste de largura de banda ou depois de uma alteração na ID LSP (independentemente da mudança de caminho), também é ignorada.

Se você tiver configurado proteção de enlace e nó para LSP e o tráfego tiver sido comutado para o LSP de bypass, o recurso de alocação de largura de banda automática continuará a operar e pegar amostras de largura de banda do LSP de bypass. Para o primeiro ciclo de ajuste da largura de banda, a utilização média máxima de largura de banda retirada do enlace original e do LSP protegido por nós é usada para ressignificar o LSP de bypass caso seja necessário mais largura de banda. (A proteção de enlace e nó não é suportada em switches da Série QFX.)

Se tiver configurado um reroute rápido para o LSP, talvez você não seja capaz de usar esse recurso para ajustar a largura de banda. Como os LSPs usam um estilo de reserva de filtro fixo (FF), quando um novo caminho é sinalizado, a largura de banda pode ser duplamente contada. A dupla contagem pode impedir que um LSP reroute rapidamente nunca mais ajuste sua largura de banda quando a alocação automática de largura de banda estiver ativada. (O reroute rápido não é suportado em switches da Série QFX.)

Para configurar a alocação automática de largura de banda, complete as etapas nas seguintes seções:

Nota:

Nos switches QFX10000, você só pode configurar a alocação automática de largura de banda em nível edit protocols mpls de hierarquia. Sistemas lógicos não são suportados.

Configurando ajustes otimizados de largura de banda automática para MPLS LSPs

A funcionalidade de largura de banda automática permite que os LSPs RSVP-TE, configurados diretamente ou criados automaticamente usando malha automática, reesforçam com base na taxa de tráfego. A taxa de tráfego realizada em cada LSP é medida coletando periodicamente amostras da taxa de tráfego. A frequência da coleta de estatísticas de tráfego é controlada por meio da instrução adjust-interval de configuração. O valor mínimo configurável é adjust-interval de um segundo. O reajuste dos LSPs é chamado de ajuste e a frequência dos ajustes é controlada pela adjust-interval instrução.

A partir da versão 20.4R1 Junos OS, o mínimo para um ajuste é reduzido para 150 segundos se as declarações atravessarem os valores de estouro ou limiar de fluxo adjust-intervalauto-bandwidthadjust-threshold-overflow-limitadjust-threshold-underflow-limit configurados.

No entanto, o mínimo adjust-interval para um ajuste é de auto-bandwidth 300 segundos se nenhuma amostra de estouro ou subfluxo for detectada.

Nas versões anteriores à versão do Junos OS 20.4R1, são 300 segundos em condições de estouro ou adjust-interval subfluxo.

Com a implementação da otimização do ajuste da largura de banda automática, a largura de banda do LSP diminui auto-bandwidth mais rapidamente. O roteador de borda de rótulo de ingresso (LER) é capaz de reagrecer em até 150 segundos por causa da redução, desde que a redução de uma MBB (Make-before-Break) antiga da instância de LSP seja realizada em adjust-threshold-overflow-limit 150 segundos.

Os requisitos para otimização da largura de banda automática são:

  • Reduza a probabilidade de mudança de rota LSP — isso reduz a probabilidade de mudança de rota LSP quando ocorre um ajuste de largura de banda automática.

  • Reduza a probabilidade de recaminhamento de LSP — isso reduz a probabilidade de recaminhamento do LSP devido aos LSPs de maior prioridade que demandam o mesmo recurso.

Para atender a esses requisitos, a otimização dos ajustes de largura de banda automática aceita as seguintes:

  1. In-place LSP Bandwidth Update— Permite que o roteador de borda de rótulo (LER) de entrada re use a ID LSP ao realizar mudança de largura de banda em um LSP intra-domínio.

    Nota:

    A atualização da largura de banda LSP no local não é aplicável a um LSP entre domínios.

    Em determinados cenários, o próximo salto da rota LSP transporta a largura de banda LSP direta ou indiretamente. Embora a atualização da largura de banda LSP local seja suportada nesses cenários, a melhoria do desempenho da funcionalidade é limitada devido à mudança na rota do LSP. Ou seja, devido à mudança na tabela de roteamento inet.3 após a largura de banda automática (MPLS Túnel). Por exemplo, o aprimoramento do desempenho é limitado quando você configura ou ambas as declarações:

    • auto-policing configurado em MPLS.

    • A opção bandwidth na instrução load-balance configurada em RSVP.

    Nota:

    A atualização da largura de banda de LSP no local por meio da rea utilidade LSP-ID falha e o LER de entrada aciona imediatamente o MBB com um novo LSP-ID se:

    • no-cspf está configurado para o LSP.

    • O LSP é controlado pelo Elemento de Computação de Caminhos (PCE).

    • O temporizador de otimização LSP dispara.

    • clear mpls lsp optimize-aggressive o comando é executado.

  2. Per-priority Subscription— Para utilizar os recursos da rede de maneira mais eficiente, a assinatura por prioridade permite configurar uma porcentagem menor de assinatura de RSVP para LSPs de prioridades inferiores e uma porcentagem maior de assinatura de RSVP para LSPs de prioridades mais altas.

    Por exemplo, em vez de definir a porcentagem de assinatura de RSVP como 90% para LSPs para todas as prioridades, você pode configurar uma porcentagem menor de assinatura de RSVP (digamos 75%) para LSPs de prioridades inferiores

Nota:

A assinatura por prioridade não interopera com engenharia de tráfego (DiffServ) de serviços diferenciados (DiffServ) que reconhece TE). A engenharia de tráfego consciente de serviços diferenciados (DiffServ) oferece compartilhamento mais flexível e estatístico de TE largura de banda do enlace do que a assinatura por prioridade.

To Configure In-place LSP Auto-bandwidth Resizing:

  1. Configure a interface do dispositivo para habilitar MPLS.
  2. Configure MPLS protocolo na interface.
  3. Configure MPLS e LSPs e configure a proteção de enlace para o LSP.
  4. Configure para o LSP para permitir ressarção automática de in-place-bandwidth-update LSP da largura de banda.
  5. Insira commit a partir do modo de configuração.

Verification

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

To Configure Per-priority Subscription:

  1. Configure o protocolo RSVP na interface.

  2. Configure o valor da assinatura da largura de banda para a interface. Pode ser um valor de 0 a 65.000 por cento. O valor da assinatura padrão é de 100 por cento.

  3. Configure a prioridade de assinatura na interface.

  4. Configure a porcentagem de assinatura para a prioridade.

  5. Insira commit a partir do modo de configuração.

Verification

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

Configurando relatórios de estatísticas automáticas de alocação de largura de banda para LSPs

A alocação automática de largura de banda permite MPLS túnel para ajustar automaticamente sua alocação de largura de banda com base no volume de tráfego que flue pelo túnel. Você pode configurar o dispositivo para coletar estatísticas relacionadas à alocação automática de largura de banda, completando as seguintes etapas:

  1. Para coletar estatísticas relacionadas à alocação automática de largura de banda, configure a auto-bandwidth opção statistics para a instrução em nível de [edit protocols mpls] hierarquia. Essas configurações aplicam-se a todos os LSPs configurados no roteador no qual você também configurou a auto-bandwidth instrução em nível [edit protocols mpls label-switched-path label-switched-path-name] de hierarquia.
  2. Especifique os para os arquivos usados para armazenar a saída MPLS filename operação de rastreamento usando a file opção. Todos os arquivos são colocados no /var/log diretório. Recomendamos que você coloque MPLS saída de rastreamento no mpls-log arquivo.
  3. Especifique o número máximo de arquivos de rastreamento usando a files number opção. Quando um arquivo de rastreamento nomeado chega ao seu tamanho máximo, ele é rebatizado, e assim por diante, até atingir o número máximo de arquivos trace-filetrace-file.0 de trace-file.1 rastreamento. Em seguida, o arquivo de rastreamento mais antigo é sobregravado.
  4. Especifique o intervalo para calcular a utilização média de largura de banda configurando um tempo em segundos usando a interval opção. Você também pode definir o intervalo de ajuste em um LSP específico configurando a interval opção no nível da [edit protocols mpls label-switch-path label-switched-path-name statistics] hierarquia.
    Nota:

    Para evitar ressalções desnecessárias dos LSPs, é melhor configurar um intervalo de ajuste de LSP com pelo menos três vezes mais tempo do que o intervalo de estatísticas de largura de banda MPLS de largura de banda automática. Por exemplo, se você configurar um valor de 3 MPLS 0 segundos para o intervalo de estatísticas de largura de banda automático (instrução no nível da hierarquia), você deve configurar um valor de pelo menos 90 segundos para o intervalo de ajuste LSP ( instrução no nível da interval[edit protocols mpls statistics]adjust-interval[edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] hierarquia).

  5. Para rastrear a alocação automática de largura de banda, inclua a autobw-state flag instrução para a MPLS traceoptions no nível [edit protocols mpls] da hierarquia.

    A configuração a seguir permite MPLS de rastreamento para alocação automática de largura de banda. Os registros de rastreamento são armazenados em um arquivo chamado auto-band-trace (o nome de arquivo é configurável pelo usuário):

  6. Usando o comando, você pode exibir o arquivo de estatísticas de alocação de largura de banda automática gerada ao configurar a instrução de largura de banda show logautomática (MPLS Estatísticas). A seguir mostra a saída do arquivo de log de amostra coletada de um arquivo de MPLS estatísticas nomeado em um roteador configurado com auto-band-stats um LSP nomeado E-D . O arquivo de log mostra inicialmente que o LSP E-D está funcionando acima do limite de largura de banda reservado. Antes, o roteador acionou um ajuste automático de largura de banda (pode-se ver duas sessões para um LSP passando por um ajuste automático da largura Oct 30 17:14:57 de banda). Por fim, o LSP foi restabelecido com uma largura de banda maior e agora é mostrado usando menos de 100 por cento de sua largura de banda (largura de banda Oct 30 17:16:57Reserved Bw reserva).
  7. Eme o comando show mpls lsp autobandwidth para exibir informações atuais sobre a alocação automática de largura de banda. A seguir mostra a saída da amostra do comando tomada ao mesmo tempo do show mpls lsp autobandwidth arquivo de log mostrado anteriormente:
  8. Emito o file show comando para exibir o arquivo MPLS rastreamento. Você precisa especificar o local do arquivo e o nome do arquivo (o arquivo está localizado em /var/log/ . A seguinte mostra que a saída do arquivo de rastreamento da amostra é coletada de um arquivo MPLS de rastreamento nomeado em um auto-band-trace.0.gz roteador configurado com um LSP nomeado E-D . O arquivo de rastreamento mostra que o LSP E-D está funcionando acima de seu limite de largura de banda reservado inicialmente. No , o roteador aciona um ajuste automático de largura de banda (pode-se ver duas sessões para um LSP que sofre um ajuste automático da largura Oct 30 17:15:26 de banda). Por fim, o LSP foi restabelecido com uma largura de banda maior e agora é mostrado usando menos de 100 por cento de sua largura de banda (largura de banda Oct 30 17:15:57Reserved Bw reserva).

Configurando um LSP em ASs

Você pode configurar um LSP para atravessar várias áreas em uma rede, incluindo inter-domain a instrução como parte da configuração LSP. Essa declaração permite que o roteador pesquise rotas no IGP banco de dados. Você precisa configurar essa instrução em roteadores que pode não conseguir localizar um caminho usando CSPF intra-domínio (olhando o banco de dados de engenharia de tráfego (TED)). Quando você configura LSPs entre áreas, inter-domain a instrução é necessária.

Antes de começar:

  • Configure as interfaces do dispositivo com as MPLS.

  • Configure a ID do roteador do dispositivo e o número do sistema autônomo.

  • Ative MPLS e RSVP no roteador e nas interfaces de trânsito.

  • Configure sua IGP para dar suporte à engenharia de tráfego.

  • Configurar um LSP desde a entrada até o roteador de saída.

Para configurar um LSP em vários ASs no roteador de entrada comutado por rótulos (LER):

  1. Habilita MPLS todas as interfaces (exceto a interface de gerenciamento).
  2. Ative o RSVP em todas as interfaces (exceto a interface de gerenciamento).
  3. Configure o LSP entre áreas.
  4. Verificar e confirmar a configuração.

Anúncio de amortecimento de alterações de estado do LSP

Quando um LSP muda de estar ativo ou de baixo para cima, essa transição entra em vigor imediatamente no software e no hardware do roteador. Entretanto, quando anunciar LSPs em IS-IS e OSPF, você pode querer amortecer as transições de LSP, não anunciando assim a transição até que um certo período de tempo tenha transposto (conhecido como tempo de espera). Nesse caso, se o LSP for de cima para baixo, o LSP não será anunciado como um down até permanecer em baixa durante o período de espera. As transições de baixo para cima são anunciadas em IS-IS e OSPF imediatamente. Observe que o amortecimento de LSP afeta apenas os IS-IS e OSPF anúncios do LSP; outros softwares e hardware de roteamento reagem imediatamente às transições de LSP.

Para transições de LSP a fim de atenuar, inclua a advertisement-hold-time declaração:

seconds pode ser um valor de 0 a 65.535 segundos. O padrão é de 5 segundos.

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Configuração de LSPs bidirecionais corouted

Um pacote bidirecional corouted é uma combinação de dois LSPs que compartilham o mesmo caminho entre um par de nós de entrada e saída, como mostrado em Figura 2 . Ele é estabelecido usando as extensões GMPLS para RSVP-TE. Esse tipo de LSP pode ser usado para transportar qualquer um dos tipos padrão de tráfego baseado em MPLS, incluindo VPNs de Camada 2, circuitos de Camada 2 e VPNs de Camada 3. Você pode configurar uma única sessão BFD para o LSP bidirecional (você não precisa configurar uma sessão BFD para cada LSP em cada direção). Você também pode configurar um único LSP bidirecional em standby para fornecer um backup para o LSP bidirecional principal. LSPs bidirecionais corouted são suportados para penúltimo hop popping (PHP) e ultimate hop popping (UHP).

Alta disponibilidade está disponível para LSPs bidirecionais. Você pode habilitar o roteamento ativo de reinicialização e sem parar. O roteamento ativo de reinicialização e sem escalas é suportado quando o roteador de reinicialização é o roteador de entrada, saída ou trânsito para o LSP bidirecional.

Figura 2: LSP bidirecional coroutedLSP bidirecional corouted

Para configurar um LSP bidirecional corouted:

  1. No modo de configuração, configure o roteador de ingresso no LSP e inclua a instrução para especificar que o LSP seja estabelecido como um corouted-bidirectional LSP bidirecional corouted.

    O caminho é computado usando CSPF e iniciado usando sinalização RSVP (assim como um LSP com sinal de RSVP unidirecional). O caminho até o roteador de saída e o caminho reverso do roteador de saída são criados quando essa configuração é comprometida.

  2. (Opcional) Para um caminho inverso, configure um LSP no roteador de saída e inclua a instrução para associar o corouted-bidirectional-passive LSP a outro LSP.

    Nenhuma computação ou sinalização de caminho é usada para esse LSP, uma vez que ela depende da computação e da sinalização de caminho fornecidas pelo LSP de entrada. Você não pode configurar a corouted-bidirectional instrução e corouted-bidirectional-passive a instrução no mesmo LSP.

    Essa declaração também facilita depurar LSPs bidirecionais e depurados. Se você configurar a instrução (mais uma vez, no roteador de saída), você pode emitir , , e comandos para testar o corouted-bidirectional-passiveping mpls lsp-end-pointping mpls ldpping mpls rsvptraceroute mpls ldptraceroute mpls rsvp LSP bidirecional corouted do roteador de saída.

  3. Use os show mpls lsp extensive comandos e os comandos para exibir informações sobre o show rsvp session extensive LSP bidirecional.

    A seguir mostra a saída para o comando quando executado em um roteador de entrada com um show rsvp session extensive LSP bidirecional configurado:

Configurando o rótulo entropy para LSPs

A inserção de rótulos de entropia para um LSP permite que roteadores de trânsito equilibrem o tráfego MPLS entre os caminhos de ECMP ou grupos de agregação de enlaces usando apenas a pilha de rótulos MPLS como uma entrada hash sem depender de inspeção profunda de pacotes. A inspeção profunda de pacotes requer mais do poder de processamento do roteador, e diferentes roteadores têm diferentes recursos de inspeção de pacotes profundos.

Para configurar o rótulo de entropia para um LSP, complete as seguintes etapas:

  1. No roteador de entrada, inclua a entropy-label instrução no nível [edit protocols mpls labeled-switched-path labeled-switched-path-name] da hierarquia ou no nível da [edit protocols mpls static-labeled-switched-path labeled-switched-path-name ingress] hierarquia. O rótulo de entropy é adicionado à pilha MPLS rótulos e pode ser processado no plano de encaminhamento.
    Nota:

    Isso só é aplicável para RSVP e LSPs estáticos.

  2. No roteador de entrada, você pode configurar uma política de entrada para LSPs com sinal de LDP:

    Configure a política de ingresso no nível [edit policy-options] da hierarquia:

    A seguir, mostra um exemplo de uma política de entrada de rótulos de entropy.

  3. (Opcional) Por padrão, os roteadores que suportam o uso e o estouro de rótulos de entropy estão configurados com a instrução no nível da hierarquia para sinalizar os rótulos de acordo com load-balance-label-capability[edit forwarding-options] o LSP. Caso o roteador de peer não esteja equipado para lidar com rótulos de balanceamento de carga, você pode impedir que o roteador da borda do provedor (PE) sinalize a capacidade do rótulo de entropia configurando a instrução no nível no-load-balance-label-capability[edit forwarding-options] da hierarquia.

Os roteadores de trânsito não precisam de configuração. A presença do rótulo de entropia indica ao roteador de trânsito carregar o saldo com base unicamente na pilha MPLS rótulos.

Os roteadores de salto penúltimos pop o rótulo de entropia por padrão.

Exemplo: Configurando um rótulo de entropia para um BGP unicast LSP rótulo

Este exemplo mostra como configurar um rótulo de entropia para um BGP unicast identificado para obter balanceamento de carga de ponta a ponta usando rótulos de entropia. Quando um pacote IP tem vários caminhos para chegar ao seu destino, o Junos OS usa determinados campos dos headers de pacote para hash-lo em um caminho determinístico. Isso requer um rótulo de entropia, um rótulo especial de balanceamento de carga que pode transportar as informações de fluxo. LSRs no núcleo simplesmente usam o rótulo de entropia como a chave para haxixer o pacote até o caminho correto. Um rótulo de entropia pode ser qualquer valor de rótulo entre 16 e 1048575 (intervalo regular de rótulos de 20 bits). Uma vez que esse intervalo se sobrepõe à variedade de rótulos regulares existente, um rótulo especial chamado indicador de rótulo de entropia (ELI) é inserido antes do rótulo de entropia. ELI é um rótulo especial atribuído pela IANA com o valor de 7.

BGP unicasts identificados geralmente concatenam RSVP ou LDP LSPs em várias áreas IGP áreas ou vários sistemas autônomos. Rótulos de entropia de RSVP ou LDP são lançados no penúltimo nó de hop, junto com o rótulo RSVP ou LDP. Esse recurso permite o uso de rótulos de entropia nos pontos de costura para ponte entre o penúltimo nó de hop e o ponto de costura, a fim de obter balanceamento de carga de rótulos de entropia de ponta a ponta para BGP tráfego.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Sete roteadores da série MX com MPCs

  • Junos OS Release 15.1 ou mais tarde executado em todos os dispositivos

Antes de configurar um rótulo de entropia para BGP unicast, certifique-se de que:

  1. Configure as interfaces de dispositivo.

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

  3. Configure BGP.

  4. Configurar RSVP.

  5. Configure MPLS.

Visão geral

Quando BGP rótulos de unicasts concatenados RSVP ou LDP LSPs em várias áreas de IGP ou em vários sistemas autônomos, rótulos de entropia RSVP ou LDP são lançados no penúltimo nó de hop, junto com o rótulo RSVP ou LDP. No entanto, não há rótulos de entropia nos pontos de costura, ou seja, os roteadores entre duas áreas. Portanto, os roteadores nos pontos de costura usavam as BGP para encaminhamento de pacotes.

A partir da Versão 15.1 do Junos OS, você pode configurar um rótulo de entropia para BGP unicast etiquetado para obter balanceamento de carga de rótulo de entropia de ponta a ponta. Esse recurso permite o uso de um rótulo de entropia nos pontos de costura para conseguir balanceamento de carga de rótulos de entropia de ponta a ponta para BGP tráfego. O Junos OS permite a inserção de rótulos de entropia no BGP rótulos unicast LSP.

Por padrão, os roteadores que suportam rótulos de entropia estão configurados com a instrução no nível da hierarquia para sinalização dos rótulos load-balance-label-capability[edit forwarding-options] por LSP. Caso o roteador de peer não esteja equipado para lidar com rótulos de balanceamento de carga, você pode impedir a sinalização da capacidade do rótulo de entropy configurando-o no nível no-load-balance-label-capability[edit forwarding-options] da hierarquia.

Nota:

Você pode desativar explicitamente o recurso de rótulo de entropia de publicidade na saída para rotas especificadas na política com a no-entropy-label-capability opção no nível da [edit policy-options policy-statement policy name then] hierarquia.

Topologia

Em , o roteador PE1 é o roteador de entrada, e o roteador PE2 é o Figura 3 roteador de saída. Os roteadores P1 e P2 são os roteadores de trânsito. O roteador ABR é o roteador de ponte de área entre a Área 0 e a Área 1. O LAG está configurado nos roteadores do provedor para balanceamento de carga do tráfego. A capacidade do rótulo entropy para BGP unicast etiquetada está ativada no Roteador PE1 de entrada.

Figura 3: Configurando um rótulo de entropy para BGP UnicastConfigurando um rótulo de entropy para BGP Unicast

Configuração

Configuração rápida CLI

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

Roteador PE1

Roteador P1

Roteador ABR

Roteador P2

Roteador PE2

Configuração do roteador PE1

Procedimento passo a passo

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

Para configurar o roteador PE1:

Nota:

Repetir este procedimento para o Roteador PE2 depois de modificar os nomes, endereços e outros parâmetros de interface apropriados.

  1. Configure as interfaces com endereços IPv4 e IPv6.

  2. Configure a interface de loopback.

  3. Dede a ID do roteador e o número do sistema autônomo.

  4. Configure o protocolo RSVP para todas as interfaces.

  5. Ative MPLS em todas as interfaces do Roteador PE1 e especifique o LSP.

  6. Configure o IBGP nos roteadores internos.

  7. Ative a capacidade de rótulo de entropy para BGP unicast rótulo para ibgp BGP grupo interno.

  8. Ative o OSPF de segurança em todas as interfaces do roteador de borda da área (ABR).

  9. Defina listas de prefixo para especificar as rotas com o recurso de rótulo de entropy.

  10. Defina um EL de política para especificar as rotas com o recurso de rótulo de entropy.

  11. Defina outra política EL-2 para especificar as rotas com capacidade de rótulo de entropy.

  12. Defina uma política para BGP rotas até a tabela OSPF roteamento.

  13. Defina uma política para OSPF rotas até a tabela BGP roteamento.

  14. Defina uma política para exportar rotas estáticas para a tabela BGP roteamento.

  15. Configure um alvo de VPN para a comunidade de VPN.

  16. Configure a instância de roteamento VPN-l3vpn de Camada 3.

  17. Atribua as interfaces para a instância de roteamento VPN-l3vpn.

  18. Configure o diferencial de rota para a instância de roteamento VPN-l3vpn.

  19. Configure um alvo de roteamento e encaminhamento de VPN (VRF) para a instância de roteamento VPN-l3vpn.

  20. Configure uma rota estática para o dispositivo CE1 usando o protocolo VPN de Camada 3 para a instância de roteamento VPN-l3vpn.

  21. Exporte as BGP de roteamento OSPF para a instância de roteamento VPN-l3vpn.

  22. Atribua a OSPF de dados para a instância de roteamento VPN-l3vpn.

Configuração do roteador P1

Procedimento passo a passo

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

Para configurar o roteador P1:

Nota:

Repetir este procedimento para o roteador P2 após modificar os nomes, endereços e outros parâmetros de interface apropriados.

  1. Configure as interfaces com endereços IPv4 e IPv6.

  2. Configure a agregação de enlace nas interfaces.

  3. Configure a interface de loopback.

  4. Configure MPLS rótulos que o roteador usa para hashing dos pacotes até o seu destino para balanceamento de carga.

  5. Dede a ID do roteador e o número do sistema autônomo.

  6. Habilitar por balanceamento de carga de pacote.

  7. Configure o protocolo RSVP para todas as interfaces.

  8. Ative MPLS em todas as interfaces do roteador P1 e especifique o LSP.

  9. Ative o OSPF de segurança em todas as interfaces do Roteador P1, exceto na interface de gerenciamento.

  10. Defina uma política para cada balanceamento de carga de pacote.

Configurando o roteador ABR

Procedimento passo a passo

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

Para configurar o roteador ABR:

  1. Configure as interfaces com endereços IPv4 e IPv6.

  2. Configure a interface de loopback.

  3. Configure a agregação de enlace nas interfaces.

  4. Configure MPLS rótulos que o roteador usa para hashing dos pacotes até o seu destino para balanceamento de carga.

  5. Dede a ID do roteador e o número do sistema autônomo.

  6. Habilitar por balanceamento de carga de pacote.

  7. Configure o protocolo RSVP para todas as interfaces.

  8. Ative MPLS em todas as interfaces do roteador P1 e especifique o LSP.

  9. Configure o IBGP nos roteadores internos.

  10. Ative o OSPF de segurança em todas as interfaces da ABR.

  11. Defina uma política para especificar as rotas com o recurso de rótulo de entropy.

Resultados

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

Verificação

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

Verificar se a capacidade do rótulo da Entropy está sendo anunciada pelo Roteador PE2

Propósito

Verificar se o atributo do caminho do rótulo de entropia está sendo anunciado a partir do Roteador UPSTREAM PE2 na saída.

Ação

Do modo operacional, execute o show route 10.255.101.200 advertising-protocol bgp 10.255.102.102 comando no Roteador PE2.

Significado

A saída mostra que o host PE2 com o endereço IP de 10.255.101.200 tem a capacidade do rótulo de entropia. O host está anunciando a capacidade do rótulo de entropia para seus BGP vizinhos.

Verificar se a ABR do roteador recebe o anúncio do rótulo entropy

Propósito

Verificar se o roteador ABR recebe o anúncio de rótulo de entropia na entrada do Roteador PE2.

Ação

Do modo operacional, execute o show route 10.255.101.200 receiving-protocol bgp 10.255.101.200 comando no roteador ABR.

Significado

O roteador ABR recebe o anúncio de capacidade do rótulo de entropy de seu BGP vizinho PE2.

Verificar se a bandeira do rótulo da Entropy está definida

Propósito

Verificar se o sinal do rótulo de entropia está definido para os elementos de rótulo na entrada.

Ação

Do modo operacional, execute o show route protocol bgp detail comando no Roteador PE1.

Significado

Um rótulo de entropia é ativado no Roteador PE1. A saída mostra que o rótulo de entropia está sendo usado para o BGP unicast rótulo para obter balanceamento de carga de ponta a ponta.

Configurando o Ultimate-Hop Popping para LSPs

Por padrão, LSPs com sinal de RSVP usam penultimate-hop popping(PHP).Figura 4 ilustra um penúltimo salto entre o roteador PE1 e o roteador PE2. O roteador CE1 encaminha um pacote para seu próximo hop (Roteador PE1), que também é a entrada LSP. O roteador PE1 envia o rótulo 1 ao pacote e encaminha o pacote identificado ao roteador P1. O roteador P1 conclui a operação MPLS padrão de troca de rótulos, trocando o rótulo 1 pelo rótulo 2 e encaminha o pacote ao roteador P2. Como o roteador P2 é o penúltimo roteador de hop do LSP para o roteador PE2, primeiro ele pops o rótulo e depois encaminha o pacote para o roteador PE2. Quando o Roteador PE2 o recebe, o pacote pode ter um rótulo de serviço, um rótulo explicit-null ou apenas um pacote de IP ou VPLS simples. O roteador PE2 encaminha o pacote sem rótulo para o roteador CE2.

Figura 4: Penultimate-Hop Popping para um LSPPenultimate-Hop Popping para um LSP

Você também pode configurar o ultimate-hop popping(UHP)(como mostrado) para LSPs com sinal Figura 5 de RSVP. Alguns aplicativos de rede podem exigir que os pacotes cheguem ao roteador de saída (Roteador PE2) com um rótulo externo não nulo. Para um LSP de salto final, o penúltimo roteador (Roteador P2 in) realiza a operação de troca de rótulos padrão MPLS (neste exemplo, rótulo 2 para o rótulo 3 ) antes de encaminhá-lo ao roteador Figura 5 de saída PE2. O roteador PE2 revela o rótulo externo e realiza uma segunda busca no endereço do pacote para determinar o destino final. Em seguida, ele encaminha o pacote ao destino apropriado (roteador CE2 ou Roteador CE4).

Figura 5: Ultimate-Hop Popping para um LSPUltimate-Hop Popping para um LSP

Os seguintes aplicativos de rede exigem que você configure LSPs uhp:

  • MPLS-TP para monitoramento de desempenho e OAM dentro da banda

  • Circuitos virtuais de proteção de borda

Os seguintes recursos não suportam o comportamento do UHP:

  • LSPs com sinal LDP

  • LSPs estáticos

  • Point-to-multipoint LSPs

  • Ccc

  • traceroute Comando

Para obter mais informações sobre comportamento de UHP, consulte o draft da Internet-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, comportamento não PHP e Mapeamento fora da banda para LSPs RSVP-TE.

Para LSPs sinalização de RSVP ponto a ponto, o comportamento de UHP é sinalização da entrada LSP. Com base na configuração do roteador de entrada, o RSVP pode sinalizar o LSP do UHP com o conjunto de bandeiras não PHP. As mensagens RSVP PATH transportam as duas bandeiras no objeto LSP-ATTRIBUTES. Quando o roteador de saída recebe a mensagem PATH, ele atribua um rótulo não nulo ao LSP. O RSVP também cria e instala duas rotas na tabela de roteamento mpls.0. S refere-se ao bit S do rótulo MPLS, que indica se a base da pilha de rótulos foi alcançada ou não.

  • Rota S=0 — Indica que há mais rótulos na pilha. O próximo salto desta rota indica a tabela de roteamento mpls.0, acionando uma busca MPLS rótulos de MPLS encadeados para descobrir os rótulos de MPLS restantes na pilha.

  • Rota S=1 — Indica que não há mais rótulos. O próximo hop indica a tabela de roteamento inet.0 se a plataforma tiver suporte para a análise encadeada e multi-família. Como alternativa, a rota de rótulos pode apontar para uma interface VT para iniciar o encaminhamento ip.

Se você habilitar LSPs de UHP, MPLS aplicativos como VPNs de Camada 3, VPLS, VPNs de Camada 2 e circuitos de Camada 2 podem usar os LSPs do UHP. A seguir explica como os LSPs de UHP afeta os diferentes tipos de MPLS aplicativos:

  • Circuitos VPNs de Camada 2 e Camada 2 — Um pacote chega ao roteador PE (saída do LSP do UHP) com dois rótulos. O rótulo externo (S=0) é o rótulo UHP, e o rótulo interno (S=1) é o rótulo VC. Uma pesquisa baseada no rótulo de transporte resulta em uma pega de tabela para a tabela de roteamento mpls.0. Existe uma rota adicional na tabela de roteamento mpls.0 correspondente ao rótulo interno. Uma pesquisa baseada no rótulo interno resulta no roteador CE próximo hop.

  • VPN de Camada 3 — Um pacote chega ao roteador PE (saída do LSP do UHP) com dois rótulos. O rótulo externo (S=0) é o rótulo UHP, e o rótulo interno é o rótulo VPN (S=1). Uma pesquisa baseada no rótulo de transporte resulta na pega da tabela para a tabela de roteamento mpls.0. Existem dois casos nesse cenário. Por padrão, as VPNs de Camada 3 anunciam o rótulo por próximo hop. Uma pesquisa baseada no rótulo interno resulta no próximo salto em direção ao CE roteador. Entretanto, se você tiver configurado a instrução para a instância de roteamento VPN de Camada 3, o rótulo LSI interno indica a tabela de roteamento vrf-table-label VRF. Uma busca por IP também é concluída para a tabela de roteamento VRF.

    Nota:

    O UHP para VPNs de camada 3 configurados com a instrução é suportado apenas em redes vrf-table-label 5G da Série MX Plataformas de roteamento universal.

  • VPLS — Um pacote chega ao roteador PE (saída do LSP do UHP) com dois rótulos. O rótulo externo é o rótulo de transporte (S=0) e o rótulo interno é o rótulo VPLS (S=1). Uma pesquisa baseada no rótulo de transporte resulta na pega da tabela para a tabela de roteamento mpls.0. Uma pesquisa baseada no rótulo interno na tabela de roteamento mpls.0 resulta na interface de túnel LSI da instância de roteamento VPLS se os serviços de túnel não estão configurados (ou uma interface VT não disponível). Os roteadores da Série MX 3D são suportados por uma olhada encadeada e uma olhada em várias famílias.

    Nota:

    O UHP para VPLS configurado com a declaração é suportado apenas em roteadores da Série no-tunnel-service MX 3D.

  • IPv4 por MPLS — Um pacote chega ao roteador PE (saída do LSP do UHP) com um rótulo (S=1). Uma olhada com base nesse rótulo retorna uma interface de túnel VT. Outra busca por IP é concluída na interface VT para determinar onde encaminha o pacote. Se a plataforma de roteamento tiver suporte para buscas em várias famílias e cadeias (por exemplo, roteadores MX 3D e série PTX Roteadores de transporte de pacotes), a busca baseada na rota de rótulos (S=1) indica a tabela de roteamento inet.0.

  • IPv6 sobre MPLS — para o tunelamento IPv6 sobre MPLS, os roteadores PE anunciam rotas IPv6 entre si com um valor de rótulo de 2. Esse é o rótulo explicit null para IPv6. Como resultado, os próximos saltos de encaminhamento para rotas IPv6 que são aprendidas com roteadores PE remotos normalmente empurram dois rótulos. O rótulo interno é 2 (pode ser diferente se o roteador PE de publicidade for de outro fornecedor), e o rótulo do roteador é o rótulo LSP. Os pacotes chegam ao roteador PE (saída do UHP LSP) com dois rótulos. O rótulo externo é o rótulo de transporte (S=0), e o rótulo interno é o rótulo explicit-null IPv6 (rótulo 2). A busca baseada no rótulo interno da tabela de roteamento mpls.0 é redirecionada de volta para a tabela de roteamento mpls.0. Nos roteadores da Série MX 3D, o rótulo interno (rótulo 2) é retirado e uma busca no IPv6 é feita usando a tabela de roteamento inet6.0.

  • Ativação de LSPs PHP e UHP — Você pode configurar LSPs PHP e UHP pelos mesmos caminhos de rede. Você pode separar o tráfego PHP e o UHP selecionando o encaminhamento de LSP nos próximos hops usando uma expressão regular com a install-nexthop declaração. Você também pode separar o tráfego nomeando os LSPs de maneira adequada.

As declarações a seguir permitem a popping ultimate-hop para um LSP. Você pode habilitar esse recurso em um LSP específico ou para todos os LSPs de entrada configurados no roteador. Configure essas declarações no roteador na entrada LSP.

  1. Para habilitar o ultimate-hop popping, inclua a ultimate-hop-popping declaração:

    Inclua essa instrução no nível [edit protocols mpls label-switched-path label-switched-path-name] da hierarquia para permitir a adoção de ultimate-hop em um LSP específico. Inclua essa instrução no nível da hierarquia para permitir o estouro de ultimate-hop em todos os LSPs de entrada [edit protocols mpls] configurados no roteador. Você também pode configurar a ultimate-hop-popping declaração nos níveis de hierarquia [edit logical-routers] equivalentes.

    Nota:

    Ao habilitar o ultimate-hop popping, o RSVP tenta ressignificar os LSPs existentes como LSPs de salto final, de forma make-before-break. Se um roteador de saída não tiver suporte para popping ultimate-hop, o LSP existente será eliminado (O RSVP envia uma mensagem PathTear ao longo do caminho de um LSP, removendo o estado do caminho e o estado da reserva dependente e liberando os recursos de rede associados).

    Se você desativar o estouro de ultimate-hop, o RSVP renuncia aos LSPs existentes como penúltimo salto com LSPs estourando de forma make-before-break.

  2. Se você quiser habilitar os próximos saltos ultimate-hop-popping e encadeados apenas em roteadores da série MX 3D, você também precisa configurar a opção para a enhanced-ipnetwork-services instrução:

    Você configura essa instrução em nível [edit chassis] de hierarquia. Depois de configurar a network-services declaração, você precisa reinicializar o roteador para habilitar o comportamento do UHP.

Configuração de LSPs de caminho explícito

Se você desativar a computação LSP (Label-Switched Path, caminho comutado por rótulos) de caminho restrito, como descrito na Computação LSPde caminho restrito de desativação, você pode configurar LSPs manualmente ou permitir que os LSPs sigam o caminho IGP de segurança.

Quando os LSPs de caminho explícito estão configurados, o LSP é estabelecido ao longo do caminho especificado. Se o caminho não for topologicamente viável, seja porque a rede é particionada ou se há recursos insuficientes disponíveis ao longo de algumas partes do caminho, o LSP falhará. Nenhum caminho alternativo pode ser usado. Caso a configuração tenha sucesso, o LSP permanece no caminho definido por tempo indeterminado.

Para configurar um LSP de caminho explícito, siga essas etapas:

  1. Configure as informações de caminho em um caminho nomeado, como descrito na criação de caminhos nomeados. Para configurar informações de caminho completas, especifique cada hop de roteador entre os roteadores de entrada e saída, de preferência usando o strict atributo. Para configurar informações de caminho incompletas, especifique apenas um subconjunto de hops do roteador, usando o atributo em locais onde loose o caminho está incompleta.

    Para caminhos incompletos, MPLS roteadores completam o caminho consultando a tabela de roteamento local. Essa consulta é feita de forma hop-by-hop, e cada roteador pode descobrir apenas informações suficientes para alcançar o próximo hop explícito. Pode ser necessário atravessar vários roteadores para alcançar o próximo hop explícito (frouxo).

    Configurar informações de caminho incompletas cria porções do caminho que dependem da tabela de roteamento atual, e essa porção do caminho pode ser recambiada conforme a topologia muda. Portanto, um LSP de caminho explícito que contém informações de caminho incompletas não é completamente fixo. Esses tipos de LSPs têm apenas uma capacidade limitada de se reparar, e eles tendem a criar loops ou abas, dependendo do conteúdo da tabela de roteamento local.

  2. Para configurar o LSP e aponte-o para o caminho nomeado, use a ou a instrução, conforme descrito na configuração de primarysecondaryLSPs primárias e secundárias.

  3. Desative a computação de LSP de caminho restrito, incluindo a instrução como parte do LSP ou no-cspf como parte de uma ou primarysecondary declaração. Para obter mais informações, consulte Desativação da Computação LSPde caminho restrito.

  4. Configure quaisquer outras propriedades LSP.

Usar LSPs de caminho explícito tem as seguintes desvantagens:

  • É necessário mais esforço de configuração.

  • As informações de caminho configuradas não podem levar em consideração a reserva de largura de banda dinâmica da rede, portanto, os LSPs tendem a falhar quando os recursos se esgotam.

  • Quando um LSP de caminho explícito falha, você pode precisar reparar manualmente.

Devido a essas limitações, recomendamos que você use LSPs de caminho explícito somente em situações controladas, como para aplicar uma estratégia de posicionamento LSP otimizada decorrente de computação com um pacote de software de simulação offline.

Exemplo: Configurando um LSP de caminho explícito

No roteador de entrada, crie um LSP de caminho explícito e especifique os roteadores de trânsito entre os roteadores de entrada e saída. Nesta configuração, nenhuma computação de caminho restrito é executada. Para o caminho principal, todos os hops intermediários são especificados rigorosamente para que sua rota não possa mudar. O caminho secundário deve atravessar o roteador 14.1.1.1.1 primeiro e, em seguida, pegar qualquer rota disponível para chegar ao destino. A rota restante tomada pelo caminho secundário costuma ser o caminho mais curto computado pela IGP.

Visão geral da sobresubscrição da largura de banda LSP

Os LSPs são estabelecidos com reserva de largura de banda configurada para a quantidade máxima de tráfego que você espera atravessar o LSP. Nem todos os LSPs transportam o máximo de tráfego por seus links o tempo todo. Por exemplo, mesmo que a largura de banda do enlace A tenha sido completamente reserva, a largura de banda real ainda pode estar disponível, mas não está em uso no momento. Esse excesso de largura de banda pode ser usado permitindo que outros LSPs também usem o enlace A, sobrescrever o enlace. Você pode sobrescreve a largura de banda configurada para tipos de classe individuais ou especificar um único valor para todos os tipos de classe que usam uma interface.

Você pode usar a sobrescrição para aproveitar a natureza estatística dos padrões de tráfego e permitir maior utilização de links.

Os exemplos a seguir descreverão como você pode usar excesso de largura de banda e subsubscrição:

  • Use sobresubscrição em tipos de classe onde períodos de pico de tráfego não coincidim com o tempo.

  • Use excesso de subscrição de tipos de classe que transportam tráfego de melhor esforço. Você corre o risco de retardar temporariamente ou derrubar tráfego em troca de melhorar a utilização dos recursos da rede.

  • Dê diferentes graus de sobresubscrição ou subsubscrição de tráfego para os diferentes tipos de classe. Por exemplo, você configura a assinatura para classes de tráfego da seguinte forma:

    • Melhor esforço—ct0 1000

    • Voz—ct3 1

Quando você subscreve um tipo de classe para um LSP multiclasse, a demanda total de todas as sessões de RSVP é sempre inferior à capacidade real do tipo de classe. Você pode usar a subscrição para limitar a utilização de um tipo de classe.

O cálculo da sobresubscrição da largura de banda ocorre apenas no roteador local. Como nenhuma sinalização ou outra interação é necessária de outros roteadores na rede, o recurso pode ser ativado em roteadores individuais sem estar habilitado ou disponível em outros roteadores que podem não suportar esse recurso. Os roteadores vizinhos não precisam saber sobre o cálculo da sobresubscrição, eles dependem da IGP.

As seções a seguir descreverão os tipos de excesso de largura de banda disponíveis no Junos OS:

Sobrescrição de tamanho LSP

Para excesso de subscrição do tamanho LSP, você simplesmente configura menos largura de banda do que a taxa de pico esperada para o LSP. Você também pode precisar ajustar a configuração para os policiais automáticos. Os policiais automáticos gerenciam o tráfego atribuído a um LSP, garantindo que ele não exceda os valores de largura de banda configurados. A sobresubscrição do tamanho LSP requer que o LSP possa exceder a alocação configurada de largura de banda.

O policiamento ainda é possível. No entanto, o policial deve ser configurado manualmente para responder pela largura de banda máxima planejada para o LSP, em vez de pelo valor configurado.

Sobresubscrição do tipo de classe e multiplicadores locais de oversubscription

Multiplicadores de sobresubscrição locais (LOMs) permitem diferentes valores de sobrescrição para diferentes tipos de classe. AS LOMs são úteis para redes onde a razão de excesso de assinatura precisa ser configurada de maneira diferente em links diferentes e onde valores de sobresubscrição são necessários para classes diferentes. Você pode usar esse recurso para sobrescrevem tipos de classe que lidam com o tráfego de maior esforço, mas não use excesso de subscrição para tipos de classe que lidam com tráfego de voz. Um LOM é calculado localmente no roteador. Nenhuma informação relacionada a um LOM é sinal para outros roteadores na rede.

Um LOM é configurável em cada enlace e para cada tipo de classe. O LOM por categoria permite que você aumente ou diminua a taxa de sobrescrição. O LOM por categoria é fatorado em toda a contabilidade de largura de banda local para controle de admissão e IGP um anúncio de largura de banda não reservado.

O cálculo do LOM está vinculado ao modelo de largura de banda (MAM, MAM estendido e bonecas russas) usado, porque o efeito da excesso de subscrição entre os tipos de classe deve ser contabilado com precisão.

Nota:

Todos os cálculos de LOM são executados pelo Junos OS e não exigem intervenção do usuário.

As fórmulas relacionadas à sobresubscrição de tipos de classe estão descritas nas seguintes seções:

Configurando a porcentagem de assinatura de largura de banda para LSPs

Por padrão, o RSVP permite que toda a largura de banda de um tipo de classe (100 por cento) seja usada para reserva de RSVP. Quando você sobrescreve um tipo de classe para um LSP multiclasse, a demanda agregada de todas as sessões de RSVP pode exceder a capacidade real do tipo de classe.

Se você quiser sobrescreve ou subscreve todos os tipos de classe em uma interface com a mesma largura de banda percentual, configure a porcentagem usando a subscription instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo da declaração.

Para subscreve ou sobrescreve a largura de banda de cada tipo de classe, configure uma porcentagem para cada tipo de classe (, , e ) opção ct0ct1 para a ct2ct3subscription instrução. Quando você sobrescreve um tipo de classe, um LOM é aplicado para calcular a largura de banda real reserva. Consulte a sobresubscrição do tipo de classe e os multiplicadores de sobresubscrição locais para obter mais informações.

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo da declaração.

percentage é a porcentagem da largura de banda do tipo classe que o RSVP permite ser usada para reserva. Pode ser um valor de 0 a 65.000 por cento. Se você especificar um valor maior que 100, você vai sobrescrever a interface ou o tipo de classe.

O valor que você configura quando você sobrescreve um tipo de classe é uma porcentagem da largura de banda do tipo classe que pode ser usada de fato. O valor da assinatura padrão é de 100 por cento.

Você pode usar a subscription instrução para desativar novas sessões de RSVP para um ou mais tipos de classe. Se você configurar uma porcentagem de 0, nenhuma nova sessão (incluindo aquelas com requisitos de largura de banda zero) será permitida para o tipo de classe.

As sessões de RSVP existentes não são afetadas pela alteração do fator de assinatura. Para limpar uma sessão existente, emito o clear rsvp session comando. Para obter mais informações sobre clear rsvp session o comando, consulte o CLI Explorer.

Restrições na configuração da assinatura da largura de banda

Saiba dos seguintes problemas ao configurar a assinatura da largura de banda:

  • Se você configurar restrições de largura de banda em nível de hierarquia, elas sobrepõem qualquer configuração de largura de banda especificada no nível da hierarquia para [edit class-of-service interface interface-name][edit protocols rsvp interface interface-name bandwidth] Diffserv-TE. Observe também que qualquer uma das restrições de largura de banda CoS ou RSVP pode substituir as restrições de largura de banda do hardware da interface.

  • Se você configurar um valor de assinatura de largura de banda para uma interface específica que difere do valor configurado para todas as interfaces (incluindo valores diferentes para a instrução nos níveis e na hierarquia), o valor específico da interface será usado nessa subscription[edit protocols rsvp interface interface-name][edit protocols rsvp interface all] interface.

  • Você só pode configurar a assinatura de cada tipo de classe se configurar um modelo de largura de banda. Se nenhum modelo de largura de banda estiver configurado, a operação de confirmação falha com a seguinte mensagem de erro:

  • Não é possível incluir a subscription instrução na configuração de um tipo de classe específico e a configuração de toda a interface. A operação commit falha com a seguinte mensagem de erro:

Tabela de histórico de liberação
Versão
Descrição
14.1R9
A partir do Junos OS Release 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3 e 17.2R2, todas as amostras de largura de banda de valor zero são consideradas como amostras de subfluxo, exceto as amostras de valor zero que chegam depois que um LSP aparece pela primeira vez, e as amostras de valor zero que chegam primeiro após uma composição de Mecanismo de Roteamento.