مسیریابی بر اساس پارامترهای کیفی شبکه همواره یکی از چالش های اصلی شبکه های IP بوده است و تاکنون نیز راه حل جامع و کاملی که بتوان در شبکه های IP از آن استفاده کرد، توسعه داده نشده است. پروتکل مسیریابی EIGRP با قراردادن پارامترهای کیفی Load و Reliability گام اول را در محقق ساختن این هدف برداشت اما متاسفانه هیچگاه عملیاتی نشد. کمپانی سیسکو در سالهای اخیر با معرفی تکنولوژی به نام pfr گام خوبی در این راه برداشته است که پیشنهاد می شود حتما مطالعه ای داشته باشید.

در این بخش قصد داریم ابزاری که سیسکو صرفا برای اندازه گیری کیفیت شبکه بین دو نقطه اختراع کرده است را معرفی نماییم. خروجی این ابزار قابل بکارگیری در مسیریابی Static و همچنین مسیریابی PBR است و بنابراین می توان در شرایطی محدود با توجه به کیفیت شبکه مسیر ترافیک را تغییر داد. از این روش نمی توان همواره استفاده نمود زیرا قابل بکارگیری در پروتکل های مسیریابی نیست. این ابزار عمدتا در روتر لبه سازمانهایی که با بیش از یک مسیر به اینترنت و یا دیگر دفاتر سازمان متصل هستند، استفاده می شود.

ابزار IP SLA قادر است با توجه به کاربرد، ترافیک ارسال نموده و پارامترهای کیفی مختلفی را اندازه گیری نماید. به عنوان مثال در دسترسی اینترنت اگر صرفا در دسترس بودن اینترنت برای کاربر اهمیت دارد، IP SLA به صورت دوره ای ترافیک ICMP ارسال می کند و در صورت دریافت پاسخ، در دسترس بودن اینرنت را تایید می کند. اما گاهی مقدار تاخیر ترافیک و یا زمان رفت و برگشت ترافیک نیز برای کاربر اهمیت دارد. در چنین شرایطی نوع ترافیک ارسالی و همچنین پارامترهای اندازه گیری کیفیت ارتباط با توجه به کاربرد تعیین می گردد.

برای کاربردهای Voice و Vodeo میزان delay و jitter بسیار با اهمیت است. کاربرد هایی نیز وجود دارند که میزان Loss و یا حتی ترتیب رسیدن ترافیک به مقصد اهمیت دارد. ابزار IP SLA قادر است کیفیت ارتباط بین دو نقطه یا بین روتر سازمان و اینترنت را با توجه به هر یک از پارامترهای زیر اندازه گیری نماید.

  • تاخیر یکطرفه و دو طرفه
  • مقدار Jitter
  • میزان Loss
  • ترتیب ترافیک
  • وجود یا عدم وجود ارتباط (دسترس پذیری ارتباط)
  • زمان دانلود از سرور و یا وب سایت
  • و دیگر پارامترهای کیفیتی ارتباط شبکه

شیوه عملکرد IP SLA بدین صورت است که روتری که IP SLA روی آن فعال است، به صورت دوره ای ترافیک های خاصی را با توجه به نوع کاربرد به مقصد مورد نظر شما ارسال می کند و پارامترهای کیفیت شبکه را با توجه به نیاز کاربرد اندازه گیری می کند. برای اندازه گیری پارامترهای کیفیت شبکه گاهی لازم است تا IP SLA در دو طرف ارتباط فعال گردد. به عنوان مثال اگر قصد دارید صرفا در دسترس بودن مقصد را چک کنید، روتر به صورت دوره ای ترافیک ICMP ECHO ارسال می کند و در صورتی که پاسخ دریافت شود، نشان دهنده در دسترس بودن مقصد است. در چنین شرایطی فعال کردن IP SLA در هر دو طرف ارتباط ضرورتی ندارد زیرا همه دستگاههای متصل به شبکه IP پاسخ ICMP Echo را ارسال می کنند. اما اگر قصد دارید میزان تاخیر Voice را اندازه گیری کنید، روتر ترافیک Voice را شبیه سازی کرده و به صورت دوره ای ارسال می کند اما در چنین شرایطی در طرف مقابل ارتباط باید IP SLA Responder را فعال نمایید تا بتواند پاسخ Voice شما را ارسال نماید و شما با توجه به زمان رفت و برگشت مقدار تاخیر را محاسبه نمایید.

