abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 4
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 22
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 3
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 2
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 771 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: IPv6 a hodně adres na interface

13.11.2012 16:57 Radek Hladik | skóre: 20
IPv6 a hodně adres na interface
Přečteno: 498×
Jedna z velkých výhod IPv6 je ohromné množství použitelných adres. Jedna z výhod této výhody by měla být to, že je možné každé službě přiřadit jednu IP adresu, kterou bude mít "na dosmrti". Proto bych se chtěl zeptat, zda má někdo praktické zkušenosti s větším počtem adres na jednom rozhraní. Typická představa je webserver, který má pro každou doménu vlastní IP. Dneska server zvládá několik set "malých domén", s rosotoucím výkonem to může být i násobně víc.

Řekněme, že tedy chci mít na jednom interface 1000 IPv6 adres. Než se pustím do praktického experimentování, chtěl bych vědět, zda někdo něco takového zkoušel/provozuje. Zatím jsem něco málo googlil, ale většinou jsem narazil jen na věci, týkající se více adres, než jedné, ale ne tak velkého množství...

V principu vidím tyto otázky:
  • Kernel - očekávám, že počet problém nebude, ale otázka je, zda opravdu všude všecky algoritmy budou O(1) nebo v nejhoším O(n)
  • Síťová karta - to je podle mně největši problém. Karta se musí nastavit, aby poslouchala v řádově tisíci multicastech (kvůli Neighbor Discovery). Nemám tušení, zda to zvládne každá karta nebo zda bude potřeba nějaká speciální. Nebo zda nebude lepší použít třeba nějakou virtuální a bridgeovat - MAC adresa bude pořád jen jedna, takže na straně ethernetu by s tím problém být neměl...
  • Správa IP adres - na takové množství už asi obyčejné ip addr nebude moc pohodlné, ideální by bylo, kdyby se daly všecky tyto adresy nějak označit - něco jako "secondary", ale jen ve smyslu administrace

Řešení dotazu:


Odpovědi

13.11.2012 17:09 NN
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Ja se jen zeptam bokem, k cemu to vubec bude dobre ?
13.11.2012 17:23 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Především jde o čistotu návrhu. V literatuře se často doporučuje mít pro každou službu vlastní IP, takže je možné "tahat služby jako kočka koťata", každý předpokládám někdy řešil server, který dělá víc věcí na jednom IP, kdy bylo potřeba jednu věc přesunout jinam...

Samozřejmě existují řešení na vyšší úrovni, například Virtuální Hosty, SNI, atd..., ale když už IPv6 láká na astronomická čísla IP adres, proč nevyužít jí? Prostě pro všechny typy služeb použít stejné řešení na stejné vrstvě. Prostě přijde zákazník s nějakou doménou, dostane 2001:neco:neco:prefixwebu::357, 2001:neco:neco:prefixsmtp::357, 2001:neco:neco:prefiximap::357,2001:neco:neco:prefixsip::357... A buď ty adresy budou na nějakém sdíleném serveru nebo budou každá na jednom...
xkucf03 avatar 13.11.2012 21:39 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
víc věcí na jednom IP, kdy bylo potřeba jednu věc přesunout jinam...
Tohle bych spíš řešil na úrovni DNS: V jednu chvíli to budeš mít třeba tak, že sql.example.com, www.example.com, smtp.example.com a imap.example.com budou směřovat na jednu IP adresu a později to můžeš rozdělit a dát poštu, databázi a weby na různé servery. DNS mi přijde ta správná vrstva abstrakce, na které by se to mělo řešit – naopak na IP adresu bych se dlouhodobě nijak nevázal – souvisí prostě s aktuálním fyzickým umístěním služby v síti a může se změnit s přechodem k jinému ISP nebo s přestěhováním serveru do jiné budovy. Rozhodně bych IP adresu nebral jako něco na celý život – doménové jméno klidně ano.

