Da, daca pun arp static catre fiecare ip address prin interfata opusa. Vin cereri ICMP req. Nu se trimite reply. Deci probabil kernelul foloseste corect interfata de plecare (ping -I eth0 ), cunoaste ARP si pune pachetul pe sirma. Asta ajunge la eth1apoi in kernel care raspunde la ICMP insa probabil ca nu prefera interfata prin care acesta a ajuns fin'ca vede interfata direct conectata.Sau nu raspunde fiindca si-ar raspunde siesi. Cred ca este mai mult de sapat in aceasta directie, asa ca probabil o sa prefer varianta cu namespaces.
2013/2/14 Florin Samareanu <[email protected]> > Tcpdump pe interfata arata ca vin pachetele icmp la destinatie? > > F > > Sent from my iPhone > > On Feb 14, 2013, at 12:53, alex alex <[email protected]> wrote: > > > 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 > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
