מספר נקודות מעניינות בנוגע ל Cisco VRF

אז מה זה בעצם VRF?
VRF הינו מימוש בסיסי של מעין נתב וירטואלי בציוד Cisco. הסיבה שלא מדובר בנתב וירטואלי לכל דבר היא שרק הטבלאות הבאות ייחודיות לכל VRF ואילו שאר תהליכי הנתב משותפים:

• טבלת ממשקים 
• טבלת ARP 
• טבלת Routing 

זליגת מידע בין VRF-ים
ניתן להגדיר ניתוב סטטי ב VRF כך ש next-hop יהיה בטבלת ה global. הפקודה היא:

ip route vrf vrf-name dest mask next-hop global. 

ניתן להגדיר ניתוב סטטי בטבלת ה global כך שייצא דרך ממשק של VRF, באופן הבא: 

ip route dest mask out-interface next-hop (optional) 

בניתוב כזה נדרש לציין את ממשק היציאה כי כתובת ה next-hop אינה מופיעה בטבלת הניתוב של ה VRF. בממשקים שהם point-to-point אין צורך לציין את כתובת ה next-hop.

GRE Tunnels ו VRF-ים
ניתן לשייך ממשק GRE ל VRF כאשר בברירת מחדל הוא יוקם דרך vrf default. כלומר, הנתב יחפש את כתובת ה tunnel destination בטבלת הניתוב הגלובאלית של הנתב. ניתן להגדיר לנתב לחפש את כתובת ה tunnel destination בטבלת ניתוב של VRF אחר באמצעות הפקודה vrf תחת הגדרת ה GRE.

שיוך חבילות נכנסות ל VRF
ניתן להגדיר לנתב לשייך חבילה ל VRF שלא על פי ממשק הכניסה אלא על פי פרמטר אחר, כגון כתובת ה source של החבילה, על ידי הפקודה ip vrf select source. אופציה נוספת היא שיוך על פי PBR, ראה דוגמא: 

access-list 40 permit 10.1.0.0 0.0.255.255
access-list 50 permit 10.2.0.0 0.0.255.255
access-list 60 permit 10.3.0.0 0.0.255.255
!
route-map PBR-VRF-Selection permit 10
 match ip address 40
 set vrf VRF_1
 !
route-map PBR-VRF-Selection permit 20
 match ip address 50
 set vrf VRF_2
 !
route-map PBR-VRF-Selection permit 30
 match ip address 60
 set vrf VRF_3
 !
interface Ethernet0/1
 ip address 192.168.1.6 255.255.255.252
 ip policy route-map PBR-VRF-Selection
 ip vrf receive VRF_1
 ip vrf receive VRF_2
 ip vrf receive VRF_3

מספר פעולות שימושיות שניתן לבצע עם PowerCLI

PowerCLI הינו כלי המאפשר הרצה של סקריפטים בסביבת VMware. להלן מספר פעולות וקטעי קוד רלוונטיים העשויים להיות שימושיים:

הגדרת משתנים

$MyHosts = "192.168.0.101", "192.168.0.102"
$username = "root"
$password = "p@$$w0rd"
$DomainSRV = "DOMAIN01", "DOMAIN02"
$VirtualVC = "vCenter01"

שינוי הגדרות ה PowerCLI עבור חיבור בו זמנית למספר שרתי Host

$AllowMultiple = Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Confirm:$false

התחברות לשרתי ה Host וביצוע פעולות

$MyHosts | Foreach {
Write-Host "Connecting to host: $($_)"
$connection = Connect-VIServer $_ -User $username -Password $password
}

קבלת רשימת ה VM-ים שרצה בשרת Host

$VM = Get-VM $DomainSRV

ריצה על כל ה VM שהתקבלו

$VM | Foreach {
Write-Host "VM $($_.name) found on $($_.VMHost)"
}

בדיקה ש VM תקין באמצעות סטטוס ה VM Tools המותקנים עליו

$VM | Foreach {
do {
$VM = Get-VM $_
$Toolsstatus = $VM.ExtensionData.Guest.ToolsRunningStatus
Write-Host "VM tools status is $Toolsstatus"
}
}

שיקולי HA בשדרוג ל vSphere 5

בגרסא vSphere 5 שוכתב הקוד המטפל במנגנון ה HA וככל הנראה פתר בעיות רבות שהיו בגרסא 4.


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


כאשר משדרגים vCenter לגרסא 5, מותקן בכל ה ESX-ים ה agent החדש של HA דהיינו FDM. ה agent יותקן רק על ESX-ים מגרסא 3.5 ומעלה. ראה קישור. כלומר, כל עוד כל ה ESX-ים בסביבה הם גרסא 3.5 ומעלה, תהליך המיגרציה מבוצע אוטומטית על ידי vCenter.


מצד שני, חשוב לזכור כי רק ה Agent של HA שודרג לגרסא החדשה ואילו כל ה ESX-ים ממשיכים להריץ גרסא שאינה 5. השלב הבא יהיה לשדרג כל ESX בנפרד. כעת, לפחות לשלב המעבר, יהיו בסביבה ESX-ים גרסא 5 ו ESX-ים מגרסא קודמת. על פי VMware, התצורה נתמכת אולם יש לפעול לצמצום משך זמן המעבר ככל האפשר.

ראה עוד נושאים של vmware במסמך הבא.

vPC Consistency Check

שני המתגים החברים ב VPC מבצעים consistency check. המשמעות היא ששני המתגים מוודאים שהקונפיגורציה שלהם זהה ואם מזוהה פער שניהם מכבים את הפורטים השייכים ל VPC מסוים.

ישנם שני סוגים של אי תאימות - Type 1 ו Type 2.

כאשר מזוהה אירוע של אי תאימות מסוג Type 1 שני הפורטים נכבים מיידית. אירוע כזה מתרחש אם אחד הפרמטרים הבאים אינו תואם בממשקים החברים ב VPC בשני המתגים:

• קצב הממשקים.
• MTU
• STP

כאשר מזוהה אירוע של אי תאימות מסוג Type 2, מיוצרת הודעת שגיאה וייתכן שחלק מ VLAN-ים לא יעברו ב VPC. בכל מקרה, הפורטים לא יכובו. אירוע כזה מתרחש אם אחד הפרמטרים הבאים אינו תואם בממשקים החברים ב VPC בשני המתגים:

• VTP
• QOS

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

קיימות מספר אופציות להתמודד עם הנושא. דרך אחת היא להשתמש ב graceful consistency check (מופעל בברירת מחדל ב 5K, מיועד להגיע גם ל 7K). זהו מנגנון המבצע את בדיקות התאימות כפי המתואר מעלה אלא שבעת זיהוי אי תאימות מסוג Type 1 הפורטים יישאר דולקים רק ב Primary.

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

מומלץ לקרוא בהרחבה על נושא ה vPC במסמך Nexus.