Naopak jako náhrada virtuálhostů a SNI ten větší počet IP adres smysl dává a asi je to správná cesta, byť třeba může mít nějaké dětské nemoci v současnosti.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.11.2012 21:43 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Rozlišování na úrovni DNS nelze provést u všech služeb a i tam, kde to jde, to nemusí být efektivní (je nutná analýza na úrovni aplikační vrstvy). V podstatě je to jedna z nešťastných daní, které platíme za příliš dlouhé odkládání přechodu na IPv6.
xkucf03 avatar 13.11.2012 21:53 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Šlo mi o případ, kdy doméně example.com přidělím nějakou IP adresu a všechny služby (web, sql, e-mail, ftp…) na ni nasměruji pomocí DNS. Žádné jiné domény tuhle IP adresu sdílet samozřejmě nebudou – takže nebude potřeba je rozlišovat na aplikační úrovni. Doména bude rozlišena IP adresou a jednotlivé služby číslem portu.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 13.11.2012 21:56 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Neříkám, že by to nešlo, nebo že by s tím byly nějaké problémy… ale k čemu by pak bylo číslo portu? To bychom se pak mohli dohodnout, že všechny služby poběží třeba na portu 100 a budeme uvádět jen IPv6 adresu :-)
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.11.2012 21:57 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Pochybuji, že tazatel na tom stroji hodlá provozovat tisíc různých služeb. Mnohem pravděpodobnější mi připadá možnost, že jde o tisíc instancí jedné služby (nebo několika málo).
13.11.2012 22:49 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Přesně viz poslední věta. DNS je u IPv6 samozřejmost/nutnost. Ale podstatná je i ta IP adresa, protože když chci přesouvat pouze jednu službu, musí mít jedinečnou adresu. Toho samozřejmě můžu dosáhnout tak, že ji nejprve v DNS změním, ale proč to neudělat hned od začátku, když mám adresní prostor, dámy prominou, jako kráva?

Jako příklad je opravdu vhodný ten web server. Je spousta domének, kde jsou tři stránky (homepage, kontakt a fotka) s návštěvností limitující k nule zleva. Ale pak se taková doménka rozjede a bude se pídit, zda jim jde SSL (ano jde a všude, bez nějakého SNI (otázka, zda bude dřív všude SNI nebo IPv6 budiž ponechána stranou, tady řeším koncepční problematiku)). Pak si najednou pořídí eshop a vlastní server... Ale obdobné je to s poštou (tam žádné virtuální hosty nejsou a vše se řeší přes username typu user@domena) a spol...

Tím vším neříkám, že je to to nejlepší řešení, ale podle mně stojí za prozkoumání, samozřejmě se může stát, že problémy s tím spojené přesáhnou přínosy...
13.11.2012 22:57 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Ještě jsem zapoměl, samozřejmě, pokud se mi změní prefix od ISP nebo to budu dělat v nějaké více rozdělené síti a přesunu servery z jedné do druhé, tak mi nezbývá, než IP adresu změnit. Ale to je stav, který v takovém případě nastane tak jako tak...
pavlix avatar 14.11.2012 01:50 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Tohle bych spíš řešil na úrovni DNS:
Já bych to taky při tvorbě standardů a software řešil na úrovni DNS SRV záznamů, ale i kdyby byla vůle, tak se to bude prosazovat deset a více let.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
14.11.2012 07:41 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
SRV záznam řeší přiřazení různých adres jednomu jménu v závislosti na službě. Neřeší nutnost rozlišovat virtuální server až podle aplikačního protokolu, pokud se více jmen překládá na stejnou adresu.
pavlix avatar 14.11.2012 10:15 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
SRV řeší problém, o které se tu mluvilo, tedy že chci každé službě na každé doméně volně přiřadit stroj, který se o ni bude starat. Stroj potom může disponovat záznamy typu A a AAAA.

Neřeší uměle vytvořené problémy ani problémy s nedostatkem adres. Nicméně tazatel se ptal v kontextu toho, že má hromadu IPv6 adres, kde nutnost překládat více jmen na jednu adresu nevzniká.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
14.11.2012 10:31 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Beru zpět, přečetl jsem si znovu pořádně příspěvek xkucf03 a opravdu píše něco jiného, než jsem si myslel.
Řešení 1× (Radek Hladik (tazatel))
13.11.2012 17:42 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Problémy se bohužel očekávat dají, už jsem pár bugů tohoto typu viděl, naposledy třeba tenhle v glibc. Co se efektivity týká, časově kritické operace budou závislé hlavně na rychlosti vyhledávání v routing cache (v novějších jádrech už jen FIB), takže tam bych až takový problém neviděl, při práci s konfigurací ale často dojde na tu lineární složitost. Čeho bych se bál, je resolver. I když pominu chyby jako výše odkazovaná, pořád je tam to nešťastné dotazování na seznam lokálních adres při každém getaddrinfo() - naštěstí už je tam v aktuálních verzích cache na výsledek.
13.11.2012 18:10 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Díky za podněty ke zkoušení. Lineární složitost u konfiguračních záležitostí mi tolik nevadí, ale ten resolver bude hodný pořádného otestování...
13.11.2012 17:42 mpel
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
1) IPv6 node ma za povinnost vykonavat DAD, takze "IP na dozivoti" je dobry, ale nerealny napad. Kdyz si kazdy rekne, ze jeho prefix "dead:beef:cafe: urcite nikdo jiny nepouzije a zacne ho natvrdo k necemu pridelovat, rozbije tim vsechny okolo sebe.

2) Nevim jak v Linuxu, ale v OpenBSD jsou IP adresy na interfejsech v cerno-cervenem strome. Takze neni problem jich mit klidne i tisice, ale samozrejme musite kazdy socket bindnout na tu spravnou.

