სანამ OTV-ს დაამატებთ, ჩაწერეთ საჭირო Ethernet ხელშეკრულება

სამუშაო დატვირთვა გადადის მეორე მონაცემთა ცენტრში და იწყებს დროის ამოწურვას იმ სერვისზე, რომელიც პირველიდან კარგად პასუხობდა. ვიღაც გვთავაზობს OTV-ს, რადგან არსებული Layer 2 VPN «broadcast-ს არ აკეთებს». ეს დასკვნა, როგორც წესი, ნაადრევია. სერვისის კატეგორია და თქვენ მიერ შეძენილი კონკრეტული ხელშეკრულება ორი სხვადასხვა კითხვაა და დროის ამოწურვა ჯერ არც ერთ მათგანს არ მიკუთვნებია.

სიმპტომი, რომლითაც იწყება შედარება

ჩაწერეთ, რა სჭირდება აპლიკაციას სინამდვილეში, სანამ პროდუქტებს შეადარებთ. საიტების რაოდენობა, VLAN-ის ფარგლები, მისამართების სწავლა, flooding-ის ტოლერანტობა და წარუმატებლობის ქცევა აღწერს მოთხოვნას. «Layer 2» და «OTV» აღწერენ არქიტექტურებს და არც ერთი მათგანი თავისთავად მოთხოვნა არ არის. ხუთი თვისება ერთ გვერდზე გადაიტანს ნებისმიერ მომწოდებლის შედარებას.

შემდეგ შეამოწმეთ, აკმაყოფილებს თუ არა მიმდინარე სერვისი უკვე ამ ხუთ თვისებას. პროვაიდერის მიერ მართული Layer 2 VPN შეიძლება მოიცავდეს multipoint გადაცემას და საკონტროლო სიბრტყის სწავლას, რომლებიც ინვოისზე სწრაფ შეხედვას არ უხსენებია.

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

რას არ გეუბნებათ ეტიკეტი

Layer 2 VPN კატეგორიაა, არა პროდუქტი. წერტილიდან წერტილამდე VPWS და multipoint VPLS სხვანაირად გადასცემენ და კატეგორია მოიცავს როგორც საკონტროლო სიბრტყის სწავლისა და ციკლების მართვის მქონე სერვისებს, ისე უფრო მარტივებს. ვარაუდი, რომ ყოველი Layer 2 VPN ზუსტად ორ საიტს აკავშირებს და ყველაფერს flood-ავს, არასწორი შედარების გაკეთების გზაა. სახელი ხელშეკრულებაზე არაფერს ამბობს მის უკან არსებულ გადაცემის ცხრილზე.

ჰკითხეთ რომელი გადაცემის მოდელი დანერგა არსებულმა სერვისმა და რომელი სჭირდება აპლიკაციას. hub-and-spoke მოთხოვნა და full-mesh მოთხოვნა სხვადასხვა დიზაინს იძლევა, თუნდაც ორივე Layer 2-ად იყოს აღწერილი.

სად ხატავს OTV თავის საზღვარს

OTV მუშაობს IP ტრანსპორტზე, საკონტროლო სიბრტყის MAC ხელმისაწვდომობით და განსაზღვრული edge როლებით. ლოკალური spanning-tree ინფორმაცია ლოკალური რჩება, ნაცვლად იმისა, რომ ერთ უკონტროლო დომენად გაფართოვდეს ტრანსპორტზე. ეს რეალური განსხვავებაა უბრალო ხიდოვანი გაფართოებისგან და ეს არის მიზეზი, რის გამოც ხალხი მას მიმართავს.

საზღვარი ისეთივე მნიშვნელოვანია, როგორც სარგებელი. უცნობი unicast, broadcast და multicast-ის დამუშავება დამოკიდებულია პლატფორმასა და მის კონფიგურაციაზე, და edge წყვილმა უნდა ითანამშრომლოს მხარდაჭერილი multihoming მექანიზმით. ორი დამოუკიდებელი მოწყობილობა, რომლებიც ერთსა და იმავე VLAN-ს გადასცემენ, ერთი და იგივე დიზაინი არ არის და ისინი სხვა ავარიის რეჟიმს ქმნიან.

Flooding მცირდება, არ იშლება

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

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

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

ხელშეკრულება, რომელიც წერილობით უნდა მოითხოვოთ

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

ცვლილება აირჩიეთ მხოლოდ იმ მოთხოვნისთვის, რომელსაც მიმდინარე სერვისი ცხადად ვერ აკმაყოფილებს. VLAN-ის შემდგომი გაფართოება აპლიკაციისა და Ethernet-ის დამოკიდებულებებსაც აფართოებს მასთან ერთად; overlay-ის ახალი სახელი მათ არ აშორებს.

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