Configurazione e risoluzione dei problemi di elevata disponibilità ZBFW

Introduzione

Questa guida fornisce la configurazione di base per Zone Firewall High Availability (HA) per un'installazione attiva/standby, nonché i comandi per la risoluzione dei problemi e i problemi comuni rilevati con la funzione.

Cisco IOS^® Zone-Based Firewall (ZBFW) supporta HA in modo che due router Cisco IOS possano essere configurati in modalità attivo/standby o attivo/attivo. Ciò consente la ridondanza per evitare un singolo punto di errore.

Prerequisiti

Requisiti

È necessario disporre di una versione successiva al software Cisco IOS versione 15.2(3)T.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Configurazione

Il diagramma mostra la topologia utilizzata negli esempi di configurazione.

Nella configurazione mostrata nell'Esempio 1, lo ZBFW è configurato per ispezionare il traffico TCP, UDP e ICMP (Internet Control Message Protocol) dall'interno all'esterno. La configurazione mostrata in grassetto imposta la funzione HA. Nei router Cisco IOS, il protocollo HA è configurato tramite il comando redundancy subconfig. Per configurare la ridondanza, il primo passaggio consiste nell'abilitare la ridondanza nella mappa dei parametri di ispezione globale.

Dopo aver abilitato la ridondanza, immettere la subconfig di ridondanza applicazione e selezionare le interfacce utilizzate per il controllo e i dati. L'interfaccia di controllo viene usata per scambiare informazioni sullo stato di ciascun router. L'interfaccia dati viene utilizzata per scambiare informazioni sulle connessioni da replicare.

Nell'esempio 2, il comando priority è impostato anche per rendere il router 1 l'unità attiva nella coppia se sia il router 1 che il router 2 sono operativi. il comando preempt (descritto più avanti in questo documento) viene usato per verificare che l'errore si verifichi quando la priorità cambia.

Il passaggio finale consiste nell'assegnare l'identificatore di interfaccia ridondante (RII) e il gruppo di ridondanza (RG) a ciascuna interfaccia. Il numero di gruppo RII deve essere univoco per ciascuna interfaccia, ma deve corrispondere tra i dispositivi per le interfacce nella stessa subnet. L'interfaccia RII viene utilizzata solo per il processo di sincronizzazione globale quando i due router sincronizzano la configurazione. In questo modo i due router sincronizzano le interfacce ridondanti. L'RG viene usato per indicare che le connessioni attraverso quell'interfaccia vengono replicate nella tabella delle connessioni HA.

Nell'esempio 2, il comando redundancy group 1 viene usato per creare un indirizzo IP virtuale (VIP) sull'interfaccia interna. Ciò assicura un'elevata disponibilità in quanto tutti gli utenti interni comunicano solo con l'indirizzo VIP, per il quale l'unità attiva elabora.

L'interfaccia esterna non ha alcuna configurazione RG perché è l'interfaccia WAN. L'interfaccia esterna del router 1 e del router 2 non appartengono allo stesso provider di servizi Internet (ISP). Sull'interfaccia esterna, è necessario un protocollo di routing dinamico per garantire che il traffico passi al dispositivo corretto.