شکل زیر بیانگر عملکرد ابزار IP SLA است. روی روتر های سمت چپ IP SLA فعال شده است که IP SLA source نام گرفته است. در سمت راست شکل دو شعبه وجود دارد که روی یکی از آنها IP SLA responder فعال شده است و دیگری نیاز به responder نداشته است. حال روتر های سمت چپ به صورت دوره ای ترافیک هایی را به شعبه ها ارسال می کند. نوع ترافیک ارسالی به شعبه ای که SLA responder روی آن فعال نیست، معمولا از نوع ICMP است که هر دستگاهی قادر به پاسخ گویی است. البته ممکن است ترافیک های ارسالی از نوع TCP و روی پورتی باشد که مقصد به صورت معمول به آن گوش و پاسخ می دهد. مثلا اگر مقصد، وب سرور باشد درخواست های TCP روی پروت 80 به صورت دوره ای به آن ارسال می گردد. اما ترافیک های ارسالی به دیگر شعبه که SLA responder روی آن فعال است، با توجه به نوع responder فعال شده، ارسال می گردد. مثلا اگر بخواهیم ترافیک UDP با شماره پورت 5000  ارسال کنیم، روی روتر responder نیز این مشخصات را از قبل تنظیم می نماییم تا قادر به پاسخگویی باشد.

نکته دیگری که در شکل نیز نشان داده شده است اینکه خروجی پارامترهای کیفیتی IP SLA قابل انتقال توسط SNMP است و بنابراین نرم افزارهای مانیتورینگ که وضعیت شبکه را مانیتور می کنند، با توجه به خروجی IP SLA گراف هایی که وضعیت کیفی ارتباط را نشان می دهد به شما ارائه خواهند داد.

01 مکانیزم IP SLA

 مکانیزم IP SLA

برای پیاده سازی IP SLA اقدامات زیر صورت می گیرد.

  • 1- فعال نمودن IP SLA responder در طرف مقصد (در صورت لزوم)
  • 2- فعال نمودن IP SLA در طرف مبداء و تعیین نوع ترافیک ارسالی
  • 3- تعیین پارامترهای نوع ترافیک ارسالی (مثلا آدرس مبدا، شماره پورت مقصد و ...)
  • 4- تعیین مقادیر threshold قابل قبول با توجه به نوع پارامتر در حال اندازه گیری (حداکثر زمان قابل قبول رفت و برگشت، حداکثر میزان Loss قابل تحمل و ...) در صورت لزوم
  • 5- زمانبندی ارسال ترافیک و اندازه گیری پارارمترهای کیفیت ارتباط
  • 6- مانیتور و تحلیل نتایج با ابزار command و SNMP
  • 7- مانیتورینگ خروجی IP SLA با ابزار track
  • 8- تغییر مسیر ترافیک در صورت مناسب نبودن کیفیت ارتباط

برای درک بهتر گام های فوق به مثال زیر توجه کنید که در آن دو روتر از طریق شبکه Ethernet به یکدیگر متصل هستند. یکی از روترها نقش SLA source و دیگری نقش SLA responder دارد. قصد داریم یک به یک گام های فوق را روی این سناریوی بسیار ساده پیاده سازی نماییم.

02 سناریوی نمونه جهت پیاده سازی IP SLA

سناریوی نمونه جهت پیاده سازی IP SLA

گام اول: فعال نمودن IP SLA responder در طرف مقصد (در صورت لزوم)

اولین گام در راه اندازی IP SLA که لزوما ضروری نیز نیست، فعال نمودن SLA responder در طرف دوم ارتباط است. اگر قصد داریم با ارسال ترافیک ICMP و یا ترافیک TCP روی پورتی که مقصد به آن گوش می دهد، پارامترهای کیفی شبکه را اندازه بگیریم معمولا نیازی به راه اندازی SLA responder نیست، در غیر این صورت نیاز است تا SLA responder فعال گردد. مثلا وقتی قصد داریم با ارسال ترافیک UDP و شبیه سازی ترافیک Voice کیفیت شبکه را اندازه گیری نماییم

 

!!! SLA responder

!

ip sla responder {tcp-connect | udp-echo} ipaddress ip-address port port-number

!!! برای شبیه سازی TCP Server از دستور tcp-connect استفاده می کنیم

!!! برای فعال سازی responder برای ترافیک های UDP echo و UDP jitter از دستور udp-echo استفاده کنید

!!! آدرس IP و شماره پورت، آدرس و پورتی است که responder به آن گوش می دهد

!

!!! برای این مثال از دستورات زیر در SLA responder استفاده شده است

!

ip sla responder

