Dotaz: DHCPD 1IP pro 2MAC

[zipi]

Zdravím, umí dhcp server přiřazovat jednu IP ke dvou MAC adresám?

V dhcpd.conf mám napsáno tohle, ale danému zařízení to nepřidělí druhou IP, pokud byla již použita už u hostu PC.

Do logu mi to píše že ještě nevypršela session u prvního hosta.

host PC {
	hardware ethernet BA:DF:00:DF:C0:FF;
	fixed-address 192.168.1.1;
}

host PCC {
	hardware ethernet BA:DF:00:DF:C0:FF;
	fixed-address 192.168.1.1;
}

---

---

Odpovědi

[Filip Jirsák]

To je správně, nemohou být v síti dvě zařízení se stejnou IP adresou. To by muselo to první zařízení IP adresu vrátit.

[Petr Tomášek]

Nesmysl, být můžou .

Navíc pokud je to to samé zařízení s vícero síťovými rozhraními, tak to dokonce má i opodstatnění...

[pavlix]

V některé síti je to fuk, v jiné není, takže standard z toho rozumně udělat nejde.

[pavlix]

Tady prosím ignorujte, dám to ještě pod správný komentář.

[Filip Jirsák]

Mohl byste nám prakticky popsat, jak to potom vypadá? Mám v síti současně dvě zařízení s IP adresou třeba 192.168.1.1 a začínám navazovat TCP spojení s touto adresou. Jak konkrétně to bude vypadat? Navážou se dvě spojení, jedno, žádné? Nebo to bude záviset na momentální konstelaci hvězd a uživatelé v té síti se budou divit, proč jim náhodně síť někdy funguje a někdy nefunguje?

[Peter Golis]

Vyzerať to bude podobne ako keď sa správca snaží nepoužiť technológiu primárne na to určenú, teda bonding.

[pavlix]

Obávám se, že bonding není vůbec primárně určený pro tento specifický use case.

[Peter Golis]

Obávam sa, že mód active-backup je presne na toto určený.

[pavlix]

Chápu, co tím myslíš, ale mám dojem, že byl bonding primárně určený a vytvořený pro situace, kdy (1) je nakonfigurovaný na obou stranách, (2) se počítá především s lehce a rychle detekovatelnými chybami. Pokud vím, tak vznikl v kontextu datacenter, nikoli v kontextu mobilních zařízení, takže toto vzhledem k zásadním odlišnostem ani primární účel být nemůže, za tím si bohužel musím stát.

Vyzerať to bude podobne ako keď sa správca snaží nepoužiť technológiu primárne na to určenú, teda bonding.

Otázka je, jaké výhody přesně jednostranně nakonfigurovaný bonding může přinést oproti těm ostatním řešením. Pokud možno konkrétně, ne nějaké filosofické kecy jako ty výše. Když se přidával do NetworkManageru bonding, byl setup wifi+eth taky první use case, co mě napadl, ale ne vždycky je hned první nápad ten nejlepší, to ukáže až čas.

[Peter Golis]

Najhoršie je to že zadávateľ témy vyjadril čo potrebuje dosiahnúť až po tom ako sa tu strhla debata o vzdušných zámkoch. Začal s tým, ako chce dosiahnúť časť nepodporovaného riešenia ktoré môže fungovať len náhodou a pri určitej konštalácii hviezd.

Ak potrebuje pohodlné pripojenie NB s pomocou striedania NW rozhrania, tak na to nepotrebuje nič zvláštne. Stačí mu aby NB pretlačil hostname cez DHCP do DNS. Ak chce mať zachované konekcie pri prepnutí NW rozhraní (ETH OnBoard, ETH USB Dock, možno WiFi), tak potrebuje mať na to nielen postavenú topológiu ale aj korektne nastavené klientské stanice. Aj preto, že si zamestnanci určite pomenia tie USB dokiny a tým pádom vezba MAC USB ETH (v dokine ktorá pre srandu zmenial majiteľa) na hostname a IP nemá zmysel. Buď to ojebabre pri pripojení USB ETH vypnutím ONBOARD ETH a nastavením rovnakej MAC na USB ETH (čo je pár riadkov), alebo použije niečo sofistikovanejšie. Ale ajtak sa mu môže zopár packetov postrácať. Ďalšeie možnosti ako zamontovať do toho VLANy a podobné cudzie slovíčka je už zbytočné. Možností je viacero.

