Re: [mpls-linux-devel] L2 VPN with MPLS - another problem

[Pali <pal...@gm...>]

Problem solved : )
*
sudo chmod a+rwx /dev/vmnet* -v*

do the work. Problem was in security setting that prohibit promiscuous mode
to regular user. More about this:

*
http://www.vmware.com/support/ws55/doc/ws_net_advanced_linux_vadapter_promiscuous.html
*


2010/5/12 Pali <pal...@gm...>

> Hi everybody, there is a little bit of magic, for some time LAB works as
> expected, pings return back, even TCP connections works across mpls tunnel
> (in tcpdump could be seen both tunnels) Even if I change hosts A1 and A2 for
> different clients, it also work. After rebooting Linux routers, problem
> repeat, arp replay does not appear inside the tunnel. Will explore why is it
> so, any clue?
>
>
> 2010/5/12 Pali <pal...@gm...>
>
>> Hi everbody,
>> I collected all useful information to debug L2VPN lab. I added them as
>> mail attachment, or they could be downloaded from:
>>
>> *http://www.localnet.sk/~maestro/dnl/mpls-linux/l2vpn_public_log.tgz<http://www.localnet.sk/%7Emaestro/dnl/mpls-linux/l2vpn_public_log.tgz>
>> *
>>
>> If anybody has a clue what is wrong, please write it. If someone find
>> useful, I could also hang network topology and all VM on Internet.
>>
>> Pali
>>
>> 2010/5/12 Pali <pal...@gm...>
>>
>>> Hi mpls community,
>>>
>>> I successfully run
>>>
>>>  *MPLS-Linux labs – 5.1 Layer 2 VPN with MPLS*
>>> *
>>> http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/mpls-linux/5-1-layer2_vpn.html<http://www.sj.ifsc.edu.br/%7Emsobral/RCO2/docs/mpls-linux/5-1-layer2_vpn.html>
>>> *
>>>
>>> using last stable Etch Debian with kernel 2.6.15.1 and mpls v1.950 patch.
>>> No more kernel panic appear, just kernel oops when I execute *
>>> del_mpls.sh* with no previous mpls configuration.
>>>
>>> Linux routers are quite stable, on uplink direction (A1->A3) everything
>>> works fine, broadcast, and arp request successfully travel from A1 to A3. No
>>> traffic return back, even I see arp reply on A3. Let me describe situation:
>>>
>>> A1: ping 172.16.30.30 or arping -i eth2 172.16.30.30
>>> E2: receive ICMP echo request on eth1, encapsulate as two layer MPLS
>>> packet (1000,100) and send out on eth0.
>>> E3: receive MPLS packet, change top label 1000 to 3000 and send MPLS
>>> packet (3000,100) from outgoing interface eth2.
>>> E1: receive MPLS packet (3000,100), remove all labels and send Ethernet
>>> frame from outging eth1
>>> A3: receive arp request on 172.16.30.30, because it has requested IP
>>> address, if replay with ARP-reply, that 172.16.30.30 is available under MAC
>>> address 00:0c:29:54:f1:0d
>>> E1: receive no ARP replay so it encapsulate no traffic back to
>>> E3->E2->A1. Here is the problem that I need to solve.
>>>
>>> I have same results with ping (L3) and arping (L2), even if I configure
>>> staticly MAC address of remote computer on A1 and A3
>>>
>>> example of static assignment:
>>> A3: arp -v -i eth0 -s 172.16.30.10 00:0c:29:53:64:53
>>>
>>> When I bypass MPLS network and connect A1 and A3 directly, everything
>>> works as expected, even with static MAC address assignment.
>>>
>>> Any ideas what could be wrong?
>>> I have this topology connected and freeze as virtual machines on VMware
>>> Workstation, so I can provide anytime all information, that You will
>>> request. I will search also mpls-linux mailing list archive if I found
>>> something.
>>>
>>>
>>> --
>>> << 0903 48 47 40 >> mobil
>>> << 309458351 >> icq
>>> << ortseamo >> skype
>>>
>>
>
>
> --
> Ak si prajes aby som cital tvoj mail do 5 min, tak napis do predmetu X5.
> Na skype som dostupny stale, len mi daj vediet aby som sa prihlasil.
>
> << 0903 48 47 40 >> mobil
> << 309458351 >> icq
> << ortseamo >> skype
>



-- 
Ak si prajes aby som cital tvoj mail do 5 min, tak napis do predmetu X5.
Na skype som dostupny stale, len mi daj vediet aby som sa prihlasil.

<< 0903 48 47 40 >> mobil
<< 309458351 >> icq
<< ortseamo >> skype