این روش نیز از MQC یا Modular QoS Command Line استفاده میکند. یعنی ترافیک مورد نظر را با کمک یک ACL یا NBAR یا هر روشی ابتدا برای سیسکو درون یک Class-Map تعریف میکنیم… سپس درون یک Policy-Map یک سیاست نظیر محدودکردن، گارانتی، Shape و غیره را روی آن ترافیک اعمال میکنیم. اما کار به اینجا تمام نمی شود چون باید Policy به یک Interface ربط داده تا ترافیک ورودی یا خروجی (یا هردو) را کنترل کند. پس دید ما در پیاده سازی MQC بصورت Interface ی است: ترافیک ورودی / خروجی پورت (یا پورت ها). ترافیک ورودی را Inbound و خروجی را با Outbound مشخص میکنیم.

نکته:

برخی از دستورات نظیر گارانتی پهنای باند که با دستور Bandwidth اعمال میگردند تنها در زمان Congenstion (کمبود پهنای باند) عمل میکنند. یعنی وقتی پهنای باند پر شد این دستور شروع به کار میکند و برای مصرف خاصی که در Class-map مشخص کرده اید حداقل پهنای باندی را رزرو میکند. اما سیسکو از کجا پهنای باند کل پورت را تشخیص میدهد تا Congestion را Detect کند؟ از روی پهنای باند کل Interface یعنی روی Interface Fast Ethernet که سرعت آن 100Mbps است وقتی مصرف به 96-98 مگ رسید Congestion تشخیص داده شده و دستور Bandwidth شروع به کار میکند که این برای بعضی کاربران مناسب نیست… زیرا که سرویس دهنده تنها 2 مگابیت به آنها اختصاص داده و Congestion باید روی سقف 2 Mbps تشخیص داده شود نه پهنای باند کل Interface.

برای این کار باید خودمان ترافیک خروجی خودمان را محدود کنیم. و درون این محدودیت (که با دستور Shape یا Policy انجام میشود) مقداری پهنای باند برای سرویس خاصی تخصیص دهیم.

در مثال زیر سرویس Voice ما از IP 10.0.0.10 استفاده میکند و میخواهیم روی پهنای باند 1mbps خود، 128kbps برای ترافیک Voice اختصاص دهیم:

توجه داشته باشید که Interface ما Ethernet است یعنی پهنای باندی تا 10mbps را پشتیبانی میکند اگر بدون Policy Parent تنها Voice Policy را اعمال میکردیم وقتی پهنای باند 10 مگ پرمیشد تازه کار رزرو صورت میگرفت که زیاد به درد ما نمیخورد! چون پهنای باند ما هیچ وقت اجازه ندارد به این اندازه برسد… توسط سرویس دهنده محدود شده است. به این روش پیاده سازی Nested Model یا مدل تودرتو اجرای MQC میگویند. یک Policy کل پهنای باند خروجی را محدود میکند و Policy دیگر درون آن محدودیت، قانون دیگری وضع میکند…

Service-policy output: Parent

Service-policy : Voice

از سری محصولات CiscoWorks میتوان به موارد زیر اشاره کرد:

LAN Management System – LMS

CiscoWorks Voice Manager

CiscoWorks QoS Policy Manager – QPM

CiscoWorks Network Compliance Manager – NCM

 Cisco Security Manager – CSM

CiscoWorks Wireless LAN Solution Engine – WLSE

سری LMS بدون شک پرفروش ترین و معروف ترین CiscoWorks است. در این بین با QPM هم کار کردم که برای مدیریت QoS شبکه طراحی شده و ویژگی های جالبی دارد. WLSE برای مدیریت شبکه های Wireless سیسکو است و مطابق نقشه ساختمان پوشش Wireless ها را نشان داده و در صورتیکه Access-Point زائدی در شبکه نصب شود آنرا شناسایی میکند. CSM خود از زیر نام CiscoWorks در آمده و با پشتیبانی از دیگر محصول سیسکو بنام MARS بعنوان یک محصول قوی جهت استاندارد سازی امنیت شبکه و محدود کردن خطرات عرضه میشود.

