כיצד פועל פרוטוקול VRRP

FHRP (פרוטוקול יתירות הופ ראשון) היא משפחה של פרוטוקולים שנועדו לספק יתירות שער ברירת מחדל. הרעיון הכללי של פרוטוקולים אלו הוא לשלב מספר נתבים לנתב וירטואלי אחד עם כתובת IP משותפת. כתובת IP זו תוקצה למארחים ככתובת השער המוגדרת כברירת מחדל. יישום חופשי של רעיון זה הוא VRRP (פרוטוקול יתירות נתב וירטואלי). במאמר זה נבחן את היסודות של פרוטוקול VRRP.

נתבי VRRP משולבים לנתב וירטואלי אחד. לכל הנתבים בקבוצה יש כתובת IP וירטואלית משותפת (VIP) ומספר קבוצה משותף או VRID (זיהוי נתב וירטואלי). נתב אחד יכול להיות חבר בכמה קבוצות, שלכל אחת מהן חייב להיות זוג VIP/VRID ייחודי משלה.

במקרה של סיסקו, הנתב הוירטואלי מוגדר על הממשק שאנו מעוניינים בו עם הפקודה:

R1(config-if)# vrrp <group-number> ip <ip-address>

כל הנתבים מחולקים לשני סוגים: VRRP Master ו-VRRP Backup.

מאסטר VRRP הוא נתב שמעביר מנות עבור קבוצה וירטואלית נתונה.

גיבוי VRRP הוא נתב שמצפה לחבילה מהמאסטר. אם מנות מהמאסטר מפסיקות להגיע, גיבוי מנסה לעבור למצב מאסטר.

נתב הופך למאסטר אם יש לו את העדיפות הגבוהה ביותר. המאסטר שולח הודעות ללא הרף לכתובת השידור 224.0.0.18 כדי לומר לנתבי הגיבוי שהוא עובד. מאסטר שולח הודעות לפי טיימר Adver, ששווה לשנייה אחת כברירת מחדל.

במקרה זה, כתובת הקבוצה 00:00:5E:00:01:xx משמשת ככתובת ה-MAC של השולח, כאשר xx הוא ה-VRID בפורמט הקסדצימלי. דוגמה זו משתמשת בקבוצה הראשונה.

אם נתבי גיבוי אינם מקבלים הודעות בתוך שלושה טיימרים של Adver (Master Down Timers), אז הנתב עם העדיפות הגבוהה ביותר או הנתב עם ה-IP הגבוה ביותר הופך ל-Master החדש. במקרה זה, נתב הגיבוי עם עדיפות גבוהה יותר ישתלט על תפקיד המאסטר בעדיפות נמוכה יותר. עם זאת, כאשר מצב ההקדמה של גיבוי מושבת, גיבוי לא ישתלט על התפקיד ממאסטר.

R1(config-if)# no vrrp <group-number> preempt

אם נתב VRRP הוא הבעלים של כתובת VIP, אז הוא תמיד משתלט על תפקיד המאסטר.

עדיפות VRRP מוגדרת בערכים מ-1 עד 254. ערך 0 שמור למקרים שבהם יש צורך במאסטר להמריא לקחת אחריות על הניתוב. הערך 255 מוגדר לנתב שבבעלותו ה-VIP. עדיפות ברירת המחדל היא 100, אך ניתן להגדיר באופן ניהולי:

R1(config-if)#vrrp <group-number> priority <priority 1-254>

כאן אנו יכולים לראות את עדיפות הנתב כאשר היא מוגדרת ניהולית:

והנה מקרה שבו הנתב הוא הבעלים של ה-VIP:

לנתב VRRP יכולים להיות שלושה מצבים: אתחול, גיבוי, מאסטר. הנתב משנה את המצבים האלה ברצף.

במצב אתחול, הנתב ממתין להתחיל בפעולה. אם הנתב הזה הוא הבעלים של כתובת ה-VIP (העדיפות היא 255), אז הנתב שולח הודעות המציינות שהוא הפך למאסטר. הוא גם שולח בקשת ARP ללא תשלום, שבו כתובת ה-MAC המקור שווה לכתובת הנתב הווירטואלי. ואז זה נכנס למצב המאסטר. אם הנתב אינו הבעלים של ה-VIP, אז הוא עובר למצב גיבוי.

במצב גיבוי, הנתב ממתין למנות מהמאסטר. הנתב במצב זה אינו מגיב לבקשות ARP מכתובת ה-VIP. הוא גם אינו מקבל מנות בעלות כתובת ה-MAC של הנתב הוירטואלי ככתובת היעד שלהן.

אם גיבוי לא מקבל הודעה מהמאסטר במהלך טיימר השבתה של המאסטר, הוא שולח הודעת VRRP המציינת שהוא עומד להפוך למאסטר. לאחר מכן שולח הודעת שידור VRRP שבה כתובת ה-MAC המקור שווה לכתובת של נתב וירטואלי זה. בהודעה זו, הנתב מציין את העדיפות שלו.

במצב Master, הנתב מעבד מנות הממוענות לנתב הוירטואלי. הוא גם מגיב לבקשות ARP ל-VIP. המאסטר שולח הודעות VRRP בכל טיימר Adver כדי לאשר שהוא עובד.

*May 13 19:52:18.531: %VRRP-6-STATECHANGE: Et1/0 Grp 1 state Init -> Backup
*May 13 19:52:21.751: %VRRP-6-STATECHANGE: Et1/0 Grp 1 state Backup -> Master

VRRP מאפשר גם איזון עומסים על פני מספר נתבים. לשם כך נוצרות שתי קבוצות VRRP בממשק אחד. קבוצה אחת מקבלת עדיפות גבוהה יותר מהשנייה. במקרה זה, בנתב השני העדיפות נקבעת בצורה הפוכה. הָהֵן. אם בנתב אחד העדיפות של הקבוצה הראשונה היא 100, והקבוצה השנייה היא 200, אז בנתב אחר העדיפות של הקבוצה הראשונה תהיה 200, והשנייה 100.

כאמור, לכל קבוצה חייבת להיות VIP ייחודי משלה. כתוצאה מכך, אנו מקבלים שתי כתובות IP המוגשות על ידי שני נתבים, שכל אחד מהם יכול לשמש כשער ברירת מחדל.

למחצית מהמחשבים מוקצים כתובת שער ברירת מחדל אחת, לחצי כתובת אחרת. כך, מחצית מהתנועה תעבור דרך נתב אחד, וחצי דרך אחר. אם אחד הנתבים נכשל, השני משתלט על העבודה של שני ה-VIPs.

לפיכך, VRRP מאפשר לך לארגן סובלנות תקלות של שער ברירת המחדל, להגביר את האמינות של הרשת. ואם אתה משתמש במספר נתבים וירטואליים, אתה יכול גם לאזן את העומס בין נתבים אמיתיים. ניתן להפחית את מהירות התגובה לכשל על ידי הפחתת הטיימרים.

מקור: www.habr.com