nu e datorita rp_filter, am incercat. Insa am gasit ceva interesant in documentatia de sysctl:
904 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#904> accept_local - BOOLEAN905 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#905> Accept packets with local source addresses. In combination906 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#906> with suitable routing, this can be used to direct packets907 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#907> between two local interfaces over the wire and have them908 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#908> accepted properly.909 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#909> 910 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#910> rp_filter must be set to a non-zero value in order for911 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#911> accept_local to have an effect.912 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#912> 913 <http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#913> default FALSE Acum problema devine "what is suitable routing". Insa de asemenea s-ar putea sa le primeasca si sa nu raspunda corect. Cred ca pina la urma tot namespace. thanks! 2013/2/14 Florin Samareanu <[email protected]> > 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 > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
