لب عملی: پیکربندی Telemetry مبتنی‌بر-مدل

این لب عملی یک روتر را برای جریان‌سازی پیوسته آمار اینترفیس به یک collector با استفاده از telemetry مبتنی‌بر-مدل پیکربندی می‌کند، و این رویکرد push-محور را با رویکرد pull-محور و مبتنی‌بر-پرس‌وجو که هر روش نظارتی قبلی در این مجموعه به آن متکی بود مقایسه می‌کند.

Telemetry مبتنی‌بر-مدلاشتراک Dial-Outپخش‌جریانی Push-محور

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

هدف لب

پیکربندی یک اشتراک telemetry از نوع dial-out روی یک روتر که آمار اینترفیس را به یک collector در بازه منظم جریان می‌دهد، تأیید اینکه داده به‌طور پیوسته بدون نیاز collector به درخواست‌کردن آن می‌رسد، و مقایسه این مدل push-محور با pull-محور استفاده‌شده توسط SNMP در یک لب قبلی.

هدف لب (چرا مهم است)

SNMP، پیش‌تر در این مجموعه پوشش داده شد، نیازمند این است که یک ایستگاه مدیریتی به‌طور فعال یک دستگاه را برای آمار به‌روزشده پرس‌وجو کند، به این معنا که داده هرگز تازه‌تر از آخرین بازه پرس‌وجو نیست و هر پرس‌وجو چرخه‌های CPU دستگاه را برای پاسخ‌دادن مصرف می‌کند. Telemetry مبتنی‌بر-مدل این رابطه را کاملاً معکوس می‌کند: خود دستگاه فعالانه داده را به یک collector طبق یک زمان‌بندی می‌فرستد، بدون نیاز collector به درخواست هیچ‌چیزی.

توپولوژی لب

R1 ---- Gi0/0: 192.168.255.1/24

Collector Telemetry: 192.168.255.200، گوش‌دادن
روی پورت TCP 25000

وظیفه ۱: تعریف یک اشتراک Telemetry

یک اشتراک telemetry که مسیر YANG را برای آمار اینترفیس برای جریان‌سازی مشخص می‌کند بساز.

وظیفه ۲: پیکربندی Collector مقصد

اشتراک را با استفاده از مدل dial-out به آدرس و پورت collector اشاره بده.

وظیفه ۳: تنظیم بازه جریان‌سازی

پیکربندی کن به‌روزرسانی‌ها چقدر مکرر به collector فرستاده می‌شوند.

وظیفه ۴: تأیید فعال‌بودن اشتراک

تأیید کن روتر اشتراک را برقرار و به‌طور فعال در حال جریان‌سازی نشان می‌دهد.

وظیفه ۵: تأیید رسیدن داده به Collector بدون پرس‌وجو

تأیید کن collector یک جریان پیوسته از به‌روزرسانی‌ها را بدون هرگز فرستادن یک درخواست خودش دریافت می‌کند.

راه‌حل و تأیید

R1(config)# telemetry ietf subscription 100
R1(config-mdt-subs)# encoding encode-kvgpb
R1(config-mdt-subs)# filter xpath /interfaces-state/interface/statistics
R1(config-mdt-subs)# source-address 192.168.255.1
R1(config-mdt-subs)# stream yang-push
R1(config-mdt-subs)# update-policy periodic 3000

-- "periodic 3000" به‌روزرسانی‌ها را هر ۳۰۰۰
-- سانتی‌ثانیه (۳۰ ثانیه) می‌فرستد -- کاملاً
-- توسط خود روتر طبق این زمان‌بندی آغاز می‌شود،
-- برخلاف SNMP جایی که مدیر تصمیم می‌گیرد چه
-- زمانی سؤال کند

R1(config-mdt-subs)# receiver ip address 192.168.255.200 25000 protocol grpc-tcp

-- Dial-out یعنی R1 اتصال را به‌سمت collector
-- آغاز می‌کند، به‌جای اینکه collector به R1
-- مانند یک مدیر SNMP متصل شود

R1# show telemetry ietf subscription 100 detail

Subscription ID: 100
Type: Configured
State: Valid
Stream: yang-push
Filter: /interfaces-state/interface/statistics
Update policy: Periodic (3000 centiseconds)
Receiver: 192.168.255.200:25000, State: Connected
-- "Connected" تأیید می‌کند R1 جلسه خروجی به
-- collector را برقرار کرده و به‌طور فعال داده
-- می‌فرستد

-- روی collector (تأیید مفهومی):

