ყველაფერი ძალიან ცუდია, ან ახალი ტიპის მოძრაობა

13 მარტს RIPE ძალადობის საწინააღმდეგო სამუშაო ჯგუფს შეთავაზება მიღებულია განიხილოს BGP-ის გატაცება (hjjack), როგორც RIPE პოლიტიკის დარღვევა. თუ წინადადება მიღებულ იქნა, ინტერნეტ პროვაიდერს, რომელსაც თავს დაესხნენ ტრაფიკის ჩარევა, ექნება შესაძლებლობა გამოაგზავნოს სპეციალური მოთხოვნა თავდამსხმელის გამოსავლენად. თუ მიმომხილველი ჯგუფი შეაგროვებდა საკმარის დამადასტურებელ მტკიცებულებებს, LIR, რომელიც იყო BGP-ის დაჭერის წყარო, ჩაითვლებოდა თავდამსხმელად და შეიძლება ჩამოერთვათ მისი LIR სტატუსი. იყო გარკვეული არგუმენტებიც ამის წინააღმდეგ ცვლილებები.

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

ბოლო რამდენიმე წლის განმავლობაში, მხოლოდ ისეთი კონფლიქტები, როგორიცაა MOAS (მრავალჯერადი წარმოშობის ავტონომიური სისტემა) იყო გაშუქებული პრესაში, როგორც BGP ჩარევა. MOAS არის განსაკუთრებული შემთხვევა, როდესაც ორი განსხვავებული ავტონომიური სისტემა აქვეყნებს ურთიერთსაწინააღმდეგო პრეფიქსებს შესაბამის ASN-ებთან AS_PATH-ში (პირველი ASN AS_PATH-ში, შემდგომში მოხსენიებული, როგორც საწყისი ASN). თუმცა, მაინც შეგვიძლია დავასახელოთ 3 დამატებითი ტიპი ტრაფიკის ჩარევა, რაც თავდამსხმელს საშუალებას აძლევს მანიპულირება მოახდინოს AS_PATH ატრიბუტით სხვადასხვა მიზნებისთვის, მათ შორის ფილტრაციისა და მონიტორინგის თანამედროვე მიდგომების გვერდის ავლით. ცნობილი შეტევის ტიპი პილოსოვა-კაპელი - ასეთი ჩარევის ბოლო ტიპი, მაგრამ არა მნიშვნელოვნებით. სავსებით შესაძლებელია, რომ სწორედ ასეთი თავდასხმა ვნახეთ ბოლო კვირების განმავლობაში. ასეთ მოვლენას აქვს გასაგები ხასიათი და საკმაოდ სერიოზული შედეგები.

მათ, ვინც ეძებს TL;DR ვერსიას, შეუძლიათ გადახვიდეთ "Perfect Attack" სუბტიტრზე.

ქსელის ფონი

(იმისთვის, რომ უკეთ გაიგოთ ამ ინციდენტთან დაკავშირებული პროცესები)

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

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

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

ინციდენტი

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

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
განცხადებების მაგალითები 2019 წლის აპრილის დასაწყისისთვის

NTT /25 პრეფიქსის გზაზე მას განსაკუთრებით საეჭვოდ ხდის. LG NTT არ იცოდა ამ მარშრუტის შესახებ ინციდენტის დროს. დიახ, ზოგიერთი ოპერატორი ქმნის მთელ AS_PATH-ს ამ პრეფიქსებისთვის! სხვა მარშრუტიზატორებზე შემოწმება ავლენს ერთ კონკრეტულ ASN-ს: AS263444. ამ ავტონომიური სისტემით სხვა მარშრუტების დათვალიერების შემდეგ, ჩვენ შევხვდით შემდეგ სიტუაციას:

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
შეეცადეთ გამოიცნოთ რა არის აქ არასწორი

როგორც ჩანს, ვიღაცამ აიღო პრეფიქსი მარშრუტიდან, გაყო იგი ორ ნაწილად და გამოაქვეყნა მარშრუტი იმავე AS_PATH-ით ამ ორი პრეფიქსისთვის.

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
მარშრუტების მაგალითი გაყოფილი პრეფიქსის წყვილისთვის

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

სწორედ აქ იწყება ჩვენი წარუმატებლობის სერია და კიდევ ერთი იმედგაცრუების რაუნდი ინტერნეტის ჯანმრთელობის ამჟამინდელი მდგომარეობით.

წარუმატებლობის გზა

