როგორ განვასხვავოთ მარშრუტიზაციის ციკლი მარშრუტის ფლაპინგისგან VPN საიტებზე
მარშრუტიზაციის ციკლი და ფლაპავი მარშრუტი ერთსა და იმავე შეწყვეტილ დანაკარგს იწვევს. გეითვეებზე სამი შემოწმება გამოყოფს მათ, სანამ რამეს შეცვლით.
ორი საიტი, ერთი გვირაბი და ერთი შორეული პრეფიქსი, რომელიც გარკვეული დროის განმავლობაში პასუხობს და შემდეგ დუმს. რეფლექსია მას მარშრუტიზაციის ციკლი ვუწოდოთ, და ზოგჯერ ზუსტად ასეც არის. მაგრამ ციკლი და ფლაპავი მარშრუტი ერთსა და იმავე ჩივილს იწვევს და საპირისპირო შეკეთებას მოითხოვს: ერთი გადაცემის გადაწყვეტილებაა, რომელიც არასოდეს სრულდება, მეორე კი პრეფიქსია, რომელიც გამუდმებით ტოვებს ცხრილს. სამი დაკვირვება ყოფს მათ, და სამივე შეგიძლიათ შეაგროვოთ გეითვეის ბრძანების სტრიქონიდან, სანამ ფილტრს შეეხებით ან გვირაბს გადატვირთავთ.
ციკლი ნაბიჯ-ნაბიჯ წყდება. საიტი A დანიშნულებისთვის B-ს ირჩევს შემდეგ ნაბიჯად, B იმავე დანიშნულებისთვის A-ს ირჩევს, და პაკეტი ორი ორმხრივი მგზავრობის შემდეგ TTL-ზე იწურება. ფლაპინგს კი მარშრუტიზაციის პროტოკოლი წყვეტს: პრეფიქსი უკან იხევა, ხელახლა დგინდება ან ალტერნატიული შემდეგი ნაბიჯით იცვლება, ამიტომ ზოგი პაკეტი საერთოდ არანაირ მარშრუტს არ ფლობს, ზოგი კი სრულიად კარგს მიჰყვება.
სამი შემოწმება, რომელიც კითხვას წყვეტს
პირველი გადაწყვეტილებისთვის პაკეტების ჩაჭერა არ გჭირდებათ. გჭირდებათ პრეფიქსის მდგომარეობა ორივე ბოლოში, თითოეული მხარის მიერ არჩეული შემდეგი ნაბიჯი და ნაბიჯების რაოდენობა, რომელიც ან მეორდება, ან არა. თუ პრეფიქსი იმავე შემდეგი ნაბიჯით დაყენებული რჩება მაშინ, როცა ტრაფიკი ვერ გადის, ციკლი გადაცემის გზაში ცხოვრობს. თუ პრეფიქსი ქრება და ბრუნდება, ხარვეზი გადაცემის ზემოთაა და შეკეთება მარშრუტიზაციის პროტოკოლს ეკუთვნის, არა სტატიკურ მარშრუტს.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
ერთი გაფრთხილება დაწყებამდე. თუ ამას კითხულობთ იმ გვირაბიდან, რომელიც ციკლავს, თქვენი სესია იმ წამსვე კვდება, როცა მარშრუტს შეცვლით. გახსენით კონსოლი ან მართვის გზა, რომელიც არ არის დამოკიდებული იმ პრეფიქსზე, რომლის შეკეთებასაც აპირებთ.
შემოწმება პირველი: პრეფიქსი სტაბილურია თუ ღელავს
ჰკითხეთ ბირთვს, რა დააყენა, და არა რას გვპირდება კონფიგურაციის ფაილი. Linux გეითვეიზე ip route get 10.20.30.40 ასრულებს იმავე ძიებას, რასაც გადაცემის გზა, პოლიტიკის ცხრილების ჩათვლით, ხოლო ip route show 10.20.30.0/24 თავად ჩანაწერს აჩვენებს. ip monitor route ყოველ ცვლილებას დადგომის მომენტში გადასცემს, რაც პრეფიქსის მოსვლისა და წასვლის დაკვირვების უსწრაფესი გზაა.
FRR-ის ან BIRD-ის მქონე მარშრუტიზატორზე საინტერესო გადაცემის ცხრილი არ არის. show ip bgp 10.20.30.0/24 აბრუნებს არჩეულ გზას და მის მუშაობის დროს; მუშაობის დრო, რომელიც ყოველ რამდენიმე წუთში ახლდება, ის ფლაპინგია, რომელსაც შეგიძლიათ დაარქვათ, და არა ციკლი. show ip bgp summary მეზობლის მდგომარეობასა და პრეფიქსების რაოდენობას აჩვენებს, ამიტომ გამუდმებით ვარდნილი პარტნიორი ბრალს გადაცემის გზას ახსნის.
ჩაწერეთ პასუხი, სანამ რამეს შეცვლით. ათი წუთი სტაბილური, სანამ პინგები ვერ გადიოდა, და ათ წუთში ოთხჯერ გაქრობა სხვადასხვა შემდეგ ნაბიჯებამდე მიგვიყვანს. მეორე შემთხვევა სტატიკური მარშრუტის ყველა თეორიას უაზროს ხდის.
შემოწმება მეორე: უბრუნდება თუ არა შემდეგი ნაბიჯი შემოსვლის გვირაბს
ციკლს ორი გეითვეის შეთანხმება სჭირდება. პაკეტის მიმღებ საიტზე ნახეთ გზა, რომელსაც პაკეტი გასასვლელად გამოიყენებს: ip route get 10.20.30.40 from 10.10.5.20 რეალური წყაროს მისამართით, რადგან პოლიტიკის წესმა შეიძლება სხვაგვარად უპასუხოს, ვიდრე მთავარი ცხრილი. შემდეგ გაიმეორეთ ძიება იმ საიტზე, რომელმაც გამოგზავნა. თუ თითოეული მხარე მეორეს ირჩევს იმავე პრეფიქსის შემდეგ ნაბიჯად, ციკლი დამტკიცებულია და არც ერთი ჩაჭერა ვერაფერს დაუმატებს.
მიზეზი თითქმის ყოველთვის განცხადებაა, რომელსაც გვირაბის გადაკვეთა არ უნდა მოეხდინა. გვირაბში გადანაწილებული ნაგულისხმევი მარშრუტი, შორეული საიტის საკუთარ ქვექსელს დამფარავი აგრეგატი, ან სიფრთხილისთვის პარტნიორზე მიმართული სტატიკური მარშრუტი — ყველა ერთსა და იმავე ურთიერთ შემდეგ ნაბიჯს ქმნის. გვირაბი შეიძლება სრულად იყოს დამყარებული და მაინც ტრაფიკი წრეში ატაროს; strongSwan-ის გადაცემის შენიშვნები ამ მოთხოვნის მარშრუტიზაციის მხარეს აღწერს.
WireGuard საკუთარ შენიშვნას იმსახურებს, რადგან დასაბრალებელი განცხადება არ არსებობს. wg show ყოველი პარტნიორის AllowedIPs-ს ჩამოთვლის, და ბირთვი პარტნიორისთვის დანიშნულებას მხოლოდ მაშინ იღებს, როცა ის ამ დიაპაზონში ხვდება. ციკლი იქ გადამთხვევადი AllowedIPs დიაპაზონია ან ინტერფეისის გავლით უკან მიმართული სტატიკური მარშრუტი, ამიტომ შეკეთება მხოლოდ ამ ორ ადგილას ცხოვრობს.
შემოწმება მესამე: წაიკითხეთ ნაბიჯების რაოდენობა და არა ვარსკვლავები
traceroute -n -I 10.20.30.40 და mtr -n -r -c 20 10.20.30.40 ორივე გზას აჩვენებს, და ICMP რეჟიმი ხშირად გადაურჩება იმ ფილტრაციას, რომელიც UDP ზონდებს ჭამს. ციკლი იმავე ორი გეითვეის მისამართის მოკლე განმეორებით მიმდევრობას ჰგავს, TTL კი ყოველ ჯერზე იზრდება. ვარდნა ბოლო პასუხისმგებელი გეითვეის შემდეგ ვარსკვლავებს ჰგავს, და ერთი ჩუმი ნაბიჯი არაფრის მტკიცებულება არ არის.
როცა გზა გაურკვეველია, წაიკითხეთ TTL მავთულზე. tcpdump -ni any -vv icmp ორივე გეითვეიზე ყოველი პაკეტის TTL-ს და დროის გადაჭარბების ყოველი პასუხის წყაროს მისამართს აჩვენებს. თუ პაკეტი შორეულ საიტს აღწევს უფრო დაბალი TTL-ით, ვიდრე გზაში შესაძლო ნაბიჯების რაოდენობაა, რაღაც ნაბიჯებს ამატებს, რომლებსაც traceroute თქვენ არ გაჩვენებთ, და ეს მაშინ ხდება, როცა ერთი საიტის ფაირვოლი მეორის სახელით პასუხობს ზონდებს.
შეაკეთეთ პრეფიქსის მფლობელი, შემდეგ შეამოწმეთ ორივე მიმართულება
გადაწყვიტეთ, რომელი საიტი ქმნის დანიშნულებას და რომელი ტრანზიტული გზებია ნებადართული, შემდეგ შეცვალეთ განცხადება ან სტატიკური მარშრუტი იმ მფლობელთან. მიმღები საიტის გასწორება მაცდური და ჩვეულებრივ არასწორია: ის ციკლს ერთი პრეფიქსისთვის მალავს და ცუდ განცხადებას შემდეგისთვის ადგილზე ტოვებს. მარშრუტის ტეგები, განაწილების სიები და split-horizon წესები არსებობს ამის წყაროში შესაჩერებლად, და ისინი იაფია ერთ პრეფიქსზე მორგებულ ფილტრზე.
ცვლილების შემდეგ ცალკე შეამოწმეთ წინა და უკანა მიმართულება, რადგან ციკლი შეიძლება შავი ხვრელით შეიცვალოს სიმპტომის ხილული გაუმჯობესების გარეშე. გაუშვით ip route get ორივე ბოლოდან, ტრაფიკი გაგზავნეთ ჰოსტიდან, რომელიც გეითვეი არ არის, და ip monitor route მინიმუმ ერთი შეკავების ტაიმერის განმავლობაში მუშაობის საშუალება მისცით, რომ ფლაპინგი შეკეთებად არ ჩაითვალოს.
სანამ რამეს შეცვლით, დაადასტურეთ ეს ხუთი პუნქტი: პრეფიქსი სტაბილურია თუ ღელავს, ორივე ბოლოში შემდეგი ნაბიჯი გვირაბისკენ მიუთითებს, ნაბიჯების რაოდენობა მეორდება თუ არა, ერთი საიტი ფლობს პრეფიქსს, და გაქვთ მართვის გზა, რომელიც ცვლილებას გაუძლებს. თუ ხუთიდან რომელიმე უცნობია, დანარჩენი ოთხი ვარაუდია.