Začal jako projekt studentů Matfyzu. Český BIRD dnes pomáhá řídit provoz na největších internetových uzlech

Internet drží pohromadě i díky místům, kde se propojují sítě poskytovatelů připojení, cloudů nebo videoslužeb. S předáváním informací o tom, kudy jsou jednotlivé sítě dostupné, jim ve Frankfurtu, Londýně i Amsterdamu pomáhá český BIRD. Začal jako studentský projekt, po první verzi z roku 2000 léta spíš dřímal a soustavný vývoj obnovil až CZ.NIC. Ve své úloze uspěl tak výrazně, že největší uzly nakonec začaly platit vývoj konkurenčního softwaru, aby nebyly závislé jen na něm.
Nálepky:
V příručce pro připojení k route serverům frankfurtského DE-CIX stojí mezi technickými pokyny nenápadná věta: službu obsluhuje software BIRD. Za tou větou se skrývá český projekt, který pomáhá sítím domluvit se, kudy si mají posílat data.
Internet totiž propojuje samostatně spravované sítě. Jedna patří poskytovateli domácího připojení, jiná provozovateli cloudu nebo videoslužby. V internetovém propojovacím uzlu, označovaném zkratkou IXP, mohou tyto sítě propojit své routery přes společnou infrastrukturu a vyměňovat si provoz přímo. Zjednodušeně si lze představit velký síťový přepínač, switch, do kterého se připojí všichni účastníci. U velkých uzlů tuto práci obstarává celá soustava propojených přepínačů.