برگردیم به LMS برای مدیریت شبکه های LAN… نسخه های اولیه LMS بسیار آزاردهنده بودند. مجموعه ای از 13 CD که یک به یک باید نصب میشدند و بیش از 4 ساعت زمان برای نصب آن نیاز بود. ماه پیش نسخه جدید 3.2 آن ارائه شد که خصوصیات جدیدی را به ارمغان آورده است. برای مقایسه نسخه های متفاوت LMS اینجا را کلیک کنید.

محصول CiscoWorks LAN Management از چندین محصول زیرمجموعه تشکیل شده است:

CiscoWorks Assistant
CiscoWorks Campus Manager
CiscoWorks CiscoView
CiscoWorks Common Services Software
CiscoWorks Device Fault Manager
CiscoWorks Internetwork Performance Monitor
CiscoWorks LAN Management Solution
CiscoWorks LMS Portal
CiscoWorks Resource Manager Essentials

یکی از شش برنامه اصلی در LMS برنامه RME است. کار Resource Management Essentials ایجاد لیست تجهیزات درست مثل فهرست های انبار داری است – Inventory Management مثل شماره سریال سوییچ ها و روتر های شبکه، ماژول ها، میزان حافظه و فلاش هر دستگاه و نوع IOS و نسخه آن. از جمله مواردی که با RME میتوان انجام داد upgrage کردن چندین دستگاه طی یک برنامه زمانبندی شده است. همچنین RME برای شما از Configuration ها و IOS ها بصورت اتوماتیک Backup میگیرد و اگر تغییراتی در تنظیمات انجام شود ثبت میکند و نسخه های قبلی تنظیمات را بصورت History برایتان حفظ میکند.

از دیگر برنامه های پکیج LMS برنامه CiscoView است. بکمک این برنامه میتوان تصویر یک دستگاه را بدون اینکه وارد سایت شویم و چراغ های دستگاه ها را چک کنیم برایمان پدیدار میکند:

روی پورت های سوییچ یا روتر کلیک کنید تا وضعیت ترافیک روی آن را به شما نشان دهد (تصویر بالا). در تصویر زیر پورت Ethernet روتر 1751 ما Shutdown است و برنگ قرمز نشان داده شده است:

LMS برای شما گراف شبکه ایجاد میکند و در صورتیکه دستگاهی ارتباط خود را از دست داد به شما Alert میدهد و روی صفحه نمایشگر بزرگ LCD خود برای Monitoring میتوانید دستگاه خراب را برنگ قرمز ببینید.  این گراف میتواند مربوط به یک ناحیه از شبکه یا کل شبکه باشد و بنام Topology Services داخل صفحه LMS Portal قید شده است:

از دیگر خصوصیات LMS اندازه گیری Performance شبکه و نشان دادن کارایی بر اساس اندازه گیری Jitter (نوسان در تاخیر) یا محاسبه عملکرد ICMP بین نقاط شبکه و حاصل آن را بصورت گراف در اختیارتان میگذارد. به این برنامه IPM یا Internetwork Performance Monitor میگوییم که از LMS2 به بسته CiscoWorks اضافه شد. در شکل زیر عمکرد چند ماه اخیر و نوسان Ping ها  بین نود های مختلف WAN نشان داده شده است.

در آخر باید بخاطر داشت که نصب LMS بصورت کامل کار ساده ای نیست و نیاز به آزمایش، تمرین و تجربه دارد. برای دریافت اطلاعات از تجهیزات باید SNMP را روی دستگاه ها تنظیم کنید و به LMS دسترسی دهید. LMS از یک یا چند روتر بعنوان Seed Device استفاده میکند تا توپولوژی شبکه را تشخیص دهد و بقیه دستگاهها را بصورت Auto Discovery به مجموعه اضافه کند. پس از آن باید RCP را روی دستگاهها تنظیم کنید تا کار کپی IOS برای Upload و Download از LMS به هر روتر و سوییچ امکان پذیر شود. SYSLOG را نیز به آدرس LMS میفرستید چون LMS خود یک Syslog Server نیز هست. پس از آن SMTP سرور را برای LMS تنظیم میکنید تا در صورتیکه خطایی در کارایی شبکه پیدا شد DFM يا Device Fault Management به شما email زده و شما را از حوادث مطلع کند.

در صورتیکه خواستید امتحان کنید نسخه 3.2 را پیشنهاد میکنم (Stable است) که از سایت سیسکو میتوان بصورت Evaluation دریافت کرد. (از IP های ایران ممکن است کار نکند در صورتیکه کار کرد لطفا comment بگذارید.)

http://cisco.mediuscorp.com/lms

چندی پیش برای مشتری بزرگی Presentation برای LMS تهیه کردم و پروژه نصب LMS با License 1000 دستگاه را انجام دادیم. میتوانید این PowerPoint مختصر نیم مگی را Download کنید:

پروتکل NetFlow در سال 1996 توسط دو مهندس سیسکو بنامهای Darren Kerr  و Barry Bruins ایجاد شد. یک پروتکل مدیریتی که اطلاعات Flow هایی که از روتر یا سوییچ عبور میکنند را به سرور ارسال میکند. بدین صورت میتوان از Flow ها و ترافیک در حال عبور مطلع شد.

NetFlow به پنج سوال رایج در ترافیک شبکه پاسخ میدهد: who, what, when, where and how

چه فرستنده ای به کدام گیرنده در زمان مشخص چه دیتایی را در چه حجمی ارسال میکند.

Source IP address

Destination IP address

Source port for UDP or TCP, 0 for other protocols

Destination port for UDP or TCP, type and code for ICMP, or 0 for other protocols

IP protocol

Ingress interface

IP Type of Service

از این پروتکل در Backbone های اینترنت جهت Accounting براساس ترافیک IP استفاده میشود. (Peering Arrangement )

براین اساس Backbone ها میتوانند ترافیک مورد Exchange خود با یکدیگر را حساب کنند. از دیگر موارد استفاده آن Network Planning و بررسی منابع مورد نیاز شبکه است.

از مصارف جدیدتر NetFlow، NBA يا Network Behavior Analysis است که در امنیت شبکه و برای تشخیص حملات و Denial of Service – DOS مورد استفاده قرار میگیرد.

اطلاعات جمع آوری شده در زمان های مشخصی توسط UDP به سرور NetFlow Collector ارسال میگردد. عموما 20 تا 50 Flow در هر بسته گزارش گنجانده میشود روی اکثر روتر های سیسکو و سوییچ های 6500 و 4500 پشتیبانی  شده و جدیدا در نسخه 8.2 سیستم عامل ASA روی فایروال نیز گنجانده شده است. که به آن NSEL یا NetFlow Security Event Logging گفته میشود و برای ارسال Flow ها به CS-MARS در نظر گرفته شده است.

آخرین نسخه NetFlow v9 است که اجازه تعریف اطلاعات ارسالی را بصورت Template به فرستنده و گیرنده میدهد. مثل MPLS و IPv6. همچنین IETF نسخه ای بنام IPFIX را که Version 10 آن اطلاق میشود براساس v9 استاندارد کرده است.RFC5101, RFC5102

از NetFlow برندهای دیگر شبکه نظیر جونیپر ، HP و Brocade تحت عنوان sFlow استفاده میکنند. (استاندارد)

برنامه های Collector متعددی برای NetFlow وجود دارد که قابلیت های زیاد و متنوعی را ارائه میکنند:

