Si nu cumva le da drop datorita rp_filter? Sent from my iPhone
On Feb 14, 2013, at 13:21, alex alex <[email protected]> wrote: > 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 _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
