Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Configurar

Exemplo 1: Trecho de configuração do roteador 1 (nome de host ZBFW1)

Exemplo 2: Trecho de configuração do roteador 2 (nome de host ZBFW2)

Troubleshoot

Confirme se os dispositivos podem se comunicar entre si

Exemplo 3: Detecção de presença de mesmo nível

Exemplo 4: Saída Granular

Exemplo 5: Status e prioridade da função

Exemplo 6: Confirmar se a ID do grupo RII está atribuída

Verifique se as conexões se replicam para o roteador peer

Exemplo 7: Conexões processadas

Obter saída de depuração

Problemas comuns

Controle e seleção de interface de dados

Grupo de RII ausente

Failover automático

Roteamento Assimétrico

Exemplo 11: Configuração de roteamento assimétrico

Informações Relacionadas

Introduction

Este guia fornece a configuração básica de alta disponibilidade (HA) do Zone Firewall para uma configuração ativa/em standby, bem como comandos de solução de problemas e problemas comuns observados com o recurso.

O Cisco IOS® Zone-Based Firewall (ZBFW) suporta HA para que dois roteadores Cisco IOS possam ser configurados em uma configuração ativa/standby ou ativa/ativa. Isso permite redundância para evitar um único ponto de falha.

Prerequisites

Requirements

Você deve ter uma versão posterior ao Cisco IOS Software Release 15.2(3)T.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Configurar

Este diagrama mostra a topologia usada nos exemplos de configuração.

Na configuração mostrada no Exemplo 1, o ZBFW é configurado para inspecionar o tráfego TCP, UDP e ICMP (Internet Control Message Protocol) de dentro para fora. A configuração mostrada em negrito configura o recurso HA. Nos roteadores Cisco IOS, o HA é configurado através do comando redundancy subconfig. Para configurar a redundância, a primeira etapa é ativar a redundância no mapa de parâmetros de inspeção global.

Depois de habilitar a redundância, insira a subconfiguração de redundância de aplicativo e selecione as interfaces usadas para controle e dados. A interface de controle é usada para trocar informações sobre o estado de cada roteador. A interface de dados é usada para trocar informações sobre as conexões que devem ser replicadas.

No Exemplo 2, o comando priority também é definido para tornar o Roteador 1 a unidade ativa no par se o Roteador 1 e o Roteador 2 estiverem operacionais. O comando preempt (também discutido neste documento) é usado para garantir que a falha ocorra quando a prioridade for alterada.

A etapa final é atribuir o Redundant Interface Identifier (RII) e o Redundancy Group (RG) a cada interface. O número do grupo RII deve ser exclusivo para cada interface, mas deve corresponder entre dispositivos para interfaces na mesma sub-rede. O RII é usado somente para o processo de sincronização em massa quando os dois roteadores sincronizam a configuração. É assim que os dois roteadores sincronizam interfaces redundantes. O RG é usado para indicar que as conexões por meio dessa interface são replicadas na tabela de conexão HA.

No Exemplo 2, o comando redundancy group 1 é usado para criar um endereço IP virtual (VIP) na interface interna. Isso garante o HA, pois todos os usuários internos se comunicam somente com o VIP, para o qual a unidade ativa processa.

A interface externa não tem nenhuma configuração de RG porque esta é a interface de WAN. A interface externa do Roteador 1 e do Roteador 2 não pertence ao mesmo Provedor de Internet (ISP). Na interface externa, um protocolo de roteamento dinâmico é necessário para garantir que o tráfego passe para o dispositivo correto.

Exemplo 1: Trecho de configuração do roteador 1 (nome de host ZBFW1)

parameter-map type inspect global

redundancy

log dropped-packets enable

!

redundancy

application redundancy

group 1

name ZBFW_HA

preempt

priority 200

control Ethernet0/2 protocol 1

data Ethernet0/2

!

class-map type inspect match-any PROTOCOLS

match protocol tcp

match protocol udp

match protocol icmp

class-map type inspect match-all INSIDE_TO_OUTSIDE_CMAP

match class-map PROTOCOLS

match access-group name INSIDE_TO_OUTSIDE_ACL

