لب عملی: پیکربندی NBAR2 برای دید برنامه

این لب عملی کشف پروتکل NBAR2 را روی یک اینترفیس روتر فعال می‌کند، و ترافیک لایه-برنامه را با امضا به‌جای فقط شماره پورت شناسایی می‌کند، سپس آن طبقه‌بندی را مستقیماً درون یک policy-map QoS برای اولویت‌دادن به یک برنامه خاص استفاده می‌کند.

کشف پروتکل NBAR2طبقه‌بندی مبتنی‌بر-برنامهبازرسی عمیق بسته با match protocol

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

هدف لب

فعال‌کردن کشف پروتکل NBAR2 روی یک اینترفیس، بررسی تفکیک برنامه حاصل ترافیک مشاهده‌شده، سپس پیکربندی یک class-map که یک برنامه خاص را با امضای NBAR2 به‌جای شماره پورت تطبیق می‌دهد، و اعمال رفتار QoS بر اساس آن طبقه‌بندی.

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

هر class-map پوشش‌داده‌شده در سراسر لب‌های QoS این مجموعه ترافیک را با ACL ها، مقادیر DSCP، یا تطبیق‌های ساده پروتکل/پورت تطبیق دادند — هیچ‌کدام به‌طور قابل‌اعتماد برنامه‌ای که از پورت‌های پویا استفاده می‌کند یا خودش را روی یک پورت رایج پنهان می‌کند را شناسایی نمی‌کنند. NBAR2 بازرسی عمیق بسته انجام می‌دهد تا برنامه واقعی را با امضا شناسایی کند، و طبقه‌بندی‌ای را امکان‌پذیر می‌کند که تطبیق مبتنی‌بر-پورت به‌تنهایی نمی‌تواند به دست آورد.

توپولوژی لب

R1 ---- Gi0/1 (اینترفیس رو‌به‌سمت-WAN)

ترافیک مخلوط شامل یک برنامه کنفرانس ویدیویی
که از پورت‌های UDP پویا که به‌ازای-هر-جلسه
تغییر می‌کنند استفاده می‌کند، که تطبیق ACL
ایستا مبتنی‌بر-پورت را غیرقابل‌اعتماد می‌کند

وظیفه ۱: فعال‌کردن کشف پروتکل NBAR2

کشف پروتکل را روی اینترفیس رو‌به‌سمت-WAN برای مشاهده منفعلانه ترکیب ترافیک فعال کن.

وظیفه ۲: تولید ترافیک مخلوط شامل برنامه ویدیو

یک تنوع از انواع ترافیک، شامل برنامه کنفرانس ویدیویی که از پورت‌های پویایش استفاده می‌کند، تولید کن.

وظیفه ۳: بررسی آمار کشف پروتکل

تفکیک برنامه‌های شناسایی‌شده و مصرف پهنای‌باندشان را بررسی کن.

وظیفه ۴: ساخت یک Class-Map که برنامه ویدیو را با امضای NBAR2 تطبیق می‌دهد

یک class-map با استفاده از match protocol که به برنامه خاصی که NBAR2 شناسایی کرد ارجاع می‌دهد، به‌جای یک شماره پورت، پیکربندی کن.

وظیفه ۵: اعمال رفتار اولویتی بر اساس این طبقه‌بندی

یک policy-map که به این ترافیک طبقه‌بندی‌شده-با-NBAR2 صف‌بندی اولویتی می‌دهد پیکربندی کن، و تأیید کن با وجود استفاده پویا از پورت برنامه تأثیر می‌گذارد.

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

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip nbar protocol-discovery

VideoApp-PC> [یک جلسه کنفرانس ویدیویی آغاز
              می‌کند، و پورت‌های UDP پویا برای
              جلسه مذاکره می‌کند]

R1# show ip nbar protocol-discovery interface gigabitethernet0/1

Protocol                Total       Input        Output
                         (packets)   (packets)    (packets)
webex-meeting            48210       24105        24105
http                     12403       6201         6202
unknown                  3204        1602         1602
-- NBAR2 به‌درستی برنامه کنفرانس ویدیویی را با
-- امضا شناسایی کرد ("webex-meeting" در این
-- مثال)، با وجود استفاده‌اش از پورت‌های UDP
-- پویا که یک ACL ایستا مبتنی‌بر-پورت را کاملاً
-- شکست می‌داد

R1(config)# class-map match-all VIDEO-APP
R1(config-cmap)# match protocol webex-meeting

-- "match protocol" که به نام امضای NBAR2
-- ارجاع می‌دهد، به‌جای "match protocol udp"
-- ترکیب‌شده با یک بازه پورت که نیاز به
-- به‌روزرسانی‌مداوم همان‌طور که پورت‌های پویای
-- برنامه تغییر می‌کنند داشت

R1(config)# policy-map CBWFQ-POLICY
R1(config-pmap)# class VIDEO-APP
R1(config-pmap-c)# priority percent 15

-- افزودن این به سیاست LLQ موجود از لب قبلی،
-- در کنار صف اولویت صوتی و کلاس‌های CBWFQ
-- از‌قبل پیکربندی‌شده

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICY

VideoApp-PC> [یک تماس ویدیویی دیگر انجام می‌دهد،
              و مجموعه‌ای متفاوت از پورت‌های
              UDP پویا نسبت به قبل مذاکره می‌کند]

R1# show policy-map interface gigabitethernet0/1

    Class-map: VIDEO-APP
      Strict Priority
      (pkts matched/bytes matched) 38942/...
      (total drops) 0
-- سیاست به‌درستی این جلسه را نیز تطبیق داد و
-- اولویت‌بندی کرد، با وجود استفاده از یک
-- مجموعه کاملاً متفاوت از پورت‌های پویا نسبت
-- به جلسه قبلی که NBAR2 در ابتدا مشاهده کرد --
-- و تأیید می‌کند طبقه‌بندی بر اساس امضای واقعی
-- برنامه است، نه هیچ شماره پورت خاصی

نکته کلیدی

طبقه‌بندی match protocol در NBAR2 ترافیک را با امضای واقعی لایه-برنامه‌اش به‌جای شماره پورت شناسایی می‌کند، که آن را منحصراً قادر به طبقه‌بندی سازگار برنامه‌هایی که از پورت‌های پویا یا غیر-استاندارد استفاده می‌کنند می‌کند — قابلیتی که هر class-map مبتنی‌بر-پورت یا مبتنی‌بر-ACL پوشش‌داده‌شده پیش‌تر در لب‌های QoS این مجموعه اساساً فاقد آن است، چون آن رویکردها نیاز به به‌روزرسانی‌های دستی مداوم هر بار که استفاده پورت یک برنامه تغییر می‌کند داشتند.

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

مقالات مرتبط

لب عملی: پیکربندی مسیریابی 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 پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه