[Nottingham] NIC MACs aliases & IP aliases

Martin martin at ml1.co.uk
Thu May 14 16:46:31 UTC 2009

Martin wrote:
> OK folks,
> likely a rather silly question...
> Just as you can have IP aliases for a NIC...
> Can multiple MACs be spoofed for a single NIC?
> For example, can one NIC port be made to appear to be multiple physical 
> ports to a network switch?

Well, well, well,...

In this instance, it really does look like it can't be done with linux!

(No firewalling enabled throughout the tests.)

 From my experimenting, all I ever get is the MAC of the eth0 interface 
being used. Hence you at best can get IP aliases on the one MAC. This is 
no good if you want to acquire multiple IPs from DHCP by giving multiple 
MACs to a DHCP server.

(Use Time Division Multiplexing of MACs on the one interface as a 
workaround?! :-p OK, so that still wouldn't work...)

It looks like the linux bridging code must make the assumption that you 
only ever would want to bridge real eth devices and nothing else...

So... I've tried:

eth0 --- br0 --- tap0

eth0 --- br0 --- tap0 --- vde_switch --- tap1

eth0 --- br0 --- tap0 --- vde_switch --- tap1 --- br1

You can't join multiple bridges. Also tun (rather than tap) doesn't work 

Anyone with any further ideas? Tricks via loopback??

However, this comment appears to be a killer and fits with what I've 
found by experimenting:

[LARTC] Proxy Arp question

Here's what I believe proxy_arp does.
If anyone knows better please send corrections.

When an arp request arrives on an interface, if proxy_arp is OFF at
that interface, then we reply only if it asks who has an IP address
assigned to that interface.  In that case we reply that this IP
address is at the MAC address of the receiving interface.

If, however, proxy_arp is ON at that interface, then we check the
routing table (here things get a little fuzzy, since in reality the
routing can depend on all sorts of things other than the destination
address, and the arp request isn't specifying any of those) to find
out, if we were sending a packet to that IP address, which interface
we would use to send it out.  If there is such an interface (we do
have a route to that address) and it's NOT the same one that the
request arrived on, then we reply with the MAC address of the
interface on which the request arrived.

And indeed, from my network gateway machine, all "arp -e" would ever 
show would be the test machine's eth0 MAC. Indeed, ifconfig lists the 
same MAC for both br0 and eth0. Interestingly, the same MAC was shown 
for br1 and tap1. tap0 would have it's own separate MAC.

Further associated links:



Very interesting stuff and good fun but still no beer :-(

Help? Ideas?


Martin Lomas
martin at ml1.co.uk

More information about the Nottingham mailing list