VxLAN ქარხანა. Მე -3 ნაწილი

გამარჯობა, ჰაბრ. ვასრულებ სტატიების სერიას, კურსის დაწყებას ეძღვნება "ქსელის ინჟინერი" OTUS-ის მიერ, VxLAN EVPN ტექნოლოგიის გამოყენებით ქსოვილში მარშრუტირებისთვის და Firewall-ის გამოყენებით შიდა სერვისებს შორის წვდომის შესაზღუდად

სერიის წინა ნაწილები შეგიძლიათ იხილოთ შემდეგ ბმულებზე:

• ციკლის 1 ნაწილი - L2 კავშირი სერვერებს შორის
• სერიის მე-2 ნაწილი - მარშრუტიზაცია VNI-ებს შორის
• სერიის 2.5 ნაწილი - თეორიული დიგრესია

დღეს ჩვენ გავაგრძელებთ მარშრუტიზაციის ლოგიკის შესწავლას VxLAN ქსოვილის შიგნით. წინა ნაწილში ჩვენ გადავხედეთ ქსოვილის შიდა მარშრუტიზაციას ერთი VRF-ის ფარგლებში. თუმცა, ქსელში შეიძლება იყოს კლიენტთა სერვისების დიდი რაოდენობა და ყველა მათგანი უნდა განაწილდეს სხვადასხვა VRF-ებში, რათა განასხვავოს მათ შორის წვდომა. ქსელის განცალკევების გარდა, ბიზნესს შეიძლება დასჭირდეს Firewall-ის დაკავშირება ამ სერვისებს შორის წვდომის შესაზღუდად. დიახ, ამას არ შეიძლება ეწოდოს საუკეთესო გამოსავალი, მაგრამ თანამედროვე რეალობა მოითხოვს "თანამედროვე გადაწყვეტილებებს".

მოდით განვიხილოთ VRF-ებს შორის მარშრუტიზაციის ორი ვარიანტი:

1. მარშრუტირება VxLAN ქსოვილის დატოვების გარეშე;
2. მარშრუტი გარე აღჭურვილობაზე.

დავიწყოთ VRF-ებს შორის მარშრუტიზაციის ლოგიკით. არსებობს VRF-ების გარკვეული რაოდენობა. VRF-ებს შორის მარშრუტისთვის, თქვენ უნდა აირჩიოთ მოწყობილობა ქსელში, რომელიც ეცოდინება ყველა VRF-ის (ან ნაწილების, რომელთა შორის მარშრუტიზაციაა საჭირო). ასეთი მოწყობილობა შეიძლება იყოს, მაგალითად, Leaf-ის ერთ-ერთი გადამრთველი (ან ყველა ერთდროულად) . ეს ტოპოლოგია ასე გამოიყურება:

რა არის ამ ტოპოლოგიის უარყოფითი მხარეები?

ასეა, ყველა Leaf-მა უნდა იცოდეს ყველა VRF-ის (და მათში არსებული ყველა ინფორმაციის) შესახებ ქსელში, რაც იწვევს მეხსიერების დაკარგვას და ქსელის დატვირთვის გაზრდას. ყოველივე ამის შემდეგ, საკმაოდ ხშირად თითოეულ Leaf switch-ს არ სჭირდება იმის ცოდნა, რაც არის ქსელში.

თუმცა, მოდით განვიხილოთ ეს მეთოდი უფრო დეტალურად, რადგან მცირე ქსელებისთვის ეს ვარიანტი საკმაოდ შესაფერისია (თუ არ არსებობს კონკრეტული ბიზნეს მოთხოვნები)

ამ ეტაპზე შეიძლება გაგიჩნდეთ კითხვა, თუ როგორ გადავიტანოთ ინფორმაცია VRF-დან VRF-ზე, რადგან ამ ტექნოლოგიის აზრი სწორედ იმაშია, რომ ინფორმაციის გავრცელება შეზღუდული უნდა იყოს.

