Piďi-Howto: PC s vícero síťovkami - do bridge

3.1.2016 23:34 | Přečteno: 1460× | Linux

Tento zápisek se snaží ukázat jednoduché řešení nastavení konfigurace PC s Debianem (Wheezy) a s vícero síťovými kartami (integrovanými na desce). Přitom jde o to aby: 1) byla vždy IPv4 konektiva (ať už PC bude zapojeno kteroukoliv ze síťových karet) - IPv6 nechceme; 2) PC musí vždy dostat stejnou lokální IPv4 adresu, ať už je zapojeno přes kterýkoliv port (resp. ať už se eth* rozhraní nadetekují v jakémkoliv pořadí) - přičemž tu adresu dostane přes DHCP; 3) nastavení musí být natvrdo v systému a dostupné všem uživatelům (a nikoliv pomocí NetworkManageru či tak podobně); 3) PC by případně mělo fungovalo jako switch a to se zapnutým STP; 4) nahození rozhraní a získání adresy z DHCP nesmí při bootu zdržovat.

Řešení vypadá asi nějak takto (/etc/network/interfaces na daném PC):

# --- Loopback
auto lo
iface lo inet loopback

# --- Set up interfaces
iface eth1 inet manual
  ethernet-wol g
iface eth0 inet manual
  ethernet-wol g

# --- Ethernet Bridge
auto br0
iface br0 inet dhcp
  bridge_ports eth0 eth1
  bridge_waitport 1
  bridge_maxwait 1
  # !! Not using "bridge_stp on" in order to reduce boot time. Using "post_up" instead !!
  post-up   /sbin/brctl stp br0 yes

Vysvětlení: 1) nejdřív zajistíme, aby na eth[0-1] nešahal nikdo jiný (např. již zmíněný NetworManager [pun intended]). To se zajistí pomocí dvou sekcí iface eth? inet manual. Jako bonus pro každé rozhraní nastavíme možnost buzení přes Wake-On-Lan.

2) obě rozhraní (eth0 + eth1) dáme do bridge - br0. To nám pak bude sloužit jako virtualní ethernetové rozhraní, které si získá svoji adresu přes DHCP a přes které se připojíme do sítě.

3) aby nastavení rozhraní netrvalo věčnost, nastavíme waitport (doba, po kterou se čeká na nahození jednotlivých rozhraní, než jsou přidány do bridge) jakož i maxwait (maximální doba, po kterou se čeká, než bude bridge v použitelném stavu) na jednu sekundu. Zvláště MAXWAIT je potvora, anžto je běžně nastavena na 32 sekund, po které se čeká, až bude bridge ve "stabilním stavu".

4) ovšem těchto 32 sekund vypadá jako dlouhá doba, nicméně je potřeba v případě, kdy je bridge v režimu STP (což chceme, protože máme různorodou síť a různé způsoby propojení a je potřeba, aby nám tam nevznikaly smyčky a pododně). Což je ale trochu problém, protože pokud nejprve nahodíme bridge a zapneme STP, pak je docela nutností nejprve dlouho čekat na ustálení STP. Pokud tak neučiníme, tak DHCP nefunguje a trvá nějakou chvíli, než to celé začne fungovat.

Moje řešení je v tuto chvíli takové, že nejdřív nahodím rozhraní, ale nezapnu STP - a doufám, že se síť za tu chviličku nezblázní - nechám PC, ať si získá adresu z DHCP - a teprve potom nahodím STP pomocí post-up.

Dodatek: To aby PC dostalo vždy stejnou řeším přes ISC-dhcpd asi nějak takto:

host pc1-eth0 { option host-name pc1; hardware ethernet xx:yy:zz:qq:1c:23; fixed-address 192.168.123.123; }
host pc1-eth1 { option host-name pc1; hardware ethernet xx:yy:zz:qq:0f:12; fixed-address 192.168.123.123; }

       

Komentáře

[Max]

STP snad ani nemá cenu provozovat. Dnes už minimálně RSTP.
Zdar Max

[trekker.dk]

RSTP je v kernelu?

[Max]

Právě, že není, stejně jako tam není MSTP. Osobně to nechápu :-/.
Každopádně je to v userspace a mělo by to být i tak rychlejší, jak obyčejné STP.
Zdar Max

[Petr Tomášek]

Hm, tak dokud mi RSTP/MSTP nebudou podporovat switche, tak je to stejně k ničemu, nebo ne?

[Max]

