Dotaz: Router s jedním ethernetem a vlany

[mlha]

Ahoj. Stavím domácí router z desky alix 1c - AMD geode 500MHz, 256MB RAM, 100M ethernet. Problém je, že deska má jen jeden ethernetový port. Takže mám 2 možnosti: použít tagované vlany (switch to podporuje) nebo přidat novou USB síťovku. Provoz bude maximálně 12Mbit/s down / 12Mbit/s up. Je hodně velká blbost řešit to pomocí VLAN? A fungovalo by to tak vůbec? Moje představa by byla, že na switchi přidám paketům z internetu tag, oroutuju a pošlu na virtuální síťovku s jiným tagem, switch si to pak přebere. Nebo bych mohl ještě dokoupit další síťovku přes USB (PCI ta deska nemá). Jak byste to řešily vy? Já si hlavně nejsem jistý, zdali ta vlana takhle může na linuxu fungovat a zdali by to ta karta stíhala (nicméně teoreticky by takto měla dávat max 50M FD).

Odpovědi

[vagojan]

svého času jsem takto řešil test firewallu v práci. Z centrálního catalystu jsem si poslal vlany trunkem do notebooku s gbit síťovkou. Zvládlo to firmu s 300 PC a 100Mbit uplinkem. Produkční řešení jsem ale postavil dedikovaném serveru s netagovanou 4 portovou síťovkou + interními síťovkami serveru.

Rozhodně to fungovat bude, jen vzhledem k železu z mého hlediska pomalu.

[RYU.cz]

a co ip aliasing?

Já teď řeším router kde bude 2xWLan a 1xLan, ale má pouze 2 síťovky. Na tom Wlan to chci řešit ip aliasingem, vlany nemám jak zajistit.

[Michal Kubeček]

a co ip aliasing?

Ten fungoval naposledy v jádře 2.0. :-)

[RYU.cz]

Funguje naprosto bez problémů na poslední verzi Debianu.

root@gw:~# uname -a
Linux gw.example.com 2.6.32-5-686 #1 SMP Mon Mar 26 05:20:33 UTC 2012 i686 GNU/Linux

root@gw:~# ifconfig
eth0      Link encap:Ethernet  HWadr 08:00:27:7a:88:f0  
          inet adr:192.0.0.10  Všesměr:192.0.0.255 Maska:255.255.255.0
          inet6-adr: fe80::a00:27ff:fe7a:88f0/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:0 (0.0 B)  TX bytes:398 (398.0 B)

eth1      Link encap:Ethernet  HWadr 08:00:27:6f:60:9e  
          inet adr:10.0.0.15  Všesměr:10.0.0.255 Maska:255.255.255.0
          inet6-adr: fe80::a00:27ff:fe6f:609e/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:230 errors:0 dropped:0 overruns:0 frame:0
          TX packets:207 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:25843 (25.2 KiB)  TX bytes:20726 (20.2 KiB)

eth1:0    Link encap:Ethernet  HWadr 08:00:27:6f:60:9e  
          inet adr:10.0.0.14  Všesměr:10.0.0.255 Maska:255.255.255.0
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1

eth1:1    Link encap:Ethernet  HWadr 08:00:27:6f:60:9e  
          inet adr:10.0.0.13  Všesměr:10.0.0.255 Maska:255.255.255.0
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1

eth1:2    Link encap:Ethernet  HWadr 08:00:27:6f:60:9e  
          inet adr:10.0.0.12  Všesměr:10.0.0.255 Maska:255.255.255.0
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1

lo        Link encap:Místní smyčka  
          inet adr:127.0.0.1 Maska:255.0.0.0
          inet6-adr: ::1/128 Rozsah:Počítač
          AKTIVOVÁNO SMYČKA BĚŽÍ  MTU:16436  Metrika:1
          RX packets:71 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:0 
          RX bytes:5860 (5.7 KiB)  TX bytes:5860 (5.7 KiB)

[Michal Kubeček]

Ne, to není IP aliasing. IP aliasing fungoval naposledy v řadě 2.0, od řady 2.2 se rozhraní přiřazuje více adres přirozeným způsobem a žádný IP aliasing není potřeba. To, co vám ukazuje obsolentní příkaz ifconfig, je fikce, která nemá se skutečným nastavením sítě moc společného.

[TomM]

Fungovat to bude, netřeba se bát. Rychlost bude "co zvládne železo", uvedeným požadavkům by to mělo vyhovět v pohodě.
Nicméně použil bych radši alix-2 (nejlíp se třemi eth). Nejvytíženější port (uplink) pak může být bokem. Stroj nebude obsahovat blbosti (VGA, kbd, zvuk a další).
Na alix-1 pozor, pokud budeš chtít zapnout watchdog (geodewdt), potřebuješ poslední betu BIOSu a s tou jsem měl problémy. Po zavedení modulu ohci mi ohluchnul eth0 (stalo se to na těžko přístupném místě, velmi mrzuté).
Pokud ale budeš mít alix-1 se starým BIOSem (před alixbio7), připoj monitor nebo aspoň zkratovací konektor (popsáno na webu). Ta známá závada s nenabootováním se umí vyskytnout zcela nečekaně po delsím bezproblémovém fungování.

[mlha]

Jo alix 2 by byl lepší, ale alix 1 už nějakou dobu vlastním a používám na všechno možný. Teď to bude router. Watchdog nepoužívám a ani ho k ničemu nepotřebuju. O jaké závadě s nenabootováním je řeč? VGA propojku těch 2 pinů standardně používám a nedávno se mi stalo, že to nenaběhlo, tak jsem to připojil na normální monitor, naběhlo v pohodě, pak jsem tam dal tu propojku a běží to zase dál.

[TomM]

Problémem s nenabootováním jsem myslel právě tu potřebu vrazit tam místo monitoru konektor s uzemněným SDA. Mám jeden alix-1, co v pohodě chodil cca rok a půl, až si jednou vzpomněl, že je vlastně vadnej a nenabootoval. Dostal "zkratkonektor" a je hodnej dodnes.

[SPM]

Fungovat to bude určitě líp, než USB síťovka :)

[mlha]

Jaké jsou problémy s USB síťovkami?

[Michal Kubeček]

USB (<= 2.0) se moc nehodí pro tento typ použití. Jednak funguje jako half duplex, jednak jsou tam dost obtížně kontrolovatelné latence. Ve výsledku je dost velký rozdíl mezi teoretickou propustností a tím, kolik opravdu reálně protlačíte, zvlášť pokud je na sběrnici víc zařízení.

[SPM]

Další věc je, že snad všechny USB síťovky jsou jenom redukce na RJ45 port. Narozdíl od normálních síťovek neřeší sami vůbec nic a všechno to oddře CPU.

[Michal Kubeček]

Výkonově to problém nebude, spíš bych měl obavy z bezpečnosti takového řešení, asi půjde hlavně o to, nakolik se dá důvěřovat tomu switchi.

[mlha]

Je to TP-LINK TL-SG2109WEB, prakticky skoro nic neumí a VLANy se tam konfigurují docela zajímavým mechanismem... Za tu cenu to asi nebude kdovíjak bezpečné řešení, ale na domácí použití vyhovuje.

[pavlix]

Mají ty obavy o bezpečnost nějakou konkrétní podobu?

[BigWrigley]

Tagovani pomoci 802.1q funguje na linuxu dobre, pouzivame nekolik let "na produkci" na bondovanych interfacech. Na prikladu nize (redhat) je trunk na interface bond0 s ip adresou v native vlan a pak interfacy ve vlanach 265 a 266.

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue
    link/ether 00:24:81:a9:84:5a brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.208/26 brd 172.19.0.255 scope global bond0
    inet6 fe80::224:81ff:fea9:845a/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:24:81:a9:84:5a brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:24:81:a9:84:5a brd ff:ff:ff:ff:ff:ff
5: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:1f:29:60:af:11 brd ff:ff:ff:ff:ff:ff
6: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:1f:29:60:af:10 brd ff:ff:ff:ff:ff:ff
7: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:1f:29:60:af:13 brd ff:ff:ff:ff:ff:ff
8: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:1f:29:60:af:12 brd ff:ff:ff:ff:ff:ff
9: bond0.265: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue
    link/ether 00:24:81:a9:84:5a brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.16/25 brd 172.19.0.127 scope global bond0.265
    inet 172.19.0.48/25 brd 172.19.0.127 scope global secondary bond0.265:A-inf
    inet 172.19.0.32/25 brd 172.19.0.127 scope global secondary bond0.265:A-rad
    inet 172.19.0.61/25 brd 172.19.0.127 scope global secondary bond0.265:A-lda
    inet6 fe80::224:81ff:fea9:845a/64 scope link 
       valid_lft forever preferred_lft forever
10: bond0.266: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue
    link/ether 00:24:81:a9:84:5a brd ff:ff:ff:ff:ff:ff
    inet 172.19.1.15/25 brd 172.19.1.127 scope global bond0.266
    inet6 fe80::224:81ff:fea9:845a/64 scope link 
       valid_lft forever preferred_lft forever

[ivan]

Tagovani se bezne pouziva i na routerech od Cisca. Nikdo nebude pridavat/dokupovat fyzicky interface kvuli kazdemu novemu segmentu v siti. To se dela az kdyz je to opravdu potreba. Pokud mas dve sitovky, tak stejne sdilis pasmo na PCI smernici, CPU a pamet. Rozhodne neni pravda , ze se dvema sitovkama dokazes routovat 2x vice trafficu.

USB sitovka je urcite horsi reseni. Ma vetsi natence, USB samo o sobe vytezuje CPU.

[linuxik]

Tohle platilo nekdy pred 10 lety. Dnes pokud pouzijes kvalitni sitovou kartu do PCI-Express s MSI-X a spravny serverovy chipset neni problem na 4 sitovych kartach spojenych pres LACP routovat 4Gb/s.

[SPM]

Tak to bych zas až tolik netvrdil. Router od cisca (nebo adekvátní) co uroutuje 4Gb/s bude drahej jak prase. A routovat to na PCčku; tomu bych taky moc nevěřil... nicméně to bude režie samotnýho routování, ne síťovky...

[linuxik]

5 let stary test. Na dnesnim HW se necha routovat pres milion packetu za vterinu a pokud tam nejsou tisice pravidel a slozity QoS, procesor se ani nezapoti.

[sigma]

Od dob Intel P4 s pomalou FSB už čas pokročil, a IO výkon PC platformy je podstatně jinde. Na Intel Sandy Bridge s PCIe ethernety připojenými na CPU PCIe linky, není problém routovat 10 Gb/s+. Pokud se bavíme o čistém routování, vč. full BGP tabulky. Na jednotky Gb/s to lidé bez problémů používají, není čemu nevěřit.

[sigma]

A samozřejmě, rozhodující je spíš počet paketů za sekundu, než bandwidth. Bavíme se o běžném internetovém provozu ISP s tímto objemem konektivity.

[SPM]

No, já znám spíš lidi, co běžně na routování používají k tomu určené boxy :) a ty v těch vyšších konfiguracích obvykle mívají HW podporu / karty... routovat gigabity na zbastleném PCčku mi přijde lehce ujeté... pokud to teda člověk nemá doma na to, aby si vyzkoušel, že to jde.

[linuxik]

Ja zase znam dost ISP, kterym se nechce davat statisice za HW routery a licence, kdyz to same zvladne server od HP nebo IBM za 40k a jeden zkuseny admin

[Ondrej 'SanTiago' Zajicek]

No, me zas prijde ujete pouzivat predrazene boxy s proprietarnim software, kdyz to same se srovnatelnym vykonem jde udelat radove levneji a s free software, nehlede na mnohem snazsi dostupnost nahradnich dilu.

Samozrejme nemluvim o hi-end routerech s hadrwarovou akceleraci routingu, ale o mid-range routerech, ktere i u Cisca funguji AFAIK vicemene stejne jako PC router s Linuxem.

Viz treba tyhle testy: Vyatta Delivers 10X Price/Performance Advantage Over Cisco 7200

[SPM]

Naproti tomu i na těch SW boxech, když je člověk kupuje, tak má zaručené chování (tedy to co to vážně uroutuje a ne podle toho, jak se zrovna vyspal vývojář kernelu), prostředí je nějakým způsobem konzistentní a lze na to získat support. Pokud se někdo bez toho obejde, tak pak je pro něj PC lepší volba; nicméně u routování gigabitů mi přijde, že se už šetří někde, kde by nemělo.

[linuxik]

To ze koupim nejake hotove reseni a bude fungovat lepe a rychleji nez opensouce je takova "urban legend", ktera nema s realitou nic spolecneho. Jedine co maji takova reseni lepsi je snadnejsi konfigurace a casto take vytvareni ruzny reportu a trendu. Opravdu si myslis ze v SW boxech je neco jineho nez linux pripadne bsd? Zadna firma nema dost prostredku/casu na vyvinuti sveho networking stacku. Navic zrovna networking stack je v linux jadre jednou z nejsledovanejsich oblasti a jeho vykon se s kazdou verzi zlepsuje.

[kyytaM]

Nj. Cisco SAN-OS, NX-OS aj IOS-XE je Linux. :) IOS-XR je myslim QNX. Ale napr. Cisco appliance ako IPS 4270, ACS, MARS, GSS...su Linuxy vsetko. A tusim aj Cisco ACE. :D Juniper firewally su pre zmenu na FreeBSD postavene. :)

[Ivan]

Juniper bezi na FreeBSD a network stack maji pry vlastni, HW akcelerovany. Content switche od Cisca bezi na QNX - puvodne je vyvijela jina firma, kterou Cisco koupilo. PIX je nespis neco nad *BSD - alespon to tak vypada kdyz to bootuje do modu kdy se zadava licencni cislo. IOS je vlastni.

[Ivan]

Teda kecam, ACE a CSS bezi(bezely) na VxWorks.

[linuxik]

Rec byla o SW boxech(Astaro Internet Security, Vyatta a pod), ne o resenich stojicich pres mega.

[SPM]

Juniper má i SW boxy.

[vencour]

Junipery začínají už na lidovějších cenách.

A k Ciscu ... podle tohodle je ASA stavěná na linuxu.

[SPM]

Ono nejde ani tak o to, co v tom jede. Když si to budeš řešit sám a upgradneš si kernel a výkon najednou bude o 50% horší, tak je to akorát tvuj problém. Můžeš ledatak vyplnit bug request a někdy se dočkáš opravy. A týká se to všeho, co ten router potřebuje, takže celkem dost věcí na to, které se budou moc rozbít. U toho boxu to packagování řeší dodavatel; takže jednak něco vyloženě rozbitého se k tobě ani nedostane a jednak ve chvíli, kdy máš box, kterej má v papírech traffic, kterej musí uroutovat a nedává ho, tak máš koho tím mlátit po hlavě. Máš toho míň co řešit sám, ale zase je to dražší.

[Michal Kubeček]

Takže když budu mít performance regression na linuxovém routeru, můžu leda tak kontaktovat support a čekat, až to opraví, zatímco u black-box řešení jsem na tom mnohem lépe, protože můžu kontaktovat support a čekat, až to opraví?

[SPM]

No, zatím jsem ještě neviděl nikoho, kdo by dával support na Linuxový server pro použití jako router. Ty jo? :) A jo, u té krabičky máš jasně dány její parametry, co ještě musí dát. Když si nakoupíš libovolné železo co kde splašíš, tak ti těžko na něm bude někdo zaručovat, co to ještě dá.

[Michal Kubeček]

No, zatím jsem ještě neviděl nikoho, kdo by dával support na Linuxový server pro použití jako router. Ty jo? :)

Ano, třeba zrovna ta firma, kde pracuju. :-) Jednou ta funkcionalita je součástí systému, tak se na ni support vztahuje. A 50% peformance regression u routingu je rozhodně něco, co by se řešit muselo.

[SPM]

Pak je otázka co vše se bere jakou součást systému :) routing čistě ano, ale co pak zebra a další... potíž je, že u supportu linuxu jako celku je těch věcí tolik, že se to těžko nějak dá zkoušet dopředu. Teda, pokud někdo na to síťování prodává celý box, tak obvykle před vydáním nové verze sw apod. se někdo bude obtěžovat s tím, aby vyzkoušel jestli to funguje. U obecného PC na to většinou narazí až ten zákazník. Když má support, tak mu to sice v nějaké době vyřeší, ale do té doby má buď nefunkční síť nebo bude downgradovat zpět... chápu, že u nějakých vesnických a menších ISP to bude plně vyhovující řešení. Na druhou stranu pořád síť, kde se routujou běžně Gb/s routujou už mi přijde dost velká na nějaké bastlící řešení.