[Petr Tomášek]

Naváže se jedno spojení, jen není zaručené, přes který interface to pojede (což ale naprosto nevadí, protože IP packety do cíle vždy dojdou). Co se může maximálně stát(*) je to, že se na krátký čas začnou ztrácet packety v okamžiku vypnutí jednoho z interfaců. Dle mých zkušeností ale TCP vydží (spíš jsem míval problémy s RTP streamem, který tuto krátkou pauzu občas nerozdýchal...).

(*)Samozřejmě za předpokladu, že žádný ze síťových prvků není natolik zkriplený, aby situaci nerozdýchal.

[Filip Jirsák]

IP pakety do cíle sice vždy dojdou, ale ten cíl může být pokaždé jiné zařízení. Vy stále popisujete speciální případ, kdy obě rozhraní jsou součástí jednoho počítače, což ale není obecný případ, který se řeší v tomhle vlákně.

[Petr Tomášek]

Nemáte pravdu. Naučte se číst, protože přesně o tento „speciální případ“ se zde jedná.

[pavlix]

To musím potvrdit, nevím, co pan Jirsák bere, ale celá diskuze je pouze o speciálním případu, kdy se jedná o dvě síťová rozhraní jednoho linuxového systému. To už se tu rovnou můžem rozepsat o pěstování ovoce.

[Filip Jirsák]

Gratuluju oběma k věšteckým schopnostem. Zkuste si teď přečíst dotaz ještě jednou, a pochopíte, že my ostatní, kteří křišťálovou kouli nemáme, z dotazu nemůžeme tušit, že se jedná o jedno zařízení. Ta informace byla poprvé uvedena včera ve 22:12, takže včera ve 20:40 s ní běžní smrtelníci ještě pracovat nemohli.

Navíc pokud je zařízení stále připojeno oběma rozhraními do stejné sítě, nemělo by vadit, že požadovanou IP adresu má jenom jedno rozhraní. A pokud se přepojuje z jednoho rozhraní na druhé, neměl by být problém na tom prvním rozhraní tu IP adresu vrátit.

[Petr Tomášek]

danému zařízení to nepřidělí druhou IP

...hovoří IMO za vše. I když je ten příspěvek trochu zmatený, je jasné, že šlo o pouze jediné zařízení...

[Filip Jirsák]

Ano, říká to, že jedno zařízení nedostane IP adresu toho druhého zařízení, kterým je "host PC". Nazvat jedno zařízení v jedné větě jednou "zařízením" a jednou "host PC" opravdu není dobrý způsob, jak napsat, že se jedná o jedno a totéž zařízení.

Naštěstí tazatel na druhý pokus popsal, co doopravdy řeší, ale z toho úvodního dotazu to jasné není.

[pavlix]

že my ostatní

Jo tak Jirsák je teď my ostatní, sorry, na tohle nemám náladu. Ale původní dotaz je špatně položený, to je pravda.

A pokud se přepojuje z jednoho rozhraní na druhé, neměl by být problém na tom prvním rozhraní tu IP adresu vrátit.

On to problém ale je. Jestliže se ta adresa nejdříve vrátí a teprve potom znovu získá, je tam časová prodleva, která by mohla teoreticky vadit. Jestli v praxi nevadí, ok, ale rád bych to měl nějak podložené na základě chování kernelu.

[Filip Jirsák]

Jo tak Jirsák je teď my ostatní, sorry, na tohle nemám náladu.

Ne, není. Vytrhl jste to z kontextu schválně, nebo jste tu větu ani nedočetl? Ono tam totiž je napsáno my ostatní, kteří křišťálovou kouli nemáme, což má poněkud jiný význam, než jaký tomu přisuzujete.

