File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc / slt2001 / slt.tex
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Aug 22 12:33:54 2017 UTC (7 years, 7 months ago) by misho
Branches: bird, MAIN
CVS tags: v1_6_8p3, v1_6_3p0, v1_6_3, HEAD
bird 1.6.3

    1: \magnification=\magstep1
    2: \input epsf.tex
    3: \input mjmac.tex
    4: 
    5: \language=\czech
    6: \chyph
    7: 
    8: \hsize=160truemm	% A4 with 25mm margins
    9: \vsize=247truemm
   10: \parindent=2em
   11: \nopagenumbers
   12: 
   13: \def\hdr#1{\medskip\leftline{\bf #1}\smallskip}
   14: \def\\{\hfil\break}
   15: \def\BIRD{{\sc Bird}}
   16: 
   17: \def\inititemize{\vskip 1pt\begingroup
   18: \parskip=1pt plus 0.3pt minus 0.1pt
   19: \advance\leftskip by 3em
   20: \advance\rightskip by 3em
   21: \parindent=0pt
   22: }
   23: 
   24: %%% Úvod a historie projektu
   25: \hdr{Na počátku bylo vejce aneb Úvodem}
   26: 
   27: \noindent Internet i UNIX jsou na světě již pěkných pár pátků. Počítače pracující
   28: pod nepřeberným množstvím unixovských systémů od nepaměti fungují jako
   29: internetové poštovní servery, name-servery a menší routery. Skoro by se zdálo, že
   30: si tyto dva světy už nemají co nového říci. V~posledních letech ovšem
   31: výrazně vzrostl výkon běžných PC-ček a objevily se pro ně karty podporující
   32: nejrůznější síťové technologie, a~tak se tyto počítače staly vhodnými
   33: kandidáty i~pro funkci routerů. Na~mnoha místech tak starší PC-čko
   34: s~volně šiřitelným softwarem předstihlo svého staršího a dražšího
   35: komerčního sourozence. Ačkoliv podpora routingu, firewallingu a inteligentní
   36: queue management v~jádrech těchto~OS (a~zejména Linuxu) je již velice
   37: vyspělá, ještě nedávno byly notně zanedbávány protokoly pro dynamický
   38: routing, tradiční unixovskou koncepcí umístěné do~uživatelského prostoru
   39: v~podobě routovacích daemonů.
   40: 
   41: Tento nedostatek se pokoušela mezi jinými napravit také skupina nadšenců
   42: na~pražské Matematicko-fyzikální fakultě UK, která se rozhodla jako svůj
   43: studijní projekt vytvořit nového routovacího daemona, který by se stal
   44: něčím víc než jen důstojným konkurentem komerčních routerů -- nejen
   45: kopíroval už známá řešení, ale také přispěl něčím novým; na~jedné straně
   46: být stabilním a efektivním programem pro praxi, na~straně druhé ovšem
   47: i~laboratoří pro snadné experimentování s~novými myšlenkami. A~tak se
   48: narodil projekt {\it BIRD Internet Routing Daemon} (zkráceně \BIRD\footnote{$^0$}{Projekt
   49: si samozřejmě vysloužil nejrůznější přezdívky -- od Ptáčete až po~Ptákovinu.}).
   50: 
   51: Původní plány byly smělé a rozhodné: Vytvořit nejlepšího routovacího
   52: daemona na světě, který by fungoval na~všech platformách, vyžadoval
   53: minimum strojového času a paměti, podporoval všechny routovací protokoly
   54: atd., zkrátka sen, jaký má být. Přeskočme nyní dva roky vývoje\footnote{$^1$}{během nichž
   55: z~některých požadavků samozřejmě sešlo -- například logem projektu
   56: se nakonec nestal ptáček nesoucí v~zobáčku snítku byliny řečené routa \dots}
   57: a podívejme se, co z~toho vzešlo.
   58: 
   59: %%% Svět routingu
   60: %% v~tištěné verzi přeskočíme
   61: 
   62: %%% Co BIRD dokáže
   63: \hdr{Když ptáčka lapají, pěkně mu zpívají aneb Feature list}
   64: 
   65: \noindent \BIRD\ dostal od svých sudiček do~vínku mnohé dary:
   66: 
   67: \def\icirc{\raise0.2ex\hbox{$\circ$}} % Signs frequently used for \itemize
   68: 
   69: \itemize\ibull
   70: \:Schopnost komunikovat protokoly IPv4 i IPv6.
   71: \:Podporu všech základních routovacích protokolů:
   72:   \itemize\icirc
   73:     \:RIPv2 (Routing Information Protocol, viz RFC 1723 a 2080)\\
   74:       Určen pro interní routing, dnes významu spíše historického.\\
   75:       Algoritmus: distance vector (Bellman-Ford).\\
   76:       Velmi pomalá konvergence, použitelý pouze pro maličké sítě.
   77:     \:OSPFv2 (Open Shortest Path First, viz RFC 2328)\\
   78:       Určen pro interní routing, v~současné době asi nejběžnější.\\
   79:       Algoritmus: link state (Dijkstra).\\
   80:       Rychlá konvergence, ale velice komplikovaný.\\
   81:       Zatím podporujeme pouze pro IPv4.
   82:     \:BGP4 (Border Gateway Protocol, viz RFC 1771 a 2283)\\
   83:       Standardní protokol pro externí routing mezi AS.\\
   84:       Rychlá konvergence, možnost administrativní filtrace.\\
   85:       Algoritmus: path vector (upravený Bellman-Ford).
   86:   \endlist
   87: \:Propojování protokolů a výměnu dat mezi nimi.
   88: \:Schopnost uplatňovat routing policy -- určovat, které routovací informace
   89:   budou od~kterých protokolů přijímány a do~kterých protokolů vysílány.
   90: \:Snadnou konfiguraci a údržbu, ale o~tom až později.
   91: \:Modulární architekturu umožňující snadné doplňování nových protokolů,
   92:   filtrů i jednoduché portování na~další systémy. (Interface k~routovacím
   93:   službám jádra je bohužel i mezi jednotlivými unixovskými systémy natolik
   94:   různorodý, že dokonce i~Linux 2.0 a Linux 2.2 jsou naprogramovány jako dva
   95:   odlišné porty.)
   96: \:A v~neposlední řadě kvalitní dokumentaci jak uživatelskou, tak
   97:   programátorskou (to je vítaný důsledek bytí školním projektem).
   98: \endlist
   99: 
  100: %%% A jak to všechno propojit
  101: \hdr{Svět z~ptačí perspektivy aneb Jak to všechno dát dohromady?}
  102: 
  103: \noindent Hlavním problémem ovšem není ani tak všechny tyto vymoženosti naprogramovat
  104: a popropojovat, nýbrž udělat to tak, aby z~toho nevznikl neudržovatelný
  105: a neefektivní zmatek\footnote{$^2$}{Nádherným příkladem je Mendelův pes,
  106: jak ho kdysi nakreslil pan Kantorek.}. Z~toho se zrodil modulární pohled
  107: na~svět routingu a následně i celá modulární architektura programu:
  108: 
  109: \bigskip
  110: 
  111: \centerline{\epsfxsize=0.9\hsize\epsfbox{../slides/obr5.eps}}
  112: 
  113: \medskip
  114: 
  115: Základem pohledu na~Internet z~naší \uv{ptačí perspektivy} je routovací
  116: tabulka. Na~ní jsou připojeny jednotlivé routovací protokoly -- jak
  117: protokoly reálné, tak i několik virtuálních, jako je například protokol
  118: Kernel zajišťující synchronizaci tabulky s~tabulkou jádra nebo protokol
  119: Static generující podle své konfigurace statické směrování. Každý z~protokolů
  120: posílá do~tabulky položky pro všechny routy, které se na~základě svých informací
  121: o~topologii sítě dozvídá. Tabulka pro každou síť vybírá na základě preferencí
  122: jednotlivých protokolů a jejich metrik optimální směr a ten oznamuje
  123: zpět protokolům. V~cestě ovšem v~obou směrech stojí filtry, které mohou
  124: tok dat regulovat -- některé položky odmítat, jiné upravovat (například
  125: jim přenastavovat metriky či tagy; to se dokonce vztahuje i~na
  126: atributy doplňované cílovým protokolem, protože nejprve cílový protokol
  127: nastaví implicitní hodnoty svých atributů, pokud je již položka neobsahovala,
  128: a teprve pak dojde k~filtrování).
  129: 
  130: Routovacích tabulek může dokonce existovat vícero a pomocí protokolu Pipe
  131: si mohou přeposílat vybrané položky. Tím můžeme zajistit například
  132: routing závislý na~zdrojové adrese či vstupním interfacu: u~Linuxu 2.2
  133: či novějšího nakonfigurujeme jádru více routovacích tabulek a každou
  134: z~nich připojíme na~jednu tabulku naši.
  135: 
  136: \hdr{Ptačí zpěv aneb User interface}
  137: %%% User interface: konfigurace, logging a filtry. Remote control.
  138: 
  139: \noindent Síť se mění a s~ní se musí měnit i konfigurace síťových
  140: komponent. Ta se pozvolna stala tradičním kamenem úrazu většiny routerů.
  141: U~tohoto kamene se totiž scházejí dva odvěcí nepřátelé:
  142: snaha o~snadnost a flexibilitu konfigurace a snaha o~nepřetržitý
  143: provoz sítě. A~jednou sleví ten, podruhé onen -- autoři některých
  144: routerů vsadili na~sílu textových konfiguračních souborů za~cenu
  145: toho, že se po~každé změně konfigurace musí router restartovat
  146: a po~nějakou dobu neroutuje, jiní zase podřídili non-stop provozu
  147: vše ostatní a stvořili konfigurování nepřeberným množstvím online
  148: příkazů, pomocí nichž se některé věci provádějí snadno, jiné,
  149: na~které autoři speciální příkaz nevymysleli, už obtížněji a ještě jiné
  150: vyžadují do~výsledného stavu dospět postupným provedením mnoha změn,
  151: což má obvykle za~důsledek daleko delší výpadek než jaký by byl vznikl
  152: reloadem celého routeru.
  153: 
  154: \BIRD\ se snaží dosáhnout obojího: používá textové konfigurační soubory,
  155: uživateli tak dává možnost vytvářet konfiguraci víceméně libovolným
  156: způsobem -- ať již ručním editováním, interaktivními programy či
  157: automatickým generováním pomocí scriptů. Po~změně konfigurace je
  158: ovšem schopen si novou verzi souboru přečíst, porovnat s~právě
  159: používanou konfigurací a změnám se za běhu přízpůsobit (pokud
  160: jsou změny příliš velké, může to způsobit restart
  161: některého z~protokolů, ale provoz těch, kterých se změna
  162: netýkala, to nijak neohrozí).
  163: 
  164: Konfigurace každého protokolu (lépe řečeno každé jeho instance --
  165: protokoly mohou být spuštěny několikrát na~různých rozhraních
  166: či nad různými tabulkami) vypadá přibližně takto:
  167: 
  168: \verbatim{   protocol bgp TestBGP {               # instanci si můžeme nazvat
  169:       local as 65000;			# náš AS
  170:       neighbor 195.39.3.64 as 5588;	# sousední AS
  171:       export all;			# posílat budeme všechno
  172:       import filter {                   # na vstupu některé odmítneme
  173:          if !(bgp_path ~ / ? 5588 ? /) then reject;
  174:          if net ~ [ 10.0.0.0/8+, 192.168.0.0/16+ ] then reject;
  175:          preference = 101;              # zbylým nastavíme preferenci
  176:          accept;                        # a přijmeme je
  177:       };
  178:    }}
  179: \noindent Vždy popisuje protokol, jeho parametry, připojení k~tabulkám
  180: (v~našem případě používáme tabulku implicitní) a nastavení vstupních
  181: i~výstupních filtrů.
  182: 
  183: Filtry jsou popisovány jednoduchým procedurálním programovacím jazykem,
  184: který má k~dispozici všechny informace o~právě zpracovávané položce, může
  185: se podle nich rozhodovat a libovolně je měnit. Díky tomu je možné jednoduše
  186: zadávat i velice složitá pravidla, definovat si podprogramy sdílené
  187: filtry patřícími k~více protokolům, i~počítat metriky pro jeden protokol
  188: na základě metrik protokolů ostatních.
  189: 
  190: Vítaným pomocníkem při odhalování problémů v~sítích je rovněž volitelné
  191: logování důležitých událostí a trasování činnosti protokolů: zde si je
  192: možno pro každý protokol vyžádat prakticky cokoliv počínaje základními informacemi o~běhu
  193: protokolu (připojování a odpojování sousedů apod.), přes výměnu položek
  194: mezi protokolem, filtry a jeho tabulkou, a konče detailním výpisem všech
  195: přijatých i odeslaných paketů.
  196: 
  197: Mimo to \BIRD\ disponuje \uv{dálkovým ovládáním} -- jednoduchým příkazovým
  198: rozhraním, přes které se mohou připojovat různí klienti a vydávat jak
  199: některé řídící příkazy (restarty protokolů, reload konfigurace, přepínání
  200: trasování, \dots), tak požadavky na~vypisování stavu routovacích tabulek
  201: a protokolů. U~těchto příkazů je možno využívat plné síly filtrovacího
  202: jazyka, takže chceme-li například znát všechny routy směrované pomocí
  203: BGP na jednoho konkrétního souseda, stačí položit dotaz typu
  204: 
  205: \verbatim{   bird> show route where source=RTS_BGP && gw=62.168.0.1}
  206: 
  207: \noindent a dozvíme se ihned vše, co jsme potřebovali. Ladění filtrů
  208: navíc usnadní i~to, že se můžeme zeptat na~obsah routovací tabulky
  209: z~pohledu některého z~běžících protokolů.
  210: 
  211: %%% BIRD uvnitř
  212: %\hdr{Ptačí anatomie}
  213: %% existuje progdoc
  214: 
  215: %%% Netradicni pouziti
  216: \hdr{Cesty tažných ptáků aneb Za hranicemi všedních dnů}
  217: 
  218: \noindent Hotová modulární implementace routovacího daemona samozřejmě
  219: svádí i k~méně tradičnímu využití. Zde se fantazii meze nekladou, autory
  220: samé během vývoje napadly například tyto triky:
  221: 
  222: \itemize\ibull
  223: \:{\I multirouter} -- \uv{schizofrenní} zařízení pracující na různých
  224:   skupinách interfaců jako různé routery řídící se různými pravidly,
  225:   ležící třeba i v~různých autonomních systémech. To je možno zařídit
  226:   patřičným nastavením jádra a buďto více běžícími \BIRD{}y nebo dokonce
  227:   jedním pracujícím s~několika různými routovacími tabulkami. Tak by
  228:   mohl například celý pražský NIX běžet na jediném routeru (pravda,
  229:   běžné PC by na to nestačílo), a přesto by si každý provider mohl sám
  230:   určovat a konfigurovat svou vlastní routovací politiku.
  231: \:{\I šedá eminence} -- \BIRD\ by ani nemusel běžet přímo na~stroji, který
  232:   pakety routuje, mohl by také hotové routovací tabulky diktovat
  233:   nějakému dedikovanému routeru disponujícím výkonnějším hardwarem,
  234:   a tak skloubit špičkovou propustnost \uv{velkého železa}
  235:   s~flexibilitou routeru bežícího pod unixovským systémem.
  236: \:{\I inteligentní mirror} -- aplikace se nemusí zastavovat u~routingu
  237:   jako takového, mnohdy je možno informace získané z~provozu routeru
  238:   využívat k~dalším účelům, například k~inteligentnímu přesměrovávání
  239:   klientů na~nejbližší mirror vašeho archivu.
  240: \endlist
  241: 
  242: %%% A co dal?
  243: \hdr{Čas ptáčat aneb Co dál?}
  244: 
  245: Přestože po~úspěšném obhájení projektu a prvních několika desítkách
  246: spokojených uživatelů (a samozřejmě i~pár opravených chybách) nyní vývoj
  247: spíše stagnuje, autoři již spřádají plány do~budoucnosti, které
  248: by měly \BIRD{}ovi přinést mimo jiné také routování multicastů, agregaci
  249: síťových prefixů, OSPFv3 pro IPv6, on-demand linky a porty na~další systémy.
  250: 
  251: %%% Reference na nás a ostatní routery
  252: \hdr{Snůška odkazů na závěr}
  253: 
  254: \noindent {\sc Bird Team} pod vedením RNDr. Libora Forsta ({\I forst@cuni.cz}) tvořili:
  255: $$\vbox{\halign{#\hfil & \quad \it # \hfil & \quad \it # \hfil\cr
  256: Ondřej Filip&feela@ipex.cz&http:/$\!$/feela.ipex.cz/\cr
  257: Martin Mareš&mj@ucw.cz&http:/$\!$/atrey.karlin.mff.cuni.cz/\char126mj/\cr
  258: Pavel Machek&pavel@ucw.cz&http:/$\!$/atrey.karlin.mff.cuni.cz/\char126pavel/\cr}}$$
  259: Domácí stránku projektu najdete na {\it http:/$\!$/bird.network.cz/,} odtamtud již
  260: vedou odkazy na~aktuální verzi, online dokumentaci i mailing list
  261: uživatelů.
  262: Všechna zmiňovaná RFC i mnoho dalších naleznete na {\it http:/$\!$/www.rfc-editor.org/},
  263: první myšlenky o~využívání ptactva v~Internetu sahají až k~RFC~1149.
  264: \BIRD\ není na~světě sám, má i~příbuzné; mezi nimi za zmínku stojí
  265: daemoni {\sc GateD} ({\I http:/$\!$/www.gated.org/}), \hbox{\sc Zebra} ({\I http:/$\!$/www.zebra.org/})
  266: a {\sc Mrtd} ({\I http:/$\!$/www.mrtd.net/}).
  267: O~IPv6 se bohužel zatím jen píše, na~jeho celointernetové nasazení se stále
  268: čeká a mezitím přibývá address-translatorů a dalších zvěrstev. Snad jediná
  269: větší síť používající tento protokol je experimentální virtuální síť 6-bone
  270: (viz {\it http:/$\!$/www.6bone.net/} a odkazy odtamtud).
  271: 
  272: Dotazy a připomínky posílejte buďto autorovi nebo celému {\sc Bird Team}u na~adresu
  273: {\I bird@bird.network.cz}.
  274: 
  275: \bye

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>