[ducht]

Router Support for IP Multicast

To forward IP multicast packets to only those subnets for which there are group members, an IP
multicast router must be able to:

· Receive all IP multicast traffic.

For shared access technologies, the normal listening mode for network adapters is unicast listening
mode. The listening mode is the way that the network adapter analyzes the destination MAC
address of incoming frames to decide to process them further. In unicast listening mode, the only
frames that are considered for further processing are in a table of interesting destination MAC
addresses stored on the network adapter. Typically, the only interesting addresses are the
broadcast address (0xFF-FF-FF-FF-FF-FF) and the unicast MAC address of the adapter.

However, for an IP multicast router to receive all IP multicast traffic, it must place the network
adapter in a special listening mode called multicast promiscuous mode. Multicast promiscuous
mode analyzes the Institute of Electrical and Electronics Engineers (IEEE)-defined Individual/Group
(I/G) bit to determine whether the frame requires further processing. The I/G bit for Ethernet
addresses is the low-order bit of the first byte of the destination MAC address.

The values of the I/G bit are the following:

· If set to 0, then the address is a unicast (or individual) address.

· If set to 1, then the address is a multicast (or group) address. The multicast bit is also set to 1 for
the broadcast address.

When the network adapter is placed in multicast promiscuous listening mode, any frames with the
I/G bit set to 1 are passed up for further processing.

Multicast promiscuous mode is different than promiscuous mode. In promiscuous mode, all
frames—regardless of the destination MAC address—are passed up for processing. Protocol
analyzers, such as Network Monitor 3.1, use promiscuous mode. Network adapters of hosts are
typically not placed in multicast promiscuous mode.

· Forward IP multicast traffic.

IP multicast packet forwarding is a capability of IP. When IP multicast forwarding is enabled, IP
analyzes IP multicast data packets to determine the interfaces over which the packet is to be
forwarded. IP performs this analysis by comparing the IP source and destination group addresses
to entries in the IP multicast forwarding table. Upon receipt of a non-local IP multicast packet, the
Time to Live (TTL) in the IPv4 header or the Hop Limit field in the IPv6 header is decremented by 1.
If the TTL or hop limit is greater than 0 after decrementing, the multicast forwarding table is
checked. If an entry in the multicast forwarding table is found that matches the destination IP
multicast address, the IP multicast packet is forwarded with its new TTL or hop limit over the
appropriate interfaces.

The multicast forwarding process does not distinguish between hosts on locally attached subnets
that are receiving multicast traffic or hosts on a network segment that are downstream from the
locally attached subnet across another router on the subnet. In other words, a multicast router
might forward a multicast packet on a subnet for which there are no hosts listening. The multicast
router forwards the packet because another router on that subnet indicated that a host in its
direction is receiving the multicast traffic.

The multicast forwarding table does not record each host group member or the number of host
group members, only that the multicast traffic needs to be forwarded over specific interfaces.

· Receive and process multicast group membership messages sent by hosts.

Multicast routers receive IGMP or MLD messages from hosts on all locally attached subnets. This
information is used to track host group membership by placing or removing entries in the multicast
forwarding table. Because all multicast routers are listening in multicast promiscuous mode, they
receive all IGMP and MLD messages sent to any group address.

To improve the leave latency, which is the time between when the last host on a subnet has left the
group and when no more multicast traffic for that group is forwarded to that subnet, a host that
might be the last member of a group on a subnet sends an IGMP Leave Group or MLD Multicast
Listener Done message. After sending multicast-address-specific IGMP or MLD queries to the
group being left and receiving no response, the router determines that there are no more group
members on that subnet.

· Query attached subnets for host membership status.

Multicast routers periodically send general IGMP and MLD query messages to the local subnet to
query for host membership information. A host that is still a member of a multicast group responds
to the query.

· Communicate group membership to other IP multicast routers.

To create multicast-enabled IP networks containing more than one router, multicast routers must
communicate group membership information to each other so that group members can receive IP
multicast traffic regardless of their location on the IP network.

Multicast routers exchange host membership information using a multicast routing protocol such as
Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF),
or Protocol Independent Multicast (PIM). Group membership is either communicated explicitly, by
exchanging group address and subnet information, or implicitly, by informing upstream routers
whether or not group members exist downstream from the source of the multicast traffic.

The goals of a multicast routing protocol include the following:

· Forward traffic away from the source to prevent loops.

· Minimize or eliminate multicast traffic to subnets that do not need the traffic.

· Minimize processor and memory load on the router for scalability.

· Minimize the overhead of the routing protocol.

· Minimize the join latency, which is the time it takes for the first host member on a subnet to begin
receiving group traffic.

Multicast routing is more complex than unicast routing. With unicast routing, unicast traffic is
forwarded to a globally unique destination. Unicast routes summarize ranges of globally unique
destinations. Unicast routes in the network are comparatively consistent and only need to be
updated when the topology of the IP network changes.

With multicast routing, multicast traffic is forwarded to an ambiguous group destination. Group
addresses represent individual groups, and in general, cannot be summarized in the multicast
forwarding table. The location of group members is not consistent, and the multicast forwarding
tables of multicast routers might need to be updated whenever a host group member joins or leaves
a host group.

Just as unicast routing protocols update the unicast IP routing table, multicast routing protocols
update the IP multicast forwarding table.

Routing and Remote Access in Windows Server 2008 and Windows Server 2003 does not include
any IPv4 or IPv6 multicast routing protocols, although it provides a platform on which third-party
IPv4 multicast routing protocols can run. The only component provided with Windows Server 2008
and Windows Server 2003 that can update entries in the IPv4 multicast forwarding table is the
IGMP routing protocol component of Routing and Remote Access.

Multicast Addresses

Multicast addresses are defined for both IPv4 and IPv6 addresses.

IPv4 Multicast Addresses

IPv4 multicast addresses, also known as group addresses, are in the class D range of 224.0.0.0/4 (from
224.0.0.0 to 239.255.255.255) as defined by setting the first four high order bits to 1110. Multicast
addresses in the range 224.0.0.0/24 (from 224.0.0.0 to 224.0.0.255) are reserved for the local subnet
and are not forwarded by IPv4 routers regardless of the TTL value in the IPv4 header. The following are
examples of reserved IPv4 multicast addresses:

· 224.0.0.1 - all hosts on this subnet

· 224.0.0.2 - all routers on this subnet

· 224.0.0.5 – all Open Shortest Path First (OSPF) routers on a subnet

· 224.0.0.6 – all OSPF designated routers on a subnet

· 224.0.0.9 - Routing Information Protocol (RIP) Version 2

For the current list of reserved IPv4 multicast addresses, see
http:// www. iana. org/assignments/multicast-addresses.

(Còn tiếp)

[ducht]

Mapping IPv4 Multicast to MAC-Layer Multicast

To support IPv4 multicasting, the Internet authorities have reserved the multicast address range of 01-
00-5E-00-00-00 to 01-00-5E-7F-FF-FF for Ethernet MAC addresses. To map an IPv4 multicast address
to a MAC-layer multicast address, the low order 23 bits of the IPv4 multicast address are mapped
directly to the low order 23 bits in the MAC-layer multicast address. Figure A-2 shows the mapping of
an IPv4 multicast address to an Ethernet multicast address.



Figure A-2 Mapping IPv4 multicast addresses to Ethernet multicast addresses

For example:

· The IPv4 multicast address 224.0.0.1 is mapped to 01-00-5E-00-00-01.

When mapping the 23 low order bits, the first octet is not used, and only the last 7 bits of the
second octet is used. The third and fourth octets are converted directly to hexadecimal numbers.
For the second and third octets, 0 in hexadecimal is 0x00. For the last octet, 1 in hexadecimal is
0x01. Therefore, the destination MAC address corresponding to 224.0.0.1 becomes 01-00-5E-00-
00-01.

· The IPv4 multicast address 224.192.16.1 is mapped to 01-00-5E-40-10-01.

For the second octet, 192 in binary is 11000000. If you drop the high order bit, it becomes 1000000
or 64 (in decimal), or 0x40 (in hexadecimal). For the third octet, 16 in hexadecimal is 0x10. For the
last octet, 1 in hexadecimal is 0x01. Therefore, the destination MAC address corresponding to
224.192.16.1 becomes 01-00-5E-40-10-01.

Because the first 4 bits of an IPv4 multicast address are fixed according to the class D convention,
there are 5 bits in the IPv4 multicast address that do not map to the MAC-layer multicast address.
Therefore, it is possible for a host to receive MAC-layer multicast packets for groups to which it does
not belong. However, IPv4 drops these packets once the destination IPv4 address is determined.

