отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Потенциальная проблема OSPF NSF и Multi-chassis HA

Введение

Данный документ описывает потенциальные проблемы OSPF NSF, в случаях, когда эта технология применяется совместно с multi-chassis HA (например, стек коммутаторов или VSS).

"Проблема" может приводить к неожиданно высокому времени сходимости сети (до 120 секунд, при ожидаемом времени около 1 секунды), в случаях, когда активный интерфейс (используемый для отправки трафика) находится на активном SUP или коммутаторе.

Общая информация

Нередко в сетевых дизайнам можно встретить решения, использующие несколько High Availability элементов (фич), для достижения как можно более короткого времени сходимости сети. Но некоторые из этих элементов могут не очень хорошо работать совместно. Как результат, иногда можно видеть, что время сходимости «неожиданно» высоко. И такое поведение называется проблемой дизайна.

OSPF NSF и Multi-chassi HA – это два подобных элемента, которые мы рассмотрим в данном документе.

Проблема может возникнуть в дизайне, где роутер использует несколько L3 интерфейсов, размещенных на разных устройствах, объединенных в multi-chassis HA, а в протоколе OSPF включен NSF.

OSPF NSF feature

NSF и “graceful-restart” являются синонимами и могут быть использованы в данном документе как взаимозаменяемые.

Основной идеей NSF (Nonstop Forwarding) является минимизация времени, в течение которого сеть не способна доставлять трафик в место назначение после события переключения SUP. Основной целью NSF является продолжать пересылку IP-пакетов, после того, как на устройстве произошло переключение SUP. NSF поддерживается в протоколе OSPF.

Cisco IOS поддерживает два типа OSPF NSF: проприетарный режим Cisco и режим IETF (rfc 3623).

