ეთიკეტის გარეშე წვდომის პორტის სწორ EVPN VNI-ზე მიბმა

ჩვეულებრივი Ethernet ჰოსტი ეთიკეტის გარეშე კადრებს აგზავნის და EVPN ქსოვილმა მაინც სწორ მოიჯარე მომსახურებაში უნდა გადაიტანოს ისინი. წვდომის პორტი კადრს ლოკალურ სეგმენტად აკლასიფიცირებს, VTEP ამ სეგმენტს VNI-ზე აბამს, ხოლო დისტანციური მიერთება კადრს ისე წარმოადგენს, როგორც მისი ჰოსტი ელოდება. VLAN და VNI ამ გზის სხვადასხვა ნაწილს აღნიშნავენ და მათ არ სჭირდებათ საერთო ნომერი. შეასრულეთ ქვემოთ მოცემული runbook თანმიმდევრობით, რადგან ნებისმიერ საფეხურზე შეცდომა იმავე სიმპტომს იძლევა: ჰოსტი აგზავნის და ვერაფერს იღებს.

ერთი კადრის ქსოვილში თვალყურის დევნება

VLAN-ზე დაფუძნებული მარტივი მომსახურებისთვის საილუსტრაციო გზა ასე გამოიყურება:

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

VLAN და VNI ნომრები მაგალითებია და არა წესი. ლოკალური VLAN არის შესვლის კლასიფიკაცია, რომელიც ერთ კომუტატორზე არსებობს; L2VNI არის overlay მომსახურების იდენტიფიკატორი, რომელსაც ორივე VTEP ესმის. Overlay სპეციფიკაცია RFC 8365 მომსახურების იდენტიფიკატორს ჰოსტის მიერთების წესისგან ცალკე ინახავს და სამ ფორმას ასახელებს: VLAN-ზე დაფუძნებული, დაჯგუფებული და VLAN-ის მცოდნე.

შესვლის კლასიფიკაციის კონფიგურაცია

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

ტიპიურ კომუტატორზე თანმიმდევრობაა რეჟიმის შეცვლა და წვდომის VLAN-ის მინიჭება, რასაც მოჰყვება შემოწმება, რომ პორტი ნამდვილად ჩართულია და ამ მდგომარეობაშია. თუ პორტი trunk-ია, ეთიკეტის გარეშე კადრებს native VLAN ამუშავებს და ეს სხვა კონფიგურაციაა სხვა უკმარისობის რეჟიმებით. ჩაწერეთ როგორც რეჟიმი, ისე VLAN, სანამ გააგრძელებთ.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

VTEP-ის და VNI-ის შესაბამისობის კონფიგურაცია

VTEP ამატებს VXLAN ინკაფსულაციას და VNI-ს. ჰოსტი ამ სათაურს არ ქმნის და არ სჭირდება იცოდეს, რომ მომსახურება არსებობს.

დააბით ლოკალური VLAN L2VNI-ზე პლატფორმის მიერ მხარდაჭერილი ბრძანების ფორმით და შეინარჩუნეთ ეს შესაბამისობა მომსახურების ორივე ბოლოში ერთნაირი. მოიჯარის L2VNI და ქვექსელებს შორის მარშრუტიზაციისთვის გამოყენებული L3VNI სხვადასხვა ობიექტია და მათი ნომრების შერევა ამტვრევს მარშრუტიზაციას L2 გზის შეხების გარეშე; და გახსოვდეთ, რომ დისტანციურ VTEP-მდე მოქმედი underlay მარშრუტი კონფიგურაციის კიდევ ერთ ფენას ეკუთვნის.

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

გასვლის წარდგენის კონფიგურაცია

დისტანციურ ბოლოში მიღებული მომსახურება იმაში უნდა გადაიქცეს, რასაც ჰოსტი ელოდება: შიშველი Ethernet წვდომის პორტზე, კონკრეტული ტეგი თქვენს მიერ კონტროლირებულ trunk-ზე და შიდა ტეგის დამუშავება, რომელიც შეესაბამება არჩეულ მომსახურების მოდელს. შეამოწმეთ trunk-ზე დაშვებული VLAN-ების სია, სანამ overlay-ს დაადანაშაულებთ, რადგან ტეგი, რომელსაც გასვლის trunk არ უშვებს, უგულებელყოფილია მას შემდეგ, რაც overlay-მა უკვე შეასრულა თავისი საქმე. დაადასტურეთ, რომ დისტანციური ჰოსტი ელოდება იმ წარდგენას, რომელსაც იღებს და არა იმას, რაც თქვენმა დიაგრამამ ივარაუდა.

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

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

ერთი ჰოსტის წყვილით გადამოწმება

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

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

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