Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Configuração LSP básica

Configuração de métricas LSP

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

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

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

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

Por exemplo, se a métrica do 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 o OSPF em direção a um roteador mudar mais tarde para um valor diferente, todas as métricas de LSP mudam de acordo. Se não houver rotas de IGP em direção ao roteador, o LSP eleva sua métrica para 65.535.

Observe que, neste caso, a métrica de LSP é completamente determinada pelo IGP; não tem relação com o caminho real que o LSP atravessa no momento. Se o LSP reencaminhar (como por meio da reoptimização), sua métrica não mudará e, assim, permanecerá transparente para os usuários. A métrica dinâmica é o comportamento padrão; nenhuma configuração é necessária.

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

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

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

A métrica LSP tem vários usos:

  • Quando existem 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 para o destino. Se as métricas forem as mesmas, o tráfego será compartilhado.

    Ajustar os valores métricos pode forçar o tráfego a preferir alguns LSPs em vez de outros, independentemente da métrica de IGP subjacente.

  • Quando um atalho de IGP é habilitado (veja usando caminhos comutados rotulados para aumentar sPF para computar atalhos de IGP), uma rota de IGP pode ser instalada na tabela de roteamento com um LSP como o próximo salto, se o LSP estiver no caminho mais curto até o destino. Nesse caso, a métrica de LSP é adicionada às outras métricas de IGP para determinar a métrica total do caminho. Por exemplo, se um LSP cujo roteador de entrada é X e o roteador de saída é Y estiver no caminho mais curto até o destino Z, a métrica de LSP é adicionada à métrica para a rota de IGP de Y a Z para determinar o custo total do caminho. Se vários LSPs forem potenciais próximos saltos, as métricas totais dos caminhos são comparadas para determinar qual caminho é preferido (ou seja, tem a menor métrica total). Ou, caminhos de IGP e LSPs que levem ao mesmo destino poderiam ser comparados por meio do valor métrico para determinar qual caminho é preferido.

    Ao ajustar a métrica LSP, você pode forçar o tráfego a preferir LSPs, preferir o caminho do IGP ou compartilhar a carga entre eles.

  • Se o roteador X e Y são pares BGP e se houver um LSP entre eles, a métrica de LSP representa o custo total para atingir Y a partir de X. Se por algum motivo o LSP se redirecionar, o custo do caminho subjacente pode mudar significativamente, mas o custo de X para chegar a Y permanece o mesmo (a métrica LSP), o que permite que X reporte através de um BGP múltiplos de saída discriminadora (MED) uma métrica estável para vizinhos downstream. Enquanto Y permanecer acessível através do LSP, nenhuma mudança é visível para vizinhos BGP downstream.

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

Configuração de métricas condicionais RSVP LSP

A métrica condicional fornece a capacidade de usar diferentes valores métricas condicionalmente para caminhos locais configurados por rótulos (LSPs). As métricas condicionais são baseadas na métrica de IGP que muda dinamicamente. O Junos OS altera a métrica de LSP para a métrica condicional configurada que corresponde ao limite mais alto atingido pela métrica de IGP. Se não houver condições de correspondência, o LSP usa a métrica de IGP da rota. Você pode configurar até quatro métricas condicionais para um LSP e elas estarão em ordem classificada.

Se você configurar a track-igp-metric declaração com a configuração de métrica condicional, o Junos OS usa a métrica de IGP das rotas instaladas para avaliar a métrica condicional configurada. Você não pode configurar métrica estática junto com métrica condicional.

Configuração de uma descrição de texto para LSPs

Você pode fornecer uma descrição textual para um LSP incluindo qualquer texto descritivo que inclua espaços dentro das cotações (" "). 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 sobre a operação do LSP. A descrição do texto LSP não pode ter mais de 80 caracteres de comprimento.

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

Antes de começar:

  • Configure as interfaces do dispositivo.

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

  • Habilite o MPLS nas interfaces dos dispositivos.

  • Configure um LSP no domínio MPLS.

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

  1. Insira qualquer texto que descreva o LSP.

    Por exemplo:

  2. Verifique e confirme a configuração.

    Por exemplo:

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

Configuração de preempção suave MPLS

A preempção suave tenta estabelecer um novo caminho para um LSP antecipado antes de derrubar o LSP original. O comportamento padrão é derrubar um LSP antecipado primeiro, sinalizar um novo caminho e, em seguida, restabelecer o LSP sobre o novo caminho. No intervalo entre quando o caminho é retirado e o novo LSP está estabelecido, qualquer tráfego que tente usar o LSP é perdido. A preempção suave evita esse tipo de perda de tráfego. A compensação é que durante o tempo em que um LSP está sendo preempido suave, dois LSPs com seus requisitos de largura de banda correspondentes são usados até que o caminho original seja rasgado.

A preempção suave do MPLS é útil para a manutenção da rede. Por exemplo, você pode mover todos os LSPs para longe de uma interface específica e, em seguida, reduzir a interface para manutenção sem interromper o tráfego. A preempção suave do MPLS é descrita em detalhes na RFC 5712, MPLS Traffic Engineering Soft Preemption.

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

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

Você também pode configurar um temporizante para uma preempção suave. O temporiza o tempo que o roteador deve esperar antes de iniciar uma preempção dura do LSP. Ao final do tempo especificado, o LSP é derrubado e renunciado. O timer de limpeza de preempção suave tem um valor padrão de 30 segundos; a faixa de valores permitidos é de 0 a 180 segundos. Um valor de 0 significa que a preempção suave está desativada. O timer de limpeza de preempção suave é global para todos os LSPs.

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

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

Nota:

A preempção suave não pode ser configurada em LSPs para os quais o redirecionamento rápido foi configurado. A configuração não confirma. No entanto, você pode habilitar a preempção suave em conjunto com nó e proteção de enlace.

Nota:

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

Configuração de prioridade e preempção para LSPs

Quando não há largura de banda suficiente para estabelecer um LSP mais importante, você pode querer derrubar um LSP existente menos importante para liberar a largura de banda. Você faz isso antecipando o LSP existente.

Se um LSP pode ser predito é determinado por duas propriedades associadas ao LSP:

  • Prioridade de configuração — determina se um novo LSP que antecipa um LSP existente pode ser estabelecido. Para que a preempçã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 prever o LSP existente deve produzir largura de banda suficiente para dar suporte ao novo LSP. Ou seja, a preempção só ocorre se o novo LSP puder ser configurado com sucesso.

  • Prioridade de reserva — determina o grau em que um LSP mantém sua reserva de sessão após o LSP ter sido configurado com sucesso. Quando a prioridade de reserva é alta, o LSP existente é menos propenso a desistir de sua reserva e, portanto, é improvável que o LSP possa ser antecipado.

Você não pode configurar um LSP com uma alta prioridade de configuração e uma prioridade de baixa reserva, porque loops de preempção permanentes podem resultar se dois LSPs forem autorizados a se antecipar. Você deve configurar a prioridade de 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 começa, quando um novo LSP é estabelecido ou durante a recuperação de falhas, a prioridade de configuração determina a ordem em que os LSPs são atendidos. Os LSPs de maior prioridade tendem a ser estabelecidos primeiro e, portanto, desfrutam de uma seleção de caminho mais ideal.

Para configurar as propriedades de preempção do LSP, inclua a priority declaração:

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