On to problém ale je. Jestliže se ta adresa nejdříve vrátí a teprve potom znovu získá, je tam časová prodleva, která by mohla teoreticky vadit. Jestli v praxi nevadí, ok, ale rád bych to měl nějak podložené na základě chování kernelu.

Ano, to by mohlo vadit. Bohužel, když nevíme, jak to tazatel chce používat, těžko radit. Už sice víme, že jde o dokovací stanici, ale pořád (asi) nevíme, zda je požadavek na přepínání „za běhu“ (tedy jsem připojen přes WiFi, šoupnu notebook do doku a spojení zůstanou zachována), nebo zda požadavek na stejnou IP adresu je spíše kvůli přehlednosti a přepojení z WiFi do doku se typicky dělá s vypnutým nebo uspaným notebookem, takže prodleva nevadí.

[pavlix]

Nejde mi o nějaké hádky, jen mě skutečně pobavilo, že takový svéráz jako vy, který je věčným oponentem všech ostatních, používá slovní spojení my ostatní.

[Ivan]

asi by to slo "ocurat" tim, ze bys' pouzil DHCP s LDAP backendem. ale na co to potrebujes? vzdyt je to nesmysl.

PS: nejsem si jistej, jestli se doopravdy pro fixed-hosty zapisuji leases do souboru.

[zipi]

Potřebuji to kvůli USB dokinam :(, které mají odlišné MAC adresy od notebooku.

[Jendа]

Hm. Tvůj problém nejspíš bude v tom, že ta lease nevyprší a tak ji DHCP server odmítne znova přidělit.

Co nastavit oběma síťovkám stejnou MAC?

[Petr Tomášek]

vzdyt je to nesmysl.

Není to nesmysl, běžně to používám. Notebook můžu zároveň připojit přes wifi a zároven přes pevný ethernet. Normálně na stole to visí na pevném ethernetu kvůli spolehlivosti, atd. a když potřebuji s ntb odejít jinam, tak prostě zapnu WiFi a pak odpojím kabel a všechno funguje dál, např. mně to neshodí ssh spojení atd.

A není v tom žádný problém, protože je naprosto šumafuk, ze kterého rozhraní packety přicházejí atd...

[pavlix]

V některé síti je to fuk, v jiné není, takže standard z toho rozumně udělat nejde.

[Petr Tomášek]

Hele, to je tak nicneříkající gumový výrok, že ani nemá cenu ho komentovat...

[pavlix]

Zase na druhou stranu, kdybys o sítích něco trochu víc věděl, byl zvyklý o nich přemýšlet, případně měl nějakou tu zkušenost se zařízeními, která si pohlídají, abys se stejnou MAC nepřistupoval různými cestami (třeba jen různými fyzickými porty nebo v tomto případě dokonce zcela různými rozhraními), nebyl by to pro tebe vůbec gumový výrok a hlavně bys nepředpokládal, že když jednou něco vyzkoušíš, že to bude platit obecně. Zase na druhou stranu nemůžeš čekat, že tu práci se získáváním znalostí a nabíráním zkušeností za tebe udělá někdo jiný.

[Petr Tomášek]

Gumový výrok je to pořád, dokud nenapíšeš konkrétně o čem mluvíš. To jsou jen takové všeobecné kecy, které nejde ani vyvrátit ani dokázat (dokud to nekonkretizuješ o čem vlastně chceš mluvit).

Jo, samozřejmě, když budeš mít v síti switche, které si příliš hrají na bezpečnost, tak máš smůlu. Nicméně to je tvoje rozhodnutí jakožto správce sítě, co vůbec chceš...

[pavlix]

Gumový výrok je to pořád, dokud nenapíšeš konkrétně o čem mluvíš.

Už se stalo.

To jsou jen takové všeobecné kecy, které nejde ani vyvrátit ani dokázat (dokud to nekonkretizuješ o čem vlastně chceš mluvit).

Nebo stačí používat tu šišatou kouli na krku.

Jo, samozřejmě, když budeš mít v síti switche, které si příliš hrají na bezpečnost, tak máš smůlu. Nicméně to je tvoje rozhodnutí jakožto správce sítě, co vůbec chceš...

1) Kupodivu se ne vždycky jedná o zařízení, od kterých bys to primárně čekal.

