Consider a network set up as follows :
(DMB)
N1_A N1_B N1_C N1_D N1_E
| | | | |
-------------------------------------------------------
| subnet 1 |
+---+ +---+
|R1 | Router 1 Router 2 |R2 |
+---+ +---+
| |
| subnet 2 subnet 3 |
-------------------------- ------------------------------------
| | | | | | | |
N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D
(WINS)
Consisting of 3 subnets (1, 2, 3) conneted by two routers (R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume for the moment that all these machines are configured to be in the same workgroup (for simplicities sake). Machine N1_C on subnet 1 is configured as Domain Master Browser (ie. it will collate the browse lists for the workgroup). Machine N2_D is configured as WINS server and all the other machines are configured to register their NetBIOS names with it.
As all these machines are booted up, elections for master browsers will take place on each of the three subnets. Assume that machine N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on subnet 3 - these machines are known as local master browsers for their particular subnet. N1_C has an advantage in winning as the local master browser on subnet 1 as it is set up as Domain Master Browser.
On each of the three networks, machines that are configured to offer sharing services will broadcast that they are offering these services. The local master browser on each subnet will receive these broadcasts and keep a record of the fact that the machine is offering a service. This list of records is the basis of the browse list. For this case, assume that all the machines are configured to offer services so all machines will be on the browse list.
For each network, the local master browser on that network is considered 'authoritative' for all the names it receives via local broadcast. This is because a machine seen by the local master browser via a local broadcast must be on the same network as the local master browser and thus is a 'trusted' and 'verifiable' resource. Machines on other networks that the local master browsers learn about when collating their browse lists have not been directly seen - these records are called 'non-authoritative'.
At this point the browse lists look as follows (these are the machines you would see in your network neighborhood if you looked in it on a particular network right now).
| Subnet | Browse Master | List |
|---|---|---|
| Subnet1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E |
| Subnet2 | N2_B | N2_A, N2_B, N2_C, N2_D |
| Subnet3 | N3_D | N3_A, N3_B, N3_C, N3_D |
Note that at this point all the subnets are separate, no machine is seen across any of the subnets.
Now examine subnet 2. As soon as N2_B has become the local master browser it looks for a Domain master browser to synchronize its browse list with. It does this by querying the WINS server (N2_D) for the IP address associated with the NetBIOS name WORKGROUP<1b>. This name was registerd by the Domain master browser (N1_C) with the WINS server as soon as it was booted.
Once N2_B knows the address of the Domain master browser it tells it that is the local master browser for subnet 2 by sending a MasterAnnouncement packet as a UDP port 138 packet. It then synchronizes with it by doing a NetServerEnum2 call. This tells the Domain Master Browser to send it all the server names it knows about. Once the domain master browser receives the MasterAnnouncement packet it schedules a synchronization request to the sender of that packet. After both synchronizations are done the browse lists look like :
| Subnet | Browse Master | List |
|---|---|---|
| Subnet1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
| Subnet2 | N2_B | N2_A, N2_B, N2_C, N2_D N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) |
| Subnet3 | N3_D | N3_A, N3_B, N3_C, N3_D |
At this point users looking in their network neighborhood on subnets 1 or 2 will see all the servers on both, users on subnet 3 will still only see the servers on their own subnet.
The same sequence of events that occured for N2_B now occurs for the local master browser on subnet 3 (N3_D). When it synchronizes browse lists with the domain master browser (N1_A) it gets both the server entries on subnet 1, and those on subnet 2. After N3_D has synchronized with N1_C and vica-versa the browse lists look like.
| Subnet | Browse Master | List |
|---|---|---|
| Subnet1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
| Subnet2 | N2_B | N2_A, N2_B, N2_C, N2_D N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) |
| Subnet3 | N3_D | N3_A, N3_B, N3_C, N3_D N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
Servers with a (*) after them are non-authoritative names.
At this point users looking in their network neighborhood on subnets 1 or 3 will see all the servers on all sunbets, users on subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
Finally, the local master browser for subnet 2 (N2_B) will sync again with the domain master browser (N1_C) and will recieve the missing server entries. Finally - and as a steady state (if no machines are removed or shut off) the browse lists will look like :
| Subnet | Browse Master | List |
|---|---|---|
| Subnet1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
| Subnet2 | N2_B | N2_A, N2_B, N2_C, N2_D N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
| Subnet3 | N3_D | N3_A, N3_B, N3_C, N3_D N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
Servers with a (*) after them are non-authoritative names.
Synchronizations between the domain master browser and local master browsers will continue to occur, but this should be a steady state situation.
If either router R1 or R2 fails the following will occur:
- Names of computers on each side of the inaccessible network fragments will be maintained for as long as 36 minutes, in the network neighbourhood lists.
- Attempts to connect to these inaccessible computers will fail, but the names will not be removed from the network neighbourhood lists.
- If one of the fragments is cut off from the WINS server, it will only be able to access servers on its local subnet, by using subnet-isolated broadcast NetBIOS name resolution. The effects are similar to that of losing access to a DNS server.
No comments:
Post a Comment