Безопасность : Межсетевой экран Cisco IOS

Конфигурация высокой доступности ZBFW и технические примечания по поиску и устранению неисправностей

13 августа 2013 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (5 ноября 2013) | Отзыв


Содержание


Введение

Это руководство предоставляет базовую конфигурацию для Зональной Высокой доступности (HA) Межсетевого экрана для активной/резервной настройки, а также команды устранения неполадок, и общие проблемы, замеченные с функцией.

Зональный Межсетевой экран IOS (ZBFW) поддерживает HA так, чтобы два маршрутизатора Cisco IOS могли быть настроены в активной/резервной или активной/активной настройке. Это позволяет избыточности предотвращать единственное уязвимое звено.

Примечание. Внесенный Адамом Мэковецем, Рамой Дарбхой, и Джеем Джонстон, специалисты службы технической поддержки Cisco.

Предварительные условия

Требования

Должен быть позже, чем Cisco IOS® Software Release 15.2 (3) T.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Подробные сведения об условных обозначениях см. в документе "Условное обозначение технических терминов Cisco".

Конфигурация

Схема на рисунке 1 показывает топологию, используемую в примерах конфигурации.

Рис. 1. Топология

zbfw-ha-config-ts-01.gif

В конфигурации, показанной в Примере 1, ZBFW был уже настроен для осмотра TCP, UDP, и трафика Протокола ICMP изнутри к внешней стороне. Конфигурация, показанная полужирным, устанавливает HA функция. В маршрутизаторах Cisco IOS, HA настроен через команду подconfig избыточности. Чтобы настроить избыточность, первый шаг должен включить избыточность в глобальной карте параметра проверки.

После включения избыточности введите подconfig избыточности приложения и выберите интерфейсы, которые используются для контроля и данных. Контрольный интерфейс используется для обмена информацией о состоянии каждого маршрутизатора. Интерфейс данных используется для обмена информацией о соединениях, которые должны быть реплицированы.

Если и Маршрутизатор 1 и Маршрутизатор 2 в рабочем состоянии, в Примере 2, приоритетная команда также собирается сделать Маршрутизатор 1 активный модуль в паре. Команда preempt (также обсужденный далее в этом документе) используется, чтобы гарантировать, что сбой происходит, как только изменяется приоритет.

Заключительный шаг должен назначить группы RII на каждый интерфейс. Номер группы идентификатора избыточного интерфейса (RII) должен быть уникальным для интерфейса, но это должно совпасть через устройства для интерфейсов в той же подсети. В Примере 2, группа избыточности 1 команда используется для создания виртуального IP (VIP) адрес на внутреннем интерфейсе. Это гарантирует высокую доступность, потому что все внутренние пользователи только связываются с VIP, для которого активный модуль обрабатывает.

Внешний интерфейс не имеет этой конфигурации, потому что это - Интерфейс WAN. Внешний интерфейс и Маршрутизатора 1 и Маршрутизатора 2 не принадлежит тому же ISP. На внешнем интерфейсе требуется протокол динамической маршрутизации, чтобы гарантировать, что трафик проходит к корректному устройству.

