Synchronized browsing

[Avantel Systems]

Yes, that describes the problem although I have more experience with the =
case
where there are 3 different and unique workgroups involved (assuming the =
same
example as you describe).  The workgroups could be FOO,  BAR  and URQ as =
long as
there was a samba server configured to be a DMB on both LANs (one for FOO=
 and
one for BAR) - the same behaviour as you describe would still occur when
those browse lists are synchronized. =20

Alex Vandenham
Avantel Systems
Ottawa, Ontario, Canada

On Mon, 01 Jan 2001, Christopher R. Hertel wrote:
> Alex Vandenham raised a question that I find interesting.  Here, if I=20
> have it right, is the scenario:
>=20
>   Lan1 =20
>  |----------+---------------+--|
>             |               |
>         [LMB: FOO]       [Router]
>   Lan2                      |
>  |------+-----------+-------+--|
>         |           |
>     [LMB: FOO]  [LMB: URQ]
>=20
> That is, Lan1 has a workgroup named FOO.  Lan2 also has a workgroup nam=
ed=20
> FOO as well as a workgroup named URQ.
>=20
> Now add a Domain Master Browser and a WINS server to the above.  They c=
an
> go anywhere.  It doesn't matter where they reside.  The DMB is for=20
> ntdomain FOO, thus promoting both FOO workgroups to the status of a=20
> single ntdomain.
>=20
>   Lan1 =20
>  |----------+---------------+--|       [DMB:FOO]
>             |               |              |
>         [LMB:FOO]        [Router]---+------+--|
>   Lan2                      |       |
>  |------+-----------+-------+--|  [WINS]
>         |           |
>     [LMB:FOO]   [LMB:URQ]
>=20
> Here's what happens:
>=20
> On Lan2, LMB:FOO knows about workgroup URQ, and lists the existance of=20
> workgroup URQ in its browse list.  It eventually forwards that list to=20
> DMB:FOO.  DMB:FOO, in turn, eventually forwards the combinded list to t=
he=20
> *other* LMB:FOO on Lan1.
>=20
> So, Lan1's LMB:FOO now knows about workgroup URQ.
>=20
> Unfortunately, since WINS does not register #1D names, there is no way=20
> for a client on Lan1 to *find* LMB:URQ, even though it knows about LMB:=
URQ.
> Indeed, the Get Backup List Request for a workgroup is sent to the=20
> broadcast address on the apparent assumption that only the local=20
> <workgroup>#1D system will respond.
>=20
> If a client on Lan1 could find LMB:URQ, it could send a unicast message=
 to
> get the backup list, but that's simply not how it works.  My guess is t=
hat
> the idea of combining workgroups and ntdomains was not considered a goo=
d
> one when this was all being designed.=20
>=20
> I would love to see some traces of this stuff.  I'm curious to know if =
the
> client on Lan1 would try sending the query on to a DMB if it could not
> find the LMB for the missing workgroup.  My guess is that no DMB is eve=
r
> consulted.=20
>=20
> I hope, Alex, that I have done a good job of describing the problem.  L=
et=20
> me know if I'm close.
>=20
> Chris -)-----
>=20
> --=20
> Christopher R. Hertel -)-----                   University of Minnesota
> crh at nts.umn.edu              Networking and Telecommunications Services
>=20
>     Ideals are like stars; you will not succeed in touching them
>     with your hands...you choose them as your guides, and following
>     them you will reach your destiny.  --Carl Schultz