Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Rotas LSP

Tabelas de MPLS e roteamento

Os IGPs e o BGP armazenam suas informações de roteamento na tabela de roteamento inet.0, a tabela principal de roteamento IP. Se o traffic-engineering bgp comando estiver configurado, permitindo assim que apenas o BGP use caminhos MPLS para encaminhar tráfego, as informações de caminho MPLS são armazenadas em uma tabela de roteamento separada, inet.3. Apenas o BGP acessa a tabela de roteamento inet.3. O BGP usa o inet.0 e o inet.3 para resolver endereços next-hop. Se o traffic-engineering bgp-igp comando estiver configurado, permitindo assim que os IGPs usem caminhos MPLS para encaminhar tráfego, as informações de caminho MPLS serão armazenadas na tabela de roteamento inet.0. (Figura 1 e Figura 2 ilustrar as tabelas de roteamento nas duas configurações de engenharia de tráfego.)

Figura 1: Tabelas de roteamento e encaminhamento, bgp de engenharia de tráfegoTabelas de roteamento e encaminhamento, bgp de engenharia de tráfego

A tabela de roteamento inet.3 contém o endereço de host do roteador de saída de cada LSP. Esta tabela de roteamento é usada em roteadores de entrada para rotear pacotes para o roteador de saída de destino. O BGP usa a tabela de roteamento inet.3 no roteador de entrada para ajudar na resolução de endereços next-hop.

O MPLS também mantém uma tabela de roteamento de caminho MPLS (mpls.0), que contém uma lista do próximo roteador comutador de rótulos em cada LSP. Esta tabela de roteamento é usada em roteadores de trânsito para rotear pacotes para o próximo roteador ao longo de um LSP.

Normalmente, o roteador de saída em um LSP não consulta a tabela de roteamento mpls.0. (Este roteador não precisa consultar mpls.0 porque o penúltimo roteador do LSP altera o rótulo do pacote para um valor de 0 ou coloca o rótulo.) Em ambos os casos, o roteador de saída o encaminha como um pacote IPv4, consultando a tabela de roteamento IP, inet.0, para determinar como encaminhar o pacote.

Quando um roteador de trânsito ou saída recebe um pacote MPLS, as informações na tabela de encaminhamento MPLS são usadas para determinar o próximo roteador de trânsito no LSP ou determinar que este roteador é o roteador de saída.

Quando o BGP resolve um prefixo de next-hop, ele examina as tabelas de roteamento inet.0 e inet.3, buscando o próximo salto com a menor preferência. Se encontrar uma entrada de next-hop com preferência igual em ambas as tabelas de roteamento, o BGP prefere a entrada na tabela de roteamento inet.3.

Figura 2: Tabelas de roteamento e encaminhamento, bgp-igp de engenharia de tráfegoTabelas de roteamento e encaminhamento, bgp-igp de engenharia de tráfego

Geralmente, o BGP seleciona entradas de next-hop na tabela de roteamento inet.3 porque suas preferências são sempre menores do que as preferências de next-hop do OSPF e IS-IS. Ao configurar LSPs, você pode substituir a preferência padrão por LSPs MPLS, o que pode alterar o processo de seleção do next-hop.

Quando o BGP seleciona uma entrada de next-hop na tabela de roteamento inet.3, ele instala esse LSP na tabela de encaminhamento no Mecanismo de Encaminhamento de Pacotes, o que faz com que os pacotes destinados a esse próximo salto entrem e viajem ao longo do LSP. Se o LSP for removido ou falhar, o caminho será removido da tabela de roteamento inet.3 e da tabela de encaminhamento, e o BGP volta a usar um próximo salto da tabela de roteamento inet.0.

Visão geral do reroute rápido

O redirecionamento rápido fornece redundância para um caminho LSP. Quando você habilita o redirecionamento rápido, os desvios são pré-compensados e pré-estabelecidos ao longo do LSP. Em caso de falha de rede no caminho LSP atual, o tráfego é rapidamente encaminhado para um dos desvios. Figura 3 ilustra um LSP do roteador A ao roteador F, mostrando os desvios estabelecidos. Cada desvio é estabelecido por um nó upstream para evitar o enlace em direção ao nó downstream imediato e ao nó de downstream imediato em si. Cada desvio pode atravessar um ou mais roteadores comutados por rótulos (ou switches) que não são mostrados na figura.

