Da, ma lasa. Acum cunoaste arp dar probabil din acelasi motiv pentru care nu se raspundea la arp, acum nu raspunde la ICMP. E o idee buna, insa rezolva 1/2 din problema. dar e un pas inainte. Multumesc.
2013/2/13 Adrian Popa <[email protected]> > O altă idee ar putea fi (dacă te lasă) să setezi arp static - MAC-ul eth0 > ca fiind învățat prin eth1 și invers. Așa scapi de ARP, în speranța ca > verifică dacă are MAC destinație cunoscut înainte să verifice dacă MAC > destinație e pe o interfață proprie. > > > 2013/2/13 Florin Samareanu <[email protected]> > > > Poate e o prostie, dar accept_source_route si rp_filter nu fac ce vrei > tu? > > > > Sent from my iPhone > > > > On Feb 13, 2013, at 17:57, alex alex <[email protected]> wrote: > > > > > Salut, > > > Incerc sa obtin o posibilitate sa masor o conectivitate intre doua > > > switchuri avind acces la un singur capat si m-am gindit la urmatorul > > set-up: > > > > > > o statie linux (doua carduri retea), fiecare card conectat in cite un > > port > > > al switch1. Porturile din switch 1 sunt in mod acces, vlan-uri > diferite. > > > Intre switch 1 si switch 2 am trunk. > > > Pe switch 2 am doua porturi configurate in mod acces, cu vlan-urile > copie > > > din switch 1. Intre aceste doua porturi pun un cross-over (loop). Dupa > ce > > > configurez switch 2 sa fie de acord cu bucla respectiva (!), practic am > > > obtinut o cale looped-back intre port1 din sw1 si port2 din sw2. > > > > > > Linux sw1 sw2 > > > ------------ access ------------------ trunk > -------------------- > > > | eth0|-------------|vlan10 |---------------| vlan10 > > > |----------| loop > > > | eth1 |-------------|vlan20 | | vlan20 > > > |----------| > > > ----------- access ------------------- > > > -------------------- > > > > > > Bun. Acum la partea care ma intereseaza. In linux configurez eth0 si > eth1 > > > in acelasi subnet (ex: 192.168.0.1 respectiv 192.168.0.2). Si incerc sa > > fac > > > ping cu sursa eth0 in ip eth1. > > > Ce obtin: arp initial pleaca asa cum trebuie(de pe eth0), parcurge > bucla > > si > > > intra in eth1. Nu am insa reply la arp. Evident, nici mai departe nu se > > mai > > > trimit pachetele ICMP. > > > Intrebarea este, pentru cine s-a mai lovit de asa ceva, daca exista o > > > explicatie. Si evident, daca exista vreo setare (/proc/sys/net?) > pentru a > > > obtine comportamentul dorit, adica conectivitatea. > > > Exista o solutie prin folosirea namespece-urilor care functioneaza ok > > prin > > > punerea celor doua interfete in contexte diferite. Insa macar as vrea > sa > > > inteleg comportamentul prin care kernelul trateaza pachete destinate > > catre > > > o interfata proprie de retea cind sursa este cunoscuta ca fiind o alte > > > interfata interna. > > > Un link care sa arunce o lumina in aceasta intrebare ar fi suficient. > Sau > > > daca e o intrebare timpita, un motiv pentru care e asa ar fi excelent. > > > Multumesc. > > > _______________________________________________ > > > RLUG mailing list > > > [email protected] > > > http://lists.lug.ro/mailman/listinfo/rlug > > _______________________________________________ > > RLUG mailing list > > [email protected] > > http://lists.lug.ro/mailman/listinfo/rlug > > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