Пример 1 Маршрутизатор 1 Фрагмент конфигурации (Имя хоста 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

Пример 2 Маршрутизатор 2 Фрагмента конфигурации (Имя хоста 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

Команды для устранения неполадок

Подтвердите, что устройства могут связаться друг с другом

Чтобы подтвердить, что устройства могут видеть друг друга, необходимо проверить, что произошло операционное состояние группы приложений избыточности. Затем гарантируйте, что каждое устройство взяло корректную роль и может видеть ее узел в их корректной роли. В Примере 3, ZBFW1 активен и обнаруживает свой узел как резерв. Это инвертировано на ZBFW2. Когда оба устройства также показывают, что операционное состояние произошло, и их одноранговое присутствие обнаружено, эти два маршрутизатора могут успешно связаться через канал управления.

Пример 3 Одноранговое обнаружение присутствия

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

Выходные данные в Примере 4 показа больше гранулированных выходных данных о контрольном интерфейсе этих двух маршрутизаторов. Выходные данные подтверждают физический интерфейс, используемый для контрольного трафика, и это также подтверждает IP-адрес узла.

Пример 4 Гранулированные выходные данные

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

Когда связь установлена, команда в Примере 5 помогает вам понимать, почему каждое устройство находится в своей специальной роли. ZBFW1 активен, потому что он имеет более высокий приоритет, чем свой узел. В то время как ZBFW2 имеет приоритет 150, ZBFW1 имеет приоритет 200. Эти выходные данные выделены полужирным.

Пример 5 Статус роли и приоритет

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

Последнее подтверждение должно гарантировать, что идентификатор группы RII назначен на каждый интерфейс. Если вы вводите эту команду в оба маршрутизатора, они проверяют дважды, чтобы гарантировать, что парам интерфейса в той же подсети между устройствами назначают тот же ID RII. Если они не настроены с тем же уникальным ID RII, соединения не реплицируют между этими двумя устройствами. См. Пример 6.

Пример 6: Подтвердите, что Назначен Идентификатор группы 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

Проверьте, что соединения реплицируют в равный маршрутизатор

В Примере 7, ZBFW1 активно передает трафик для соединения. Соединение успешно реплицировано в резервное устройство ZBFW2. Для просмотра соединений, обработанных зональным межсетевым экраном, используйте сеанс межсетевого экрана политики показа команды.

Пример 7: Обработанные Соединения

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

Заметьте, что соединение реплицирует, но переданные байты не быть обновленными. Состояние соединения (информация TCP) регулярно обновляется через интерфейс данных, чтобы гарантировать, что на трафик не влияют, если происходит событие переключения при отказе.

Для большего количества гранулированных выходных данных ха может быть введен зонально-парный <ZP> сеанса межсетевого экрана политики показа команды. Это предоставляет подобные выходные данные как Пример 7, но это позволяет пользователю ограничивать выходные данные только заданным зонально-парным.

Соберите выходные данные отладки

Этот раздел показывает команды отладки, которые производят соответствующие выходные данные для того, чтобы устранить неполадки этой функции.

Включение отладок может быть очень напряжено на маршрутизаторе в состоянии занято. Поэтому, поймите влияние перед включением их.

группа приложений debug redundancy rii событие

Эта команда используется, чтобы удостовериться, что соединения совпадают с корректной группой RII, чтобы быть реплицированными должным образом. Когда трафик поступает в ZBFW, источник и интерфейсы назначения проверены для идентификатора группы RII. Эта информация тогда передана через канал передачи данных к узлу. Когда группа RII резервного узла выравнивается с активными модулями, тогда syslog в Примере 8 генерируется и подтверждает идентификаторы группы RII, которые используются для репликации соединения:

Пример 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 все

Эта команда используется, чтобы подтвердить, что эти два узла могут видеть друг друга. IP - адрес адресуемой точки подтвержден в отладках. Как замечено в Примере 9, ZBFW1 видит свой узел в резервном состоянии с IP-адресом 10.60.1.2. Обратное истинно для ZBFW2.

Пример 9: Подтвердите одноранговый IPs в Отладках

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

Распространенные проблемы

Контроль и выбор интерфейса данных

Вот некоторые советы для контроля и VLAN для передачи данных:

  • Не включайте контроль и интерфейсы данных в конфигурации ZBFW. Они только используются для передачи друг с другом; поэтому, потребность защитить эти интерфейсы не необходима.

  • Контроль и интерфейсы данных могут быть на том же интерфейсе или VLAN. Это сохраняет порты на маршрутизаторе.

Absent RII Group

Группа RII должна быть применена и на LAN и на Интерфейсы WAN. Интерфейсы LAN (локальной сети) должны быть в той же подсети, но Интерфейсы WAN могут быть на отдельных подсетях. Если существует группа RII, отсутствующая на интерфейсе, этот syslog происходит в выходных данных группы приложений debug redundancy rii событие и группа приложений debug redundancy rii ошибка:

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

Автоматическое переключение при отказе

Чтобы настроить автоматическое переключение при отказе, ZBFW HA должен быть настроен, чтобы отследить объект Service Level Agreement (SLA) и динамически уменьшить основанное на приоритете на этом событии SLA. В Примере 10, ZBFW HA отслеживает статус соединения интерфейса GigabitEthernet0. Если этот интерфейс выключается, мы сокращаем приоритет так, чтобы одноранговое устройство было более привилегированным.

Пример 10: 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

Иногда ZBFW HA не делает автоматически отказоустойчивости даже при том, что у нас есть уменьшенное приоритетное событие. Это вызвано тем, что вытеснять ключевое слово не настроено под обоими устройствами. Вытеснять ключевое слово имеет другую функциональность, чем в (Протокол маршрутизатора Горячего резервирования) Отказоустойчивость Устройства адаптивной защиты (ASA) или HSRP. Если приоритет устройства изменяется, в ZBFW HA, вытеснять ключевое слово позволяет событию переключения при отказе происходить. Это задокументировано в Руководство по конфигурации системы безопасности: Zone-Based Policy межсетевой экран, Cisco IOS Release 15.2M&T. Вот выдержка из главы Высокой доступности Zone-Based Policy межсетевого экрана:

"Переключатель к резервному устройству может произойти при других обстоятельствах. Другой фактор, который может вызвать переключатель, является настройкой приоритета, которая может быть настроена на каждом устройстве. Устройство с наивысшим приоритетом оценивает быть активным устройством. Если отказ происходит или на активном или на резервном устройстве, приоритет устройства постепенно уменьшен конфигурируемой суммой, известной как вес. Если приоритет активного устройства падает ниже приоритета резервного устройства, переключатель происходит, и резервное устройство становится активным устройством. Это поведение по умолчанию может быть отвергнуто путем отключения атрибута приоритетного прерывания обслуживания для группы избыточности. Когда состояние Уровня 1 интерфейса выключается, можно также настроить каждый интерфейс для уменьшения приоритета. Приоритет, который настроен, отвергает приоритет по умолчанию группы избыточности."

Эти выходные данные указывают на надлежащее состояние:

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

Эти журналы генерируются на ZBFW без любых включенных отладок. Когда устройство идет активное, этот журнал показывает:

*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

Когда устройство идет на резерв, этот журнал показывает:

*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

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 115956