On May 17, 2012, at 3:57 PM, Adrian Popa <[email protected]> wrote:
> Nu știu dacă în RFC-ul 2131 e specificat un mecanism de revocare a unei > clase stabilite. > Teoretic odată ce i-ai confirmat unui client o anumită clasă, nu prea mai > ai cum să o iei înapoi fără ca clientul să ceară eliberarea/reînnoirea > clasei. Fiecare client va cere reînnoirea adresei după lease_time/2 > secunde, așa că atunci ai putea răspunde cu NACK și clientul ar cere o > clasă nouă, dar chestia asta nu se întâmplă foarte frecvent. > > Dacă îți trebuie alocată clasa mai repede, ar trebui să scazi lease_time > pentru clientul respectiv, dar asta înseamnă că el va face cereri de renew > mai dese și vei avea un overhead mai mare. Lease time e exclus. La cat naiba sa-l pun astfel incat clientii sa nu simta delay ? la 2 secunde ? imagine the noise > > Dar poate problema ta se poate rezolva mai elegant altfel, dar trebuie să > ne spui ce vrei să faci defapt. pai cam ce-am zis mai devreme: * router are aloca ip-uri prin dhcp * clientii proaspeti primesc un ip care are o singura regula de filtering - redirect catre o pagina in care dau proceed sau nu (un fel de captive portal - http://en.wikipedia.org/wiki/Captive_portal) * clientii care dau proceed, intra pe un numar de vreo 10-15 reguli de filtrare Ce vreau e sa nu fie nevoie sa adaug 10-15 reguli de filtrare pentru fiecare nou IP. Daca puteam sa-i schimb ip-ul, puneam regulile pe o clasa si il mutam in clasa aia) > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug -- Jay _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