С технической точки зрения, логика работы NSF такова:

  • В случае события переключения SUP (или RP switchover), новый RP перехватывает управление устройством и запускает новый процесс маршрутизации (в нашем случае OSPF);
  • Новый процесс OSPF пытается восстановить соседство (adjacency) со всеми предыдущими соседями;
  • Если NSF настроен для прокола, CEF (FIB) фиксируется (для того, чтобы устройство продолжало пересылку трафика, не смотря на то, что RIB (таблица маршрутизации) пуста;
  • Во время восстановления соседства, ни одно из устройств не извещает остальную сеть о событии, таким образом маршрут передачи трафика по сети является неизменным;
  • Только когда прокол маршрутизации завершает передачу всей необходимой информации, данные попадают в RIB и (оттуда) могут обновить CEF.

Этот процесс таит в себе подводные камни в случаях использования multi-chassis (например, стек коммутаторов или VSS).

Multi-chassis

Multi-chassis решения позволяют нескольким отдельным физическим устройствам использовать единый control-plane и management-plane (выглядят для остальной сети как одно логическое устройство), в результате чего data-plane также управляется из одного источника.

Плюсы решения:

  • Единое логическое устройство с точки зрения management-plane - настройки и мониторинга (до девяти коммутаторов в стеке или 2 устройства в VSS);
  • interface bundle, в котором участвуют интерфейсы с разных физических устройств (например, чтобы обеспечить резервный интерфейс для конечного хоста\сервера на access-layer);
  • единое логическое устройство в точки зрения control-plane (упрощает работу STP, упрощает топологию протоколов маршрутизации);
  • дополнительная емкость каналов данных между устройствами (для стека коммутаторов – используется выделенный высокоскоростной stack-port);
  • наличие резервного SUP/RP.

Сетевая топология

Во всех тестах мы будем использовать стек коммутаторов 3750G (два, версия IOS 12.2(55)SE8). Другие роутеры – ISR G2.

Рис. 1. Сетевая топология

Сетевая топология

На R1 настроены loopback 1.1.1.1/32 и 11.11.11.11/32

На R2 настроены loopback 2.2.2.2/32 и 22.22.22.22/32

На SW4 настроен loopback 4.4.4.4/32; интерфейсы настроены как L3 (использование SVI может приводить к дополнительным задержкам, которые не интересны в рамках данного документа).

IP-адреса интерфейсов:

  • R1 G0/0 (192.168.114.1) – SW4 G1/0/1 (192.168.114.4);
  • R1 G0/1 (192.168.214.1) – SW4 G3/0/1 (192.168.214.4);
  • R2 G0/0 (192.168.124.2) – SW4 G1/0/2 (192.168.124.4);
  • R2 G0/1 (192.168.224.2) – SW4 G3/0/2 (192.168.224.4).

OSPF работает на всех интерфейсах.

Сценарии тестирования

Во всех тестах мы будем симулировать сбой работы коммутатора и оценивать время, необходимое сети для сходимости (на уровне data-plane).

Во всех тестах коммутатор 1(сверху) является активным (мастером) и RIB указывает на интерфейсы G1/0/1 и G1/0/2 (OSPF cost), в то время как R1 и R2 используют G0/1 интерфейсы, чтобы пересылать трафик друг другу. Как результат, путь трафика будет следующим:

Рис.2. Исходный путь прохождения трафика

Исходный путь прохождения трафика

Переключение стека на коммутатор 3 выполняется командой “reload slot 1”. Время недоступности сервиса измеряется на основе потерь пакетов отправляемыми между адресами 1.1.1.1 и 2.2.2.2 (интервал отправки пакетов равен 1 секунде).

 

Рис.3. Ожидаемый путь прохождения трафика после выключения коммутатора 1

Ожидаемый путь прохождения трафика после выключения коммутатора 1

Во избежание дополнительных задержек на R1 и R2, на них выполняются следующие настройки:

  • static route на R1: 2.2.2.2/32 через 168.214.4;
  • static route на R2: 1.1.1.1/32 через168.224.4;
  • carrier-delay = 1ms на всех интерфейсах.

Во избежание дополнительных задержек со стороны OSPF, таймеры настроены следующим образом на всех устройствах:

  • timers throttle spf 5 10 50
  • timers throttle lsa all 1 10 100
  • timers lsa arrival 8
  • hello-timer = 1 second;
  • dead-timer = 40 seconds (должно быть достаточно высоким, чтобы NSF процесс успел запустить;
  • все интерфейсы настроена как network type point-to-point.

Во время тестов мы включаем следующие команды debug для сбора дополнительной информации:

  • debug ip ospf nsf det
  • debug ip routing
  • debug ip ospf adj

Результаты тестов:

Для всех тестов ниже приводим временную шкалу (таблицу), по котором мы может понять в какой процесс явился причиной потери пактов. События между устройствами можно коррелировать, т.к. время синхронизировано по NTP (разница составляет не более 50 мс). 

Тест 1. NSF не включен

В данном тесте общий время потери трафика составило около 15 секунд. Основной задержкой (около 10 секунд ) стал запуск control-plane на коммутаторе 3.

Вмененная шкала:

Timestamp

On device

Event details

11:34:26.217

11:34:25.737

R1

R2

%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

11:34:25.749

SW4

Master role failover:

TACKMGR-4-SWITCH_REMOVED: Switch 1 has been REMOVED from the stack

11:34:26.227

 

R1

RIB converges (stops using G0/0):

RT: del 22.22.22.22 via 192.168.114.4, ospf metric [110/3]

11:34:25.753

R2

RT: del 11.11.11.11 via 192.168.124.4, ospf metric [110/3]

11:34:35.302

SW4

OSPF process started listening 224.0.0.5:

OSPF: OSPF: Rcv pkt from GigabitEthernet3/0/2 src 192.168.224.2 dst 192.168.224.4 id 2.2.2.2 type 4 if_state 0 : ignored due to unknown neighbor

11:34:39.543

11:34:39.727

R1

R2

OSPF neighbor issue detected:

OSPF-1 ADJ   Gi0/1: Cannot see ourself in hello from 4.4.4.4, state INIT

11:34:39.553

R1

Routing over 4.4.4.4 is broken completely:

RT: del 22.22.22.22 via 192.168.214.4, ospf metric [110/3]

11:34:39.743

R2

RT: del 11.11.11.11 via 192.168.224.4, ospf metric [110/3]

11:34:39.553

11:34:39.739

R1

R2

OSPF converges:

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/1 from LOADING to FULL

 

11:34:39.623

R1

Connectivity restores:

RT: add 22.22.22.22/32 via 192.168.214.4, ospf metric [110/102]

11:34:39.604

SW4

RT: add 1.1.1.1/32 via 192.168.214.1, ospf metric [110/101]

RT: add 2.2.2.2/32 via 192.168.224.2, ospf metric [110/101]

11:34:39.779

R2

RT: add 11.11.11.11/32 via 192.168.224.4, ospf metric [110/102]

 

Тест 2. Настроен NSF IETF.

В данном тесте общее время потери трафика составило около 125 секунд (более двух минут). Основной задержкой стал NSF - pooling interfaces (около 101 секунд):

Timestamp

On device

Event details

12:25:52.217

12:25:52.870

R1

R2

%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

12:25:52.573

SW4

Master role failover:

TACKMGR-4-SWITCH_REMOVED: Switch 1 has been REMOVED from the stack

12:25:52.227

R1

RIB converges (stops using G0/0):

RT: del 22.22.22.22 via 192.168.114.4, ospf metric [110/3]

12:25:52.886

R2

RT: del 11.11.11.11 via 192.168.124.4, ospf metric [110/3]

12:26:01.782

SW4

OSPF process started listening 224.0.0.5:

OSPF: OSPF: Rcv pkt from GigabitEthernet3/0/1 src 192.168.214.1 dst 192.168.214.4 id 11.11.11.11 type 4 if_state 0 : ignored due to unknown neighbor

12:26:03.996

SW4

NSF starts:

12:26:03.996: OSPF: IETF NSF complete check for area 0 process 1

12:26:06.479: OSPF: IETF NSF Build Grace LSA for interface GigabitEthernet3/0/1

12:26:06.459

R1

Starting NSF helper mode:

OSPF-1 NSF_I Gi0/1: Process grace LSA from nbr 4.4.4.4, age 1, grace period 120, graceful restart reason - Switch to redundant control processor

OSPF-1 NSF_I Gi0/1: Enter graceful restart helper mode for 4.4.4.4 for 119 seconds (requested 120 sec)

12:26:10.487

SW4

NSF convergence:

%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet3/0/1 from DOWN to INIT, Received Hello

12:26:10.504

SW4

Initial convergence with R1 done:

%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet3/0/1 from LOADING to FULL

12:26:15.267

SW4

Initial convergence with R2 done:

%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet3/0/2 from LOADING to FULL

12:26:16.474

SW4

NSF is in progress (timer):

OSPF: will poll [count 10] interface status for GigabitEthernet3/0/1

OSPF: will poll [count 10] interface status for GigabitEthernet3/0/2

12:27:57.046

SW4

NSF is about to be over:

OSPF: will poll [count 0] interface status for GigabitEthernet3/0/2

OSPF: will poll [count 0] interface status for GigabitEthernet3/0/1

12:27:57.063

SW4

NSF is over:

OSPF: Graceful Restart timer expired for process 1, terminating IETF NSF

OSPF: Force running SPF

12:27:57.063

SW4

Routing recovered:

RT: add 1.1.1.1/32 via 192.168.214.1, ospf metric [110/101]

RT: add 2.2.2.2/32 via 192.168.224.2, ospf metric [110/101]

 

Такое длительное переключение вызвано фиксацией CEF на время работы процесса NSF. В нашем случае CEF указывает на интерфейсы G1/0/1 и G1/0/2, которые недоступны (т.к. коммутатор 1 выключен\перезагружается) во время переключения.

Как результат, трафик не может быть правильно маршрутизирован и теряется.

LFA (loop-free alternative) опция могла бы помочь в данном случае (не рассматривается в данном документе). 

Тест 3. Включен NSF IETF  + strict-lsa-checking.

В данном тесте мы включаем опциональную настройку Strict-LSA-checking для NSF процесса.  Она позволяет R1/R2 обнаружить изменения в сетевой топологии (например, что один из интерфейсов соседа недоступен) и прервать NSF процесс .

В данном тесте общее время потери трафика составило около 20 секунд. Основная задержка – перезапуск control-plane на коммутаторе 3:

Timestamp

On device

Event details

10:01:32.671 10:01:33.495

R1

R2

%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

10:01:33.017

SW4

Master role failover:

TACKMGR-4-SWITCH_REMOVED: Switch 1 has been REMOVED from the stack

10:01:32.681

R1

RIB converges (stops using G0/0):

RT: del 22.22.22.22 via 192.168.114.4, ospf metric [110/3]

10:01:33.511

R2

RT: del 11.11.11.11 via 192.168.124.4, ospf metric [110/3]

10:01:42.235

SW4

OSPF process started listening 224.0.0.5:

OSPF: OSPF: Rcv pkt from GigabitEthernet3/0/1 src 192.168.214.1 dst 192.168.214.4 id 11.11.11.11 type 4 if_state 0 : ignored due to unknown neighbor

10:01:44.398

SW4

NSF starts:

10:01:44.398: OSPF: IETF NSF complete check for area 0 process 1

10:01:46.948: OSPF: IETF NSF Build Grace LSA for interface GigabitEthernet3/0/1

10:01:46.941

R1

Starting and terminating NSF mode:

OSPF-1 NSF_I Gi0/1: Process grace LSA from nbr 4.4.4.4, age 1, grace period 120, graceful restart reason - Switch to redundant control processor

OSPF-1 NSF_I Gi0/1: Not entering graceful restart helper mode for 4.4.4.4, resetting neighbor, Changed LSA queued for flooding

10:01:46.941

R1

Terminating peering due to no NSF:

OSPF-1 ADJ   Gi0/1: 4.4.4.4 address 192.168.214.4 is dead, state DOWN

10:01:47.134

R2

OSPF-1 ADJ   Gi0/1: 4.4.4.4 address 192.168.224.4 is dead, state DOWN

 

10:01:46.951

10:01:47.150

 

R1

R2

Traffic outage starts:

RT: del 22.22.22.22 via 192.168.214.4, ospf metric [110/3]

RT: del 11.11.11.11 via 192.168.224.4, ospf metric [110/3]

10:01:50.957

R1

OSPF converge:

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/1 from LOADING to FULL

10:01:51.146

R2

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/1 from LOADING to FULL

10:01:50.998

SW4

Routing recovering:

RT: add 1.1.1.1/32 via 192.168.214.1, ospf metric [110/101]

RT: add 2.2.2.2/32 via 192.168.224.2, ospf metric [110/101]

10:01:50.997

R1

RT: add 22.22.22.22/32 via 192.168.214.4, ospf metric [110/3]

10:01:51.194

R2

RT: add 11.11.11.11/32 via 192.168.224.4, ospf metric [110/102]

 

Тест 4. Настроен режим NSF Cisco .

В данном тесте общее время потери трафика составило около 36 секунд. Основная задержка - NSF process (более 20 секунд):

Timestamp

On device

Event details

10:27:10.671

10:27:11.000

R1

R2

%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

10:27:10.648

SW4

Master role failover:

TACKMGR-4-SWITCH_REMOVED: Switch 1 has been REMOVED from the stack

10:27:10.681

R1

RIB converges (stops using G0/0):

RT: del 22.22.22.22 via 192.168.114.4, ospf metric [110/3]

10:27:11.016

R2

RT: del 11.11.11.11 via 192.168.124.4, ospf metric [110/3]

10:27:20.268

SW4

OSPF process started listening 224.0.0.5:

OSPF: OSPF: Rcv pkt from GigabitEthernet3/0/1 src 192.168.214.1 dst 192.168.214.4 id 11.11.11.11 type 4 if_state 0 : ignored due to unknown neighbor

10:27:22.046

SW4

NSF starts:

10:27:22.046: OSPF: IETF NSF complete check for area 0 process 1

10:27:24.403: Extended options bit out 0x3, GigabitEthernet3/0/1 (lls_len 12 bytes)

OSPF: will poll [cnt 11] interface status for GigabitEthernet3/0/1

OSPF: will poll [cnt 11] interface status for GigabitEthernet3/0/2

10:27:44.873

SW4

Initial LSDB exchange on NSF (OOB):

OSPF: Starting OOB-Resync with 22.22.22.22 address 192.168.224.2 on GigabitEthernet3/0/2 (requester)

10:27:44.890: OSPF: OOB-Resync completed with 22.22.22.22 address 192.168.224.2 on GigabitEthernet3/0/2

10:27:44.932: OSPF: OOB-Resync completed with 11.11.11.11 address 192.168.214.1 on GigabitEthernet3/0/1

10:27:44.932

SW4

OOB resync is over:

OSPF process 1: oob-resync completed for all neighbors

OSPF: Force running SPF

10:27:44.932

SW4

Routing recovers:

RT: add 1.1.1.1/32 via 192.168.214.1, ospf metric [110/101]

RT: add 2.2.2.2/32 via 192.168.224.2, ospf metric [110/101]

10:29:14.446

SW4

End of NSF process:

OSPF: will poll [count 0] interface status for GigabitEthernet3/0/1

OSPF: will poll [count 0] interface status for GigabitEthernet3/0/2

 

Тест 5. Настроен NSF Cisco (измененная топология)

Рис. 4. В данном тесте трафик передается по следующему пути

Коммутатор 1 активен и мы выполняем его перезагрузку reload slot 1.

В данном тесте общее время потери трафика составило около 4 секунд.

Timestamp

On device

Event details

10:54:12.671

10:54:12.569

R1

R2

%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

10:54:12.599

SW4

Master role failover:

TACKMGR-4-SWITCH_REMOVED: Switch 1 has been REMOVED from the stack

10:54:12.681

R1

RIB converges (stops using G0/0):

RT: del 22.22.22.22 via 192.168.114.4, ospf metric [110/3]

10:54:12.585

R2

RT: del 11.11.11.11 via 192.168.124.4, ospf metric [110/3]

10:54:16.584

SW4

Stack master switchover complete:

%STACKMGR-5-MASTER_READY: Master Switch 3 is READY

10:54:17.003

SW4

MKA-LLI: Failover Event

Потери трафика вызваны переключением стек мастера с одного устройства на второе и обусловлены архитектурой 3750G (потери могут быть меньше или отсутствовать в случае использования SSO).

Тест 6. Быстрая сходимость (BFD/dead-timers) без NSF

Рис. 5. Добавляем резервный путь

Добавляем резервный путь

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

В данном тесте общее время потери трафика составило около 1040 мс, т.к. для скорейшего обнаружения проблемы мы устанавливаем (только в этом тесте) dead-timer равный 1 секунде:

Timestamp

On device

Event details

11:30:11.952

R2

%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down

11:30:12.220

SW4

Master role failover:

TACKMGR-4-SWITCH_REMOVED: Switch 1 has been REMOVED from the stack

11:30:11.702

R1

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired

11:30:11.712

R1

RT: add 2.2.2.2/32 via 192.168.114.4, ospf metric [110/4]

11:30:11.722

R1

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

11:30:11.722

R1

RT: add 2.2.2.2/32 via 192.168.12.2, ospf metric [110/10001]

11:30:11.864

R2

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired

11:30:11.872

R2

RT: add 1.1.1.1/32 via 192.168.124.4, ospf metric [110/4]

11:30:11.952

R2

%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

11:30:11.904

R2

RT: add 1.1.1.1/32 via 192.168.12.1, ospf metric [110/10001]

 

Заключение

Cводная таблица результатов тестов:

Тест #

Содержание

Время сходимости

Основная задержка вызвана

Тест1

NSF отключен

15 сек.

Перезапуск control-plane

Тест2

NSF IETF

125 сек.

NSF таймер

Тест3

NSF IETF strict-LSA-check

20 сек.

Перезапуск control-plane

Тест4

NSF Cisco

36 сек.

NSF таймер

Тест5

NSF Cisco, без переключения интерфейсов

4 сек.

Процесс переключения стек роли

Тест6

Без NSF, dead-timer

1040 мс

Детектирование проблемы

 

Как видно из проведенных тестов, NSF является полезной технологией, но [только] в случаях, когда при переключение SUP/RP не изменяется состояние (up/down) интерфейсов, через которые проходит трафик. Такими сценариями могут быть, например, обновление firmware в случае dual-SUP.

В то же время заметим, что если переключение сопровождается изменением состояния интерфейсов (up/down), то время сходимости сети может быть «неожиданно» высоким (в худшем из наших тестов – до 125 секунд).

Если Ваш дизайн требует использование multi-chassis HA одновременно с OSPF NSF IETF, рекомендуется использовать Strict-LSA-check, чтобы изменения топологии могли быть своевременно обнаружены. Однако эта опция делает NSF IETF фактически бессмысленной на стеках коммутаторов; дизайн VSS quad-SUP не страдает от этой проблемы.

Если OSPF NSF не является обязательно технологией в Вашем дизайне, имеет смысл исключить ее использование и полностью положиться на время сходимости OSPF (при должном дизайне и настройке составляет до 1 секунды).

Дополнительные рекомендации:

  • используйте NSR вместо NSF (если поддерживается платформой), т.к. в этом случае выполняется stateful переключение и о времени сходимости речь не идет;
  • если NSF необходим – рассмотрите возможность использования опции “Loop-free-alternative” (LFA), которая позволит решить проблему фиксации CEF во время работы NSF процесса;
  • если ничего из вышеуказанного не применимо, попробуйте, где возможно, объединить L3 интерфейсы в L3 port-channel.

 

Благодарю за внимание. Удачи.

История версий
Редакция №
1 из 1
Последнее обновление:
‎02-08-2016 04:29 AM
Автор обновления: