რა უნდა დაემთხვეს, სანამ MX შეძლებს IPsec-ის დასრულებას
კონფიგურაციის მიმღები commit ამტკიცებს პარსერს და არა გზას. პლატფორმის კორტეჟის ხუთი ნაწილი წყვეტს, ნამდვილად მუშაობს თუ არა სერვისი.
კონფიგურაცია სუფთად commit-დება, ინტერფეისები ადის, ხოლო გვირაბი კვლავ უარყოფს დამყარებას. ლოგში არც ერთი სტრიქონი არ ამბობს, რომ პლატფორმას ეს არ შეუძლია; ის უბრალოდ არ აკეთებს ამას. Junos-ზე IPsec არის სერვისი, რომლის შესრულებაც მხოლოდ კორპუსის, სერვისული ტექნიკის ან პროგრამული გზისა და გამოშვების გარკვეულ კომბინაციას შეუძლია, და ფუნქციის გვერდი აღწერს პროგრამული უზრუნველყოფის შესაძლებლობას და არა თქვენს მოწყობილობას. კორტეჟი ნაწილ-ნაწილ უნდა შემოწმდეს, რადგან commit-ის შედეგი მხოლოდ პარსერს ამტკიცებს.
სად მიდის პაკეტი სინამდვილეში
IPsec-ისთვის შერჩეული ტრაფიკი უნდა მიაღწიოს იმ კომპონენტს, რომელიც მას შიფრავს. სერვისული მოდულის მქონე პლატფორმებზე შერჩეული ნაკადი მიმართულია ამ მოდულზე და შემდეგ უბრუნდება გადამისამართების გზას. თუ მოდული არ არსებობს, არასაკმარისია ან არ არის მიბმული ინტერფეისზე, კონფიგურაცია არსებობს და ვერც ერთი პაკეტი ვერ მუშავდება. commit-ის გამოსავალში არაფერი განასხვავებს ამ შემთხვევას ჯანსაღისგან.
პროგრამულ უზრუნველყოფაში განთავსებული იმპლემენტაციები სამუშაოს ტოვებენ მარშრუტიზაციის ძრავაზე ან ჩაშენებულ ტექნიკაში, რესურსების ლიმიტები ძალიან განსხვავებულია. კონფიგურაციაში ხილული გვირაბი არ გეუბნებათ, რომელი ამ გზებიდან რეალურად ატარებს მას.
კორტეჟის ხუთი ნაწილი
ჩაწერეთ კომბინაცია, სანამ რაიმე რეკომენდაციას წაიკითხავთ, რადგან ერთმა ნაწილმა შეიძლება სხვები გააუქმოს. ნაწილის ნომერი, რომელიც სამი წლის წინ სერვისს მხარს უჭერდა, არაფერს ამბობს ამ კორპუსში არსებულ ბარათსა და გამოშვებაზე. წაიკითხეთ ქვემოთ მოცემული სტრიქონები როგორც შემოწმების სია, შემდეგ შეავსეთ ის მნიშვნელობები, რომლებსაც კონფიგურაცია ვერ გაჩვენებთ.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
მისამართების ოჯახები და დატვირთვა არის ის ორი სტრიქონი, რომლებსაც ხალხი გამოტოვებს, და ორივე იაფია შესამოწმებლად და ძვირი გვიან აღმოსაჩენად. წაიკითხეთ კორტეჟი მოწყობილობიდან და არა ცხრილიდან, რადგან კონფიგურაცია იტყობინება, რაც მოითხოვეთ და არა რაც დაყენებულია. უმეტეს ნაწილს ორი ბრძანება ატარებს: show chassis hardware ასახელებს რეალურად ჩასმულ ბარათს, ხოლო show version იძლევა ზუსტ გამოშვებას. არც ერთი მათგანი არ არის დამოკიდებული იმაზე, სწორია თუ არა კონფიგურაცია, და სწორედ ეს არის არსი.
show chassis hardware
show versionგამოშვების ზღურბლები ნამდვილი ზღურბლებია
გამოშვების დეტალი ფორმალობა არ არის. Juniper-ის IPsec მიმოხილვა მრავალსერვისული ბარათებისთვის AES-GCM-ის მხარდაჭერას Junos 17.3R1-ზე ათარიღებს, ხოლო FIPS რეჟიმი 17.4R1-დან იწყება. ამიტომ ერთსა და იმავე ფუნქციას ორი ზღურბლი აქვს იმის მიხედვით, როგორ მუშაობს პლატფორმა, და თქვენს მიერ გაშვებული რეჟიმი წყვეტს, რომელი მოქმედებს. შეამოწმეთ რეჟიმი, სანამ ფუნქციების სიას შეამოწმებთ.
წაიკითხეთ გამოშვების შენიშვნები ზუსტად დაყენებული ვერსიისთვის და არა ყველაზე ახალი დოკუმენტირებულისთვის. შესაძლებლობა, რომელიც გვიან build-ში მოვიდა, არ შეიძლება ჩაითვალოს ადრეულში არსებულად, და ერთი ბარათისთვის დაწერილი განაცხადი მეორეზე არ გადადის. დააკოპირეთ გამოშვების შენიშვნის სტრიქონი დიზაინის ჩანაწერში, რათა განაცხადმა თავისი წყარო თან იქონიოს, რადგან პლატფორმათა ოჯახისთვის დაწერილი მხარდაჭერის განაცხადი არ არის განაცხადი იმ რეჟიმზე, რომელშიც მუშაობთ, ან ბარათზე, რომელიც გაქვთ.
ტევადობა დატვირთვაა და არა სათაური
სათაურში მოცემული გამტარუნარიანობის ციფრი გაზომვის პირობების გარეშე მარკეტინგული რიცხვია. პატარა პაკეტები ბიტზე გაცილებით ძვირია, ვიდრე დიდი, ერთდროული ასოციაციები მეხსიერებას ხარჯავს, და ბარათის გამზიარებელი ნებისმიერი სხვა სერვისი ამცირებს დარჩენილს.
შეაფასეთ მოსალოდნელი ტრაფიკიდან: ტიპიური და ყველაზე ცუდი პაკეტის ზომები, peer-ების რაოდენობა და ამთავრებს თუ არა ეს ბარათი ასევე NAT-ს ან სხვა სერვისს. შემდეგ დატოვეთ რეზერვი იმ დღისთვის, როცა ერთი გზა დიზაინის ვარაუდზე მეტ დატვირთვას ატარებს. ტევადობის გეგმა, რომელიც უმოქმედო ტექნიკას ითვალისწინებს, სურვილია და არა გეგმა. თუ ციფრს ბიზნეს-დასაბუთებისთვის მნიშვნელობა აქვს, გაზომეთ ის ერთხელ მოწყობილობაზე წარმომადგენლობითი დატვირთვის ქვეშ და შეინახეთ ეს გაზომვა დიზაინთან ერთად.
დაწერეთ ჩანაწერი დიზაინამდე
დიზაინისთვის საჭირო ყოველი შესაძლებლობისთვის შეინახეთ პლატფორმის მითითება, გამოშვების შესაბამისი დოკუმენტაცია და ნებისმიერი გადაუჭრელი შეზღუდვა ერთ ადგილას. სადაც კორტეჟის რომელიმე სტრიქონი ვერ სრულდება, შეადარეთ ცალკე დამტკიცებულ კარიბჭეს, ნაცვლად იმისა, რომ დიზაინი მოძველებული შესყიდვების სიის გარშემო თავიდან ააგოთ. ჩანაწერმა უნდა თქვას, რომელი ზუსტი სისტემა ასრულებს სამუშაოს და რა ფარგლებში.
მხოლოდ ამის შემდეგ შეამოწმეთ peer, რადგან შორეულ ბოლოსთან პროტოკოლის თავსებადობა შემდეგი კითხვაა და არასოდეს ცვლის ლოკალურ მხარდაჭერას. peer, რომელიც წინადადებებზე თანხმდება, მაინც ვერ დაეხმარება კორპუსს, რომელიც არასოდეს შიფრავს პაკეტს.