3) Sitova karta s tim nema co docineni, pokud neumi IPv6 offloading. Kontaktujte vyrobce sve karty.

4) V OpenBSD je mozne se sitovkou dat do bridge virtualni porty vether(4) a na ne napsat description.
# ifconfig vether0 create up
# ifconfig vether0 description "potazmo"
# ifconfig vethet0 inet6 alias "..."
# ifconfig bridge0 add vether0
5) V Linuxu vam nikdo nebrani napsat si vlastni program, ktery s tim manipuluje pres netlink(7) a v textovem souboru drzi textove popisky. S pouzitim ip(8) to jde klidne v shellu.

6) Zopakujte si, co je referencni ISO/OSI model. Na sitove vrstve nereste multiplexing sluzeb.
13.11.2012 18:08 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
ad 1) nerozumíme si úplně přesně. Od ISP dostanu prefix 2001:1234:5678/48. Já si vyčlením prefix 2001:1234:5678:1111/64 pro webservery a třeba 2001:1234:5678:2222/64 pro SMTP... Doména něco.cz pak dostane třeba 2001:1234:5678:1111::123 pro webserver a 2001:1234:5678:2222::123 pro SMTP server. Ty IPčka pak normálně přidělím reálným strojům. Naprosto standardní situace a žádný DAD mi nedělá problém, jedině, když budu přesouvat IP z jednoho stroje na jiný...

ad 3) síťová karta má hodně co do činění. Pro každou IPv6 adresu se musí přihlásit do ethernetové multicast skupiny, což v principu znamená, že OS musí kartě říct, že framy pro tuto adresu jsou pro ní... (http://knihy.nic.cz/files/nic/edice/pavel_satrapa_ipv6_2012.pdf strana 163).

ad 5) vlasntí program je zřejmý, ale otázka je, zda už není něco "ve standardu", aby člověk nedělal kolo...

ad 6) pominu fakt, že ISO/OSI se v praxi nepoužívá (to už jsem tu řešil několikrát), ale připomínku chápu. Na druhou strany vy si zopakujte, co je model přesýpacích hodin a pak se můžeme bavit o tom, zda je lepší řešit multiplexing jednou na jendom místě nebo X-krát na X místech X různými způsoby. A to nemluvím o tom, že některé aplikační protokoly multiplexing uspokojivě řešit neumí (např. IMAP, POP3)...
Řešení 1× (Radek Hladik (tazatel))
13.11.2012 18:16 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Ad 3: co si tak vzpomínám z těch pár driverů, co jsem viděl (podotýkám, že mne zajímala spíš filtrace unicastových adres), bývá to tak, že karta umí filtrovat adresy do určitého počtu; pokud se do tohoto počtu vejdete, použije se tato feature, pokud ne, driver automaticky nastaví promiscuous flag. Přičemž u hloupějších karet ten počet může být i 1.
13.11.2012 18:20 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Tak nějak jsem si to představoval, zkusím se podívat, kolik tak ten limit pro různé karty je, protože promiskuitní režim by mohl zbytečně zatěžovat OS... Hlavně pokud každý frame vyvolá přerušení :-)
13.11.2012 18:34 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface

Tak jsem se pro jistotu znovu podíval do e1000 driveru a trochu jsem vás mystifikoval. Tak, jak jsem popisoval, to funguje pro unicast adresy. U multicast je tam ještě hashovací tabulka (bitmapa), konkrétně u e1000 se z MAC adresy vezme 12-bitový hash (konkrétní blok 12 bitů) a nastaví se příslušný bit v bitmapě. Předpokládám, že karta pak přijímá multicasty, jejichž hash cílové adresy má bit nastavený.

V každém případě by ale mělo platit, že ať máte adres kolik chcete, neměl byste přijít o pakety, které máte dostat.

13.11.2012 18:41 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
V tomhle případě nemám strach jen o to, že nedostanu packet/frame, který chci, ale i o to, abych nedostával moc paketů, které nechci :-) V datacentru máme střední tok okolo 300Mbit/s, tedy okolo 20 000 packetů/s (spodní odhad). Pokud by každý vyvolal IRQ... :)
13.11.2012 18:46 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Většina z toho by ale měly být (ethernetové) unicasty.
13.11.2012 19:19 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
To jsem si pak taky uvědomil. Jedině, kdyby to nějak zblblo switch, ale to už je jiný problém (jednou nám to udělalo FreeBSD, driver při offloadingu zapoměl otočit MAC adresy odesílatele a adresáta :-) )
13.11.2012 21:04 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Tak, jak jsem popisoval, to funguje pro unicast adresy.
Jeste bych dodal (ac to je snad vsem zucastnenym jasne), ze tady se mysli unicastove MAC adresy, a pro vsechny zminovane IPv6 adresy se stejne pouzije jedina MAC adresa.
13.11.2012 21:00 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
ad 3) síťová karta má hodně co do činění. Pro každou IPv6 adresu se musí přihlásit do ethernetové multicast skupiny,
No, tohle ma dve mozne reseni:

1) (hloupe) pridelovat ty IPv6 adresy tak, aby se prislusne solicited-node multicast adresy vsechny mapovaly na jednu L2 multicast adresu. V jednom /64 prefixu je spousta mista, takze 24 bitu je mozne zafixovat.

2) (chytre) pridelovat ty 'sluzebni' IPv6 adresy nikoliv na ethernetovy iface (a z rozsahu dane ethernetove site), ale na loopback ci dummy iface (a ze samostatneho rozsahu). To koneckoncu lepe odpovida tomu, ze ty adresy nejsou adresy rozhrani ale sluzeb. Pak je mozne je nezavisle migrovat i mezi vzdalenymi stroji, akorat bude treba to osetrit v routovani.
13.11.2012 22:55 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
V obou případech ale ethernetová karta bude muset poslouchat na všech možných ND multicastech. A pokud ty IP adresy přidělím tak, aby co nejvíce IPv6 unicast adres mělo stejnou MAC multicast ND adresu, tak si moc nepomůžu, protože to celé dělám proto, aby se ty IP adresy mohly migrovat.
13.11.2012 23:53 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Co se tyce postupu 1), tak to preci vubec migraci jednotlivych IPv6 adres nebrani, pouze proste u vsech pouzitych adres budes mit stejnych dolnich 24 bitu, ale jinak je to uplne stejne.

Co se tyce postupu 2), tak sitove rozhrani posloucha na solicited-node multicastech pouze pro adresy pridelene danemu rozhrani. Pokud ty IPv6 adresy pridelis loopbacku, tak ethernetova karta na prislusnych multicastech poslouchat obecne nebude.
14.11.2012 01:09 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Rozumím tomu druhému postupu tak, že ty adresy budou na loopbacku a někde na routeru bude pro každou IP adresu routa směrovaná na linkspecific IP síťovky, která je v tom stroji, kde ta IP zrovna je na loopbacku? To mi připadá výrazně složitější co se správy týče....
14.11.2012 01:37 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Ano. Spravu lze plne automatizovat pomoci routovaciho demona (treba BIRD). Snadno pak lze delat treba automaticky failover, load balancing ci migrovat sluzbu kamkoliv v ramci vlastni site.
14.11.2012 02:22 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
To už je další vrstva, která sice přináší zajímavé věci navrch, ale zároveň potenciální problémy. Tím neříkám, že se mi to nelíbí, ale je to už dost posunuté jinam, než jsem si původně představoval... Každopádně se nad tím zamyslím...
pavlix avatar 14.11.2012 02:29 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Je to mnohem flexibilnější, už kvůli routingu mezi různými lokalitami a technologiemi.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
14.11.2012 02:51 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Na druhou stranu, budu muset dělat routy /128 takže každý (kdo nebude dostatečně "daleko") bude muset mít několik tisíc routovacích pravidel versus ethernet, kde se to bude dělat v HW vrstvě se složitostí O(1) a v kernelu neighbor table (taky předpokládám O(1)). Navíc stroje, co mezi sebou nebudou komunikovat nebudou muset mít záznam o sousedovi, zatímco routovací pravidlo jo. A co se týče více lokalit, tak tam si stejně moc nepomůžu, protože pokud nebudu mít pod kontrolou routování na dostatečné úrovni, tak se zbláznim*. A neethernetové technologie taky úplně pravděpodobné nejsou...

*) buď budou mít lokality jen trochu rozdílný prefix (třeba /56) nebo bych musel ty svoje malinký routy distribuovat výrazně mimo mojí síť.
pavlix avatar 14.11.2012 10:33 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Na druhou stranu, budu muset dělat routy /128 takže každý (kdo nebude dostatečně "daleko") bude muset mít několik tisíc routovacích pravidel versus ethernet, kde se to bude dělat v HW vrstvě se složitostí O(1) a v kernelu neighbor table (taky předpokládám O(1))
Tak tohle tvrzení bych potřeboval nějak podložit. Že by směrovací tabulka byla by definition zpracovávána méně efektivně než neighbor cache. Nejsem hardwarář, ale třeba na úrovni té sítě je to přesně naopak

Jak se budou předávat informace o směrování nastavím na routerech a nemusím ladit parametry na každém (i virtuálním) stroji. Můžu agregovat adresy a zase z nich separovat výjimky. Vtip je v tom, že třeba na virtuálech ty routy nebudu udržovat vůbec. Když to nebude dobře chodit, tak můžu fyzickým strojům předřadit nějaký slušný hardware (L3 switch s podporou OSPF).