ip sla responder udp-echo ipaddress 192.168.1.2 port 5000

!

گام اول: فعال سازی IP SLA Responder

گام دوم: فعال نمودن IP SLA در طرف مبداء (SLA operation) و تعیین نوع ترافیک ارسالی

در گام دوم باید در طرف مبدا IP SLA را فعال نماییم و همچنین نوع ترافیکی که قرار است به سمت مقصد ارسال شود را با توجه به نوع پارامتری که قرار است کیفیت آن را اندازه بگیریم، تعیین نماییم. در ذیل نشان داده شده است که ارسال انواع ترافیک امکان پذیر است. ارسال ترافیک dns، dhcp، ftp، http، icmp-echo، icmp-jitter، tcp-connect، udp-jitter وudp-echo بعضی از انواع operation هایی که در طرف مبدا قابل پیاده سازی است. به عنوان مثال هر دو icmp-echo و icmp-jitter بسته icmp تولید می کنند اما هدف یکی تست دسترس پذیری مقصد است اما هدف دیگری اندازه گیری مقدار jitter بین مبدا و مقصد است. ترافیک های udp-echo و udp-jitter نیز همین هدف را برای ترافیک های Voice و Video به عهده دارند. وظیفه اکثر operation هایی که در طرف مبدا قابل پیاده سازی هستند، از نام آنها پیداست.

 

 !!! SLA source

!

SLA_SOURCE(config)#ip sla 10

SLA_SOURCE(config-ip-sla)#?

IP SLAs entry configuration commands:

  dhcp         DHCP Operation

  dns          DNS Query Operation

  exit         Exit Operation Configuration

  frame-relay  Frame-relay Operation

  ftp          FTP Operation

  http         HTTP Operation

  icmp-echo    ICMP Echo Operation

  icmp-jitter  ICMP Jitter Operation

  mpls         MPLS Operation

  path-echo    Path Discovered ICMP Echo Operation

  path-jitter  Path Discovered ICMP Jitter Operation

  tcp-connect  TCP Connect Operation

  udp-echo     UDP Echo Operation

  udp-jitter   UDP Jitter Operation

  voip         Voice Over IP Operation

!!! برای این مثال از دستور زیر در SLA source استفاده شده است

!

ip sla 10

 udp-echo 192.168.1.2 5000

!

گام دوم: فعال سازی IP SLA Source Operation

گام سوم: تعیین پارامترهای نوع ترافیک ارسالی (مثلا آدرس مبدا، شماره پورت مقصد و ...)

در گام سوم جزئیات ترافیک ارسالی را تعیین می کنید. به عنوان مثال آدرس IP و پورت مبدا ترافیک، تعداد ترافیک های ارسالی، فواصل زمانی بین ترافیک ارسالی بعضی از مشخصاتی هستند که در این بخش قابل تعیین هستند. در ذیل برای دو نوع ترافیک udp-echo و udp-jitter پارارمترهای قابل تنظیم ترافیک نشان داده شده است. همانطور که مشاهده می کنید برای ترافیک udp-echo آدرس IP و پورت مبدا و همچنین ارسال و یا عدم ارسال ترافیک های کنترلی، پارارمترهای قابل تنظیم هستند. اما در ترافیک های udp-jitter پارارمترهای بیشتری قابل دستکاری می باشند. به عنوان مثال تعداد بسته های ارسالی و فاصله زمانی بین بسته های متوالی بعضی از موارد قابل پیکربندی هستند. در ادامه نیز وارد محیط udp-echo شده و مجددا ? وارد نموده ایم. مواردی مانند الگوی داده، سایز داده ارسالی و همچنین فرکانس ارسال ترافیک نیز در این محیط قابل تنظیم هستند.

 

 !!! SLA source

!

SLA_SOURCE(config-ip-sla)#udp-echo 192.168.1.2 5000 ?

control      Enable or disable control packets

  source-ip    Source address

  source-port  Source Port

!

SLA_SOURCE(config-ip-sla)#udp-jitter 192.168.1.2 5000 ?

  codec        codec type to be configured

  control      Enable or disable control packets

  interval     Inter Packet Interval

  num-packets  Number of Packets to be transmitted

  source-ip    Source address

  source-port  Source Port

  <cr>

!

SLA_SOURCE(config-ip-sla-udp)#?