Samotné propojení ale nestačí. Router poskytovatele potřebuje vědět, přes kterého souseda jsou dostupné adresy serverů s videem. Výměnu takových informací může zprostředkovat route server: od jednotlivých sítí přijímá oznámení o dostupných cestách a předává je ostatním. Když se pak divákovi začne přehrávat video, jeho data tečou mezi routery přes přepínače uzlu. Route server se tohoto přenosu neúčastní. Právě v předávání a třídění informací o cestách se BIRD prosadil.
Vedle DE-CIX běží i na jednom z route serverů hlavní londýnské sítě LINX. Web projektu BIRD mezi uživateli uvádí také amsterdamský AMS-IX, Fastly, Akamai a Twitch.
V hlavičce souboru README jsou dodnes uvedeni původní autoři i pozdější správce projektu. Copyright všech tří původních autorů začíná rokem 1998, u Pavla Machka končí rokem 2000, u Ondřeje Filipa a Martina Mareše rokem 2008 a od roku 2009 pokračuje CZ.NIC. Projekt vznikl na Matematicko-fyzikální fakultě Univerzity Karlovy pod vedením Libora Forsta. Mezi tou seminárkou a frankfurtskou příručkou leží léta nárazového vývoje, jeden pražský uzel ochotný ho nasadit a jazyk pro filtrování cest, který se nakonec ukázal jako jedna z jeho největších předností.
Seminárka, která na pár let usnula
Z té trojice se Pavel Machek v linuxovém jádře léta staral o podporu hibernace, při níž se obsah paměti uloží na disk, aby mohl počítač po opětovném zapnutí navázat na předchozí práci. Martin Mareš je autorem pciutils, takže jeho kód spouští každý, kdo na Linuxu zadá lspci. Ondřej Filip později zamířil do CZ.NIC, správce české národní domény, kde je výkonným ředitelem od konce roku 2004. Jméno projektu je mimochodem rekurzivní zkratka: BIRD Internet Routing Daemon.
BIRD měl být směrovací démon, program běžící na pozadí, který si s dalšími routery vyměňuje informace o dostupných sítích a podle pravidel vybírá vhodné cesty. Obsluha route serveru je jednou z úloh, které takový program může plnit. Autoři původně mířili šířeji: chtěli otevřenou alternativu k tehdejší Zebře, z níž později vznikla Quagga, a k nesvobodnému GateD.
Už v cílech projektu z roku 1999 stálo, že program má být rychlý, přenositelný a modulární a zvládat IPv4 i IPv6 z jednoho zdrojového kódu. Autoři chtěli také flexibilní jazyk pro filtrování cest a snadnou konfiguraci. Změněná pravidla měl BIRD umět načíst za běhu, bez zbytečného přerušení provozu. Právě tyto vlastnosti se později hodily na route serverech.
První verze vyšla v pátek 9. června 2000 pod licencí GPL. Pak ho potkal osud mnoha školních projektů. Autoři se po obhajobě rozprchli a BIRD se dál vyvíjel jen nárazově, když se nahromadily požadavky uživatelů, kteří si ho díky otevřené licenci našli. Menší probuzení přišla v letech 2003 a 2006, mimo jiné v souvislosti s CESNETem. Soustavný vývoj obnovil až CZ.NIC na přelomu let 2008 a 2009, kdy Filip BIRD doporučil jako jeden z prvních projektů nově vznikajících Laboratoří CZ.NIC. Peníze na něj šly z přebytku příjmů z registrací domén .cz.
Projekt si vzal na starost Ondřej Zajíček, autor současných implementací směrovacích protokolů BGP a OSPF, který dodnes spravuje řadu BIRD 2. Od roku 2015 v týmu pracuje Maria Matějka, autorka dnešního filtrovacího jádra, vedoucí týmu a správkyně BIRD 3. Kromě CZ.NIC dnes vývoj platí také zákazníci komerční podpory.
CZ.NIC měl blízko k pražskému uzlu NIX.CZ, v jehož představenstvu Filip seděl. Právě tam BIRD dostal úlohu, na kterou se nakonec hodil ze všeho nejlíp.
Route server: předává cesty, uživatelská data tečou jinudy
Přímá výměna provozu mezi sítěmi se nazývá peering. Účastníkům uzlu umožňuje předávat si data bez toho, aby je mezi nimi přepravovala další síť v rámci placeného tranzitu. Každý z nich ale potřebuje oznámit ostatním, které cíle jsou přes něj dostupné, a dozvědět se totéž od sousedů. K tomu slouží BGP, protokol pro výměnu směrovacích informací mezi sítěmi.
Routery si přes BGP neposílají seznam každého připojeného počítače. Oznamují celé bloky IP adres, kterým se říká prefixy. Oznámení v principu říká: adresy z tohoto bloku jsou dostupné touto cestou. K prefixu se připojují atributy, které cestu blíž popisují a pomáhají routeru rozhodnout, jestli ji přijme a použije.
V těchto oznámeních vystupují sítě jako autonomní systémy, zkráceně AS. Autonomní systém je síť nebo skupina sítí se společnou správou a směrovací politikou; navenek ji identifikuje přidělené číslo ASN. Atribut AS_PATH zaznamenává čísla autonomních systémů, přes které se informace o cestě šířila. Atribut NEXT_HOP zase určuje adresu routeru, kterému se mají předat pakety mířící k danému prefixu.
Aby si dva routery tyto informace mohly předávat, navážou spojení přes TCP, takzvanou relaci BGP. Ta zůstává otevřená a routery si přes ni oznamují i změny. Pokud se mají všichni účastníci uzlu propojit tímto způsobem se všemi, počet relací roste kvadraticky. Na modelovém uzlu se třemi sty sítěmi a jedním routerem za každou by pro jednu rodinu IP adres bylo potřeba 44 850 relací. Každý nováček by navíc musel domluvit a nastavit peering s ostatními zvlášť.
Route server tuhle spleť nahradí hvězdou. Router každého účastníka naváže relaci k němu a jeho prostřednictvím získá povolené cesty od ostatních připojených sítí. Kvůli redundanci se obvykle připojí ke dvěma route serverům; například DE-CIX navíc používá samostatné relace pro IPv4 a IPv6. Správce tak místo stovek sousedů nastavuje jen několik spojení.
Pro samotná data se tím trasa přes uzel nemění. Když router sítě A posílá data síti B, jdou přes přepínače uzlu přímo do routeru B. Route server pouze zprostředkoval informaci, že tudy cesta vede. Proto do AS_PATH nepřidává vlastní číslo autonomního systému a NEXT_HOP nechává ukazovat na původní router.
Většinu práce route serveru tak tvoří správa směrovacích záznamů, vyhodnocování pravidel a obsluha spojení BGP. Nepotřebuje specializovaný hardware na rychlé předávání uživatelských paketů, stačí server s Linuxem nebo BSD. U dnešních největších nasazení ovšem směrovací data a jejich zpracování vyžadují pořádnou paměť: projekt uvádí i provoz s více než terabajtem RAM.
Prosté „vezmi všechno a rozešli to všem“ by ale nefungovalo. Každá síť má vlastní pravidla, s kým chce provoz vyměňovat. Route serveru je může sdělit pomocí BGP communities, číselných štítků připojených k oznámené cestě. Jeden štítek například říká, aby cestu neposílal konkrétnímu účastníkovi, jiný ji dovolí poslat jen vybraným sítím.
V pravidlech NIX.CZ z roku 2014 například značka 0:47200 znamenala cestu neposílat nikomu. Doplněním značky 47200:<AS příjemce> ji síť mohla zpřístupnit vybranému účastníkovi. Číslo 47200 patří autonomnímu systému route serveru NIX.CZ. Kombinací značek tak šlo určit, kdo cestu dostane.
Route server navíc musí kontrolovat, co od účastníků přijímá. Chybné oznámení jedné sítě by jinak mohl rozeslat mnoha ostatním. DE-CIX například odmítá soukromé adresní rozsahy nebo příliš malé bloky adres a ověřuje, jestli oznámení odpovídá směrovacím registrům IRR a záznamům RPKI. V IRR provozovatelé zveřejňují informace o svých sítích a směrovací politice. RPKI umožňuje pomocí kryptograficky podepsaných záznamů ověřit, který autonomní systém smí daný prefix původně oznámit. Konfigurace filtrů se u DE-CIX aktualizuje každých šest hodin, na dvojici route serverů s dvouhodinovým odstupem. Případná chyba v nové konfiguraci tak zasáhne nejdřív jen jeden z nich.
Při výběru cest může nastat problém označovaný jako path hiding. Route server zná několik cest ke stejnému prefixu, ale pro klienta obvykle vybírá jednu nejlepší. Síť, která ji oznámila, ovšem může zakázat její předání tomuto klientovi. Pokud server další možnosti nezkusí, klient nedostane žádnou cestu, přestože by mohl použít druhou nejlepší od jiné sítě. BIRD od verze 1.3.8 z roku 2012 umí v takovém případě hledat mezi dalšími kandidáty. Takto ho používá i DE-CIX.
Politika zapsaná jako program
Route server tato pravidla vyhodnocuje pro stovky účastníků. BIRDu při tom pomáhá filtrovací jazyk, který patřil k cílům projektu už v roce 1999. Má proměnné, funkce, podmínky a datové typy pro prefixy, cesty přes AS nebo seznamy communities. Správce v něm může napsat společnou logiku a pro jednotlivé sousedy jen měnit vstupní hodnoty.
Už v roce 2014 se filtry překládaly do bajtkódu, tedy instrukcí pro interní interpret BIRDu. Při vyhledávání v množinách používal BIRD stromové struktury, takže nemusel pokaždé procházet všechny položky jednu po druhé.
Rozdíl mezi BIRDem a Quaggou byl vidět na zápisu stejných pravidel NIX.CZ. Pro Quaggu bylo potřeba pro každého člena napsat vlastní seznamy communities a pravidla se střídajícími se řádky deny a permit. V BIRDu stačila jedna funkce s parametrem. Následující výřez ukazuje tutéž myšlenku v syntaxi současných řad BIRD 2 a 3, zjednodušeně a jen pro ilustraci. Funkce rozhoduje, jestli se právě zpracovávaná cesta smí poslat klientovi s daným číslem AS:
define RS_ASN = 47200;
function rs_export_ok(int peer_asn) -> bool
{
if (0, peer_asn) ~ bgp_community then return false; # tomuto klientovi ne
if (RS_ASN, peer_asn) ~ bgp_community then return true; # tomuto klientovi ano
if (0, RS_ASN) ~ bgp_community then return false; # nikomu dalšímu
return true; # jinak všem
}
protocol bgp member_as64500 {
local as RS_ASN;
neighbor 192.0.2.10 as 64500;
rs client;
ipv4 {
import filter member_as64500_in; # vstupní kontrola cest člena
export where rs_export_ok(64500);
};
}
Operátor ~ tady kontroluje, jestli je daná community připojená k cestě. Funkce nejdřív zkontroluje zákaz pro konkrétního klienta. Pokud ho nenajde, ověří výslovné povolení pro tohoto klienta a teprve potom obecný zákaz pro všechny. Volba rs client zapíná chování potřebné pro průhledný route server, včetně zachování cesty bez přidání jeho vlastního AS.
Importní filtr, který v ukázce není rozepsaný, kontroluje příchozí oznámení od člena. Exportní funkce pak rozhoduje, co se tomuto členovi smí poslat. Pro dalšího účastníka přibude obdobný blok protocol bgp s jiným číslem AS a vlastními vstupními pravidly. Historický příklad používá standardní communities se dvěma šestnáctibitovými čísly; pro dnešní čtyřbajtová ASN je potřeba zvolit jiný způsob značení, například large communities.
Takové bloky obvykle nepíše člověk, ale skript. NIX.CZ měl v roce 2014 kolem 130 BGP relací, konfiguraci skládal z interní databáze a registru RIPE DB, přegeneroval ji každé dvě hodiny a výsledek měl zhruba čtyři miliony znaků.
Kdyby každé načtení konfigurace přerušilo všechna spojení, server by je musel několikrát denně znovu navazovat. BIRD proto nechává nedotčené protokoly běžet, změněné se snaží překonfigurovat za chodu a restartuje je, jen když to povaha změny vyžaduje. Po příkazu configure timeout se navíc sám vrátí k předchozí konfiguraci, pokud změnu nikdo včas nepotvrdí.
Jak drahé může být zpracování nové konfigurace, ukazoval v roce 2018 OpenBGPD. Na malém kanadském uzlu YYCIX měla jeho vygenerovaná konfigurace 370 tisíc filtrovacích pravidel. Znovunačtení trvalo hodinu, během které route server nezpracovával aktualizace ani oznámení o stažení cest.
Z NIX.CZ do Londýna, Frankfurtu a Amsterdamu
První zkušenosti z provozu na route serveru získal BIRD už v roce 2009 v NIX.CZ. V srpnu téhož roku projekt oznámil, že ho používá i londýnský LoNAP. Nasazení v NIX.CZ dalo ostatním uzlům možnost posoudit, jak BIRD obstojí v reálném provozu.
Další uzly se přidávaly rychle. Elisa Jasinska z AMS-IX a Chris Malayter ve srovnání route serverů z roku 2010 označili BIRD za nejstabilnější route server, jaký testovali. V lednu 2010 ho nasadil londýnský LINX, v únoru moskevský MSK-IX a frankfurtský DE-CIX, v roce 2011 švédský Netnod a v srpnu 2012 AMS-IX. LINX projektu v roce 2010 udělil cenu za mimořádný přínos, kterou předtím několik let nikomu nedal. Archiv novinek na webu projektu pak pokračuje přes uzel v CERNu, japonský JPNAP nebo nigerijský IXPN až po uzly v Poznani a v Řecku.
Podle přehledu Euro-IX běžel BIRD v roce 2011 na 15 z 37 sledovaných uzlů, tedy přibližně na 41 procentech, zatímco Quagga měla 22 procent a Cisco 13. Filip to v roce 2012 v rozhovoru pro E15 shrnul větou: „Díky nasazení v mnoha propojovacích uzlech můžeme s trochou nadsázky tvrdit, že velká část paketů současného světového internetu najde svůj cíl díky našemu softwaru BIRD.“ V roce 2015 už CZ.NIC s odkazem na přehled Euro-IX za předchozí rok hlásil 64 procent.
Za tím vším přitom stála hrstka lidí. Zajíček byl ještě v roce 2012 prakticky jediným vývojářem na plný úvazek a vedle toho dodělával doktorát. Placenou nepřetržitou podporu BIRD neměl, dotazy uzlů řešil Filip se Zajíčkem po e-mailu. „Řešíme je velice rychle, protože nechceme, aby naše produkty měly chyby. Zatím to všem vždy stačilo,“ říkal Filip.
Mezitím si BIRD našel cestu i mimo uzly. V září 2012 se dostal do serverů Netflix Open Connect, které Netflix umisťuje přímo k poskytovatelům internetu, aby obsah dostal blíž k divákům. „V Netflixu si BIRD sami našli a jenom nám oznámili, že ho nasadili,“ popsal to Filip. Mezi dalšími známými uživateli projektu jsou Akamai a Fastly. Uplatnění má BIRD také v datových centrech nebo při sběru a analýze směrovacích dat.
Vývojář na něj může narazit i v Kubernetes. Síťová vrstva Calico ho při použití BGP spouští na jednotlivých nodech clusteru, kde pomáhá šířit informace potřebné ke směrování provozu mezi nimi. Podle dokumentace Calica mu konfiguraci generuje nástroj confd z dat v úložišti a při změně zařídí její nové načtení. Ani tady konfiguraci BIRDu nepíše člověk.
Strop jednoho jádra
Úspěch na uzlech přinesl nový problém. Největší nasazení měla podle DE-CIX v roce 2016 kolem tisíce BGP sousedů a BIRD zpracovával směrovací informace v jednom vlákně. Zpracování nové cesty nekončilo jejím vložením do tabulky. Příslušná funkce se vrátila až po dokončení navazujícího exportu ke klientům. Při tisíci sousedech už se za jedinou přijatou změnou mohlo skrývat hodně práce.
Po spuštění route serveru se tato práce nahromadí: server musí od sousedů přijmout cesty, zpracovat je a rozeslat výsledky. Ustálení směrovacích informací se říká konvergence. Matějka později poznamenala, že o multithreading stojí hlavně uzly, protože nikdo jiný nečeká dvacet minut, než všechno zkonverguje.
DE-CIX se to v roce 2016 pokusil obejít zvenčí. Výzkumníci Benedikt Rudolph a Sebastian Abt rozdělili práci mezi několik procesů BIRD, které se navenek tvářily jako jediný soused. Příchozí spojení rozdělovali podle podsítě klientů a pomocí překladu cílových adres, DNAT, je směrovali k příslušnému procesu. V jejich měření trvalo naučit se 76 500 prefixů jednomu procesu 165 sekund, dvěma 150 a čtyřem 108. Čtyři procesy ovšem spotřebovaly dvojnásobek paměti. Mezi dalšími kroky autoři uváděli jednoduchý multithreading přímo v BIRDu.
Než k němu došlo, projekt vyřešil jinou zvláštnost původního návrhu. BIRD 1 měl pro IPv4 i IPv6 jeden zdrojový kód, ten se ale překládal do dvou samostatných démonů, bird a bird6. BIRD 2 z prosince 2017 obě rodiny adres spojil do jednoho programu. Zavedl kanály, kterými se směrovací protokol připojuje k tabulkám pro jednotlivé druhy adres, a vytvořil prostor pro další rozšiřování. Přibylo například automatické načítání podkladů pro ověřování RPKI a postupně i podpora dalších typů směrovacích informací. Podpora BIRD 1 skončila s koncem roku 2023.
BIRD 3 vyšel jako první testovací alfa v březnu 2022. Matějka už v únoru zveřejnila srovnání výkonu s verzí 2.0.8 na Xeonu s osmi fyzickými jádry a šestnácti hardwarovými vlákny. V konfiguraci, kde byli všichni klienti napojení na jednu tabulku, zkrátila alfa dobu konvergence zhruba na osminu. S pomocnými importními a exportními tabulkami byla šest- až osmkrát rychlejší.

