โรงงาน VxLAN ส่วนที่ 3

สวัสดีฮับ ฉันกำลังเขียนบทความชุดหนึ่งเสร็จ ทุ่มเทให้กับการเปิดหลักสูตร "วิศวกรเครือข่าย" โดย OTUSโดยใช้เทคโนโลยี VxLAN EVPN สำหรับการกำหนดเส้นทางภายในแฟบริค และใช้ไฟร์วอลล์เพื่อจำกัดการเข้าถึงระหว่างบริการภายใน

ส่วนก่อนหน้าของซีรีส์สามารถดูได้ที่ลิงก์ต่อไปนี้:

• 1 ส่วนของวงจร - การเชื่อมต่อ L2 ระหว่างเซิร์ฟเวอร์
• ส่วนที่ 2 ของซีรีส์ - การกำหนดเส้นทางระหว่าง VNI
• ส่วนที่ 2.5 ของซีรีส์ - การพูดนอกเรื่องทางทฤษฎี

วันนี้เราจะศึกษาตรรกะการกำหนดเส้นทางภายใน VxLAN Fabric ต่อไป ในส่วนก่อนหน้านี้ เราดูที่การกำหนดเส้นทางภายในแฟบริคภายใน VRF เดียว อย่างไรก็ตาม อาจมีบริการลูกค้าจำนวนมากในเครือข่าย และทั้งหมดจะต้องกระจายไปยัง VRF ที่แตกต่างกันเพื่อแยกความแตกต่างในการเข้าถึงระหว่างกัน นอกเหนือจากการแยกเครือข่ายแล้ว ธุรกิจอาจจำเป็นต้องเชื่อมต่อไฟร์วอลล์เพื่อจำกัดการเข้าถึงระหว่างบริการเหล่านี้ ใช่ สิ่งนี้ไม่สามารถเรียกได้ว่าเป็นทางออกที่ดีที่สุด แต่ความเป็นจริงสมัยใหม่จำเป็นต้องมี "โซลูชั่นที่ทันสมัย"

ลองพิจารณาสองตัวเลือกสำหรับการกำหนดเส้นทางระหว่าง VRF:

1. การกำหนดเส้นทางโดยไม่ทิ้งแฟบริค VxLAN
2. การกำหนดเส้นทางบนอุปกรณ์ภายนอก

เริ่มจากลอจิกการกำหนดเส้นทางระหว่าง VRF กันก่อน VRF มีจำนวนหนึ่ง หากต้องการกำหนดเส้นทางระหว่าง VRF คุณต้องเลือกอุปกรณ์ในเครือข่ายที่จะทราบเกี่ยวกับ VRF ทั้งหมด (หรือส่วนที่อยู่ระหว่างการกำหนดเส้นทางที่จำเป็น) ตัวอย่างเช่น อุปกรณ์ดังกล่าวอาจเป็นสวิตช์ Leaf ตัวใดตัวหนึ่ง (หรือทั้งหมดในครั้งเดียว) . โทโพโลยีนี้จะมีลักษณะดังนี้:

โทโพโลยีนี้มีข้อเสียอะไรบ้าง?

ถูกต้อง Leaf ทุกคนจำเป็นต้องรู้เกี่ยวกับ VRF ทั้งหมด (และข้อมูลทั้งหมดที่อยู่ในนั้น) บนเครือข่าย ซึ่งทำให้สูญเสียหน่วยความจำและเพิ่มภาระของเครือข่าย ท้ายที่สุดแล้วสวิตช์ Leaf แต่ละตัวไม่จำเป็นต้องรู้ทุกอย่างที่อยู่ในเครือข่ายบ่อยครั้ง

อย่างไรก็ตาม ลองพิจารณาวิธีนี้โดยละเอียดยิ่งขึ้น เนื่องจากสำหรับเครือข่ายขนาดเล็ก ตัวเลือกนี้ค่อนข้างเหมาะสม (หากไม่มีข้อกำหนดทางธุรกิจเฉพาะ)