بطور مثال در Scrutinizer میتوان کاربر تعریف کرد و براساس هر کاربر سطح دسترسی مشخص کرد. نسخه رایگان آن را از وب سایت Plixer میتوان Download کرد. که البته نسخه حرفه ای آن رایگان نیست:

http://www.plixer.com/products/scrutinizer.php

تنظیمات:

router#configure terminal

router-2621(config)#interface FastEthernet 0/1

router-2621(config-if)#ip route-cache flow

router-2621(config-if)#exit

router-2621(config)#ip flow-export destination 192.168.0.101 9996

router-2621(config)#ip flow-export source FastEthernet 0/1

router-2621(config)#ip flow-export version 5

router-2621(config)#ip flow-cache timeout active 1

router-2621(config)#ip flow-cache timeout inactive 15

router-2621(config)#snmp-server ifindex persist

router#show ip flow export

router#show ip cache flow

از دیگر برنامه های Collector :

Adventnet Netflow analyzer

Solarwinds

Linux, FlowScan – http://net.doit.wisc.edu/~plonka/FlowScan

Netscout

Fluke Netflow Tracker – http://www.flukenetworks.com/fnet/en-us/products/NetFlow+Tracker

همچنین:

http://www.switch.ch/tf-tant/floma/software.html

http://www.networkuptime.com/tools/netflow

ترافیک را تفکیک کرده و به آن ترافیک خاص اولویت یا محدودیت میدهیم.

تفکیک ترافیک مورد نظر میتواند توسط Access List  یا NBAR یا از روی بیت های DSCP و ToS و IP-Precedence صورت گیرد.

Access-list 100 permit ip 192.168.1.0 0.0.0.255 any

!

Class-map customer1

Match access-group name 100

در مثال بالا ترافیک مشتری توسط Class-map بنام customer1 مشخص شد و در بخش بعدی تنظیمات در زیر مورد Policing قرارمیگیرد:

policy-map policy1

class customer1

police 800000 50000 exceed-action drop

توسط  دستور فوق هر آنچه توسط کلاس customer1 تشخیص داده شد به 800 کیلوبیت در ثانیه محدود میشود.

سپس در Interface مربوطه این تنظیمات اعمال میگردد:

interface GigabitEthernet0/2

service-policy input policy1

آنچه اشاره کردیم برای ترافیک ورودی به پورت یا Ingress است که روی سوییچ نیز قابل پیاده سازی است.

همچنین سوییچ های جدید نظیر 2960 قابلیت SRR bandwidth limit در زمان خروج ترافیک از پورت را دارند:

Switch(config)# interface fastethernet0/1

Switch(config-if)# srr-queue bandwidth limit 10

بطور مثال ترافیک پورت 100 فوق به 10 درصد یا 10 مگابیت در ثانیه محدود شده است. برای تنظیم این میزان بازه 10 تا 90 درصدی از کل 100 درصد ترافیک Interface قابل استفاده است.

پست های مرتبط:

http://shzandi.wordpress.com/2009/01/09/quality-of-services-review

http://shzandi.wordpress.com/2008/02/09/ccie-lab-qos-tricks

نوشته شده در Quality of Service, پاسخ به پرسش ها ]]> http://persian.shafagh.com/2009/06/25/%d9%85%d8%ad%d8%af%d9%88%d8%af-%da%a9%d8%b1%d8%af%d9%86-%d9%be%d9%87%d9%86%d8%a7%db%8c-%d8%a8%d8%a7%d9%86%d8%af/feed/ 18 SZandi 90563 http://persian.shafagh.com/2009/06/10/%d9%85%d8%ad%d8%a7%d8%b3%d8%a8%d9%87-%d9%be%d9%87%d9%86%d8%a7%db%8c-%d8%a8%d8%a7%d9%86%d8%af/ http://persian.shafagh.com/2009/06/10/%d9%85%d8%ad%d8%a7%d8%b3%d8%a8%d9%87-%d9%be%d9%87%d9%86%d8%a7%db%8c-%d8%a8%d8%a7%d9%86%d8%af/#comments Tue, 09 Jun 2009 20:40:32 +0000 Shafagh http://shzandi.wordpress.com/?p=792 ]]> دوست عزیزمان رامین سوال خوبی مطرح کردند:

