EVPN firewall პოლიტიკა: ცენტრალიზებული gateway და განაწილებული IRB
ცენტრალიზებული gateway-ები მოიჯარის ტრაფიკს firewall-ზე გაატარებენ, განაწილებული IRB — არა. შეადარეთ, სად ამოწმებს თითოეული და რა სჭირდება სწრაფ გზას.
ორი EVPN დიზაინი მოიჯარის gateway-ს სხვადასხვა ადგილას ათავსებს და firewall თითოეულში სხვადასხვა ტრაფიკს ხედავს. ცენტრალიზებული gateway-ის შემთხვევაში ქვექსელებს შორის ტრაფიკი firewall-ამდე აღწევს, რადგან სწორედ იქ ხდება მარშრუტიზაცია. განაწილებული IRB-ის შემთხვევაში leaf კომუტატორები ლოკალურად მარშრუტიზაციას აკეთებენ და firewall ვერაფერს ხედავს, თუ განზრახ არ ჩასვით იგი. არც ერთი მოდელი არ არის მცდარი. მცდარია firewall-ის საზღვარზე მიმაგრება და იმის ვარაუდი, რომ fabric ტრაფიკს მასთან მიიტანს.
ორი მოდელი, ორი განსხვავებული შემოწმების წერტილი
ჯერ დაასახელეთ ის ნაკადები, რომლებსაც შემოწმება სჭირდება, რადგან ორი მოდელი მათ სხვაგვარად ეპყრობა.
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
ერთი და იმავე ქვექსელის შიგნით ტრაფიკი ის სტრიქონია, რომელსაც ავიწყდებიან. ერთ VLAN-ზე ორი ჰოსტი ხიდის მეშვეობით საუბრობს და ამ გზაზე მარშრუტიზებადი firewall არ დგას, თუ ცალკე მე-2 დონის შემოწმების დიზაინი არ ჩაერევა. ეს ორივე მოდელშია მართალი, ამიტომ ეს დიზაინის ხარვეზია და არა მათ შორის შედარება.
დანარჩენი სამი სტრიქონი არის ადგილი, სადაც მოდელები ნამდვილად იშლება.
ცენტრალიზებული gateway: მარტივი შემოწმება, რეალური ტრანზიტის ხარჯი
შეინარჩუნეთ მოიჯარის VLAN-ები როგორც მე-2 დონის სერვისები და განათავსეთ მათი მარშრუტიზაციის gateway-ები firewall-ზე. ქვექსელებს შორის ტრაფიკი შემდეგ ამ gateway-მდე მიდის და უკან ბრუნდება, შესაძლოა მაშინაც, როცა ორივე ჰოსტი ერთსა და იმავე leaf-ზეა. შემოწმების წერტილი ცალსახაა და ეს არის ამ დიზაინის მთელი არგუმენტი. ხარჯია ტრანზიტული დატვირთვა firewall-ზე და ცენტრალური დამოკიდებულება სიმძლავრესა და ხელმისაწვდომობაზე, რომელიც ახლა უნდა დააპროექტოთ.
შეზღუდეთ ცვლილება იმ მოიჯარის gateway-ებით, რომლებიც გაქვთ განზრახული. ყოველი VLAN მისამართის მოხსნა ძალიან ფართოა, როცა მართვას, underlay-ს და პლატფორმის ინტერფეისებს ცალკე მოვალეობები აქვთ. შეამოწმეთ მეორე აქტიური gateway-ც, რადგან ის, რომელიც ჯერ კიდევ firewall-ის ირგვლივ მარშრუტიზაციას აკეთებს, ჩუმად აუქმებს დიზაინს.
ეს მოდელი უფრო ადვილად აიხსნება აუდიტორისთვის. ის ავტომატურად არ არის იაფი ექსპლუატაციაში.
განაწილებული IRB: სწრაფი გზა, ნაგულისხმევად შემოწმების გარეშე
განაწილებული anycast gateway-ებით თითოეული leaf მოიჯარის ტრაფიკს ლოკალურად მარშრუტიზაციას უკეთებს და RFC 9135 ხსნის, რატომ ირიდებს ეს ცენტრალიზებული gateway-ის უკან გადატანას. სარგებელი რეალურია და მას პირდაპირი შედეგი აქვს: შემოწმება ვერ დაუსკვნით იმას, თუ სად არის firewall ჩართული. სასაზღვრო leaf-ზე მიერთებული firewall ხედავს გარე ტრაფიკს და ყველაფერს, რასაც განზრახ მისკენ მიმართავთ.
ჩასვით სერვისი მექანიზმით, რომელსაც პლატფორმა ნამდვილად მხარს უჭერს: პოლიტიკაზე დაფუძნებული გადამისამართება, სერვისის კვანძი ან კონტროლირებული მარშრუტიზაცია VRF-ებს შორის firewall-ის გავლით. შეუსაბამეთ განზრახული ტრაფიკი მის რეალურ შესვლის წერტილს. პოლიტიკა, რომელიც ჰოსტებისკენ მიმართულ ინტერფეისზეა დაწერილი, არ ფარავს overlay-იდან მომავალ პაკეტს.
წაიკითხეთ დაყენებული მარშრუტები და არა განზრახული ნაგულისხმევი. პირდაპირ იმპორტირებული უფრო კონკრეტული მოიჯარის პრეფიქსი შეიძლება გვერდი აუაროს firewall-ისკენ მიმთითებელ ნაგულისხმევ მარშრუტს და კონფიგურაციაში არაფერი გამოჩნდება არასწორად.
სიმეტრია მარშრუტიზაციის თვისებაა და არა შემოწმების გარანტია
სიმეტრიული IRB აღწერს, როგორ ამუშავებენ შემავალი და გამომავალი provider edge კვანძები ნაკადის მარშრუტიზაციასა და ხიდს. ის არაფერს ამბობს იმაზე, აღწევს თუ არა ორივე მიმართულება ერთსა და იმავე stateful მოწყობილებას. ECMP, anycast და firewall-ის მაღალი ხელმისაწვდომობა ყველა გავლენას ახდენს იმაზე, თუ რომელი კვანძი ხედავს დაბრუნების ტრაფიკს და კლასტერის მხარდაჭერილი მდგომარეობის მოდელი წყვეტს, მისაღებია თუ არა ეს.
მკაფიოდ მიჰყევით დაბრუნების გზას თითოეული ნაკადისთვის, რომელიც თქვენთვის მნიშვნელოვანია. NAT არ არის ამ სამუშაოს უნივერსალური შემცვლელი და დიზაინები, რომლებიც მას ეყრდნობიან, ხარვეზს ჩვეულებრივ failover-ის დროს პოულობენ და არა მშენებლობისას.
გაიარეთ ერთი სავალდებულო ნაკადი და ერთი განზრახ გამორიცხული ნაკადი ორივე მიმართულებით, სანამ დიზაინს დაამტკიცებთ.
როგორ ავირჩიოთ და რა ვცადოთ ნებისმიერ შემთხვევაში
აირჩიეთ ცენტრალიზებული gateway, როცა შემოწმების დაფარვა უფრო მნიშვნელოვანია ვიდრე ტრანზიტული სიმძლავრე და შეგიძლიათ ცენტრალური დამოკიდებულების საშუალება. აირჩიეთ განაწილებული IRB, როცა ლოკალური მარშრუტიზაცია არის მიზანი და ბიუჯეტი გამოყავით მკაფიო სერვისის ჩასმისთვის, ნაცვლად მისი ვარაუდისა.
შემდეგ გამოსცადეთ მარშრუტიზაცია, რომელიც რეალურად დააყენეთ, რადგან სწორედ იქ განსხვავდება ორი დიზაინი ყველაზე მეტად:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixტესტში ჩართეთ სერვისის კვანძის გაუმართაობა და აღდგენა. სარეზერვო მარშრუტი, რომელიც ჩუმად გვერდს უვლის შემოწმებას, სხვა გადაწყვეტილებაა, ვიდრე დაგეგმილი fail-open პოლიტიკა და ჩვეულებრივ მხოლოდ ერთი მათგანია განზრახული. დასრულებული დიზაინი ასახელებს, სად მარშრუტიზდება თითოეული ტრაფიკის კლასი, სად მოწმდება და რა ხდება, როცა ეს შემოწმების გზა მიუწვდომელია.