Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Redundância de interface de serviços de enlace

Recursos e interfaces do pacote de serviços de camada 2

Conforme descrito em Habilitando pacotes de serviço, você pode configurar o AS ou o PIC multisserviços e o ASM interno na plataforma M7i para usar o pacote de serviços de Camada 2 ou Camada 3.

Quando você habilita o pacote de serviços de Camada 2, o AS ou o PIC multisserviços oferece suporte a serviços de link. No AS ou Multiservices PIC e no ASM, os serviços de enlace incluem o seguinte:

  • Componentes do Junos CoS — Configuração de filas de agendamento de CoS em interfaces lógicas LSQ descreve como os componentes do Junos CoS funcionam em interfaces IQ (lsq) de serviços de enlace. Para obter informações detalhadas sobre os componentes do Junos CoS, consulte o Guia do usuário da classe de serviço (Roteadores e switches EX9200).

  • Compactação de dados usando o protocolo de transporte em tempo real (CRTP) compactado para uso na transmissão de voz sobre IP (VoIP).

    Observação:

    Em interfaces LSQ, todo o tráfego multilink para um único pacote é enviado para um único processador. Se o CRTP estiver habilitado no pacote, ele adicionará sobrecarga à CPU. Como as interfaces de rede T3 suportam apenas um link por pacote, certifique-se de configurar um mapa de fragmentação para tráfego compactado nessas interfaces e especificar a no-fragmentation opção. Para obter mais informações, consulte Configurando a intercalação de pacotes sensível a atrasos e Configurando a fragmentação de CoS encaminhando classe em interfaces LSQ.

  • Intercalação de fragmentos de enlace (LFI) em enlaces do Frame Relay usando FRF.12 fragmentação de ponta a ponta — O padrão para FRF.12 é definido na especificação FRF.12, Acordo de Implementação de Fragmentação do Frame Relay.

  • LFI em links MLPPP (Multilink Point-to-Point Protocol).

  • Multilink Frame Relay (MLFR) end-to-end (FRF.15) — O padrão para FRF.15 é definido na especificação FRF.15, Acordo de Implementação do Multilink Frame Relay de Ponta a Ponta.

  • Multilink Frame Relay (MLFR) UNI NNI (FRF.16)— O padrão para FRF.16 é definido na especificação FRF.16.1, Acordo de Implementação do Multilink Frame Relay UNI/NNI.

  • MLPPP — O padrão para MLPPP é definido na especificação RFC 1990, O PPP Multilink Protocol (MP).

  • Extensão multiclasse para MLPPP — O padrão é definido na especificação RFC 2686, A extensão multiclasse para PPP multilink.

Para a interface LSQ no AS ou Multiservices PIC, a sintaxe de configuração é quase a mesma que para PICs de serviços multilink e link. A principal diferença é o uso do descritor lsq do tipo de interface em vez de ml ou ls. Quando você habilita o pacote de serviços de Camada 2 no PIC de AS ou Multisserviços, as seguintes interfaces são criadas automaticamente:

Os tipos grde interface , ip, , pemtpd, e vt são interfaces de túnel padrão que estão disponíveis no AS ou no PIC multisserviços, independentemente de você habilitar o pacote de serviços de Camada 2 ou Camada 3. Essas interfaces de túnel funcionam da mesma maneira para ambos os pacotes de serviços, exceto que o pacote de serviços de Camada 2 não suporta algumas funções de túnel, como mostrado na Tabela 5 na página 24. Para obter mais informações sobre interfaces de túnel, consulte Guia do usuário de interfaces de serviços de túnel e criptografia para dispositivos de roteamento.

Observação:

O tipo sp de interface é criado porque é necessário para o Junos OS. Para o pacote de serviços de Camada 2, a sp interface não é configurável, mas você não deve desabilitá-la.