Nejtěžší scénář se dvěma miliony cest a tisícem sousedů ale nezvládla dobře ani jedna verze. BIRD 2.0.8 se k cíli dopracoval po skoro dvou hodinách a alfa se nevešla do 32 GB paměti. Stabilní BIRD 3.0.0 vyšel až v prosinci 2024. Projekt dnes uvádí, že BIRD 2 zvládne v jednom vlákně přes tisíc BGP sousedů a BIRD 3 bez potíží obslouží přes pět tisíc.
Obě generace jsou dnes udržované souběžně. Poslední opravné verze 3.3.2 a 2.19.2 vyšly 30. července 2026. Řady 3.3 a 2.19 mají podporu do půl roku po vydání 3.4 a 2.20, zatímco dlouhodobé řady 3.1 a 2.17 sledují životní cyklus Debianu 13 Trixie.
Vývojáři přidávali podporu více vláken do stávajícího kódu. Chtěli zachovat implementace protokolů z BIRDu 2, jejichž jednotlivé části se ovšem mohly navzájem přímo volat. Matějka tenhle přístup označuje za geniální pro jedno vlákno a za peklo deadlocků pro víc vláken. Hrozilo totiž, že se vlákna navzájem zablokují při čekání na zámky. Vývojáři proto rozdělili program na zamykací domény a určili, které další domény smí rutina zamknout podle toho, jaké zámky už drží.
Protokol tak smí vstoupit do tabulky, ale tabulka do protokolu ne. Místo přímého volání mu pošle upozornění. Export cest se stal asynchronním: po přijetí cesty a výběru nejlepší varianty se změna zaznamená, zatímco její předání jednotlivým klientům se může zpracovat samostatně. Program tak může rozdělit práci mezi více vláken, aniž by vývojáři museli naráz nahradit všechny implementace protokolů. Cenou je složitost, která se ještě připomene.
Cena za vítězství
Čím víc uzlů na BIRD přecházelo, tím víc vadilo, že všude běží tentýž software. Dva servery ochrání před poruchou jednoho stroje, ale stejná chyba v programu může postihnout oba. Pokud různé uzly používají stejný program, může je chyba zasáhnout současně. V NIX.CZ už v roce 2011 sloužila dvojice route serverů, z nichž jeden běžel na BIRDu a druhý na Quagge.
Trh se ale vyvinul opačně. OpenBGPD podle svého vývojáře Claudia Jekera do začátku desátých let patřil k nejoblíbenějším route serverům, ale výkonem filtrování nestačil růstu internetu a podíl ztratil. Job Snijders na setkání Euro-IX v dubnu 2018 shrnul, že prakticky všechny uzly s pečlivě filtrovanými route servery provozují BIRD, a položil dvě nepříjemné otázky. Co když nějaká vadná zpráva BGP proběhne internetem a shodí všechny route servery naráz? A co když organizace, která ten jediný software financuje, přestane vývoj platit?
Odpověď přišla v penězích. Díky fondu komunitních projektů RIPE NCC mohl Jeker od června 2018 pracovat na OpenBGPD na plný úvazek. Efektivnější práce s množinami prefixů a čísel AS pomohla v OpenBGPD 6.4 srazit konfiguraci YYCIX ze 370 tisíc pravidel pod šest tisíc. OpenBGPD navíc při načítání nové konfigurace mohl dál zpracovávat změny cest.
V březnu 2021 se AMS-IX, DE-CIX, LINX a Netnod spojily s nizozemskou nadací Route Server Support Foundation, aby financovaly druhý plnohodnotný route server postavený na OpenBGPD. Technický ředitel DE-CIX Thomas King to při oznámení spolupráce zdůvodnil bez obalu: téměř všechny route servery podle něj stojí na jediném uznávaném open source softwaru. Největší uživatelé BIRDu tak začali platit jeho konkurenci. Chtěli mít vedle něj rovnocennou alternativu, která nebude sdílet stejné chyby.
LINX ukazuje, jak to vypadá v provozu. Od odstranění Quaggy v roce 2020 běžel na obou route serverech hlavní londýnské sítě LON1 BIRD. Od roku 2022 LINX nasazoval OpenBGPD na svých dalších peeringových sítích a v říjnu 2025 dokončil změnu i v LON1. Vedle BIRDu tam od té doby slouží také OpenBGPD. Uzel to výslovně popisuje jako ochranu před chybami, zranitelnostmi i budoucími změnami ve vývoji jednoho softwaru.
Jak reálné to riziko je, ukázalo září 2025. Tehdy zveřejněná chyba CVE-2025-59688 dovolovala shodit zranitelné verze BIRDu 3 pouhým ukončením relace BGP s doprovodnou textovou zprávou, kterou umožňuje RFC 9003. Matějka to ve svém rozboru chyby ilustrovala příkazem disable bgp1 "lol bye": na jedné straně zdvořilé rozloučení, na druhé spadlý démon. Na route serveru přitom takové spojení udržuje každý připojený klient.
Rutina obsluhující zprávu si sáhla pro paměť do globálního poolu, k němuž přes pravidla zamykacích domén neměla přístup. Ochranná kontrola proto ukončila celý proces, aby zabránila možnému deadlocku. Chybu nahlásil Rob Lister z LONAP, tedy z uzlu, který BIRD jako route server nasadil už v roce 2009. Dopad byl podle Matějky nejspíš malý, protože BIRD 2 chybou netrpěl a hodně provozovatelů na něm zůstává. V tomto konkrétním případě tedy část nasazení ochránila starší větev téhož projektu; nezávislou implementaci ovšem nenahrazuje.
V červnu 2026 tým popsal a opravil další bezpečnostní chybu. Při porovnávání mimořádně dlouhého AS_PATH s maskou mohl filtr přepsat paměť na zásobníku, s možností vzdáleného spuštění kódu. Útok přes BGP vyžadoval povolené rozšířené zprávy, dostatečně dlouhou cestu a filtr, který příslušné porovnání skutečně prováděl. Už v květnu, kdy tým na opravách nahlášených chyb pracoval, radil provozovatelům kontrolovat délku cest a seznamů communities před složitějšími operacemi. První linii obrany tak znovu tvořil filtrovací jazyk.
Proč právě BIRD
Route servery jsou úzká nika. Provozují je správci propojovacích uzlů, jejich službu pak využívají stovky připojených sítí. Filip se v roce 2012 dokonce divil, že route server zavedlo Cisco, protože pro firmu takové velikosti to podle něj není zásadní trh. Do této mezery se vešel malý tým, pro který se potřeby uzlů staly hlavní náplní práce.
BIRD do ní přinesl to, co si jeho autoři vytkli deset let předtím, než ho velké uzly nasadily: flexibilní jazyk pro filtrování cest, snadnou rekonfiguraci a přenositelného démona, kterému stačí obyčejný unixový server. Nasazení v NIX.CZ ukázalo, jak tyto vlastnosti obstojí v praxi. Že si vedle něj dnes velké uzly financují další implementaci, je zvláštní druh uznání. Berou ho jako kus kritické infrastruktury a počítají i s tím, že může selhat. Ve frankfurtské příručce DE-CIX přitom pořád stojí stejná věta: službu obsluhuje BIRD.