BGP Initial
Configuration Commands:
הגדרת BGP מבוצעת בצורה ידנית
לחלוטין, כל פעולה ב-BGP צריכה להיות מוגדרת, כגון
שכנים ספציפיים וכו.
BGP עובד בפורט 179 באמצעות TCP ולכן הוא גם מוגדר Reliable בגלל ה-ACK של TCP
BGP הוא כמו כל אפליקציה שמשתמשת ב-TCP מה שאומר שבאמצעות TCP הקליינט יוצר את קשרי ה- 3-way-handshake זאת ע"י שליחת פקטת SYN לכיוון לפורט 179, במידה וקיים נתב בקצה
השני שמוגדר לקבל את BGP הוא עונה עם SYN/ACK
לכיוון הפורט שממנו הוא התקבל.
במידה ושני השכנים מנסים להקים קשרי שכנות באותו זמן ישנו כלי
עפ"י RFC 4271 אשר תפקידו הוא לגלות Collision
באמצעות ה-BGP RID ובכך הוא יודע את איזה
הודעת Hello להשאיר ולאיזו לעשות DROP.
הגדרת קשרי שכנות ב-BGP:
router
bgp xxx
neighbor x.x.x.x remote-as xxx
ניתן לוודא שהשכנים אחר הוקמו על ידי פקודת:
במידה ואנחנו רואים Prefix ולא ACTIVE/IDLE משמש קשרי השכנות הוקמו
(המספר מעיד על כמות הניתובים שקיבלנו מאותו שכן).
exec
show ip bgp summary
הערה חשובה!!
ה-TTL עבור Sessions
שיוצאים הוא 255 בקשרי IBGP,
ו-IBGP לא חייבים להיות DC
כל עוד ה-IGP
מחבר בינהם ויודע להגיע משכן לשכן.
לעומת זאת EBGP Sessions יוצאים עם TTL שווה ל-1 כברירת מחדל מה שאומר לנו ששכנים
חייבים להיות מחוברים ישירות אחד לשני.
כמו כן ניתן לצפות בניתובים שהתקבלו וזאת באמצעות פקודה:
exec
show ip bgp
חשוב מאוד לשים לב לשורת ה-NEXT-HOP .
שים לב שהשדה הזה הוא מכיל את הכתובת של השכן שממנו נלמד הניתוב.
אם ניקח לדוגמא את הרשת 150.1.7.0
דרך
הכתובת 155.1.67.7, על מנת להגיע לניתוב
הנ"ל צריך לבצע Recursive Lookup (חיפוש חוזר) על כתובת
השכן (Next-Hop) עד שנמצא ממשק תואם
שדרכו אפשר לצאת.
ניתוב לא יכול להחשב כ-BEST במידה ואין אפשרות יציאה
לכיוון ה-NEXT HOP .
BGP Update Source:
כיוון ש-BGP משתמש ב-TCP לטובת העברת המידע, לכן אין צורך בכך
שהשכנים יהיו DC.
מה שמאפשר לנו להגדיר ממשקים וירטואליים – כגון Loopbackים כממשק
היציאה של קשרי השכנות.
מה שקורה בעצם הוא מצב שבו קשרי השכנות לא עולים כיוון שאנחנו מגדירים
אותם לעבוד עם Loopback וה-BGP מוציא את הודעת ה-TCP עם Source IP הלא נכון.
ניתן להשתמש בפקודה על מנת לעדכן את הכתובת שאיתה אנחנו רוצים להקים
את קשרי השכנות:
router
bgp xxx
neighbor xxx update-source
טיפ יעיל!
ניתן להגדיר ACL אשר תוחם את כתובת המקור וכל יעד כמו בדוגמא הנ"ל ולבצע Debug IP Packet ל-TCP רק עם הכתובות הללו ובכך בעצם לפלטר את הנתונים ולא להציף את כל
הנתב בנתונים.
דוגמא:
global
access-list 100 permit tcp any host 150.1.4.4
access-list 100 permit tcp host 150.1.4.4 any
exec
debug ip packet detail 100
מה שחשוב לזכור בעדכון הכתובת מקור ב-BGP הוא שה-TCP Server של ה-BGP חייב לאשר מהיכן ה-Session מגיע.
אם ה-SYN מגיע מכתובת שאינה מוגדרת
כשכן ה-Connection Refuse.
BGP
Multihop Peering:
כפי שציינו קודם לכן, כברירת מחדל חיבורי EBGP יוצאים עם TTL של 1 מה שאומר לנו שחיבורים לא ישירים (Non-DC) אינם יכולים להתקיים כיוון שנקבל הודעת "TTL Expire in transit"
לכן אנחנו צריכים להוסיף את הפקודה תחת השכן:
router
bgp xxx
neighbor x.x.x.x ebgp-multihop 10
הערה: אם לא הגדרות מספר אחרי ה-Multihop מה שיופיע הוא 255
(המקסימום)
BGP Disable
Connected-Check:
אם ניזכר בסעיף מעל נוכל לראות כפי שדיברנו על ה-TTL, TTL =1 מונע הקמת קשרי שכנות
בין נתבים שהם לא DC.
בנוסף על כך ה-IOS מונע הקמת קשרי שכנות בין
נתבים שהם לא DC כאשר ה-TTL=1 .
כפי שראינו קודם לכן, ניתן לפתור בעיה זו על ידי פקודת ebgp-multihop והעלאת ה-TTL לערך שיאפשר הקמת קשר
שכנות.
בתצורות מסוימות שהשכנים כן מחוברים ישירות אחד לשני
אבל מקימים קשרי שכנות באמצעות LOOPBACKים במקום
הממשקים הישירים שלהם ניתן להשתמש באופציית ה-Disable-Connected-Check.
למרות שאנחנו משיגים את אותה תוצאה (הגדלת ה-TTL) ההבדל ביניהם הוא שה- Disable-Connected-Check מונע מצבים שבהם ה-EBGP
Session בין שתי התקנים מנותב דרך נתב TRANSIT.
הפקודה:
router
bgp xxx
neighbor x.x.x.x disable-connected-chcek
BGP
Authentication Peering:
התמיכה של BGP בסיסמה היא באמצעות Option 19 בתוך TCP.
ההגדרה של Md5 Hash היא דיי
פשוטה ומבוצעת באופן הבא תחת השכן:
router
bgp xxx
neighbor x.x.x.x password CISCO
ניתן לצפות בהגדרה של הסיסמה באמצעות הפקודה:
exec
show ip bgp neighbors x.x.x.x | include state|flags
BGP
Route-Reflector:
הגדרת BGP route reflector כפי שצוין ב-RFC 2796 נמצאים בשימוש ברשתות BGP גדולות וזאת על מנת
להוריד את כמות הנתבים שצריכים להיות Fully Meshed על הנוסחה: n*(n-1)/2
לנתבי RR יכולים להיות סוגים שונים של Peers והם:
EBGP Peers
Client-Peers
Non-client peers
-
EBGP Peers הם שכנים
שנמצאים ב-AS שונה כולל אלו שנמצאים ב-Sub-AS Confederation.
-
Client Peers הם שכני IBGP שיש להם את שורת ה- route-reflector-client מוגדרת עליהם.
-
Non-Client הם שכני IBGP שאין להם את הגדרת ה-RR.
פרסומי ניתובים שנשלחים מה-RR
חייבים להיות תואמים לתנאים הבאים:
1. ניתובים שנלמדו ע"י EBGP יכולים להיות מועברים
לשכני EBGP אחרים, Clients ו- Non Clients.
2. ניתובים שנלמדו ע"י Client יכולים להיות מועברים לשכן EBGP, שכן Client ושכן שהוא Non Client.
3. ניתובים שנלמדו ע"י Non Client יכולים להיות מועברים לשכן-EBGP, לשכן Client אבל לא לשכן שהוא Non Client.
בתצורה הפשוטה ביותר של RR נבחרת נקודה אחת מרכזית
בתוך כל ה-IBGP דומיין וכל השכנים מוגדרים כקליינטים של
אותו RR שנבחר.
הגדרת Route-Reflector:
router
bgp xxx
neighbor x.x.x.x route-reflector-client
ניתן לראות ניתוב שהתקבל על ידי RR באמצעות פקודה:
exec
show ip bgp 150.1.1.1 255.255.255.0
שים לב!
כאשר ניתוב מופץ, או לחילופין
משתקף (Reflected) מנתב שהוא RR
אל Client או אל Non Client
כתובת ה-Next-Hop
בתוך ה-BGP
Attribute
לא מתעדכנת!
אך לעומת זאת מוכנים 2 Attributes חדשים לתוך הניתוב ש-Reflected והם:
·
Originator ID.
·
Cluster List.
אם נזכור שמנגנון למניעת לולאות ב-BGP היה חוק ה-Split Horizon והוא היה מתבצע על ידי מניעת הפצת ניתוב
שהתקבל משכן IBGP לשכן IBGP אחר, כיוון שה-Route Reflector שובר
את החוק הזה אנחנו צריכים מנגנון אחר שיסייע במניעת לולאות.
הראשון מבניהם הוא ה-Originator
ID שהוא מוחל על ידי ה- route
reflector כמו ה-RID שממנו נלמד הניתוב.
אם נסתכל בדוגמא למעלה אנחנו יכולים לראות שהניתוב נלמד מה-RID של R2.
המנגנון נכנס לפעולה ברגע שהנתב מזהה את ה-RID של עצמו בתוך העדכון וכך
הוא עושה לניתוב DROP.
לכן ישנה חשיבות רבה לכתובת ה-RID בדיוק כמו ב-EIGRP או OSPF.
ה-Attribute
השני מבניהם הוא ה-Cluster List, הוא
מכיל בתוכו את ה-Cluster-ID של כל ה-RR ים שהניתוב צריך לעבור דרכם בתוך הרשת.
אלא אם אנחנו מגדירים Bgp cluster-id הערך ברירת מחדל הוא ה-RID של ה-RR.
ה-Attribute הזה נועד למנוע לולאות בין RRים כאשר אנחנו מטמיעים בצורה היררכית.
Cluster ב-BGP מוגדר כ- RR וכל הקליינטים שלו, כאשר RR לומד ניתוב משכן IBGP אחר והוא מוצא בתוך ה-Cluster-List את ה-RID של עצמו,
הוא מפיל את העדכון.
ישנה נטייה להשוות את ה-RR ל-DR/BDR ב-OSPF, ובמקרים מסויימים
התעבורה לא מגיעה להתקן ה-RR, אלא ברוב המקרים ה-RR משמש כמרכז התעבורה אבל לא בהכרח מעביר את
כל התעבורה דרכו.
המונח Cluster מתייחס ל-RR והקליינטים שלו או למספר RRים שמשרתים את אותם קליינטים.
Clustering משמש לצורך יצירת איזון בין
כמות תעבורת ה-BGP שצריכה לעבור בין ה-Peers ולטובת שרידות
הרבה ספקיות אינטרנט גדולות משתמשות בקלסטרים בתצורות ה-IBGP שלהם, זאת על ידי מיקום של ה-CLUSTER במיקומים גאוגרפיים שונים דבר אשר מפחית את
כמות החורים הארוכים של קשרי ה-BGP שמוקמים.
המשך יבוא...
מקווה שעזרתי.
אבי