مدت زمان ارسال یا دریافت یک فایل مثلا8G با پهنای باندمثلا 64K، بین دو لینک ارتباطی را چه طوری میتوان محاسبه کرد ؟

پهنای باندی که از سرویس دهنده میخرید براساس SLA يا Service Level Agreement – توافق فی مابین، میزان دیتایی که در واحد ثانیه قابل ارسال و دریافت از اینترنت است را مشخص میکند. اگر فرض کنیم که این عدد درست باشد و سرویس دهنده میزان واقعی را به شما اختصاص دهد (پهنای باند Dedicated به شما اختصاص دهد) شما در هر زمان باید قادر باشید که از تمام پهنای باند خود استفاده کنید.

پس پهنای باند به میزان دیتا در ثانیه بر میگردد اما ربطی به Delay یا تاخیر ارتباط شما ندارد. بطور مثال ممکن است ارتباط شما با Youtube یا Skype به 200 میلی ثانیه تا 700 میلی ثانیه برگردد (بسته به مقصد و مسیری که بسته های IP ارسال میشوند.)

بطور مثال اگر از ماهواره در بین راه استفاده شود:

برای اینکه ماهواره به نسبت یک نقطه روی زمین ثابت باشد باید در مدار GEO یا Geostationary orbit قرار گیرد که به نسبت یک نقطه از زمین بدون حرکت بنظر رسد تا بتوان Dish خود را ثابت به آن نقطه Fix کرد، به این مدار بخاطر محقق آن Clark Belt نیز گفته میشود.

بخاطر قرارگیری Satellite ها در مدار GEO که در 36000 کیلومتری زمین قراردارد با احتساب سرعت نور که 30000 کیلومتر در ثانیه است 120 میلی ثانیه نیاز داریم تا سیگنال به ماهواره رسیده و از آنجا به نقطه مقصد ارسال شود (مخابره از نقطه زمینی یک تا ماهواره و از هوا به نقطه دوم زمینی = 240 میلی ثانیه.)

پس اگر از ماهواره استفاده شود و بخواهیم مقصد را PING کنیم با توجه به رفت و برگشت بسته های ICMP برای هر بسته حدودا 250 میلی ثانیه زمان رفت و 250 میلی ثانیه جهت دریافت Reply سپری میشود (حداقل 500ms) نیاز داریم.

اگر از فیبرنوری استفاده شود مسیر زمینی کوتاهتری فراهم شده و میزان Delay کمتر خواهد بود بطور مثال وقتی RIPE.net را پینگ میکنم از مسیر فیبر استفاده میشود و RIPE را در 160 میلی ثانیه میبینم (80 میلی ثانیه برای رفت و 80 برای برگشت.)

حال برگردیم به سوال شما،

برای پهنای باند 64Kbps حمل یک فایل 8 Gigabyte چقدر زمانبر است؟

میدانیم که پهنای باند را بر حسب بیت مشخص میکنیم یعنی برخلاف فایل و Storage که براساس بایت (با B نشان داده میشود) عدد مورد نظر را در 8 ضرب میکنیم تا برحسب b یا بیت به میزان مورد نظر برسیم:

8 x 8 = 64 bit

یعنی 64 گیگابیت یا دقیقتر آن (از آنجا که هر کیلو بایت یا بیت 1024 واحد است نه هزار)

8 x 1024 x 1024 x 1024 x 8 = 68719476736 bit

حال برای این میزان بیت با در نظر گرفتن پهنای باند 64 هزار بیت در ثانیه به:

68719476736 / 64000 = 1073742 second = 17896 min = 298 hours = 12.5 days

