From: Jeff D. <jd...@ka...> - 2000-04-30 17:42:46
|
gbr...@mi... said: > This doesn't actually work for protocols other than IP. You can't > send such things as AppleTalk over the SLIP link. Why not? That's a real good reason to switch to ethertap, but I'd still like to know what about slip makes it impossible to encapsulate things like appletalk. > You cannot bridge ethernet traffic onto a SLIP link. The point is raw > ethernet frames are reproduced onto the other side of the bridge, > which is impossible over SLIP because you are limited to IP traffic > and lose the lower layer of information. But if it were possible to pass arbitrary protocols over slip, you don't care whether or not you can pass ethernet frames over it. > If there are say 4 UML sessions running on a single machine, you would > need 4 separate SLIP connections and individual routes for each of > them to get them visible to the outside world. You'd make one uml the gateway to the outside world, give it a connection to the host, and set up routes on the others to it. > With the solution I'm talking about, you would simply need to setup > uml-net with the ethertap device on the host machine, and setup a > bridge between eth0 and tap0. Now every UML which is using uml-net > can simply configure its eth0 as if it were on the host's ethernet > directly. I agree that that's pretty slick. Would all the packets on the ethernet flow through the bridge? If so, I think that would make it look like all the umls really were on the physical ethernet. The problem I have is the combining of virtually networking umls and connecting them to the host. Those seem to me to belong in separate drivers. On a physical machine, if you have a local ethernet and a connection to an outside network, those are different devices and probably different drivers. Without a good reason to put them in the same driver, I'd like to mimic the physical world as much as possible. Jeff |