AS path je BGP povinný atribut. Obsahuje seznam čísel autonomních systémů (ASNs), přes které je prefix (rozsah adres) propagován. Například AS path pro ripe.net 193.0.19.25 může vypadat:
test@juniper> show route protocol bgp 193.0.19.25
inet.0: 275156 destinations, 374067 routes (275106 active,
0 holddown, 76 hidden)
+ = Active Route, - = Last Active, * = Both
193.0.18.0/23 *[BGP/170] 1w0d 17:01:53, localpref 100
AS path: 15685 1299 3333 I
> to 10.0.0.254 via ge-0/0/0.0
Má-li směrovač k danému prefixu více cest, může být délka AS path při výběru nejlepší cesty rozhodující.
AS path prepending neboli „umělé“ prodloužení AS path se užije v případě multihomingu, kdy chceme pro příchozí provoz preferovat jeden upstream před druhým.
Dne 16.2.2008 si takto svoji cestičku v globální směrovací tabulce do Uherského Hradiště/Broda (AS47868) prodloužila společnost SUPRO-NET. Využila zmiňované možnosti “AS path prependingu“ pro svůj druhý upstream a nešetřila.
Běžně stačí svoje AS znásobit jednociferným číslem. Ale 251x se ukázalo, jako velké sousto pro starší směrovače/staré verze IOSu či jakékoliv implementace BGP, které si neporadí s delším AS path. Následkem bylo rozpojení BGP sezení, velké BGP updaty a výpadky konektivity.
Článek na renesys.com popisuje, že to nebyl úmysl, ale chyba správce a bug routeru MikroTik.
Že prefixy s delším AS path nejsou ojedinělé, se můžete přesvědčit na http://bgpmon.net/maxASpath.php
Velmi dlouhé AS path jsou nerozumné, protože zbytečně zabírají systémové prostředky na směrovačích. Nejsou však v rozporu s RFC4271 . V BGP UPDATE zprávě jsou pro délku atributů vyhrazeny 2 Byty (64KB), takže AS path je omezeno snad jen samotnou velikostí BGP UPDATE zprávy, která je 4KB.
Zajímalo mě, jak se k tomu staví jednotlivé implementace. Zkoušel jsem příkazy pro omezení délky AS path, možnosti prodloužení AS path a nakonec import prefixu s velmi dlouhým AS path. Testovány byly tyto implementace Cisco, Juniper, Quagga a BIRD.
Testováno s IOS 12.4(11)T2.
Cisco ve starších IOSech mělo s delším AS path vážné problémy! Jak se jim vyvarovat?
Od IOS 12.0(17)S by měl být implementován příkaz „bgp maxas-limit“
#bgp maxas-limit ?
<1-2000> Number of ASes in the AS-PATH attribute
pokud příkaz není dostupný, můžete použít „ip as-path access-list“ a „filter-list/route-map“ nebo sáhnout po novějším IOS.
Maximální hodnota 2000 u „bgp maxas-limit“ je taková Cisco hrátka, protože v aktuální dokumentaci uvádí <1-255>. I když je Vám umožněno zadat více, bude limit pro importované prefixy stále 255 a to i v případě, neuvedete-li příkaz „bgp maxas-limit“ vůbec.
A aby to nebylo tak jednoduché, je tu ještě odlišnost ve výpisech.
# sh ip bgp neighbors 10.0.0.22 route … zobrazuje přijaté a akceptované prefixy
V případě „bgp maxas-limit“ s hodnotou < 255, nejsou ve výstupu prefixy s delším AS path logicky zobrazeny. Ale s hodnotou >= 255 nebo bez samotného příkazu pro omezení AS path, jsou zobrazeny jako akceptované, nejsou však zařazeny do směrovací tabulky.
Ukázka omezení délky AS path na 15:
cisco(config)#router bgp 64551
cisco(config-router)#bgp maxas-limit 15
Při překročení limitu 15 ASNs se prefix ignoruje a důvod je zalogován.
*Feb 19 20:12:27.057: %BGP-6-ASPATH: Long AS path 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 15685 1299 3333
received from 10.0.0.20: More than configured MAXAS-LIMIT
Pravděpodobně jako prevence dlouhých AS path, je v IOS prodloužení AS path omezeno na maximálně 10 ASNs pro jednotlivé příkazy.
cisco(config)# route-map prepend-as permit 10
cisco(config-route-map)#set as-path prepend 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551
cisco(config-route-map)#set as-path prepend last-as 10
Při pokusu zadat více, skončíte s chybovou zprávou.
cisco(config-route-map)#set as-path prepend 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551
% Cannot have more than 10 as-paths prepended
% Cannot have more than 10 as-paths prepended
Pokud upravujete AS path pro prefix, který nemá původ u Vás, můžete přidat dalších 20 ASNs aplikací route-mapy při importu.
cisco(config-router)#neighbor 10.0.0.22 route-map prepand-as ?
in Apply map to incoming routes
out Apply map to outbound routes Celkem lze prodloužit AS path až o 40 ASNs + 1 ASN implicitně. Tranzitní AS s Cisco směrovači si musí dát pozor na novou chybu a omezit AS path. V opačném případě může dojít při exportu k přerušení BGP spojení.
Testováno s JUNOS verzí 9.2R2.15.
Alternativou pro „bgp maxas-limit number“ je AS path regulární výraz, který následně aplikujeme ve směrovací politice.
AS path regulární výraz pro 91 ASNs a více.
[edit policy-options]
test@juniper# set as-path maxas-limit ".{91,}"
Rozšíření importovací politiky o zamítnutí všech prefixů s delším AS path než 90.
[edit policy-options policy-statement nix-import term reject-long-aspath]
test@juniper# set from as-path maxas-limit
test@juniper# set then reject
Výsledná konfigurace.
[edit policy-options ]
test@juniper# show
policy-statement nix-import {
...
term reject-long-aspath {
from as-path maxas-limit;
then reject;
}
...
}
set as-path maxas-limit ".{91,}"
Odmítnuté prefixy pak naleznete takto:
test@juniper> show route receive-protocol bgp 10.0.0.21 hidden
inet.0: 249888 destinations, 249891 routes (249886 active,
0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
10.123.0.0/16 10.0.0.1 0 64551 64551
64551 ... výpis zkrácen ... 64551 64551 64551 64551 64551 64551 I
10.124.0.0/16 10.0.0.25 0 64551 64551
64551 ... výpis zkrácen ... 64551 64551 64551 64551 64551 64551 I
Také Juniper omezuje vytvoření velmi dlouhých AS path. Prodloužit AS path se dá třemi příkazy:
as-path-prepend as-path-string ... omezuje na 30 ASNs nebo na maximální délku řetězce 256
as-path-expand last-as count n ... n = kolikrát se poslední ASNs zopakuje a to v rozmezí 1..32
as-path-expand as-path-string ... omezuje na 30 ASNs nebo na maximální délku řetězce 256
Maximálně tedy můžeme prodloužit AS path o 62 ASNs.
V případě překročení limitu 30ti ASNs pro daný příkaz dostaneme chybovou zprávu:
AS path too complex
error: configuration check-out failed
A pokusíme-li zadat řetězec delší než 256 znaků, budeme informováni o invalidním řetězci a prefix nebude vůbec propagován.
test@juniper# commit
[edit policy-options policy-statement export-limited term allow-ripe-prefix then as-path-prepend]
'as-path-prepend "25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 ... výpis zkrácen ... 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 "'
Insufficient buffer space for string
[edit policy-options policy-statement export-limited term allow-ripe-prefix then as-path-prepend]
'as-path-prepend "25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 ... výpis zkrácen ... 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 "'
Policy: Invalid string
commit complete
testovaná verze 0.99.9
Omezení délky AS path na 30 ASNs:
ip as-path access-list maxas-path deny ( [0-9]+){30}$
ip as-path access-list maxas-path permit .*
Aplikujeme na příchozí prefixy:
neighbor 10.0.0.21 filter-list maxas-path in
Quagga neumožní prodloužit AS path více než o 24 ASNs.
Při pokusu zadat více, dostaneme chybovou zprávu a BGP démon se nespustí. Přes VTY sice můžete zadat více, ale příkaz bude tiše ignorován.
There is no such command.
Error occured during reading below line.
set as-path prepend 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 3333
testovaná verze 1.0.12
Omezení délky AS path na 35 ASNs:
protocol bgp {
export all;
import filter {
if bgp_path.len > 35 then reject;
accept;
};
local as 64502;
neighbor 10.0.0.20 as 25192;
}
Filtry můžete testovat pohodlně z příkazové řádky BIRD klienta.
V ukázce má importovaný prefix 193.0.18.0/23 délku AS path 35.
# ./birdc -s bird.ctl
BIRD 1.0.12 ready.
bird> show route all filter {if bgp_path.len > 35 then reject; accept;}
193.0.18.0/23 via 10.0.0.20 on eth0 [bgp1 17:21] (100) [AS3333i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 25192 25192 25192 25192 25192 25192 25192
25192 25192 25192 25192 25192 25192 25192 25192 25192 25192
25192 25192 25192 25192 25192 25192 25192 25192 25192 25192
25192 25192 25192 25192 25192 15685 1299 3333
BGP.next_hop: 10.0.0.20
BGP.local_pref: 0
bird> show route all filter {if bgp_path.len > 34 then reject; accept;}
bird>
Prodloužení AS path je omezeno interní velikostí atributů 1KB. Limitu je většinou dosaženo při cca 250 ASNs. Při překročení, obdržíme chybovou zprávu a BGP prefix nebude správně propagován.
20-02-2009 14:08:35 <ERR> BGP: attribute list too long, ignoring the remaining attributes
Import prefixu s velmi dlouhým AS path
A jak si poradily jednotlivé implementace s importem prefixu, jehož AS PATH čítala 560 ASNs. Takto dlouhý BGP update byl vytvořen úpravou zdrojových kódů BIRD.
| Cisco | import zvládne, ale prefix nezařadí do směrovací tabulky |
| Juniper | OK |
| Quagga | OK |
| BIRD | OK |
Závěr
Máte-li na svém směrovači alespoň verze, které byly testovány, tak nebudete mít při samotném importu prefixu s dlouhým AS path problém.
Na směrovačích Cisco se však objevila nová chyba. Překročíte-li při prodloužení AS path délku 255 ASNs a tento prefix vypropagujete, bude BGP sezení přerušeno a následně cyklicky restartováno. Detailně se této nové chybě budu věnovat v dalším článku.
Dodatek:
1.3.2009 – Quagga má obdobný problém při exportu s AS path > 255, a to i bez dodatečného prependingu. Ve verzi 0.99.10 byla chyba opravena.
2.3.2009 – Rozbor Cisco chyby je součástí článku Proč a zda Supronet shodil Internet.
Emanuel Petr
Zdroje:
http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml
http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length
http://bgpmon.net/maxASpath.php
http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#wp1013932
http://www.juniper.net/
http://www.quagga.net/
http://bird.network.cz/
http://www.ietf.org/rfc/rfc4271.txt
http://blog.ioshints.info/2009/02/oversized-as-paths-cisco-ios-bug.html
Konečně máme kořen DNSSEC
Ačkoliv už pět správců domén nejvyšší úrovně (TLD) zavedlo technologii DNSSEC, stále nám chybí jakoby krok číslo 1, tedy podpis té úplně prvotní, neboli kořenové zóny. Pokud tedy chci v současné době plně validovat záznamy ve všech podepsaných zónách, musím si stáhnout klíče všech pěti organizací a starat se o jejich aktualizaci. To je pochopitelně poměrně nepraktické, každý správce domény má jiný způsob, jak klíče zveřejňuje. V praxi to tedy funguje tak, že každý ISP, který validaci provádí, si buď sleduje aktuálnost obvykle té pro něj nejzajímavější domény a ostatní ignoruje, nebo použije úložiště klíčů mechanismu DNSSEC Lookaside Validation – DLV. DLV je poměrně elegantní řešení, nicméně ne každý má důvěru v konkrétního provozovatele DLV. Navíc DLV není zcela obecně přijaté a standardizované řešení.
Vzhledem k tomu, že podepsání kořenové zóny z mnoha důvodů ještě nedošlo, rozhodla se organizace IANA, která se jinak o změny v kořenové zóně stará, jednat a vytvořila prozatímní řešení, do doby než se spory vyjasní a dojde k podpisu. Proto vytvořila tak zvaný ITAR – Interim Trust Anchor Repository. Toto řešení je technologické odlišné od DLV a je z hlediska typu použitého DNS resolveru zcela neutrální. Dalším plusem je, že jej spravuje důvěryhodná organizace, která se o změny v kořenové zóně stará a má tedy autentizační mechanismy pro komunikaci se správci TLD. Výhodou je poměrně přesná specifikace toho, za jakých podmínek je služba provozována, a toho, co se stane po podpisu zóny. Ještě je třeba dodat, že narozdíl od DLV slouží ITAR pouze pro TLD. Způsob, jak nastavit DNS resolver pro spolupráci s DLV nebo ITAR popisuje kolega Surý ve svém článku na serveru Root.
Ač se vznik ITAR nemusí jevit jako důležitý krok, ve skutečnosti jím je. Může totiž přesvědčit registry, kteří čekají s implementací DNSSEC na podpis kořene, k urychlení plánu. Teď totiž kořen vlastně máme.
Ondřej Filip
Bind 9.6 a DNSSEC
Konsorcium ISC nedávno vydalo novou verzi pravděpodobně nejpoužívanějšího DNS serveru Bind. Bind od verze 9.6 kromě pravidelných oprav chyb a vylepšení přináší také zlepšení podpory pro technologii DNSSEC.
Bind 9.6 konečně podporuje standard NSEC3, který přináší více soukromí do podepsaných zón. Tento standard byl vydán jako RFC5155 před necelým rokem a s novou verzí Bindu je konečně podporován všemi významnými open source DNS servery podporujícími DNSSEC (Bind, NSD, Unbound).
Další novinka by měla výrazně zjednodušit správu DNSSEC podepsaných domén. Bind 9.6 přináší automatické přepodepisování zónových souborů dynamických zón. Osobně jsem ještě neměl čas se podívat na to, jak to celé funguje, protože jsem se zabýval následujícím bodem, ale myslím si, že je to správný krok ke zjednodušení nasazení DNSSECu.
Onen další bod, který mě osobně zaměstnával posledních pár měsíců, je podpora PKCS#11 přímo v Bindu. Nová verze přináší nástroj dnssec-keyfromlabel, který umožňuje vytvořit DNSSEC klíč z dat uložených na kryptografickém zařízení (např. takové ty různé USB tokeny). Mělo by to fungovat s openssl a opencryptoki – tj. musíte mít funkční podporu PKCS#11 v openssl. Dnssec-keyfromlabel pak umí vytvořit dvojici souborů .key/.private ve speciálním formátu, který říká, na kterém zařízení najít soukromou část klíče. Zatím jsem neměl čas vyzkoušet tuto funkci na Linuxu, ale společně s Francisem DuPontem z ISC se nám před týdnem povedlo zprovoznit kartu SCA6000 pod Solarisem 10. Sice to zatím vyžaduje verzi z CVS, ale mám osobně slíbeno od ISC, že tato oprava, kterou je potřeba začlenit do hlavní vývojové větve, bude v další verzi řady 9.6 (tedy pravděpodobně v 9.6.1).
Za další z nových nástrojů pravděpodobně můžu já – dnssec-dsfromkey umí z klíče vytvořit DS záznamy bez toho, aby bylo potřeba podepsat zónový soubor. Nápad na tento nástroj vznikl na základě mé diskuze s inženýry z ISC, že v některých specifických případech trvá podepsání zóny i několik (desítek) minut – a je to dost neefektivní muset podepsat zónu, aby byl soubor s DS záznamy vytvořen.
Poslední věc, která stojí za zmínku je zahrnutí sady nástrojů ZKT do distribučního souboru Bindu (hledejte v adresáři contrib). ZKT obsahuje sadu nástrojů, která umí usnadnit práci s DNSSEC klíči a automatizaci podepisování zónových souborů. Používám jej na automatizaci podepisování našich zón. A také připravuji jeho zabalíčkování do distribuce Debian (a tím pádem časem propadne i do distribucí odvozených), nicméně v současnosti je build systém trochu nevhodný na balíčkování, takže to bude chtít ještě trochu společné práce s autorem na ZKT. A času se nikdy není dost.
Ondřej Surý
Jak zjednodušit DNSSEC?
Minulý týden jsem měl docela pěknou, plodnou debatu s Ondřejem Filipem, Danem Kaminskym a Paulem Wouterem o tom, jak usnadnit použití DNSSECu pro běžné uživatele. Dan je v tom poněkud radikální a vymýšlí systém, kdy by stačilo „nasadit novou verzi“ a všechny spravované domény by byly podepsané, tj. koncový uživatel by nemusel dělat nic. Osobně si myslím, že je to zatím příliš odvážné, a že je zatím potřeba postupovat po menších kouscích. Celé to totiž začíná být složitější ve chvíli, kdy každý doménový registr má vlastní verzi registračního systému a hierarchii dat uvnitř registru.
Nicméně s Paulem jsme pak rozebírali modely toho, jak to zjednodušit a zároveň respektovat různé registrační systémy. Je jasné, že první krok, který je potřeba udělat, bude vždycky muset být ruční – jedná se o vytvoření důvěry mezi doménovým registrem a prvotním DNSSEC klíčem. V případě naší národní domény bude zachovaný proces, kdy držitel doménového jména kontaktuje existujícím komunikačním kanálem svého registrátora a ten pošle zabezpečeným kanálem přes EPP protokol přidání (nebo změnu) DNSSEC klíče do centrálního registru.
Další krok už lze automatizovat. Pokud použijeme specifikaci RFC5011, která říká, jakým způsobem lze měnit DNSSEC kořeny důvěry, tak existuje možnost, že by DNS server podepsané domény mohl poslat speciální UPDATE zprávu (podepsanou stávajícím DNSSEC klíčem) o tom, že dochází ke změně DNSSEC klíče. Specializovaný DNS server by tuto zprávu zaznamenal, ověřil změnu a vygeneroval DS záznam pro nový klíč. Celý tento proces by mohl proběhnout bez lidského zásahu.
Na konci jsme se s Paulem dohodli, že tento koncept rozpracujeme ve formě Internetového Draftu a pokusíme se jej standardizovat na půdě IETF.
Docela by mě zajímalo, co si o tomto nápadu myslíte? Své připomínky můžete psát do diskuze níže.
Ondřej Surý
cz = us… aneb ztraceno v překladu
V rámci e-mailové debaty o zavádění DNSSEC s jedním ze zahraničních držitelů domény .cz z Holandska jsem byl upozorněn na zajímavý překladatelský oříšek. Na stránkách technické podpory CZ.NIC najdete wizard, který má uživatelům pomoci projít si procesem zavedení DNSSEC, který obsahuje kroky, jak postupovat. Jelikož je v češtině, použil tento uživatel translate Google a podívejte se na výsledek (klikněte pro zvětšení):
Překlad jména domény je přinejmenším hodně originální :) Z textu je každopádně patrné, že dobrý automatizovaný překlad ještě není možný, snad jen ve filmu.
PT