Subnet masks? In English? Anybody?

It looked like you had the helm, so I was thinkin' you had this fingered out. It seems that you're getting confused with the host machine network ID and the VM. I don't know why you decided to mess around with class A addressing, although you can use it for LAN network IDs. You really shoudl stick with the default class C address/subnet schema until you truly get how subnetting works. Then you can go with CIDR and whatever network ID class floats your boat.

If you use a network mask of 255.255.255.0, then a total of 254 host ID's are addressable on any arbitrary network using the last octet. A subnet utilizes the mathematical bitwise operator AND. For the default private class C addressing scheme, any network ID that is returned after the subnet mask bitwise AND operator 255.255.255 that equals 192.168.0 is on the same network; any OTHER network ID will be a different network and will require a router to handle the packets addressed to it.

For example, 192.168.1 is on a different network than 192.168.0. If the subnet mask implemented is 255.255.255.0, then 254 hosts can exist on each of 254 seperate networks. A packet addressed to 192.168.1.10 from any host on network 192.168.0 gets sent by the router (192.168.0.1) to the router handling that network, i.e. 192.168.1.1. 192.168.0.1 knows to do that, because 192.168.1.10 is not in his domain.

If I utlize subnet mask 255.255.255.248, then I have 6 hosts avaialable on each of 8190 networks. I can use class A addressing of 10.10.10 if I'd like, but the last octet is tricky because its sharing network ID & host ID simultaneously. 248 translates to 11111000. And so any combination of 1 or 0 for the first 5 bits are available for network ID, while only the last three bits are avaialable for host ID.

2⁸ bits translates to 256 combinations. However, 0 (all bits in the octet off) is reserved for the network address, and 255 (all bits in the octet on) is reserved for the broadcast address; two network IDs for each network are unuseable.

Your VM host machine has network ID of 192.168.0.70. That is the real network ID for the network adapter (NIC). The VM itself is configured with a virtual network adapter having a network address of 192.168.0.100. The VM should be able to ping itself, 127.0.0.1 (or 0.0.0.0), as the local loopback address. It should also be able to see 192.168.0.70 without any issues.

Any other host on the network, including the router, e.g., 192.168.0.1, should be able to see 192.168.0.70. However, NOBODY else is going to know what 192.168.0.100 is; as far as they're concerned it doesn't exist. Depending on how you configure the VM, will depend on the network resources available to 192.168.0.100.

When you use "host-only networking" on the VM, a network connection between the virtual machine and the host computer, using a virtual Ethernet adapter that is visible to the host operating system. This approach can be useful if you need to set up an isolated virtual network.

If you use host-only networking, your virtual machine and the host virtual adapter are connected to a private TCP/IP network. Addresses on this network are provided by the VMware DHCP server.

If you want to connect to the Internet or other TCP/IP network using the host computer’s dial-up networking or broadband connection and you are not able to give your virtual machine an IP address on the external network, NAT is often the easiest way to give your virtual machine access to that network. However your virtual machine will not have its own IP address on the external network when implementing NAT on the VM. Instead, a separate private network is set up on the host computer. Your virtual machine gets an address on that network from the VMware virtual DHCP server. The VMware NAT device passes network data between one or more virtual machines and the external network. It identifies incoming data packets intended for each virtual machine and sends them to the correct destination.

Bridged networking is often the easiest way to give your virtual machine access to the network when your host computer is on an Ethernet network. On a Windows host, you can use bridged networking to connect to either a wired or a wireless network. On a Linux host, you can use bridged networking to connect to a wired network.

If you use bridged networking, your virtual machine needs to have its own identity on the network. For example, on a TCP/IP network, the virtual machine needs its own IP address. Your network administrator can tell you whether IP addresses are available for your virtual machine and what networking settings you should use in the guest operating system. Generally, your guest operating system can acquire an IP address and other network details automatically from a DHCP server. You might need to set the IP address and other details manually in the guest operating system.

Using bridged networking enables the virtual machine to be a full participant in the network. It has access to other machines on the network and can be contacted by other machines on the network as if it were a physical computer on the network.

If the host computer is set up to boot multiple operating systems and you run one or more of them in virtual machines, you need to configure each operating system with a unique network address. People who boot multiple operating systems often assign all systems the same address, since they assume only one operating system will run at a time. If you use one or more of the operating systems in a virtual machine, this assumption is no longer true.

Changing the Networking Configuration in a VM

Thanks.
A comprehensive and informative reply.

I think part of my issue may be hampered by the fact I am using win2K.

By default, win2k doesn’t do any of the software routing stuff. I went in and REGEDIT’d it so that IPEnableRouting is turned on.

But there is another part, one of the system services a routing snapin of sorts, that I can’t find a clue out about how to actually USE it, I turned it on using Admin Tools, but can’t find any way how to tweak the settings once it’s started.

My idea has always been:

Machine A is 192.168.0.70 and runs VM 192.168.0.100
Machine B is 192.168.0.66 and can ping 192.168.0.70 quite ok.
Making NO CHANGES, I cannot ping 192.168.0.100 from machine B.

If I do this on B:

Route Add 192.168.0.100 mask 255.255.255.0 192.168.0.70

then does that not mean if I do a PING from machine B to 192.168.0.100, he knows enough to send it to 192.168.0.70