IP SLAs udpEcho configuration commands:

  data-pattern           Data Pattern

  default                     Set a command to its defaults

  dest-ipaddr             Destination ip address

  dest-port                 Destination port

  exit                           Exit operation configuration

  frequency               Frequency of an operation

  history                     History and Distribution Data

  no                             Negate a command or set its defaults

  owner                      Owner of Entry

  request-data-size  Request data size

  tag                           User defined tag

  threshold               Operation threshold in milliseconds

  timeout                  Timeout of an operation

  tos                           Type Of Service

  verify-data             Verify data

  vrf                           Configure IP SLAs for a VPN Routing/Forwarding instance

!

!!! برای این مثال مقدار frequency 10 ثانیه در نظر گرفته شده است. بدین معنی که هر 10 ثانیه یک بار بسته udp-echo ارسال گردد

ip sla 10

 udp-echo 192.168.1.2 5000

 frequency 10

!

گام سوم: تعیین پارامترهای ترافیک ارسالی تعریف شده در SLA Operation

گام چهارم: تعیین مقادیر threshold با توجه به نوع پارامتر در حال اندازه گیری (حداکثر زمان قابل قبول رفت و برگشت، حداکثر میزان Loss قابل تحمل و ...) در صورت لزوم

ابزار IP SLA قابلیت مانیتورینگ سطوح آستانه برای انواع مولفه های قابل مانیتورینگ و همچنین ارسال پیغام های هشداردهنده را داراست. مولفه هایی همچون میانگین jitter، تاخیر یکطرفه، زمان رفت و برگشت، میزان Loss و کیفیت Voice در این ابزار قابل اندازه گیری هستند. در صورتی که سطوح آستانه بالاتر و یا پایین تر از محدوده قابل قبول قرار گیرد، پیغام های هشدار دهنده در قالب syslog و یا SNMP ارسال می گردد.

برای مانیتورینگ کیفیت ارتباط با توجه به سطوح آستانه و ارسال پیغام های هشداردهنده از دستور ip sla reaction-configuration در محیط global استفاده می شود.

 !!! SLA source

!

ip sla reaction-configuration operation-number react monitored-element [action-type option] [threshold-type {average [number-of-measurements] |consecutive [occurrences] | immediate | never | xofy [x-value y-value]}] [threshold-value upper-threshold lower-threshold]

!

!!! operation-number شماره IP SLA ایجاد شده در SLA_SOURCE را مشخص می کند

!!!  monitored-element مولفه ای را مشخص می کند که قصد مانیتور کردن آن را دارید. حدود 30 مولفه قابل مانیتوریگ وجود دارد. packet loss، delay، jitter ، mos بعضی از این مولفه های هستند.

!!! action-type عملی را نشان می دهد که IP SLA در صورت مشاهده سطوح آستانه انجام خواهد داد. None، trapOnly، triggerOnly و trapAndTrigger بعضی از انواع action ها هستند.

!!! threshold-type average number-of-measurements تعداد دفعاتی را نشان می دهد که میانگین مولفه های مانیتور شده روی آن محاسبه می شود.

!!! threshold-type consecutive occurrences تعداد دفعاتی را اگر به صورت متوالی از محدوده آستانه تخطی شود، عمل معرفی شده انجام خواهد شد

!!! در صورت ورود threshold-type immediate به محض مشاهده تخطی از سطوح آستانه عکس العمل نشان داده خواهد شد

!!! upper-threshold و lower-threshold مقادیر بالا و پایین سطوح آستانه را تعیین می کند.

گام چهارم: مانیتورینگ IP SLA و تعریف محدوده سطوح آستانه

 

گام پنجم: زمانبندی ارسال ترافیک و اندازه گیری پارارمترهای کیفیت ارتباط

بعد از فعال سازی IP SLA باید آن را زمانبندی کنید تا در زمانبندی اعلام شده نسبت به جمع آوری اطلاعات آماری و همچنین پیغام های خطا اقدام نماید. زمانبندی هم به صورت نسبی و هم به صورت مطلق امکان پذیر است. مثلا می توانید بگویید از چند ساعت دیگر IP SLA شروع به جمع آوری اطلاعات نماید و تا 3 ماه دیگر به کار خود ادامه دهد و یا آنکه تاریخ دقیق شروع و پایان را مشخص نمایید.

برای پیاده سازی زمانبندی از دستور زیر استفاده می شود که همه گزینه های آن گویاست. 

 !!! SLA source

!

ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

!

!!! برای سناریوی این درس از دستور زیر استفاده شده است که در IP SLA شماره 10 هم اکنون شروع به کار می کند و برای همیشه ادامه خواهد داشت

ip sla schedule 10 start-time now life forever

!

گام پنچم: زمانبندی ارسال ترافیک تعریف شده در SLA Operation