Já neříkám, že je řešení na L2 vrstvě špatné a dokonce ani že je horší… ale obě mají značně odlišné vlastnosti a hodí se asi na různé věci.
A co se týče více lokalit, tak tam si stejně moc nepomůžu, protože pokud nebudu mít pod kontrolou routování na dostatečné úrovni, tak se zbláznim*.
Já bych se spíš zbláznil, kdybych mezi lokalitami tuneloval ethernet o řádově tisících až desetitisících individuálních adres. Nedej bože, aby tam byl ještě záložní tunel mezi jinými kusy hardware.

Takže i v případě celých lokalit propojených na L2, bych volil OSPF a routing.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
14.11.2012 11:17 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Tak tohle tvrzení bych potřeboval nějak podložit. Že by směrovací tabulka byla by definition zpracovávána méně efektivně než neighbor cache. Nejsem hardwarář, ale třeba na úrovni té sítě je to přesně naopak
To vyplývá ze selského rozumu. Routing table má složitější pravidla, takže se prochází docela hodně a až pak se cachuje to vlastní routing decision. Navíc v té routing table budou předem všechny routy, zatímco do neighbor table se budou dostávat jen stroje, se kterými se reálně komunikuje.

A to, že ethernet směrování/forwarding je rychlejší, protože se dělá v HW vrtsvě switche snad není potřeba rozvádět.
Jak se budou předávat informace o směrování nastavím na routerech a nemusím ladit parametry na každém (i virtuálním) stroji.
Výměny informací se bude muset účastnit každý, kdo bude mít nějaké ty adresy na svém loopbacku. Agregace by v principu moc účinná být neměla, protože jde právě o to mít možnost každou jednu adresu vzít a odsunout, takže časem by bylo vyjímek nezanedbatelné množství...
Já bych se spíš zbláznil, kdybych mezi lokalitami tuneloval ethernet o řádově tisících až desetitisících individuálních adres. Nedej bože, aby tam byl ještě záložní tunel mezi jinými kusy hardware.
Ale vždyť já o ničem takovém nemluvím. Stěhování strojů mezi lokalitami je tak "složitá" věc, že odůvodní změnu DNS. Prostě celé co řeším je, mít v rámci jedné lokality, dokonce i jen jednoho eth segmentu pro každou instanci služby předem vlastní IP, tak abych minimalizoval zásahy do DNS, když už mám možnost mít tolik adres....

Dokonce ani neřeším, jestli stroje budou virtuální nebo reálné, to je na této úrovni irelevatní.

Ale když už jsme u těch zajiímavých řešení problematiky více lokalit, virtualizace ethernetu je taky poměrně zajímavá věc, ale to jen tak na okraj...
15.11.2012 07:27 tomfi
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Jenom upřesním... většina moderních implementací předpočítá "routing decision", pak se vyhodnocuje buď v TCAM nebo pomocí trie. Pokud na to máte HW, může se tedy i routing vyhodnocovat v HW (je to sice dražší řešení než switching, ale jde to). Route caching je spíše vyjímka

k tunelování ethernetu... nechám se poučit... to už VMware podporuje ty zupa vlastnosti jako např. vmotion i přes IP síť? Nebo se toho moc nezměnilo a pořád ty "šílené" banky tunelují ethernet mezi dvěma zálohovanými datovými centry.
pavlix avatar 15.11.2012 07:46 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
To vyplývá ze selského rozumu.
Právě.
Navíc v té routing table budou předem všechny routy, zatímco do neighbor table se budou dostávat jen stroje, se kterými se reálně komunikuje.
Tak trochu jsem předpokládal, že ty služby budou převážně živé. Takže například router, který sloužý jako výchozí brána, by musel aktivně komunikovat se všemi.
A to, že ethernet směrování/forwarding je rychlejší, protože se dělá v HW vrtsvě switche snad není potřeba rozvádět.
Uznávám, že určitý rozdíl v ceně tam bude :).
Výměny informací se bude muset účastnit každý, kdo bude mít nějaké ty adresy na svém loopbacku.
s/musí/může/
Ale vždyť já o ničem takovém nemluvím. Stěhování strojů mezi lokalitami je tak "složitá" věc, že odůvodní změnu DNS.
Už se to stalo součástí kontextu. V rámci jedné lokality se většina zajímavých vlastností řešení s OSPF neuplatní. Pokud by se vzal pouze případ fyzických serverů a jednoho jediného routeru, tak se nejspíš OSPF neuplatní vůbec.

On každý z nás kromě faktů vychází rovněž i z praxe, která může pro každého vypadat trochu odlišně.
Dokonce ani neřeším, jestli stroje budou virtuální nebo reálné, to je na této úrovni irelevatní.
Má to velký vliv na potřeby škálování a taky na odpovědnost za routing. U virtuálních strojů velkou část odpovědnosti přebírá hostitel, zatímco u fyzických to bude na separátním routeru.

