Re: Strange ARP problem

Normando Marcolongo <[email protected]>
Newsgroups gmane.linux.drivers.vlan
Message-ID <[email protected]>
Justin Cormack wrote:

>
>
> I think you have to do it while the interface is down.

Yeah I did but the problem persists. The fact is that Cisco too has the 
same MAC across multiple VLAN:

# arp -an
? (172.19.1.1) at 00:07:B3:1A:AC:0A [ether] on eth0
? (172.22.1.1) at 00:07:B3:1A:AC:0A [ether] on eth0.201

There you can see the linux machine catching the client broadcasts on 
the eth0.201:

09:48:39.392575 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST
09:48:40.128021 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST
09:48:40.688972 00:03:fe:ac:09:58 > 01:00:0c:cc:cc:cd sap aa ui/C len=39
09:48:40.877931 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST
09:48:41.627924 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST
09:48:42.378053 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST
09:48:42.688993 00:03:fe:ac:09:58 > 01:00:0c:cc:cc:cd sap aa ui/C len=39
09:48:43.127830 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST
09:48:43.877744 IP 172.22.1.5.137 > 172.22.1.255.137: NBT UDP 
PACKET(137): REGISTRATION; REQUEST; BROADCAST

and there you can see the client (.5) asking the MAC address of the 
server (.2) that replies. The reply is _not_ arriving on the client cable.

09:49:10.034136 arp who-has 172.22.1.2 tell 172.22.1.5
09:49:10.034159 arp reply 172.22.1.2 is-at 06:0b:db:a9:0f:d1

Note the mac address that is the correct one:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0B:DB:A9:0F:D1
          inet addr:172.19.1.11  Bcast:172.19.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20b:dbff:fea9:fd1/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:299499 errors:0 dropped:0 overruns:0 frame:0
          TX packets:161893 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22443458 (21.4 MiB)  TX bytes:220560315 (210.3 MiB)
          Base address:0xece0 Memory:fe8e0000-fe900000

eth0.201  Link encap:Ethernet  HWaddr 06:0B:DB:A9:0F:D1
          inet addr:172.22.1.2  Bcast:172.22.1.255  Mask:255.255.255.0
          inet6 addr: fe80::40b:dbff:fea9:fd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:78326 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3923165 (3.7 MiB)  TX bytes:1610 (1.5 KiB)

I'm going to give up... Please if anyone has a suggestion is very welcome.

Thanks,
Normando

