Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Rotas LSP

MPLS e tabelas de roteamento

Os IGPs e BGP armazenar suas informações de roteamento na tabela de roteamento inet.0, a tabela de roteamento IP principal. Se o comando estiver configurado, permitindo apenas BGP usar caminhos MPLS para encaminhamento do tráfego, MPLS informações de caminho serão armazenadas em uma tabela de roteamento traffic-engineering bgp separada, inet.3. Somente BGP acessa a tabela de roteamento inet.3. BGP usa inet.0 e inet.3 para resolver endereços de next-hop. Se o comando estiver configurado, permitindo que os IGPs usem MPLS caminhos para encaminhamento do tráfego, MPLS informações de caminho serão armazenadas na tabela de roteamento traffic-engineering bgp-igp 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 de cada roteador de saída do LSP. Essa tabela de roteamento é usada em roteadores de entrada para rotear pacotes até o roteador de saída de destino. BGP usa a tabela de roteamento inet.3 no roteador de entrada para ajudar a resolver endereços de next-hop.

MPLS também mantém uma tabela de roteamento de MPLS de caminho (mpls.0), que contém uma lista do próximo roteador comutado por rótulos em cada LSP. Essa 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. (Esse roteador não precisa consultar mpls.0 porque o penúltimo roteador do LSP muda o rótulo do pacote para um valor de 0 ou pops o rótulo.) Em qualquer caso, o roteador de saída o encaminha como um pacote IPv4, consultando a tabela de roteamento IP, inet.0, para determinar como encaminhá-lo.

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

Quando BGP resolve um prefixo de next-hop, ele examina as tabelas de roteamento inet.0 e inet.3, buscando o próximo hop com a menor preferência. Se encontrar uma entrada de next-hop com uma preferência igual em ambas as tabelas de roteamento, 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

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

Quando BGP escolhe uma entrada de next-hop da tabela de roteamento inet.3, ela instala esse LSP na tabela de encaminhamento na Mecanismo de Encaminhamento de Pacotes, o que faz com que os pacotes destinados a esse próximo hop entrem e viajem ao longo do LSP. Caso o LSP seja removido ou não, o caminho é removido da tabela de roteamento inet.3 e da tabela de encaminhamento, e BGP reverte para usar um próximo hop da tabela de roteamento inet.0.

Visão geral do fast reroute

O reroute rápido fornece redundância para um caminho LSP. Ao habilitar o rerrote rápido, os desvios são pré-endossados e preestabelecidos ao longo do LSP. Em caso de falha na rede no caminho do LSP atual, o tráfego é rapidamente roteado 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ó downstream imediato. Cada desvio pode atravessar um ou mais roteadores comutado por rótulos (ou switches) que não sejam mostrados na figura.

O reroute 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 reroute rápido e dimensionado, os dispositivos perderão a capacidade de alcance para todos os colegas que foram conectados pelo enlace com falha. Isso leva à interrupção do tráfego, à medida que BGP a sessão entre os dispositivos acaba. Se houver várias falhas ao longo de um LSP, o reroute rápido pode falhar. Além disso, o reroute 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 enlace downstream falhou (usando um mecanismo de detecção de liveness específico da camada de enlace) ou se um nó downstream tiver falhado (por exemplo, usando o protocolo RSVP neighbor Hello), o nó muda rapidamente o tráfego para o desvio e, ao mesmo tempo, indica o roteador de entrada sobre a falha do link ou nó. Figura 4 ilustra o desvio feito quando o enlace entre o roteador B e o roteador C falha.

Figura 4: Faça o desvio após o enlace do roteador B ao roteador C falharFaça o desvio 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 não Figura 3 pode atravessar o enlace A-B e o roteador B. Caso esse caminho não seja possível, o desvio não ocorre.

Observe que, depois que o nó mudar o tráfego para o desvio, ele pode mudar o tráfego novamente para um novo desvio calculado logo depois. Isso porque a rota de desvio inicial pode não ser a melhor. Para fazer o rerouamento o mais rápido possível, o nó comuta o tráfego para o desvio inicial sem antes verificar se o desvio é válido. Depois que o switch é feito, o nó recomputa o desvio. Se o nó determinar se o desvio inicial ainda é válido, o tráfego continuará a fluí-lo por esse desvio. Se o nó determinar que o desvio inicial não é mais válido, ele volta a mudar o tráfego para um novo desvio computado.

Nota:

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

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

  • Tempo de detecção de falha no 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 link SONET/SDH normalmente é muito mais rápida do que em um enlace Ethernet Gigabit, e ambas são muito mais rápidas do que a detecção de uma falha do roteador.

  • Tempo necessário para splice do tráfego no desvio; esta operação é executada pelo Mecanismo de Encaminhamento de Pacotes, o que requer pouco tempo para a aplice do tráfego no desvio. O tempo necessário pode variar dependendo do número de LSPs sendo comutado para desvios.