گام ششم: مانیتور و تحلیل نتایج با ابزار command و SNMP

برای مانیتور کردن و تحلیل نتایج به صورت command معمولا از دو دستور ip sla configuration و ip sla statistics استفاده می شود.  در مثال این کتاب خروجی دو دستور فوق در ذیل نشان داده شده است. در خروجی دستور show ip sla configuration تنظیمات انجام شده و مقادیر پیش فرض نشان داده شده است. به عنوان شماره sla، نوع و مشخصات بسته ارسالی، زمانبندی ارسال در این خروجی قابل مشاهده است که قبلا تنظیم شده اند اما مقادیر threshold و timeout به صورت پیش فرض 5 ثانیه هستند. همچنین خروجی دستور show ip sla statistics نشان می دهد که به تعداد 356 بسته از نوع udp-echo قبلا ارسال شده است که همه آنها نوع ارتباط موفق را نشان می دهد و همچنین نشان داده شده است که زمان رفت و برگشت میانگین 237 میلی ثانیه بوده است

 

 !!! SLA source

!

SLA_SOURCE#sh ip sla configuration

IP SLAs Infrastructure Engine-II

Entry number: 10

Owner:

Tag:

Type of operation to perform: udp-echo

Target address/Source address: 192.168.1.2/0.0.0.0

Target port/Source port: 5000/0

Type Of Service parameter: 0x0

Request size (ARR data portion): 16

Operation timeout (milliseconds): 5000

Type Of Service parameters: 0x0

Verify data: No

Data pattern:

Vrf Name:

Control Packets: enabled

Schedule:

   Operation frequency (seconds): 10  (not considered if randomly scheduled)

   Next Scheduled Start Time: Start Time already passed

   Group Scheduled : FALSE

   Randomly Scheduled : FALSE

   Life (seconds): Forever

   Entry Ageout (seconds): never

   Recurring (Starting Everyday): FALSE

   Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 5000 (not considered if react RTT is configured)

Distribution Statistics:

   Number of statistic hours kept: 2

   Number of statistic distribution buckets kept: 1

   Statistic distribution interval (milliseconds): 20

Enhanced History:

History Statistics:

   Number of history Lives kept: 0

   Number of history Buckets kept: 15

   History Filter Type: None

!

!

SLA_SOURCE#sh ip sla statistics

IPSLAs Latest Operation Statistics

IPSLA operation id: 10

Type of operation: udp-echo

        Latest RTT: 237 milliseconds

Latest operation start time: *23:09:47.631 UTC Fri Dec 12 2014

Latest operation return code: OK

Number of successes: 356

Number of failures: 0

Operation time to live: Forever

گام ششم: تحلیل نتایج IP SLA

گام هفتم: مانیتورینگ خروجی IP SLA با ابزار track

گاهی هدف از مانیتورینگ کیفی ارتباطات شبکه صرفا مانیتورینگ است تا بتوان بر اساس خروجی مانیتورینگ، تصمیمات جدیدی در حوزه های فنی و مدیریتی اتخاذ گردد. اما گاهی نیز خروجی مانیتورینگ مستقیما در تغییر مسیر ترافیک تاثیر می گذارد. در دو روش مسیریابی static و PBR امکان تغییر مسیر بر اساس خروجی مانیتورینگ وجود دارد. در حال حاضر پروتکل های مسیریابی قابلیت تغییر مسیر با توجه به خروجی پارامترهای کیفی شبکه را ندارند.

برای اثرگذاری خروجی مانیتورینگ بر مسیرهای static و PBR لازم است تا حتما از ابزاری به نام track استفاده شود. track ابزاری است که خروجی IP SLA را دریافت می کند و در صورت بد بودن کیفیت، مسیر را جابجا می کند. حتما این سوال پیش می اید که چرا IP SLA مستقیما در جابجایی مسیر تاثیر نمی گذارد. شاید اصلی ترین دلیل آن جلوگیری از جابجایی های مکرر مسیر است. بدین معنی که زمانی که کیفیت مسیر در محدوده سطوح آستانه قرار نمی گیرند، track بلافاصله روی مسیر تاثیر نمی گذارد، بلکه اگر چندین بازه زمانی متوالی پایین بودن کیفیت مسیر تایید شود، آنگاه خروجی track به حالت down تغییر می کند و می تواند روی جابجایی مسیر تاثیر بگذارد. همچنین در صورتی که کیفیت مسیر به حالت نرمال بازگردد، track بلافاصله نسبت به بازگرداندن مسیر اقدام نمی کند بلکه باید چندین بازه زمانی متوالی خروجی IP SLA نرمال بودن کیفیت مسیر را تایید کند. در این صورت خروجی track به حالت up باز می گردد که در نتیجه روی بازگرداندن مسیر تاثیر خواهد داشت.