Token Ring uses this same method for MAC-layer multicast addressing. However, many Token Ring
network adapters do not support it. Therefore, by default, the functional address 0xC0-00-00-04-00-00
is used for all IP multicast traffic sent over Token Ring networks. For more information about Token
Ring support for IPv4 multicasting, see RFC 1469.

IPv6 Multicast Addresses

IPv6 multicast addresses have the first eight bits fixed at 1111 1111 (FF00::/8). Therefore, an IPv6
multicast address always begins with FF. Multicast addresses cannot be used as source addresses or
as intermediate destinations in a Routing header. Beyond the first eight bits, IPv6 multicast addresses
include additional structure to identify flags, their scope, and the multicast group. Figure A-3 shows the
structure of the IPv6 multicast address.



Figure A-3 The structure of the IPv6 multicast address

The fields in the multicast address are:

· Flags Indicates flags set on the multicast address. The size of this field is 4 bits. RFC 4291 defines the
Transient (T) flag, which uses the low-order bit of the Flags field. When set to 0, the T flag indicates that
the multicast address is a permanently assigned (well-known) multicast address allocated by the IANA.
When set to 1, the T flag indicates that the multicast address is a transient (non-permanently-assigned)
multicast address.

· Scope Indicates the scope of the IPv6 network for which the multicast traffic must be delivered. The
size of this field is 4 bits. In addition to information provided by multicast routing protocols, routers use
the multicast scope to determine whether multicast traffic can be forwarded. Commonly used values for
the Scope field include 1 for interface-local scope, 2 for link-local scope, and 5 for site-local scope.
Additional values for the Scope field are defined in RFC 4291.

· Group ID Identifies the multicast group and is unique within the scope. The size of this field is 112 bits.

Permanently assigned group IDs are independent of the scope. Transient group IDs are relevant only to
a specific scope. Multicast addresses from FF01:: through FF0F:: are reserved, well-known addresses.

To identify all nodes for the interface-local and link-local scopes, the following addresses are defined:

· FF01::1 (interface-local scope all-nodes multicast address)

· FF02::1 (link -local scope all-nodes multicast address)

To identify all routers for the interface-local, link-local, and site-local scopes, the following addresses
are defined:

· FF01::2 (interface-local scope all-routers multicast address)

· FF02::2 (link -local scope all-routers multicast address)

· FF05::2 (site-local scope all-routers multicast address)

For the current list of permanently assigned IPv6 multicast addresses, see

http:// www. iana. org/assignments/ipv6-multicast-addresses.

IPv6 multicast addresses replace all forms of IPv4 broadcast addresses. The IPv4 network broadcast
(all host bits are set to 1 in a classful environment), subnet broadcast (all host bits are set to 1 in a
classless environment), and limited broadcast (255.255.255.255) addresses are replaced by the linklocal
scope all-nodes multicast address (FF02::1) in IPv6.

Solicited-Node Address

The solicited-node address facilitates the efficient querying of network nodes during link -layer address
resolution, the resolving of a link-layer address of a known IPv6 address. In IPv4, the ARP Request
frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those
that are not running IPv4. IPv6 uses the Neighbor Solicitation message to perform link-layer address
resolution. However, instead of using the local-link scope all-nodes multicast address as the Neighbor
Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node
multicast address is used. The solicited-node multicast address is constructed from the prefix
FF02::1:FF00:0/104 and the last 24 bits of the unicast IPv6 address being resolved. Figure A-4 shows
the mapping of unicast IPv6 address to its corresponding solicited node multicast address.



Figure A-4 Mapping an IPv6 unicast address to its corresponding solicited node multicast address

For example, Node A is assigned the link-local address of FE80::2AA:FF:FE28:9C5A and is also
listening on the corresponding solicited-node multicast address of FF02::1:FF28:9C5A (the underline is
used to highlight the correspondence of the last six hexadecimal digits). Node B on the local link must
resolve Node A’s link-local address FE80::2AA:FF:FE28:9C5A to its corresponding link-layer address.

Node B sends a Neighbor Solicitation message to the solicited node multicast address of
FF02::1:FF28:9C5A. Because Node A is listening on this multicast address, it processes the Neighbor
Solicitation message and sends back a unicast Neighbor Advertisement message in reply.

The result of using the solicited-node multicast address is that link-layer address resolutions, a common
occurrence on a link, are not using a mechanism that disturbs all network nodes. By using the solicitednode
address, very few nodes are disturbed during address resolution. In practice, due to the
relationship between the link-layer MAC address, the IPv6 interface ID, and the solicited-node address,
the solicited-node address acts as a pseudo-unicast address for very efficient address resolution.

Mapping IPv6 Multicast to MAC-Layer Multicast

To support IPv6 multicasting, the Internet authorities have reserved the multicast address range of 33-
33-00-00-00-00 to 33-33-FF-FF-FF-FF for Ethernet MAC addresses. To map an IPv6 multicast address
to a MAC-layer multicast address, the low order 32 bits of the IPv6 multicast address are mapped
directly to the low order 32 bits in the MAC-layer multicast address. Figure A-5 shows the mapping of
an IPv6 multicast address to an Ethernet multicast address.



Figure A-5 Mapping IPv6 multicast addresses to Ethernet multicast addresses

For example:

· The link-local scope all-nodes multicast address of FF02::1 maps to the Ethernet multicast address of
33-33-00-00-00-01.

· The example solicited-node address of FF02::1:FF3F:2A1C maps to the Ethernet multicast address of
33-33-FF-3F-2A-1C.

Multicast Subnet Membership Management

For multicast subnet group membership, IPv4 nodes use IGMP and IPv6 nodes use MLD.

IGMP for IPv4

Routers and hosts use IGMP to manage subnet host membership in IPv4 multicast groups. IGMP
messages take the following forms:

· When a host joins a host group, it sends an IGMP Host Membership Report message to the all-hosts
IPv4 multicast address (224.0.0.1) or to the specified IPv4 multicast address declaring its membership
in a specific host group by referencing the IPv4 multicast address.

· When a router polls a network to ensure that there are members of a specific host group, it sends an
IGMP Host Membership Query message to the all-hosts IPv4 multicast address. If no responses to the
poll are received after several polls, the router assumes no membership in that group for that network
and stops advertising that group-network information to other routers.

· When a host leaves an IPv4 multicast group and has determined that it is the last member of that group
on the subnet, it sends an IGMP Leave Group message.

TCP/IP in Windows supports IGMP, IGMP version 2 (IGMP v2), and IGMP version 3 (IGMP v3). There
is no IGMP-related configuration required for a Windows -based computer to use all three versions of
IGMP.

IGMP is defined in RFC 1112. IGMP v2 is defined in RFC 2236. IGMP v3 is defined in RFC 3376.

(Còn tiếp)

[ducht]

MLD for IPv6

MLD is the IPv6 equivalent of IGMP v2 for IPv4. MLD is a set of ICMPv6 messages exchanged by
routers and nodes, enabling routers to discover the set of multicast addresses for which there are
listening nodes for each attached interface. Like IGMPv2, MLD only discovers the list of multicast
addresses for which there is at least one listener, not the list of individual multicast listeners for each
multicast address. MLD is described in RFC 2710.

The three types of MLD messages are:

· When a host joins a host group, it sends an MLD Multicast Listener Report message to the specific
IPv6 multicast address declaring its membership in a specific host group.

· When a router polls a network to ensure that there are members of a specific host group, it sends an
MLD Multicast Listener Report message to the link-local scope all-hosts IPv6 multicast address
(FF02::1).

· When a host leaves an IPv6 multicast group and has determined that it is the last member of that group
on the subnet, the host sends an MLD Multicast Listener Done message.

Table A-1 lists IGMPv2 messages and their corresponding MLD equivalents.



Table A-1 IGMPv2 messages and their MLD equivalents

MLD version 2 (MLDv2) is the IPv6 equivalent of IGMP v3 for IPv4. MLDv2 is described in RFC 3810.
Windows Server 2008 and Windows Vista support MLDv2.

IPv4 Multicast Forwarding Support in Windows Server 2008 and
Windows Server 2003

Multicast forwarding in Windows Server 2008 and Windows Server 2003 consists of the following:

· IPv4 multicast forwarding by the Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol (TCP/IP)
component

· The IGMP routing protocol component of Routing and Remote Access

IPv4 Multicast Forwarding

