BGP marsruudi leke põhjustab Internetis massilise ühenduse katkemise

Cloudflare'i ettevõte опубликовала aruanne eilse juhtumi kohta, mille tulemusena kolm tundi Kell 13:34 kuni 16:26 (MSK) oli probleeme juurdepääsuga paljudele ülemaailmse võrgu ressurssidele, sealhulgas Cloudflare'i, Facebooki, Akamai, Apple'i, Linode'i ja Amazon AWS-i infrastruktuurile. Probleemid Cloudflare'i infrastruktuuris, mis pakub CDN-i 16 miljonile saidile, täheldatud kell 14:02-16:02 (MSK). Cloudflare'i hinnangul läks katkestuse ajal kaduma ligikaudu 15% ülemaailmsest liiklusest.

Probleem oli selles põhjustanud marsruudi leke läbi BGP, mille käigus suunati valesti ümber umbes 20 tuhat eesliidet 2400 võrgu jaoks. Lekke allikaks oli teenusepakkuja DQE Communications, kes kasutas tarkvara BGP optimeerija marsruutimise optimeerimiseks. BGP Optimizer jagab IP-eesliited väiksemateks, näiteks jagab 104.20.0.0/20 104.20.0.0/21 ja 104.20.8.0/21 ning selle tulemusena hoidis DQE Communications enda poolel palju konkreetseid marsruute, mis tühistavad. levinumad marsruudid (st Cloudflare'i üldiste marsruutide asemel kasutati üksikasjalikumaid marsruute konkreetsete Cloudflare'i alamvõrkudesse).

Neid punktimarsruute reklaamiti ühele klientidest (Allegheny Technologies, AS396531), kellel oli samuti ühendus teise pakkuja kaudu. Allegheny Technologies edastas saadud marsruudid teisele transiiditeenuse pakkujale (Verizon, AS701). BGP teadete nõuetekohase filtreerimise puudumise ja eesliidete arvu piirangu tõttu valis Verizon selle teadaande ja edastas saadud 20 tuhat prefiksit ülejäänud Internetti. Ebaõigeid eesliiteid peeti nende detailsuse tõttu kõrgema prioriteediks, kuna konkreetsel marsruudil on suurem prioriteet kui üldisel.

Selle tulemusel hakati paljude suurte võrkude liiklust suunama Verizoni kaudu väikesele teenusepakkujale DQE Communications, kes ei saanud hakkama üleujutatud liiklusega, mis viis kokkuvarisemiseni (mõju on võrreldav osa tiheda liiklusega kiirtee asendamisega maateega ).

Et vältida sarnaste juhtumite esinemist tulevikus
soovitatav:

• Kasutage kontrollimine RPKI-l põhinevad teadaanded (BGP Origin Validation, võimaldab saada teateid ainult võrguomanikelt);
• Piirata kõigi EBGP seansside lubatud eesliidete arvu (maksimaalse prefiksi määramine aitaks koheselt loobuda 20 tuhande prefiksi edastamisest ühe seansi jooksul);
• Rakendada IRR-registril põhinevat filtreerimist (Internet Routing Registry, määrab AS-i, mille kaudu antud eesliidete marsruutimine on lubatud);
• Kasutage ruuterite RFC 8212-s soovitatud keelamise vaikeseadeid ('vaikekeeld');
• Lõpetage BGP optimeerijate hoolimatu kasutamine.

Allikas: opennet.ru