البته دلیل فوق تنها دلیل استفاده از track نیست. track این قابلیت را دارد که اولا خروجی های دیگری را نیز علا.ه بر IP SLA چک نماید. به عنوان مثال وضعیت اینترفیس در لایه 2 و 3 و همچنین وجود و یا عدم وجود یک مسیر خاص در جدول مسیریابی بعضی از مواردی هستند که track قادر به چک کردن است تا چنانچه خروجی مطابق خواسته ما نباشد، به حالت down در آید. علاوه بر آن track این قابلیت را دارد تا بتواند بر اساس یک رابطه منطقی (AND, OR and NOT) بین خروجی چندین مولفه تصمیم به up و یا down کردن خود نماید که در این صورت انعظاف پذیری در تصمیم گیری را افزایش می دهد.

در ذیل گزینه های دستور track نشان داده شده است. در خروجی دستور track 1 ?، track 1 ip ? و همچنین track 1 list boolean نشان داده شده است که قابلیت track کردن اینترفیس، IP SLA، مسیر در جدول مسیریابی و همچنین ایجاد track های منطقی برای مانیتور کردن چندین مولفه قابل مانیتورینگ امکان پذیر است.

 

 !!! SLA source

!

SLA_SOURCE(config)#track 1 ?

  application  Application

  interface    Select an interface to track

  ip           IP protocol

  list         Group objects in a list

  stub-object  Stub tracking object

!

SLA_SOURCE(config)#track 1 ip ?

  route  IP route

  sla    IP Service Level Agreement

!

SLA_SOURCE(config)#track 1 ip sla ?

  <1-2147483647>  Entry number

!

SLA_SOURCE(config)#track 1 list boolean ?

  and  Boolean AND operation on list

  or   Boolean OR operation on list

کاربردهای ابزار track

برای مثال مربوط به این بخش track ای نوشته می شود که IP SLA 10 را مانیتور نماید. جزئیات پیاده سازی آن در ذیل آمده است. هدف track شماره 1 مانیتور کردن ip sla شماره 10  است. در صورتی که IP SLA برای 6 بازه متوالی (60 ثانیه) به وضعیت قطعی و یا خارج از محدوده سطوح قابل قبول آستانه برسد، به حالت down تغییر می نماید. همچنین اگر برای 6 بازه متوالی خروجی IP SLA به حالت نرمال بازگردد، خروجی track به وضعیت up تغییر می کند.

برای درک بهتر عملکرد track ، خروجی دستور show track 1 در روتر SLA_SOURCE نشان داده شده است. خروجی پیکربندی انجام شده را تایید می نماید. در ادامه در روتر SLA_RESPONDER اینترفیس ارتباطی به حالت shutdown تغییر داده شده است. بعد از 4 ثانیه مجدد دستور show track 1 روی روتر SLA_SOURCE نشان داده شده است. همچنان وضعیت track در حالت up قرار داد. اما نشان داده شده است که در 56 ثانیه آینده اگر وضعیت در شرایط فعلی باقی بماند، خروجی track به down تغییر می کند.

 

 !!! SLA source

!

track 1 ip sla 10 reachability

 delay down 60 up 60

!

SLA_SOURCE#sh track 1

Track 1

  IP SLA 10 reachability

  Reachability is Up

    1 change, last change 00:04:06

  Delay up 60 secs, down 60 secs

  Latest operation return code: OK

  Latest RTT (millisecs) 200

!

!!!

SLA_RESPONDER(config-if)#shutdown

!

!!!

SLA_SOURCE#sh track 1

Track 1

  IP SLA 10 reachability

  Reachability is Up, delayed Down (56 secs remaining)

    1 change, last change 00:05:14

  Delay up 60 secs, down 60 secs

  Latest operation return code: OK

  Latest RTT (millisecs) 201

گام هفتم: کاربرد ابزار track در مانیتور کردن خروجی IP SLA

