[Nottingham] NIC MACs aliases & IP aliases

[Martin]

A summary of the multimac and tap fun thus far:

[---]
>>> http://www.primianotucci.com/default.php?view=57
>> Well... This one is proving to be a strange one indeed.
[---]
>>
>> Sending out data through one of the tap interfaces gives the MAC address 
>> of that tap. Yea, it works!!!
>>
>> Pinging from externally the IP address of whichever tap also works, so 
>> all looks good.
>>
>> BUT... "arp -e" still stubbornly lists the same one eth0/br0 MAC address 
>> for all the host IPs. [On a remote host.]
>>
>> Also, there are "martian source" in the log for all the tap interfaces 
>> except tap0.
>>
>> ifconfig shows that each tap has it's own unique MAC.
>>
>>
>> Sooo... It /might/ be working although the arp table is still not 
>> listing the expected MACs. [On a remote host.]
>>
>> Anyone with any ideas?
> 
> OK, so playing with:
> 
> # arp_accept
> # arp_announce
> # arp_filter
> # arp_ignore
> # forwarding
> # proxy_arp

[---]

> The various comments on:
> 
> http://www.linuxinsight.com/proc_sys_net_ipv4_conf_eth0.html
> 
> suggests the default behaviour that I've seen for the defaults. (See the 
> arp_announce and arp_ignore.)
> 
> So what is the magic combination of settings to get proxy_arp (and/or 
> whatever else is needed) to work transparently across eth0 -- br0 -- 
> tap0 so that the other taps become visible to a remote machine. Or is 
> the MAC address of the eth0 actually the correct one to give for return 
> packets?
> 
> 
> To summarise:
> 
> eth0 -- br0 -- tap0 -- ( tap1 tap2 tap3 tap4 tap5 )
> 
> Outgoing packets via tap[1-5] show the MAC of the respective tap interface.
> 
> However, on a remote machine, the IP addresses of tap[1-5] have the MAC 
> of eth0/br0 in that host's arp table.

Indeed, it looks like the taps can receive arp requests and ping 
requests from the outside, but do not respond to them unless you have 
some code running listening on the tap to make the response.

So that leaves it that you can have outgoing unique IP + unique MAC 
(going via the br0 connection), but for incoming you must use proxy_arp 
to give the eth0 MAC for the return packets (and ip_forward to connect 
through to the tap ip via the kernel?).

So... I guess that makes the setup look more like a router but with no 
NAT...


> Or do I not need the remote host arp table to list unique MACs to still 
> gain multiple DHCP addresses for the one host? Are the unique source 
> MACs enough to work ok?

I'm thinking that I shouldn't be using proxy_arp (and ip_forwarding) to 
be able to have all this to work as intended...


> But then, there's still the question of how to get the eth0 -- br0 -- 
> tap0 to appear transparent just like a true network switch...

Is there a "arp & ping response" utility that I can attach to a tap to try?


Anyone with any insight?

Cheers,
Martin

-- 
----------------
Martin Lomas
martin at ml1.co.uk
----------------