!

policy-map type inspect INSIDE_TO_OUTSIDE_PMAP

class type inspect INSIDE_TO_OUTSIDE_CMAP

inspect

class class-default

drop

!

ip access-list extended INSIDE_TO_OUTSIDE_ACL

permit ip any any

!

zone security INSIDE

zone security OUTSIDE

zone-pair security INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE

service-policy type inspect INSIDE_TO_OUTSIDE_PMAP

!

interface Ethernet0/0

ip address 10.1.1.1 255.255.255.0

ip nat inside

ip virtual-reassembly in

zone-member security INSIDE

redundancy rii 100

redundancy group 1 ip 10.1.1.3 exclusive

!

interface Ethernet0/1

ip address 203.0.113.1 255.255.255.0

ip nat outside

ip virtual-reassembly in

zone-member security OUTSIDE

redundancy rii 200

Exemplo 2: Trecho de configuração do roteador 2 (nome de host ZBFW2)

parameter-map type inspect global

redundancy

log dropped-packets enable

!

redundancy

application redundancy

group 1

name ZBFW_HA

preempt

priority 200

control Ethernet0/2 protocol 1

data Ethernet0/2

!

class-map type inspect match-any PROTOCOLS

match protocol tcp

match protocol udp

match protocol icmp

class-map type inspect match-all INSIDE_TO_OUTSIDE_CMAP

match class-map PROTOCOLS

match access-group name INSIDE_TO_OUTSIDE_ACL

!

policy-map type inspect INSIDE_TO_OUTSIDE_PMAP

class type inspect INSIDE_TO_OUTSIDE_CMAP

inspect

class class-default

drop

!

ip access-list extended INSIDE_TO_OUTSIDE_ACL

permit ip any any

!

zone security INSIDE

zone security OUTSIDE

zone-pair security INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE

service-policy type inspect INSIDE_TO_OUTSIDE_PMAP

!

interface Ethernet0/0

ip address 10.1.1.2 255.255.255.0

ip nat inside

ip virtual-reassembly in

zone-member security INSIDE

redundancy rii 100

redundancy group 1 ip 10.1.1.3 exclusive

!

interface Ethernet0/1

ip address 203.0.113.2 255.255.255.0

ip nat outside

ip virtual-reassembly in

zone-member security OUTSIDE

redundancy rii 200

Troubleshoot

Esta seção disponibiliza informações para a solução de problemas de configuração.

Confirme se os dispositivos podem se comunicar entre si

Para confirmar se os dispositivos podem se ver, você deve verificar se o estado operacional do grupo de aplicativos de redundância está ativo. Em seguida, certifique-se de que cada dispositivo tenha assumido a função correta e possa ver seu peer em suas funções corretas. No Exemplo 3, o ZBFW1 está ativo e detecta seu peer como standby. Isso é invertido em ZBFW2. Quando ambos os dispositivos também mostram que o estado operacional está ativo e sua presença de peer é detectada, os dois roteadores podem se comunicar com êxito através do link de controle.

Exemplo 3: Detecção de presença de mesmo nível

ZBFW1# show redundancy application group 1

Group ID:1

Group Name:ZBFW_HA

Administrative State: No Shutdown

Aggregate operational state : Up

My Role: ACTIVE

Peer Role: STANDBY

Peer Presence: Yes

Peer Comm: Yes

Peer Progression Started: Yes

RF Domain: btob-one

RF state: ACTIVE

Peer RF state: STANDBY COLD-BULK

!

ZBFW2#  show redundancy application group 1

Group ID:1

Group Name:ZBFW_HA

Administrative State: No Shutdown

Aggregate operational state : Up

My Role: STANDBY

Peer Role: ACTIVE

Peer Presence: Yes

Peer Comm: Yes

Peer Progression Started: Yes

RF Domain: btob-one

RF state: STANDBY COLD-BULK

Peer RF state: ACTIVE

A saída no Exemplo 4 mostra uma saída mais granular sobre a interface de controle dos dois roteadores. A saída confirma a interface física usada para controlar o tráfego e também confirma o endereço IP do peer.

Exemplo 4: Saída Granular