In Windows, IPv4 multicast forwarding is supported by the Internet Protocol Version 4 (TCP/IPv4) or
Internet Protocol (TCP/IP) component. IPv4 multicast forwarding is enabled when you configure and
enable Routing and Remote Access. The Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol
(TCP/IP) component maintains an IPv4 multicast forwarding table, which can be viewed from the
Routing and Remote Access snap-in or by using the netsh routing ip show mfe command.

Note The Internet Protocol Version 6 (TCP/IPv6) component in Windows Server 2008 and Windows Vista
supports IPv6 multicast forwarding, which you can enable with the netsh interface ipv6 set global
multicastforwarding=enable command. However, at the time of the publication of this book, there is no
mechanism to update the IPv6 multicast forwarding table.

IGMP Routing Protocol Component

Because there are no multicast routing protocols provided with Windows Server 2008 or Windows
Server 2003, the maintenance of entries in the IPv4 multicast forwarding table is a function of IGMP, a
component that is added as an IPv4 routing protocol.

To add the IGMP routing protocol component, do the following:

1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Routing
And Remote Access.

2. In the console tree, open Routing And Remote Access, the server name, and then either IPv4 or IP
Routing.

3. In the console tree, right -click General, and then click New Routing Protocol.

4. In the Select Routing Protocol dialog box, click IGMP Router And Proxy, and then click OK.

The IGMP routing protocol component might have already been added, depending on your choices in
the Routing and Remote Access Server Setup wizard.

Although the IGMP routing protocol component provides some limited ability to create or extend
multicast-enabled IPv4 networks, it is not the equivalent of a multicast routing protocol, such as DVMRP
or PIM. It is not recommended for use to create a multicast-enabled IPv4 network of an arbitrary size or
topology.

After the IGMP routing protocol is added, you must add router interfaces by doing the following:

1. In the console tree of the Routing and Remote Access snap-in, open Routing And Remote Access,
the server name, and then either IPv4 or IP Routing.

2. In the console tree, right -click IGMP, and then click New Interface.

3. In Interfaces, click the interface you want to enable, and then click OK.

4. On the General tab of the IGMP Properties dialog box for the interface, verify that the Enable IGMP
check box is selected.

5. Under Mode, click IGMP Router or IGMP Proxy. Under IGMP Protocol Version, select the version
of IGMP being used in your network.

6. Click OK.

Figure A-6 shows the General tab for the properties of an IGMP interface.



Figure A-6 The General tab for the properties of an IGMP interface

When you add an interface to the IGMP routing protocol component in the Routing and Remote Access
snap-in, you must configure the interface with one of the following:

· IGMP router mode

· IGMP proxy mode

IGMP Router Mode

When an IGMP routing protocol interface is configured in IGMP router mode, it performs the following
functions:

· Listens in multicast promiscuous mode.

· Listens for IGMP Host Membership Report messages and Leave Group messages.

· Sends IGMP Host Membership Queries.

· Maintains entries in the IPv4 multicast forwarding table.

IGMP router mode can be enabled on multiple interfaces. For each interface, a specific version of IGMP
can be configured. The default version is IGMP v3.

IGMP Proxy Mode

While the purpose of IGMP router mode is to act as a multicast router, the purpose of IGMP proxy
mode is to act as a multicast proxy for hosts on interfaces on which IGMP router mode is enabled.
When an IGMP routing protocol interface is configured in IGMP router mode, it performs the following
functions:

· Forwards IGMP Host Membership Reports

All IGMP Host Membership Reports received on IGMP router mode interfaces are retransmitted on
the IGMP proxy mode interface.

· Registers multicast MAC addresses

For shared access technologies such as Ethernet, the network adapter is left in unicast listening
mode. For each unique group registered by IGMP Host Membership Reports forwarded on the
IGMP proxy mode interface, the network adapter is programmed to pass up frames with the
corresponding multicast MAC address. Each additional multicast MAC address is an entry in the
table of interesting destination MAC addresses on the network adapter. Each network adapter has
a maximum number of entries it can store. If the maximum number of entries is used, then the
IGMP routing protocol enables multicast promiscuous listening mode on the network adapter.

· Adds entries to the multicast forwarding table

When non-local multicast traffic is receive d on an IGMP router mode interface, the IGMP routing
protocol adds or updates an entry to the multicast forwarding table to forward the multicast traffic
out the IGMP proxy mode interface. The end result of this process is that any non-local multicast
traffic received on IGMP router mode interfaces is flooded, or copied, to the IGMP proxy mode
interface.

· Receives multicast traffic received on IGMP proxy mode interfaces

Multicast traffic received on the IGMP proxy mode interface corresponding to the groups registered
by hosts on IGMP router mode interfaces are forwarded to the appropriate interfaces using the IP
protocol and the multicast forwarding table.

The purpose of IGMP proxy mode is to connect a Windows Server 2008 or Windows Server 2003
router to a multicast-enabled IPv4 network, such as the multicast backbone of the IPv4 Internet
(MBone), or a private intranet that is using multicast routing protocols, such as DVMRP and PIM. Figure
A-7 shows an example of using IGMP router mode and IGMP proxy mode to connect a small office
network to the MBone.



Figure A-7 Using IGMP proxy mode to connect a small office network to the MBone

The IGMP proxy mode interface acts like a host and joins host groups on behalf of hosts on its IGMP
router mode interfaces. Multicast traffic sent to host members on IGMP router mode interfaces are
received on the IGMP proxy mode interface and forwarded by the Internet Protocol Version 4
(TCP/IPv4) or Internet Protocol (TCP/IP) component. Multicast traffic sent by hosts on IGMP router
mode interfaces are flooded on the IGMP proxy mode interface where a downstream IPv4 multicastenabled
router can either forward the traffic or ignore it.

IGMP proxy mode can only be enabled on a single IGMP routing protocol interface. The correct
interface on which to enable IGMP proxy mode is the interface attached to a subnet containing a
multicast router running multicast routing protocols. In other words, the IGMP proxy mode interface
"points" to the multicast-enabled intranet.

(Còn tiếp)

[ducht]

IPv4 Multicast Address Allocation with MADCAP

The Multicast Address Dynamic Client Allocation Protocol (MADCAP) is an Internet standard for
multicast address allocation defined in RFC 2730. The primary benefit of MADCAP is that you can use
it to leverage your existing Windows Dynamic Host Configuration Protocol (DHCP) infrastructure to
assign multicast IPv4 addresses in the same way that you assign unicast IPv4 addresses.

The multicast address allocation uses the following components:

· MADCAP servers

MADCAP servers allocate IP v4 multicast addresses. For Windows, a MADCAP server is a
computer running Windows Server 2008 or Windows Server 2003 and the DHCP Server service.
Using the DHCP snap-in, you must configure and activate at least one multicast scope.

· MADCAP clients

MADCAP clients use the MADCAP protocol to request IPv4 multicast addresses from a MADCAP
server. Windows supports a MADCAP application programming interface (API) so that an
application can use MADCAP to request, renew, or release a unique IPv4 multicast address from a

MADCAP server.

An example of a MADCAP client application is a video conferencing server service that uses MADCAP
to receive a unique multicast address and then communicate that address to connecting video clients.
After the initial connection negotiation, the video client computer listens on the IPv4 multicast address
for the video stream.

Using Multicast Scopes

A multicast scope is a range of IPv4 multicast addresses that the MADCAP server is configured to
assign to requesting MADCAP clients. When deciding the multicast address ranges to use for multicast
scopes on your MADCAP server, there are two ranges of addresses that are recommended:

· Administratively scoped multicast addresses are in the 239.192.0.0/14 range (from 239.192.0.1 to
239.255.255.255) and are intended for use by an organization using multicast scopes privately for its
own internal use. Administratively scoped multicast addresses are described in detail in RFC 2365.

· Globally scoped multicast addresses are in the range 233.0.0.0/8 (from 233.0.0.1 to 233.255.255.255)
and are intended for use by an organization using multicast scopes on the Internet. Within the
233.0.0.0/8 range, the second and third octets are used for the autonomous system (AS) number,
assigned to the organization by an Internet Assigned Numbers Authority (IANA) registry. The last octet
identifies the multicast group. For more information on AS numbering, see RFC 1930.

The Windows Server 2008 or Windows Server 2003 DHCP Server service supports both the DHCP and
MADCAP protocols. These protocols function separately and are not dependent on each other. To
configure a DHCP-only server, configure DHCP scopes but no multicast scopes. To configure a
MADCAP-only server, configure multicast scopes but no DHCP scopes.

To create a multicast scope on a computer running Windows Server 2008 or Windows Server 2003 and
the DHCP Server service, do the following:

1. Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then doubleAppendix
click DHCP.

2. In the console tree, click the applicable DHCP server.