Ambos setup-priority e reservation-priority pode ser um valor de 0 a 7. O valor 0 corresponde à maior prioridade e ao valor 7 ao mais baixo. Por padrão, um LSP tem uma prioridade de configuração de 7 (ou seja, não pode prever nenhum outro LSPs) e uma prioridade de reserva de 0 (ou seja, outros LSPs não podem prever isso). Esses padrões são para que a preempção não aconteça. Quando você está configurando esses valores, a prioridade de configuração deve ser sempre menor ou igual à prioridade de hold.

Configuração de grupos administrativos para LSPs

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

Os grupos administrativos só são significativos quando a computação LSP de caminho limitado é habilitada.

Você pode atribuir 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 preempçã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 esta 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 atribuir vários grupos a uma interface. Inclua a interface declaração:

    Você pode incluir esta 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 do grupo para criar pacotes de estado de link, que são então inundados por toda a rede, fornecendo informações a todos os nós da rede. Em qualquer roteador, a topologia do IGP, bem como grupos administrativos de todos os links, estão disponíveis.

    Mudar o grupo administrativo da interface afeta apenas novos LSPs. Os LSPs existentes na interface não são preditos ou recomputados para manter a rede estável. Se os LSPs precisarem ser removidos por causa de uma mudança de grupo, emita o clear rsvp session comando.

    Nota:

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

  3. Configure uma restrição de grupo administrativo para cada LSP ou para cada caminho de LSP primário 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, include-allinclude-anyou exclude declarações, a computação de caminho permanecerá imutável. A computação de caminhos é baseada na computação LSP de caminho limitado. Para obter informações sobre como a computação LSP de caminho limitado é calculada, veja como o CSPF escolhe um caminho.

    Nota:

    Mudar o grupo administrativo do LSP causa uma recomputação imediata da rota; portanto, o LSP pode ser redirecionado.

Configuração de grupos administrativos estendidos para LSPs

