هدف لب
فعالکردن کشف پروتکل 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-discoveryVideoApp-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-POLICYVideoApp-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 این مجموعه اساساً فاقد آن است، چون آن رویکردها نیاز به بهروزرسانیهای دستی مداوم هر بار که استفاده پورت یک برنامه تغییر میکند داشتند.