ZBFW1#  show redundancy application control-interface group 1

The control interface for rg[1] is Ethernet0/2

Interface is Control interface associated with the following protocols: 1

BFD Enabled

Interface Neighbors:

Peer: 10.60.1.2 Standby RGs: 1 BFD handle: 0

ZBFW1#  show redundancy application data-interface group 1

The data interface for rg[1] is Ethernet0/2

!

ZBFW2#  show redundancy application control-interface group 1

The control interface for rg[1] is Ethernet0/2

Interface is Control interface associated with the following protocols: 1

BFD Enabled

Interface Neighbors:

Peer: 10.60.1.1 Active RGs: 1 BFD handle: 0

ZBFW2#  show redundancy application data-interface group 1

The data interface for rg[1] is Ethernet0/2

Quando a comunicação é estabelecida, o comando no Exemplo 5 ajuda você a entender por que cada dispositivo tem sua função específica. O ZBFW1 está ativo porque tem uma prioridade mais alta que seu peer. O ZBFW1 tem uma prioridade de 200, enquanto o ZBFW2 tem uma prioridade de 150. Esta saída está realçada em negrito.

Exemplo 5: Status e prioridade da função

ZBFW1#  show redundancy application protocol group 1

RG Protocol RG 1

Role: Active

Negotiation: Enabled

Priority: 200

Protocol state: Active

Ctrl Intf(s) state: Up

Active Peer: Local

Standby Peer: address 10.60.1.2, priority 150, intf Et0/2

Log counters:

role change to active: 1

role change to standby: 0

disable events: rg down state 0, rg shut 0

ctrl intf events: up 1, down 0, admin_down 0

reload events: local request 0, peer request 0

RG Media Context for RG 1

--------------------------

Ctx State: Active

Protocol ID: 1

Media type: Default

Control Interface: Ethernet0/2

Current Hello timer: 3000

Configured Hello timer: 3000, Hold timer: 10000

Peer Hello timer: 3000, Peer Hold timer: 10000

Stats:

Pkts 249, Bytes 15438, HA Seq 0, Seq Number 249, Pkt Loss 0

Authentication not configured

Authentication Failure: 0

Reload Peer: TX 0, RX 0

Resign: TX 0, RX 0

Standby Peer: Present. Hold Timer: 10000

Pkts 237, Bytes 8058, HA Seq 0, Seq Number 252, Pkt Loss 0

!

ZBFW2#  show redundancy application protocol group 1

RG Protocol RG 1

------------------

Role: Standby

Negotiation: Enabled

Priority: 150

Protocol state: Standby-cold

Ctrl Intf(s) state: Up

Active Peer: address 10.60.1.1, priority 200, intf Et0/2

Standby Peer: Local

Log counters:

role change to active: 0

role change to standby: 1

disable events: rg down state 0, rg shut 0

ctrl intf events: up 1, down 0, admin_down 0

reload events: local request 0, peer request 0

RG Media Context for RG 1

--------------------------

Ctx State: Standby

Protocol ID: 1

Media type: Default

Control Interface: Ethernet0/2

Current Hello timer: 3000

Configured Hello timer: 3000, Hold timer: 10000

Peer Hello timer: 3000, Peer Hold timer: 10000

Stats:

Pkts 232, Bytes 14384, HA Seq 0, Seq Number 232, Pkt Loss 0

Authentication not configured

Authentication Failure: 0

Reload Peer: TX 0, RX 0

Resign: TX 0, RX 0

Active Peer: Present. Hold Timer: 10000

Pkts 220, Bytes 7480, HA Seq 0, Seq Number 229, Pkt Loss 0

A última confirmação é garantir que a ID do grupo RII seja atribuída a cada interface. Se você inserir esse comando em ambos os roteadores, eles verificarão duas vezes para garantir que os pares de interface na mesma sub-rede entre os dispositivos recebam a mesma ID de RII. Se não estiverem configuradas com a mesma ID RII exclusiva, as conexões não serão replicadas entre os dois dispositivos. Veja o exemplo 6.

Exemplo 6: Confirmar se a ID do grupo RII está atribuída

ZBFW1# show redundancy rii

No. of RIIs in database: 2

Interface                         RII Id     decrement

Ethernet0/1                   :   200           0

Ethernet0/0                   :   100           0

!

ZBFW2# show redundancy rii

No. of RIIs in database: 2

Interface                         RII Id     decrement

Ethernet0/1                     :   200           0

Ethernet0/0                     :   100           0

Verifique se as conexões se replicam para o roteador peer

No exemplo 7, o ZBFW1 passa ativamente o tráfego para uma conexão. A conexão foi replicada com êxito para o dispositivo de espera ZBFW2. Para visualizar as conexões processadas pelo firewall de zona, use o comando show policy-firewall session.

Exemplo 7: Conexões processadas

ZBFW1#show policy-firewall session

Session B2704178 (10.1.1.100:52980)=>(203.0.113.100:23) tcp

SIS_OPEN/TCP_ESTAB

Created 00:00:31, Last heard 00:00:30

Bytes sent (initiator:responder) [37:79]

HA State: ACTIVE, RG ID: 1

Established Sessions = 1

ZBFW2#show policy-firewall session

Session B2601288 (10.1.1.100:52980)=>(203.0.113.100:23) tcp

SIS_OPEN/TCP_ESTAB

Created 00:00:51, Last heard never

Bytes sent (initiator:responder) [0:0]

HA State: STANDBY, RG ID: 1

Established Sessions = 1

Observe que a conexão é replicada, mas os bytes transferidos não são atualizados. O estado da conexão (informações TCP) é atualizado regularmente através da interface de dados para garantir que o tráfego não seja afetado se ocorrer um evento de failover.

Para uma saída mais granular, insira o comando show policy-firewall session zone-pair <ZP> ha. Ele fornece saída semelhante à do Exemplo 7, mas permite que o usuário restrinja a saída somente ao par de zonas especificado.

Obter saída de depuração

Esta seção mostra os comandos debug que produzem saída relevante para solucionar problemas deste recurso.

A ativação de depurações pode ser muito intensa em um roteador ocupado. Portanto, você deve entender o impacto antes de ativá-los.

- debug redundancy application group rii event

Esse comando é usado para garantir que as conexões correspondam ao grupo RII correto a ser replicado corretamente. Quando o tráfego chega no ZBFW, as interfaces origem e destino são verificadas quanto a uma ID de grupo RII. Essas informações são então comunicadas através do enlace de dados ao peer. Quando o grupo RII do peer de standby se alinha com as unidades ativas, o syslog no Exemplo 8 é gerado e confirma as IDs de grupo RII que são usadas para replicar a conexão:

Exemplo 8: Syslog

debug redundancy application group rii event

debug redundancy application group rii error

!

*Feb  1 21:13:01.378: [RG-RII-EVENT]:  get idb: rii:100

*Feb  1 21:13:01.378: [RG-RII-EVENT]:  get idb: rii:200

- debug redundancy application group protocol all

Esse comando é usado para confirmar se os dois pares podem se ver. O endereço IP do peer é confirmado nas depurações. Como visto no Exemplo 9, o ZBFW1 vê seu peer no estado de standby com o endereço IP 10.60.1.2. O inverso é verdadeiro para ZBFW2.

Exemplo 9: Confirmar IPs pares em depurações

debug redundancy application group protocol all

!

ZBFW1#

*Feb  1 21:35:58.213: RG-PRTCL-MEDIA: RG Media event, rg_id=1, role=Standby,

addr=10.60.1.2, present=exist, reload=0, intf=Et0/2, priority=150.

*Feb  1 21:35:58.213: RG-PRTCL-MEDIA: [RG 1] [Active/Active] set peer_status 0.

*Feb  1 21:35:58.213: RG-PRTCL-MEDIA: [RG 1] [Active/Active] priority_event

'media: low priority from standby', role_event 'no event'.

*Feb  1 21:35:58.213: RG-PRTCL-EVENT: [RG 1] [Active/Active] select fsm event,

priority_event=media: low priority from standby, role_event=no event.

*Feb  1 21:35:58.213: RG-PRTCL-EVENT: [RG 1] [Active/Active] process FSM event

