რატომ შეიძლება ერთმა EVPN მოიჯარემ რამდენიმე route distinguisher აჩვენოს
ორი RD ერთ მოიჯარეში კონფლიქტი არ არის. CLI-ის გამოსავლიდან გადადით იმ MAC-VRF ან IP-VRF-მდე, რომელმაც მარშრუტი შექმნა, შემდეგ შეამოწმეთ RT-ის იმპორტი და VNI.
თქვენ ფილტრავთ EVPN ცხრილს ერთი მოიჯარისთვის და მარშრუტები ორ სხვადასხვა route distinguisher-ს ატარებს. პირველი რეაქცია კონფიგურაციის კონფლიქტია და ეს რეაქცია ჩვეულებრივ მცდარია. მოიჯარის სახელი ბიზნეს ეტიკეტია, არა მართვის სიბრტყის ერთი ობიექტი, ამიტომ მის შიგნით არსებულ ხიდის კონტექსტს და მარშრუტიზაციის კონტექსტს კანონიერად შეუძლია ცალკე იდენტიფიკატორებით გამოცხადება. გაიარეთ ერთი მარშრუტი ყოველ ჯერზე გამოსავლიდან უკან იმ ლოკალურ სერვისის ობიექტამდე, რომელმაც ის შექმნა, და მეორე RD შეწყვეტს შეცდომის მსგავსად ჩვენებას.
დაიწყეთ იმ გამოსავლიდან, რომელმაც დაგაბნიათ
აირჩიეთ ერთი მარშრუტი და არა მთელი ცხრილი. ჩაიწერეთ მისი მარშრუტის ტიპი, RD, ექსპორტირებული route target-ები და შემდეგი ჰოპი. ეს ოთხი ველი საკმარისია იმის დასადგენად, რომელმა ლოკალურმა ობიექტმა გამოაცხადა ის და რომელმა დისტანციურმა პოლიტიკამ უნდა შემოიტანოს ის.
NX-OS სტილის მოწყობილობაზე დეტალური ხედი მიიღწევა ბრძანებით show bgp l2vpn evpn route-type 2 detail ან show bgp l2vpn evpn route-type 5 detail. Junos-ზე იგივე ინფორმაცია არის show route table bgp.evpn.0 detail-ში. განსხვავებული სინტაქსი, იგივე ველები.
ნუ დაიწყებთ ყველა ნაჩვენები რიცხვის ტოლად ქცევით. RD-ების გათანაბრება ის ცვლილებაა, რომელიც ამტვრევს იმპორტის პოლიტიკას მოქმედ fabric-ზე.
მიეცით თითოეულ იდენტიფიკატორს თავისი საქმე
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF ინახავს MAC-გადაგზავნის ინფორმაციას ხიდის სერვისისთვის. IP-VRF უზრუნველყოფს IP მარშრუტიზაციის კონტექსტს მარშრუტიზებული სერვისისთვის. მოიჯარეს შეუძლია ორივეს მოცვა, ამიტომ ერთ მოიჯარეს შეუძლია ერთზე მეტი RD შექმნას ყოველგვარი კონფიგურაციის შეცდომის გარეშე.
RFC 7432 ანიჭებს გამომცხადებელი MAC-VRF-ის RD-ს მის EVPN NLRI-ს და მოითხოვს განსხვავებულ RD-ებს ერთი და იმავე PE-ის MAC-VRF-ებს შორის. Route-target პროცედურები ცალკეა: ისინი უშვებენ ერთ ან მეტ RT ატრიბუტს და წევრობისთვის ეყრდნობიან იმპორტის პოლიტიკას. საერთო წევრობას RD-ების თანასწორობა არ ქმნის და ასე მოპყრობა ამ დაბნეულობის ფესვია.
გაიარეთ ერთი მარშრუტი გამოცხადებიდან იმპორტამდე
მიჰყევით მარშრუტს ერთი მიმართულებით. დაადასტურეთ მარშრუტის ტიპი, შემქმნელი სერვისი, RD, ექსპორტირებული RT-ები და შემდეგ მიმღები PE-ის იმპორტის პოლიტიკა. თითოეული ნაბიჯი სხვადასხვა კითხვას პასუხობს და ნებისმიერ ნაბიჯზე ჩავარდნა მეორე მხარეს იმავე დაკარგული პრეფიქსის მსგავსად ჩანს.
როცა მარშრუტი არსებობს, შეამოწმეთ დაყენებული გადაგზავნის კონტექსტი და VNI-ის რუკა. VNI-ის დამთხვევა ორივე ბოლოში აჩვენებს, რომ მონაცემთა სიბრტყე თანახმაა; ის არ აჩვენებს, რომ მართვის სიბრტყემ მარშრუტი განზრახული პოლიტიკით შემოიტანა.
თუ მარშრუტი ჩნდება დისტანციურ PE-ზე, მაგრამ ტრაფიკი არ მიედინება, პრობლემა EVPN-ს გასცდა. შეამოწმეთ VNI-VLAN ან VNI-VRF კავშირი და underlay გზა სანამ კვლავ შეცვლით route target-ებს. დაიწყეთ რუკით, შემდეგ underlay-ით და მხოლოდ ამის შემდეგ მართვის სიბრტყით. Route-target ცვლილების უკან დაბრუნება მონაცემთა სიბრტყის ხარვეზის დევნისთვის საიმედო გზაა მოქმედი იმპორტის გასატეხად.
ფენა 3-ის პრეფიქსები კვლავ EVPN მარშრუტებია
EVPN ცხრილში IP პრეფიქსი ჩვეულებრივი IPv4-unicast BGP არ არის. EVPN IP Prefix მარშრუტი საკუთარი მარშრუტის ტიპია, ხოლო MAC/IP და IP-პრეფიქსის გამოცხადებები მოძრაობენ EVPN მისამართების ოჯახში, რომელსაც RFC 7432 AFI 25 და SAFI 70-ად განსაზღვრავს.
ეს განსხვავება მნიშვნელოვანია, როცა EVPN ცხრილის მარშრუტს ადარებთ unicast ცხრილის მარშრუტს. მათ შეუძლიათ აღწერონ ერთი და იგივე დანიშნულება და მაინც სხვადასხვა პოლიტიკით შეიქმნან, გაიფილტრონ და შემოიტანონ. ერთის მეორეზე მტკიცებულებად წაკითხვა იმიტომ ხდება, რომ სწორი fabric მიგრაციის დროს გატეხილად გამოიყურება.
რიცხვების შედარებამდე შეამოწმეთ მწარმოებლის გამოყვანა
RFC 9136 აფართოებს EVPN-ს IP Prefix მარშრუტებით და განსაზღვრავს, მოქმედი RD მოდის MAC-VRF თუ IP-VRF კონტექსტიდან. ამიტომ ერთ გამოსავალში L2 სერვისის ეტიკეტი და მარშრუტიზებული სერვისის ეტიკეტი უნდა წაიკითხოს იმ ობიექტების მიმართ, რომლებსაც ეკუთვნის, და არა შემცირდეს ერთ RD-მდე თითო მოიჯარეზე.
RD-ისა და RT-ის ავტომატური გამოყვანა მწარმოებელზეა დამოკიდებული. წაიკითხეთ დანერგილი მწარმოებლის ცნობარი გამოყენებული ფორმულის შესახებ; ერთ კომუტატორზე დანახული ავტომატურად გენერირებული მნიშვნელობა უნივერსალური კოდირება არ არის და ორი მწარმოებლის რიცხვების შედარება იშვიათად რამეს ამტკიცებს.
დაასრულეთ წერილობითი კვალით იმ მარშრუტისთვის, რომლითაც დაიწყეთ: ტიპი, შემქმნელი ობიექტი, RD, ექსპორტირებული RT, იმპორტის პოლიტიკა, დაყენებული VNI. ექვსი ველი ხსნის გამოცხადებას ყველასთვის, ვინც შემდეგ წაიკითხავს ბილეთს და არც ერთი მათგანი არ მოითხოვს მოიჯარის რიცხვების დამთხვევას.