3. On the Action menu, click New Multicast Scope.

4. Follow the instructions in the New Multicast Scope wizard.

The New Multicast Scope wizard guides you through the configuration of the multicast address range,
exclusions, lease duration, and scope activation.

Reliable Multicast with Pragmatic General Multicast (PGM)

Multicast data streams are typically sent using the User Datagram Protocol (UDP). Transmission
Control Protocol (TCP) is not used because it is designed for one-to-one unicast streams of data.
Multicast data streams sent over UDP are inherently unreliable because UDP does not provide
guaranteed delivery or retransmission of lost packets. Unless reliability is provided by the upper layer
protocol, lost packets in UDP -based multicast data streams cannot be detected or recovered.

The Reliable Multicast Transport working group of Internet Engineering Task Force (IETF) has created
a set of standards for the reliable transmission of multicast data streams from one or multiple senders
to multiple receivers. There are many protocol standards that provide reliable multicast at the transport
or application layers. Existing reliable multicast protocols fall into the following four categories:

1. Negative acknowledgement (NACK)-only

Receivers send NACK packets to request, from the sender, the retransmission of missing packets in
the multicast data stream. NACK-only protocols do not require any additional support from routers in
the network.

2. Tree-based acknowledgement (ACK)

Receivers send positive acknowledgments to indicate multicast data packets that are successfully
received.

3. Asynchronous Layered Coding (ALC)

Senders provide forward error correction (FEC) with no messages from receivers or the routers of the
network.

4. Router assist

Receivers send NACK packets. Routers in the network assist with retransmitting lost packets.

PGM Overview

PGM is a router assist type of reliable multicast protocol that is described in RFC 3208. PGM-enabled
receivers use NACK packets to request the retransmission of missing packets. PGM-enabled routers in
a network define a logical PGM topology and can facilitate the recovery of lost packets by sending them
on behalf of the sender. The PGM topology is overlaid on top of the physical IPv4 network topology.
PGM routers define a series of PGM hops between a sender and its receivers. Although defined in RFC
3208, PGM routers are not required. The PGM topology of a network can consist of the single logical
hop between the sender and the receivers.

PGM does not provide all of the capabilities of TCP for multicast data streams. For example, PGM does
not provide sender or receiver-side flow control, byte stream windowing, or congestion control. PGM
provides basic reliability for PGM-enabled applications.

PGM is a transport layer multicast protocol that runs directly over IPv4 using protocol number 113. It
does not use TCP or UDP for its own messages or for multicast data transmission. PGM is the only
reliable multicast protocol supported by Windows Server 2008, Windows Vista, and Windows Server
2003.

Adding and Using the Reliable Multicast Protocol

To use PGM on computers running Windows Server 2008, Windows Vista, or Windows Server 2003,
you must add the Reliable Multicast Protocol component and create PGM-enabled applications.

Adding the Reliable Multicast Protocol

To add the Reliable Multicast Protocol to a connection, complete the following steps:

1. From the Network Connections folder, right-click the connection, and then click Properties.

2. In the properties dialog box for the connection, click Install.

3. In Select Network Feature Type or Select Network Component Type, double-click Protocol.

4. In the Network Protocol list, click Reliable Multicast Protocol, and then click OK.

5. To save changes to the connection properties, click Close.

The Reliable Multicast Protocol component appears in the list of items being used by the connection,
but has no configurable properties.

Writing PGM-enabled Applications

To use PGM, an application must use Windows Sockets and the PGM socket options. A sender
application uses Windows Sockets to create a PGM socket, bind the socket to any address, and then
connect to the multicast group address. A receiver application uses Windows Sockets to create a PGM
socket, bind the socket to the multicast group address, post a listen on the new socket, and then use
the accept() function to obtain a socket handle for the PGM session.

Microsoft products that use PGM include Message Queuing (also known as MSMQ) and Automated
Deployment Services (ADS).

How PGM and the Reliable Multicast Protocol Works

A receiver uses the following process:

1. The multicast application opens a listen socket with the appropriate reliable multicast socket options.

2. The receiver sends an IGMP Host Membership Report message to inform the local routers of the
receiver's membership in the multicast group.

A sender uses the following process:

1. The multicast application opens a send socket with the appropriate reliable multicast socket options.

2. The multicast application begins to send data. PGM packets containing data are sent beginning with
a sequence number of 0, and are incremented by 1 for subsequent packets.

3. The multicast-enabled routers forward the multicast data packets throughout the IPv4 network to the
subnets that contain group members.

When a receiver determines that there is a missing packet, it sends a PGM message to its nearest
PGM router, requesting that the missing packet with a specific sequence number be resent. This
request is forwarded to either the original source or a PGM router that stores copies of recent packets
sent by the source. In either case, the missing packet is sent directly to the requesting receiver.
Hết Appendix A

[ducht]

Appendix B – Simple Network Management Protocol

Abstract

This appendix describes the Simple Network Management Protocol (SNMP) and its support in the Microsoft Windows
operating systems. SNMP is used in enterprise network environments to manage many types of network devices. A
network administrator must understand SNMP to integrate computers running Windows Vista, Windows XP, Windows
Server 2008, or Windows Server 2003 into an SNMP-managed environment.

SNMP Overview

SNMP is a network management protocol and infrastructure widely used on IP networks. It was
originally developed in the Internet community to monitor and troubleshoot routers and bridges. SNMP
allows network administrators to manage network devices such as workstation or server computers,
routers, switches, and wireless access points.

SNMP can be used to:

· Configure devices remotely You can use an SNMP to configure a device across the network from a
central management computer.

· Monitor network performance You can use an SNMP to systematically and periodically query
devices for current performance statistics to monitor network throughput.

· Detect network faults or inappropriate access A device can use SNMP to send a message when
specific events occur. Common types of conditions to report to a management system include a device
being shut down and restarted, a link failure being detected on a router, inappropriate access, and low
disk space on a file server.

SNMP uses a distributed architecture consisting of the following components:

· SNMP management systems

The SNMP management system, also known as a management station or a management console,
is a computer running SNMP management software that sends information and update requests to
devices running an SNMP agent.
The SNMP management system requests information from a device, such as the amount of hard
disk space available or the number of active sessions. If the management system has been granted
write access to a device, the management system can also change a device's configuration.

· SNMP agents

An SNMP agent is a device running software that collects information and responds to
management system requests for information. The SNMP agent software can be configured to
determine which statistics are tracked and which management systems are authorized to request
information. Typically, agents do not originate messages, but only respond to them. The exception
is when the agent is configured to report a specific event, such as a system restart or an
inappropriate access.

Figure B-1 shows an example of SNMP being used on a network.



Figure B-1 An example of SNMP being used on a network

SNMP is defined in RFC 1157.

The Management Information Base

The information that an agent can collect and a management system can request from an agent is
contained in a Management Information Base (MIB). A MIB is a set of manageable objects representing
various types of information about a network device, such as the number of active sessions or the
version of network operating system software that is running on a host. SNMP management systems
and agents share a common understanding of MIB objects. For a given MIB, the agent maintains
information about the objects in the MIB and the management system retrieves the information in the
MIB from the agent.

The Hierarchical Name Tree

The name space for MIB objects is hierarchical. It is structured so that each manageable object can be
assigned a globally unique name. When a management system requests a data object from an agent, it
includes the globally unique name in the request. Authority for parts of the name space is assigned to
individual organizations. This allows organizations to assign names to new objects without consulting
an Internet authority for each assignment. For example, the name space assigned to the LAN Manager
MIB II is 1.3.6.1.4.1.77. LAN Manager is an obsolete Microsoft operating system. Microsoft has also
been assigned 1.3.6.1.4.1.311, and all new MIBs for Microsoft-specific technologies are created under
that branch. Microsoft has the authority to assign names to objects anywhere below that portion of the
name space.

Figure B-2 shows a portion of the SNMP hierarchical name tree.



Figure B-2 The SNMP hierarchical name tree

The object identifier in the hierarchy is written as a sequence of number labels beginning at the root and
ending at the object. Labels are separated with periods. For example, the object identifier for MIB II is
1.3.6.1.2.1, corresponding to the object name iso.org.dod.internet.management.mibii. The object
identifier for LAN Manager MIB II is 1.3.6.1.4.1.77, corresponding to the object name
iso.org.dod.internet.private.enterprise.lanmanager .

The name space used to map object identifiers is separate from the hierarchical name space
associated with Domain Name System (DNS) domain names.

SNMP Messages

SNMP uses the following messages:

· Get-request Sent by an SNMP management system to request information about a single MIB object
on an SNMP agent (for example, the number of packets forwarded).