Ten rozdíl je natolik podstatný, že ho nemůžu ignorovat.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.11.2012 07:13 tomfi
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Huh... Routovací démon jako nástroj pro "automatizaci správy" to umí ten ptáček koukám víc než quagga, a tím nemyslím počet implementovaných směrovacích protokolů ;). No k tématu

Myslím že toto řešení, jak již někdo zmiňoval je spíše nešťastné.

1. další služba na každém serveru a na zařízeních mezi servery.

2. v případě velké L2 (což datová centra většinou jsou) bude velká neighbor table v ospf a související problémy (hello paket s řádově stovkami neighbor).

3. routovací tabulka s /128 adresami (s nemožností agregace adres protože přece "migrace jednotlivých adres kamkoliv v rámci vlastní sítě") ... to jste někde implementoval? v datovém centru? Všiml jste si té takové "mírné" degradace výkonu routerů? Nebo je možné, že znáte router který se s tím popere, zkuste prozradit který to je :)

4. musí se řešit nejen aby fungoval směrovací protokol, ale aby bylo jeho nastavení dobře synchronizováno s věcmi jako jsou privátní VLAN.

Ono by toho bylo asi i více... ale už podle těch 4 věcí je to s praktičností na štíru.
pavlix avatar 15.11.2012 07:24 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Huh... Routovací démon jako nástroj pro "automatizaci správy" to umí ten ptáček koukám víc než quagga, a tím nemyslím počet implementovaných směrovacích protokolů ;). No k tématu
Netřeba se chytat každého slovíčka. Směrovací démon skutečně odlehčí administrátorům od správy směrovacích tabulek.
1. další služba na každém serveru a na zařízeních mezi servery.
Která může plnit svůj účel lépe než obrovská ARP cache s přímým dotazováním.
2. v případě velké L2 (což datová centra většinou jsou) bude velká neighbor table v ospf a související problémy (hello paket s řádově stovkami neighbor).
Celý smysl nasazení OSPF je v tomto případě omezit velikost spravovaných L2 segmentů. Snažíš se kombinovat nevýhody obojího.
3. routovací tabulka s /128 adresami (s nemožností agregace adres protože přece "migrace jednotlivých adres kamkoliv v rámci vlastní sítě") ... to jste někde implementoval? v datovém centru? Všiml jste si té takové "mírné" degradace výkonu routerů? Nebo je možné, že znáte router který se s tím popere, zkuste prozradit který to je :)
Jako kdyby ta ARP cache agregovaná byla :).
4. musí se řešit nejen aby fungoval směrovací protokol, ale aby bylo jeho nastavení dobře synchronizováno s věcmi jako jsou privátní VLAN.
To je snad samozřejmost.
Ono by toho bylo asi i více... ale už podle těch 4 věcí je to s praktičností na štíru.
Ani bych neřekl.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.11.2012 09:26 tomfi
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface

Netřeba se chytat každého slovíčka. Směrovací démon skutečně odlehčí administrátorům od správy směrovacích tabulek.

Ano, pro zjednodušení směrovací protokoly mimo jiné jsou... snížení náročnosti na správu a automatická reakce na změny v síti... ale "automatizace" je trochu silné slovo (o tom se mluví v souvislosti třeba s SDN) ... to už bychom rovnou mohli říct, že Switch má nástroj pro "automaticaci správy" a tím je tabulka mac adres.
Která může plnit svůj účel lépe než obrovská ARP cache s přímým dotazováním.
jasně nebudeme chytat za slovo a v tichosti pomineme, že ARP cache u IPv6 není. ARP cache má jednu výhodu... schválně je rozdíl mezi vyhledáváním v tabulce (CAM např.) a v trie? Je rozdíl mezi aktualizací ARP cache a aktualizací trie?

Nicméně jsem schopen připustit, že existuje nějaká hraniční hodnota počtu IP adres na jednom zařízení kdy už se vyplatí routing oproti přímé komunikaci v rámci subnetu.

Celý smysl nasazení OSPF je v tomto případě omezit velikost spravovaných L2 segmentů. Snažíš se kombinovat nevýhody obojího.
Bohužel obrovské L2 domény jsou realitou datových center a serveroven a důvodem není nedostatek IPv4 adres. Vývoj v této oblasti (v oblasti L2) jenom naznačuje, že se toho jen tak nezbavíme. Schválně akademická otázečka, kolik je routerů a kolik switchů v serverovnách, čemu které z těch zařízení slouží a proč tomu tak je? Prostě kdyby se dalo L2 vyměnit za L3 s OSPF směrováním jenom mávnutím BIRDu tak tu nemáme věci jako TRILL. Změnit L2 doménu na L3 síť není jenom o nalezení adresy koncového zařízení... z nezmíněných věcí - co takhle multicast.

