מספר נקודות מעניינות בנוגע ל 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.

סקריפט PERL להרצת פקודות ב cisco device

להלן קישור לסקריפט PERL שמריץ פקודות בציוד Cisco, מנתח אותן ואוסף מידע נדרש.
שימושי לתחקור תקלות.

אופן פעולת שרת PXE

PXE - ר"ת של Preboot Execution Environment.

PXE הינו הרחבה ל DHCP שתוקננה על ידי אינטל ומיקרוסופט ומאפשרת להתקין מחשב(מערכת הפעלה) ישירות מרשת Ethernet .לטובת ההתקנה נדרש שרת DHCP ושרת TFTP.

להלן תיאור התהליך:

• עמדת קצה פונה לשרת DHCP
• שרת ה DHCP מספק כתובת IP לעמדה ורשימת שרתי PXE
• תחנת הקצה פונה לאחד משרתי ה PXE ומבקשת את ה path לקובץ ההתקנה
• התחנה מעלה תוכנת bootstrap מתוך ה BIOS אל זיכרון ה RAM. תוכנה זו מנהלת את תהליך ההתקנה.
• מכאן, תוכנת ה bootstrap מתייחסת ל path שקיבלה כאילו היה התקן פיזי של המחשב ומבצעת את ההתקנה.

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

מפות מוח - מה זה?

קיימת טכניקת למידה המבוססת על מפות מח.

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

על מנת להתרשם מהמבנה של מפות מוח, מצורף  קישור למפות מוח שהוכנו בתהליך לימוד למבחן ה CCIE (הסמכה המתקדמת ביותר של Cisco).

למי שמעונין להתחיל לעבוד בטכניקה זו, מומלץ להצטייד בתוכנה מתאימה, כגון Mindo, MindNode וכו'.

TCP flags

שני דגלים ב tcp header אינם אינטואיטיביים לרוב וננסה להסביר אותם.

psh - דגל push משמעותו כפולה:

1. האפליקציה המשדרת מסמנת ל tcp לא להמתין למידע נוסף שיצטבר ב transmit buffer אלא לשלוח מיידית אכל המידע שקיים כרגע ב buffer.

2. בתהליך קבלת המידע, הדגל מסמן ל tcp ל להמתין למידע נוסף שיצטבר ב recieve buffer אלא להעביר את כל המידע שכרגע ב buffer מיידית לאפליקציה.

urg - דגל urgent. מציין ל tcp להעביר לאפליקציה חלק מהמידע שבחבילה לפני שאר המידע. במידה ודגל זה דולק, הערך בשדה urgent pointer מציין כמה בתים מתחילת חביה נחשבים דחופים לענין זה.

הקישור הבא מסביר את הנושא לעומק עם דוגמאות.

LAM

בימים האחרונים אביב ביצע בחינה של פרוטוקול LAM.
מדובר בפרוטוקול Local Area Mobility המאפשר לתחנות ניידות ברשת לקבל גישה גם בסגמנטים שאינם הסגמנטים המקוריים שלהם.

איך זה עובד?
נניח שתחנת קצה בכתובת 10.0.0.1/24 מועברת ברשת, מאתר א' שם כתובת הנתב היא 10.0.0.254/24 לאתר ב' שם כתובת הנתב היא 11.0.0.254/24. במידה ומוגדר ip arp-mobility תחת ממשק ה LAN של הנתב באתר ב', הוא יזהה שהעמדה מבקשת ARP לכתובת שאינה שייכת לסגמנט ויענה על בקשת ה ARP. בנוסף, יוסיף ניתוב ספציפי לכתובת 10.0.0.1/32 וניתן אף להגדיר לו לבצע redistribute של הניתוב לתוך OSPF. בצורה כזו, לעמדה יש תקשורת החוצה וגם מחשבים מסגמנטים אחרים יכולים להגיע אליה.

הנ"ל יכול להיות שימושי בהקשר של vmotion במידה ולא רוצים לייצר ערוץ L2.