· Get-next-request An extended type of request message sent by an SNMP management system that
can be used to browse an entire tree of management objects. When processing a Get-next-request
request for a particular object, the agent returns the identity and value of the next object in the MIB,
based on the previous request. The Get -next-request request is useful for dynamic tables, such as an
IPv4 or IPv6 route table.

· Getbulk-request Sent by an SNMP management system to request that the data transferred by the
agent be as large as possible within the restraints of maximum message size. This message minimizes
the number of message exchanges required to retrieve a large amount of management information.

· Set-request Sent by an SNMP management system to assign an updated value for a MIB object the
agent (provided write access is enabled on the SNMP agent). Management systems use Set-request
messages to remotely configure SNMP agents.

· Get-response Sent by the SNMP agent in response to a Get -request, Get-next-request, Getbulkrequest,
or Set-request message.

· Trap An unsolicited message sent by an SNMP agent to an SNMP management system when the
agent detects that a certain type of event has occurred. The SNMP management system that receives
a trap message is known as a trap destination. For example, a trap message might be sent when a
device is restarted.

The Get -request, Get-next-request, Getbulk-request, and Set-request messages are sent by a
management system to an agent as a unicast UDP message sent to the IPv4 address of the agent and
destination UDP port 161. An agent sends the Trap message to a management system as a unicast
UDP message sent to the IPv4 address of the management system and destination UDP port 162.

Figure B-3 shows the exchange of messages between an SNMP management system and an SNMP
agent.



Figure B-3 The exchange of messages between an SNMP management system and an SNMP agent

All SNMP messages are sent without data protection. To protect SNMP messages, use Internet
Protocol security (IPsec) to protect traffic between SNMP management systems and agents. Both the
management system and the agent must support IPsec. For more information about IPsec, see
Chapter 13, "Internet Protocol Security (IPsec) and Packet Filtering."

SNMP Communities

Management systems and agents belong to an SNMP community, which is a collection of hosts
grouped together for administrative purposes. The use of a community name provides context checking
for agents that receive requests and initiate traps, and for management systems that initiate requests
and receive traps. An agent will not accept a request from a management system outside its configured
communities. A management system will not accept a trap from an agent outside its configured
communities.

You use community names primarily as an element for organization, not security. SNMP messages are
typically sent without IPsec protection. By capturing unprotected SNMP messages, a malicious user
can determine the SNMP community name and send their own SNMP messages with the correct
community name.

There is no relationship between community names and domain or workgroup names. Community
names represent a named context for groups of the components of SNMP infrastructure.

Agents and management systems can be members of multiple communities at the same time, allowing
for flexibility in configuring the administrative elements of your SNMP infrastructure.

Figure B-4 shows an example of two defined communities—IT and Admin.



Figure B-4 An example of SNMP communities

Only the agents and management systems that are members of the same community can communicate
with each other. For example:

· Agent1 can receive and send messages to Manager2 because they are both members of the Admin
community.

· Agent2, Agent3, and Agent4 can receive and send messages to Manager1 because they are all
members of the IT community.

The default name for many SNMP agents is Public. The SNMP service for Windows Server 2008,
Windows Vista, and Windows Server 2003 does not have a configured SNMP community name. The
SNMP service for Windows XP uses the default name of Public.
(Còn tiếp)

[ducht]

How SNMP Works

The following steps describe how SNMP works in a typical get operation:

1. An SNMP management system sends a request to an SNMP agent.

The request is a Get-request, Get-next-request, or Getbulk-request message with one or more data
objects and a community name, and is sent to the SNMP agent's IPv4 address and destination UDP
port 161. For example, the SNMP management system sends a Get-request message with the
community name IT requesting the number of active sessions.

2. The SNMP agent receives the SNMP message.

The community name is verified. If the community name is invalid or the packet is malformed, it is
silently discarded. If the community name is valid, the request is passed to the appropriate MIB
component. The MIB component returns the requested information to the agent. For this example,
the SNMP agent retrieves the number of active sessions from the MIB.

3. The SNMP agent sends a Get-response message to the SNMP management system with the
requested information.

For this example, the SNMP agent sends a Get-response message with the community name IT that
contains the number of active sessions.

Figure B-5 shows this process.



Figure B-5 An example of how SNMP works

Windows SNMP Service

The SNMP service in Windows is SNMP agent software that provides information to management
systems running SNMP management software. The SNMP service:

· Responds to requests for status information from multiple hosts.

· Reports significant events (traps) to multiple hosts as they occur.

· Uses host names and IPv4 addresses to identify the hosts to which it reports information and from
which it receives requests.

The Windows SNMP service is a Windows Sockets application. It provides an internal infrastructure
that allows third-party software and hardware developers to create their own MIBs for use with the
Windows SNMP service and for the development of SNMP management system applications.

The SNMP service in Windows Server 2008 and Windows Server 2003 supports the following MIBs:

· Internet MIB II

Internet MIB II is a superset of the previous standard, Internet MIB I. Internet MIB II defines objects
essential for either fault or configuration analysis. Internet MIB II is defined in RFC 1212.

· LAN Manager MIB II

LAN Manager MIB II defines objects for share, session, user, and logon information. Most LAN
Manager MIB II objects have read-only access because typically SNMP messages are not
protected.

· DHCP MIB

The Dynamic Host Configuration Protocol (DHCP) MIB defines objects to monitor DHCP server
activity. This MIB is automatically installed when the DHCP server service is installed. It contains
objects for monitoring DHCP, such as the number of DHCPDiscover messages received and the
number of addresses leased out to DHCP clients.

· WINS MIB

The Windows Internet Name Service (WINS) MIB defines objects to monitor WINS server activity.
This MIB is automatically installed when the WINS Server service is installed. It contains objects for
monitoring WINS, such as the number of resolution requests successfully processed, the number of
resolution requests that failed, and the date and time of the last database replication.

· IIS MIBs

The Internet Information Services (IIS) MIBs define objects to monitor File Transfer Protocol (FTP)
and Hypertext Transfer Protocol (HTTP) activity. These MIBs are automatically installed when IIS is
installed. They contain objects for monitoring the FTP and Web services of IIS and include counters
for total bytes sent and total files sent.

· RADIUS Server MIBs

The Remote Authentication Dial-In User Service (RADIUS) Server MIBs define objects to monitor
RADIUS server authentication and accounting activity. These MIBs are automatically installed when
the Internet Authentication Service (IAS) is installed. They contain objects for monitoring the
RADIUS server, such as the number of authentication requests successfully processed and the
number of accounting requests.

The RADIUS Authentication Server MIB is defined in RFC 2619. The RADIUS Accounting Server
MIB is defined in RFC 2621.

Installing and Configuring the SNMP Service

To install the SNMP service in Windows Vista, do the following:

1. From Control Panel-Programs and Features, click Turn Windows features on or off.

2. In Windows Features, click SNMP feature, and then click OK.

To install the SNMP service in Windows Server 2008, use the Server Manager snap-in to add the
SNMP Service feature.

To install the SNMP service in Windows Server 2003 and Windows XP, do the following:

3. Click Start, click Control Panel, double-click Add Or Remove Programs, and then click
Add/Remove Windows Components.

4. In Components, click Management And Monitoring Tools (but do not select or clear its check
box), and then click Details.

5. Select the Simple Network Management Protocol check box, and click OK.

6. Click Next.

The SNMP service starts automatically after installation.

Unlike many services in Windows, the SNMP service does not have a corresponding snap-in. Instead,
you configure the SNMP service through additional tabs on the properties of the SNMP service in the
Services snap-in.

To configure the SNMP service, do the following:

1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click
Computer Management.

2. In the console tree, open Services And Applications, and then click Services.

3. In the details pane, right-click SNMP Service, and then click Properties.

You configure the SNMP service from the following tabs:

· Agent

· Traps

· Security

Agent Tab

On the Agent tab, you can configure a contact person, the physical location of the computer, and
enable and disable the types of information that you want the SNMP service to collect. By default the
Applications, Internet, and End-to-end categories are enabled.

Figure B-6 shows the Agent tab.



Figure B-6 The Agent tab for the SNMP service

Traps Tab

On the Traps tab, you configure the community name that is included in Trap messages and the trap
destinations—a list of IPv4 addresses to which Trap messages are sent.

Figure B-7 shows the Traps tab.



Figure B-7 The Traps tab for the SNMP service

Security Tab

On the Security tab, you configure the following:

· Whether the SNMP service will send a trap to all trap destinations if it receives a request that does not
contain a recognized community name.

· The list of accepted community names.