O redirecionamento rápido protege o tráfego contra qualquer ponto de falha entre os roteadores de entrada e saída (ou switches). Se houver uma falha em um cenário de redirecionamento rápido escalonado, os dispositivos perderão a acessibilidade para todos os pares que foram conectados por meio do enlace com falha. Isso leva à interrupção do tráfego, à medida que a sessão BGP entre os dispositivos cai. Se houver várias falhas ao longo de um LSP, o redirecionamento rápido pode falhar. Além disso, o redirecionamento rápido não protege contra falhas dos roteadores de entrada ou saída.

Figura 3: Desvios estabelecidos para um LSP usando reroute rápidoDesvios estabelecidos para um LSP usando reroute rápido

Se um nó detectar que um link downstream falhou (usando um mecanismo de detecção de liveness específico da camada de enlace) ou se um nó a jusante falhou (por exemplo, usando o protocolo de olá vizinho RSVP), o nó muda rapidamente o tráfego para o desvio e, ao mesmo tempo, sinaliza o roteador de entrada sobre a falha de enlace ou nó. Figura 4 ilustra o desvio feito quando a ligação entre o roteador B e o roteador C falha.

Figura 4: Desvio após o enlace do roteador B ao roteador C falharDesvio após o enlace do roteador B ao roteador C falhar

Se a topologia de rede não for rica o suficiente (não há roteadores suficientes com links suficientes para outros roteadores), alguns dos desvios podem não ter sucesso. Por exemplo, o desvio do roteador A para o roteador C Figura 3 não pode atravessar o enlace A-B e o roteador B. Se esse caminho não for possível, o desvio não ocorrerá.

Observe que, após o nó mudar o tráfego para o desvio, ele pode mudar o tráfego novamente para um desvio recém-calculado logo depois. Isso ocorre porque a rota de desvio inicial pode não ser a melhor rota. Para fazer o reencaminho o mais rápido possível, o nó muda o tráfego para o desvio inicial sem antes verificar se o desvio é válido. Assim que o switch é feito, o nó recomputa o desvio. Se o nó determinar que o desvio inicial ainda é válido, o tráfego continua a fluir por esse desvio. Se o nó determinar que o desvio inicial não é mais válido, ele muda novamente o tráfego para um desvio recém-computado.

Nota:

Se você emitir show comandos após o nó ter trocado o tráfego para o desvio inicial, o nó pode indicar que o tráfego ainda está fluindo sobre o LSP original. Essa situação é temporária e deve se corrigir rapidamente.

O tempo necessário para que um desvio de roteamento rápido entre em vigor depende de dois intervalos de tempo independentes:

  • Tempo para detectar que existe uma falha de enlace ou nó — esse intervalo depende muito da camada de enlace em uso e da natureza da falha. Por exemplo, a detecção de falhas em um enlace SONET/SDH normalmente é muito mais rápida do que em um link Gigabit Ethernet, e ambas são muito mais rápidas do que a detecção de uma falha no roteador.

  • Quantidade de tempo necessária para unir o tráfego no desvio — esta operação é realizada pelo Mecanismo de Encaminhamento de Pacotes, o que requer pouco tempo para unir o tráfego ao desvio. O tempo necessário pode variar dependendo do número de LSPs sendo trocados para desvios.

O redirecionamento rápido é um patch de curto prazo para reduzir a perda de pacotes. Como a computação de desvio pode não reservar largura de banda adequada, os desvios podem introduzir congestionamento nos enlaces alternativos. O roteador de entrada é o único roteador que tem plena consciência das restrições de política de LSP e, portanto, é o único roteador capaz de criar caminhos alternativos adequados a longo prazo.

Os desvios são criados pelo uso de RSVP e, como todas as sessões de RSVP, eles exigem estado extra e sobrecarga na rede. Por isso, cada nó estabelece no máximo um desvio para cada LSP que tem rerroteamento rápido habilitado. Criar mais de um desvio para cada LSP aumenta a sobrecarga, mas não serve a nenhum propósito prático.

Para reduzir ainda mais a sobrecarga da rede, cada desvio tenta se fundir de volta ao LSP o mais rápido possível após o nó ou enlace com falha. Se você pode considerar um LSP que viaja por n nós de roteador, é possível criar n – 1 desvios. Por exemplo, Figura 5o desvio tenta se fundir de volta ao LSP no Roteador D em vez de no Roteador E ou roteador F. A fusão de volta ao LSP torna o problema de escalabilidade de desvio mais gerenciável. Se as limitações de topologia impedirem que o desvio volte rapidamente ao LSP, os desvios se fundem com outros desvios automaticamente.

