Jonathan Johnson
2005-Mar-29 01:49 UTC
[Samba] Browsing with duplicate names in multiple workgroups/subnets and multihome machines
You can see by the subject I've got an ugly problem. Even though I don't have a Samba server anywhere near the network in question, nobody understands browsing as well as the folks on the Samba team. :-) Here's the situation: I've got two workgroups, FLINTSTONE and RUBBLE which are on physically separate networks. FLINTSTONE has a Windows 2003 Active Directory domain controller; RUBBLE is a simple workgroup. All workstations are either Windows 2000 or Windows XP Professional. There is no routing between these networks. However, there are two workstations which are multihomed. More on that in a minute. Here's the logic (illogic?) of the network: Segment 1: * FLINTSTONE domain * PEBBLES (Windows 2003 Small Business Server Active Directory domain controller) * FRED Windows XP Pro workstation (multi-homed to Segment 2, member of FLINTSTONE) * WILMA Windows XP Pro workstation (also multi-homed to Segment 2, member of FLINTSTONE) Segment 2: * RUBBLE workgroup * BETTY Windows 2000 Pro workstation (single-homed, member of RUBBLE) * BARNEY Windows 2000 Pro workstation (single-homed, member of RUBBLE) * FLINTSTONE Windows 2000 Pro workstation (single-homed, member of RUBBLE) The reason that FRED and WILMA are multi-homed is that they both must be able to access the workstations in the RUBBLE workgroup on Segment 2. As you can see, we've got a name conflict: a workstation named the same as the domain. This is, apparently, causing browsing problems for the multi-homed workstations. Unfortunately, it's not as simple as renaming the FLINTSTONE workstation to BAM-BAM. This network on Segment 2 was set up by another vendor (who, we might add, seems to be rather clueless about Windows networking), and they are afraid to change the name for fear of what it would break. That vendors requirements do not allow routing to other networks. This network is the automation system for a radio station, and "it cannot go down." The domain of Segment 1 cannot be changed, as Small Business Server doesn't allow that. At this point, I'm not really seeking solutions, but perhaps a technical explanation of what might go on in this situation. Even if there were no naming conflicts, what are the implications of having two multi-homed non-routing Windows machines on common networks? --Jonathan Johnson Sutinen Consulting, Inc. www.sutinen.com
Thomas M. Skeren III
2005-Mar-29 02:24 UTC
[Samba] Browsing with duplicate names in multiple workgroups/subnets and multihome machines
Jonathan Johnson wrote:> You can see by the subject I've got an ugly problem. Even though I > don't have a Samba server anywhere near the network in question, > nobody understands browsing as well as the folks on the Samba team. :-) > > Here's the situation: I've got two workgroups, FLINTSTONE and RUBBLE > which are on physically separate networks. FLINTSTONE has a Windows > 2003 Active Directory domain controller; RUBBLE is a simple workgroup. > All workstations are either Windows 2000 or Windows XP Professional. > There is no routing between these networks. However, there are two > workstations which are multihomed. More on that in a minute. > > Here's the logic (illogic?) of the network: > > Segment 1: > * FLINTSTONE domain > * PEBBLES (Windows 2003 Small Business Server Active Directory domain > controller) > * FRED Windows XP Pro workstation (multi-homed to Segment 2, member of > FLINTSTONE) > * WILMA Windows XP Pro workstation (also multi-homed to Segment 2, > member of FLINTSTONE) > > Segment 2: > * RUBBLE workgroup > * BETTY Windows 2000 Pro workstation (single-homed, member of RUBBLE) > * BARNEY Windows 2000 Pro workstation (single-homed, member of RUBBLE) > * FLINTSTONE Windows 2000 Pro workstation (single-homed, member of > RUBBLE) > > The reason that FRED and WILMA are multi-homed is that they both must > be able to access the workstations in the RUBBLE workgroup on Segment > 2. As you can see, we've got a name conflict: a workstation named the > same as the domain. This is, apparently, causing browsing problems for > the multi-homed workstations. > > Unfortunately, it's not as simple as renaming the FLINTSTONE > workstation to BAM-BAM. This network on Segment 2 was set up by > another vendor (who, we might add, seems to be rather clueless about > Windows networking), and they are afraid to change the name for fear > of what it would break. That vendors requirements do not allow routing > to other networks. This network is the automation system for a radio > station, and "it cannot go down." The domain of Segment 1 cannot be > changed, as Small Business Server doesn't allow that. > > At this point, I'm not really seeking solutions, but perhaps a > technical explanation of what might go on in this situation. Even if > there were no naming conflicts, what are the implications of having > two multi-homed non-routing Windows machines on common networks?Hmm it's a pickle. Try resolving netbios via DNS for the W2k3 domain and WINS for the other. That's where I'd start poking around. I have something of a similar problem on my VLAN. I inherited a server named server that's w2k SBS with w2k pro server on another node named server. They have different domains. I use bind9 and have both servers use it on the vlan, but the inherited domain uses a different WINS (itself) as do the clients. When I join machines to the inherited domain over the VLAN I use the FQDN of that domain and set WINS manually. I haven't had any conflicts yet. The reason for allowing this is that the office my company acquired leased the computers in the office. The lease ends in August. I have reccommened returning the equipment, so I need to limp along until then. But it works. Something like this might work for you. Dunno for sure.> > --Jonathan Johnson > Sutinen Consulting, Inc. > www.sutinen.com >
Possibly Parallel Threads
- why is dovecot "Allowing any password"
- BUG? 'valid users' doesn't allow groups from trusted domains
- why is dovecot "Allowing any password"
- INVITE from DID: No matching endpoint found but completes the call anyway
- what do you think about write.table(... qmethod = "excel")?