პირველ რიგში. როგორ შეგვიძლია განვსაზღვროთ რომელმა მარშრუტიზატორებმა მიიღეს ასეთი ჩაკეტილი მარშრუტები და ვისი ტრაფიკის გადამისამართება შეიძლება დღეს? ჩვენ ვიფიქრეთ, რომ დავიწყებდით /25 პრეფიქსებით, რადგან მათ „უბრალოდ არ შეუძლიათ გლობალური განაწილება“. როგორც მიხვდით, ძალიან ვცდებოდით. ეს მეტრიკა ძალიან ხმაურიანი აღმოჩნდა და მარშრუტები ასეთი პრეფიქსებით შეიძლება გამოჩნდეს Tier-1 ოპერატორებისგანაც კი. მაგალითად, NTT-ს აქვს დაახლოებით 50 ასეთი პრეფიქსი, რომლებსაც ის საკუთარ კლიენტებს ანაწილებს. მეორეს მხრივ, ეს მეტრიკა ცუდია, რადგან ასეთი პრეფიქსები შეიძლება გაფილტრული იყოს, თუ ოპერატორი იყენებს მცირე პრეფიქსების გაფილტვრა, ყველა მიმართულებით. ამიტომ, ეს მეთოდი არ არის შესაფერისი ყველა ოპერატორის მოსაძებნად, რომელთა ტრაფიკი გადამისამართდა ასეთი ინციდენტის შედეგად.

კიდევ ერთი კარგი იდეა, რომელიც ჩვენ გვეგონა, იყო ნახვა POV. განსაკუთრებით მარშრუტებისთვის, რომლებიც არღვევენ შესაბამისი ROA-ის maxLength წესს. ამ გზით ჩვენ ვიპოვით სხვადასხვა წარმოშობის ASN-ების რაოდენობას სტატუსით არასწორი, რომლებიც ხილული იყო მოცემული AS-ისთვის. თუმცა არის "პატარა" პრობლემა. ამ რიცხვის საშუალო (მედიანა და რეჟიმი) (სხვადასხვა წარმოშობის ASN-ების რაოდენობა) არის დაახლოებით 150 და, თუნდაც მცირე პრეფიქსებს გავფილტროთ, ის რჩება 70-ზე ზემოთ. ამ მდგომარეობას აქვს ძალიან მარტივი ახსნა: არსებობს მხოლოდ რამდენიმე ოპერატორი, რომელიც უკვე იყენებს ROA- ფილტრებს „გადატვირთვის არასწორი მარშრუტების“ პოლიტიკით შესვლის წერტილებში, ასე რომ, სადაც კი მარშრუტი ROA დარღვევით გამოჩნდება რეალურ სამყაროში, მას შეუძლია გავრცელდეს ყველა მიმართულებით.

ბოლო ორი მიდგომა საშუალებას გვაძლევს ვიპოვოთ ოპერატორები, რომლებმაც დაინახეს ჩვენი ინციდენტი (რადგან ის საკმაოდ დიდი იყო), მაგრამ ზოგადად ისინი არ გამოიყენება. კარგი, მაგრამ შეგვიძლია ვიპოვოთ შემოჭრილი? რა არის ამ AS_PATH მანიპულაციის ზოგადი მახასიათებლები? არსებობს რამდენიმე ძირითადი ვარაუდი:

• პრეფიქსი აქამდე არსად იყო ნანახი;
• წარმოშობის ASN (შეხსენება: პირველი ASN AS_PATH-ში) მოქმედებს;
• ბოლო ASN AS_PATH-ში არის თავდამსხმელის ASN (იმ შემთხვევაში, თუ მისი მეზობელი ამოწმებს მეზობლის ASN-ს ყველა შემომავალ მარშრუტზე);
• თავდასხმა წარმოიქმნება ერთი პროვაიდერისგან.

თუ ყველა ვარაუდი სწორია, მაშინ ყველა არასწორი მარშრუტი წარმოაჩენს თავდამსხმელის ASN-ს (გარდა წარმოშობის ASN-ისა) და, ამრიგად, ეს არის "კრიტიკული" წერტილი. ნამდვილ გამტაცებლებს შორის იყო AS263444, თუმცა იყვნენ სხვებიც. მაშინაც კი, როდესაც ჩვენ განვიხილეთ ინციდენტის მარშრუტები. რატომ? კრიტიკული წერტილი შეიძლება დარჩეს კრიტიკული სწორი მარშრუტებისთვისაც კი. ეს შეიძლება იყოს რეგიონში ცუდი კავშირის ან ჩვენი ხილვადობის შეზღუდვის შედეგი.

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

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

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

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
ჩვენი მისამართის სივრცის დაჭერის მცდელობის ბოლო მაგალითი