[kyytaM]

Otazka je, ze preco vobec upgradovat. Co som na vlastne oci videl, "enterprise" spolocnosti aj mensie firmy, vlastni IT ludia, ci outsourcing s velkym menom, tak updatuju len vtedy, ked nieco nejde...(co napr. pri Ciscu byva dost casto :D). Ale ked vsetko pozadovane funguje podla potrieb, nikto sa toho ani nechyti. :)

[Michal Kubeček]

routing čistě ano, ale co pak zebra a další...

Třeba ve SLESu Quagga je a je supportovaná v plném rozsahu.

potíž je, že u supportu linuxu jako celku je těch věcí tolik, že se to těžko nějak dá zkoušet dopředu. Teda, pokud někdo na to síťování prodává celý box, tak obvykle před vydáním nové verze sw apod. se někdo bude obtěžovat s tím, aby vyzkoušel jestli to funguje. U obecného PC na to většinou narazí až ten zákazník. Když má support, tak mu to sice v nějaké době vyřeší, ale do té doby má buď nefunkční síť nebo bude downgradovat zpět...

Jak už zmínil kolega, enterprise zákazníci vesměs upgradují jen velmi neradi a typicky jen tehdy, když k tomu mají hodně vážný důvod. Některé je problém přimět i k tomu, aby instalovali aspoň maintenance updaty. Že by nějaký enterprise zákazník provedl upgrade jen tak naslepo bez důkladných testů, s tím, že se teprve uvidí, jestli to bude fungovat, to moc obvyklé není.

[SPM]

Ono s upgradama úplně stačí, když to PC shoří a veme se náhradní, na kterém už verze stejné nebudou :) nicméně, ty upgrady stejně za čas nutné jsou - ať už kvůli security bugům a podobně. A pak se taky lehce stane, že to běží v síti dostatečně na to, aby kvůli upgradu jednoho balíku bylo nutné updatnout celý systém.

[kyytaM]

Napr. Vyatta k tomu nema daleko. :)

[Michal Kubeček]

prostředí je nějakým způsobem konzistentní a lze na to získat support

A v čem že je konkrétně ten rozdíl oproti linuxovému řešení?

[Ivan]

Je pravda, ze uz je to par let co jsem delal u ISP.

Otazka je, na co uzivatel potrebuje internet. Jestli je to router pro firmu, pro maleho ISP anebo na stahovani porna. Pokud jde o HW routery/switche tak u nich se neudava propustnost v Gb/s. Prenosy dat uvnitr te krabice jsou vice-mene HW akcelerovane a temer nikdy nejsou bottle-neck. Vykon se udava v megapacketech. Nejnarocnejsi cast routovani je samotne rozhodnuti co se ma s danym packetem udelat. Zvlast kdyz je routovaci tabulka hodne velika, plus filtry a ruzny prepisy IP hlavicek.

Tagovani poskytuje velkou flexibilitu pri sprave, protoze neni potreba pri kazde zmene topologie rozebirat nejaky krabice. I kdyby propustnost diky tagovani klesla na polovinu, tak pochybuju ze nekdo v beznym provozu potrebuje routovat 0.5 Gb/s. A kdyz jo, tak at si koupi opravdovej router.

[Ondrej 'SanTiago' Zajicek]

Nejnarocnejsi cast routovani je samotne rozhodnuti co se ma s danym packetem udelat. Zvlast kdyz je routovaci tabulka hodne velika,

Zrovna na Linuxu (v def. konfiguraci) je vcelku jedno, jestli tam mas 10 rout, nebo celou globalni routovaci tabulku (cca 400k rout), nebot se pouziva route cache zalozena na flows, takze se routovaci tabulka zkouma jen u route cache miss. V normalnim pripade se jen vezme signatura paketu, zahashuje se podle ni a pouzije vysledek, takze to je vcelku rychle.

[pavlix]

Čistě mezi náma, prakticky všechny levné routříky fungují přesně jak popisuješ. Procesor má jeden nebo dva integrované ethernety a jeden z nich je napojený na integrovaný VLAN switch. V systému se to pak může nebo nemusí tvářit jako samostatná eth rozhraní, ale fyzicky nejsou.