მშვიდი EVPN ჰოსტი არასოდეს იხსნება: მიჰყევით ARP-ს ბმამდე

საბოლოო წერტილი მიერთებულია, მისი პორტი აქტიურია და მონიტორინგის ჰოსტი მაინც ვერ აღწევს მას. ვიღაც მეორე მხრიდან ping-ს უშვებს და ის მუშაობას იწყებს, რაც პრობლემას წყვეტილად აჩენს, ხოლო fabric-ს — უდანაშაულოდ. ეს ნიმუში მშვიდი ჰოსტის ნიშანია: ის იშვიათად აგზავნის, ამიტომ fabric-ის აღმოჩენისა და განახლების ქცევა უფრო მნიშვნელოვანია, ვიდრე მისი მიერთების მდგომარეობა. დაიწყეთ ერთი სამიზნე IP-ით, MAC-ით და bridge domain-ით და მიჰყევით შემდეგ გადაწყვეტის გაცვლას.

მიჰყევით შემდეგ ARP ან ND გაცვლას

IPv4-ისთვის დააკვირდით მოთხოვნის გამომგზავნი ჰოსტის ARP გაცვლას; IPv6-ისთვის მიჰყევით Neighbor Solicitation-ს და Advertisement-ს. დაადასტურეთ, რომ მოთხოვნა შედის სამიზნე ლოკალურ სეგმენტში და სამიზნე VNI-ში, რადგან მოთხოვნას, რომელიც არასოდეს აღწევს სწორ bridge domain-ს, ვერც ერთი პროქსი ვერ უპასუხებს.

შემდეგ შეხედეთ, რა იცის fabric-მა სამიზნის შესახებ. მხოლოდ MAC მარშრუტს შეუძლია Layer 2 დანიშნულების იდენტიფიცირება, მაშინ როცა პროქსის ჯერ არ აქვს IP-to-MAC ბმა მისთვის. ეს ცალკე ჩანაწერებია და ერთის შემოწმება მეორეზე არაფერს ამბობს.

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

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

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

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

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

რას უშვებს სტანდარტი სინამდვილეში

RFC 9161 აღწერს პროქსის დინამიკურ სწავლას და უცნობი ARP და ND მოთხოვნების ნაგულისხმევ flooding-ს. ამ flooding-ის სრული ჩახშობა შემოიფარგლება იმ განლაგებებით, რომელთა სწავლის ან მომარაგების ვარაუდები მას უსაფრთხოს ხდის, რაც უფრო ვიწრო პირობაა, ვიდრე კონფიგურაციის სახელმძღვანელოების უმეტესობა მიანიშნებს.

fabric-ს, რომელიც ახლად აღმოჩენილ საბოლოო წერტილებს ელოდება, სჭირდება მუშა გზა ამ მოთხოვნებისთვის. თუ ვინმემ BUM ტრაფიკის შესამცირებლად გამორთო უცნობი მოთხოვნების flooding, მშვიდი ჰოსტები არიან ის პოპულაცია, რომელიც ამის ფასს იხდის, და სიმპტომი კვირების შემდეგ მოდის როგორც წყვეტილი ხელმისაწვდომობის საჩივარი.

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

განახლება, დაძველება და სტატიკური ალტერნატივა

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

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

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

რა უნდა ჩაიწეროს შემდეგ ბილეთამდე

შეინახეთ ბმის წყარო, ბოლო განახლების დრო, მიმდინარე მდებარეობა და ნებისმიერი გატანის მოვლენა MAC მარშრუტის გვერდით. ეს ჩანაწერი პასუხობს კითხვას, რომელსაც ბილეთი სინამდვილეში სვამს: ელოდება აპლიკაცია აღმოჩენას, ეყრდნობა მოძველებულ მდგომარეობას, თუ ვერ ახერხებს გადამისამართებას წარმატებული გადაწყვეტის შემდეგ?

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