Figura 5: Desvios se fundindo em outros desviosDesvios se fundindo em outros desvios

Configuração de reroute rápido

O redirecionamento rápido fornece um mecanismo para redirecionar automaticamente o tráfego em um LSP se um nó ou enlace em um LSP falhar, reduzindo assim a perda de pacotes que viajam pelo LSP.

Para configurar o redirecionamento rápido em um LSP, inclua a fast-reroute declaração no roteador de entrada (ou switch):

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

Você não precisa configurar um redirecionamento rápido nos roteadores de trânsito e saída do LSP (ou switches). Uma vez habilitado o redirecionamento rápido, o roteador de entrada (ou switch) sinaliza todos os roteadores downstream (ou switches) que são habilitados para reroute rápido no LSP, e cada roteador downstream faz o seu melhor para configurar desvios para o LSP. Se um roteador downstream não tiver suporte para reroute rápido, ele ignora a solicitação de configurar desvios e continua a dar suporte ao LSP. Um roteador que não suporta reroute rápido fará com que alguns dos desvios falhem, mas de outra forma não tem impacto no LSP.

Nota:

Para habilitar o redirecionamento rápido do PFE, configure uma declaração de política de roteamento com a load-balance per-packet declaração no nível de [edit policy-options policy-statement policy-name then] hierarquia em cada um dos roteadores onde o tráfego pode ser redirecionado. Veja também a configuração do balanceamento de carga em LSPs RSVP.

Por padrão, nenhuma largura de banda é reservada para o caminho redirecionado. Para alocar largura de banda para o caminho redirecionado, inclua a bandwidth declaração ou a bandwidth-percent declaração. Você só pode incluir uma dessas declarações de cada vez. Se você não incluir a bandwidth declaração ou a bandwidth-percent declaração, a configuração padrão é não reservar largura de banda para o caminho do desvio.

Quando você inclui a bandwidth declaração, você pode especificar a quantidade específica de largura de banda (em bits por segundo [bps]) que você deseja reservar para o caminho do desvio. A largura de banda não precisa ser idêntica à alocada para o LSP.

Quando você especifica uma largura de banda por cento usando a bandwidth-percent declaração, a largura de banda do caminho de desvio é computada multiplicando a porcentagem de largura de banda pela largura de banda configurada para o LSP principal projetado pelo tráfego. Para obter informações sobre como configurar a largura de banda para um LSP projetado para tráfego, consulte a configuração de LSPs projetados por tráfego.

As restrições de limite de hop definem quantos roteadores a mais um desvio é permitido atravessar em comparação com o próprio LSP. Por padrão, o limite de hop é definido para 6. Por exemplo, se um LSP atravessar 4 roteadores, qualquer desvio para o LSP pode ser de até 10 (ou seja, 4 + 6) saltos de roteador, incluindo os roteadores de entrada e saída.

Por padrão, um desvio herda as mesmas restrições de grupo administrativas (colorir) que seu LSP pai quando o CSPF está determinando o caminho alternativo. Grupos administrativos, também conhecidos como coloração de enlace ou classe de recursos, são atribuídos manualmente atributos que descrevem a "cor" dos links, de modo que os links com a mesma cor conceitualmente pertencem à mesma classe. Se você especificar a include-any declaração ao configurar o LSP pai, todos os links atravessados pela sessão alternativa devem ter pelo menos uma cor encontrada na lista de grupos. Se você especificar a include-all declaração ao configurar o LSP pai, todos os enlaces atravessados pela sessão alternativa devem ter todas as cores encontradas na lista de grupos. Se você especificar a exclude declaração ao configurar o LSP pai, nenhum dos links deve ter uma cor encontrada na lista de grupos. Para obter mais informações sobre restrições de grupos administrativos, consulte Configuração de grupos administrativos para LSPs.

Processo de fusão de desvios

Esta seção descreve o processo usado por um roteador para determinar qual LSP selecionar quando o roteador recebe mensagens de caminho de diferentes interfaces com objetos idênticos de Session and Sender Template. Quando isso ocorre, o roteador precisa mesclar os estados de caminho.

