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

Raspunde prin e-mail lui