Jako kdyby ta ARP cache agregovaná byla :).

Pochopil jsem správně že srovnáváte agregaci z důvodu velikosti ARP tabulky s agregací z důvodu zefektivnění směrování? Nebo má ARP cache nějaké výkonnostní problémy, které mi unikají?
To je snad samozřejmost.
To jako z důvodu zjednodušení administrace se přidá jiná administrace minimálně v poměru 1:1?
pavlix avatar 15.11.2012 10:01 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Ano, pro zjednodušení směrovací protokoly mimo jiné jsou... snížení náročnosti na správu a automatická reakce na změny v síti... ale "automatizace" je trochu silné slovo (o tom se mluví v souvislosti třeba s SDN) ... to už bychom rovnou mohli říct, že Switch má nástroj pro "automaticaci správy" a tím je tabulka mac adres.
Když se nutně vyžíváš v chytání za slovo, tak tabulka MAC adres je pouhá datová struktura.
jasně nebudeme chytat za slovo a v tichosti pomineme, že ARP cache u IPv6 není.
Detail.
Nicméně jsem schopen připustit, že existuje nějaká hraniční hodnota počtu IP adres na jednom zařízení kdy už se vyplatí routing oproti přímé komunikaci v rámci subnetu.
O vysokých počtech je i původní dotaz.
Bohužel obrovské L2 domény jsou realitou datových center a serveroven a důvodem není nedostatek IPv4 adres.
Je to levnější, alespoň v tuto chvíli.
Změnit L2 doménu na L3 síť není jenom o nalezení adresy koncového zařízení...
Tady se nebavíme o změně L2 na L3, ale o dvou možných návrzích sítě.
z nezmíněných věcí - co takhle multicast.
A co takhle anglická královna?
Pochopil jsem správně že srovnáváte agregaci z důvodu velikosti ARP tabulky s agregací z důvodu zefektivnění směrování? Nebo má ARP cache nějaké výkonnostní problémy, které mi unikají?
Poukazuju na to, že mezi vyhledáním čísla v tabulce a vyhledáním čísla v tabulce není až takový rozdíl. Jasně, směrovací tabulka má délku prefixu, ale pokud by single-address směrovací záznamy získaly velkou oblibu, nebyl by problém jejich vyhledávání optimalizovat stejným způsobem.
To jako z důvodu zjednodušení administrace se přidá jiná administrace minimálně v poměru 1:1?
Ne.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.11.2012 12:00 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
2. v případě velké L2 (což datová centra většinou jsou) bude velká neighbor table v ospf a související problémy (hello paket s řádově stovkami neighbor).

Tohle lze resit mnoha zpusoby. Tenhle use case je tak trivialni, ze OSPF je overkill, RIP by uplne stacil. V pripade pouziti OSPF je mozne pouzit pro dane rozhrani ptmp rezim namisto broadcast rezimu, tim odpadne prevazna vetsina problemu spojenych s mnoho neighbors na jedne L2 siti.
3. routovací tabulka s /128 adresami

Netusim, jak jsou na tom hardwarove routery s podporou /128 adres, je mozne, ze to maji implementacne odflaknute. Pro 'stredni zatez' (cca Gbps) je mozne bez potizi pouzit linuxovy sw router, kteremu je to jedno (protoze namisto TCAM pouzivaji route cache).
4. musí se řešit nejen aby fungoval směrovací protokol, ale aby bylo jeho nastavení dobře synchronizováno s věcmi jako jsou privátní VLAN.

Pokud se bavime o tomto jednoduchem pripadu, kdy mame jedinou L2 sit, tak to je vcelku irelevantni.
pavlix avatar 14.11.2012 01:56 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Jedna z výhod této výhody by měla být to, že je možné každé službě přiřadit jednu IP adresu, kterou bude mít "na dosmrti".
To je zajímavá teorie. Ale jo, adresu z rozsahu může mít napořád. Jinak nevidím důvod sypat hromadu adres na vnější rozhraní, ale když už tak opravdu na loopback a na eth rozhraní posadit toho BIRDa, jak píše ondra.

Stejně tam ethernet jako mezivrstva bude, tak proč to zbytečně trápit.
Správa IP adres - na takové množství už asi obyčejné ip addr nebude moc pohodlné, ideální by bylo, kdyby se daly všecky tyto adresy nějak označit - něco jako "secondary", ale jen ve smyslu administrace
Zbytečné. Příkaz ip umí vše, co je potřeba, tedy přidat adresu, smazat adresu či zahodit všechny. Shellovský či třeba Pythonovský for cyklus zařídí zbytek.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
14.11.2012 02:34 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
To je zajímavá teorie. Ale jo, adresu z rozsahu může mít napořád. Jinak nevidím důvod sypat hromadu adres na vnější rozhraní, ale když už tak opravdu na loopback a na eth rozhraní posadit toho BIRDa, jak píše ondra.