להלן מספר נקודות שחשוב להכיר:
1. הנתב המארח מכניס רשומת ניתוב מסוג Mobile גם אם אין לו ניתוב לרשת המקורית
2. נדרש שבנתב המארח יהיה ניתוב לרשת המקורית על מנת שיענה על בקשת ה ARP
3. תקשורת בין עמדה שנדדה לתחנות שנשארו בסגמנט המקורי, תקפא למשך פרק הזמן הדרוש לפקיעת רשומת ה cache של טבלת ה ARP של העמדות שלא נדדו, כיוון שעדיין זוכרות את כתובת ה MAC של העמדה שנדדה
4. גם הנתב המקורי וגם המארח נדרשים להפעיל proxy arp
5. כאשר יש שני נתבים בסגמנט שמופעל עליהם LAM, שניהם יפעלו כאמור לעיל בצורה בלתי תלויה
6. לא ניתן להפעיל LAM על ממשק המשויך ל VRF (ניתן להכניס הפקודה אך לא עובדת)

להלן קישור למסמך של Cisco בנושא.

אז מה ההבדל בין המתגים הוירטואליים השונים בסביבת vmware?

בגרסא הבסיסת של כל ESX קיים מתג vSwitch הנקרא Virtual Standard Switch או בקצרה vSS.
היתרון של ה vSS הוא שכל מתג עצמאי לחלוטין בהיבט ההגדרות וכאן גם החסרון הגדול שלו - כל הגדרה צריך לבצע ידנית במתג שבכל שרת ובכך מעלים את הסבירות לטעות אנוש.

על מנת להתמודד עם בעיה זו ובעיות נוספות, vmware פיתחה מתג וירטואלי נוסף הנקרא Virtual Distributed Switch או בקצרה vDS.
היתרון המשמעותי של המתג הוא ביכולת הניהול המרכזי של כלל המתגים בסביבה באמצעות ה vCenter. שים לב ש vCenter מהווה Configuration Plane בלבד ולא Control Plane. זהו הבדל חשוב שנעמוד עליו ועל ההשלכות שלו כשנפרט לגבי Nexus 1000v.

בנוסף, למתג ה vDS ישנן תכונות נוספות המבדלות אותו מ vSS (פרט למחיר... מחייב רשיון Enterprise plus):

• ניהול מרכזי
• יכולות QoS מתקדמות כגון Shaping בכניסה וביציאה של כל פורט
• יכולת Security מתקדמות כגון Private VLAN
• מאפשר להתקין Nexus 1000v שמאפשר יכולות נוספות כגון NetFlow, ACL וכו'

מצד שני, ישנם גם חסרונות.