როდესაც უფრო სპეციფიკური შეიქმნა ჩვენი პრეფიქსებისთვის, გამოიყენებოდა სპეციალურად შექმნილი AS_PATH. თუმცა, ეს AS_PATH ვერ იქნა აღებული ჩვენი წინა მარშრუტიდან. AS6762-თან კომუნიკაციაც კი არ გვაქვს. ინციდენტის სხვა მარშრუტების დათვალიერებისას, ზოგიერთ მათგანს ჰქონდა რეალური AS_PATH, რომელიც ადრე გამოიყენებოდა, ზოგი კი არა, თუნდაც ის რეალურს ჰგავს. AS_PATH დამატებით შეცვლას არავითარი პრაქტიკული აზრი არ აქვს, რადგან ტრაფიკი მაინც გადამისამართდება თავდამსხმელზე, მაგრამ მარშრუტები „ცუდი“ AS_PATH შეიძლება გაფილტრული იყოს ASPA ან სხვა შემოწმების მექანიზმით. აქ ჩვენ ვფიქრობთ გამტაცებლის მოტივაციაზე. ამჟამად არ გვაქვს საკმარისი ინფორმაცია იმის დასადასტურებლად, რომ ეს ინციდენტი იყო დაგეგმილი თავდასხმა. მიუხედავად ამისა, შესაძლებელია. შევეცადოთ წარმოვიდგინოთ, თუმცა ჯერ კიდევ ჰიპოთეტური, მაგრამ პოტენციურად საკმაოდ რეალური სიტუაცია.

სრულყოფილი თავდასხმა

რა გვაქვს? ვთქვათ, თქვენ ხართ ტრანზიტის პროვაიდერი თქვენი კლიენტებისთვის მაუწყებლობის მარშრუტებზე. თუ თქვენს კლიენტებს აქვთ მრავალჯერადი ყოფნა (multihome), მაშინ თქვენ მიიღებთ მათი ტრაფიკის მხოლოდ ნაწილს. მაგრამ რაც მეტი ტრეფიკია, მით მეტია თქვენი შემოსავალი. ასე რომ, თუ დაიწყებთ იმავე მარშრუტების ქვექსელის პრეფიქსების რეკლამირებას იმავე AS_PATH-ით, თქვენ მიიღებთ მათ დარჩენილ ტრაფიკს. შედეგად, დანარჩენი ფული.

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

სხვა მარშრუტიზაციის უსაფრთხოების მექანიზმების გათვალისწინებით, ASPA არც ამ შემთხვევაში დაეხმარება (რადგან ის იყენებს AS_PATH-ს მოქმედი მარშრუტიდან). BGPSec ჯერ კიდევ არ არის ოპტიმალური ვარიანტი დაბალი მიღების მაჩვენებლებისა და შეტევების შემცირების შესაძლებლობის გამო.

ასე რომ, ჩვენ გვაქვს აშკარა მოგება თავდამსხმელისთვის და უსაფრთხოების ნაკლებობა. შესანიშნავი ნაზავი!

რა უნდა გავაკეთო?

აშკარა და ყველაზე მკვეთრი ნაბიჯი არის თქვენი მიმდინარე მარშრუტიზაციის პოლიტიკის გადახედვა. დაყავით თქვენი მისამართის სივრცე ყველაზე პატარა ნაწილებად (გადახურვის გარეშე), რომლის რეკლამირებაც გსურთ. მოაწერეთ ROA მხოლოდ მათთვის, maxLength პარამეტრის გამოყენების გარეშე. ამ შემთხვევაში, თქვენს ამჟამინდელ POV-ს შეუძლია გიხსნათ ასეთი შეტევისგან. თუმცა, კიდევ ერთხელ, ზოგიერთი ოპერატორისთვის ეს მიდგომა არ არის გონივრული უფრო კონკრეტული მარშრუტების ექსკლუზიური გამოყენების გამო. ROA-ს და მარშრუტის ობიექტების ამჟამინდელ მდგომარეობასთან დაკავშირებული ყველა პრობლემა აღწერილი იქნება ჩვენს მომავალ მასალაში.

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

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

მეორე მიდგომა არის თავდამსხმელის და მათთვის, ვისთვისაც ის არის კრიტიკული წერტილის დასჯა (კარგი მარშრუტებისთვის) თქვენი მარშრუტების წვდომის შეწყვეტით თავდამსხმელთან. ეს შეიძლება გაკეთდეს თავდამსხმელის ASN-ის დამატებით თქვენი ძველი მარშრუტების AS_PATH-ზე და ამით აიძულოთ ისინი თავიდან აიცილონ ეს AS BGP-ში ჩაშენებული მარყუჟის გამოვლენის მექანიზმის გამოყენებით. საკუთარი სიკეთისთვის.

წყარო: www.habr.com