საინჟინრო გადაწყვეტა · IPoE და LANBilling
როგორ გავარკვიეთ გაჭედილი IPoE-სესიების მიზეზი და როგორ გავხადეთ წვდომის აღდგენა ავტომატური
აბონენტი რეკავს: ინტერნეტი არ არის. როუტერი გადატვირთეს, კაბელი ადგილზეა, ოპტიკური სიგნალი ნორმაშია. ავტორიზაციის ჟურნალში კი ისევ და ისევ ერთი და იგივე ჩანაწერია — AlreadyConnected. ბილინგი დარწმუნებულია, რომ აბონენტი ისედაც დაკავშირებულია.
ჩვეულებრივი სესია
Accounting-Update რამდენიმე წუთში ერთხელ
Accounting-Stop დაიკარგა
ავარია, კავშირის გაწყვეტა ან ბილინგის გადატვირთვა
მდგომარეობები გაიყო
უარი: AlreadyConnected
მოწყობილობა ისევ ითხოვს ქსელში შესვლას, ბილინგი კი პასუხობს: ეს აბონენტი უკვე დაკავშირებულია
IPoE-ქსელში ჩვეულებრივი გაგებით ლოგინი და პაროლი არ არსებობს. წვდომის სერვერი ხედავს მოწყობილობას, RADIUS-ით ეკითხება ბილინგს და Access-Accept-ის შემდეგ ხსნის სესიას. რამდენიმე წუთში ერთხელ ის Accounting-Update-ს აგზავნის, გათიშვისას კი — Accounting-Stop-ს, და მაშინ LANBilling სესიას თავის მხარეს ხურავს. სანამ შეტყობინებები აღწევს, ჩანაწერები წვდომის სერვერზე და ბილინგში ემთხვევა.
ბილინგი გადაიტვირთა, სერვერებს შორის კავშირი გაწყდა, წვდომის სერვერმა ავარიის შემდეგ სესიები დაკარგა — და Accounting-Stop არ მივიდა. წვდომის სერვერს სესია უკვე დავიწყებული აქვს, LANBilling კი მას ღიად ინახავს. აბონენტის მოწყობილობა ისევ ითხოვს ქსელში შესვლას, ბილინგი კი უარს ეუბნება მიზეზით AlreadyConnected: მისი მონაცემებით აბონენტი ისედაც დაკავშირებულია.
როუტერის ან ONU-ს გადატვირთვა ახალ მოთხოვნას იძლევა, მაგრამ ბილინგში ღია სესია რჩება და უარი მეორდება. გაჭედილი სესიის ტაიმაუტი ჩვენს კონფიგურაციაში ერთი დღე-ღამეა და ამის შემდეგაც სესია თავისით არ იხურება. ბილინგიდან სტანდარტული Disconnect-იც არ შველის: წვდომის სერვერმა ასეთი სესია არ იცის და Disconnect-NAK-ით პასუხობს, ბილინგი კი ჩანაწერს ღიად ტოვებს.
პორტალში უკვე იყო ავტომატიკა ბილინგის გადატვირთვის შემდეგ აღსადგენად: ის წვდომის სერვერზე შლიდა კლიენტების მოძველებულ ჩანაწერებს, რომ მოწყობილობას ავტორიზაცია თავიდან გაევლო. ტექმომსახურების შემდეგ მან თხუთმეტი აბონენტი იპოვა წვდომის გარეშე, იმუშავა — და შემდეგ ციკლზე ისევ იგივე თხუთმეტი იპოვა. ასე გაგრძელდა ერთ საათზე მეტხანს, შეცდომებისა და ინჟინრისთვის შეტყობინების გარეშე. თხუთმეტივე სესია ბილინგში ღიად დარჩა, მათი აქაუნთინგი გაჩერებამდე რამდენიმე წუთით ადრე შეწყდა, ამ ჩანაწერს კი ავტომატიკა არაფერს უკეთებდა.
სტანდარტულმა Disconnect-მა Disconnect-NAK დააბრუნა. მონაცემთა ბაზის ცხრილების პირდაპირ შესწორებაზე უარი ვთქვი: ეს ბილინგის ლოგიკას გვერდს უვლის. LANBilling-ის API-ში არის მეთოდი, რომელიც RADIUS-სესიას მისი ზუსტი რეკვიზიტებით ასრულებს. პირველმა გამოძახებამ „წარმატებით“ უპასუხა, მაგრამ სესია დარჩა: მოთხოვნის მომზადებისას წვდომის სერვერის მისამართი ცარიელ მნიშვნელობად იქცეოდა. მას შემდეგ წარმატებად მხოლოდ განმეორებითი წაკითხვა ითვლება, რომელშიც სესია აღარ არის. გასწორებული გამოძახება ჯერ ერთ აბონენტზე გავუშვი, აქაუნთინგის სრულ ინტერვალს დაველოდე და მხოლოდ ამის შემდეგ — დანარჩენ თოთხმეტზე. წვდომა ყველას დაუბრუნდა.
პირველი ავტომატური ვერსია კანდიდატებს წვდომის სერვერთან შედარებიდან იღებდა. მალე გამოჩნდა აბონენტი, რომელსაც ის ვერ ხედავდა: მისი ჩანაწერი წვდომის სერვერზე რამდენიმე წამს ცოცხლობდა, შედარება კი, რომელიც ორ წუთში ერთხელ ეშვება, მხოლოდ წუთზე ძველ ჩანაწერებს ითვალისწინებს. ადამიანი დღე-ღამეზე მეტხანს იყო წვდომის გარეშე. ასე გაჩნდა მეორე წყარო — ავტორიზაციის უარების ჟურნალი ბილინგში. თან ციკლმა დაიწყო გაშვება არა მხოლოდ ბილინგის სერვერის გადატვირთვის შემდეგ, არამედ მისი სერვისების გადატვირთვისასაც და მაშინაც, როცა შედარება რამდენჯერმე ზედიზედ ერთსა და იმავეს პოულობს.
ყოველ ორ წუთში ავტომატიკა სამი ადგილიდან აგროვებს მონაცემებს და წყვეტს, არის თუ არა სესია, რომლის უსაფრთხოდ დახურვაც შეიძლება.
1
ღია RADIUS-სესიები: ანგარიში, MAC, წვდომის სერვერი, ბოლო Accounting-Update-ის დრო. API-ით — ანგარიშის მდგომარეობა: ტარიფი და ბლოკირებები.
2
AlreadyConnected-ის უარები: როდის იყო ბოლო, რამდენი მცდელობა, რომელი MAC-იდან და რომელი წვდომის სერვერით. ექსპორტი წუთში ერთხელ, მხოლოდ წაკითხვა.
3
აქვს თუ არა ამ MAC-ს აქტიური სესია ახლავე. მდგომარეობის ასლი, რომელიც ხუთ წუთზე ძველი არ არის.
შემოწმება
თუ ერთი პირობაც არ სრულდება, სესიას არ ვეხებით და მიზეზს ვიწერთ
სესიის დასრულება LANBilling-ის API-ით
აღდგენის კონტროლი, 30 წუთამდე
ახალი სესია და აქაუნთინგი → შეტყობინება „აღდგენილია“
არ დადასტურდა → მხოლოდ დაკვირვება და შეტყობინება ინჟინერს
თუ ყველაფერი დაემთხვა, ავტომატიკა LANBilling-ის API-ში RADIUS-სესიის დასრულებას იძახებს ახლახან წაკითხული რეკვიზიტებით და სიას რამდენჯერმე ხელახლა კითხულობს: API ზოგჯერ წაშლილ სესიას კიდევ რამდენიმე წამს აჩვენებს. შემდეგ ნახევარ საათამდე ელოდება დადასტურებას: ახალი სესია იმავე MAC-ით, მასზე აქაუნთინგი, აბონენტი აქტიურია წვდომის სერვერზე, ტარიფი და ბლოკირებები უცვლელია. მანამდე შემთხვევა ღიად რჩება.
ყველა სესიის დახურვა, რომელზეც ახალი აქაუნთინგი არ არის, ყველაზე მარტივი და ყველაზე სახიფათო ვარიანტია: აქაუნთინგი ცოცხალ სესიაზეც შეიძლება დაგვიანდეს. როცა ფილტრს ცოცხალ მონაცემებზე ვამოწმებდი, AlreadyConnected-ის უარები იმ დღეს რამდენიმე ათეულ ანგარიშს ჰქონდა, თითქმის ყველას უვნებელი — მოწყობილობა წვდომას ხელახლა ითხოვდა, სანამ მისი სესია მუშაობდა. ნამდვილად გაჭედილი მხოლოდ ერთი სესია იყო. ამიტომ ახალი აქაუნთინგის მქონე სესია დაცულია, ხოლო თუ მონაცემები არ ჰყოფნის ან მოძველებულია, ავტომატიკა არაფერს ეხება და მიზეზს ჟურნალში წერს.
დრო დახურვის მომენტიდან ითვლება — კონტროლირებადი აღდგენის მიხედვით.
ავტომატური რეჟიმის ჩართვამდე ერთი კონტროლირებადი აღდგენა ჩავატარე — სწორედ იმ აბონენტზე, რომელსაც პირველი ვერსია ვერ ხედავდა. წინასწარმა გაშვებამ აჩვენა, რომ ყველა შემოწმება გავლილია, და დახურვა მხოლოდ მისთვის შესრულდა:
ამ გაშვებამ ბოლო შეცდომა დაიჭირა. წაშლიდან კიდევ ერთი წამის განმავლობაში API სესიას სიაში აჩვენებდა და ავტომატიკამ წარმატებული დახურვა წარუმატებლად ჩაწერა. შემოწმება რამდენიმე განმეორებით წაკითხვაზე გადავაკეთეთ.
ამის შემდეგ ავტომატური რეჟიმი მუდმივად ჩაირთო. პირველი პერიოდისთვის შეზღუდვები განზრახ მკაცრია: ციკლზე არაუმეტეს ერთი დახურვისა და ანგარიშზე არაუმეტეს ორი მცდელობისა. თუ დახურვის შემდეგ ძველი სესია დაბრუნდა, წაშლა არ დადასტურდა ან აბონენტს წვდომის პარამეტრები შეეცვალა, ავტომატიკა თავად გადადის დაკვირვების რეჟიმში: გაჭედილ სესიებს კვლავ პოულობს, მაგრამ აღარაფერს ხურავს. ამის შესახებ MAX-ში მაშინვე მოდის შეტყობინება. ავტომატური რეჟიმის ხელახლა ჩართვა მხოლოდ ხელით შეიძლება, მიზეზის გარკვევის შემდეგ.
ვერ დაგპირდებით, რომ ახლა ნებისმიერი აბონენტი ორ წუთში აღდგება. ორი წუთი შემოწმების პერიოდულობაა. სესია ჯერ 15 წუთი უნდა დადუმდეს, აბონენტმა რამდენჯერმე უნდა სცადოს დაკავშირება, ხოლო ციკლზე ერთი დახურვისას დიდი ავარია რიგ-რიგობით გაირჩევა. სამაგიეროდ გაჭედილი სესია აღარ ელოდება, სანამ აბონენტი მხარდაჭერას დაურეკავს და ინჟინერი ბილინგში ხელით ჩაიხედავს.
ყოველი დახურვისა და ყოველი წარუმატებლობის შესახებ ავტომატიკა ინჟინერს MAX-ში წერს. შეტყობინებებში არ არის MAC-მისამართები, სახელები და ხელშეკრულების ნომრები — მხოლოდ მთვლელები, რეჟიმი და მიზეზის კოდი. დეტალებს ინჟინერი პორტალში ნახულობს.
სადემონსტრაციო მაგალითი. დრო, მთვლელები და სტატუსები გამოგონილია; ფორმატი ნამდვილ შეტყობინებებს იმეორებს. ბოტი რუსულად წერს — ტექსტი ამ გვერდისთვის არის თარგმნილი.
დღეს
IPoE: გაჭედილი სესია ავტომატურად დაიხურა
კლიენტები წვდომის სერვერზე აქტიური სესიის გარეშე: 1
გაჭედილი სესიები ბილინგში: 1; აღდგენილია: 0; არ აღდგენილა: 0
ავტომატიკა: ავტომატური დახურვა ჩართულია
მიზეზი: none
IPoE: სესიების აღდგენა დასრულდა
კლიენტები წვდომის სერვერზე აქტიური სესიის გარეშე: 0
გაჭედილი სესიები ბილინგში: 1; აღდგენილია: 1; არ აღდგენილა: 0
ავტომატიკა: ავტომატური დახურვა ჩართულია
მიზეზი: none
ფონური ამოცანების გახსნადღეს
IPoE: გაჭედილი სესიის დახურვის მცდელობა ვერ შესრულდა
კლიენტები წვდომის სერვერზე აქტიური სესიის გარეშე: 1
გაჭედილი სესიები ბილინგში: 1; აღდგენილია: 0; არ აღდგენილა: 1
ავტომატიკა: ავტომატური დახურვა ჩართულია
მიზეზი: delete_without_effect
შეამოწმეთ ამოცანა „IPoE-ს აღდგენა ჩატვირთვის შემდეგ“. ნუ გადატვირთავთ ყველა კლიენტს.
IPoE: ავტომატური დახურვა შეჩერდა, ჩართულია მხოლოდ აღმოჩენა
კლიენტები წვდომის სერვერზე აქტიური სესიის გარეშე: 1
გაჭედილი სესიები ბილინგში: 1; აღდგენილია: 0; არ აღდგენილა: 1
ავტომატიკა: მხოლოდ აღმოჩენა
მიზეზი: delete_without_effect
ფონური ამოცანების გახსნაეს პირველი მასალაა სერიიდან იმის შესახებ, როგორ არის მოწყობილი პორტალი. შემდეგები ძირითადი ქეისის განყოფილებაში „საინჟინრო გადაწყვეტები“ გამოჩნდება.