O roteador emprega o seguinte processo para determinar quando e como mesclar estados de caminho:

  • Quando todas as mensagens de caminho não incluem um redirecionamento rápido ou um objeto de desvio, ou quando o roteador é a saída do LSP, nenhuma fusão é necessária. As mensagens são processadas de acordo com a engenharia de tráfego RSVP.

  • Caso contrário, o roteador deve registrar o estado do caminho, além da interface de entrada. Se as mensagens de caminho não compartilharem a mesma interface de saída e o roteador next-hop, o roteador as considera LSPs independentes e não as mescla.

  • Para todas as mensagens de caminho que compartilham a mesma interface de saída e o roteador next-hop, o roteador usa o seguinte processo para selecionar o LSP final:

    • Se apenas um LSP for originado deste nó, selecione-o como o LSP final.

    • Se apenas um LSP contiver um objeto de redirecionamento rápido, selecione-o como o LSP final.

    • Se houver vários LSPs e alguns deles tiverem um objeto de desvio, elimine aqueles que contêm um objeto de desvio do processo de seleção de LSP final.

    • Se vários candidatos finais de LSP permanecerem (ou seja, ainda houver desvio e LSPs protegidos), selecione os LSPs com objetos de redirecionamento rápido.

    • Se nenhum dos LSPs tiver objetos de redirecionamento rápido, selecione os sem objetos de desvio. Se todos os LSPs tiverem objetos de desvio, selecione todos eles.

    • Dos candidatos LSP restantes, elimine da consideração aqueles que atravessam nós que outros LSPs evitam.

    • Se vários LSPs candidatos ainda permanecerem, selecione aquele com o menor comprimento de caminho do objeto de rota explícito (ERO). Se mais de um LSP tiver o mesmo comprimento de caminho, selecione um aleatoriamente.

  • Assim que o LSP final for identificado, o roteador deve transmitir apenas as mensagens de caminho que correspondem a este LSP. Todos os outros LSPs são considerados mesclados neste nó.

Computação de desvio

A computação e a configuração de desvios são feitas de forma independente em cada nó. Em um nó, se um LSP tiver um redirecionamento rápido habilitado e se um link ou nó downstream puder ser identificado, o roteador realizará uma computação de Caminho Mais Curto Restrito Primeiro (CSPF) usando as informações no banco de dados de engenharia de tráfego local. Por isso, os desvios dependem de seu IGP para oferecer suporte a extensões de engenharia de tráfego. Sem o banco de dados de engenharia de tráfego, os desvios não podem ser estabelecidos.

O CSPF inicialmente tenta encontrar um caminho que ignora o próximo nó downstream. Tentar encontrar esse caminho fornece proteção contra falhas a jusante em nós ou links. Se um caminho sem nó não estiver disponível, o CSPF tenta encontrar um caminho em um link alternativo para o próximo nó downstream. Tentar encontrar um link alternativo fornece proteção contra falhas a jusante apenas em links. As computação de desvio podem não ter sucesso da primeira vez. Se uma computação falhar, o roteador recomputa desvios aproximadamente uma vez que cada intervalo de atualização até que a computação tenha sucesso. A métrica de RSVP para cada desvio é definida como um valor na faixa de 10.000 a 19.999.

Otimização rápida de caminhos de redirecionamento

Um caminho de proteção de redirecionamento rápido não é determinado. O caminho de proteção real de um nó específico depende do histórico do LSP e da topologia de rede quando o caminho de redirecionamento rápido foi computado. A falta de comportamento determinístico pode levar a dificuldades operacionais e caminhos mal otimizados após vários flaps de enlace em uma rede. Mesmo em uma rede pequena, depois de alguns flaps de enlace, caminhos de redirecionamento rápido podem atravessar um número arbitrariamente grande de nós e podem permanecer nesse estado indefinidamente. Isso é ineficiente e torna a rede menos previsível.

A otimização rápida de redirecionamento resolve essa deficiência. Ele oferece um temporizador de otimização de caminho global, permitindo que você otimize todos os LSPs que tenham reroute rápido habilitado e um caminho de desvio em funcionamento. O valor do temporizador pode ser variado dependendo da carga de processamento de RE esperada.

O algoritmo de otimização de redirecionamento rápido é baseado apenas na métrica IGP. Enquanto a métrica de IGP do novo caminho for menor do que a do caminho antigo, o resultado do CSPF é aceito, mesmo que o novo caminho possa ser mais congestionado (maior utilização de largura de banda) ou atravessar mais hops.