نیاز داریم. در حالیکه اگر پهنای باند 2.5 مگابیت داشتید این میزان به 7 الی 8 ساعت کاهش پیدا میکرد.

اما این محاسبه کافی نیست!

از آنجا که محتویات Data داخل IP و TCP حمل میشود باید Header های اضافی و پارامتر های زیادی را محاسبه کرد که به عدد نهایی Throughput يا حداکثر توان انتقال لینک شما گفته میشود.

برای محاسبه میزان Throughput به فاکتورهای متعددی باید رجوع کرد:

MTU و MSS، Header Size ، TCP Window Size و همچنین RTT و Delay.

MTU میزان حداکثر دیتایی است که در یک بسته قرار میگیرد و عموما 1500 بایت یا  12000 بیت است. از این میزان عموما 40 بایت به Header های IP و TCP تعلق دارد پس 1460 بایت برای دیتای واقعی شما در هر Packet در نظر میگیریم.

هر چقدر میزان MTU بیشتر باشد میزان تاخیر نیز بیشتر میشود زیرا دیتای بیشتری در یک بسته حمل میشود اما نکته مثبت آن کمتر شدن Header های IP و TCP به ازای دیتای واقعی است.

پس اگر از هر 1500 بایت 1460 بایت آن محتویات فایل مورد نظر شما باشد در ارتباط 64 کیلوبیت میتوانید 510306 بیت در ثانیه را دیتای حقیقی قلمداد کنیم و محاسبه عوض میشود و یک ساعت جهت هدر ها افزایش زمان خواهیم داشت:

68719476736 / 63788 = 1077310 second = 17955 min = 299 hours

مساله بعدی TCP Window Size است که براساس استاندارد حداکثر 64 کیلوبایت است.

استفاده از Window Size برای کنترل سرعت در یک ارتباط TCP و اصلاح خطا ها در ارتباط يا Error Recovery است. یعنی هر چه پهنای باند هم داشته باشید در یک ارتباط TCP محدود به Window Size هستید بطور مثال پهنای باند 10 مگابیت من تا مقصد 200 میلی ثانیه تاخیر دارد. 64 کیلوبایت سایز Window برابر با 524288 بیت است.

اگر تاخیر را تا مقصد 200 میلی ثانیه فرض کنیم حداکثر توان حمل دیتا در یک ارتباط TCP برابر با:

524288 bits / 0.2 seconds = 2621440 = 2.5 mbps

پس بدون در نظر گرفتن پهنای باند من تا مقصد حداکثر پهنای باند در یک TCP Session برای من 2.5 مگابیت خواهد بود اگر بخواهم تا سقف 10 مگابیت خود را از مقصد بکشم باید از برنامه های Download استفاده کنم که تعداد بیشتری Connection تا سایت مورد نظر را فراهم میکنند و با Download همزمان در 4 Connection به عدد 10 مگابیت میرسد.

حال برای شما که 400 میلی ثانیه تا مقصد تاخیر دارید این عدد به  256 کیلوبیت در ثانیه محدود میشود که عدد بسیار کمی است. اما از آنجا که پهنای باند شما 64 کیلوبیت است به مشکلی در این زمینه برنخواهید خورد و نیاز به TCP Connection بیشتر ندارید!

در RFC 1323 راه حلی برای افزایش Window Size ارائه شده که توسط ویندوز ویستا نیز بکارگرفته میشود. از آن جا که این مساله در کل اینترنت بصورت یکپارچه پشتیبانی نمیشود؛ در بسیاری از موارد سرعت انتقال در ویستا کندتر از بقیه سیستم عامل ها شده و میتوان قابلیت Receive Window Auto-Tuning را غیرفعال کرد.

http://blogs.msdn.com/wndp/archive/2007/07/05/receive-window-auto-tuning-on-vista.aspx

برای اطلاع در مورد Acceleration:

http://shzandi.blogspot.com/2008/12/why-wan-accelerator.html

برای اينکه QoS با موفقيت و بصورت کامل پياده سازی شود، بايد در تمام مسير و End-to-End در تمامی روتر های مسير و Intermediate System ها لحاظ شود. اجرای QoS و روش های پیرامون آن بسيار متنوع است که در زير از انواع آن ميگوييم:

Best Effort Delivery

در واقع شبکه ای که به اين روش کار ميکند فاقد QoS حقيقی است و Packet ها را بصورتی که دريافت ميکند به همان ترتيب ارسال مينمايد. اينترنت از همين روش استفاده ميکند چرا که نمیتوان به پکت ها اولویت داد (نمی توان اطمينان کرد).

Integrated Services Model

به اين روش به اختصار IntServ ميگويند. ايده اصلی در اجرای QoS در اين روش، رزرو کردن يک مسير و پهنای باند کافی برای انتقال ترافيک خاص است (مثل خط ويژه عبور آمبولانس در خيابان ها). برای اجرای اين روش پروتکلی بنام Resource Reservation Protocol در RFC 1633 معرفی و تشريح شده است که به اختصار به آن RSVP ميگويند.

Differentiated Services Model يا DiffServ

روشی است که اطلاعات QoS را بر روی هر بسته منتقل ميکند و برعکس IntServ که Per-Flow کار ميکند اين روش Per-Hop عمليات خود را انجام داده و قابليت رشد بالاتری برای شبکه های بزرگ دارد و از همين رو نيازی به پروتکلی ندارد. به اين گونه پياده سازی Per Hop Behavior (PHB) ميگوئيم.

QoS  و لايه دو

هر فريمی در لايه دو، از لحاظ ارزش و اولويت با بقيه برابر است. در واقع متد Forwarding در اين لايه Best-effort است. اما در زمانی که يک فريم از سوئيچی به سوئيچ ديگر منتقل ميشود روی Trunk از ويژگی خاصی چون IEEE 802.1p می توان بهره برد. درواقع فيلدی وجود دارد که به CoS اشاره ميکند. CoS يا Class of Services اجازه ميدهد که به ازای هر فريم اولويتی از 0 تا 7 تعيين شود.

پس در هر دو مد Trunking چه 802.1q و چه Cisco ISL می توان از سه بيت رزرو شده تحت عنوان CoS استفاده کرد و هر فريم را بر اساس ارزش طبقه بندی شده و اولويت Forward کرد.

QoS و لايه سه

در مدل  DiffServ   Classification  يا طبقه بندی توسط DSCP صورت ميگيرد. از بدو تولد IP, فيلدی بنام ToS در هدر در نظر گرفته شده است. ToS يا Type of Services به ميزان يک بايت از دو قسمت تشکيل می شود که سه بيت به IP Precedence و چهار بيت به ToS Value تعلق دارد. سه بيت اول در ToS به نوع و جنس سرويس منتقل شده توسط IP اشاره ميکند که کاربرد اين روش محدود است. در عوض در مدل DiffServ از يک بايت ToS در هدر IP تحت عنوان Differentiated Service Code Point يا DSCP استفاده ميشود که سه بيت برای انتخاب Class و سه بيت برای اولويت در Drop شدن وجود دارد.

Class Selector يا انتخاب کلاس از 0 تا 7 (000 تا 111) و Drop Precedence از 1:Low، 2:Medium و 3:High تشکيل شده اند.

کلاس صفر هميشه به Best-effort اشاره دارد در حاليکه کلاس 1 تا 4 بعنوانAssured Forwarding (AF) به ترتيب اولويت، کلاس 5 بعنوان Expedited Forwarding (EF) برای کاربردهای حساس در برابر تاخير (مثل Voice) و کلاس های 6 و 7 به ترتيب Internetwork Control و Network Control هستند.

بيت های DS به صورتی در ToS جای ميگيرند که با IP Precedence برای دستگاه هايی که DiffServ نميدانند Backward Compatible  باشند.