هدف از مطالب این بخش صرفا track کردن IP SLA است اما برای آنکه عملکرد track را بهتر درک کنیم، در ذیل مثال دیگری از track نشان داده شده است که در آن یک مسیر در جدول مسیریابی track شده است. برای اینکار ابتدا یک مسیر default در جدول مسیریابی ایجاد می کنیم. سپس track شماره 2 مسیر default را track می کند و چنانچه به مدت 10 ثانیه مسیر default از جدول مسیریابی به هر دلیلی حذف گردد، track به حالت down تغییر خواهد کرد. در ادامه خروجی show track 2 نشان داده شده است که وجود مسیر default در جدول مسیریابی را تایید می کند. سپس به صورت دستی مسیر default را از جدول مسیریابی پاک می کنیم. مشاهده مجدد خروجی show track 2 نشان می دهد که هم اکنون مسیر مورد نظر در جدول مسیریابی وجود ندارد و اگر در 4 ثانیه آینده همچنان در جدول مسیریابی وجود نداشته باشد، track در حالت down قرار می گیرد. در 4 ثانیه بعدی نیز در صفحه کنسول پیغامی مبنی بر down شدن track  ظاهر شده است.

 

ip route 0.0.0.0 0.0.0.0 192.168.1.2

!

track 2 ip route 0.0.0.0 0.0.0.0 reachability

 delay down 10 up 10

!

SLA_SOURCE#sh track 2

Track 2

  IP route 0.0.0.0 0.0.0.0 reachability

  Reachability is Up (static)

    2 changes, last change 00:00:03

  Delay up 10 secs, down 10 secs

  First-hop interface is FastEthernet0/0

!

no ip route 0.0.0.0 0.0.0.0 192.168.1.2

!

SLA_SOURCE#sh track 2

Track 2

  IP route 0.0.0.0 0.0.0.0 reachability

  Reachability is Up (static), delayed Down (4 secs remaining) (no route)

    2 changes, last change 00:01:25

  Delay up 10 secs, down 10 secs

  First-hop interface is FastEthernet0/0 (was unknown)

!

*Dec 13 00:37:36.355: %TRACKING-5-STATE: 2 ip route 0.0.0.0/0 reachability Up->Down

کاربرد ابزار track در مانیتور کردن مسیر های جدول مسیریابی

به عنوان یک مثال پایانی نیز دو track 3 و track 4 ایجاد شده است که هر کدام جداگانه track های شماره 1 و 2 را چک می کنند و با توجه به رابطه منطقی بین نتایج track 1 و track 2 تصمیم به down و یا up کردن track 3 و track 4 می گیرند. Track 3 وقتی up می شود که track 1 در وضعیت up باشد و یا آنکه track 2 در حالت down باشد. همچنین track 4 وقتی up خواهد بود که track 1 در وضعیت down باشد و track 2 نیز در وضعیت up قرار بگیرد.

 

!

track 3 list boolean or

 object 1

 object 2 not

!

track 4 list boolean and

 object 1 not

 object 2

کاربرد ابزار track در مانیتور کردن چندین مولفه به صورت همزمان

گام هشتم: تغییر مسیر ترافیک در صورت مناسب نبودن کیفیت ارتباط

قبلا نیز گفته شده است که خروجی IP SLA می تواند در تعیین و تغییر مسیر ترافیک تاثیر بگذارد البته مشروط بر آنکه روش مسیریابی static و یا PBR باشد. اکثر سازمانها امروزه برای ارسال ترافیک اینترنت از مسیر default که به صورت static وارد می شود، استفاده می کنند. بنابراین به نظر می آید که یکی از کاربردهای مهم تغییر مسیر بر اساس خروجی IP SLA در ترافیک اینترنت است. سازمانهایی که بیش از یک لینک اینترنت دارند، می توانند ترافیک را با توجه به خروجی کیفیت هر یک از لینک های اینترنت تقسیم نمایند.

شکل زیر شکلی است که در بخش PBR مورد بررسی قرار گرفته است. در آن بخش از روی gateway سازمان دو نوع ترافیک به مقصد اینترنت تولید کرده ایم. بخشی از ترافیک ها با مبدا 1.1.1.1 و بخش دیگر با مبدا 2.2.2.2  تولید شده است. با ابزار PBR روتر GW را مجبور کردیم تا ترافیک با مبدا 1.1.1.1 را روی اینترنت اول و ترافیک با مبدا 2.2.2.2 را روی اینترنت دوم ارسال نماید. چگونگی جزئیات شکل نیز در همان بخش تشریح شده است. پیشنهاد می کنم قبل از مطالعه این بخش از کتاب، حتما یکبار دیگر بخش PBR را مطالعه نمایید.