· Whether to accept SNMP messages from any host, or from a list of hosts by IPv4 address or host
name.

Figure B-8 shows the Security tab.



Figure B-8 The Security tab for the SNMP service

Evntcmd Tool

You can use the Evntcmd.exe tool at a command prompt to configure SNMP traps based on events
recorded in system logs. You can also use Evntcmd.exe to specify where trap messages are sent
within an SNMP community.
Hết Appendix B

[ducht]

Appendix C – Computer Browser Service

Abstract

This appendix describes how the Computer Browser service on computers running Microsoft Windows operating
systems works to display the list of workgroups and domains and the servers within them for the contents of the
Network and Microsoft Windows Network windows and related windows in My Network Places. A network
administrator must understand how the Computer Browser service works over an IPv4 network to determine why some
domains, workgroups, or the server computers within them are not displayed.

Computer Browsing Overview

The Computer Browser service in Windows maintains an updated list of domains, workgroups, and
server computers on the network and supplies this list to client computers upon request.

A domain is a grouping of computers that provide a centralized account database and security. The
definition of domain for computer browsing is separate from its definition for Active Directory. In Active
Directory, a domain is a collection of computer, user, and group objects defined by the administrator.
These objects share a common directory database, security policies, and security relationships with
other domains.

A workgroup is a logical grouping of computers that helps users locate shared resources such folders
and printers. Workgroups do not offer the centralized user accounts and security offered by domains. A
LAN group is either a domain or a workgroup.

The Computer Browser service maintains a distributed series of lists of available network resources as
viewed from the following locations:

· Using the new Windows XP -style Start menu, click Start, and then click My Network Places. In the My
Network Places window, click Entire Network. In the Entire Network window, double-click Microsoft
Windows Network.

· Using the classic Windows Start menu, double-click My Network Places on your desktop. In the My
Network Places window, double-click Entire Network. In the Entire Network window, double-click

Microsoft Windows Network.

For either method, the Microsoft Windows Network window displays a list of LAN groups.

The list of LAN groups and the servers within them are distributed to automatically elected browse
server computers. Computers elected as browse servers eliminate the need for all computers to
maintain a list of all the LAN groups and their servers on the network and lowers the amount of network
traffic required to build and maintain a list of all the computers on the network.

The browse list, the list of LAN groups and the servers within them that are accumulated and distributed
by the Computer Browser service, is separate from the list of computers maintained in Active Directory.
For example, when you click Search Active Directory in the Network Tasks pane of the My Network
Places window, the Find Users, Contacts, And Groups dialog box is displayed. Queries using this
dialog box are performed against Active Directory, not against the browse list maintained by computers
running the Computer Browser service.

The Computer Browser service operates by exchanging a set of NetBIOS over TCP/IP (NetBT)
broadcast and unicast messages. There is no support for computer browsing over IPv6. If NetBT is
disabled, the Computer Browser service can no longer operate. This means that for a network that has
NetBT disabled and is just using the Domain Name System (DNS) and Active Directory, you cannot
view any LAN groups or servers using the Entire Network window. You must use find computers using
Active Directory.

Computer browsing over remote access connections is aided by the NetBT proxy in Windows Server
2008 and Windows Server 2003, which is enabled by default for Routing and Remote Access on all
interfaces that are not connected to the Internet.

For more information about NetBT, see Chapter 11, "NetBIOS over TCP/IP" and Chapter 12 "Windows
Internet Name Service Overview."

The Computer Browser service in Windows performs three processes:

· Collection of browsing information

· Distribution of browsing information

· Servicing of browse client requests

Browsing Collection and Distribution

The browsing collection and distribution processes occur between designated browse server
computers. The following types of browse servers are defined:

· Master Browse Server

A computer that collects and maintains the browse list of available servers within its LAN group and
a list of other LAN groups and their Master Browse Servers. It also distributes the browse list to the
Backup Browse Servers.

· Backup Browse Server

A computer that receives a copy of the browse list from the Master Browse Server, and distributes
information in the browse list to browse clients upon request.

· Domain Master Browse Server

The first domain controller to register the NetBIOS name of Domain[1B] becomes the Domain
Master Browse Server. Besides being a Master Browse Server for its domain, the Domain Master
Browse Server synchronizes the browse list for the Master Browse Servers in the domain that are
located on remote subnets.

Computers are designated the Master Browse Server or a Backup Browse Server through an automatic
election process. For a given LAN group, there is only one Master Browse Server and zero or more
Backup Browse Servers. The number of Backup Browse Servers depends on the number of servers in
the LAN group.

Computers running Windows XP can perform the Master Browse Server and Backup Browse Server
roles. Only a computer running Windows Server 2008 or Windows Server 2003 that is acting as a
domain controller can perform the Domain Master Browse Server role.

The Collection Process

The Master Browse Server performs the collection process by accumulating the following information in
its browse list:

· A list of servers within its LAN group

Periodically, every computer running the Server service within the LAN group broadcasts a Host
Announcement packet to the NetBIOS name LANGroup[1D]. The Server service corresponds to the
File and Printer Sharing for Microsoft Networks component in Network Connections and provides
file and print sharing using the Common Internet File System (CIFS), also known as the Server
Message Block (SMB) protocol. The Master Browse Server processes the Host Announcement
packet and adds or refreshes the sender’s computer name in the list of servers of the LAN group.

· A list of other LAN groups

Periodically, every Master Browse Server of a LAN group broadcasts a Domain Announcement or
Workgroup Announcement packet to the NetBIOS name [01][02]__MSBROWSE__[01][02].
Contained in the Domain Announcement or Workgroup Announcement packet is the LAN group
name and the computer name of the Master Browse Server. Each Master Browse Server stores the
announced LAN group name and its associated Master Browse Server in the browse list.

The Distribution Process

The Master Browse Server distributes the browse list to the Backup Browse server computers that will
service the requests from browse clients. This occurs through the following:

· Local Master Announcement packet

Periodically, the Master Browse Server broadcasts a Local Master Announcement packet to the
NetBIOS name LANGroup[1E]. This packet informs the Backup Browse Servers that a Master
Browse Server for the LAN group still exists. If the Master Browse Server does not periodically sent
a Local Master Announcement packet, a Backup Browse Server starts an election by broadcasting
an Election packet to the NetBIOS name LANGroup[1E]. The election process selects a new
Master Browse Server.

· Browse list pull operation from Master Browse Server to Backup Browse Server

Periodically, each Backup Browse Server contacts the Master Browse Server in its LAN group to
download the browse list. The downloaded browse list includes the list of servers within the LAN
group and the list of other LAN groups and their associated Master Browse Servers.

Figure C-1 shows the collection and distribution process.



Figure C-1 The Computer Browser service collection and distribution processes

Servicing Browse Client Requests

After the browse list has been built by the Master Browse Server and distributed to the Backup Browse
Servers, it can be used to service browse client requests.

Browse clients request the following:

· The list of servers within its LAN group

· The list of servers within another LAN group

· The list of shares on a server
(Còn tiếp)

[ducht]

Obtaining the List of Servers Within its LAN Group

On a computer running Windows XP or Windows Server 2003 that is a member of a workgroup, you
can view the list of servers in its own workgroup by clicking on View Workgroup Computers in the
Network Tasks pane of the My Network Places window. On a computer running Windows XP or
Windows Server 2003 that is a member of a domain, you can view the list of servers in its own domain
by double-clicking your domain name in the Microsoft Windows Network window.

To get the list of servers within its LAN group, the browse client does the following:

1. Upon startup, the browse client broadcasts a Get Backup List Request packet to the NetBIOS name
LANGroup[1D].

2. The Master Browse Server responds to the client request with a list of computer names for Backup
Browse Servers in the LAN group.

3. The client randomly selects one of the Backup Browse Servers. When the user wants to view the list
of servers in its LAN group, the computer sends the selected Backup Browse Server a request for the
servers in its LAN group.

4. The Backup Browse Server responds with the list of servers in the LAN group.

Figure C-2 shows this process.



Figure C-2 Servicing browse client requests

For subsequent requests for a list of servers within its LAN group, the client continues to use the list of
Backup Browse Server names obtained during startup and does not broadcast a new Get Backup List
Request packet. The success of the browse client request is dependent on the client getting a response
from the Master Browse Server and the client’s ability to resolve the computer name of the randomly
selected Backup Browse Server to its IPv4 address.

Obtaining the List of Servers Within Another LAN Group

On a computer running Windows XP or Windows Server 2003 that is a member of a workgroup, you
can view the list of servers in another LAN group by clicking on the LAN group name in the Browse For
Folder dialog box. On a computer running Windows XP or Windows Server 2003 that is a member of a
domain, you can view the list of servers in another LAN group by double-clicking the LAN group name
in the Microsoft Windows Network window.

