Ввиду того, что VSS для третьего коммутатора выглядит как единое устройство, при обрыве одного из линков проиcходит перераспределение трафика на второй. Время восстановления в этом случае можно считать равным заявленому - 200 мс (Потерялся один пинг от хоста к хосту в разных виланах, терминирующихся на VSS и подключенных к третьему свитчу. В обратную сторону вообще не было пропадания.)
Второй сценарий - обрыв одного из линков VSL.
Здесь происходит то же самое. Трафик перераспределяется теперь уже внутри etherchannel VSL.
Третий сценарий - выход из строя одного из свитчей или супервизора одного из свитчей.
В этом случае, если падает Standby, второй просто остается в Active режиме. Если вышел из строя Active - Standby свитч через VSLP определяет падение пира и становится Active. Трафик по multichassis etherchannel опять же перераспределяется через работающие линки.
Найболее интересный и разрушительный сценарий - обрыв обоих линков VSL. В этом случае оба коммутатора заметив падение пира перейдут в состояние Active и в сети появляются два устройства с одинаковой конфигурацией.
Чтобы избавиться от такой ситуации Cisco предлагает два решения:
- использоварь Enhanced PAgP. В этом случае коммутатор, подключенный через MEC к VSS должен поддерживать данный протокол. Ввиду отсутствия такого свитча, тест с использованием Enhanced PAgP не проводился.
- использовать специально выделенный layer 3 линк для определения ролей (на рисунках обозначен IP BFD)- Bidirectional Forwarding Detection.
Для конфигураци bfd настраиваются два l3 интерфейса
vss#conf t
Enter configuration commands, one per line. End with CNTL/Z.
core-vss(config)#int gig 1/2/1
core-vss(config-if)#ip address 10.1.1.1 255.255.255.0
core-vss(config-if)#bfd interval 100 min_rx 100 multiplier 50
core-vss(config-if)#no shutdown
core-vss(config-if)#int gig 2/2/1
core-vss(config-if)#ip address 10.1.2.1 255.255.255.0
core-vss(config-if)#bfd interval 100 min_rx 100 multiplier 50
core-vss(config-if)#no shutdown
core-vss(config-if)#exit
Затем включаем BFD
vss(config)#switch virtual domain 10
core-vss(config-vs-domain)#dual-active detection bfd
core-vss(config-vs-domain)#dual-active pair interface gig1/2/1 interface gig2/2/1 bfd
adding a static route 10.1.2.0 255.255.255.0 Gi1/2/1 for this dual-active pair
adding a static route 10.1.1.0 255.255.255.0 Gi2/2/1 for this dual-active pair
core-vss#show switch virtual dual-active bfd
Bfd dual-active detection enabled: Yes
Bfd dual-active interface pairs configured:
interface-1 Gi1/2/1 interface-2 Gi2/2/1
Время приступать к тестам. Рвем оба линка между куммутаторами в VSS
Jun 4 12:57:54.270: %VSLP-SW1_SP-3-VSLP_LMP_FAIL_REASON: Te1/5/5: Link down
Jun 4 12:58:10.552: %VSLP-SW1_SP-3-VSLP_LMP_FAIL_REASON: Te1/5/4: Link down
Jun 4 12:58:10.572: %VSLP-SW1_SP-2-VSL_DOWN: Last VSL interface Te1/5/4 went down
Jun 4 12:58:10.572: %VSLP-SW1_SP-2-VSL_DOWN: All VSL links went down while switch is in ACTIVE role
Jun 4 12:58:10.572: %VSL-SW1_SP-3-VSL_SCP_FAIL: SCP operation failed
Jun 4 12:58:11.540: %PFREDUN-SW1_SP-6-ACTIVE: Standby supervisor removed or reloaded, changing to Simplex mode
Как видно, Active свитч заметил падение обоих VSL. Та же картина и на Standby, только он теперь в Active mode.
Jun 4 12:50:02.970: %VSLP-SW2_SPSTBY-2-VSL_DOWN: Last VSL interface Te1/5/4 went down
Jun 4 12:50:02.970: %VSLP-SW2_SPSTBY-2-VSL_DOWN: All VSL links went down while switch is in Standby role
Jun 4 12:50:02.970: %DUAL_ACTIVE-SW2_SPSTBY-1-VSL_DOWN: VSL is down - switchover, or possible dual-active situation has occurred
Jun 4 12:50:02.970: %DUAL_ACTIVE-SW2_SPSTBY-1-VSL_DOWN: VSL is down - switchover, or possible dual-active situation has occurred
Jun 4 12:50:02.970: %VSL-SW2_SPSTBY-3-VSL_SCP_FAIL: SCP operation failed
Jun 4 12:50:02.974: %PFREDUN-SW2_SPSTBY-6-ACTIVE: Initializing as Virtual Switch ACTIVE processor
Jun 4 12:50:05.098: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
Jun 4 12:50:05.102: %C6KPWR-SP-4-PSOK: power supply 2 turned on.
000015: Jun 4 12:50:05.274: %SATVS_IBC-5-VSL_DOWN_SCP_DROP: VSL inactive - dropping cached SCP packet: (SA/DA:0x14/0x1, SSAP/DSAP:0x18/0x0, OP/SEQ:0x19/0x1E, SIG/INFO:0x1/0x501, eSA:0000.1500.0000)
Jun 4 12:50:05.118: %OIR-SP-6-INSCARD: Card inserted in slot 3, interfaces are now online
Jun 4 12:50:05.174: %OIR-SW2_SP-6-INSCARD: Card inserted in slot 1, interfaces are now online
Jun 4 12:50:05.178: %OIR-SW2_SP-6-INSCARD: Card inserted in slot 5, interfaces are now online
Jun 4 12:50:05.178: %OIR-SW2_SP-6-INSCARD: Card inserted in slot 2, interfaces are now online
Оба коммутатора находятся в Active mode. Далее происходит слеующее. Коммутаторы определяют dual-active state и тот из них, который был Active в нормальном режиме переходит в режим dual-active recovery, выключая все свои порты, кроме VSL и исключенных.
Jun 4 12:58:58.274: %DUAL_ACTIVE-SW1_SP-1-RECOVERY: BFD running on Gi1/2/1 triggered dual-active recovery
Jun 4 12:58:58.302: %DUAL_ACTIVE-SW1_SP-1-DETECTION: Dual-active condition detected: all non-VSL and non-excluded interfaces have been shut down
После восстановления VSL, коммутатор в dual-active режиме перезагружается и становится Standby.
Jun 4 13:00:58.072: %VSLP-SW1_SP-5-VSL_UP: Ready for Role Resolution with Switch=2, MAC=0022.0d87.c000 over Te1/5/4
000020: Jun 4 13:01:01.140: %DUAL_ACTIVE-1-VSL_RECOVERED: VSL has recovered during dual-active situation: Reloading switch 1
000021: Jun 4 13:01:01.728: %SYS-5-RELOAD: Reload requested Reload Reason: Reload Command.
Jun 4 13:01:01.172: %SATVS_IBC-SW1_SP-5-VSL_DOWN_SCP_DROP: VSL inactive - dropping cached SCP packet: (SA/DA:0x4/0xFF, SSAP/DSAP:0x2/0x18, OP/SEQ:0x215/0xB4D4, SIG/INFO:0x1/0x1504, eSA:0000.0500.0000)
Jun 4 13:01:02.140: %VSLP-SW1_SP-5-RRP_MSG: Role change from Active to Standby and hence need to reload
Jun 4 13:01:02.140: %VSLP-SW1_SP-5-RRP_MSG: Reloading the system...3:
Jun 4 13:01:04.724: %SYS-SW1_SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.
01
Jun 4 13:01:04.724: %OIR-SW1_SP-6-CONSOLE: Changing console ownership to switch processor
:03.708: %SYS-SW1_SP-5-RELOAD: Reload requested Reload Reason: VSLP HA role change from active to standby.
Jun 4 13:01:04.940: %SYS-SW1_SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output.
Jun 4 13:01:07.524: %SYS-SW1_SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.
***
*** --- SHUTDOWN NOW ---
***
Jun 4 13:01:07.524: %SYS-SW1_SP-5-RELOAD: Reload requested
Jun 4 13:01:07.524: %OIR-SW1_SP-6-CONSOLE: Changing console ownership to switch processor
Таким образом происходит восстановление всей системы вцелом.
В общих чертах система показывает довольно неплохую надежность и заявленные 200 мс на восстановление после сбоя впечатляют, однако не обошлось без ложки дегтя. При обрыве VSL два устройства с одинаковой конфигурацией жили в сети почти минуту. А это время плохой доступности сервисов. А также расстроила необходимость перезагрухки про переходе из Active в Standby.
Однако, посмотрим как VSS будет вести себя в продакшене.
Сообщения
Комментариев нет:
Отправить комментарий