2) Majitel laptopu není nutně správcem sítě, naopak se čast pohybuje ve více různých sítích, které nespravuje.

3) Tvůrce standardu rovněž není správcem všech sítí, kam se všichni majitelé laptopů připojují a ani k tomu nemá nijak blízko.

Právě z těchto důvodů si nemyslím, že by bylo možné či dokonce rozumné vystavět nad tím standard, který by se týkal právě laptopů s kombinací ethernetu a wifi, a jsem přesvědčen o tom, že tahle konfigurace zůstane nestandardním hackem alespoň dokud se neudělá standard i pro tu druhou stranu, který by umožnil detekovat podporu roamingu mezi wifi a ethernetem. Takže sorry, je mi líto, nebreč, co se dá dělat.

[Petr Tomášek]

2) Majitel laptopu není nutně správcem sítě, naopak se čast pohybuje ve více různých sítích, které nespravuje.

A já myslel, že se bavíme o správci DHCP serveru .

Právě z těchto důvodů si nemyslím, že by bylo možné či dokonce rozumné vystavět nad tím standard, který by se týkal právě laptopů s kombinací ethernetu a wifi

A to tvrdí kdo?

a jsem přesvědčen o tom, že tahle konfigurace zůstane nestandardním hackem

Souhlas. Ovšem existují i "nestandardní hacky", které za normálních okolností (žádné velké chytré switche, atd.) prostě fungují...

[pavlix]

A já myslel, že se bavíme o správci DHCP serveru .

Pravda, trochu míchám vlákna, bonding versus multilease, sorry, stane se. Na tom DHCP serveru bych viděl jako možnost multilease ideálně pomocí DUID namísto skupiny MAC adres, a na síti, kde se ví, že to funguje, by mohl administrátor v serveru zapnout tuhle funkci, na ostatních sítích by ji vypnul, nebavme se teďka o tom, co by byl default.

Otázka tedy zní, jestli se umí běžný klient srovnat s tím, že dostane dvě stejné IP adresy pro různá rozhraní. Pak by asi bylo dobré, kdyby klient uměl preferovat lepší cestu, tedy drát. A stejnětak by bylo dobré, kdyby bridge na routeru uměl najít stroj na obou stranách, ale preferovat drát, ale hlavně, aby byl celý mechanismus dotazování se přes ARP/NDP přizpůsobený situaci, kdy odpověď chodí ze dvou stran. Tam je víceméně potřeba při dotazování ze strany serveru počkat, aby měly šanci dojít obě odpovědi, ale zase nečekat příliš dlouho, aby se tím nezdržovala komunikace, a ideálně průběžně obnovovat, i když komunikace probíhá.

Pravda, nemluvím o tom, že se něco zkusí a ono to nějak projde, ale o řešení, které by vykazovalo určitou dávku solehlivosti a předvídatelného chování, tedy vlastnosti, které by dobrý standard měl mít.

Právě z těchto důvodů si nemyslím, ...

A to tvrdí kdo?

Nevyjádřený podmět, neznáš? ;)

[Ivan]

To se mi nejak nezda. Alespon wokna to maji tak, ze kdyz pevny ethernet nema link, tak na tom inferface neni ani zadna IP adresa. Pokud pevny ethernet ztrati link alespon na 2 vteriny, tak wokna poslou DHCPDISCOVERY (broadcast) do site, takze se zadny lease time neuplatnuje. (Tohodle vyuzivam, kdyz prehazuju na portech VLANy. Shodim link na portu na swichi a po nahozeni, dostane klient IPcko z jinyho segmentu).

Pokud ale mas zapojeny kabel a zaroven se pripojis stejne site pres Wifi, tak musi blbnout.

Neverim, ze jde prehodit Ipcko z jednoho interface na jiny, aniz by popadaly TCP spojeni.

[Petr Tomášek]

Pokud ale mas zapojeny kabel a zaroven se pripojis stejne site pres Wifi, tak musi blbnout.