AF-21( 18 ) = 010,010 = Class 2 (010) + Drop Precedence (01) Low

جدول زير، ارتباط بيت هایDSCP با IP Precedence و ترتيب MAP شدن آنها را مشخص ميکند:

در اين پروژه از دستگاه های Cisco ACE برای Load-balancing و ASA های Redundant برای امنيت و IPS برای جلوگيری و ثبت حمله ها استفاده کرديم. سوئيچ های Datacenter از سری 4900-10G است که سيسکو برای Datacenter ها طراحی کرده و از تکنولوژی Catalyst IOS استفاده ميکند. دسترسی به اينترنت با کمک BGP و اتصال به دو سرويس دهنده از طريق فيبر و از دو مسير مختلف برقرار شده است. برای اتصال به دفاتر ديگر و Partner ها از دو 3845 استفاده کرديم تا به شبکه MPLS متصل شوند.

برای اطلاعات بيشتر:

a Datacenter Design (in Persian – PDF) 619KB

WCCP يا Web Cache Communication Protocol

مصارف گوناگونی در شبکه های Content Delivery دارد و ده سالی از معرفی آن ميگذرد.

قبل از معرفی WCCP؛ يک Cache Server بصورت inline در شبکه قرار مي گرفت (يعنی برای اينکه بسته های Web از Cache Server عبور کنند از سرور بعنوان Gateway يا بصورت Bridge بسته های به آن ميفرستاديم و به قولی سر راه اينترنت قرار ميگرفت)

اما با معرفی WCCP اين کار به طور منطقی صورت گرفته و اگر محتويات Packet شامل Web؛ FTP و يا هر چيزی که مربوط به Cache باشد به Cache Server ارسال ميشود. روتر WCCP Client و سرور WCCP Server است.

WCCP Server به روتر ميگويد چه ترافيکی را من ميخواهم Cache کنم پس همان ترافيک را برای من بفرست. WCCP از GRE برای ارسال Packet ها بين روتر و سرور استفاده ميکند که دو مزيت دارد:

1.      بسته ها داخل GRE ارسال شده پس در راه فيلتر يا دوبار Cache نميشوند.

2.      سرور ميتواند در شبکه ديگر يا چند hop دورتر باشد.

با استفاده از WCCP2 ميتوان چند سرور داشت و آن ها را بصورت يک cluster به چند روتر نسبت دارد و بدين صورت Redundancy و Efficiency (کارايي) بيشتری در سايزهای بزرگتر فراهم ميشود.

Cache Server هايي مثل SQUID نيز قابليت WCCP را دارند و برای WCCP2 نيز برنامه های Patch وجود دارد. استفاده از WCCP به Cache Server ها محدود نميشود و برای WAN Acceleration مثل ACE و WAAS؛ همچنين برای فيلترينگ و Streaming و WEB Acceleration و … در شبکه های گسترده استفاده ميگردد (نظير پخش المپيک 2008 که توسط Cisco و NBC ارائه شد.)

برای تنظيم WCCP کافيست ترافيک را در زمان ورود به روتر يا خروج از روتر به سمت سرور بفرستيم مثال زير ترافيک ورودی از Gig0/0 را به سرور ميفرستد (بخش ارتباط با روتر در سرور تنظيم ميشود) :

ip wccp 99

!

interface GigabitEthernet0/0

ip address 10.10.10.1 255.255.255.0

ip wccp 99 redirect in

!

و يا در زمان خروج از روتر:

ip wccp 99

!

interface Serial0/0

ip address 11.11.11.2 255.255.255.252

ip wccp 99 redirect out

Router#debug ip wccp packets

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003532

WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003534

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003533

WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003535

TOS يا Type of Service مشخص کننده ارزش و اهميت ديتا داخل IP است. اين TOS برای ترافيک Telnet قابل تغيير است.