OSPF หรือ EIGRP บน VTI ของ ASA: รุ่นของคุณรองรับตัวไหน
OSPFv2 และ EIGRP วิ่งบน VTI ของ ASA ได้ตั้งแต่ 9.19(1) เป็นต้นไป และเฉพาะเมื่อเปิด multicast เท่านั้น เปรียบเทียบทั้งสองบนรุ่นที่คุณใช้งาน แล้วตรวจสอบเพื่อนบ้าน
การถกเถียง OSPF กับ EIGRP ส่วนใหญ่มักถือว่าอุโมงค์สามารถรับส่งโปรโตคอลได้แล้ว และบน ASA สมมติฐานนั้นคือส่วนที่ควรตรวจก่อน การเปรียบเทียบจะน่าสนใจก็ต่อเมื่อยืนยันอิมเมจ ชนิด VTI และเส้นทาง multicast แล้ว ถ้าสลับลำดับนี้ คุณจะเสียเวลาช่วงบ่ายไปกับการจูนไทม์เมอร์บนอุโมงค์ที่จะไม่มีวันสร้างเพื่อนบ้านได้ ผมเริ่มทุกดีไซน์แบบนี้จากบันทึกรุ่นและคอนฟิกูเรชันที่รันอยู่ ไม่ใช่จากความชอบโปรโตคอล
รุ่นเป็นตัวตัดสินก่อนโปรโตคอล
คู่มือ VTI ของ Cisco สำหรับ ASA 9.24 เป็นฐานเอกสารที่ใช้ได้: อธิบาย VTI แบบสแตติกและไดนามิก และระบุการเราต์แบบสแตติก BGP OSPF และ EIGRP ประวัติฟีเจอร์ระบุการรองรับ OSPFv2 และ EIGRP บน VTI ไว้ที่ 9.19(1) อะไรที่เก่ากว่านั้นเป็นอีกเรื่องหนึ่ง
ดังนั้นสองคำถามแรกจึงน่าเบื่อและชี้ขาด:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
ข้อความที่ว่า ASA ใช้ VTI ไม่ได้ หรือรับส่ง IGP ไม่ได้ เป็นจริงสำหรับอิมเมจเก่าบางรุ่น และไม่ใช่เมทริกซ์การรองรับปัจจุบัน เช่นเดียวกัน คู่มือ 9.24 ไม่ใช่คำสั่งให้อัปเกรดทุกอุปกรณ์ มันบอกว่ารุ่นนั้นรองรับอะไร และรุ่นที่คุณติดตั้งไว้ต้องตอบด้วยตัวเอง
unicast ผ่านได้ไม่ได้หมายความว่า IGP จะเกิดขึ้น
คู่มือเดียวกันระบุว่า unicast ผ่านได้โดยค่าเริ่มต้น และต้องเปิด multicast สำหรับ OSPFv2 หรือ EIGRP บน VTI โดยมีขีดจำกัดที่เขียนไว้สำหรับกลุ่ม multicast ประโยคเดียวนั้นอธิบายเพื่อนบ้านที่ล้มเหลวส่วนใหญ่ที่ผมเห็นในดีไซน์นี้ ping ที่ใช้ได้ผ่านอุโมงค์ หรือสถานะ IPsec สีเขียว พิสูจน์ได้แค่เส้นทาง unicast การค้นหาโปรโตคอลต้องใช้เส้นทาง multicast และทั้งสองอย่างถูกคอนฟิกแยกกัน
ตรวจสอบคอนฟิกอินเทอร์เฟซอุโมงค์สำหรับการตั้งค่า multicast นั้นก่อนจะแตะไทม์เมอร์ hello หรือ hold ถ้าไม่มีการตั้งค่า เพื่อนบ้านไม่ได้ช้า แต่มันเป็นไปไม่ได้
OSPF และ EIGRP เคียงข้างกันบนอุโมงค์เดียวกัน
บนอุโมงค์เอง โปรโตคอลทั้งสองก็ดูเหมือนที่อื่นๆ OSPF ต้องใช้ ชนิดเครือข่ายที่ตรงกันพื้นที่ การพิสูจน์ตัวตน และพารามิเตอร์เพื่อนบ้าน ส่วน EIGRP ต้องใช้หมายเลข AS และการตั้งค่าระดับอินเทอร์เฟซที่มาด้วย
กับดักคือการคัดลอกคำสั่งเพื่อนบ้านจากโมเดลอุโมงค์อื่น คำแนะนำเรื่องเพื่อนบ้านแบบสแตติกในดีไซน์ที่ไม่มี VTI มีไว้เพื่อเลี่ยง multicast และมันไม่ย้ายมาสู่ VTI ที่คาดว่าจะรับส่งโปรโตคอลได้เองตามธรรมชาติ คอนฟิกพฤติกรรมอินเทอร์เฟซที่รองรับ แล้วปล่อยให้โปรโตคอลสร้างเพื่อนบ้านของตัวเอง
จากนั้นเปรียบเทียบบนแกนที่ต่างกันจริงสำหรับโทโพโลยีของคุณ: การทำงานร่วมกับอีกฝั่ง พฤติกรรมการลู่เข้าที่คุณทดสอบได้ และความรู้ด้านปฏิบัติการในทีมของคุณ เรื่องเล่าทางประวัติศาสตร์ว่าโปรโตคอลหนึ่งเร็วกว่าหรือเบากว่าไม่ใช่การวัดเครือข่ายของคุณ
เพื่อนบ้านไม่เท่ากับเส้นทางที่ติดตั้งแล้ว
เมื่อเพื่อนบ้านขึ้นแล้ว แยกสิ่งที่ถูกสร้างออกจากสิ่งที่ถูกยอมรับ ดูว่าฝั่งไหนประกาศพรีฟิกซ์สาขาใด ตัวไหนได้รับ ตัวไหนถูกเลือก และตัวไหนเข้าตารางเราต์จริง ขอบเขตการนำเข้า ส่งออก และแจกจ่ายซ้ำควรตั้งใจกำหนด ไม่ใช่ประกาศทุกอย่างที่อุปกรณ์รู้
show ospf neighbor และ show eigrp neighbors บอกคุณว่าเซสชันยังมีชีวิต show route บอกคุณว่าพรีฟิกซ์สาขามาถึงหรือไม่ และนั่นเป็นคนละคำถาม
เส้นทางแอปพลิเคชันเป็นคำถามที่สามอีกครั้ง ความสัมพันธ์เพื่อนบ้านแจกจ่ายการเข้าถึงได้ แต่ไม่ได้ให้สิทธิผ่านไฟร์วอลล์ และไม่ได้พิสูจน์ว่าตัวเลือกทราฟฟิกกับกฎกรองสอดคล้องกัน ตรวจสอบโฟลว์ที่อนุญาตและเส้นทางตอบกลับด้วยการทดสอบที่ได้รับอนุมัติ แทนที่จะถือว่าเส้นทางหมายถึงนโยบาย
การเปรียบเทียบที่เสร็จสมบูรณ์ควรบันทึกอะไร
เขียนอินเทอร์เฟซอุโมงค์ รุ่นที่รองรับ การแลกเปลี่ยนควบคุมที่คุณตรวจสอบ และนโยบายเส้นทางที่คุณกำหนดขอบเขต เพิ่มการตั้งค่า multicast เพราะเป็นรายละเอียดที่ตัดสินอย่างเงียบๆ ว่าส่วนที่เหลือทำงานได้หรือไม่ เก็บบันทึกนั้นไว้ข้างรุ่นที่ติดตั้ง เพื่อให้การเปลี่ยนฟีเจอร์ในภายหลังตรวจทานได้โดยไม่ต้องเริ่มจากสมมติฐานที่หมดอายุไปแล้ว
ถ้าขาดข้อใดในสี่ข้อนั้น คุณมีเพียงความชอบไม่ใช่ดีไซน์ แก้ข้อเท็จจริงที่ขาดก่อน การเลือกโปรโตคอลเป็นส่วนที่ง่าย