'media: low priority from standby'.

*Feb  1 21:35:58.213: RG-PRTCL-EVENT: [RG 1] [Active/Active] no FSM transition

ZBFW2#

*Feb  1 21:36:02.283: RG-PRTCL-MEDIA: RG Media event, rg_id=1, role=Active,

addr=10.60.1.1, present=exist, reload=0, intf=Et0/2, priority=200.

*Feb  1 21:36:02.283: RG-PRTCL-MEDIA: [RG 1] [Standby/Standby-hot]

set peer_status 0.

*Feb  1 21:36:02.283: RG-PRTCL-MEDIA: [RG 1] [Standby/Standby-hot] priority_event

'media: high priority from active', role_event 'no event'.

*Feb  1 21:36:02.283: RG-PRTCL-EVENT: [RG 1] [Standby/Standby-hot] select

fsm event, priority_event=media: high priority from active, role_event=no event.

*Feb  1 21:36:02.283: RG-PRTCL-EVENT: [RG 1] [Standby/Standby-hot] process

FSM event 'media: high priority from active'.

*Feb  1 21:36:02.283: RG-PRTCL-EVENT: [RG 1] [Standby/Standby-hot] no FSM

transition

Problemas comuns

Esta seção detalha alguns problemas comuns encontrados.

Controle e seleção de interface de dados

Aqui estão algumas dicas para VLANs de controle e dados:

- Não inclua as interfaces de controle e de dados na configuração do ZBFW. Apenas são utilizados para comunicar entre si; portanto, não há necessidade de proteger essas interfaces.

- As interfaces de controle e de dados podem estar na mesma interface ou VLAN. Isso preserva as portas no roteador.

Grupo de RII ausente

O grupo RII deve ser aplicado nas interfaces LAN e WAN. As interfaces LAN devem estar na mesma sub-rede, mas as interfaces WAN podem estar em sub-redes separadas. Se houver um grupo RII ausente em uma interface, esse syslog ocorrerá na saída do comando debug redundancy application group rii event e debug redundancy application group rii error:

000515: Dec 20 14:35:07.753 EST: FIREWALL*: RG not found for ID 0

Failover automático

Para configurar o failover automático, o HA do ZBFW deve ser configurado para rastrear um objeto SLA (Service Level Agreement, contrato de nível de serviço) e diminuir dinamicamente a prioridade com base nesse evento SLA. No Exemplo 10, o ZBFW HA rastreia o status do link da interface GigabitEthernet0. Se essa interface ficar inativa, a prioridade será reduzida para que o dispositivo peer seja mais favorecido.

Exemplo 10: Configuração de failover automático do ZBFW HA

redundancy

application redundancy

group 1

name ZBFW_HA

preempt

priority 230

control Vlan801 protocol 1

data Vlan801

track 1 decrement 200

!

track 1 interface GigabitEthernet0 line-protocol

redundancy

application redundancy

group 1

name ZBFW_HA

preempt

priority 180

control Vlan801 protocol 1

data Vlan801

Às vezes, o HA do ZBFW não faz failover automaticamente, mesmo que haja um evento de prioridade menor. Isso ocorre porque a palavra-chave preempt não está configurada em ambos os dispositivos. A palavra-chave preempt tem funcionalidade diferente da do failover do Hot Standby Router Protocol (HSRP) ou do Adaptive Security Appliance (ASA). No ZBFW HA, a palavra-chave preempt permite que um evento de failover ocorra se a prioridade do dispositivo for alterada. Isso está documentado no Guia de Configuração de Segurança: Zone-Based Policy Firewall, Cisco IOS versão 15.2M&T. Aqui está um extrato do capítulo de alta disponibilidade do firewall de política baseado em zona:

"Uma comutação para o dispositivo de espera pode ocorrer em outras circunstâncias. Outro fator que pode causar um switchover é uma configuração de prioridade que pode ser configurada em cada dispositivo. O dispositivo com o maior valor de prioridade é o dispositivo ativo. Se ocorrer uma falha no dispositivo ativo ou em standby, a prioridade do dispositivo será reduzida por uma quantidade configurável, conhecida como peso. Se a prioridade do dispositivo ativo cair abaixo da prioridade do dispositivo em standby, um switchover ocorrerá e o dispositivo em standby se tornará o dispositivo ativo. Esse comportamento padrão pode ser substituído desabilitando o atributo de preferência para o grupo de redundância. Você também pode configurar cada interface para diminuir a prioridade quando o estado da Camada 1 da interface for desativado. A prioridade configurada substitui a prioridade padrão de um grupo de redundância."

Essas saídas indicam o estado correto:

ZBFW01#show redundancy application group 1

Group ID:1

Group Name:ZBFW_HA

Administrative State: No Shutdown

Aggregate operational state : Up

My Role: ACTIVE

Peer Role: STANDBY

Peer Presence: Yes

Peer Comm: Yes

Peer Progression Started: Yes

RF Domain: btob-one

RF state: ACTIVE

Peer RF state: STANDBY HOT

ZBFW01#show redundancy application faults group 1

Faults states Group 1 info:

Runtime priority: [230]

RG Faults RG State: Up.

Total # of switchovers due to faults:           0

Total # of down/up state changes due to faults: 0

Esses registros são gerados no ZBFW sem nenhuma depuração ativada. Este registro mostra quando o dispositivo se torna ativo:

*Feb  1 21:47:00.579: %RG_PROTOCOL-5-ROLECHANGE: RG id 1 role change from

Init to Standby

*Feb  1 21:47:09.309: %RG_PROTOCOL-5-ROLECHANGE: RG id 1 role change from Standby

to Active

*Feb  1 21:47:19.451: %RG_VP-6-BULK_SYNC_DONE: RG group 1 BULK SYNC to standby

complete.

*Feb  1 21:47:19.456: %RG_VP-6-STANDBY_READY: RG group 1 Standby router is in

SSO state

Este registro mostra quando o dispositivo fica em espera:

*Feb  1 21:47:07.696: %RG_VP-6-BULK_SYNC_DONE: RG group 1 BULK SYNC to standby

complete.

*Feb  1 21:47:07.701: %RG_VP-6-STANDBY_READY: RG group 1 Standby router is in

SSO state

*Feb  1 21:47:09.310: %RG_PROTOCOL-5-ROLECHANGE: RG id 1 role change from Active

to Init

*Feb  1 21:47:19.313: %RG_PROTOCOL-5-ROLECHANGE: RG id 1 role change from

Init to Standby

Roteamento Assimétrico

O suporte ao roteamento assimétrico está descrito no guia Asymmetric Routing Support.

Para configurar o roteamento assimétrico, adicione os recursos à configuração global do grupo de aplicativos de redundância e à subconfiguração da interface. É importante observar que o roteamento assimétrico e um RG não podem ser habilitados na mesma interface, porque não são suportados. Isso se deve ao modo como o roteamento assimétrico funciona. Quando uma interface é designada para roteamento assimétrico, ela não pode fazer parte da replicação da conexão HA nesse ponto, porque o roteamento é inconsistente. Configurar um RG confunde o roteador, porque um RG especifica que uma interface faz parte da replicação da conexão HA.

Exemplo 11: Configuração de roteamento assimétrico

redundancy

application redundancy

group 1

asymmetric-routing interface Ethernet0/3

interface Ethernet0/1

redundancy asymmetric-routing enable

Essa configuração deve ser aplicada em ambos os roteadores no par HA.

A interface Ethernet0/3 listada anteriormente é um novo link dedicado entre os dois roteadores. Esse link é usado exclusivamente para transmitir tráfego roteado assimetricamente entre os dois roteadores. É por isso que ele deve ser um link dedicado equivalente à interface externa.

Informações Relacionadas

- Guia de configuração de segurança: Firewall de política baseado em zona, Cisco IOS versão 15.2M&T

- Guia de configuração de segurança de alta disponibilidade do firewall de política baseado em zona

- Cisco IOS 15.2M&T

- Cisco IOS Firewall

- Avisos de campo do produto de segurança

- Suporte Técnico e Documentação - Cisco Systems