Na engenharia de tráfego MPLS, um link pode ser configurado com um conjunto de grupos administrativos (também conhecidos como cores ou classes de recursos). Grupos administrativos são transportados no protocolo de gateway interior (IGP) (OSPFv2 e IS-IS) como um valor de 32 bits atribuído a cada link. Os roteadores da 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 (faixa 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 faixa original de valores disponíveis para grupos administrativos ainda é compatível com a compatibilidade retrógrada.

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 para o IGP. Os valores do grupo administrativo estendido são globais e precisam ser configurados de maneira idêntica em todos os roteadores suportados que participam da rede. O banco de dados de grupos administrativos estendidos em todo o domínio, aprendido com outros roteadores através de inundações de IGP, é usado pelo Constranged Shortest Path First (CSPF) 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 esta 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 minimum opções.maximum O alcance máximo deve ser maior do que o mínimo de alcance.

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

    Você pode incluir esta 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 um valor de grupo para o grupo administrativo. O valor do grupo deve estar dentro da faixa de valores configurados usando a admin-groups-extended-range declaração.

  3. Os grupos administrativos estendidos para uma interface MPLS consistem no conjunto de nomes de grupos administrativos estendidos atribuídos para a interface. Os nomes de grupos administrativos estendidos da interface devem ser configurados para os grupos administrativos estendidos globais.

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

    Você pode incluir esta 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 do LSP definem o conjunto de incluir e excluir restrições para um LSP e para caminhos primários e secundários de um caminho. Os nomes de grupos administrativos estendidos devem ser configurados para os grupos administrativos estendidos globais.

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

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

    Para a lista dos níveis de hierarquia em que 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, emita o show mpls admin-groups-extended comando.
Nota:

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

Configuração de 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 LSP em vez de outro, defina níveis de preferência diferentes para LSPs individuais. O LSP com o menor valor de preferência é usado. A preferência padrão por LSPs RSVP é 7 e para LSPs LDP é 9. Esses valores de preferência são mais baixos (mais preferenciais) do que todas as rotas aprendidas, exceto rotas de interface diretas.

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

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

Desativação da gravação de rotas de caminho por LSPs

A implementação do RSVP pelo Junos oferece suporte ao objeto de Rota de Registro, que permite que um LSP registre ativamente os roteadores pelos quais ele transita. Você pode usar essas informações para solucionar problemas e evitar loops de roteamento. Por padrão, as informações da rota do caminho são registradas. Para desativar a gravação, inclua a no-record declaração:

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

Obtendo um switchover make-before-break e hitless para LSPs

Caminhos adaptativos comutados por rótulos (LSPs) podem precisar estabelecer uma nova instância 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 é referida como uma make antes do intervalo (MBB).

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

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

  • optimize-hold-dead-delay— Tempo para esperar após a transição e antes da exclusão da antiga instância LSP.

Tanto as declarações quanto optimize-hold-dead-delay as optimize-switchover-delay declarações aplicam-se a todos os LSPs que usam o comportamento make-before-break para configuração e teardown de LSP, não apenas para LSPs para os quais a optimize-timer declaração também foi configurada. Os seguintes recursos MPLS fazem com que os LSPs sejam configurados e derrubados usando o comportamento make-before-break:

  • LSPs adaptativos

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

  • BFD para LSPs

  • Switchover gracioso do mecanismo de roteamento

  • Proteção contra links e nós

  • Roteamento ativo sem parar

  • LSPs otimizados

  • LSPs ponto a multiponto (P2MP)

  • Preempção suave

  • Caminhos secundários de standby

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

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

No entanto, a partir do Lançamento 15.1, o Junos OS é capaz de alcançar uma transição MBB sem sucesso sem configurar os atrasos artificiais que esses valores de temporizantes introduzem.

Este tópico resume os três métodos de obtenção de uma transição 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 mudar por instâncias LSP para caminhos recém-otimizados, use a optimize-switchover-delay declaração. Você só precisa configurar esta declaração em roteadores que atuam como a entrada dos LSPs afetados (você não precisa configurar esta declaraçã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 trocado dos caminhos antigos. Esse temporizador só pode ser habilitado ou desativado para todos os LSPs configurados no roteador.

Para configurar o tempo que o roteador espera para mudar por instâncias LSP para caminhos recém-otimizados, especifique o tempo em segundos usando a optimize-switchover-delay declaração:

Você pode incluir esta 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 adiar a derrubada de caminhos antigos

Para especificar o tempo para adiar a derrubada de caminhos antigos depois que o roteador tiver trocado o tráfego por novos caminhos otimizados, use a optimize-hold-dead-delay declaração. Você só precisa configurar esta declaração em roteadores que atuam como a entrada dos LSPs afetados (você não precisa configurar esta declaraçã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 que todas as rotas sejam transferidas para os novos caminhos otimizados. Esse temporizador pode ser habilitado para LSPs específicos ou para todos os LSPs configurados no roteador.

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

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

Obtendo um switchover MBB sem sucesso sem atrasos artificiais

A partir do Junos OS Release 15.1, há outra maneira de renunciar às antigas instâncias de LSP após a transição de MBB sem depender dos intervalos de tempo arbitrários estabelecidos pela declaração ou optimize-hold-dead-delay declaraçãooptimize-switchover-delay. Por exemplo, se você usar a optimize-hold-dead-delay declaração, configure um tempo que considera seguro esperar antes de derrubar a antiga instância LSP após a MBB. No entanto, algumas rotas ainda podem estar em processo de mudança para a nova instância. Derrubar a antiga instância LSP precocemente resulta em um dos nós de trânsito deixando cair o tráfego para aquelas rotas que não mudaram para a nova instância LSP.

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

O mecanismo de feedback está sempre em vigor, e é opcional. Configure a optimize-adaptive-teardown declaração para ter o mecanismo de feedback usado durante o switchover MBB. Esse recurso não é compatível com instâncias LSP de ponto a multiponto (P2MP) de RSVP. A configuração global da optimize-adaptive-teardown declaração afeta apenas os LSPs ponto a ponto que estão configurados no sistema.

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

Você pode incluir esta declaração no nível da [edit protocols mpls] hierarquia.

Otimização de LSPs sinalizados

Assim que um LSP tiver sido estabelecido, a topologia ou as mudanças de recursos podem, ao longo do tempo, tornar o caminho subótimo. Um novo caminho pode ter se tornado disponível que é menos congestionado, tem uma métrica menor e atravessa menos saltos. Você pode configurar o roteador para recompor caminhos periodicamente para determinar se um caminho mais ideal está disponível.

Se a reoptimização for habilitada, um LSP pode ser redirecionado por caminhos diferentes por recomputações de caminho restringido. No entanto, se a reoptimização for desativada, o LSP tem um caminho fixo e não pode aproveitar os recursos de rede recém-disponíveis. O LSP é fixo até que a próxima mudança de topologia quebre 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 interrompem 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 reoptimização for ativada. Por padrão, a optimize-timer declaração está definida para 0 (ou seja, está desativada).

A otimização de LSP só é significativa quando a computação LSP de caminho limitado é ativada, que é o comportamento padrão. Para obter mais informações sobre a computação LSP de caminho restrito, consulte a desativação da computação LSP de caminho restringido. Além disso, a otimização de LSP só é aplicável a LSPs de entrada, por isso só é necessário configurar a optimize-timer declaração no roteador de entrada. Os roteadores de trânsito e saída não exigem configuração específica para oferecer suporte à otimização de LSP (além de ter MPLS habilitado).

Para permitir a reoptimização do caminho, inclua a optimize-timer declaração:

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

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

Após a execução da reoptimização, o resultado só é aceito se atender aos seguintes critérios:

  1. O novo caminho não é mais alto na métrica de IGP. (A métrica para o 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 é contabilizado.)

  2. Se o novo caminho tiver a mesma métrica de IGP, ele não vai mais longe.

  3. O novo caminho não causa preempção. (Isso é para reduzir o efeito cascata da preempção, causando mais preempção.)

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

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

    1. A porcentagem de largura de banda disponível em cada enlace atravessado pelo novo caminho é comparada à do caminho antigo, começando pelos 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 ascendente.

    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 ascendente.

    4. Se algum dos quatro novos valores de largura de banda disponíveis for menor do que qualquer um dos valores de disponibilidade de largura de banda antigos correspondentes, o novo caminho tem pelo menos um link mais congestionado do que o link usado pelo caminho antigo. Como o uso do enlace causaria mais congestionamento, o tráfego não é transferido 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 de largura de banda antigos correspondentes, o novo caminho está menos congestionado do que o caminho antigo.

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

  1. Se o novo caminho tiver uma métrica de IGP menor, ele será aceito.

  2. Se o novo caminho tiver uma métrica de IGP igual e menor contagem de saltos, ele será aceito.

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

    1. O LSP é movido para um novo caminho que é utilizado 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 removido de um caminho que transporta no mínimo 200 MB, o congestionamento no caminho original é 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 com menos preenchimentoExemplo de algoritmo de balanceamento de carga com menos preenchimento

    Como mostrado, Figura 1existem dois caminhos potenciais para um LSP atravessar do roteador A ao roteador H, os links ímpares de L1 a L13 e até mesmo links de L2 a L14. Atualmente, o roteador está usando os links uniformes 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 enlaces 1GE são mais propensos a ficar congestionados. Neste exemplo, os estranhos links 1GE têm a seguinte largura de banda disponível:

    • L3 = 41%

    • L5 = 56%

    • L7 = 66%

    • L9 = 71%

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

    • L4 = 37%

    • L6 = 52%

    • L8 = 61%

    • L10 = 70%

    Com base nessas informações, o roteador calcularia a diferença na largura de banda disponível entre os links ímpares e até mesmo os links da seguinte forma:

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

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

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

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

    O total de largura de banda adicional disponível nos links ímpares é de 14% (4% + 4% + 5% + 1%). Uma vez que 14% é maior que 10% (o limite mínimo de algoritmo de menor preenchimento), o LSP é movido para o novo caminho através dos links ímpares do caminho original usando os links uniformes.

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

Você pode desabilitar os seguintes critérios de reoptimização (um subconjunto dos critérios listados anteriormente):

  • Se o novo caminho tiver a mesma métrica de IGP, ele não vai mais longe.

  • O novo caminho não causa preempção. (Isso é para reduzir o efeito cascata da preempção, causando mais preempção.)

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

  • Se o novo caminho tiver uma métrica de IGP igual e menor contagem de saltos, ele será aceito.

Para desabitá-los, emite o clear mpls lsp optimize-aggressive comando ou inclua a optimize-aggressive declaração:

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

  • [edit protocols mpls]

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

Incluir a optimize-aggressive declaração na configuração faz com que o procedimento de reoptimização seja acionado com mais frequência. Os caminhos são redirecionados com mais frequência. Ele também limita o algoritmo de reoptimização apenas à métrica de IGP.

Configurando o timer Smart Optimize para LSPs

Devido a restrições de recursos de rede e roteador, normalmente é desaconselhável configurar um intervalo curto para o temporizador otimizado. No entanto, em determinadas circunstâncias, talvez seja desejável reoptimizar um caminho mais cedo do que normalmente seria fornecido pelo temporizador otimizado.

Por exemplo, um LSP está atravessando um caminho preferido que, posteriormente, falha. O LSP é então mudado para um caminho menos desejável para chegar ao mesmo destino. Mesmo que o caminho original seja rapidamente restabelecido, o LSP pode levar muito tempo para usá-lo novamente, porque ele precisa esperar o temporizador otimizado para reoptimizar os caminhos da rede. Para essas situações, você pode querer configurar o timer de otimização inteligente.

Quando você habilita o temporizador de otimização inteligente, um LSP é religado para o caminho original, desde que o caminho original tenha sido restabelecido dentro de 3 minutos após a descida. Além disso, se o caminho original cair novamente em 60 minutos, o temporizador de otimização inteligente é desativado, e a otimização de caminho se comporta como normalmente faz quando o temporizador otimizado sozinho está ativado. Isso impede que o roteador use um enlace de flapping.

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

No mínimo, você deve configurar um caminho secundário de espera para que o recurso de otimização inteligente funcione corretamente. Rerroteamento rápido e proteção de enlaces são soluções mais temporárias para uma interrupção de rede. Um caminho secundário garante que haja um caminho alternativo estável caso o caminho principal falhe. Se você não tiver configurado nenhum tipo de proteção de tráfego para um LSP, o temporizador de otimização inteligente por si só não garante que o tráfego possa chegar ao seu destino. Para obter mais informações sobre a proteção de tráfego MPLS, consulte MPLS e Proteção de tráfego.

Quando um caminho principal falha e o smart otimiza o tráfego de switches de tempo para o caminho secundário, o roteador pode continuar a usar o caminho secundário mesmo após a restauração do caminho principal. Se o roteador de entrada concluir um cálculo de CSPF, ele pode determinar que o caminho secundário é o melhor caminho.

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

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

Você pode incluir esta 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 obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

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

Configurando o valor de 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 volume maior de tráfego. A largura de banda padrão é de 0 bits por segundo.

Uma largura de banda não zero exige que os roteadores de trânsito e saída reservem a capacidade ao longo dos links de saída para o 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íticas de RSVP ou controle de admissão) pode fazer com que a configuração do LSP falhe. Se houver largura de banda insuficiente nas interfaces para os roteadores de trânsito ou saída, o LSP não está estabelecido.

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

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

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

A alocação automática de largura de banda permite que um túnel MPLS ajuste automaticamente sua alocação de largura de banda com base no volume de tráfego que flui 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ê define um intervalo de amostragem em um LSP configurado com alocação automática de largura de banda. A largura de banda média é monitorada durante este intervalo. Ao final do intervalo, é feita uma tentativa de sinalizar um novo caminho para o LSP com a alocação de largura de banda definida para o valor médio máximo para o intervalo de amostragem anterior. Se o novo caminho for estabelecido com sucesso e o caminho original for removido, o LSP será transferido para o novo caminho. Se um novo caminho não for criado, o LSP continua a usar seu caminho atual até o final do próximo intervalo de amostragem, 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 automático de alocação de largura de banda, o roteador pode receber um aumento constante do tráfego (aumentando a utilização da largura de banda) em um LSP, potencialmente causando congestionamento ou perda de pacotes. Para evitar isso, você pode definir um segundo gatilho para vencer o temporização automática de ajuste de largura de banda antes do fim do intervalo de ajuste atual.

Configuração da alocação automática de largura de banda para LSPs

A alocação automática de largura de banda permite que um túnel MPLS ajuste automaticamente sua alocação de largura de banda com base no volume de tráfego que flui pelo túnel. Você pode configurar um LSP com largura de banda mínima, e 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.

Ao final do intervalo de tempo de alocação de largura de banda automático, o uso atual da largura de banda média máxima é comparado com a largura de banda alocada para o LSP. Se o LSP precisar de mais largura de banda, é feita uma tentativa de configurar um novo caminho onde a largura de banda é igual à utilização média máxima atual. Se a tentativa for bem-sucedida, o tráfego do LSP é roteado pelo novo caminho e o caminho antigo é removido. Se a tentativa falhar, o LSP continua a usar seu caminho atual.

Nota:

No cálculo do valor ( Max AvgBW em relação ao LSP de ingresso), a amostra coletada durante o make antes do intervalo (MBB) é ignorada para evitar resultados imprecisos. A primeira amostra após um ajuste de largura de banda, ou após uma mudança no LSP ID (independentemente da mudança de caminho), também é ignorada.

Se você tiver configurado a proteção de enlace e nó para o LSP e o tráfego tiver sido trocado para o LSP de bypass, o recurso automático de alocação de largura de banda continua a operar e coletar amostras de largura de banda do LSP de bypass. Para o primeiro ciclo de ajuste de largura de banda, o uso máximo de largura de banda média retirado do link original e LSP protegido por nós é usado para renunciar ao LSP de bypass se for necessário mais largura de banda. (A proteção de enlace e nó não é compatível com switches da Série QFX.)

Se você tiver configurado o redirecionamento rápido para o LSP, talvez não seja possível 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 contagem dupla pode impedir que um LSP de redirecionamento rápido ajuste sua largura de banda quando a alocação automática de largura de banda for ativada. (O rerroteamento 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 no nível de edit protocols mpls hierarquia. Sistemas lógicos não são suportados.

Configuração de ajustes otimizados de largura de banda automática para LSPs MPLS

A funcionalidade de largura de banda automática permite que os LSPs RSVP-TE, configurados diretamente ou criados automaticamente usando a malha automática, sejam redimensionados 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 coleta de estatísticas de tráfego é controlada por meio da declaração de adjust-interval configuração. O valor mínimo configurável é de adjust-interval um segundo. O redimensionamento dos LSPs é chamado de ajuste e a frequência de ajustes é controlada por meio da adjust-interval declaração.

Começando no Junos OS Release 20.4R1, o mínimo adjust-interval para um auto-bandwidth ajuste é reduzido para 150 segundos se as declarações ou adjust-threshold-underflow-limit declarações adjust-threshold-overflow-limit cruzarem os valores de limite de excesso ou subfluxo configurados.

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

Em lançamentos anteriores ao Junos OS Release 20.4R1, os adjust-interval 300 segundos estão em condições de excesso ou de subfluxo.

Com a implementação da otimização automática de ajuste de largura de banda, a auto-bandwidth largura de banda do LSP diminui mais rapidamente. O roteador de borda de rótulo de entrada (LER) é capaz de redicionar em até 150 segundos por adjust-threshold-overflow-limitcausa da redução, desde que o rompimento de uma antiga instância de LSP pós-make-before-break (MBB) seja realizado dentro de 150 segundos.

Os requisitos para a opção de largura de banda automática são:

  • Reduza a probabilidade de mudança de rota de LSP — isso é para reduzir a probabilidade de mudança de rota LSP quando ocorre um ajuste automático de largura de banda.

  • Reduza a probabilidade de redirecionamento de LSP — isso é para reduzir a probabilidade de redirecionamento de LSP devido aos LSPs de maior prioridade que exigem o mesmo recurso.

Para atender a esses requisitos, a otimização de ajustes de largura de banda automática oferece suporte aos seguintes:

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

    Nota:

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

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

    • auto-policing configurado sob MPLS.

    • A opção bandwidth sob a declaração load-balance configurada sob RSVP.

    Nota:

    A atualização da largura de banda LSP no local por meio do reutilismo 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 Caminho (PCE).

    • O temporização de otimização de LSP dispara.

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

  2. Per-priority Subscription— Para utilizar os recursos de rede de maneira mais eficiente, a assinatura por prioridade permite que você configure uma menor porcentagem de assinatura de RSVP para LSPs de prioridades mais baixas e maior percentual 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 mais baixas

Nota:

A assinatura por prioridade não opera com engenharia de tráfego (TE) com reconhecimento de Serviços Diferenciados (DiffServ). A engenharia de tráfego com reconhecimento de Serviços Diferenciados (DiffServ) oferece um compartilhamento mais flexível e estatística da largura de banda de enlace TE do que a assinatura por prioridade.

To Configure In-place LSP Auto-bandwidth Resizing:

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

Verification

A partir do modo de configuração, confirme sua configuração entrando nos show protocols show interfaces comandos. Se a saída não exibir a configuração pretendida, repita 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 de assinatura de largura de banda para a interface. Pode ser um valor de 0 a 65.000 por cento. O valor de assinatura padrão é de 100%.

  3. Configure a prioridade de assinatura na interface.

  4. Configure a porcentagem de assinatura para a prioridade.

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

Verification

A partir do modo de configuração, confirme sua configuração entrando nos show protocols show interfaces comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Configuração de 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 que um túnel MPLS ajuste automaticamente sua alocação de largura de banda com base no volume de tráfego que flui 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 opção auto-bandwidth para a statistics declaração no nível hierárquico [edit protocols mpls] . Essas configurações se aplicam a todos os LSPs configurados no roteador no qual você também configurou a auto-bandwidth declaração no nível de [edit protocols mpls label-switched-path label-switched-path-name] hierarquia.
  2. Especifique os filename arquivos usados para armazenar a saída de operação de rastreamento MPLS usando a opção file . Todos os arquivos são colocados no diretório /var/log. Recomendamos que você coloque a saída de rastreamento MPLS no arquivo mpls-log.
  3. Especifique o número máximo de arquivos de rastreamento usando a opção files number . Quando um arquivo de rastreamento nomeado trace-file atinge seu tamanho máximo, ele é renomeado trace-file.0, em seguida trace-file.1, e assim por diante, até que o número máximo de arquivos de rastreamento seja atingido. Então o arquivo de rastreamento mais antigo é sobreescrito.
  4. Especifique o intervalo para calcular o uso médio da largura de banda configurando um tempo em segundos usando a opção interval . Você também pode definir o intervalo de ajuste em um LSP específico configurando a opção interval no nível de [edit protocols mpls label-switch-path label-switched-path-name statistics] hierarquia.
    Nota:

    Para evitar a renúncia desnecessária de LSPs, é melhor configurar um intervalo de ajuste de LSP que seja pelo menos três vezes maior do que o intervalo de estatísticas de largura de banda automática MPLS. Por exemplo, se você configurar um valor de 30 segundos para o intervalo de estatísticas de largura de banda automática MPLS (interval declaração no nível da [edit protocols mpls statistics] hierarquia), você deve configurar um valor de pelo menos 90 segundos para o intervalo de ajuste de LSP (adjust-interval declaração no nível da [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 declaração MPLS traceoptions no nível de [edit protocols mpls] hierarquia.

    A configuração a seguir permite as opções de rastreamento MPLS 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 show log comando, você pode exibir o arquivo automático de estatísticas de alocação de largura de banda gerado quando você configura a declaração de largura de banda automática (MPLS Statistics ). O seguinte mostra a saída de arquivo de registro de amostra retirada de um arquivo de estatísticas MPLS nomeado auto-band-stats em um roteador configurado com um LSP chamado E-D. O arquivo de registro mostra que o LSP E-D está operando acima do limite de largura de banda reservado inicialmente. Antes Oct 30 17:14:57, o roteador acionou um ajuste automático de largura de banda (você pode ver duas sessões para um LSP em um ajuste automático de largura de banda). Por Oct 30 17:16:57, o LSP foi restabelecido em uma largura de banda mais alta e agora é mostrado usando menos de 100 por cento de sua Reserved Bw (largura de banda reservada).
  7. Emita o comando de largura de banda automática mpls lsp para exibir informações atuais sobre a alocação automática de largura de banda. O seguinte mostra a saída de amostra do show mpls lsp autobandwidth comando tirada quase ao mesmo tempo que o arquivo de registro mostrado anteriormente:
  8. Emite o file show comando para exibir o arquivo de rastreamento MPLS. Você precisa especificar a localização do arquivo e o nome do arquivo (o arquivo está localizado em /var/log/. O seguinte mostra que a saída de arquivo de rastreamento de amostra é retirada de um arquivo de rastreamento MPLS nomeado auto-band-trace.0.gz em um roteador configurado com um LSP chamado E-D. O arquivo de rastreamento mostra que o LSP E-D está operando acima do limite de largura de banda reservado inicialmente. Em Oct 30 17:15:26, o roteador aciona um ajuste automático de largura de banda (você pode ver duas sessões para um LSP em um ajuste automático de largura de banda). Por Oct 30 17:15:57, o LSP foi restabelecido em uma largura de banda mais alta e agora é mostrado usando menos de 100 por cento de sua Reserved Bw (largura de banda reservada).

Configuração de um LSP em ASs

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

Antes de começar:

  • Configure as interfaces de dispositivo com MPLS da família.

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

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

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

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

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

  1. Habilite o MPLS em todas as interfaces (exceto a interface de gerenciamento).
  2. Habilite o RSVP em todas as interfaces (exceto a interface de gerenciamento).
  3. Configure o LSP inter-área.
  4. Verifique e confirme a configuração.

Anúncio de amortecimento das mudanças de estado do LSP

Quando um LSP muda de estar para baixo ou de baixo para cima, essa transição entra em vigor imediatamente no software e no hardware do roteador. No entanto, ao anunciar LSPs para IS-IS e OSPF, você pode querer umedegar as transições de LSP, não anunciando assim a transição até que um determinado período de tempo tenha ocorrido (conhecido como o tempo de espera). Nesse caso, se o LSP for de cima para baixo, o LSP não é anunciado como sendo baixo até que tenha ficado baixo pelo período de espera. As transições de baixo para cima são anunciadas imediatamente para IS-IS e OSPF. Observe que o amortecimento de LSP afeta apenas os anúncios IS-IS e OSPF do LSP; outros softwares de roteamento e hardware reagem imediatamente às transições de LSP.

Para transições LSP umedecientes, 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 esta 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 LSP de pacote bidirecional corouted é uma combinação de dois LSPs compartilhando o mesmo caminho entre um par de nós de entrada e saída, como mostrado em Figura 2. Ele está 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 de BFD para o LSP bidirecional (você não precisa configurar uma sessão de BFD para cada LSP em cada direção). Você também pode configurar um único LSP bidirecional de standby para fornecer um backup para o LSP bidirecional primário. LSPs bidirecionais corouted são suportados tanto para o penúltimo hop popping (PHP) quanto para o hop popping final (UHP).

A alta disponibilidade está disponível para LSPs bidirecionais. Você pode ativar o recomeço gracioso e o roteamento ativo sem parar. A reinicialização graciosa e o roteamento ativo sem parar são suportados 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 entrada para o LSP e inclua a corouted-bidirectional declaração para especificar que o LSP seja estabelecido como um LSP bidirecional corouted.

    O caminho é computado usando CSPF e iniciado usando sinalização RSVP (assim como um RSVP unidirecional sinalizado LSP). Tanto o caminho até o roteador de saída quanto o caminho inverso 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 corouted-bidirectional-passive declaração para associar o LSP a outro LSP.

    Nenhuma computação ou sinalização de caminho é usada para este LSP, pois depende da computação e sinalização de caminho fornecidas pelo LSP de entrada. Você não pode configurar a corouted-bidirectional declaração e a corouted-bidirectional-passive declaração no mesmo LSP.

    Essa declaração também facilita a depuração de LSPs bidirecionais corouted. Se você configurar a corouted-bidirectional-passive declaração (novamente, no roteador de saída), você pode emitir ping mpls lsp-end-point, ping mpls ldp, , ping mpls rsvp, traceroute mpls ldpe traceroute mpls rsvp comandos para testar o LSP bidirecional corouted do roteador de saída.

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

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

Configuração do rótulo de entropia para LSPs

A inserção de rótulos de entropia para um LSP permite que roteadores de trânsito balanceem o tráfego MPLS em caminhos de ECMP ou grupos de agregação de enlace usando apenas a pilha de rótulos MPLS como uma entrada de hash sem precisar contar com inspeção profunda de pacotes. A inspeção profunda de pacotes requer mais 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 declaração no nível de [edit protocols mpls labeled-switched-path labeled-switched-path-name] hierarquia ou no nível hierárquico [edit protocols mpls static-labeled-switched-path labeled-switched-path-name ingress] . O rótulo de entropia é adicionado à pilha de rótulos MPLS 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 ingresso para LSPs sinalizados por LDP:

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

    A seguir, mostra um exemplo de uma política de ingresso de rótulos de entropia.

  3. (Opcional) Por padrão, os roteadores que suportam o push e o estouro de rótulos de entropia são configurados com a load-balance-label-capability declaração no nível de [edit forwarding-options] hierarquia para sinalizar os rótulos por LSP. Se o roteador de peer não estiver equipado para lidar com rótulos de balanceamento de carga, você pode impedir que o roteador de borda do provedor (PE) sinaliza a capacidade do rótulo de entropia configurando a no-load-balance-label-capability declaração no nível de [edit forwarding-options] hierarquia.

Os roteadores de trânsito não exigem configuração. A presença do rótulo de entropia indica ao roteador de trânsito o equilíbrio de carga com base apenas na pilha de rótulos MPLS.

Os penúltimos roteadores de hop insusem o rótulo de entropia por padrão.

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

Este exemplo mostra como configurar um rótulo de entropia para um unicast rotulado bgp para alcançar 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 certos campos dos cabeçalhos de pacotes para hash o pacote para 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. Os LSRs no núcleo simplesmente usam o rótulo de entropia como a chave para hash o pacote para o caminho correto. Um rótulo de entropia pode ser qualquer valor de rótulo entre 16 a 1048575 (faixa regular de rótulos de 20 bits). Uma vez que essa faixa se sobrepõe à faixa de rótulos regular 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.

Os unicasts rotulados de BGP geralmente condensam RSVP ou LSPs LDP em várias áreas de IGP ou vários sistemas autônomos. Os rótulos de entropia RSVP ou LDP são colocados no penúltimo nó de hop, juntamente com o rótulo RSVP ou LDP. Esse recurso permite o uso de rótulos de entropia nos pontos de costura para preencher a lacuna entre o penúltimo nó de salto e o ponto de costura, a fim de alcançar o balanceamento de carga de rótulos de entropia de ponta a ponta para o tráfego BGP.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Sete roteadores da Série MX com MPCs

  • Junos OS Versão 15.1 ou posterior em execução em todos os dispositivos

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

  1. Configure as interfaces do dispositivo.

  2. Configure o OSPF ou qualquer outro protocolo IGP.

  3. Configure BGP.

  4. Configure RSVP.

  5. Configure MPLS.

Visão geral

Quando os unicasts rotulados de BGP condensam RSVP ou LDP LSPs em várias áreas de IGP ou vários sistemas autônomos, rótulos de entropia RSVP ou LDP são colocados no penúltimo nó de hop, juntamente 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 usaram os rótulos BGP para encaminhar pacotes.

Começando com o Junos OS Release 15.1, você pode configurar um rótulo de entropia para unicast rotulado de BGP para alcançar o balanceamento de carga de rótulos de entropia de ponta a ponta. Esse recurso permite o uso de um rótulo de entropia nos pontos de costura, a fim de alcançar balanceamento de carga de rótulos de entropia de ponta a ponta para o tráfego BGP. O Junos OS permite a inserção de rótulos de entropia na entrada LSP unicast rotulada de BGP.

Por padrão, os roteadores que oferecem suporte a rótulos de entropia são configurados com a load-balance-label-capability declaração no nível de [edit forwarding-options] hierarquia para sinalizar os rótulos por LSP. Se o roteador de peer não estiver equipado para lidar com rótulos de balanceamento de carga, você pode impedir a sinalização da capacidade do rótulo de entropia configurando o no-load-balance-label-capability nível de [edit forwarding-options] hierarquia.

Nota:

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

Topologia

O Figura 3 roteador PE1 é o roteador de entrada e o roteador PE2 é o roteador de saída. Os roteadores P1 e P2 são os roteadores de trânsito. O roteador ABR é o roteador de ponte da área entre a Área 0 e a Área 1. O LAG está configurado nos roteadores provedores para equilibrar a carga do tráfego. O recurso de rótulo de entropia para unicast com rótulo BGP está habilitado no roteador PE1 de entrada.

Figura 3: Configuração de um rótulo de entropia para o BGP Labeled UnicastConfiguração de um rótulo de entropia para o BGP Labeled Unicast

Configuração

Configuração rápida de CLI

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

Roteador PE1

Roteador P1

ABR do roteador

Roteador P2

Roteador PE2

Configuração do roteador PE1

Procedimento passo a passo

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

Para configurar o roteador PE1:

Nota:

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

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

  2. Configure a interface de loopback.

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

  4. Configure o protocolo RSVP para todas as interfaces.

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

  6. Configure o IBGP nos roteadores internos.

  7. Habilite o recurso de rótulo de entropia para unicast rotulado bgp para ibgp interno do grupo BGP.

  8. Habilite o protocolo OSPF em todas as interfaces do roteador de borda da área (ABR).

  9. Definir listas de prefixo para especificar as rotas com recursos de rótulos de entropia.

  10. Defina um EL de política para especificar as rotas com recursos de rótulos de entropia.

  11. Defina outra política EL-2 para especificar as rotas com recursos de rótulos de entropia.

  12. Definir uma política para exportar rotas BGP para a tabela de roteamento OSPF.

  13. Defina uma política para exportar rotas de OSPF para a tabela de roteamento BGP.

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

  15. Configure um alvo VPN para a comunidade VPN.

  16. Configure a instância de roteamento VPN-l3vpn da 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 uma meta 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 rotas BGP para a tabela de roteamento OSPF para a instância de roteamento VPN-l3vpn.

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

Configuração do roteador P1

Procedimento passo a passo

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

Para configurar o roteador P1:

Nota:

Repita este procedimento para Roteador P2 após modificar os nomes, endereços e outros parâmetros apropriados da interface.

  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 rótulos MPLS que o roteador usa para acelerar os pacotes até o destino para balanceamento de carga.

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

  6. Habilite o balanceamento de carga por pacote.

  7. Configure o protocolo RSVP para todas as interfaces.

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

  9. Habilite o protocolo OSPF em todas as interfaces do Roteador P1, exceto a interface de gerenciamento.

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

Configuração do roteador ABR

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre a navegação na CLI, consulte o uso do Editor de CLI no modo de configuração no Guia de 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 rótulos MPLS que o roteador usa para acelerar os pacotes até o destino para balanceamento de carga.

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

  6. Habilite o balanceamento de carga por pacote.

  7. Configure o protocolo RSVP para todas as interfaces.

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

  9. Configure o IBGP nos roteadores internos.

  10. Habilite o protocolo OSPF em todas as interfaces da ABR.

  11. Defina uma política para especificar as rotas com recursos de rótulos de entropia.

Resultados

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

Verificação

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

Verificando se o recurso de rótulo de entropia está sendo anunciado no roteador PE2

Propósito

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

Ação

A partir 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 o recurso de rótulo de entropia para seus vizinhos BGP.

Verificar se o roteador ABR recebe o anúncio do rótulo de entropia

Propósito

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

Ação

A partir 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 do recurso de rótulo de entropia de seu vizinho BGP PE2.

Verificando se a bandeira do rótulo da entropia está definida

Propósito

Verifique se a bandeira do rótulo de entropia está definida para os elementos do rótulo na entrada.

Ação

A partir do modo operacional, execute o show route protocol bgp detail comando no Roteador PE1.

Significado

Um rótulo de entropia está habilitado no Roteador PE1. A saída mostra que o rótulo de entropia está sendo usado para o unicast rotulado BGP para alcançar balanceamento de carga de ponta a ponta.

Configuração de popping de salto final para LSPs

Por padrão, os LSPs sinalizados por RSVP usam o penúltimo hop popping (PHP). Figura 4 ilustra um LSP de salto penúltimo entre o Roteador PE1 e o Roteador PE2. O roteador CE1 encaminha um pacote para o próximo hop (Roteador PE1), que também é a entrada LSP. O roteador PE1 empurra o rótulo 1 no pacote e encaminha o pacote rotulado para o Roteador P1. O roteador P1 completa a operação padrão de troca de rótulos MPLS, trocando o rótulo 1 pelo rótulo 2 e encaminha o pacote para o Roteador P2. Como o roteador P2 é o penúltimo roteador de salto para o LSP para o roteador PE2, ele primeiro abre 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 explícito ou apenas um pacote IP ou VPLS simples. O roteador PE2 encaminha o pacote sem rótulos para o Roteador CE2.

Figura 4: Penúltimo salto aparecendo para um LSPPenúltimo salto aparecendo para um LSP

Você também pode configurar o ultimate-hop popping (UHP) (como mostrado em Figura 5) para LSPs sinalizados por 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 Figura 5) executa a operação padrão de troca de rótulos MPLS (neste exemplo, rótulo 2 para rótulo 3 ) antes de encaminhar o pacote para o ROTEADOR PE2 de saída. O roteador PE2 abre o rótulo externo e realiza uma segunda olhada no endereço do pacote para determinar o destino final. Em seguida, ele encaminha o pacote para o destino apropriado (ce2 roteador ou ROTEADOR CE4).

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

Os aplicativos de rede a seguir exigem que você configure LSPs UHP:

  • MPLS-TP para monitoramento de desempenho e OAM em banda

  • Circuitos virtuais de proteção de borda

Os recursos a seguir não oferecem suporte ao comportamento de UHP:

  • LSPs sinalizados por LDP

  • LSPs estáticos

  • LSPs ponto a multiponto

  • CCC

  • traceroute Comando

Para obter mais informações sobre o comportamento de UHP, consulte o rascunho da Internet draft-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 sinalizados por RSVP ponto a ponto, o comportamento de UHP é sinalizado a partir da entrada do LSP. Com base na configuração do roteador de entrada, o RSVP pode sinalizar o LSP UHP com o conjunto de bandeiras não PHP. As mensagens RSVP PATH carregam as duas bandeiras no objeto LSP-ATTRIBUTES. Quando o roteador de saída recebe a mensagem PATH, ele atribui 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 à parte S do rótulo MPLS, que indica se a parte inferior da pilha de rótulos foi alcançada ou não.

  • Route S=0 — indica que há mais rótulos na pilha. O próximo salto para essa rota aponta para a tabela de roteamento mpls.0, desencadeando uma busca em um rótulo MPLS acorrentado para descobrir os rótulos MPLS restantes na pilha.

  • Rotear S=1 — indica que não há mais rótulos. O próximo salto aponta para a tabela de roteamento inet.0 se a plataforma oferecer suporte a uma busca em cadeia e multi-família. Como alternativa, a rota de rótulos pode apontar para uma interface VT para iniciar o encaminhamento de IP.

Se você habilitar LSPs UHP, aplicativos MPLS como VPNs de Camada 3, VPLS, VPLS, VPNs de Camada 2 e circuitos de Camada 2 podem usar os LSPs UHP. O seguinte explica como os LSPs UHP afetam os diferentes tipos de aplicativos MPLS:

  • VPNs de camada 2 e circuitos de Camada 2 — um pacote chega ao roteador PE (saída do LSP 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 alça 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 próximo salto do roteador CE.

  • VPN de camada 3 — um pacote chega ao roteador PE (saída do UHP LSP) 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 alça de tabela para a tabela de roteamento mpls.0. Há dois casos neste cenário. Por padrão, as VPNs de Camada 3 anunciam o rótulo de hop por próximo. Uma pesquisa baseada no rótulo interno resulta no próximo salto em direção ao roteador CE. No entanto, se você tiver configurado a vrf-table-label declaração para a instância de roteamento VPN de Camada 3, o rótulo LSI interno aponta para a tabela de roteamento VRF. Uma busca por IP também está concluída para a tabela de roteamento VRF.

    Nota:

    UHP para VPNs de Camada 3 configuradas com a vrf-table-label declaração é compatível apenas com plataformas de roteamento universal 5G da Série MX.

  • VPLS — Um pacote chega 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 VPLS (S=1). Uma pesquisa baseada no rótulo de transporte resulta na alça de 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 estiverem configurados (ou uma interface VT não estiver disponível). Os roteadores da Série MX 3D oferecem suporte a uma busca em cadeia e uma busca multi-família.

    Nota:

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

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

  • IPv6 sobre MPLS — Para o tunelamento IPv6 em MPLS, os roteadores PE anunciam rotas IPv6 entre si com um valor de rótulo de 2. Este é o rótulo nulo explícito para IPv6. Como resultado, os próximos saltos de encaminhamento para rotas IPv6 que são aprendidos com roteadores pe remotos normalmente empurram dois rótulos. O rótulo interno é 2 (pode ser diferente se o roteador PE publicitário 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 IPv6 explicit-null (rótulo 2). A busca baseada no rótulo interno na tabela de roteamento mpls.0 redireciona 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 IPv6 é feita usando a tabela de roteamento inet6.0.

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

As declarações a seguir permitem o salto final 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 ativar o salto final, inclua a ultimate-hop-popping declaração:

    Inclua esta declaração no nível de [edit protocols mpls label-switched-path label-switched-path-name] hierarquia para permitir que o salto final seja surgido em um LSP específico. Inclua esta declaração no nível de [edit protocols mpls] hierarquia para permitir o salto final em todos os LSPs de entrada configurados no roteador. Você também pode configurar a ultimate-hop-popping declaração sob os níveis de hierarquia equivalentes [edit logical-routers] .

    Nota:

    Quando você permite o estouro de salto final, o RSVP tenta renunciar aos LSPs existentes como LSPs de salto final em uma forma make-before-break. Se um roteador de saída não aceita o estouro de salto final, o LSP existente é derrubado (rSVP envia uma mensagem PathTear ao longo do caminho de um LSP, removendo o estado de caminho e o estado de reserva dependente e liberando os recursos de rede associados).

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

  2. Se você quiser habilitar os próximos hops de última geração e encadeados apenas em roteadores da Série MX 3D, você também precisa configurar a opção enhanced-ip para a network-services declaração:

    Você configura esta declaração no nível da [edit chassis] hierarquia. Depois de configurar a network-services declaração, você precisa reiniciar o roteador para habilitar o comportamento de UHP.

Configuração de LSPs de caminho explícito

Se você desativar a computação de caminho comutado por rótulos (LSP), conforme descrito na desativação da computação LSP de caminho restringido, você pode configurar LSPs manualmente ou permitir que os LSPs sigam o caminho do IGP.

Quando os LSPs de caminho explícito estão configurados, o LSP é estabelecido ao longo do caminho especificado por você. Se o caminho for topologicamente inviável, seja porque a rede está partilhada ou recursos insuficientes estão disponíveis em algumas partes do caminho, o LSP falhará. Nenhum caminho alternativo pode ser usado. Se a configuração for bem sucedida, o LSP permanecerá no caminho definido por tempo indefinido.

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

  1. Configure as informações do caminho em um caminho nomeado, conforme descrito na criação de caminhos nomeados. Para configurar informações completas do caminho, especifique cada salto 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 saltos de roteador, usando o loose atributo em locais onde o caminho está incompleto.

    Para caminhos incompletos, os roteadores MPLS completam o caminho consultando a tabela de roteamento local. Essa consulta é feita em uma base hop-by-hop, e cada roteador pode descobrir apenas informações suficientes para chegar ao próximo salto explícito. Talvez seja necessário atravessar vários roteadores para alcançar o próximo salto explícito .

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

  2. Para configurar o LSP e apontá-lo para o caminho nomeado, use a declaração ou secondary a primary declaração, conforme descrito na configuração de LSPs primários e secundários.

  3. Desativar a computação LSP de caminho limitado, incluindo a no-cspf declaração como parte do LSP ou como parte de uma primary ou secondary declaração. Para obter mais informações, consulte Desativação da computação LSP de caminho restrito.

  4. Configure quaisquer outras propriedades LSP.

O uso de 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 conta a reserva dinâmica de largura de banda da rede, de modo que os LSPs tendem a falhar quando os recursos ficam esgotados.

  • Quando um LSP de caminho explícito falha, você pode precisar repará-lo manualmente.

Devido a essas limitações, recomendamos que você use LSPs de caminho explícito apenas em situações controladas, como aplicar uma estratégia de colocação de LSP otimizada resultante de computaçãos 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 limitado é realizada. Para o caminho principal, todos os saltos intermediários são estritamente especificados para que sua rota não possa mudar. O caminho secundário deve percorrer o roteador 14.1.1.1 primeiro, em seguida, pegar qualquer rota disponível para chegar ao destino. A rota restante tomada pelo caminho secundário é tipicamente o caminho mais curto computado pelo IGP.

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

Os LSPs são estabelecidos com reservas de largura de banda configuradas para a quantidade máxima de tráfego que você espera atravessar o LSP. Nem todos os LSPs transportam a quantidade máxima de tráfego em seus links o tempo todo. Por exemplo, mesmo que a largura de banda para o enlace A tenha sido completamente reservada, 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, sobrescrevendo o link. Você pode inscrever demais a largura de banda configurada para tipos de classe individuais ou especificar um único valor para todos os tipos de classe usando uma interface.

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

Os exemplos a seguir descrevem como você pode usar a sobrescrição e subescrição de largura de banda:

  • Use a sobrescrição em tipos de classe onde os períodos de pico de tráfego não coincidem com o tempo.

  • Use a sobrescrição de tipos de classe que transportam tráfego de melhor esforço. Você corre o risco de atrasar temporariamente ou abandonar o tráfego em troca de uma melhor utilização dos recursos da rede.

  • Ofereça diferentes graus de sobrescrição ou subscrição de tráfego para os diferentes tipos de classe. Por exemplo, você configura a assinatura para aulas 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 menor do que a capacidade real do tipo de classe. Você pode usar a subescrição para limitar a utilização de um tipo de classe.

O cálculo de sobrescrição de 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 ser habilitado ou disponível em outros roteadores que podem não dar suporte a esse recurso. Os roteadores vizinhos não precisam saber sobre o cálculo de sobrescrição, eles dependem do IGP.

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

Sobrescrição de tamanho LSP

Para oversubscription de 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 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. O tamanho do LSP exige que o LSP possa exceder a alocação de largura de banda configurada.

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

Oversubscription class Type e Multiplicadores locais de sobresscrição

Os multiplicadores de sobrescrição locais (LOMs) permitem valores de sobrescrição diferentes para diferentes tipos de classe. Os LOMs são úteis para redes onde a relação de sobrescrição precisa ser configurada de maneira diferente em diferentes links e onde são necessários valores de sobrescrição para diferentes classes. Você pode usar esse recurso para inscrever demais tipos de classe que lidam com o tráfego de melhor esforço, mas não usam nenhuma sobrescrição para tipos de classe que lidam com o tráfego de voz. Um LOM é calculado localmente no roteador. Nenhuma informação relacionada a um LOM é sinalizada para outros roteadores na rede.

Um LOM é configurável em cada link e em cada tipo de classe. O LOM do tipo por classe permite que você aumente ou diminua a relação de sobrescrição. O LOM por tipo de classe é levado em contabilizando toda a largura de banda local para controle de admissão e anúncio de IGP de larguras de banda não reservidas.

O cálculo lom está vinculado ao modelo de largura de banda (MAM, MAM estendido e bonecas russas) usado, porque o efeito da sobrescrição entre tipos de classe deve ser contabilizado com precisão.

Nota:

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

As fórmulas relacionadas à sobreescrição de tipos de classe sã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 (100 por cento) de um tipo de classe seja usada para reservas de RSVP. Quando você inscreve demais 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 se inscrever demais ou subscrever todos os tipos de classe em uma interface usando a mesma largura de banda percentual, configure a porcentagem usando a subscription declaração:

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

Para subscrever ou subscrever demais a largura de banda para cada tipo de classe, configure uma porcentagem para cada tipo de classe (ct0, ct1ct2e ct3) para a subscription declaração. Quando você inscreve demais um tipo de classe, um LOM é aplicado para calcular a largura de banda real reservada. Consulte a sobrescrição por tipo de classe e os multiplicadores locais de sobresscrição para obter mais informações.

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

percentage é a porcentagem de largura de banda do tipo de classe que o RSVP permite ser usado para reservas. Pode ser um valor de 0 a 65.000 por cento. Se você especificar um valor superior a 100, você está atribuindo demais a interface ou o tipo de classe.

O valor que você configura quando inscreve demais um tipo de classe é uma porcentagem da largura de banda do tipo de classe que pode realmente ser usada. O valor de assinatura padrão é de 100%.

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

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

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

Esteja ciente dos seguintes problemas ao configurar a assinatura de largura de banda:

  • Se você configurar restrições de largura de banda no nível de [edit class-of-service interface interface-name] hierarquia, elas substituirão qualquer configuração de largura de banda que você especifique no nível de [edit protocols rsvp interface interface-name bandwidth] hierarquia para Diffserv-TE. Observe também que as restrições de largura de banda de CoS ou RSVP podem substituir as restrições de largura de banda de 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 subscription declaração nos [edit protocols rsvp interface interface-name] níveis de [edit protocols rsvp interface all] hierarquia), o valor específico da interface é usado para essa interface.

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

  • Você não pode incluir a subscription declaração tanto na configuração para um tipo de classe específico quanto na configuração de toda a interface. A operação de confirmação falha com a seguinte mensagem de erro:

Tabela de histórico de liberação
Versão
Descrição
14.1R9
Começando no Junos OS Versão 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 baixo fluxo, exceto pelas 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 a transição do mecanismo de roteamento.