What does 192.168.0.70 do with it? I am assuming he at least looks at it and says, hey, this is for somebody else, not me... does he trash it without routing turned on? I added 192.168.0.100 to the routing table on 192.168.0.70 but it still didn’t get there, and I can only assume it’s because machine A doesn’t have all the router snapin stuff set up to serve as a router. Leave it to Microsoft to put in like 12 options that seem to possibly conflict with each other or override...

Anyways, thanks, if you have any ideas about what I just described, lemme know. I searched the internet far and wide and still couldn’t find out how to use that dm snapin thingie!

I don't understand why you're trying to do routing on the VM host; the VMWare server handles that (apart from the host O/S). The host O/S has nothing to do with that (other than providing driver level interface to the VM for virtual hardware that it's interfacing to).

The class C address 192.168.0 with subnet mask of 255.255.255.0 will yield 254 host ID's on that network ID; 0 and 256 are reserved for network & broadcast IP addressing. The host ID's run from 1 through 255; given that host ID 1 is reserved (by convention) for the gateway, 192.168.0.100 is a legit host ID on the network 192.168.0.0.

I don't know what, if anything, intrinsic Win2k IP routing capability has to do with anything here. You're trying to implement NAT with the ROUTE command (that's just not right). Fundamentally all IP addresses boil down to MAC addressing. It doesn't matter how the IP addresses are assigned to particular nodes, i.e., APIPA, DHCP or static. What matters is that the gateway is aware of the nodes that exist on the network its serving. In most cases VM hosts will support multiple vm’s; this is especially true when running VM's on a laptop (where each vm needs a unique IP address on any arbitrary LAN). Given that laptops are portable, it is very desirable that a vmware network setup should have several key features:

All vm’s can communicate with each other
All vm’s can communicate with “host” OS
Host OS can communicate with “guest” vm’s
All vm’s can communicate with WAN (“internet”)
All vm’s IP’s can be resolved from WAN
All vm’s can resolve IP’s on the WAN.
X-windows can be launched from the vm’s
Above features are preserved on any external subnet hosting laptop hardware
Users at a client site ("foreign" subnet) should be able to connect remotely to your virtual network from their own desktops using, for example, Putty.

The means whereby the foregoing can be accomplished is via implementation of one of the following:

Bridged networking — Although bridged virtual machines use the physical network connections on the host system, each virtual machine is treated as an independent client on the network. As such it will obtain an IP address from the network's DHCP server, or will require a static IP address to be manually configured if DHCP is not used. Virtual machines using bridged networking will be able to communicate directly with both the host system and other clients on the network to which the host is connected.
Network address translation (NAT) — One or more virtual machines share the IP and MAC address of the host system for the purposes of communicating with the external network. Virtual machines are able to communicate with other clients on the network to which the host is connected, but will appear to those clients as the host system, rather than as individual network clients. This approach allows multiple virtual machines to operate using a single IP address. IP addresses are allocated dynamically to NAT based virtual machines by VMware Server's internal DHCP server. Communication with the external network can only be established by the virtual machine. It is not, therefore, possible for a client on the external network to initiate a connection with a NAT based virtual machine (although port forwarding may be configured to allow traffic to a particular port, such as HTTP traffic on port 80, to be directed to a specific virtual machine).
Host-only networking - Creates a private sub-net within the host for virtual machines for which no external network access is required or desired. Virtual machines configured with host-only networking can communicate directly only with the host system and virtual machines which are also members of the same host-only network. The virtual machines cannot, however, communicate with the network to which the host is connected. IP addresses are allocated to Host-only based virtual machines by VMware Server's internal DHCP server.

[source: VMware Server Virtual Network Architecture]

When a VM comes on-line, it needs to either obtain an IP address from somewhere, i.e., either static, or dynamically via APIPA or DHCP. DHCP can be either a dedicated server to that end, or a functionality of the router. Former case and latter case there is no negotiation; the IP is either declared by the node (static) or assigned to it (DHCP). In the case of APIPA there is negotiation between the gateway and the node until a unique network ID is established. It doesn't matter how the VM gets its unique IP address, but the VM must utilize one of the three aforementioned networking methods.

VMware Server networking 101

I ONLY want answers to my questions, as posed.

I NEED TO KNOW how Windows handles a packet if it gets plunked on his lap but he realizes it’s not for him.

Thanks, but I am not trying to set up some network so perfect my name would go down in history for it, and me, myself, and I am the ONLY user.

In answer to your question, what does windows do when a packet is not addressed to it? It simply drops the packet. If the node you are send to is not on your network, the packet eventually expires.

If you're the only user, why are you trying to complicate things by creating a second network? Keep everything on 192.168.0.x Most things appear to work, it's only the communication between your host adapter and the virtual application, whatever the hell that is, that isn't working.

Also, put out of your mind that we are talking about VMWARE in any way. What I will say is it is a “virtual machine” type application that the host communicates with through TUN/TAP.

Ok, so you want everyone to shoot in the dark troubleshooting YOUR mysterious "virtual machine" type application, and then you get all testy by telling us to "put it out of your minds". You might want to rethink that approach when asking for help.

Everything between the host and the virtual machine works perfect, I can FTP, I can TELNET, I can PING, I can see all of the virtual machines TCPIP ports from the host. But I cannot see the virtual machine from any other machine on the same network as the host.

You can pull your ethernet cable, and ping yourself all day long.

You may just be out of luck with that mysterious application on W2K. By virtue of you mentioning TUN/TAP almost as an afterthought, it sounds as though you need a bridge to gap the two adapters for Tunneling, and that doesn't work very nicely under Windows 2000.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.