და პასუხი მდგომარეობს ისეთ ფუნქციებში, როგორიცაა მარშრუტიზაციის ინფორმაციის ექსპორტი და იმპორტი (ამ ტექნოლოგიის დაყენება განიხილებოდა მეორე ციკლის ნაწილები). მოკლედ გავიმეორებ:

AF-ში VRF-ის დაყენებისას უნდა მიუთითოთ 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-ებს შორის მარშრუტიზაციის მეორე ვარიანტი - გარე აღჭურვილობის მეშვეობით, მაგალითად Firewall.

გარე მოწყობილობის საშუალებით მუშაობის რამდენიმე ვარიანტი არსებობს:

1. მოწყობილობამ იცის რა არის VxLAN და შეგვიძლია დავამატოთ ქსოვილის ნაწილს;
2. მოწყობილობამ არაფერი იცის VxLAN-ის შესახებ.

ჩვენ არ შევჩერდებით პირველ ვარიანტზე, რადგან ლოგიკა თითქმის იგივე იქნება, რაც ზემოთ იყო ნაჩვენები - ჩვენ ყველა VRF-ს მივყავართ Firewall-ზე და ვაკონფიგურირებთ მარშრუტიზაციას VRF-ებს შორის მასზე.

განვიხილოთ მეორე ვარიანტი, როდესაც ჩვენმა Firewall-მა არაფერი იცის VxLAN-ის შესახებ (ახლა, რა თქმა უნდა, ჩნდება აღჭურვილობა VxLAN მხარდაჭერით. მაგალითად, Checkpoint-მა გამოაცხადა მხარდაჭერა R81 ვერსიაში. შეგიძლიათ წაიკითხოთ ამის შესახებ. აქთუმცა, ეს ყველაფერი ტესტირების ეტაპზეა და არ არსებობს ნდობა ოპერაციის სტაბილურობაში).

გარე მოწყობილობის შეერთებისას ვიღებთ შემდეგ დიაგრამას:

როგორც დიაგრამიდან ხედავთ, ბოთლი ჩნდება Firewall-ის ინტერფეისზე. ეს სამომავლოდ უნდა იქნას გათვალისწინებული ქსელის დაგეგმვისა და ქსელის ტრაფიკის ოპტიმიზაციისას.

თუმცა, დავუბრუნდეთ VRF-ებს შორის მარშრუტიზაციის საწყის პრობლემას. Firewall-ის დამატების შედეგად მივდივართ დასკვნამდე, რომ Firewall-მა უნდა იცოდეს ყველა VRF-ის შესახებ. ამისათვის ყველა VRF ასევე უნდა იყოს კონფიგურირებული სასაზღვრო Leafs-ზე და Firewall უნდა იყოს დაკავშირებული თითოეულ VRF-თან ცალკე ბმულით.

შედეგად, სქემა Firewall-ით:

ანუ Firewall-ზე თქვენ უნდა დააკონფიგურიროთ ინტერფეისი თითოეულ VRF-ზე, რომელიც მდებარეობს ქსელში. ზოგადად, ლოგიკა არ გამოიყურება რთული და ერთადერთი, რაც აქ არ მომწონს, არის ინტერფეისების დიდი რაოდენობა Firewall-ზე, მაგრამ აქ დროა ვიფიქროთ ავტომატიზაციაზე.

ჯარიმა. ჩვენ დავაკავშირეთ Firewall და დავამატეთ ის ყველა VRF-ს. მაგრამ როგორ შეგვიძლია ახლა ვაიძულოთ ტრაფიკი თითოეული ფოთლიდან ამ Firewall-ის გავლით?

Firewall-თან დაკავშირებულ 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-დან, რომელსაც Firewall უკავშირდება. თუმცა, მარშრუტის გადასაცემად, ფოთოლმა ის თავად უნდა იცოდეს. და აქ ჩნდება გარკვეული პრობლემა (შესაძლოა მხოლოდ ჩემთვის), მარშრუტი სტატიკურად უნდა დარეგისტრირდეს 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 ტიპს და გადაეცემა დანარჩენ ფოთოლს:

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-ის ნებისმიერი ფუნქციონირება - დაწერეთ, შემდგომ განვიხილავთ.

წყარო: www.habr.com