To get the list of servers within another LAN group, the client broadcasts a Get Backup List Request
packet to the NetBIOS name LANGroup[1D]. The Master Browse Server for that LAN group responds
to the client request with a list of computer names for Backup Browse Servers within the LAN group.
The client then randomly selects one of the Backup Browse Servers and sends it a request to download
the list of servers in the LAN group. The response from the selected Backup Browse Server contains
the list of servers in the LAN group.

The success of this operation depends on the client getting a response from the Master Browse Server
for the LAN group and the client’s ability to resolve the computer name of the randomly selected
Backup Browse Server of the LAN group to an IPv4 address.

Obtaining the List of Shares on a Server

On a computer running Windows XP or Windows Server 2003, you can view the list of shares on a
selected server by double-clicking the computer in the LAN group window. Alternately, you can view the
list of shares of a specific computer from the display of the net view \\servername command.

To get the list of shares on a server, the client computer attempts to resolve the NetBIOS name for the
Server service on the desired computer, which corresponds to ComputerName[20]. After the name is
resolved, a TCP session, a NetBIOS session, and an SMB session are created between the browse
client and the file sharing server. After the SMB session is created, the client requests a list of shares.

Although the request for the list of servers does not involve the Computer Browser service or browse
servers, it is part of the browsing operation done through My Network Places.

The success of this client request is dependent on the client’s ability to resolve the computer name of
the selected computer to its IPv4 address and to establish an authenticated SMB session with the
server.

The Computer Browser Service on Computers Running Windows Server 2008

Windows Server 2008 sets the startup state of the Computer Browser service to disabled by default for
a new installation of Windows Server and when upgrading an existing server to Windows Server 2008.
The default startup state of the Computer Browser service on computers running Windows Server 2008
can cause problems for a domain controller in the primary domain controller flexible single master
operations (PDC FSMO) role. For computer browsing, the computer in the PDC FSMO role centrally
collects and distributes information about domains, workgroups, and computers for multi-subnet
networks. If the computer in the PDC FSMO role is not running the Computer Browser service,
computer browse lists across the network will contain only domains, workgroups, and computers on the
local subnet.

To prevent this problem, configure the startup type for the Computer Browser service for Automatic on
the computer in the PDC FSMO role and then start Computer Browser service. You can do this from
the Services snap-in or at an elevated command prompt with the following commands:

sc config browser start= auto

sc start browser

Because the Computer Browser service relies on the file and printer sharing, you will also need to turn
on File and Printer Sharing in the Network and Sharing Center. Alternatively, move the PDC FSMO role
to another domain controller that has the Computer Browser service started and configured for
automatic startup and File and Printer Sharing turned on in the Network and Sharing Center.

Additionally, if the only server computer on a subnet is running Windows Server 2008, client computers
will become the local browse server on the subnets. As client computers are started and are shut down,
the role of the local browse server will pass from one client computer to another, possibly resulting in an
inconsistent display of domains, workgroups, and computers. To prevent this problem, on the computer
running Windows Server 2008, turn on file and printer sharing, configure the startup type for the
Computer Browser service for Automatic, and then start the Computer Browser service.

Computer Browser Service Operation on an IPv4 Network

Because the Computer Browser service relies on a series of broadcast NetBIOS over TCP/IP packets,
the placement of IPv4 routers can create problems. IPv4 routers do not forward broadcast packets. To
facilitate client browsing of all network resources in an IPv4 network, there must be mechanisms for the
collection, distribution, and servicing of client requests for browse lists when servers, browse servers,
and browse clients are located on different subnets.

The browsing collection, distribution, and the servicing of client requests across IPv4 routers must now
take place using a combination of unicast and broadcast IPv4 traffic, rather than just broadcast IPv4
traffic. To facilitate computer browsing across an IPv4 network, the Computer Browser services uses
the following:

· Windows Internet Name Service (WINS) WINS helps in the collection of browse lists and the
servicing of client requests.

· Entries in the Lmhosts file Special entries in the Lmhosts file help facilitate the distribution of
browsing information and the servicing of client requests.

Note The Computer Browser service relies on media access control (MAC)-level broadcast packets sent
using NetBT to and from UDP port 138 (the NetBIOS datagram port). In contrast, B-node NetBIOS name
registration and name query requests are sent as MAC-level broadcasts over UDP port 137 (the NetBIOS
name service port). Some routers can be configured to forward NetBIOS broadcasts from one IPv4 subnet
to another. If the IPv4 router is configured to forward NetBIOS broadcasts, the Computer Browsing service
works as if all the LAN groups were located on the same subnet. All Master Browse Servers are aware of all
servers in their LAN group and all other LAN groups and all browse client requests can be satisfied.
If NetBIOS broadcast forwarding is enabled on all IPv4 routers in the network, the following sections do not
apply. However, this solution is highly discouraged because it increases the amount of broadcast traffic on
each subnet, leading to decreased performance by all nodes on the network. Enabling broadcast forwarding
can also cause browse server election conflicts.

The following sections examine how the Computer Browser service works across an IPv4 network for
these browsing situations:

· Domain spanning an IPv4 router

· Multiple domains separated by IPv4 routers

· Workgroup spanning an IPv4 router

· Multiple workgroups separated by IPv4 routers
(Còn tiếp)

[ducht]

Domain Spanning an IPv4 Router

Figure C-3 shows a domain that spans an IPv4 router. There are domain members on at least two
different subnets located across an IPv4 router.



Figure C-3 A domain that spans an IPv4 router

For this configuration, the following sections examine:

· The collection and distribution process

· The servicing of browse client requests

Collection and Distribution Process

When using domains that are split across routers, browse server elections occur within each subnet
and each subnet functions as an independent browsing entity with its own Master Browse Server and
Backup Browse Servers.

Each Master Browse Server collects the following for its own subnet:

· The list of servers within its domain, by listening for Host Announcement packets sent by computers in
its domain.

· The list of other LAN groups and their corresponding Master Browse Servers, by listening for Domain
Announcement or Workgroup Announcement packets sent by the Master Browse Servers of other LAN
groups.

If all the servers in the domain existed on one subnet, the Domain Master Browse Server would also be
the Master Browse Server for the domain. In the configuration in Figure C-3, the Domain Master
Browse Server is attached to only one subnet. To facilitate the flow of information for the browse list
across the IPv4 router, the Master Browse Servers on the other subnets must communicate with the
Domain Master Browse Server. The communication between the Domain Master Browse Server and
Master Browse Servers takes two forms:

· Master Browse Servers update the Domain Master Browse Server with their collected list of servers in
the domain and other LAN groups on its subnet.

· Master Browse Servers download the Domain Master Browse Server's browse list, which contains all of
the server names within the domain and all other LAN group names collected by the Domain Master
Browse Server and all other Master Browse Servers on other subnets.

The result is that each Master Browse Server gets the Domain Master Browse Server's browse list. The
Backup Browse Servers on each subnet download the browse list from their local Master Browse
Server.

The communication between the Master Browse Server and Domain Master Browse Server occurs
periodically through unicast IPv4 traffic. The Master Browse Server for each subnet contacts the
Domain Master Browse Server to exchange information. The Master Browse Server resolves the IPv4
address of the Domain Master Browse Server using either:

· WINS If the Master Browse Server is a WINS client, it will query its WINS servers for the NetBIOS
name Domain[1B]. Only the Domain Master Browse Server registers this NetBIOS name.

· Lmhosts file The Master Browse Server can use special entries in the Lmhosts file to locate the
Domain Master Browse Server. The details of these entries are discussed in the “Configuring the
Lmhosts File for an Domain that Spans IPv4 Routers” section of this chapter.

Servicing Browse Client Requests

When servicing browse client requests, the browse client can request the following:

· List of servers within its domain or a LAN group on its subnet

To get the list of servers within its domain or for a LAN group on its subnet, the browse client
initially broadcasts a Get Backup List Request packet to the NetBIOS name LANGroup[1D]. The
Master Browse Server for the LAN group on the browse client’s subnet responds to the browse
client request with a list of computer names for Backup Browse Servers. The browse client then
randomly selects one of the Backup Browse Servers and contacts it directly for a list of servers
within the LAN group.

· List of servers within another LAN group on another subnet

This process is described in the “Multiple Domains Across IPv4 Routers” section of this chapter.

· List of shares on a server