ณ จุดนี้ คุณอาจมีคำถามเกี่ยวกับวิธีการถ่ายโอนข้อมูลจาก VRF ไปยัง VRF เนื่องจากประเด็นของเทคโนโลยีนี้อยู่ตรงที่การเผยแพร่ข้อมูลควรถูกจำกัด

และคำตอบอยู่ที่ฟังก์ชันต่างๆ เช่น การส่งออกและนำเข้าข้อมูลเส้นทาง (การตั้งค่าเทคโนโลยีนี้ถือว่าอยู่ในนั้น) ที่สอง ส่วนของวงจร) ฉันขอย้ำสั้น ๆ :

เมื่อตั้งค่า VRF ใน AF คุณต้องระบุ route-target สำหรับข้อมูลเส้นทางการนำเข้าและส่งออก คุณสามารถระบุได้โดยอัตโนมัติ จากนั้นค่าจะรวม ASN BGP และ L3 VNI ที่เกี่ยวข้องกับ VRF วิธีนี้จะสะดวกเมื่อคุณมี ASN เดียวในโรงงานของคุณ:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

อย่างไรก็ตาม หากคุณมี ASN มากกว่าหนึ่งรายการและจำเป็นต้องถ่ายโอนเส้นทางระหว่างกัน การกำหนดค่าด้วยตนเองจะเป็นตัวเลือกที่สะดวกและปรับขนาดได้มากกว่า route-target. คำแนะนำในการตั้งค่าด้วยตนเองคือหมายเลขแรก ใช้หมายเลขที่สะดวกสำหรับคุณ เช่น 9999.
ส่วนที่สองควรตั้งค่าให้เท่ากับ VNI สำหรับ VRF นั้น

มากำหนดค่ากันดังนี้:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

ดูเหมือนว่าในตารางเส้นทาง:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

ลองพิจารณาตัวเลือกที่สองสำหรับการกำหนดเส้นทางระหว่าง VRF - ผ่านอุปกรณ์ภายนอก เช่น ไฟร์วอลล์

มีหลายทางเลือกในการทำงานผ่านอุปกรณ์ภายนอก:

1. อุปกรณ์รู้ว่า VxLAN คืออะไรและเราสามารถเพิ่มมันลงในส่วนหนึ่งของแฟบริคได้
2. อุปกรณ์ไม่รู้อะไรเลยเกี่ยวกับ VxLAN

เราจะไม่ยึดติดกับตัวเลือกแรก เนื่องจากตรรกะจะเกือบจะเหมือนกับที่แสดงด้านบน - เรานำ VRF ทั้งหมดไปที่ไฟร์วอลล์และกำหนดค่าการกำหนดเส้นทางระหว่าง VRF บนนั้น

ลองพิจารณาตัวเลือกที่สองเมื่อไฟร์วอลล์ของเราไม่รู้อะไรเลยเกี่ยวกับ VxLAN (แน่นอนว่าตอนนี้อุปกรณ์ที่รองรับ VxLAN ปรากฏขึ้น ตัวอย่างเช่น Checkpoint ประกาศรองรับในเวอร์ชัน R81 คุณสามารถอ่านได้ ที่นี่อย่างไรก็ตาม ทั้งหมดนี้อยู่ในขั้นตอนการทดสอบ และไม่มีความมั่นใจในความเสถียรของการทำงาน)

เมื่อเชื่อมต่ออุปกรณ์ภายนอกเราจะได้ไดอะแกรมต่อไปนี้:

ดังที่คุณเห็นจากแผนภาพ คอขวดปรากฏขึ้นที่อินเทอร์เฟซของไฟร์วอลล์ สิ่งนี้จะต้องนำมาพิจารณาในอนาคตเมื่อวางแผนเครือข่ายและเพิ่มประสิทธิภาพการรับส่งข้อมูลเครือข่าย

อย่างไรก็ตาม เราจะกลับไปสู่ปัญหาเดิมของการกำหนดเส้นทางระหว่าง VRF จากการเพิ่มไฟร์วอลล์ เราก็ได้ข้อสรุปว่าไฟร์วอลล์ต้องรู้เกี่ยวกับ VRF ทั้งหมด ในการดำเนินการนี้ VRF ทั้งหมดจะต้องได้รับการกำหนดค่าบน Border Leafs และไฟร์วอลล์จะต้องเชื่อมต่อกับ VRF แต่ละตัวด้วยลิงก์แยกต่างหาก