Esempio 1: Frammento di configurazione router 1 (nome 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

Esempio 2: Frammento di configurazione del router 2 (Hostname 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

Risoluzione dei problemi

Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.

Conferma che i dispositivi possono comunicare tra loro

Per verificare che i dispositivi possano vedersi, è necessario verificare che lo stato operativo del gruppo di applicazioni di ridondanza sia attivo. Verificare quindi che ogni dispositivo abbia assunto il ruolo corretto e che possa vedere il relativo peer nei ruoli corretti. Nell'esempio 3, ZBFW1 è attivo e rileva il peer in standby. Questo è invertito su ZBFW2. Quando entrambi i dispositivi mostrano anche che lo stato operativo è attivo e viene rilevata la loro presenza peer, i due router possono comunicare correttamente attraverso il collegamento di controllo.

Esempio 3: Rilevamento presenza peer

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

L'output dell'esempio 4 mostra un output più granulare sull'interfaccia di controllo dei due router. L'output conferma l'interfaccia fisica utilizzata per il controllo del traffico e anche l'indirizzo IP del peer.

Esempio 4: Uscita granulare

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

Una volta stabilita la comunicazione, il comando riportato nell'Esempio 5 consente di comprendere perché ogni dispositivo svolge il proprio ruolo. ZBFW1 è attivo perché ha una priorità più alta rispetto al peer. ZBFW1 ha una priorità di 200, mentre ZBFW2 ha una priorità di 150. Questo output è evidenziato in grassetto.

Esempio 5: Stato e priorità del ruolo

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

L'ultima conferma consiste nell'assegnare l'ID gruppo RII a ciascuna interfaccia. Se si immette questo comando su entrambi i router, i router eseguono un doppio controllo per verificare che alle coppie di interfacce sulla stessa subnet tra i dispositivi venga assegnato lo stesso ID RII. Se non sono configurate con lo stesso ID RII univoco, le connessioni non vengono replicate tra i due dispositivi. Vedere l'Esempio 6.

Esempio 6: Conferma assegnazione ID gruppo RII

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

Verificare che le connessioni vengano replicate sul router peer

Nell'esempio 7, ZBFW1 trasmette attivamente il traffico per una connessione. Replica della connessione nel dispositivo di standby ZBFW2 completata. Per visualizzare le connessioni elaborate dal firewall della zona, usare il comando show policy-firewall session.

Esempio 7: Connessioni elaborate

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

La connessione viene replicata, ma i byte trasferiti non vengono aggiornati. Lo stato della connessione (informazioni TCP) viene aggiornato regolarmente tramite l'interfaccia dati per garantire che il traffico non venga influenzato dal verificarsi di un evento di failover.

Per un output più granulare, immettere il comando show policy-firewall session zone-pair <ZP> ha. Fornisce un output simile all'esempio 7, ma consente all'utente di limitare l'output solo alla coppia di zone specificata.

Raccogli output di debug

In questa sezione vengono illustrati i comandi di debug che producono l'output rilevante per la risoluzione dei problemi di questa funzione.

L'abilitazione dei debug può essere molto complessa su un router occupato. Pertanto, è necessario comprendere l'impatto prima di abilitarli.

• debug redundancy application group rii event
  
  Questo comando è usato per assicurarsi che le connessioni corrispondano al gruppo RII corretto per essere replicate correttamente. Quando arriva il traffico sulla ZBFW, le interfacce di origine e di destinazione vengono controllate per trovare un ID gruppo RII. Queste informazioni vengono quindi comunicate al peer attraverso il collegamento dati. Quando il gruppo RII del peer in standby si allinea alle unità attive, viene generato il syslog nell'esempio 8 e viene confermata la presenza degli ID del gruppo RII utilizzati per replicare la connessione:
  
  
  

  Esempio 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
  
  Questo comando è usato per verificare che i due peer possano vedersi. L'indirizzo IP del peer viene confermato nei debug. Come mostrato nell'esempio 9, ZBFW1 vede il suo peer nello stato di standby con l'indirizzo IP 10.60.1.2. Il contrario è vero per ZBFW2.
  
  
  

  Esempio 9: Conferma IP peer nei debug

  
  
  

  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

Problemi comuni

In questa sezione vengono descritti in dettaglio alcuni problemi comuni riscontrati.

Selezione interfaccia dati e controllo

Di seguito sono riportati alcuni suggerimenti per le VLAN di controllo e di dati:

• Non includere le interfacce dati e di controllo nella configurazione ZBFW. sono utilizzate solo per comunicare tra loro; non è necessario quindi proteggere queste interfacce.
• Le interfacce di controllo e dati possono trovarsi sulla stessa interfaccia o VLAN. In questo modo, vengono preservate le porte del router.

Gruppo RII assente

Il gruppo RII deve essere applicato su entrambe le interfacce LAN e WAN. Le interfacce LAN devono trovarsi nella stessa subnet, ma le interfacce WAN possono trovarsi su subnet separate. Se un gruppo RII è assente su un'interfaccia, questo syslog si verifica nell'output dell'evento rii del gruppo di applicazioni di ridondanza di debug e dell'errore rii del gruppo di applicazioni di ridondanza di debug:

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

Failover automatico

Per configurare il failover automatico, ZBFW HA deve essere configurato in modo da tenere traccia di un oggetto SLA (Service Level Agreement) e ridurre dinamicamente la priorità in base a questo evento SLA. Nell'esempio 10, ZBFW HA tiene traccia dello stato del collegamento dell'interfaccia Gigabit Ethernet0. Se l'interfaccia non è disponibile, la priorità viene ridotta in modo da privilegiare il dispositivo peer.

Esempio 10: Configurazione failover automatico 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

A volte ZBFW HA non esegue il failover automatico anche se si verifica un evento con priorità ridotta. Infatti, la parola chiave preempt non è configurata su entrambi i dispositivi. La parola chiave preempt ha funzionalità diverse rispetto al failover HSRP (Hot Standby Router Protocol) o ASA (Adaptive Security Appliance). In ZBFW HA, la parola chiave preempt consente il verificarsi di un evento di failover se la priorità del dispositivo cambia. Questa condizione viene documentata nella Guida alla configurazione della sicurezza: Zone-Based Policy Firewall, Cisco IOS release 15.2M&T. Di seguito viene riportato un estratto del capitolo relativo all'alta disponibilità di Policy Firewall basata su zone:

"Il passaggio al dispositivo di standby può avvenire in altre circostanze. Un altro fattore che può causare lo switchover è l'impostazione della priorità che può essere configurata su ciascun dispositivo. Il dispositivo con il livello di priorità più alto deve essere il dispositivo attivo. Se si verifica un errore sul dispositivo attivo o in standby, la priorità del dispositivo viene ridotta di una quantità configurabile, nota come peso. Se la priorità del dispositivo attivo è inferiore a quella del dispositivo di standby, si verifica un passaggio e il dispositivo di standby diventa il dispositivo attivo. È possibile ignorare questo comportamento predefinito disabilitando l'attributo relativo all'interruzione per diritti di priorità per il gruppo di ridondanza. È inoltre possibile configurare ciascuna interfaccia in modo che diminuisca la priorità quando lo stato del layer 1 dell'interfaccia diventa inattivo. La priorità configurata ha la precedenza sulla priorità predefinita di un gruppo di ridondanza."

Questi output indicano lo stato corretto:

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

Questi log vengono generati sullo ZBFW senza alcun debug abilitato. In questo registro viene mostrato quando il dispositivo diventa attivo:

*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

Questo registro mostra quando il dispositivo entra in standby:

*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

Routing asimmetrico

Il supporto per il routing asimmetrico è descritto nella guida al supporto del routing asimmetrico.

Per configurare il routing asimmetrico, aggiungere le funzionalità alla configurazione globale del gruppo di applicazioni di ridondanza e alla sottoconfigurazione dell'interfaccia. È importante notare che il routing asimmetrico e un RG non possono essere abilitati sulla stessa interfaccia perché non sono supportati. Ciò è dovuto al funzionamento del routing asimmetrico. Quando un'interfaccia viene designata per il routing asimmetrico, non può far parte della replica della connessione HA in quel punto, perché il routing è incoerente. La configurazione di un RG confonde il router, in quanto un RG specifica che un'interfaccia fa parte della replica della connessione HA.

Esempio 11: Configurazione routing asimmetrico

redundancy
 application redundancy
  group 1
    asymmetric-routing interface Ethernet0/3

interface Ethernet0/1
  redundancy asymmetric-routing enable

Questa configurazione deve essere applicata a entrambi i router della coppia HA.

L'interfaccia Ethernet0/3 descritta in precedenza è un nuovo collegamento dedicato tra i due router. Questo collegamento viene usato esclusivamente per passare il traffico con routing asimmetrico tra i due router. Ecco perché dovrebbe essere un collegamento dedicato equivalente all'interfaccia rivolta verso l'esterno.

Informazioni correlate

• Guida alla configurazione della protezione: Zone-Based Policy Firewall, Cisco IOS release 15.2M&T
• Guida alla configurazione della protezione ad alta disponibilità del firewall dei criteri basato su zone
• Cisco IOS 15.2 M e T
• Cisco IOS Firewall
• Avvisi sui prodotti per la sicurezza
• Documentazione e supporto tecnico – Cisco Systems