Up to now, I've always configured my laptop with a wired and wireless interface, each of them being offered a different IP address from DHCP, and each of those IP addresses resolving to different host names. This has always felt kludgey but worked.
Our sysadmins made a configuration that for practical reasons doesn't work, which involves linking the same IP address to the two different MAC's. It doesn't work practically because of the tool they use to do so, but googling for this configuration tells me that this can in fact work.
I've also found posts that indicate that Windows wouldn't accept two interfaces having the same IP.
So, what are the best practices here, and the pros and cons of each approach ? In my particular case, I run Fedora Linux on the laptop. It sounds like using the same IP for both NIC's is in fact a nicer solution, since I would have the same hostname regardless of how I'm connected.
This isn't entirely clear but for arguments sake lets start with the premise that you are only going to be using 1 interface at a time, such that you will never have the same IP assigned and active at the same time on two different mac addresses. This will not work (at least not in the traditional meaning of the word work). Similarly they have to be the same subnet, obviously if the wireless and wired networks are on different subnets the same IP allocation cannot work.
If both the wired and wireless networks export the same subnet then its relatively trivial to bring up that particular interface with the same IP, DHCP has no restriction preventing the same IP being doled out to two different mac addresses (although it would specifically have to be configured in the dhcp configuration) to do so. If a particular address is reserved for you there is also no reason why you couldn't statically bring it up as necessary in a manual configuration for each network.
The biggest problem I've found with having the same host name resolve to two ip addresses on the same subnet is from the administration side. When querying DNS or WINS (on a MS Domain) the name resolves to just one of the IPs. From what I can tell, it resolves to the one that was handed out most recently. Thus it can change if, for instance, your computer updates (via DHCP, for instance) what was the "secondary" connection after the "primary".
Here is a real-world example that happens regularly on my network. A user has a laptop with dual connections, wired and wireless. I can admin the PC and various network browser and discovery tools find it at a particular address. Then the wireless card renews its info. The DNS cache on my PC shows it at a different address than the network believes it to be, since queries only return the latest name/IP combination. WINS shows it as having two names/IPs as well. You'd think it would still work, but instead I get timeouts and "RPC server not found" when running some admin tasks on the remote computer.
I have to do some digging in DNS/DHCP/WINS to find the dual addresses with the same name and then connect via IP instead of name. In addition, the wireless connection is often firewalled (if running Windows) whereas the wired connection is not, per group policy, while the computer is logged into the domain (no worries, it will firewall it if not on the domain).
All this causes problems when trying to connect to the desired computer FROM THE OUTSIDE. From the laptop itself, everything seems to work okay. The metric for the two connections keeps it using the "preferred" network connection (typically the wired one, which is usually faster).
The problem is with trying to connect/admin/discover the computer from the outside.
My Dell laptops have a nice utility that disables the wireless when connected via wire and disables the wired connection when on battery, thus eliminating the issue.
If you don't have a setup like Mgotts' where the wireless NIC is disabled when the wired NIC is connected, or a convenient way (airplane switch) to disable the wireless NIC manually, some operating systems may refuse to accept the address on the second NIC if they do an ARP check to ensure the IP is available and reply to themselves (there seem to be some cases where Windows XP confuses itself in this way).
There is another disadvantage of the same-IP setup for both wireless and wired NICs (if you don't explicitly manage things so that only one NIC is active at a time). When other systems ARP for the IP, they can get replies from both the wireless and wired NICs. In that case, it is a toss-up which MAC address they will select (and the odds may be in favor of the slower one that comes in second). As a result, even if you set up your routing to prefer the faster wired NIC (easiest to do on MacOS X, but possible on other systems too) the return traffic from other systems may be sent to your wireless NIC anyhow. And if you do manage things so that only one NIC is active at a time, you may experience a "glitch" for a few seconds when you switch over, while other systems still have the other MAC address in their ARP tables.
(Speaking of managing the two NICs so that only one is active - there is a MacOS X Hints posting with several versions of a script for doing this entirely automatically.)
One of the biggest advantage of the same-IP setup is that existing TCP or VPN connections will keep working even after you switch from one interface to the other. If you are just doing web stuff this may not matter so much, since in the different-IP setup your browser will recreate connections transparently (and on the web server side, it won't even see an IP change if your firewall NATs both to the same external IP). But if you use a VPN or SSH connections, not having to re-establish those connections is very convenient.
The trickiest part of configuring the same-IP setup may be getting your DHCP server to accept it; at least some versions of DD-WRT don't allow it, and DNSmasq DHCP servers require you to do it in a particular way - from personal experience I can say that OpenWRT will let you set it up, but then the DNSmasq DNS/DHCP server won't start. A related ServerFault question discusses what you need to do to make it work for Windows 2003 DHCP server. As noted there, it may be necessary to force the same MAC address on the two NICs (depending on the hardware and OS, you may need to clone the wireless MAC onto the wired NIC).
Using the same MAC address for both NICs may also be useful to mitigate the "glitch" mentioned above due to stale ARP table entries on other systems, and allows you to get the same-IP setup even if you don't have control of the DHCP server (e.g. at your workplace). There is some precedent for setting the same MAC on all the NICs of a system - old DEC systems did this, and Sun/Solaris systems may still. There are some gotchas about doing this, which is probably why most systems don't do this.
If your wireless AP or switches have implemented port security options, you may find the MAC blocked out on one or the other NIC, and in a large bridged network with multiple switches, the "glitch" for connections with a system that is distant may be worse unless your laptop is actively sending traffic (broadcast or multicast traffic will do) through all intermediate switches so that they update their forwarding tables and traffic to the shared MAC address goes to the currently active NIC.
Using the same MAC address for both NICs may also be necessary to get the same IP address if you are using IPv6, which generally doesn't use DHCP, but embeds the MAC address in the low 64-bits (host part) of the IPv6 address.