Nemusi. Pod linuxem mi to funguje. Widle nefunguji, ale to me jaksi nezajima.

Neverim, ze jde prehodit Ipcko z jednoho interface na jiny, aniz by popadaly TCP spojeni.

Jde.

[pavlix]

tak wokna poslou DHCPDISCOVERY

Ono je to v podstatě jedno, co pošleš, jestli DHCPDISCOVER nebo DHCPREQUEST, druhém případě můžeš vždy dostat DHCPNAK nebo ICMP unreachable a převedeš to na ten první případ. Samozřejmě odhlížím od chyb software.

Neverim, ze jde prehodit Ipcko z jednoho interface na jiny, aniz by popadaly TCP spojeni.

Co konkrétně tomu podle tebe brání? Změna IP neproběhla, takže druhá strana může komunikovat jako doposud. Takže mě napadá jedině kernel, a do toho bohužel nevidím, ale nevidím v tom úplně problém. Osobně bych se spíš bál různých implementací wifi routerů a jejich bridgů a switchů, tam to prostě může a nemusí fungovat.

[Ivan]

Ono je to v podstatě jedno, co pošleš, jestli DHCPDISCOVER nebo DHCPREQUEST, druhém případě můžeš vždy dostat DHCPNAK nebo ICMP unreachable a převedeš to na ten první případ.

Ten request nefunguje, protoze je to unicast packet a jeho cilova adresa se uz nemusi v jine siti (VLANe) vyskytovat. Pokud se posle DHCPREQUEST tak se musi dhouho cekat na timeout. Wokna proto po odpojeni a zapojeni kabelu vzdy posilaji DHCPDISCOVER. dhcp server to taky zkousne, protoze mu nevadi, ze ma dva leases zaznamy pro stejny host, pokud ty leases patri do ruznych siti.

Co konkrétně tomu podle tebe brání? Změna IP neproběhla, takže druhá strana může komunikovat jako doposud. Takže mě napadá jedině kernel, a do toho bohužel nevidím, ale nevidím v tom úplně problém. Osobně bych se spíš bál různých implementací wifi routerů a jejich bridgů a switchů, tam to prostě může a nemusí fungovat.

Ted kdyz o tom premyslim, tak asi nic. Mas pravdu. Mozna pokud bych mel zapnuty nejaky agresivni TCP keepalive tak mi to spadne pri prepojovani v okamziku kdy to IPcko nemam. Stejne je to ale divny, dve stejny MAC adresy musi delat bordel v CAM tabulkach.

[pavlix]

Ten request nefunguje, protoze je to unicast packet a jeho cilova adresa se uz nemusi v jine siti (VLANe) vyskytovat.

Nemám teď úplně připravenou infrastrukturu na testování, ale bude. Teď jsem narychlo otestoval dhcpcd, který zjevně posílá DHCPREQUEST broadcastem. Později vyzkouším dhclient a NetworkManager.

12:22:17.529524 IP (tos 0x0, ttl 64, id 48068, offset 0, flags [none], proto UDP (17), length 379)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from d0:50:99:17:87:3f, length 351, xid 0x320587b1, Flags [none] (0x0000)
          Client-Ethernet-Address d0:50:99:17:87:3f
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 19: hardware-type 255, 99:17:87:3f:00:01:00:01:1c:6c:64:dc:d0:50:99:17:87:3f
            Requested-IP Option 50, length 4: 172.16.2.189
            MSZ Option 57, length 2: 1500
            Vendor-Class Option 60, length 55: "dhcpcd-6.6.7:Linux-3.17.8-gentoo-r1:x86_64:AuthenticAMD"
            T145 Option 145, length 1: 1
            Parameter-Request Option 55, length 14: 
              Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway
              Domain-Name-Server, Hostname, Domain-Name, BR
              NTP, Lease-Time, Server-ID, RN
              RB, Option 119

V takovém případě má DHCP server možnost poslat okamžitý DHCPNAK a nadále pokračovat jako kdyby žádná lease nebyla.

v okamziku kdy to IPcko nemam

