On Sunday, 2009-03-01 21:50:24 Johnny Billquist wrote: The one limitation is that it is usually problematic to have the same machine that is running the bridge also participate as a DECnet node on the same interface. Because then you need to see all your own outgoing packets. Not all hardware will do that for you. So, if you try to run in one machine, with hardware that can't see its own packets, then you need 3 interfaces, 1: To talk TCP/IP / UDP for main interface plus UDP side of bridge 2: DECnet side of bridge 3: DECnet speaking software or a machine with only one interface running the bridge program, and a machine with two interfaces, one for TCP/IP/UDP and one DECnet. Or have I still misunderstood? You're making things over-complex. I can't ever imagine a scenario in which you need more than two interfaces. In your first example above, 1 and 2 can be on the same interface with no problems. The only time you even need more than one interface is if the machine running the bridge program is itself also a DECnet node, in which case the machines own DECnet traffic can't be on the same interface as the bridge is capturing DECnet traffic. All other stuff can be shared on any of the interfaces. In short. bridge can coexist with any TCP/IP traffic. DECnet can coexist with any TCP/IP traffic. bridge and DECnet can't coexist. And in all of these sentences I'm talking about that specific machines protocols/applications running. It is not relevant if another machine talks DECnet when we're talking about the bridge program. The bridge program is not a DECnet program, and should not be confused with them. The bridge is just a cable extension. A repeater. A hub. Johnny