هدف لب
فعال‌کردن یک ISSU روی یک stack StackWise سه‌عضوی، مشاهده هر عضو که راه‌اندازی مجدد و به‌طور متوالی دوباره می‌پیوندد در حالی که stack به‌عنوان یک کل به فوروارد‌کردن ترافیک ادامه می‌دهد، و تأیید اینکه همه اعضا نسخه IOS جدید را یک‌بار که فرآیند کامل شود بدون هیچ نقطه شکست کاملی اجرا می‌کنند.
هدف لب (چرا مهم است)
لب ارتقای IOS پیش‌تر در این مجموعه نیازمند یک راه‌اندازی مجدد کامل بود، و باعث یک خرابی کامل روی آن دستگاه منفرد در طول پنجره ارتقا می‌شد. ISSU روی یک stack از داشتن چند عضو فیزیکی برای ارتقادادن و راه‌اندازی‌مجددشان یکی‌یکی بهره می‌برد، و کل stack را در سراسر آن عملکردی نگه می‌دارد — قابلیتی بدون معادل روی یک روتر یا سوئیچ مستقل منفرد.
توپولوژی لب
stack سه‌عضوی StackWise از لب stacking قبلی، در
حال حاضر در حال اجرای IOS نسخه 16.9.1، برای
ارتقا به 16.9.4
ایمیج جدید از‌قبل به فلش روی هر سه عضو کپی
شده، همان‌طور که در لب ارتقای IOS قبلی پوشش
داده شدوظیفه ۱: تأیید نسخه IOS فعلی در سراسر همه اعضا
تأیید کن هر سه عضو stack در حال حاضر همان نسخه قدیمی‌تر IOS را اجرا می‌کنند.
وظیفه ۲: فعال‌کردن فرآیند ISSU
دستور بارگذاری ISSU با مشخص‌کردن ایمیج جدید، هدف‌گیری stack، را صادر کن.
وظیفه ۳: نظارت بر فرآیند راه‌اندازی‌مجدد متوالی عضو
مشاهده کن اعضا یکی‌یکی به‌جای هم‌زمان راه‌اندازی مجدد می‌شوند، و اتصال stack را در سراسر آن تماشا کن.
وظیفه ۴: تأیید فوروارد‌کردن پیوسته ترافیک در طول ارتقا
ترافیک پیوسته از میان stack در طول پنجره ارتقا تولید کن و تأیید کن هیچ وقفه پایداری رخ نمی‌دهد.
وظیفه ۵: تأیید اجرای نسخه جدید توسط همه اعضا
یک‌بار که فرآیند کامل شود، تأیید کن هر عضو stack نسخه IOS جدید را گزارش می‌دهد.
راه‌حل و تأیید
Switch# show version | include Version
Cisco IOS Software, Version 16.9.1
-- (تأیید‌شده سازگار در سراسر جزئیات عضو
-- "show switch" نیز -- هر سه عضو روی همان
-- نسخه)Switch# issu loadversion 1 flash:cat9k_16.09.04.SPA.bin
2 flash:cat9k_16.09.04.SPA.bin
3 flash:cat9k_16.09.04.SPA.bin
-- ISSU هدایت می‌شود تا ایمیج جدید را روی هر
-- سه عضو بارگذاری کند، اما خود فرآیند آن را
-- به‌طور متوالی اعمال خواهد کرد به‌جای
-- راه‌اندازی‌مجدد کل stack یک‌جاSwitch# show issu state detail
Slot Image Version Status
1 16.09.04 STANDBY
2 16.09.04 STANDBY
3(active) 16.09.01 RUNNING
-- اعضا ایمیج جدید را آماده می‌کنند در حالی که
-- روی نسخه در حال اجرای فعلی باقی می‌مانند، و
-- ارتقا را پیش از شروع هر راه‌اندازی‌مجدد
-- مخلی مرحله‌بندی می‌کنند-- ISSU ادامه می‌دهد به راه‌اندازی‌مجدد اعضا
-- یکی‌یکی، و اول با اعضای غیر-فعال شروع می‌کند:
*عضو 1 در حال راه‌اندازی‌مجدد...*
*عضو 1 دوباره به stack پیوست، در حال اجرای 16.09.04*
*عضو 2 در حال راه‌اندازی‌مجدد...*
*عضو 2 دوباره به stack پیوست، در حال اجرای 16.09.04*
-- فقط پس از اینکه اعضای غیر-master با موفقیت
-- دوباره پیوستند فرآیند به راه‌اندازی‌مجدد
-- master فعلی آخر حرکت می‌کند، و یک سوئیچ
-- کنترل‌شده نهایی نقش master را فعال می‌کندContinuousTrafficGen> [ping پیوسته از میان
stack در سراسر کل
فرآیند ISSU]
Ping statistics: 1,842 sent, 1,839 received,
0.16% loss (از‌دست‌رفتن کوتاه
فقط در طول سوئیچ نهایی
master، چند صد میلی‌ثانیه)
-- ترافیک در سراسر تقریباً کل ارتقا همچنان
-- جریان یافت -- تنها وقفه کوتاه در طول گذار
-- نهایی نقش master رخ داد، بسیار کوتاه‌تر از
-- خرابی چند-دقیقه‌ای که یک راه‌اندازی‌مجدد
-- کامل stack ایجاد می‌کردSwitch# show switch
Switch# Role Version State
------------------------------------
1 Member 16.09.04 Ready
2 Member 16.09.04 Ready
*3 Master 16.09.04 Ready
-- هر سه عضو اکنون تأیید‌شده در حال اجرای
-- نسخه جدید IOS، با stack که در سراسر کل
-- فرآیند ارتقا عملکردی باقی ماندهنکته کلیدی
قابلیت تقریباً-صفر-خرابی ISSU کاملاً به داشتن اعضای فیزیکی افزونه برای توالی‌کردن از میان آن‌ها بستگی دارد — قابلیتی منحصر به پلتفرم‌های stackشده یا شاسی-افزونه، بدون معادل روی روترهای مستقل منفرد ارتقا‌یافته از طریق فرآیند ساده copy/reload پوشش‌داده‌شده در یک لب قبلی؛ وقفه کوتاه در طول سوئیچ نهایی master معمولاً بسیار کوتاه‌تر از هر timeout جلسه TCP است، که ISSU را عملاً برای بیشتر اپلیکیشن‌ها شفاف می‌کند با وجود اینکه از نظر فنی کاملاً بدون-تأثیر نیست.