O tipo de lsq-fpc/pic/port interface é a interface IQ de serviços de link físico (lsq). Os tipos lsq-fpc/pic/port:0 de interface representam lsq-fpc/pic/port:N pacotes FRF.16. Esses tipos de interface são criados quando você inclui a mlfr-uni-nni-bundles instrução no nível da [edit chassis fpc slot-number pic pic-number] hierarquia. Para obter mais informações, consulte Configurando filas de agendamento de CoS em interfaces lógicas LSQ.

Observação:

Nas interfaces DS0, E1 ou T1 em pacotes LSQ, você pode configurar a bandwidth declaração, mas o roteador não usará o valor de largura de banda se as interfaces estiverem incluídas em um pacote MLPPP ou MLFR. A largura de banda é calculada internamente de acordo com os intervalos de tempo, enquadramento e codificação de bytes da interface. Para obter mais informações sobre essas propriedades, consulte a Biblioteca de interfaces de rede do Junos OS para dispositivos de roteamento.

Configuração da redundância da interface LSQ em vários roteadores usando APS SONET

As interfaces IQ (lsq-) de serviços de enlace que são emparelhadas com PICs SONET podem usar a configuração de Comutação de Proteção Automática (APS) já disponível em redes SONET para fornecer recuperação de falhas. Os APS SONET oferecem recuperação de falhas stateless, se estiverem configurados em interfaces SONET em chassis separados e cada PIC SONET estiver emparelhado com um AS ou PIC multisserviços no mesmo chassi. Se uma das seguintes condições para falha de APS for atendida, o PIC SONET associado aciona a recuperação para o circuito de backup e seu AS ou PIC multisserviços associado. As condições de falha são:

  • Falha do IQ PIC dos serviços de enlace

  • Falha do FPC que hospeda o IQ PIC de serviços de enlace

  • Falha do Mecanismo de Encaminhamento de Pacotes

  • Falha do chassi

As diretrizes para a configuração de APS SONET são descritas na Biblioteca de interfaces de rede do Junos OS para dispositivos de roteamento.

As seções a seguir descrevem como configurar propriedades de failover:

Configurando a associação entre interfaces LSQ e SONET

Para configurar a associação entre AS ou PICs multisserviços que hospedam interfaces IQ de serviços de link e as interfaces SONET, inclua a lsq-failure-options declaração no nível da [edit interfaces] hierarquia:

Por exemplo, considere o seguinte cenário de rede:

  • O roteador primário inclui interfaces oc3-0/2/0 e lsq-1/1/0.

  • O roteador de backup inclui interfaces oc3-2/2/0 e lsq-3/2/0.

Configure APS SONET, com oc3-0/2/0 como circuito de trabalho e oc3-2/2/0 como circuito de proteção. Inclua a instrução para estender a trigger-link-failure falha aos PICs LSQ:

Observação:

Você deve configurar a lsq-failure-options declaração apenas no roteador principal. A configuração não é suportada no roteador de backup.

Para inibir o roteador de enviar mensagens de solicitação de terminação PPP ao host remoto se o IQ PIC de serviços de enlace falhar, inclua a no-termination-request [edit interfaces lsq-fpc/pic/port lsq-failure-options] declaração no nível de hierarquia:

Essa funcionalidade também é suportada em PICs de link. Para inibir o roteador de enviar mensagens de solicitação de terminação PPP ao host remoto se um PIC de link falhar, inclua a no-termination-request [edit interfaces interface-name ppp-options] declaração no nível de hierarquia.

A no-termination-request declaração é suportada apenas com configurações MLPPP e SONET APS e funciona apenas com interfaces PPP, PPP over Frame Relay e MLPPP nos seguintes PICs:

  • PICs OC3 IQ canalizados

  • PICs OC12 IQ canalizados

  • PICs STM1 IQ canalizados

  • PICs STM4 IQ canalizados

Configurando a interoperabilidade do APS SONET com o Cisco Systems FRF.16

Os roteadores da Juniper Networks configurados com APS podem não interoperar corretamente com o Cisco FRF.16. Para habilitar a interoperação, inclua a cisco-interoperability instrução no nível da [edit interfaces lsq-fpc/pic/port mlfr-uni-nni-bundle-options] hierarquia:

A send-lip-remove-link-for-link-reject opção solicita que o roteador envie um link de remoção do Link Integrity Protocol quando receber uma mensagem de rejeição add-link.

Restrições à redundância de APS para interfaces LSQ

As seguintes restrições se aplicam à recuperação de falha do LSQ:

  • Aplica-se apenas aos PICs IQ de serviços de enlace instalados em roteadores da Série M, exceto para roteadores M320.

  • Você deve configurar a failure-options declaração em interfaces físicas LSQ, não em unidades canalizadas MLFR.

  • Os PICs IQ do Link Services devem ser associados aos PICs do link SONET. Os PICs emparelhados podem ser instalados em roteadores diferentes ou no mesmo roteador; Em outras palavras, a recuperação entre chassis e intrachassis é suportada

  • A recuperação de falhas é stateless; como resultado, o flapping de rota e a perda do estado do enlace são esperados na recuperação entre chassis, exigindo a renegociação do PPP. Na recuperação intrachassis, nenhum impacto no tráfego é previsto com o failover do Mecanismo de Roteamento, mas o failover do PIC resulta em renegociação de PPP.

  • A comutação não é reversiva: quando o hardware original é restaurado ao serviço, o tráfego não volta automaticamente para ele.

  • A comutação normal de APS e a comutação de APS acionada por PIC só podem ser distinguidas verificando as mensagens de log do sistema.

    Observação:

    Quando um PIC de AS apresenta contrapressão persistente como resultado de um alto volume de tráfego por 3 segundos, a condição aciona um despejo automático de núcleo e uma reinicialização do PIC para ajudar a eliminar o bloqueio. Uma mensagem de log do sistema no nível LOG_ERR é gerada. Esse mecanismo se aplica a pacotes de serviços de Camada 2 e Camada 3.

Veja também

Configuração da redundância da interface LSQ em um único roteador usando APS SONET

A comutação stateless de um Link Services IQ PIC para outro dentro do mesmo roteador pode ser configurada usando o mecanismo SONET APS descrito em Configurando a redundância da interface LSQ em vários roteadores usando SONET APS. Cada PIC do IQ de serviços de enlace deve ser associado a um PIC de enlace SONET especificado dentro do mesmo roteador.

Observação:

Para a recuperação completa do intrachassi, incluindo a recuperação do failover do Mecanismo de Roteamento, a comutação graciosa do Mecanismo de Roteamento (GRES) deve ser habilitada no roteador. Para obter mais informações, consulte a Biblioteca de administração do Junos OS para dispositivos de roteamento.

Veja também

Configuração da redundância da interface LSQ em um único roteador usando interfaces virtuais

Você pode configurar a recuperação de falhas em roteadores da Série M, Série MX e Série T que têm vários PICs e DPCs AS ou multisserviços com lsq- interfaces especificando uma interface de redundância LSQ virtual (rlsq) na qual o IQ PIC de serviços de enlace primário está ativo e um PIC secundário está em espera. Se o PIC primário falhar, o PIC secundário se tornará ativo e todo o processamento LSQ será transferido para ele. Para determinar qual PIC está ativo no momento, emita o show interfaces redundancy comando.

Observação:

Essa configuração não requer o uso de APS SONET para failover. Podem ser usadas interfaces de rede que não suportam SONET, como interfaces T1 ou E1.

As seções a seguir fornecem mais informações:

Configuração de interfaces LSQ emparelhadas redundantes

O tipo rlsq de interface física especifica os emparelhamentos entre as interfaces primária e secundária lsq para permitir a redundância. Para configurar uma interface de backup lsq , inclua a redundancy-options declaração no nível da [edit interfaces rlsqnumber] hierarquia:

Para a rlsq interface, number pode ser de 0 a 1023. Se a interface primária lsq falhar, o processamento de tráfego muda para a interface secundária. A interface secundária permanece ativa mesmo após a recuperação da interface primária. Se a interface secundária falhar e a interface primária estiver ativa, o processamento será alternado para a interface primária.

A hot-standby opção é usada com configurações de redundância um-para-um, nas quais um PIC funcional é suportado por um PIC de backup. Ele é suportado com configurações MLPPP, CRTP, FRF.15 e FRF.16 para a interface LSQ para obter um serviço LSQ ininterrupto. Ele define o requisito para que o tempo de detecção e recuperação de falhas seja inferior a 5 segundos. O comportamento é reversivo, mas você pode alternar manualmente entre os PICs primários e secundários emitindo o request interfaces (revert | switchover) rlsqnumber comando de modo operacional. Ele também fornece um tempo de comutação de 5 segundos ou menos para FRF.15 e um máximo de 10 segundos para FRF.16.

A warm-standby opção é usada com configurações de redundância nas quais um PIC de backup oferece suporte a vários PICs em funcionamento. Os tempos de recuperação não são garantidos, pois a configuração deve ser completamente restaurada no PIC de backup após a detecção de uma falha.

Determinadas combinações de e warm-standby configuração não são permitidas e resultam em um erro de hot-standby configuração. Os seguintes exemplos são permitidos:

  • Interface rlsq0 configurada com primary lsq-0/0/0 e warm-standby, em combinação com a interface rlsq0:0 configurada com primary lsq-0/0/0:0

  • Interface rlsq0:0 configurada com primary lsq-0/0/0:0, em combinação com interface rlsq0:1 configurada com primary lsq-0/0/0:1

As combinações de exemplo a seguir não são permitidas:

  • Interface rlsq0 configurada com primary lsq-0/0/0 e hot-standby, em combinação com a interface rlsq0:0 configurada com primary lsq-0/0/0:0

  • Interface rlsq0:0 configurada com primary lsq-0/0/0:0, em combinação com interface rlsq1:0 configurada com primary lsq-0/0/0:0

  • Interface rlsq0:0 configurada com primary lsq-0/0/0:1, em combinação com interface rlsq1:1 configurada com primary lsq-0/0/0:1

  • Interface rlsq0 configurada com primary lsq-0/0/0, em combinação com interface rlsq1 configurada com primary lsq-0/0/0

Além disso, a mesma interface física não pode ser reutilizada como a interface primária para mais de uma rlsq interface, nem qualquer uma das interfaces lógicas associadas. Por exemplo, a interface lsq-0/0/0 primária não pode ser reutilizada em outra rlsq interface como lsq-0/0/0:0.

Restrições em interfaces LSQ redundantes

A falha do IQ PIC dos Serviços de Enlace ocorre nas seguintes condições:

  • O PIC primário falha ao inicializar. Nesse caso, a rlsq interface não é ativada e a intervenção manual é necessária para reiniciar ou substituir o PIC, ou para renomear o PIC primário para o secundário na rlsq configuração.

  • Se as seguintes condições não forem atendidas ao configurar uma rlsq interface:

    • O número de unidade alocado para a rlsq interface é menor que o número de pacotes de interface de rede para rede (UNI-NNI) (FRF.16) do Multilink Frame Relay alocados no PIC de serviços de link.

    • O identificador de conexão de link de dados (DLCI) está configurado para a rlsq interface.

    Se essas condições não forem atendidas, a rlsq interface não será inicializada. Quando você emite o show interfaces redundancy comando, o rlsq estado da interface é indicado como Waiting for primary MS PIC.

  • O PIC primário torna-se ativo e depois falha. O PIC secundário assume automaticamente o processamento.

  • Ocorre um failover para o PIC secundário. O PIC secundário então falha. Se o PIC primário tiver sido restaurado para o estado ativo, o processamento será alternado para ele.

  • O FPC que contém o IQ PIC de serviços de enlace falha.

As seguintes restrições se aplicam a configurações LSQ redundantes:

  • Recomendamos que os PICs primários e secundários sejam configurados em dois FPCs diferentes (em chassis diferentes dos roteadores M10i).

  • Você não pode configurar um Link Services IQ PIC com configurações explícitas de pacote e como um constituinte de uma rlsq interface.

  • Configurações LSQ redundantes fornecem suporte completo ao GRES. (Você deve configurar o GRES no nível de [edit chassis] hierarquia; veja a Biblioteca de Administração do Junos OS para Dispositivos de Roteamento.

  • Se você configurar a redundancy-options declaração com a hot-standby opção, a configuração deverá incluir um primary valor de interface e um secondary valor de interface.

  • Como o mesmo nome de interface é usado para hot-standby e warm-standby, se você modificar a configuração para alterar esse atributo, é recomendável primeiro desativar a interface, confirmar a nova configuração e, em seguida, reativar a interface.

  • Não é possível fazer alterações em uma configuração ativa redundancy-options . Você deve desativar a configuração da rlsqnumber interface, alterá-la e reativá-la.

  • A rlsqnumber configuração se torna ativa somente se a interface primária estiver ativa. Quando a configuração é ativada pela primeira vez, a interface primária deve estar ativa; caso contrário, a rlsq interface aguarda até que a interface primária seja ativada.

  • Você não pode modificar a configuração das lsq interfaces depois que elas tiverem sido incluídas em uma interface ativa rlsq .

  • Todos os comandos de modo operacional que se aplicam a rsp interfaces também se aplicam a rlsq interfaces. Você pode emitir show comandos para a rlsq interface ou as interfaces primária e secundária lsq . No entanto, as estatísticas nas interfaces de enlace não são transportadas após uma comutação do Mecanismo de Roteamento.

  • As rlsq interfaces também suportam a configuração, discutida em Configurando a lsq-failure-options redundância de interface LSQ em vários roteadores usando APS SONET. Se os PICs IQ de serviços de enlace primário e secundário falharem e a lsq-failure-options declaração estiver configurada, a configuração acionará um switchover de APS SONET.

  • Configurações LSQ redundantes que exigem MLPPP Multilink Frame Relay (FRF.15 e FRF.16) são suportadas apenas com a warm-standby opção.

  • O suporte LSQ redundante é estendido para interfaces de rede ATM.

  • Interfaces canalizadas são usadas com feixes FRF-16, por exemplo rlsq0:0. O rlsq número e seus constituintes, as primary interfaces e secondary Para obter um exemplo de uma configuração FRF.16, consulte #id-configuring-lsq-interface-redundância-in-a-single-roteador-using-virtual-interfaces__d85e790.

  • Ao configurar uma interface canalizada rlsq , você deve usar um número de índice de canal de 0 a 254.

Observação:

Serviços adaptativos e multisserviços PICs no modo de camada 2 (executando serviços de camada 2) não são reinicializados quando uma situação de controle de fluxo MAC é detectada.

Configuração da replicação de estado de enlace para PICs de enlace redundantes

A replicação de estado de enlace, também chamada de preservação de interface, é uma adição à funcionalidade SONET Automatic Protection Switching (APS) que ajuda a promover a redundância dos PICs de enlace usados em configurações LSQ.

A replicação de estado de enlace oferece a capacidade de adicionar dois conjuntos de links, um do PIC SONET ativo (em funcionamento) e outro do PIC SONET de backup (proteção) ao mesmo pacote. Se o PIC SONET ativo falhar, os links do PIC em standby serão usados sem causar uma renegociação de link. Todo o estado negociado é replicado dos links ativos para os links em standby para evitar a renegociação do link. Para obter mais informações sobre configurações de APS SONET, consulte a Biblioteca de interfaces de rede do Junos OS para dispositivos de roteamento.

Para configurar a replicação de estado de link, inclua a preserve-interface declaração no nível de [edit interfaces interface-name sonet-options aps] hierarquia em ambas as interfaces de rede:

As seguintes restrições se aplicam à redundância de PIC de link:

  • A funcionalidade APS deve estar disponível nos PICs SONET e as configurações da interface devem ser idênticas em ambas as extremidades do link. Qualquer incompatibilidade de configuração faz com que a operação de confirmação falhe.

  • Esse recurso é suportado apenas com PICs de link habilitados para LSQ e SONET APS, incluindo PICs de enfileiramento inteligente (IQ) OC3 canalizado, OC12 canalizado e STM1 canalizado.

  • A replicação de estado de enlace dá suporte a MLPPP e PPP sobre encapsulamento de Frame Relay (frame-relay-ppp) e oferece suporte total a GRES.

  • Habilitar os traceoptions de interface ou protocolo com um grande número de links MLPPP pode disparar a renegociação do Link Control Protocol (LCP) durante o tempo de comutação do link.

    Observação:

    É mais provável que essa renegociação ocorra para configurações com roteadores consecutivos da Juniper Networks do que em redes nas quais um roteador da Juniper Networks está conectado a um multiplexador add/drop (ADM).

  • Em geral, as redes que conectam um roteador da Juniper Networks a um ADM permitem uma comutação de link MLPPP mais rápida do que aquelas com roteadores consecutivos da Juniper Networks. A diferença de tempo de comutação de link MLPPP pode ser significativa, especialmente para redes com um grande número de links MLPPP.

  • Uma configuração agressiva de tempo limite de manutenção de atividade do LCP pode levar à renegociação do LCP durante a comutação do enlace MLPPP. Por padrão, o intervalo do temporizador de keepalive do LCP é de 10 segundos e a contagem de links consecutivos é 3. Os links MLPPP iniciam a negociação LCP somente após um tempo limite de 30 segundos. A redução desses valores de configuração pode acionar um ou mais links MLPPP para renegociar durante o tempo de comutação.

    Observação:

    É mais provável que a renegociação de LCP ocorra para configurações com roteadores consecutivos da Juniper Networks do que em redes nas quais um roteador da Juniper Networks está conectado a um ADM.

Como exemplo, a configuração a seguir mostra a configuração de replicação de estado do link entre as portas coc3-1/0/0 e coc3-2/0/0.

Exemplos: Configuração de interfaces LSQ redundantes para recuperação de falhas

Configurando a redundância de interface LSQ para MLPPP

A configuração a seguir mostra que lsq-1/1/0 e lsq-1/3/0 funcionam como um par e o tipo de redundância é hot-standby, que define o requisito para que o tempo de detecção e recuperação de falhas seja inferior a 5 segundos:

O exemplo a seguir mostra uma configuração MLPPP relacionada:

Observação:

A configuração do protocolo MLPPP é necessária para essa configuração.

O exemplo a seguir mostra uma configuração de CoS relacionada:

O exemplo a seguir mostra uma configuração completa de replicação de estado de link para MLPPP. Este exemplo usa dois pacotes, cada um com quatro links T1. Os primeiros quatro elos T1 (t1-*:1 até t1-*:4) formam o primeiro feixe e os últimos quatro elos T1 (t1-*:5 até t1-*:8) formam o segundo pacote. Para minimizar a duplicação na configuração, este exemplo usa a [edit groups] declaração; para obter mais informações, consulte a Biblioteca de Administração do Junos OS para Dispositivos de Roteamento. Esse tipo de configuração não é necessário; simplifica a tarefa e minimiza a duplicação.

Configuração da redundância da interface LSQ para um pacote FRF.15

O exemplo a seguir mostra uma configuração para um pacote FRF.15:

Configurando a redundância da interface LSQ para um pacote FRF.16

O exemplo a seguir mostra uma configuração para um pacote FRF.16:

Veja também