Em conformidade com o RFC 4090, extensões rápidas de reroute para RSVP-TE para túneis LSP, quando um novo caminho é computado e aceito para otimização rápida de redirecionamento, o desvio existente é destruído primeiro e, em seguida, o novo desvio é estabelecido. Para evitar perdas de tráfego, os desvios que protegem ativamente o tráfego não são otimizados.

Configurando o intervalo de otimização para caminhos de redirecionamento rápido

Você pode habilitar a otimização de caminhos para redirecionamento rápido configurando o temporizador otimizado de redirecionamento rápido. O temporizador otimizado desencadeia um processo de otimização periódica que recomputa os LSPs de desvio rápido para usar recursos de rede de maneira mais eficiente.

Para permitir a otimização rápida do caminho de redirecionamento, especifique o número de segundos usando a opção otimizador de temporizador para a fast-reroute declaração:

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

  • [edit protocols rsvp]

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

Adicionando rotas relacionadas a LSP à tabela de roteamento inet.3 ou inet6.3

Por padrão, uma rota de host em direção ao roteador de saída é instalada na tabela de roteamento inet.3 ou inet6.3. (O endereço da rota do host é o que você configura na to declaração.) A instalação da rota do host permite que o BGP execute a resolução de next-hop. Ele também impede que a rota do host interfira em prefixos aprendidos com protocolos de roteamento dinâmicos e armazenados na tabela de roteamento inet.0 ou inet6.0.

Ao contrário das rotas na tabela inet.0 ou inet6.0, as rotas na tabela inet.3 ou inet6.3 não são copiadas para o Mecanismo de Encaminhamento de Pacotes e, portanto, não causam alterações na tabela de encaminhamento do sistema diretamente. Você não pode usar o ou traceroute o ping comando por essas rotas. O único uso para inet.3 ou inet6.3 é permitir que o BGP execute a resolução de next-hop. Para examinar a tabela inet.3 ou inet6.3, use o ou show route table inet6.3 o show route table inet.3 comando.

Para injetar rotas adicionais na tabela de roteamento inet.3 ou inet6.3, inclua a install declaração:

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

As rotas especificadas são instaladas como pseudônimos na tabela de roteamento quando o LSP é estabelecido. A instalação de rotas adicionais permite que o BGP resolva os próximos hops dentro do prefixo especificado e direcione tráfego adicional para esses próximos hops para um LSP específico.

Incluindo a opção active com a install declaração instala o prefixo especificado na tabela de roteamento inet.0 ou inet6.0, que é a tabela de encaminhamento primária. O resultado é uma rota instalada na tabela de encaminhamento sempre que o LSP for estabelecido, o que significa que você pode pingar ou rastrear a rota. Use essa opção com cuidado, porque esse tipo de prefixo é muito semelhante a uma rota estática.

Você usa rotas de pseudônimo para roteadores que têm vários endereços sendo usados como BGP next hops, ou para roteadores que não são capazes de MPLS. Em qualquer um desses casos, o LSP pode ser configurado para outro sistema capaz de MPLS dentro do domínio local, que então atua como um roteador "border". O LSP termina no roteador de borda e, a partir desse roteador, o encaminhamento de Camada 3 leva o pacote até o verdadeiro roteador next-hop.

No caso de uma interconexão, o roteador de borda do domínio pode atuar como o roteador proxy e pode anunciar o prefixo para a interconexão se o roteador de borda não estiver definindo o BGP próximo hop para si mesmo.

No caso de um ponto de presença (POP) que tenha roteadores que não suportam MPLS, um roteador (por exemplo, um roteador de núcleo) que oferece suporte ao MPLS pode atuar como um proxy para todo o POP e pode injetar um conjunto de prefixos que cobrem o POP. Assim, todos os roteadores dentro do POP podem anunciar-se como bgp interior (IBGP) próximo hops, e o tráfego pode seguir o LSP para chegar ao roteador de núcleo. Isso significa que o roteamento IGP normal prevaleceria dentro do POP.

Você não pode usar os ping comandos ou traceroute as rotas na tabela de roteamento inet.3 ou inet6.3.

Para resolução de next-hop BGP, não faz diferença se uma rota está em inet.0/inet6.0 ou inet.3/inet6.3; a rota com a melhor combinação (máscara mais longa) é escolhida. Entre várias rotas de melhor correspondência, a que tem o maior valor de preferência é escolhida.

Nota:

A install destination-prefix active declaração não tem suporte para LSPs estáticos. Quando a install destination-prefix active declaração é configurada para um LSP estático, as rotas MPLS não são instaladas na tabela de roteamento inet.0.