To get the list of shares on a server, the browse client attempts to resolve the NetBIOS name for
the Server service on the desired computer, which corresponds to ComputerName[20]. Once the
name is resolved, a TCP session, a NetBIOS session, and an SMB session are created between
the browse client and the desired server. The list of shares on the server computer is sent over the
SMB session.

Configuring the Lmhosts File for an Domain that Spans IPv4 Routers

To enable direct communication between Master Browse Servers on remote subnets and the Domain
Master Browse Server for computers that are not enabled to use WINS, you must configure the
Lmhosts file with the NetBIOS names and IPv4 addresses of the browse server computers.

The Lmhosts file on each subnet’s Master Browse Server should contain a series of entries for all the
domain controllers of the domain. Each entry must have the following information:

· The IPv4 address and computer name of the domain controller

· The domain name preceded by the #PRE #DOM: tags

The following is an example entry:

131.107.7.80 DC100 #PRE #DOM:EXAMPLE

For this Lmhosts entry, a domain controller for the EXAMPLE domain is a computer named DC100 at
the IPv4 address of 131.107.7.80. By adding entries for all the domain controllers, regardless of which
domain controller becomes the Domain Master Browse Server, the Lmhosts files do not need to be
changed on the other Master Browse Server computers.

When multiple Lmhosts entries exist for the same domain name, a computer running Windows XP or
Windows Server 2003 acting as a Master Browse Server determines which of the entries corresponds
to the Domain Master Browse Server by sending a query to each the IPv4 address. Only the Domain
Master Browse Server responds to the query. The computer then contacts the Domain Master Browse
Server to exchange browse list information.

At each domain controller, the Lmhosts file must be configured with entries for each of the Master
Browse Servers on remote subnets. By default, the Master Browse Server computer is elected using a
set of election criteria. To ensure that a specific computer is elected the Master Browse Server, set the
registry value

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Browser\Parameters\IsDomainMaster to
TRUE (REG_SZ). A computer with IsDomainMaster set to TRUE will typically only lose an election to
the Domain Master Browse Server or other computers with IsDomainMaster set to TRUE.

After you have configured the IsDomainMaster registry value on a designated server computer on each
subnet, add entries to the Lmhosts file on each domain controller for each of the designated Master
Browse Servers. These entries allow the Domain Master Browse Server to determine the set of
computers to contact to distribute the Domain Master Browse Server's browse list.

Multiple Domains Separated By IPv4 Routers

Figure C-4 shows multiple domains that are separated by an IPv4 router.



Figure C-4 Multiple domains separated by an IPv4 router

For this configuration, the following sections examine:

· Collection and distribution process

· Servicing browse client requests

Collection and Distribution Process

Besides collecting the servers in its domain, a Master Browse Server collects the names of other LAN
groups on its subnet. All of this information is sent to the Domain Master Browse Server and distributed
to the other Master Browse Servers for that domain. Browse clients within that domain see the list of all
of the LAN groups that have been collected.

One enhancement WINS adds to the mechanism of collecting LAN group names is that a WINSenabled
Domain Master Browse Server periodically queries the WINS server to obtain a list of all of the
domains from the WINS database. The Domain Master Browse Server queries WINS for all the
NetBIOS names that end with the 0x1B character. All NetBIOS names of this type are NetBIOS domain
names that were registered by Domain Master Browse Servers.

The list of domains obtained through the WINS query only contains the domain names and their
corresponding IP addresses. The list does not include the names of the Domain Master Browse
Servers that registered those names. To obtain the Domain Master Browse Server for the domain, the
Domain Master Browse Server computer sends a NetBIOS Adapter Status message to each IPv4
address corresponding to the NetBIOS computer name Domain[1B] for each domain collected through
the WINS query. The response to the NetBIOS Adapter Status message contains the computer name
of the computer that registered the domain name. In this way, the Domain Master Browse Server
completes its list of domain names and their corresponding Domain Master Browse Servers.

The advantage of this process is that the Domain Master Browse Server for any domain now has a list
of all domains (for those Domain Master Browse Servers that are WINS clients or have static WINS
entries), including those on remote subnets that are not spanned by its domain.

(Còn tiếp)

[ducht]

Servicing WINS-enabled Client Requests for Remote Domains

When a client requests a list of servers from a domain other than its own, the process for resolving the
Master Browse Server for the domain depends on the client type. For WINS clients, the client
broadcasts a Get Backup List Request packet to the NetBIOS name LANGroup[1D] to get a list of
Backup Browse Servers from a local Master Browse Server. Because the browse client is requesting a
set of Backup Browse Servers for a remote domain, it will not receive a response to the broadcasted
Get Backup List Request packet.

The client then requests the IPv4 address of the domain’s Domain Master Browse Server from WINS
by querying for the NetBIOS name Domain[1B]. The WINS name query will only be successful for
domains for which the Domain Master Browse Server is a WINS client or has a static WINS entry.

If the client receives a positive name response from the WINS server, the following process occurs:

1. The client sends a unicast Get Backup List Request packet to the IPv4 address of the Domain
Master Browse Server (corresponding to the NetBIOS name Domain[1B]).

2. The Domain Master Browse Server responds with a list of Backup Browse Servers. The client
randomly selects one of the Backup Browse Servers and uses a WINS query (for the NetBIOS name
BackupBrowseServerName[20]) to get the IPv4 address of the selected Backup Browse Server for
the domain.

3. The browse client then connects to the Backup Browse Server and requests a list of servers in its
domain.

4. The Backup Browse Server returns the list of servers to the browse client.

Figure C-5 shows this process.



Figure C-5 Servicing a WINS-enabled client requests for a positive WINS server response

The browse client may receive a negative name response for the NetBIOS name query LANGroup[1B]
if the LAN group is a workgroup, the domain controller for the domain is not a WINS client or has a
static WINS entry, or if the domain controller for the domain is a WINS client and the domain controller
and the browse client are not sharing a common WINS database (via replication). If the browse client
receives a negative name response from the WINS server, the following process occurs:

1. The browse client makes a connection with its local Master Browse Server and requests the name of
the Master Browse Server of the desired LAN group.

2. The local Master Browse Server returns the name of the Master Browse Server that advertised the
LAN group.

3. The client resolves the NetBIOS name of the Master Browse Server that advertised the LAN group
(MasterBrowseServerName[20]) and makes a connection with that Master Browse Server to request
a list of servers in the LAN group.

4. The Master Browse Server returns the list of servers in the LAN group to the browse client.

Figure C-6 shows this process.



Figure C-6 Servicing WINS-enabled client requests with a negative WINS server response

Servicing non-WINS Client Requests for Remote Domains

For browse clients that are not using WINS, the process for obtaining a list of servers in a remote
domain is the following:

1. The client broadcasts a Get Backup List Request packet to the NetBIOS name Domain[1D] to get a
list of Backup Browse Servers from a local Master Browse Server. The client also broadcasts a
NetBIOS name query for the NetBIOS name Domain[1B]. Since the client is attempting to obtain a
list of servers in a remote domain, there is no response to this broadcasted query.

2. The client makes a connection with its local Master Browse Server and requests the name of the
Master Browse Server of the desired domain.

3. The local Master Browse Server returns the name of the Master Browse Server that advertised the
domain.

4. The client resolves the NetBIOS name of the Master Browse Server that advertised the LAN group
(MasterBrowseServerName[20]) and makes a connection with that Master Browse Server to request
a list of servers in the LAN group.

5. The Master Browse Server returns the list of servers in the LAN group to the browse client.

Figure C-7 shows this process.



Figure C-7 Servicing a browse client request for a remote domain when WINS is not enabled

This process works for both domains and workgroups.

The success of this process depends on the following:

· The local Master Browse Server has the name of the Master Browse Server that advertised its LAN
group in its browse list. This information is available for those LAN groups that were collected through
Domain Announcement or Workgroup Announcement packets and for those domain names collected
through the WINS query for all names ending with 0x1B.

· The client is able to resolve the NetBIOS name of the Master Browse Server
(MasterBrowseServerName[20]) of the remote LAN group. For a browse client that is not using WINS,
entries must be added to the Lmhosts file for the Master Browse Servers of remote LAN groups.

If the Domain Master Browse Servers for different domains are not WINS-enabled and the domains do
not span a common subnet, the domains become stranded. They never appear in each other's browse
lists. It is possible to browse a stranded domain by name by using the net view /d:domain command.
However, this command is only successful if the browse client can resolve the NetBIOS name
Domain[1B]. For browse clients on which WINS is not enabled, you can add an entry to the local
Lmhosts file for the NetBIOS name Domain[1B] with the IPv4 address of the Domain Master Browse
Server for that domain.
(Còn tiếp)