Nevím, jak se přesně chová kernel při ztrátě IP, proto jsem spíš uvažoval o možnosti tu IP vůbec neztratit.

Stejne je to ale divny, dve stejny MAC adresy musi delat bordel v CAM tabulkach.

Tam je právě ta závislost na prostředí, které nejde plně ovlivnit z toho koncového stroje.

[Ivan]

Nemám teď úplně připravenou infrastrukturu na testování, ale bude. Teď jsem narychlo otestoval dhcpcd, který zjevně posílá DHCPREQUEST broadcastem. Později vyzkouším dhclient a NetworkManager.

Tak je to jinak nez jsem si myslel. Uz je to par let co jsem se v tom hrabal a navic jsem resil hlavne Wokna. Pokud se dobre pamatuju, tak ve zdrojacich ISC je neco jako, "kdyz client preferuje broadcast, tak server odpovida broadcastem" - anebo obracene. Ale logictejsi je, ze se server prizpusobi klientovi.

[Jendа]

Ty MAC jsou stejné.

[Jendа]

A jinak se bojím, že to umět nebude, a budeš ho muset upravit nebo si napsat vlastní DHCP server, který to bude dělat.

[zipi]

Promiň MAC adresy jsou odlišné ...

[Peter Golis]

A čo bráni nastaveniu MAC adresy pre USB sieťovku tak aby bola zhodná s onboard sieťovkou? Teda ak si odmyslím že niektoré OS mimo zamerania tohoto portálu to neumožňovali a dockiny si môžu užívatelia navzájom poprehadzovať.

[Petr Tomášek]

host pc-eth {
  option host-name pc;
  hardware ethernet 00:11:22:33:44:55;
  fixed-address 192.168.1.99;
}
host pc-wlan {
  option host-name pc;
  hardware ethernet 99:88:77:66:55:44;
  fixed-address 192.168.1.99;
}

[pavlix]

Mám pocit, že mi toto kdysi nefungovalo, můžeš k tomu přidat kompletní verzi DHCP serveru, případně jestli to závisí na nějakých dalších podmínkách? Jinak označit svůj příspěvek jako řešení je špatně v tom, že tím označuješ celý dotaz za vyřešený, aniž by tvůj příspěvek někdo druhý zrevidoval. Člověk se často mýlí a to nejen v oblastech, kde není úplně doma.

[Petr Tomášek]

IMO by to mělo být standardní chování. Používám normálně to, co je v Debianu Wheezy (4.2.2.dfsg.1-5+deb70u6).

[pavlix]

Jak potom vypadají ty leases? Vždyť ty potřebuješ dvě souběžné leases pro jednu IP, to budu muset testnout a možná i nahlásit jako chybu :D.

[NN]

Funguje to metodou "kdo drive prijde, drive mele" ie. neporusuje to standard. Precti si pozorne co pise, tvrdi ze v dokovaci stanici ma kabel a bez dokovaci stanice ma wifi = different interface, same IP = naprosto legit a spojeni zustanou protoze L3 vrstva to neresi.. nepise, ze jede na obou soucasne, to by byl skutecne nesmysl a napsane je totak, ze to tak vipada..

[pavlix]

Funguje to metodou "kdo drive prijde, drive mele" ie.

Jo to chápu, ale v diskuzi se probíral i plynulý přechod, kdy je potřeba jet chvíli současně, ale to asi není předmětem dotazu, to je fakt. Na druhou stranu se mi vůbec nelíbí myšlenka, že připojím laptop do docku a přijdu o všechna spojení, protože kernel mezitím tu IP adresu chvíli vůbec neměl. Z toho důvodu zatím používám wifi i v docku a akorát jsem trochu uvažoval o bondingu, jenže tam se mi zase nelíbí ta závislost na konkrétní síti, kde to funguje.

[NN]

Bokem, podle meho nazoru hodi system EADDRINUSE pokud se pokusi nastavit stejnou IP na dve rozhrani a neprojde to dokud tu puvodni neuvolnis. Jako reseni si dokazu predstavil bridge, se zapnutym STP, kteremu priradis IP..

[pavlix]

