Backup de Dial-on-Demand Routing (DDR) é um método de ativar um link alternativo em caso de falha do link WAN primário. O roteador configurado para o backup DDR reconhece que a conexão com o site remoto foi perdida, e inicia uma conexão DDR com o site remoto, usando uma mídia de transmissão diferente.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Configurar o backup de DDR envolve duas etapas distintas:
Configure a DDR com a chamada anterior ou usando perfis de discagem. Verifique se sua conexão DDR funciona corretamente antes de implementar a configuração de backup. Isso permitirá verificar se o método de discagem utilizado, a negociação do PPP (Point-to-Point Protocol) e a autenticação são bem-sucedidas antes de configurar o backup. Para obter configurações DDR de exemplo (sem backup DDR), consulte Configurando ISDN DDR com Perfis de Discador e Configurando Discagem BRI para BRI com Mapas de Discador DDR.
Configure o roteador para iniciar a conexão de DDR de backup quando o enlace principal falhar. Este documento aborda como determinar o método de backup a ser usado.
O roteador usa um dos três métodos a seguir para monitorar a conexão principal e iniciar a conexão de backup quando necessário, conforme listado a seguir:
Interface de Backup - Esta é uma interface que permanece como reserva até que o protocolo de linha de interface primário seja detectado como desativado e ativado.
Floating Static Route Essa rota de backup tem uma distância administrativa maior do que a da rota de conexão primária e, portanto, não estará na tabela de roteamento até que a interface primária seja desativada.
Dialer Watches - O Dialer Watch é um recurso de backup que integra o backup de discagem à capacidade de roteamento.
Este documento discute os recursos de cada método e fornece referências para outros documentos que descrevem como configurá-los. Para obter mais informações sobre configuração e solução de problemas, consulte Configuring and Troubleshooting DDR Backup (Configurando e solucionando problemas de backup de DDR).
Uma interface de backup é uma interface que permanece inativa até que determinadas circunstâncias ocorram e, em seguida, ela é ativada. A interface de backup pode ser uma interface física como uma interface de taxa básica (BRI, Basic Rate Interface), ou uma interface de discador de backup utilizada em um conjunto de discadores. Quando a linha principal está ativa, a interface de backup é colocada no modo de standby. Uma vez em reserva, a interface de backup é desligada efetivamente até ser habilitada. Nenhuma rota associada à interface de backup aparecerá na tabela de roteamento.
Quando o dispositivo recebe uma indicação de que a interface primária está desativada, a interface de backup é ativada. O tempo que o dispositivo aguarda para ativar a interface de backup é ajustável usando-se o comando backup delay. Também é possível configurar a interface de backup para ser desativada (após um tempo especificado) quando a conexão principal for restaurada.
Como o comando backup interface depende de o roteador identificar que uma interface está fisicamente inativa, ele costuma ser usado para fazer o backup de conexões BRI ISDN, de linhas assíncronas e de linhas em uso. Isto ocorre porque as interfaces para tais conexões são desativadas quando o enlace falha, por isso a interface de backup pode identificar rapidamente tais falhas. O enfoque de interface de backup também pode ser usado para subinterfaces Frame Relay ponto-a-ponto. Todavia, com o Frame Relay, as interfaces principais ou multipontos podem permanecer em um estado up/up mesmo se a PVC (Conexão permanente virtual) estiver inativa. Isso pode fazer com que o roteador não detecte uma conexão de Frame Relay principal inativa e, portanto, deixe de ativar o enlace de backup.
Ela é independente dos protocolos de roteamento. Ou seja, não depende da convergência do Routing Protocol, da estabilidade da rota etc.
Ele pode se basear na carga (Largura de Banda Sob Demanda). Enlaces adicionais podem ser adicionados a uma conexão, dependendo da carga de tráfego.
Ela é dependente da interface desativada. O roteador deve detectar que o protocolo de linha de interface primária está desativado para que ele possa ativar o enlace de backup.
Ela depende do tráfego interessante para engatilhar a backup de chamada DDR. Assim, mesmo se a interface de backup sair do modo em espera, o roteador não disparará a chamada de backup a menos que receba tráfego interessante para essa interface de backup.
A encapsulação é um fator. Por exemplo, com uma conexão Frame Relay, o protocolo de linha talvez não seja desativado quando uma determinada PVC/DLCI é desativada. Como o roteador não pode detector a falha, o enlace de backup pode não ser ativado.
A interface de backup é colocada em modo de standby e não pode ser usada enquanto a interface principal estiver ativada. Assim, a colocação de interfaces físicas, como a interface bri 0 (para BRIs) ou a interface Serial0:23 (para PRIs) como a interface de backup, as torna inutilizáveis. Você pode evitar isso usando perfis de discador para o link de backup. Com perfis de discagem, apenas o lógico (interface de discagem) é colocado no modo standby enquanto a interface física (BRI) ainda pode ser utilizada para outras conexões, tornando-a um membro de outro conjunto.
Isso fornece backup para uma interface em um único roteador.
Configuração da interface de backup para BRI com perfis de discagem
Backup de DDR utilizando BRIs e o comando de interface de backup
Rotas estáticas flutuantes são rotas estáticas que possuem uma distância administrativa maior que a distância administrativa das rotas dinâmicas. As distâncias administrativas podem ser configuradas em uma rota estática de modo que a rota estática seja menos desejável do que uma rota dinâmica. Dessa maneira, a rota estática não é usada quando a rota dinâmica estiver disponível. No entanto, caso a rota dinâmica seja perdida, a rota estática pode assumir o controle, e o tráfego pode ser enviado por essa rota alternativa. Se essa rota alternativa for fornecida usando uma interface DDR, então essa interface poderá ser usada como um mecanismo de backup.
Esta é a sequência de rotas estáticas flutuantes:
A interface primária aprende uma rota primária para uma rede remota (usando uma rota estática ou um protocolo de roteamento dinâmico). A distância administrativa dessa rota aprendida é menor do que a estática flutuante, logo, a rota aprendida é usada.
A interface primária torna-se inoperante, embora o protocolo de linha ainda possa estar ativo. A perda de atualizações de roteamento acaba removendo a rota primária aprendida na tabela de roteamento.
Observação: quando a rota primária é uma rota estática, o protocolo de linha da interface primária deve ser desativado para que a rota estática flutuante seja usada.
A rota flutuante é usada, uma vez que é agora a rota com a distância administrativa mais baixa.
Isso independe do status do protocolo da linha. Esta é uma consideração importante sobre os circuitos de Frame Relay, nos quais o protocolo de linha pode não ficar inativo caso o DLCI esteja inativo.
É independente do encapsulamento.
Ele pode realizar backup de múltiplas interfaces/redes em um roteador.
Requer um Routing Protocol.
Depende dos tempos de convergência do Routing Protocol. Uma rota não sincronizada pode fazer com que a interface de backup seja ativada desnecessariamente.
Normalmente, ela só fornece backup para um único roteador.
Ela depende do tráfego interessante para engatilhar a backup de chamada DDR. Por isso, mesmo se o roteador instalar a rota flutuante na tabela de rota, o roteador não dispara a chamada de backup, a menos que receba tráfego interessante para essa interface de backup. Na maioria dos casos, você deve marcar o protocolo de roteamento como não interessante para impedir que as atualizações periódicas/hellos mantenham o link de backup ativo.
Observação: embora os documentos acima descrevam o uso de rotas estáticas flutuantes para fazer backup de uma conexão Frame Relay, os mesmos conceitos de configuração se aplicam à maioria dos outros cenários de backup de WAN.
O dialer watch é um recurso de backup que integra o backup de discagem aos recursos de roteamento. Ela fornece conectividade confiável sem confiar exclusivamente na definição de tráfego interessante para disparar chamadas de saída no roteador central. Por isso, ela também pode ser considerada DDR regular sem nenhum requisito de tráfego interessante, apenas rotas perdidas. Configurando um conjunto de rotas observadas que definem a interface primária, você pode monitorar e acompanhar o status da interface primária porque as rotas observadas são adicionadas e excluídas.
Com o dialer watch, o roteador monitora a existência de uma rota especificada e, caso a rota não seja encontrada, ele inicia a discagem do link de backup. Ao contrário dos outros métodos de backup (como interface de backup ou rotas estáticas flutuantes) o dialer watch não exige tráfego interessante para acionar a discagem. O processo usado pelo Dialer Watch está descrito abaixo:
Quando uma rota vigiada for excluída, o dialer watch verifica pelo menos uma rota válida para qualquer um dos endereços IP ou redes sendo vigiados.
Se não houver rota válida, a linha principal será considerada inativa e inutilizável. Em seguida, o vigia do discador inicia a chamada e os roteadores se conectam e trocam informações de roteamento. Todo o tráfego para a rede local usará agora o backup de link.
Se houver uma rota válida definida para pelo menos uma das redes IP assistidas, e caso ela seja direcionada para uma interface que não seja a de backup configurada para o dialer watch, o link principal será considerado ativo e o dialer watch não iniciará o link de backup.
Quando o enlace de reserva estiver ativado, o enlace principal será verificado novamente no vencimento de cada limite de tempo de ociosidade. Se o enlace principal permanecer desativado, o cronômetro ocioso será reinicializado. Já que o roteador deve verificar periodicamente se o enlace principal foi restabelecido, você deve configurar um valor pequeno para dialer idle-timeout. Quando o link primário é restabelecido, o protocolo de roteamento atualiza a tabela de roteamento e todo o tráfego deve passar mais uma vez pelo link primário. Como o tráfego não passa mais pelo link de backup, o intervalo ocioso expira e o roteador desativa o link de backup.
Note:
Configure em protocolos de roteamento de roteadores chamadores como desinteressante na definição de tráfego interessante para impedir que saudações periódicas redefinam o intervalo ocioso. Como o roteador utilize a definição de tráfego interessante ONLY para verificar se o enlace primário está ativo, considere tornar todo o tráfego de IP desinteressante utilizando o comando dialer-list number protocol ip deny. Com essa definição de tráfego interessante, o intervalo ocioso nunca é reinicializado e o roteador verifica o status do link principal no intervalo especificado. No roteador de chamada, você não precisa definir o protocolo de roteamento dinâmico como tráfego não interessante, porque o roteador não fará nenhuma discagem para fora.
Configure o enlace de backup de modo a ser menos desejável do que o enlace principal, conforme visto pelo Routing Protocol utilizado. Isso se deve ao fato de o enlace primário tornar-se disponível novamente, o Dynamic Routing Protocol dar preferência ao enlace primário na discagem em vez do balanceamento de carga por dois enlaces, mantendo assim o backup do enlace ativo por tempo indeterminado. O link de backup pode ser configurado como menos desejável com os seguintes comandos; largura de banda, retardo ou distância, conforme apropriado.
Se o link primário for reativado, o link secundário de backup será desconectado. Entretanto, você pode implementar um cronômetro de desabilitação de forma que haja um retardo antes da perda do link de backup após a recuperação do link primário. Este cronômetro de retardo é iniciado quando o cronômetro ocioso expira, e a rota principal é descoberta ativa. Esse cronômetro de retardo pode garantir estabilidade, especialmente para interfaces não sincronizadas ou que estejam passando por alterações freqüentes de rota. Esse cronômetro de retardo pode garantir estabilidade, especialmente para interfaces não sincronizadas ou que estejam passando por alterações freqüentes de rota. Esse cronômetro de atraso pode ser configurado usando o comando dialer watch-disable seconds interface.
O vigia do discador tem as seguintes considerações:
Roteamento a inicialização de backup é vinculada ao Dynamic Routing Protocol em vez de uma entrada específica de interface ou rota estática. Portanto, as interfaces principal e de backup podem ter qualquer tipo de interface e podem ser utilizadas em interfaces múltiplas e roteadores múltiplos.
Semântica Sem Pacote - A observação de discador não confia em pacotes interessantes para disparar a discagem. O enlace é ativado automaticamente quando a rota principal fica inativa sem adiar a discagem. Esta é uma consideração importante sobre os circuitos de Frame Relay, nos quais o protocolo de linha pode não ficar inativo caso o DLCI esteja inativo.
Segurança do backup de discagem - A funcionalidade de rediscagem do dialer watch foi estendida para discar indefinidamente no caso de as linhas de backup secundárias não serem iniciadas. Normalmente, as tentativas de rediscagem de backup DDR são afetadas por valores enable-timeouts e wait-for-carrier time. Dificuldades de mídia intermitente ou interfaces não sincronizadas podem causar problemas para links DDR tradicionais. No entanto, o dialer watch restabelece automaticamente a linha de backup secundária no ISDN, além dos links seriais síncronos e assíncronos.
Você pode usar o relógio de discador para permitir que o roteador verifique se a rota principal está ativa após a conclusão da inicialização do roteador e o vencimento de um temporizador configurado (em segundos). Você pode usar o seguinte comando para conseguir isso:
dialer watch-list <group-number> delay route-check initial <seconds>
Este comando permite que o roteador verifique se a rota principal está ativada, depois que a partida inicial do roteador estiver concluída e o temporizador (em segundos) expirar. Sem este comando, o dialer watch é disparado somente quando a rota principal é removida da tabela de roteamento. Se o enlace principal não surgir durante a partida inicial do roteador, a rota nunca será adicionada à tabela de roteamento e assim não poderá ser observada. Dessa forma, com esse comando, o dialer watch disca o link de backup quando o link principal falha durante a inicialização do roteador.
Ele é útil em um cenário de backup de roteador múltiplo. Um roteador pode observar o enlace/rota entre dois outros roteadores e iniciar o backup se esse enlace falhar.
Ela depende do status do protocolo de linha.
Ele é independente do protocolo de roteamento dinâmico.
É independente do encapsulamento.
Disca imediatamente ao detectar a perda da rota principal.
Roteamento — a inicialização de backup é vinculada ao protocolo de roteamento dinâmico, e não uma interface específica ou entrada de rota estática. Portanto, as interfaces principal e de backup podem ter qualquer tipo de interface e podem ser utilizadas em interfaces múltiplas e roteadores múltiplos. A observação de discador também confia na convergência, às vezes preferencial em relação aos links DDR tradicionais.
Independente do protocolo de roteamento - As rotas estáticas ou os protocolos de roteamento dinâmico como Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP) ou Open Shortest Path First (OSPF) podem ser usados.
Semântica Sem Pacote — A observação de discador não confia exclusivamente em pacotes interessantes para disparar a discagem. O link é ativado automaticamente quando a linha primária fica inativa sem adiar a discagem.
Confiabilidade do backup de discagem — A funcionalidade de rediscagem DDR está estendida para discar indefinidamente caso as linhas de backup não sejam iniciadas. Tipicamente, as tentativas de rediscagem DDR são afetadas por valores de tempo de enable-timeouts e wait-for-carrier. Dificuldades de mídia intermitente ou interfaces não sincronizadas podem causar problemas para links DDR tradicionais. No entanto, o dialer watch restabelece automaticamente a linha de backup secundária no ISDN, além dos links seriais síncronos e assíncronos.
É mais difícil configurar do que fazer backup de interfaces e métodos de rota estática flutuante.
Ela exige um protocolo de roteamento.
Depende do tempo de convergência de Routing Protocol.
O roteador é compatível com backup de discagem, significando que o roteador tem um DCE (Equipamento de comunicação de dados), um adaptador de terminal ou um dispositivo de terminação de rede 1 anexado que suporta V.25 bis.
O roteador está configurado para DDR. Essa configuração inclui comandos tradicionais como comandos dialer map e dialer in-band.
No momento, o dialer watch só é suportado para IP.
O dialer watch era considerado instável até a versão 12.1(7) do software Cisco IOS®.
Observação: é recomendável que você use o Cisco IOS Software Release 12.1(7) ou posterior, o que inclui correções para bugs do IOS que afetam o dialer watch.
Configuração do backup de chamanda DDR usando BRIs e o Dialer Watch
Configuração do backup assíncrono de porta Aux-to-Aux com dialer watch
A tabela a seguir resume as características dos três métodos de backup. Você pode usá-la para comparar e avaliá-los e tomar uma decisão sobre que método usar.
Observação: a tabela a seguir contém links para vários documentos no CCO que fornecem exemplos sobre como configurar cada um dos métodos de backup DDR.
Interface de backup | Rota Estática Flutuante | Dialer Watch |
---|---|---|
Dependente do status de protocolo de linha da interface primária e exige que a interface primária esteja desativada. | Emprega rotas estáticas com distância administrativa maior para disparar uma chamada DDR. | Analise rotas específicas na tabela do roteador e inicie o link de backup se a rota estiver ausente. |
A encapsulação é um fator. Por exemplo, o backup do Frame Relay pode não funcionar corretamente com a interface de backup. | Encapsulamento independente. | Encapsulamento independente. |
Não considere a conectividade ponto-a-ponto. Os problemas com conectividade fim-a-fim, tal como erros de roteamento, não disparam links de backup. | Avalia o status do enlace principal com base na existência de rotas para o peer. Assim, ele considera o status do enlace principal com base na capacidade de transmitir tráfego para o correspondente. | Avalia o status do enlace principal com base na existência de rotas para o peer. Assim, ele considera o status do enlace principal com base na capacidade de transmitir tráfego para o correspondente. |
Precisa de tráfego interessante para acionar a discagem do enlace de backup. | O tráfego interessante é necessário para disparar discar o link de backup mesmo depois da rota até o peer ser perdida. | Não confia em pacotes interessantes para disparar discagem. Discagem do link de backup é feita imediatamente quando a rota primária é perdida. |
Não depende do protocolo de roteamento. | Depende do tempo de convergência do Routing Protocol. | Depende do tempo de convergência do Routing Protocol. |
Independente do Routing Protocol. | Todos os Dynamic Routing Protocols suportados. | Todos os Dynamic Routing Protocols suportados. |
Limitado a um roteador, uma interface. | Normalmente limitado a um único roteador, mas com várias interfaces/redes. | Suporta um cenário de backup de vários roteadores Por exemplo, um roteador monitora o link entre outros dois roteadores e inicia o backup se esse link falhar. |
Pode ser usado para fornecer largura de banda sob demanda. A interface de backup pode ser configurada para ser ativada quando o link primário alcançar um limite especificado. | A largura de banda sob demanda não é possível uma vez que a rota para o peer existirá independentemente da carga do enlace principal. | A largura de banda sob demanda não é possível uma vez que a rota para o peer existirá independentemente da carga do enlace principal. |