כאשר מסיבה כלשהיא (נתק תקשורת, תקלה וכו') ה ESX אינו מתקשר עם ה vCenter, לא ניתן לבצע שינוי הגדרות ב vDS. המשמעות היא שמכונות וירטואליות שרצות בשרת ה ESX הספציפי ימשיכו לעבוד בצורה תקינה אך לא אפשרי להדליק מכונה חדשה במתג או להעביר מכונה משרת אחר לשרת זה.

על מנת להתמודד עם אירוע של reboot של שרת ESX, הקונפיגורציה של המתג נשמרת בדיסק של השרת ובמידה ואינו מתקשר עם vCenter לאחר עלייתו, הוא מעלה את הקונפיגורציה השמורה שלו.

האופציה השלישית והאחרונה היא מתג Nexus 1000v עליו נפרט בפוסט נפרד.

להרחבת הנושא, מוזמנים לקרוא את מסמך ה VMware.

miercom

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

VDI products

השוואה בין מוצרי VDI על פי חברת הבדיקות miercom. הבדיקה מומנה על ידי citrix.

רוחב פס - בעבודה משרדית סטנדרטית (מיילים, מסמכים וכו׳) citrix מנצל 370kbps ואילו vmware מנצל 1.09mbps. בעבודה עם flash (סרטון ב youtube) היה הבדל גדול יותר - citrix ניצל 3mbps לעומת 29mbps של vmware.
תצוגת וידאו - בהשוואת vidMOS יש יתרון ל citrix עם ציון מקסימאלי 5 לעומת vmware עם ציון 3.

VSX vSwitch/vRouter Limitations

בארכיטקטורת VSX, ה vSwitch ו vRouter הינם מקומיים לשרת בו הם מוגדרים ואינם פרוסים על כל ה cluster. לכן, כאשר מעוניינים לבצע HA עבור VS בודד, ישנה מגבלה שלא ניתן לעשות זאת באחד המקרים הבאים:
1. אם ה VS מקושר ל vRouter
2. אם ה VS מקושר ל vSwitch שאין לו uplinks לרשת החוצה.

שילוב OSPF בארכיטקטורת VRF-Lite

כאשר מגדירים בנתב מספר VRF-ים בתצורת VRF-Lite עם OSPF, ממשק השייך ל VRF לא יקבל ניתובים מסוג LSA Type 3 או LSA Type 5 מבלי להפעיל את הפקודה capability vrf-lite תחת הגדרות ה OSPF.
פקודה זו משמשת לביטול תהליך בדיקות של נתבי PE בתצורת MPLS. הבדיקות המבוטלות הן:
1. לא בודקים down bit
2. לא בודקים זהות של domain-id

מומלץ להפעיל את הפקודה בכל מימוש של VRF-Lite בשילוב OSPF.

Service card conectivity issues in 6500

ישנה בעיה בתקשורת של service modules ב 6500 כאשר משתמשים ב etherchannel שיוצא משני כרטיסים שונים. הפתרון הוא להגדיר כתובת gw של נתב שאינו ה 6500 בו מותקן ה service module.

להלן קישור ל bug ב cisco.

Microsoft NLB

מנגנון cluster load balancing של microsoft.
הרעיון הוא שכל חבילה המיועדת ל cluster תגיע בו זמנית לכל השרתים. המטרה היא לאפשר שיקום מיידי במתאר כשל של שרת או של הרשת.

שני מצבי עבודה:

unicast mode- לכל שרת יש כתובת mac ייחודית משלו שאיתה הוא יוצא אל הרשת. כאשר ה cluster מקבל בקשת arp התשובה היא כתובת mac שאינה שייכת לאף אחד מהשרתים. המשמעות היא שהמתג יבצע flooding לתעבורה המיועדת ל cluster ולכן גם במקרה של כשל השיקום לשרת חלופי נעשה מיידית.

multicast mode - תשובה לבקשות arp הינה כתובת ethernet multicast. כל שרת מבצע igmp join לאותה כתובת כדי לאותת למנגנון ה igmp snooping במתג שהוא מעונין במידע. כתובת ה mac הפיזית של השרתים אינה כתובת ה ethernet multicast ולכן המתג לא לומד את כתובת ה mac דרך הפורטים של השרתים. בנוסף, גם אם השרתים היו עושים שימוש בכתובת mac זו, המתג היה מבצע mac flapping כי רואה את אותו ה mac במסר פורטים. הפתרון הוא להגדיר רשומות mac סטטיות במתג. ב 6500 נדרש גם לבטל snooping על הפורטים שאליהם מקושרים השרתים ב cluster.
בעיה נוספת היא שהנתב הסמוך ל cluster לא יחזיק רשומת arp תקינה כיוון שנתב cisco לא מסכים להחזיק רשומת arp דינאמית שכתובת ה mac הינה multicast. הפתרון הוא להגדיר רשומת arp סטטית.

vmware ממליצים על multicast mode.

 קישור למסמך של cisco בנושא.

FCoE in software

יש היום נסיונות למממש FCoE בצד השרת באמצעות כרטיס תקשורת סטנדרטי ethernet ו driver שיבצע את פעולת האנקפסולציה של תעבורת SCSI לתוך מסגרת ethernet. היתרונות ברורים: חיסכון בעלויות חומרה ושמירה על השקעה כך שבעתיד כשיצאו כרטיסי רשת חזקים יותר, התמיכה תהיה כמעט אוטומטית. כיום, בחלק גדול מהכרטיסים קיים כסטנדרט tcp offload כך שגם בהקשר הזה יש יתרון.
ראה קישור.

TOS to EXP mapping

שדה tos הנכנס לרשת mpls מועתק לשדה ה exp אוטומטית.
ביציאה מרשת ה mpls שדה ה exp אינו מועתק בחזרה לשדה ה tos.
ראה קישור.

link state tracking

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

הגדרות:

Switch(config)#link state track 1

interface GigabitEthernet1/0/1

link state group 1 upstream

interface GigabitEthernet1/0/2

link state group 1 downstream

well known networking timers

לעיתים בתחקור תקלה מתרחשת תופעה מחזורית כל x שניות או דקות.
על מנת למקד את הפתרון, עשוי לעזור אם יודעים איזה פרוטוקולים עושים שימוש בברירת מחדל בקבועי זמן אלו. להלן קישור ל רשימת ה timers הנפוצים.