Bokem, podle meho nazoru hodi system EADDRINUSE pokud se pokusi nastavit stejnou IP na dve rozhrani a neprojde to dokud tu puvodni neuvolnis.

mole ~ # ip a a 192.168.1.1/24 dev eth0
mole ~ # ip a a 192.168.1.1/24 dev wlan0
mole ~ # ip a | grep 192.168
    inet 192.168.1.1/24 scope global eth0
    inet 192.168.1.1/24 scope global wlan0

Jako reseni si dokazu predstavil bridge, se zapnutym STP, kteremu priradis IP..

Jsi si jistý, že je STP spolehlivý i když ho nepodporuje druhá strana?

[NN]

lol ;) beru zpet..

[Petr Tomášek]

Jak potom vypadají ty leases? Vždyť ty potřebuješ dvě souběžné leases pro jednu IP,

No a? Co se ti na tom nelíbí? Pořád je to maximálně jedna lease na MAC .

to budu muset testnout a možná i nahlásit jako chybu :D.

Jestli máš čas nazbyt, můžeš to zkusit. Ale vzhledem k tomu, že je feature not a bug, tak bych tomu moc šancí nedával...

[pavlix]

Lease je výpůjčka a jedná se o výpůjčku IP adresy, nikoli MAC adresy, tu stroj už má.

[lertimir]

Chvíli jsem takovou konfiguraci zkoušel, ale dynamické přehození to stejně nezvládalo. Kromě duplicity IP adresy byl ještě problém s routingem ve stanici. Směrovací tabulky jsou na rozhraní, a pokud seberu systému konektivitu na rozhraní, tak mu nějakou dobu trvá, než zjistí, že tím směrem už nic nepošle. Někdy to chtělo i shození a nahození síťování.

Ale zajímalo by mne jestli je nějaká rozumná možnost, jak mít stabilní IP adresu. Typická situace, kdy jsou roztahané kabely a navíc i pokrytí wifi a uživatel si může zvolit jestli se připaojí kabelem (rychle a omezený pohyb) nebo wifi (pomalu a volně). Někdy je vhodné adresu (možná by stačilo i doménové jméno) držet, protože některé služby v síti (typicky backup) by rády se spojily se stanicí a při rozdílných adresách služba pracuje jen pro připojení jedním interface.

[pavlix]

Mobile IP?

[NN]

Pokud myslis ten IETF draft, tak to po par letech umrelo a od roku 2004 se to nevyviji. Nebo se pletu?

[lertimir]

Nakonec mám dva DNS A záznamy se stejným jménem a backup se odkazuje na doménové jméno. Nicméně otázka jestli to rozumě na IP levlu jde udělat trvá. Jak jsem psal vedle, bez nějakého RIPu na klientské stanici si to moc představit nedokážu. A samozřejmě Mobile IP na IPv4 mě připadá zrůdný. Na IPv6 asi ano, ale nastudováno nemám.

[zipi]

Na jaké platformně to zkoušíš Linux, Apple či Windows?

[lertimir]

zkoušel jsem to na linuxu (openSUSE) ale to je jedno. routovací tabulka netstat -r nastaví nějaké routy a dokud není důvod je měnit tak zůstanou. většinou bylo třeba v NM apletu vypnout síťování a znovu zapnout aby dhcp client provedl nový dotaz. Asi jiná alternativa by možná bylo možné spustit RIP, ale to bych na klientu nedělal.

[zipi]

Otestuji a dám info zítra jak to dopadlo .. Na jednom PC mi to běhá bez problému.

[zipi]

Konfigurace je Ok, ale mají s tím problém Windows 7 :( pokud chci použít druhou síťovku ze stejnou IP tak musím provést restart systému.

DHCP log:

dhcpd: DHCPACK on 192.168.1.1 to BA:DF:00:DF:C0:FF via ethernet-lan
dhcpd: DHCPOFFER on 192.168.1.1 to BA:DF:00:DF:C0:FF via ethernet-lan
dhcpd: DHCPREQUEST for 192.168.1.1 from BA:DF:00:DF:C0:FF via ethernet-lan