>
> Justin
>
> On 24 May 2005, at 12:30, Normando Marcolongo wrote:
>
>> Justin Cormack wrote:
>>
>>
>>>
>>> I think that lots of equipment doesnt like you mixing tagged and   
>>> untagged traffic on the same network.
>>>
>>> If you have to it might help setting the Mac addresses on the two   
>>> interfaces to be different.
>>>
>>>
>> So how can I change the mac on the eth0.201 interface?
>>
>> # ifconfig eth0.201 hw ether 00:0B:DB:A9:1F:D1
>> SIOCSIFHWADDR: Device or resource busy
>>
>> Thanks!!!
>> Normando
>>
>>
>>>
>>> On 24 May 2005, at 11:32, Normando Marcolongo wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> Let me explain the simple architecture here. A linux machine  with  
>>>> kernel 2.6.11.7 (Debian Sarge) and e1000 driver. A Cisco  Catalyst  
>>>> 6509 configured with a trunk port this way:
>>>>
>>>> interface GigabitEthernet4/13
>>>>  switchport
>>>>  switchport trunk native vlan 100
>>>>  switchport trunk allowed vlan 100,201
>>>>  switchport mode trunk
>>>>
>>>> The linux machine has:
>>>>
>>>> # cat /proc/net/vlan/config
>>>> VLAN Dev name    | VLAN ID
>>>> Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
>>>> eth0.201       | 201  | eth0
>>>>
>>>> # ifconfig
>>>> eth0      Link encap:Ethernet  HWaddr 00:0B:DB:A9:0F:D1
>>>>           inet addr:172.19.1.11  Bcast:172.19.1.255  Mask:  
>>>> 255.255.255.0
>>>>           inet6 addr: fe80::20b:dbff:fea9:fd1/64 Scope:Link
>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>           RX packets:49984 errors:0 dropped:0 overruns:0 frame:0
>>>>           TX packets:80330 errors:0 dropped:0 overruns:0 carrier:0
>>>>           collisions:0 txqueuelen:1000
>>>>           RX bytes:4335305 (4.1 MiB)  TX bytes:110105417 (105.0 MiB)
>>>>           Base address:0xece0 Memory:fe8e0000-fe900000
>>>>
>>>> eth0.201  Link encap:Ethernet  HWaddr 00:0B:DB:A9:0F:D1
>>>>           inet addr:172.22.1.2  Bcast:172.22.1.255  Mask: 
>>>> 255.255.255.0
>>>>           inet6 addr: fe80::20b:dbff:fea9:fd1/64 Scope:Link
>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>           RX packets:255 errors:0 dropped:0 overruns:0 frame:0
>>>>           TX packets:361 errors:0 dropped:0 overruns:0 carrier:0
>>>>           collisions:0 txqueuelen:0
>>>>           RX bytes:22471 (21.9 KiB)  TX bytes:21547 (21.0 KiB)
>>>>
>>>> If I put a test client on the VLAN100 the linux machine can ping   
>>>> the 6509's VLAN100 interface and the test client.
>>>> Now, I can ping from the linux machine the VLAN201 interface of  
>>>> the  6509 and (obviuosly) vice versa.
>>>> If I put a test client on the VLAN201 the test client _cannot_   
>>>> resolve the MAC address of the linux machine while the linux   
>>>> machine has this resolved. If I do a tcpdump on the linux machine  
>>>> I  see:
>>>> on the eth0.201 the ARP request from the client _and_ the reply   
>>>> from the linux machine to the client (this will never reach the   
>>>> client for an unknown reason)
>>>> on the eth0 the same (I think I've understood that this is normal)
>>>> putting static ARPs on the server/client solves the problem.
>>>> Can you give me some directions? Need some other information?
>>>>
>>>> Thanks,
>>>> Normando
>>>> -- Normando Marcolongo | Micso s.r.l. via Tiburtina, 318 |  
>>>> I-65128  Pescara, Italy tel/fax (+39)08554105 | mob. (+39)3386296362
>>>> <normando.vcf>
>>>> _______________________________________________
>>>> Vlan mailing list
>>>> [email protected]
>>>> http://www.lanforge.com/mailman/listinfo/vlan
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Vlan mailing list
>>> [email protected]
>>> http://www.lanforge.com/mailman/listinfo/vlan
>>>
>>>
>>>
>>>
>>
>>
>> -- 
>>  Normando Marcolongo | Micso s.r.l.
>>   via Tiburtina, 318 | I-65128 Pescara, Italy
>> tel/fax (+39)08554105 | mob. (+39)3386296362
>>
>>
>> <normando.vcf>
>> _______________________________________________
>> Vlan mailing list
>> [email protected]
>> http://www.lanforge.com/mailman/listinfo/vlan
>>
>
> _______________________________________________
> Vlan mailing list
> [email protected]
> http://www.lanforge.com/mailman/listinfo/vlan
>
>
>


-- 
  Normando Marcolongo | Micso s.r.l.
   via Tiburtina, 318 | I-65128 Pescara, Italy
tel/fax (+39)08554105 | mob. (+39)3386296362

_______________________________________________
Vlan mailing list
[email protected]
http://www.lanforge.com/mailman/listinfo/vlan
normando.vcf (text/x-vcard, 312 B)
begin:vcard
fn:Normando Marcolongo
n:Marcolongo;Normando
org:Micso s.r.l.;System & Network Engineer
adr:;;via Tiburtina, 318;Pescara;;65128;Italy
email;internet:[email protected]
tel;work:+3908554105
tel;fax:+3908554105
tel;cell:+393386296362
x-mozilla-html:FALSE
url:http://www.micso.com
version:2.1
end:vcard
smime.p7s (application/x-pkcs7-signature, 3.2 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.