linux forwarding plane

Podigao sam sofverski ruter na Ubuntu mashini koji radi u nekom mreznom okruzenju od par rutera. Na tom softverskom ruteru sam konfigurisao BGP protokol koji razmenjuje rute sa ostalim ruterim u okruzenju a najbolju rutu "spusta" u kernel ruting tabelu. Softver tako radi da se samo jedna najbolja ruta za svaki destin. prefix prosledjuje u kernel ruting tabelu. E sad, napravio sam male modifikacije na softveru tako da se, pod odredjenim uslovima, dve ili vise ruta za isti destin. prefix (ali sa razlicitim next hop-om) prosledjuju kernelu. Sa stanovista ruting daemona code se kompajlirao i sve se cini ok, tj. debug poruke pokazuju da se vise ruta prosledjuju kernelu. Medjutim, u samoj kernel ruting tabeli uvek postoji samo jedna ruta (prva koja je prosledjena), pa me zanima da li Linux ima neko ogranicenje sto se tice visestrukih ruta ili jednostavno prihvata sve sto mu daemon prosledjuje? Da li i kako se realizuje ECMP (equal cost multi path) forwarding na Linux-u? Hvala

http://www.zebra.org/

Hvala. Ovo sam vec pogledao ali nisam uspeo da nadjem resenje. Proanalizirao sam deo code-a koji koristi Linux netlink socket za dodavanje ruta u kernel i ne vidim ni jedan deo code-a koji proverava da li je ruta vec u kernelu, pa ako jeste - prepisuje je. Ove provere se inace rade na "visem" nivou u code-u ruting softvera (npr. u RIB-u ili samom ruting protokolu) a izmene koje sam napravio se, izmedju ostalog, odnose i na te provere. Medjutim kad dodje do toga se ruta koja vec postoji u kernelu, ali sa razlicitim next-hop -om upise u kernel, ovaj uvek prepise postojecu...

http://etutorials.org/Networki...er+8.+Static+Routing+Concepts/

Pogledacu ponovo sam code posto, kao sto sam i pretpostavljao, kernel prihvata rute od ruting daemon-a kao sto ih prihvata od user-level komandi (route add i sl.) i preko odgovarajucih socket-a instalira ono sto mu se dostavi u FIB. Hvala jos jednom.

Evo u cemu je stvar. Netlink socket, koji je zaduzen za komunikaciju izmedju user-space ruting sofvera i kernela, ima niz flag-ova koje user-space softver setuje da naznaci socket-u sta da radi sa tom rutom. Na primer, kada ruting softver prosledjuje novu rutu kernelu on setuje prvi flag NLM_F_REQUEST, sto znaci da salje novi zahtev sa dodavanje rute, a zatim setuje i dodatne flag-ove NLM_F_REPLACE (prepisi postojecu ruta ako postoji), NLM_F_EXCL (ne diraj rutu ako postoji), NLM_F_APPEND (klucna stvar :-))), dodaj rutu na kraju liste). Pretpostavljam da je ovaj poslednji flag kljucna stvar za implementaciju ECMP funkcionalnosti. Posto je u mom slucaju ruting sofver setovao flag-ove sledecim redosledom NLM_F_REQUEST | NLM_F_REPLACE, netlink socket je prepisivao postojecu rutu u kernelu. Kada sam drugi flag zamenio sa NLM_F_APPEND sve radi kako je ocekivano tj. vise ruta za isto odrediste se pojvaljuje u kernelu.

Kao sto kazes i sa user-space tools mozes dodati vise ruta za istu destinaciju ali to i dalje ne znaci da ces imati ECMP :) Ovdje ima primjer kako se postavlja ECMP sa modernim user-space alatima http://etutorials.org/Networki...ltiple+Equal-Cost+Routes+ECMP/

Da, slazem se. Razlicite implementacije forwarding plane-a imaju razlicite ECMP mehanizme (per flow, per packet,...). Pri tome i sam kernel mora biti kompajliran sa ovom opcijom da bi to uopaste radilo, ako se ne varam...? Kada sam rekao da mislim da je onaj flag mozda kljucni za ECMP, to sam mislio sa stanovista control plane sofvera (tj. ruting daemon-a), posto daemons (ili user-space tools) kontrolisu kernel ruting tabelu. U svakom slucaju, netlink socket (u slucaju Linuxa) instalira rute u kernel ruting tabelu u skladu sa flag-ovima koje mu setuju ruting daemons ili user-space tools. Na rapidshare se moze naci odlicna knjizica koja se zove "Understanding Linux Network Internals" koju sam u medjuvremenu nasao,gde je do detalja objasnjena Linux networking implementacija.