Junos L2VPN: ჯერ კლიენტის მიერთების ხელშეკრულება მოაწესრიგე

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

ჩამოწერე კადრის ხელშეკრულება

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

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

ინკაფსულაცია ხელშეკრულებას შეუსაბამე

ერთი ნიშნის მქონე სერვისი ჩვეულებრივ იყენებს VLAN წრედის ინკაფსულაციას, მაგალითად vlan-ccc, ხოლო უნიშნო კადრებს სჭირდება Ethernet წრედის უბრალო ფორმა, სტეკს კი ორი ნიშნის გამგებელი გაფართოებული ვარიანტი. პლატფორმაზე, რომელიც ერთეულზე სერვისის ინკაფსულაციას უჭერს მხარს, ერთ ფიზიკურ ინტერფეისს შეუძლია რამდენიმე ერთდროულად დაატიოს, რაც მოსახერხებელია და ამავდროულად ის გზაა, რომლითაც კადრი არასწორ ერთეულში ხვდება. სადაც შენი პლატფორმის გზამკვლევი მოითხოვს family ccc, დააკონფიგურირე ის სრული მიერთების ნაწილად და არა მარშრუტიზებულ ინტერფეისზე მიხრახნე. ინკაფსულაციის გზამკვლევი ჩამოთვლის, რომელი ტიპის მიერთება რა მოთხოვნებს აყენებს.

სიფრთხილისთვის ყოველ ინტერფეისს family განაცხადი არ დაუმატო. კონფიგურაციამ, რომლის წყალობითაც ერთი წრედი მუშაობს, შეიძლება შემდეგი აიძულოს ისეთი კადრები მიიღოს, რომლებსაც მისი კლიენტი არასდროს აგზავნის.

მიერთება სწორ სერვისზე მიაბი

BGP-ით სიგნალიზებული მე-2 დონის VPN, LDP-ით სიგნალიზებული წრედი და სხვა მხარდაჭერილი სერვისები თითოეულს თავისი ინტერფეისის მიბმისა და სიგნალიზაციის კონფიგურაცია აქვს და ისინი ურთიერთშემცვლელნი არ არიან. ერთის მიერთების სტილის მეორის სიგნალიზაციასთან შერევა იძლევა წრედს, რომელიც peer-ზე იტყობინება და არასდროს გადასცემს კადრს.

შეადარე შორეული ბოლო ახლო ბოლოს, ნაცვლად იმისა, რომ რომელიმე მათგანი იზოლირებულად განიხილო: peer-ის მისამართი, სერვისის იდენტიფიკატორი, ინკაფსულაციის შეთანხმება, control word-ის მოლოდინი და ზომის ბიუჯეტი. MPLS-ის ქვედა ფენა შეიძლება სრულიად ჯანმრთელი იყოს, სანამ მიერთება აკლია ან სხვაგანაა კლასიფიცირებული; ამიტომ მხოლოდ ქვედა ფენაზე მიმხედველი ტესტი აქ არაფერს ამტკიცებს.

გადაამოწმე კადრით და არა სტატუსით

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

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

შემდეგ ეს ჩაწერე

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

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