O fast reroute é um patch de curto prazo para reduzir a perda de pacotes. Como a computação de desvios pode não reservar largura de banda adequada, os desvios podem introduzir congestionamento nos links alternativos. O roteador de entrada é o único roteador que está totalmente consciente das restrições da política de LSP e, portanto, é o único roteador capaz de encontrar caminhos alternativos adequados a longo prazo.

Os desvios são criados pelo uso do 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 tenha reroute rápido ativado. Criar mais de um desvio para cada PSL aumenta a sobrecarga, mas não serve para nada prático.

Para reduzir ainda mais a sobrecarga da rede, cada desvio tenta voltar ao LSP o mais rápido possível após o nó ou enlace com falha. Se você puder considerar um LSP que viaje por nós n de roteador, é possível criar n – 1 desvios. Por exemplo, em , o 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 Figura 5 gerenciável. Se as limitações da topologia impedem que o desvio volte rapidamente ao LSP, os desvios se fundem com outros desvios automaticamente.

Figura 5: Desvios se mesclando a outros desviosDesvios se mesclando a outros desvios

Configuração de reroute rápido

O fast reroute fornece um mecanismo para rearrafamento automático do 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 reroute rápido em um LSP, inclua a instrução no roteador de entrada fast-reroute (ou switch):

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

Você não precisa configurar um reroute rápido nos roteadores de trânsito e saída (ou switches) do LSP. Uma vez ativado o reroute rápido, o roteador de entrada (ou switch) indica todos os roteadores (ou switches) downstream que o reroute rápido está ativado no LSP, e cada roteador downstream faz o 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 configuração de desvios e continua a dar suporte ao LSP. Um roteador que não tenha suporte para reroute rápido causará falha em alguns dos desvios, mas caso contrário, não terá impacto no LSP.

Nota:

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

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

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

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

Restrições de limite de hop definem quantos roteadores mais um desvio pode atravessar em comparação com o LSP. Por padrão, o limite de hop é definido como 6. Por exemplo, se um LSP atravessar 4 roteadores, qualquer desvio para LSP pode ser de até 10 hops (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 (coloração) que o LSP principal quando o CSPF está determinando o caminho alternativo. Grupos administrativos, também conhecidos como coloração de enlace ou classe de recursos, são atributos atribuídos manualmente que descrevem a "cor" dos enlaces, de maneira que os enlaces com a mesma cor pertencem conceitualmente à mesma classe. Se você especificar a instrução ao configurar o LSP pai, todos os links atravessados pela sessão alternativa devem ter pelo menos uma cor encontrada include-any na lista de grupos. Se você especificar a instrução ao configurar o LSP pai, todos os links atravessados pela sessão alternativa devem ter todas as cores encontradas include-all na lista de grupos. Se você especificar a instrução ao configurar o LSP pai, nenhum dos links deve ter uma cor encontrada exclude na lista de grupos. Para obter mais informações sobre restrições de grupo administrativo, consulte Configurar grupos administrativos para LSPs.

Processo de fusão de desvios

Esta seção descreve o processo usado por um roteador para determinar qual LSP deve selecionar quando o roteador recebe mensagens de caminho de diferentes interfaces com objetos de Modelo de Sessão e Remetente idênticos. Quando isso ocorre, o roteador precisa fundir os estados do caminho.

O roteador emprega o processo a seguir para determinar quando e como mesclar os estados do caminho:

  • Quando todas as mensagens de caminho não incluem um reroute 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. Caso as mensagens de caminho não compartilhem 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 tiver origem nesse nó, selecione-o como o LSP final.

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

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

    • Caso vários candidatos finais de LSP permaneçam (ou seja, ainda há LSPs com desvio e proteção), selecione os LSPs com objetos de rerote rápido.

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

    • Dos restantes candidatos a PSL, elimine aqueles que atravessam nós que outros LSPs evitam.

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

  • Uma vez identificado o LSP final, o roteador deve transmitir apenas as mensagens de caminho que correspondem a esse 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 reroute rápido ativado e se um enlace ou nó downstream puder ser identificado, o roteador realizará uma computação CSPF (Shortest Path First) limitada usando as informações do banco de dados de engenharia de tráfego local. Por isso, os desvios dependem de sua segurança IGP extensões de engenharia de tráfego. Sem o banco de dados de engenharia de tráfego, não é possível estabelecer desvios.

Inicialmente, o CSPF tenta encontrar um caminho que ignore o próximo nó downstream. Tentar encontrar esse caminho fornece proteção contra falhas downstream em nós ou links. Se não estiver disponível um caminho de falta de nó, o CSPF tenta encontrar um caminho em um enlace alternativo para o próximo nó de downstream. Tentar encontrar um enlace alternativo fornece proteção apenas contra falhas de downstream nos enlaces. A computação de desvios pode não ter sucesso pela primeira vez. Se uma computação falha, o roteador recomputa os desvios aproximadamente uma vez a cada intervalo de atualização até a computação ter sucesso. A métrica de RSVP para cada desvio é definida como um valor na faixa de 10.000 a 19.999.

Otimização de caminho de reroute rápido

Um caminho de proteção de reroute rápido não é determinístico. 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 reroute rápido foi computado. A falta de comportamento determinístico pode levar a dificuldades operacionais e caminhos mal otimizados após várias abas de enlace em uma rede. Mesmo em uma rede pequena, depois de alguns caminhos de reroute rápido de link pode atravessar um número arbitrário de nós grandes e pode permanecer nesse estado indefinidamente. Isso é ineficiente e torna a rede menos previsível.

A otimização de reroute rápido atende a essa deficiência. Ele fornece um temporizador de otimização de caminho global, permitindo otimizar todos os LSPs que tenham reroute rápido ativado e um caminho de desvio em funcionamento. O valor do temporizador pode ser variado, dependendo da carga de processamento RE esperada.

O algoritmo de otimização de reroute rápido baseia-se apenas na IGP métrica. Enquanto a métrica de IGP do novo caminho for inferior à do caminho antigo, o resultado do CSPF é aceito, mesmo que o novo caminho possa ser mais congestionado (utilização de largura de banda mais alta) ou atravessar mais saltos.

Em conformidade com o RFC 4090, o Fast Reroute Extensions para RSVP-TEpara túneis LSP, quando um novo caminho é computado e aceito para otimização de reroute rápido, o desvio existente é destruído primeiro e, em seguida, o novo desvio é estabelecido. Para evitar perda de tráfego, os desvios que protegem o tráfego ativamente não são otimizados.

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

Você pode habilitar a otimização do caminho para reroute rápido configurando o temporizador de otimização de reroute rápido. O temporizador otimizado aciona um processo de otimização periódica que recomputa os LSPs de recaminhamento rápido para usar recursos de rede de maneira mais eficiente.

Para habilitar a otimização rápida do caminho de reroute, especifique o número de segundos usando a opção optimize-timer para a fast-reroute declaração:

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

  • [edit protocols rsvp]

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

Adicionar 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.) Instalar a rota do host permite BGP realizar a resolução de next-hop. Ele também impede que a rota do host invada os prefixos a partir de protocolos de roteamento dinâmicos e armazenados na tabela de roteamento inet.0 ou inet6.0.

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

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

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

As rotas especificadas são instaladas como nomes falsos na tabela de roteamento quando o LSP é estabelecido. Instalar rotas adicionais permite BGP resolver os próximos hops dentro do prefixo especificado e direcionar tráfego adicional para esses próximos saltos para um LSP específico.

Incluindo a opção com a instrução instala o prefixo especificado na tabela de roteamento activeinstall inet.0 ou inet6.0, que é a tabela de encaminhamento principal. O resultado é uma rota instalada na tabela de encaminhamento sempre que o LSP é estabelecido, o que significa que você pode rastrear 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 nome falso para roteadores que têm vários endereços sendo usados como BGP hops próximos ou para roteadores que não são MPLS capazes. Em qualquer um desses casos, o LSP pode ser configurado para outro sistema MPLS dentro do domínio local, que depois funciona como um roteador "border". O LSP termina no roteador de borda e, a partir desse roteador, o encaminhamento da Camada 3 leva o pacote até o roteador de next-hop verdadeiro.

No caso de uma interconexão, o roteador de borda do domínio pode atuar como o roteador proxy e anunciar o prefixo da interconexão se o roteador de borda não estiver configurando o BGP hop seguinte a si.

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) compatível com MPLS pode atuar como um proxy para toda a PoP e pode injetar um conjunto de prefixos que abrangem a PoP. Assim, todos os roteadores da PoP podem se anunciar como hops de BGP interior (IBGP), e o tráfego pode seguir o LSP para chegar ao roteador de núcleo. Isso significa que o roteamento IGP normal prevaleceria no PoP.

Você não pode usar os ou comandos nas rotas na tabela de roteamento pingtraceroute inet.3 ou inet6.3.

Para BGP de next-hop, 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 as várias rotas mais bem-escolhidas, foi escolhida a que tem o maior valor de preferência.

Nota:

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