To se divím, RSTP jsem měl na 15let starých switchích ...
MSTP je na tom hůře, ani Mikrotik ho nepodporuje :(
Zdar Max

[trekker.dk]

Není RSTP náhodou nějaké rozšíření od Cisca? Možná se to nikomu nechce dávat to do jádra, aby nebyly nějaké patentově-licenční problémy. Otázka je taky, jak moc se vlastně používá to STP

[Max]

Ne, RSTP je standard 802.1w a je mnohem rychlejší jak STP. Třeba používat TRUNK na switchích s STP znamená, že dojde k nemalé (několik sekund) ztrátě spojení při odpojení jednoho kabelu z trunku. V případě RSTP vypadne mamximálně jeden ping, někdy ani to ne.
Pak tu máme MSTP, což by mělo být zpětně kompatibilní s RSTP (ale moc lidí tomu nevěří a RSTP proti tomu nedává a řeší se spojení dvou takových prvků přes různé guardy a základními filtry na loopy).
MSTP je taktéž standard "IEEE 802.1s and later merged into IEEE 802.1Q-2005".
Ten přidává podporu instancí a path cost a path priority. Lze tedy jednoduše řídit tok dat jednotlivých vlan nebo skupin vlan.
Proti tomu stojí právě proprientální řešení od cisca PVST.
Máme tu tedy dva síťové standardy, které nejsou v linuxu implementovány, místo toho existují projekty, co to implementují do userspace. To by teoreticky nevadilo, kdyby to nebylo tak nějak divně mrtvý. Existuje dosti forků a všechny vypadají staře.
Pravdou je, že jsem to nikdy na linuxu nepotřeboval, jen na switchích a routerech.
Zdar Max

[trekker.dk]

Pravdou je, že jsem to nikdy na linuxu nepotřeboval, jen na switchích a routerech.

Jo, když odpadají licenční problémy, tak tohle bude nejspíš důvod, proč v kernelu RSTP není. Bylo by tam hezké, ale nikdo to vlastně nepoužívá, tudíž se nikomu nechce s tím patlat. Používat bridge jako fyzický switch sice jde, ale řekl bych, že drtivá většina použití bude spojení wifi a ethernetu na nějaké domácí routovací krabičce. Na větší nasazení to má málo portů (protože se do počítače nevejde tolik síťovek) a narozdíl od normálního switche se všechno řeší softwarově. S nástupem virtualizace (a virtuálních síťovek jako portů v tom bridge) by se tohle mohlo trochu posunout, ale neřekl bych, že o moc - připojením jednoho virtuálu do stejného bridge přes několik síťovek žádné výhody nemá (resp. žádné mě nenapadají) a jen si to koleduje o průšvih.

[Max]

Nesouhlasím, je tu spousta mgmt síťových prvků postavených na linuxu, tudíž implementace v kernelu by určitě byla dobrá. Se právě divím, že to nikdo neimplementoval.
Zdar Max

[Michal Kubeček]

Podle všeho to zatím nikdo nepotřeboval tak moc, aby buď implementaci napsal nebo zaplatil někoho, kdo ji napíše. Nebo jsem aspoň nenarazil na žádné vyjádření ve smyslu "ne, tohle do jádra nepatří".

[trekker.dk]

spousta mgmt síťových prvků postavených na linuxu

Nevím, které prvky jsou tím myšleny, ale pokud jde o switche a podobné*, tak i kdyby v nich byl Linux, určitě nebudou pro přepínání paketů používat kernelový bridge. A nemá smysl dávat do jádra implementaci RSTP pro něco, co se nakonec nepoužije. Tipl bych si, že spíš budou mít userspace proces, který od hardwaru dostane info o tom, že přišel RSTP rámec, a případně něco pošle do sítě.

*) moc mi toho pod rukama neprošlo, ale jediný výrobce, který se zatím "přiznal", že mu jako OS běží nějaký open source, je Juniper se svým JunOS - který navíc vychází z BSD, ne z Linuxu.

[coques]

F5 beží na linuxe

[Michal Kubeček]

Ono to může zase začít být zajímavé, pokud se trochu rozjede podpora switching devices v linuxovém jádře (IIRC loni v únoru David Miller oznamoval, že máme konečně první takový driver). Ale netroufám si říct, jestli je opravdu vhodné/žádoucí mít [RM]STP implementované zrovna v jádře.

[trekker.dk]

Štítky: +prasárna. Na tohle se nepoužívá bridge ale (terminologie linuxového kernelu) bonding.

[Petr Tomášek]

Blbost, na tohle se bonding určitě nepoužívá. Třeba chci za PC zapojit další zařízení, jak tomu pomůže bonding, he?

[Michal Kubeček]

Pokud jste nechtěl, aby čtenáři druhou podmínku 3 ze zadání přehlédli, měl jste jí dát unikátní číslo. :-)

[trekker.dk]

Praste si, jak umíte...

[Petr Tomášek]

A v čem má jako podle vás to prasení spočívat? Že používám switch (=bridge) přesně na to, k čemu je switch určený?

[VSi]

U bondingu jsem narazil na problém, že bond zařízení nelze vrstvit nad sebe - v mém případě jsem potřeboval 2× balance-alb bond, a nad tím active-passive failover. Taková konfigurace jde vytvořit, ale data neprochází... možná jsem dělal něco špatně, ale nedokázal jsem k tomu najít žádnou dokumentaci, kde by bylo zmíněno, jestli je takový setup podporovaný.

Takže jsem to vyřešil jako 2× bond, a nad tím bridge s STP, i když to STP je fakt pomalé, chtělo by to RSTP.

[trekker.dk]

Jo, to podle všeho podporované není - našel jsem k tomu tohle http://unix.stackexchange.com/questions/81633/rhel-5-complex-port-bonding