იგივე iESI საიტის შიგნით, უნიკალური საიტებს შორის: Junos-ის ნაკერი
ერთი interconnect ESI აკავშირებს საიტს მომსახურე კარიბჭეებს; მეორე საიტს საკუთარი სჭირდება. peer-განაცხადი, რომელიც ამ იდენტობას ატარებს, გამოცემებს შორის გადავიდა.
კარიბჭეების ორი წყვილი ორ მონაცემთა ცენტრს ემსახურება და ვინმემ უნდა გადაწყვიტოს, რამდენი interconnect ESI მნიშვნელობა სჭირდება დიზაინს. პასუხია ერთი კარიბჭეთა ჯგუფზე, არა ერთი fabric-ზე და არა ერთი კარიბჭეზე. ამის არასწორად გაკეთება ქმნის fabric-ს, რომელიც კონფიგურირებულად გამოიყურება და არასწორ forwarder-ს ირჩევს, ან აერთიანებს ორ საიტს, რომლებიც ცალკე უნდა დარჩენილიყო. წესი და მისი გამონაკლისები ღირს კარიბჭეების სიის გვერდით ჩაწერად.
ორი არე, ორი წესი
საიტის შიგნით, ზედმეტი interconnect კარიბჭეები ერთ multihomed ბოლო წერტილად მოქმედებენ, ამიტომ ისინი ერთ interconnect ESI-ს იზიარებენ. მათ peer-ებმა უნდა დაინახონ ერთი ლოგიკური წევრი და არა ორი დამოუკიდებელი. ეს არის საერთო მნიშვნელობის მთელი არსი.
საიტებს შორის, თითოეული კარიბჭეთა ჯგუფი თავის მნიშვნელობას იღებს. ორი მონაცემთა ცენტრი, რომლებიც ერთ იდენტიფიკატორს იზიარებენ, კონტროლის სიბრტყეში ერთ multihomed ჯგუფად იქცევიან, რაც ჩვეულებრივ არ არის ის, რასაც WAN-ის გავლით ნაკერის დიზაინი გულისხმობს. ერთ ჯგუფში მყოფი ორი საიტი ასევე ერთმანეთის უკმარისობის რეჟიმებს მემკვიდრეობით იღებს.
საიტის შიგნით: ერთი იდენტობა ჯგუფისთვის
მიეცით წყვილს იგივე მნიშვნელობა ორივე peer-ზე, იმავე სერვისის კონტექსტში, და ჩაწერეთ ის ქსელის იდენტიფიკატორების ინვენტარში და არა ჩატის ნაკადში. ორ წევრს შორის შეუთანხმებლობა არის უკმარისობის რეჟიმი, რომელიც ერთწევრიან ჯგუფს და აშკარა განგაშის გარეშე ტოვებს. შეადარეთ ორივე წევრი, სანამ იმუშავებს სესიას დაიჯერებთ.
მხარდაჭერილი მოდელია all-active. იგივე ცნობარი გამორიცხავს single-active ოპერაციას, ავტომატურად გამოყვანილ LACP იდენტიფიკატორებს და source-bmac ოფციებს ამ ნაკერის იდენტობისთვის, ამიტომ დიზაინი, რომელიც ერთ-ერთ მათგანს ვარაუდობდა, გადასინჯვას საჭიროებს იდენტიფიკატორის არჩევამდე. ეს შეზღუდვა დიზაინის შეტანაა და არა სქოლიო.
საიტებს შორის: სხვადასხვა მნიშვნელობა, ან განზრახ გაერთიანება
საიტზე უნიკალური მნიშვნელობა ორ კარიბჭეთა ჯგუფს ცალ-ცალკე ინახავს. თუ განზრახვა ნამდვილად ერთი multihomed ჯგუფის საიტებს შორის გაფართოებაა, ეს სხვა არქიტექტურაა, თავისი შედეგებით დაყოვნების, უკმარისობისა და გადაცემისთვის, და მასზე არქიტექტურად უნდა გადაწყდეს და არა იდენტიფიკატორის არჩევნად. მოითხოვეთ ეს გადაწყვეტილება წერილობით ტექნიკური მომსახურების ფანჯრამდე.
ჩაწერეთ განზრახული განსხვავება გეგმაში, რომ მოგვიანებით მომუშავე საიტის შაბლონის კოპირებისას ინჟინერმა მისი იდენტიფიკატორიც არ შემოიტანოს.
peer განაცხადი იდენტობის ნაწილია
ჯგუფის თითოეული კარიბჭე თავის ლოკალურ peer-ებს loopback მისამართით ჩამოთვლის და ეს ურთიერთობა გლობალურ EVPN დონეზე ცხოვრობს და არა ცალკეული MAC-VRF-ის შიგნით. მისი არასწორ იერარქიაში მოთავსება გავრცელებული გზაა იმისა, რომ შეიქმნას კონფიგურაცია, რომელიც commit-დება, მაგრამ ჯგუფს არასოდეს ქმნის. წაიკითხეთ საცნობარო იერარქია ერთხელ და შემდეგ დაიცავით ის.
განაცხადის სახელიც გადავიდა. Juniper-მა გადაარქვა სახელი interconnect peer-gateways განაცხადს 24.2R1-ში და აღადგინა interconnect-სპეციფიკური ფორმა მონაცემთა ცენტრების interconnect-ისთვის 24.4R1-ში. ამიტომ შუალედური გამოცემიდან აღებულმა ფრაგმენტმა შეიძლება გამოიყენოს სახელი, რომელსაც განლაგებული ვერსია არ იღებს, ან პირიქით. ჩაწერეთ გამოცემა, საიდანაც ფრაგმენტია, თავად ფრაგმენტის გვერდით.
რას არ აკეთებს iESI-ის გაზიარება
ის არ განსაზღვრავს თქვენთვის route target-ებს, VNI-ებს ან ლოკალურ EVPN ინსტანციას. ისინი ცალკე კონფიგურაციად რჩება, რომელიც ორივე მხარეს უნდა დაემთხვეს, და იდენტიფიკატორი, რომელიც ემთხვევა, მაშინ როცა route target არ ემთხვევა, ქმნის ჯგუფს, რომელიც ყალიბდება და არაფერს ატარებს. შეადარეთ ამ პარამეტრების ორივე მხარე ერთ გავლაში.
ის ასევე არ ამტკიცებს peer-ების ხელმისაწვდომობას ან designated forwarder-ის არჩევას. გამოსცადეთ unicast და საჭირო broadcast და multicast ქცევა ნორმალურ შემთხვევაში, შემდეგ გაიმეორეთ ერთი კარიბჭის მოცილებით, რომ დარჩენილმა წევრმა ჯგუფი მარტომ ატაროს.
სწორედ მეორე გაშვება ამტკიცებს, რომ ჯგუფი რეალურია.
შეინახეთ დაკვირვებული წევრობა და სერვისის კონტექსტი ტესტების შედეგებთან ერთად. მოგვიანებით იდენტიფიკატორის ცვლილება მაშინ შეიძლება განიხილოს როგორც multihoming ცვლილება, რაც სინამდვილეში არის, და არა როგორც სტრიქონის კოსმეტიკური რედაქტირება. შედეგები ერთადერთი მტკიცებულებაა, რომ იდენტიფიკატორი აკეთებს იმას, რასაც ნახაზი ამბობს.