در اینجا قصد داریم چه کاری انجام دهیم؟ همانطور که در شکل زیر مشاهده می کنید دو مبدا جدید یکی با آدرس 192.168.1.10 و دیگری به آدرس 192.168.1.20 در داخل LAN و پشت روتر GW اضافه شده است. در این بخش قصد داریم به ترتیب دو تست زیر را انجام دهیم.

  • 1- روی روتر GW دو مسیر default به روش static به سمت دو اینترنت ایجاد می گردد. ترافیک اینترنت کاربران بین دو مسیر تقسیم می شود. با توجه به الگوریتم load-sharing که به صورت پیش فرض روی روتر GW وجود دارد، ترافیک یکی از مبدا ها روی اینترنت اول و ترافیک دومین مبداء روی اینترنت دوم ارسال می گردد (اینکه ترافیک کدام نود روی کدام اینترنت قرار گیرد به الگوریتم load-sharing وابسته است). کار از اینجا آغاز می گردد. روی روتر GW دو IP SLA می نویسیم. یکی از آنها به صورت دوره ای ترافیک با مبدا 1.1.1 به مقصد اینترنت تولید می کند. دومین IP SLA نیز ترافیک دوره ای به مبدا 2.2.2.2 بهمقصد اینترنت تولید می کند. فراموش نشود که قبلا با ابزار PBR روتر GW را مجبور کردیم تا ترافیک های اینترنت با مبدا 1.1.1.1 را از روی اینترنت اول و ترافیک های اینترنت با مبدا 2.2.2.2 را از روی اینترنت دوم ارسال کند. بنابراین هدف از ایجاد دو IP SLA فوق این است که قطعی و یا وصلی دو ارتباط اینترنت را به صورت دوره ای چک نماید. حال اگر هر یک از اینترنت ها قطع شود، خروجی IP SLA قطعی را نشان خواهد داد. سپس هر یک از مسیرهای default تعریف شده در روتر GW را با کمک ابزار track به یکی از IP SLA ها متصل می کنیم که در صورت قطعی هر یک از اینترنت ها مسیر default آن نیز از روی روتر GW به صورت اتوماتیک پاک شود. پاک شدن هر یک از مسیر های default، ترافیک را به صورت اتوماتیک به اینترنت دوم منتقل خواهد نمود. بنابراین در این تست قصد داریم نشان دهیم که چگونه IP SLA می تواند در تغییر مسیر های static نقش موثری داشته باشد. جزئیات پیاده سوازی آن در ادامه شرح داده خواهد شد.
  • 2- در تست دوم روی روتر GW از روش PBR برای مسیریابی ترافیک اینترنت استفاده شده است. بدین معنی که روی اینترفیس LAN روتر GW، مسیریابی ترافیک به اینترنت بر اساس PBR انجام شده است تا ترافیک اینترنت از مبداء اول از مسیر اینترنت اول و ترافیک اینترنت از مبدا دوم از مسیر اینترنت دوم ارسال گردد. از طرفی همانند سناریوی قبل، IP SLA به صورت موازی مشغول تست کردن دو اینترنت است. قطع شدن هر یک از اینترنت ها منجر به پاک شدن خط مربوطه از مسیریابی PBR خواهد شد و ترافیک از PBR خارج شده و با جدول مسیریابی ارسال خواهد شد. در جدول مسیریابی نیز مسیرهای static همچنان وجود دارند و به خروجی IP SLA وصل هستند. بنابراین قطع شدن هر یک از اینترنت ها ترافیک را به صورت اتوماتیک به اینترنت دوم ارسال خواهد نمود. هدف از اجرای تست دوم نشان دادن تاثیر خروجی IP SLA بر مسیریابی PBR است. تفاوت آن نیز با تست اول در این است که در تست بالایی ترافیک های اینترنت توسط الگوریتم load-sharing در روتر GW بین دو اینترنت تقسیم می شود و قطع شدن هر یک از دو اینترنت، ترافیک ها را به صورت اتوماتیک روی مسیر دوم هدایت خواهد نمود اما در این تست سیاست تقسیم ترافیک اینترنت به عهده مدیر شبکه است. در چنین شرایطی نیز قطع شدن هر یک از دو اینترنت ترافیک را به اینترنت دوم هدایت خواهد نمود.

در ادامه جزئیات پیاده سازی هر یک از مثال فوق را به تفصیل مورد بررسی قرار خواهیم داد.

03 شکل مربوط به مثال های ناثیر خروجی IP SLA

شکل مربوط به مثال های تاثیر خروجی IP SLA روی تغییر مسیر ترافیک

نوشتن دیدگاه


تصویر امنیتی
تصویر امنیتی جدید