เป็นผลให้โครงร่างที่มีไฟร์วอลล์:

นั่นคือบนไฟร์วอลล์คุณต้องกำหนดค่าอินเทอร์เฟซให้กับ VRF แต่ละตัวที่อยู่บนเครือข่าย โดยทั่วไปแล้ว ตรรกะไม่ได้ดูซับซ้อนและสิ่งเดียวที่ฉันไม่ชอบที่นี่คืออินเทอร์เฟซจำนวนมากบนไฟร์วอลล์ แต่ถึงเวลาที่ต้องคิดถึงระบบอัตโนมัติแล้ว

ดี. เราเชื่อมต่อไฟร์วอลล์และเพิ่มลงใน VRF ทั้งหมด แต่ตอนนี้เราจะบังคับให้การรับส่งข้อมูลจากแต่ละ Leaf ผ่านไฟร์วอลล์นี้ได้อย่างไร

บน Leaf ที่เชื่อมต่อกับไฟร์วอลล์จะไม่มีปัญหาเกิดขึ้นเนื่องจากทุกเส้นทางอยู่ในพื้นที่:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

อย่างไรก็ตาม แล้ว Leafs ระยะไกลล่ะ? จะส่งเส้นทางภายนอกเริ่มต้นให้พวกเขาได้อย่างไร

ใช่แล้ว ผ่านเส้นทาง EVPN ประเภท 5 เช่นเดียวกับคำนำหน้าอื่นๆ เหนือแฟบริค VxLAN อย่างไรก็ตาม นี่ไม่ใช่เรื่องง่ายนัก (หากเรากำลังพูดถึง Cisco เนื่องจากฉันไม่ได้ตรวจสอบกับผู้จำหน่ายรายอื่น)

เส้นทางเริ่มต้นจะต้องโฆษณาจาก Leaf ที่ไฟร์วอลล์เชื่อมต่ออยู่ อย่างไรก็ตาม เพื่อส่งเส้นทาง ลีฟจะต้องรู้มันเอง และนี่คือปัญหาบางอย่างเกิดขึ้น (อาจเป็นสำหรับฉันเท่านั้น) เส้นทางจะต้องลงทะเบียนแบบคงที่ใน VRF ที่คุณต้องการโฆษณาเส้นทางดังกล่าว:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

ถัดไปในการกำหนดค่า BGP ให้ตั้งค่าเส้นทางนี้ใน AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

อย่างไรก็ตาม นั่นไม่ใช่ทั้งหมด วิธีนี้จะทำให้เส้นทางเริ่มต้นไม่รวมอยู่ในครอบครัว l2vpn evpn. นอกจากนี้ คุณต้องกำหนดค่าการแจกจ่ายซ้ำ:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

เราระบุว่าคำนำหน้าใดที่จะเข้าสู่ BGP ผ่านการแจกจ่ายซ้ำ

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

ตอนนี้คำนำหน้า 0.0.0.0/0 ตกอยู่ในเส้นทาง EVPN ประเภท 5 และถูกส่งไปยังส่วนที่เหลือของ Leaf:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

ในตาราง BGP เรายังสามารถสังเกตผลลัพธ์ของเส้นทางประเภท 5 ด้วยเส้นทางเริ่มต้นผ่าน 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

นี่เป็นการสรุปชุดบทความเกี่ยวกับ EVPN ในอนาคตฉันจะพยายามพิจารณาการทำงานของ VxLAN ร่วมกับ Multicast เนื่องจากวิธีนี้ถือว่าสามารถปรับขนาดได้มากกว่า (ในขณะนี้เป็นข้อความที่ขัดแย้งกัน)

หากคุณยังคงมีคำถาม/ข้อเสนอแนะในหัวข้อนี้ โปรดพิจารณาฟังก์ชันการทำงานของ EVPN - เขียนไว้เลย เราจะพิจารณาเพิ่มเติม

ที่มา: will.com