Stejně tam ethernet jako mezivrstva bude, tak proč to zbytečně trápit.
jak jsem psal, především mi jde o migraci v rámci různých strojů, klasický životní cyklus domén a doméniček... Na druhou stranu nevidím důvod, proč by tohle mělo být nějaké "trápení", pokud něco víceméně vyžaduje, aby síť měla minimálně 2^64 adres, tak mít na interfacu 2^10 adres mi nepřipadá zas tak divné... A z hlediska sítě je to přašť jako uhoď, jen ten interface může být trochu náročnější na provoz... A i pokud se s nějakou rozumnou síťovkou dostanu do stavu, že interface bude poslouchat všechny ethernet multicasty, tak to nebude nic tak extra šíleného...
Zbytečné. Příkaz ip umí vše, co je potřeba, tedy přidat adresu, smazat adresu či zahodit všechny. Shellovský či třeba Pythonovský for cyklus zařídí zbytek.
Jestli je to nebo není zbytečné, to si posuzovat netroufám. Ale to, že to ip všecko zvládne, to je mi jasné. Stejně tak je mi jasné, že jako takové to moc přehledné nebude, takže bude třeba nějaký ten skriptík. A pokud by něco obdobného už bylo k dispozici, proč to dělat znovu, že? Nejde mi ani tak o nahozeni/shozeni jako o nějakou práci s tím (výpis, kontrola, atd...) Ale to je opravdu minimální problém něco na to sesmolit...
pavlix avatar 14.11.2012 10:42 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
pokud něco víceméně vyžaduje, aby síť měla minimálně 2^64 adres
Příliš bujná fantazie. Nikdo nevyžaduje, aby měla síť minimálně 2^64 adres, ale aby mohly být adresy odvozeny od EUI. Horní mez délky prefixu je důsledkem požadavku na zapouzdření 64-bitového EUI identifikátoru.
A i pokud se s nějakou rozumnou síťovkou dostanu do stavu, že interface bude poslouchat všechny ethernet multicasty, tak to nebude nic tak extra šíleného...
Čistě mezi námi, pokud na fyzickém stroji provozuješ bridge a nefiltruješ multicastové skupiny, tak stejně použiješ promiskuitní režim a vše si zpracuješ na procesoru.
Nejde mi ani tak o nahozeni/shozeni jako o nějakou práci s tím (výpis, kontrola, atd...) Ale to je opravdu minimální problém něco na to sesmolit...
Pak už poslouží Netlink a knihovny nad ním. Pracuje se s tím docela hezky. A do budoucna D-Busový interface NetworkManageru.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
14.11.2012 11:00 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
pokud něco víceméně vyžaduje, aby síť měla minimálně 2^64 adres
Příliš bujná fantazie. Nikdo nevyžaduje, aby měla síť minimálně 2^64 adres, ale aby mohly být adresy odvozeny od EUI. Horní mez délky prefixu je důsledkem požadavku na zapouzdření 64-bitového EUI identifikátoru.
Jak je to dlouho, co to RFC je obsolete, už skoro rok? Ostatně těch diskuzí, zda používat /64 i tam, kde se EUI používat nebude bylo nespočetně, to nemá smsyl opakovat :-)
Čistě mezi námi, pokud na fyzickém stroji provozuješ bridge
Ale já nechci používat bridge (pokud to nebude potřeba), prostě eth0 a na něm tunu adres... Samozřejmě, pokud to ulehčí to, že si udělám bridge a do něj dam něco virtuálního, tak proč ne, ale podmínka to neni. Spíš naopak, dělal bych to, jen kdyby to za to stálo....
pavlix avatar 14.11.2012 11:28 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: IPv6 a hodně adres na interface
Jak je to dlouho, co to RFC je obsolete, už skoro rok?
Nemám tušení, které z mnoha RFC máš namysli, ani jakou to má mít souvislost s tématem.
Ostatně těch diskuzí, zda používat /64 i tam, kde se EUI používat nebude bylo nespočetně, to nemá smsyl opakovat :-)
Rovněž nevidím souvislost s tím, jak vzniklo pravidlo, že unicastové adresy budou dělené v půlce.
Ale já nechci používat bridge (pokud to nebude potřeba), prostě eth0 a na něm tunu adres... Samozřejmě, pokud to ulehčí to, že si udělám bridge a do něj dam něco virtuálního, tak proč ne, ale podmínka to neni. Spíš naopak, dělal bych to, jen kdyby to za to stálo....
Proto taky ta věta začíná slovem pokud.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.