[10:00:00] به‌روزرسانی دریافت شد: آمار Gi0/0،
           in-octets: 184532102
[10:00:30] به‌روزرسانی دریافت شد: آمار Gi0/0،
           in-octets: 184601288
[10:01:00] به‌روزرسانی دریافت شد: آمار Gi0/0،
           in-octets: 184670445
-- داده جدید هر ۳۰ ثانیه بدون اینکه collector
-- هرگز یک درخواست بفرستد می‌رسد -- یک جریان
-- پیوسته و درخواست‌نشده، برخلاف الگوی درخواست-
-- سپس-پاسخ SNMP

نکته کلیدی

مدل push در dial-out مسئولیت آغاز جریان داده را کاملاً به دستگاه منتقل می‌کند — R1 تصمیم می‌گیرد چه زمانی به‌روزرسانی‌ها را بر اساس زمان‌بندی پیکربندی‌شده خودش بفرستد، و collector را از مدیریت بازه‌های پرس‌وجو در سراسر بالقوه هزاران دستگاه آزاد می‌کند و تأخیر بین یک تغییر حالت واقعی و زمانی که یک collector درباره آن یاد می‌گیرد را کاهش می‌دهد، چون telemetry جریان‌شده می‌تواند بسیار مکررتر از آنچه یک بازه پرس‌وجوی معمولی SNMP بدون غرق‌کردن شبکه تحمل می‌کرد به‌روزرسانی شود.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

لب عملی: پیکربندی مسیریابی Stub در EIGRP

این لب عملی یک روتر شعبه را به‌عنوان یک stub در EIGRP پیکربندی می‌کند، و تأیید می‌کند فقط مسیرهای متصل و خلاصه خودش را تبلیغ می‌کند در حالی که روتر hub به‌درستی از پرس‌وجوکردن stub در طول یک تغییر توپولوژی در جای دیگری از شبکه اجتناب می‌کند.

ادامه

لب عملی: پیکربندی حالت Named در EIGRP

این لب عملی یک پیکربندی EIGRP کلاسیک موجود را به حالت named EIGRP بازپیکربندی می‌کند، و عبارات network و پیکربندی خاص-اینترفیس را در یک سلسله‌مراتب address-family ساختاریافته‌تر سازمان‌دهی می‌کند، و تعادل عملکردی با سبک پیکربندی کلاسیک استفاده‌شده در سراسر لب‌های EIGRP قبلی این مجموعه را تأیید می‌کند.

ادامه

لب عملی: پیکربندی ERSPAN در سراسر یک شبکه مسیریابی‌شده

این لب عملی Encapsulated RSPAN (ERSPAN) را برای آینه‌کردن ترافیک در سراسر یک شبکه مسیریابی‌شده-لایه-۳ به‌جای یک ترانک لایه ۲ واحد پیکربندی می‌کند، و مفهوم RSPAN از لب قبلی را فراتر از مرزهای یک VLAN یا دامنه سوئیچ‌شده واحد گسترش می‌دهد.

ادامه

لب عملی: پیکربندی RSPAN در سراسر سوئیچ‌ها

این لب عملی Remote SPAN (RSPAN) را با استفاده از یک VLAN RSPAN اختصاصی حمل‌شده در سراسر یک ترانک پیکربندی می‌کند، و اجازه می‌دهد ترافیک آینه‌شده روی یک سوئیچ توسط یک دستگاه گرفتن متصل به یک سوئیچ کاملاً متفاوت نظارت شود، و مفهوم SPAN محلی پوشش‌داده‌شده در یک لب قبلی را در سراسر شبکه گسترش می‌دهد.

ادامه

لب عملی: پیکربندی In-Service Software Upgrade (ISSU) روی یک Stack

این لب عملی یک In-Service Software Upgrade را در سراسر یک stack StackWise انجام می‌دهد، و ایمیج IOS هر عضو را یکی‌یکی ارتقا می‌دهد در حالی که stack در سراسر آن به فوروارد‌کردن ترافیک ادامه می‌دهد، و صفر خرابی را در مقایسه با رویکرد مخل reload استفاده‌شده در لب‌های ارتقای IOS قبلی تأیید می‌کند.

ادامه

لب عملی: پیکربندی Stacking سنتی StackWise در Catalyst

این لب عملی stacking سنتی Catalyst (StackWise) را در سراسر سه سوئیچ با استفاده از کابل‌های stack پیکربندی می‌کند، و نیازمندی تک-لایه و مجاورت فیزیکی‌اش را با جفت StackWise Virtual پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه