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 principal tabela de roteamento IP. Se o traffic-engineering bgp comando estiver configurado, permitindo assim que apenas o BGP use caminhos MPLS para encaminhamento de 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 tanto o inet.0 quanto o inet.3 para resolver endereços de próximo salto. Se o traffic-engineering bgp-igp comando estiver configurado, permitindo assim que os IGPs usem caminhos MPLS para encaminhamento de tráfego, as informações de caminho MPLS sã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.)
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 de próximo salto.
O MPLS também mantém uma tabela de roteamento de caminho MPLS (mpls.0), que contém uma lista do próximo roteador comutada por 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 para determinar que este roteador é o roteador de saída.
Quando o BGP resolve um prefixo de próximo salto, 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 próximo salto com igual preferência em ambas as tabelas de roteamento, o BGP prefere a entrada na tabela de roteamento inet.3.
Geralmente, o BGP seleciona entradas de próximo salto na tabela de roteamento inet.3 porque suas preferências são sempre menores do que as preferências de próximo salto DO OSPF e IS-IS. Ao configurar LSPs, você pode substituir a preferência padrão pelos LSPs MPLS, o que pode alterar o processo de seleção do próximo salto.
Quando o BGP seleciona uma entrada de próximo salto 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 reverterá para usar um próximo salto da tabela de roteamento inet.0.
Visão geral rápida de redirecionamento
O redirecionamento rápido oferece redundância para um caminho LSP. Quando você habilita o redirecionamento rápido, os desvios são pré-complicados 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 por um ou mais roteadores comutos de rótulo (ou switches) que não são mostrados na figura.
O redirecionamento rápido protege o tráfego contra qualquer ponto único 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 link 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.
Se um nó detectar que um link downstream falhou (usando um mecanismo de detecção de liveness específico da camada de link) ou se um nó de downstream 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 o link ou falha no nó. Figura 4 ilustra o desvio feito quando a ligação entre o roteador B e o roteador C falha.
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. 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 recentemente calculado logo depois. Isso porque a rota de desvio inicial pode não ser a melhor rota. Para fazer o redirecionamento 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 novamente muda o tráfego para um desvio recém-computado.
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 redirecionamento rápido entre em vigor depende de dois intervalos de tempo independentes:
Tempo para detectar que há 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 link 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 Packet Forwarding Engine, o que requer pouco tempo para unir o tráfego no 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 links 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 do RSVP e, como todas as sessões de RSVP, exigem um estado extra e sobrecarga na rede. Por essa razão, cada nó estabelece no máximo um desvio para cada LSP que tem o redirecionamento rápido habilitado. Criar mais de um desvio para cada LSP aumenta a sobrecarga, mas não serve para nenhum propósito 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 link com falha. Se você pode considerar um LSP que viaja por n nós do roteador, é possível criar n – 1 desvios. Por exemplo, o Figura 5desvio tenta voltar 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 automaticamente com outros desvios.
Configuração de redirecionamento rápido
O redirecionamento rápido fornece um mecanismo para redirecionar automaticamente o tráfego em um LSP se um nó ou link 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):
fast-reroute { (bandwidth bps | bandwidth-percent percentage); (exclude [ group-names ] | no-exclude ); hop-limit number; (include-all [ group-names ] | no-include-all); (include-any [ group-names ] | no-include-any); }
Você pode incluir essa declaração nos seguintes níveis de hierarquia:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
Você não precisa configurar o 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 o reencaminho rápido no LSP, e cada roteador downstream faz o seu melhor para configurar desvios para o LSP. Se um roteador downstream não suportar o redirecionamento rápido, ele ignora a solicitação de configurar desvios e continua a oferecer suporte ao LSP. Um roteador que não oferece suporte ao redirecionamento rápido fará com que alguns dos desvios falhem, mas de outra forma não tenha impacto no LSP.
Para permitir 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 entre 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 de desvio.
Ao incluir a bandwidth declaração, você pode especificar a quantidade específica de largura de banda (em bits por segundo [bps]) que deseja reservar para o caminho de 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 por tráfego. Para obter informações sobre como configurar a largura de banda para um LSP projetado para tráfego, veja configuração de LSPs projetados para tráfego.
As restrições de limite de salto definem quantos roteadores a mais um desvio é permitido atravessar em comparação com o próprio LSP. Por padrão, o limite de salto é 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 administrativo (coloração) que seu LSP pai quando o CSPF está determinando o caminho alternativo. Grupos administrativos, também conhecidos como coloração de enlaces 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. 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 links 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 grupo administrativo, 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 utiliza 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 roteador de próximo salto, o roteador as considera LSPs independentes e não as funde.
Para todas as mensagens de caminho que compartilham a mesma interface de saída e roteador de próximo salto, o roteador usa o processo a seguir para selecionar o LSP final:
Se apenas um LSP se originar deste nó, selecione-o como O LSP final.
Se apenas um LSP contém 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 há LSPs de desvio e protegidos), selecione os LSPs com objetos de redirecionamento rápido.
Se nenhum dos LSPs tiver objetos de redirecionamento rápido, selecione os que não tiverem 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 de 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 tiver sido 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 feitos 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 limitado primeiro (CSPF) usando as informações no banco de dados local de engenharia de tráfego. Por esse motivo, os desvios dependem de seu IGP que oferece 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 tenta inicialmente encontrar um caminho que ignora o próximo nó downstream. Tentar encontrar esse caminho fornece proteção contra falhas de downstream em nós ou links. Se um caminho de desbravamento de 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 de downstream 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 a cada intervalo de atualização até que a computação seja bem sucedida. A métrica de RSVP para cada desvio é definida para 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 da história 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 pequena rede, depois de alguns flaps de ligação, caminhos de redirecionamento rápido podem atravessar um número extremamente 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 global de otimização de caminhos, permitindo que você otimize todos os LSPs que tenham um redirecionamento rápido habilitado e um caminho de desvio em funcionamento. O valor do temporização 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 saltos.
Em conformidade com a RFC 4090, extensões de redirecionamento rápido 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 então o novo desvio é estabelecido. Para evitar perda 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 timer de otimização rápida de redirecionamento. O temporização otimizado desencadeia um processo de otimização periódica que recomputa os LSPs de desvio rápido para usar os recursos de rede de forma mais eficiente.
Para permitir a otimização rápida do caminho de redirecionamento, especifique o número de segundos usando a opção de otimizador de temporização para a fast-reroute declaração:
fast-reroute seconds;
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 ao 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 de rota do host é aquele que você configura na to declaração.) A instalação da rota do host permite que o BGP realize uma resolução de próximo salto. Ele também impede que a rota do host interfira nos prefixos aprendidos com protocolos dinâmicos de roteamento 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 ping ou traceroute comandar 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 show route table inet.3 ou show route table inet6.3 o comando.
Para injetar rotas adicionais na tabela de roteamento inet.3 ou inet6.3, inclua a install declaração:
install { destination-prefix <active>; }
Você pode incluir essa declaração nos seguintes níveis de hierarquia:
[edit protocols mpls label-switched-path lsp-name][edit protocols mpls static-label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls static-label-switched-path lsp-name]
As rotas especificadas são instaladas como codinomes na tabela de roteamento quando o LSP é estabelecido. A instalação de rotas adicionais permite que o BGP resolva os próximos saltos dentro do prefixo especificado e direcione tráfego adicional para esses próximos saltos para um LSP específico.
Incluir 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 principal. O resultado é uma rota que é instalada na tabela de encaminhamento sempre que o LSP é estabelecido, o que significa que você pode pingar ou rastrear a rota. Use essa opção com cuidado, pois esse tipo de prefixo é muito semelhante a uma rota estática.
Você usa rotas de vulto para roteadores que têm vários endereços sendo usados como próximo salto BGP, 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 então termina no roteador de borda e, a partir desse roteador, o encaminhamento de Camada 3 leva o pacote para o verdadeiro roteador de próximo salto.
No caso de uma interconexão, o roteador de borda do domínio pode agir como o roteador proxy e pode anunciar o prefixo para a interconexão se o roteador de borda não estiver configurando o BGP próximo salto para si mesmo.
No caso de um ponto de presença (POP) que tenha roteadores que não oferecem suporte ao MPLS, um roteador (por exemplo, um roteador de núcleo) que oferece suporte ao MPLS pode agir 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 próximos saltos BGP interior (IBGP), e o tráfego pode seguir o LSP para chegar ao roteador de núcleo. Isso significa que o roteamento normal de IGP prevaleceria dentro do POP.
Você não pode usar ou pingtraceroute comandos em rotas na tabela de roteamento inet.3 ou inet6.3.
Para resolução de próximo salto 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.
A install destination-prefix active declaração não é suportada em 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.