Microsoft® Windows® 2000 Server Resource Kit Internetworking Guide

Disclaimer:

This book is based on Microsoft® Windows® 2000 applications and technologies that are under development. Future versions of this book will reflect subsequent changes in Windows 2000.

© 1985-1999 Microsoft Corporation. All rights reserved.


Unicast Routing Overview

Unicast routing is the process of forwarding unicasted traffic from a source to a destination on an internetwork. Unicasted traffic is destined for a unique address. To understand the details of routing protocols, such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), and their implementation in Microsoft® Windows® 2000 Server, it is important to have a solid foundation in the principles of unicast routing. Because Windows 2000, with the Routing and Remote Access Service (Rremote access), is an open platform that can conceivably host any internetworking protocol and routing protocol, this chapter provides an overview of protocol-independent unicast routing principles. The Internet Protocol (IP) and the Internetwork Packet Exchange (IPX) protocol are used as the example protocols where appropriate.

In This Chapter

Internetwork Routing

Routing Concepts

Foundations of Routing Protocols

Routing Infrastructure

Related Chapters in the Resource Kit

  • For more information about Unicast IP, see “Unicast IP Routing” in this book.
  • For more information about IPX routing support, see “IPX Routing” in this book.
  • For more information about virtual private networks, see “Virtual Private Networks” in this book.

Additional Resources

  • For more information about Internet routing see, Routing in the Internet by Christian Huitema, 1995, Englewood Cliffs, NJ: Prentice Hall.
  • For more information about Internet routing see, Interconnections: Bridges and Routers by Radia Perlman, 1992, Reading, MA: Addison-Wesley.


Internetwork Routing

The following terms are essential to your understanding of routing:

End Systems. As defined by the International Standards Organization (ISO), end systems are network devices without the ability to forward packets between portions of a network. End systems are also known as hosts.

Intermediate Systems. Network devices with the ability to forward packets between portions of a network. Bridges, switches, and routers are examples of intermediate systems.

Network. A portion of the networking infrastructure (encompassing repeaters, hubs, and bridges/Layer 2 switches) that is bound by a network layer intermediate system and is associated with the same network layer address.

Router. A network layer intermediate system used to connect networks together based on a common network layer protocol.

Hardware Router. A router that performs routing as a dedicated function and has specific hardware designed and optimized for routing.

Software Router. A router that is not dedicated to performing routing but performs routing as one of multiple processes running on the router computer. The Windows 2000 Server Router Service is a software router.

Internetwork. At least two networks connected using routers. Figure 1.1 illustrates an internetwork.

Figure 1.1 An Internetwork

Addressing in an Internetwork

The following internetwork addressing terms are also important to your understanding of routing:

Network address.
Also known as a network ID. The number assigned to a single network in an internetwork. Network addresses are used by hosts and routers when routing a packet from a source to a destination in an internetwork.
Host address.
Also known as a host ID or a node ID. Can either be the host’s physical address (the address of the network adapter) or an administratively assigned address that uniquely identifies the host on its network.
Internetwork address.
The combination of the network address and the host address; it uniquely identifies a host on an internetwork. An IP address that contains a network ID and a host ID is an internetwork address.

For detailed information on how IP implements network ID and host ID addressing, see “Introduction to TCP/IP” in the Windows 2000 TCP/IP Core Networking book.

When a packet is sent from a source host to a destination host on an internetwork, the Network layer header of the packet contains:

  • The Source Internetwork Address, which contains a source network address and source host address.
  • The Destination Internetwork Address, which contains a destination network address and destination host address.
  • A Hop Count, which either starts at zero and increases numerically for each router crossed to a maximum value, or starts at a maximum value and decreases numerically to zero for each router crossed. The hop count is used to prevent the packet from endlessly circulating on the internetwork.


Routing Concepts

Routing is the process of transferring data across an internetwork from a source host to a destination host. Routing can be understood in terms of two processes: host routing and router routing.

Host routing occurs when the sending host forwards a packet. Based on the destination network address, the sending host must decide whether to forward the packet to the destination or to a router. In Figure 1.2, the Source Host forwards the packet destined for the Destination Host to Router 1.

Router routing occurs when a router receives a packet that is to be forwarded. The packet is forwarded between routers (when the destination network is not directly attached to the router) or between a router and the destination host (when the destination network is directly attached). In Figure 1.2, Router 1 forwards the packet to Router 2. Router 2 forwards the packet to the Destination Host.

Figure 1.2 The Routing Process


Host Routing

When a host using a routable protocol wants to send data to another host, it must first obtain the internetwork address of the destination. The destination internetwork address is obtained through an address resolution process whereby the sending host obtains the destination internetwork address by referencing its logical name. For example, TCP/IP hosts use Domain Name System (DNS) name resolution to resolve a DNS domain name to an IP address. Novell NetWare workstations query the bindery (a database stored on a NetWare server) or directory tree of their default server to resolve a server name to its IPX internetwork address.

Once the destination internetwork address has been obtained, the source network and the destination network addresses are compared. When the source and destination hosts are on the same network, the packets are sent directly to the destination host by the source without the use of a router (see Figure 1.3). The source host sends the packet to the destination by addressing the packet to the destination’s physical address. This is known as a direct delivery. In a direct delivery, the destination internetwork address and the destination physical address are for the same end system.

Conversely, when the source and destination hosts are on different networks, the packets to the destination cannot be directly delivered by the source. Instead, the source delivers them to an intermediate router (see Figure 1.3) by addressing the packet to the router’s physical address. This is known as an indirect delivery. In an indirect delivery, the destination internetwork address and the destination physical address are not for the same end system.

During an indirect delivery, the sending host forwards the packet to a router on its network by determining the router corresponding to the first hop or by discovering the entire path from the source to the destination.

Figure 1.3 Host Routing Process

Host Determination of the First Hop

IP and IPX sending hosts determine the physical address of the first hop router using one of the following processes:

  • Host routing table

    A routing table on the host yields the forwarding address of the router to be used to reach the desired destination network ID. An example is the IP routing table on a Microsoft TCP/IP host. See “Routing Tables” later in this chapter for a detailed definition of a routing table.

  • Dynamic updates of host routing table

    TCP/IP has a facility to dynamically update the host routing table with better routes as packets are sent to destinations. The Internet Control Message Protocol (ICMP) Redirect Message is sent by an IP router to a sending host informing it of a better route to a destination host. The better route becomes a host route in the routing table.

  • Eavesdropping

    TCP/IP hosts have the ability to listen to the routing protocol traffic used by routers. This is known as eavesdropping or wiretapping. Eavesdropping hosts have the same routing information as the routers. An example of eavesdropping is Silent RIP. Silent RIP is the ability of a TCP/IP host to listen to RIP for IP routing traffic exchanged by RIP routers and update its routing table. Microsoft® Windows® NT Server 3.51 and Service Pack 2 and later, Microsoft® Windows NT® Workstation 4.0 and Service Pack 4 and later support Silent RIP.

  • Default router

    To simplify the configuration of hosts and routers and to reduce the overhead associated with each host having routes for all the networks in the internetwork, a sending host is configured with a single default route. The default route and its forwarding address to the default router are used when no other routes to the destination network are found. The Default Gateway for TCP/IP hosts is a default router.

  • Querying the network for the best route

    For hosts without a routing table or a configured default router, the sending host can determine the physical address of the first hop router by querying the routers on the network. A query for the best route to a specified destination network address is sent as a broadcast or multicast packet. The responses from the routers are analyzed by the sending host, and the best router is chosen. An example of this querying process is the RIP GetLocalTarget message sent by an IPX host. The RIP GetLocalTarget message contains a desired destination IPX network ID. IPX routers on the sending host’s network that can reach the destination IPX network ID send a response to the sending host. Based on the RIP responses from the local routers, the sending host chooses the best router to forward the IPX packet.

Host Determination of the Entire Path

When using some routable protocols, the sending host does more than determine the first hop. The source host goes through a route discovery process and determines the path between the sending host and the destination. The list of networks or routers is then included in the Network layer header and is used by the routers to forward the packet along the indicated path. This process is known as source routing.

In source routing, the routers are only acting as store and forward devices because the routing decisions have already been made by the sending host. Source routing is not typically implemented as a method of routing because the path either needs to be known or discovered. Source route discovery processes tend to be traffic intensive and slow. IP routing is normally done through routing decisions made by sending hosts and IP routers based on local routing tables. However, it is sometimes desired, in network testing and debugging situations, for the network administrator to specify an exact route through the IP internetwork that overrides the path that would normally be taken. This is known as IP source routing.

In IP source routing, the entire route is specified by the sending host through the IP addresses of successive IP routers between the source and destination. At each IP router, the IP datagram is addressed to the next router using the Destination IP address field of the IP header.

IP supports two types of source routing. The first type is loose source routing, in which the IP address of the next router can be one or more routers away (multiple hops). The second type is strict source routing, in which the next router must be a neighboring router (single hop).

Note

Token Ring source routing is a MAC-sublayer routing scheme and does not apply to the internetwork-based source routing discussed above.


Router Routing

When a router is forwarded a packet that is not destined for that router, the router must either deliver it to the destination host or to another router, as shown in Figure 1.4.

  • If the destination network matches a network to which the router is attached, the router forwards the packet to the destination host by addressing the packet to the destination host’s physical address. The router performs a direct delivery to the destination.
  • Conversely, if the destination network is not directly attached, the router forwards the packet to an intermediate router. The intermediate router chosen is based on the forwarding address of the optimal route in the routing table. The router forwards the packet by addressing the packet to the intermediate router’s physical address. The router performs an indirect delivery to the next router in the path to the destination.

Figure [image]. Router Routing Process


Routing Tables

During the routing process, the routing decisions of hosts and routers are aided by a database of routes known as the routing table. The routing table is not exclusive to a router. Depending on the routable protocol, hosts may also have a routing table that may be used to decide the best router for the packet to be forwarded. IP hosts have a routing table. IPX hosts do not have a routing table.

The types of possible entries in a routing table include:

Network Route. A route to a specific Network ID in the internetwork.

Host Route. A route to a specific internetwork address (Network ID and Host ID). Instead of making a routing decision based on just the network ID, the routing decision is based on the combination of network ID and host ID. Host routes allow intelligent routing decisions to be made for each internetwork address. Host routes are typically used to create custom routes to control or optimize specific types of internetwork traffic.

Default Route. A route that is used when no other routes for the destination are found in the routing table. For example, if a router or end system cannot find a network route or host route for the destination, the default route is used. Rather than being configured with routes for all the Network IDs in the internetwork, the default route is used to simplify the configuration of end systems or routers.

Routing Table Structure

As illustrated in Figure 1.5, entries in the routing table usually consist of the following fields:

  • Network ID

    The Network ID field contains the identification number for a network route or an internetwork address for a host route.

  • Forwarding Address

    The Forwarding Address field contains the address to which the packet is to be forwarded. The forwarding address can be a network adapter address or an internetwork address. For network IDs to which the end system or router is directly attached, the Forwarding Address field may be blank.

  • Interface

    The Interface field indicates the network interface that will be used when forwarding packets to the network ID. This is a port number or other type of logical identifier. For example, the interface for a 3-COM Etherlink III network adapter may be referred to as ELNK3 in the routing table.

  • Metric

    The Metric field indicates the preference for a route. If multiple routes exist to a given destination network ID, the metric is used to decide which route is to be taken. The metric is an indication of the cost of the route; therefore, the lowest metric is the preferred route. Some routing algorithms only store a single route to any Network ID in the routing table even when multiple routes exist. In this case, the metric is used by the router to decide which route to store in the routing table.

Metrics can indicate different ways of expressing a route preference:

Hop Count.
A common metric. Indicates the number of routers (hops) in the path to the network ID.
Delay.
A measure of time that is required for the packet to reach the network ID. Delay is used to indicate the speed of the path—local area networks (LAN) links have a low delay, wide area network (WAN) links have a high delay—or a congested condition of a path.
Throughput.
The effective amount of data that can be sent along the path per second. Throughput is not necessarily a reflection of the bit rate of the link, as a very busy Ethernet link may have a lower throughput than an unutilized 64-Kbps WAN link.
Reliability.
A measure of the path constancy. Some types of links are more prone to link failures than others. For example, with WAN links, leased lines are more reliable than dial-up lines.
  • Lifetime

    The Lifetime field indicates the lifetime that the route is considered valid. When routes are learned through the exchange of information with other routers, this is an additional field that is used. Learned routes have a finite lifetime. To keep a learned route in the routing table, the route must be refreshed through a periodic process. If a learned route’s lifetime expires, it is removed from the routing table. The timing out of learned routes provides a way for routers to reconfigure themselves when the topology of an internetwork changes due to a downed link or a downed router.

Figure 1.5 Routing Table Structure

Note

The Lifetime field is typically not visible in routing tables.

This list of fields is a representative list in the routing tables. Actual fields in the routing tables for different routable protocols may vary. For information about the IP routing table, see “Introduction to TCP/IP” in the Windows 2000 TCP/IP Core Networking book. For information about the IPX routing table, see “IPX Routing” in this book.

Locality of the Routing Table

All the routing decisions made by the end system or the router are based on information in a local routing table that physically resides in the random access memory (RAM) of the system making the routing decision. There is no single, holistic view of the internetwork that is being gathered by a server and downloaded to each end system and router so that all users have the same view of the internetwork and all traffic flows along predictable pathways.

Each router in a path between a source and destination makes a local routing decision based on its local routing table. The path taken from the source to the destination may not be the same as the path for response packets from the destination back to the source. If the information in the local routing tables of the end systems or routers is incorrect due to misconfiguration or changing network conditions, then routing problems can result. Troubleshooting routing problems may involve the analysis of the routing tables of the end systems (source and destination) and all the routers forwarding packets between them.

For information about the operation and troubleshooting of IP routing, see “Unicast IP Support” in this book. For information about the operation and troubleshooting of IPX routing, see “IPX Routing” in this book.


Static and Dynamic Routers

For routing between routers to work efficiently in an internetwork, routers must have knowledge of other network IDs or be configured with a default route. On large internetworks, the routing tables must be maintained so that the traffic always travels along optimal paths. How the routing tables are maintained defines the distinction between static and dynamic routing.

  • Static Routing

    A router with manually configured routing tables is known as a static router. A network administrator, with knowledge of the internetwork topology, manually builds and updates the routing table, programming all routes in the routing table. Static routers can work well for small internetworks but do not scale well to large or dynamically changing internetworks due to their manual administration.

    Static routers are not fault tolerant. The lifetime of a manually configured static route is infinite and, therefore, static routers do not sense and recover from downed routers or downed links.

    A good example of a static router is a multihomed computer running Windows 2000 (a computer with multiple network adapters). Creating a static IP router with Windows 2000 is as simple as installing multiple network adapters, configuring TCP/IP, and enabling IP routing.

  • Dynamic Routing

    A router with dynamically configured routing tables is known as a dynamic router. Dynamic routing consists of routing tables that are built and maintained automatically through an ongoing communication between routers. This communication is facilitated by a routing protocol, a series of periodic or on-demand messages containing routing information that is exchanged between routers. Except for their initial configuration, dynamic routers require little ongoing maintenance, and therefore can scale to larger internetworks.

    Dynamic routing is fault tolerant. Dynamic routes learned from other routers have a finite lifetime. If a router or link goes down, the routers sense the change in the internetwork topology through the expiration of the lifetime of the learned route in the routing table. This change can then be propagated to other routers so that all the routers on the internetwork become aware of the new internetwork topology.

    The ability to scale and recover from internetwork faults makes dynamic routing the better choice for medium, large, and very large internetworks.

    A good example of a dynamic router is a computer with Windows 2000 Server and the Routing and Remote Access Service running the Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) routing protocols for IP and RIP for IPX.


Routing Problems

Routing problems can occur when either the host or router’s routing tables contains information that does not reflect the correct topology of the internetwork.

Routing Loops

During the router routing process, the packet are forwarded in the optimal direction according to the information in the local routing table. If the routing table entries on all the routers are correct, the packet takes the optimal path from the source to the destination. However, if any routing table entries are not correct, either though a misconfiguration or through learned routes that do not accurately reflect the topology of the internetwork, then routing loops can form. A routing loop is a path through the internetwork for a network ID that loops back onto itself.

Figure 1.6 illustrates a routing loop in which:

  • According to the routing table on Router 1, the optimal route to Network 10 is through Router 2.
  • According to the routing table on Router 2, the optimal route to Network 10 is through Router 3.
  • According to the routing table on Router 3, the optimal route to Network 10 is through Router 1.

The hop count in the Network layer header is used to prevent the packet from perpetually looping. Each time a router passes the packet from one network to another, it either increases or decreases the hop count. If the hop count reaches its maximum value (when increasing) or is 0 (when decreasing), the packet is discarded by the router.

For example, IPX hosts send IPX packets with a 0 hop count. Each RIP for IPX router increases the hop count by one. When it reaches 16, the packet is silently discarded. When IP hosts send IP packets, they set a maximum hop count in the Time-to-Live (TTL) field in the IP header. Each IP router encountered decreases the TTL by one. When the TTL is 0, the IP router discards the packet and sends an ICMP Time Exceeded message back to the sending host. By default, Windows NT 4.0 and later TCP/IP hosts set the TTL to the default value of 128.

Figure 1.6 A Routing Loop

Black Holes

Common internetworking protocols such as IP and IPX are connection-less, datagram-based protocols. They do not guarantee a successful delivery. IP and IPX attempt a best effort, unacknowledged delivery to the next hop or the final destination. This behavior can lead to conditions on the internetwork in which data is lost.

If a downstream router goes down and is not detected by the upstream router, the upstream router still forwards the packets to the downed router. Because the failed downstream router does not receive them, the packets forwarded by the upstream router are dropped from the internetwork. The upstream router is sending packets to a black hole, an area of the internetwork in which packets are lost. In Figure 1.7, Router 1 has not been informed that Router 2 has failed and continues to forward packets to Router 2. The failed Router 2 is a black hole.

Figure 1.7 A Routing Black Hole

Black holes form when a link or router fails, and the failure is not yet detected. In a static routing environment, black holes persist until the link or router is brought back up or the static routers are reconfigured by the network administrator. In a dynamic routing environment, routers sense downed links or routers through the expiration of the lifetime of learned routes in their routing tables.

Note

This section discusses routing black holes in terms of a downed router or a downed link. Black holes can also be created when routers discard packets without notification to users. An example is a black hole Path Maximum Transmit Unit (PMTU) IP router that silently discards IP packets that need to be fragmented when the Don’t Fragment bit is set.


Routers and Broadcast Traffic

Internetwork-level broadcasts are Media Access Control (MAC)-level broadcast frames with a special destination internetwork address that informs the router that the packet is to be forwarded to all other networks except the network on which it was received. Routers must be configured to pass internetwork-level broadcast traffic. A MAC-level broadcast frame is used to reach all the hosts on a network. Routers, unlike bridges, do not forward MAC-level broadcast traffic. However, to reach all the hosts on an internetwork, some routable protocols support the use of internetwork-level broadcasts.

The inherent danger of forwarding internetwork-level broadcasts is the possibility of an internetwork-level broadcast storm in which a host malfunctions and continuously sends out the same internetwork-level broadcast packet. If the routers forward this traffic, the result is that all the hosts on the internetwork process each broadcast frame, possibly crippling the entire internetwork.

The NetBIOS over IPX broadcast is an internetwork-level broadcast. NetBIOS applications on an IPX internetwork use a NetBIOS over IPX broadcast to perform name registration, resolution, and release. When the NetBIOS over IPX broadcast packet is received by an IPX router, the router records the network on which the packet was received in the NetBIOS over IPX header. Thus, the internetwork path is recorded in the NetBIOS over IPX header as it traverses the IPX internetwork.

Before being forwarded, the IPX router checks the internetwork path information to prevent the forwarding of the NetBIOS over IPX broadcast onto a network on which it has already traveled. This prevents the broadcast from looping and causing more broadcast traffic. As an additional safeguard, NetBIOS over IPX broadcast packets can only propagate across eight networks using seven routers. At the eighth router, the packet is discarded without notifying the sending host. This is known as a silent discard. For more information about NetBIOS over IPX broadcasts, see “IPX Routing” in this book.

Note

An IPX internetwork path is recorded in a similar fashion to the MAC-sublayer routing information in a Token Ring source routing Explorer frame. However, unlike Token Ring source routing, the IPX internetwork path is not used in the subsequent communication. The IPX internetwork path is only used to prevent the broadcast packet from being forwarded on the same IPX network more than once.


Tunneling

Tunneling, also known as encapsulation, is a method of using an internetwork infrastructure of one protocol to transfer a payload, the frames (or packets) of another protocol (see Figure 1.8). Instead of sending the frame as it is produced by the originating host, the frame is encapsulated with an additional header. The additional header provides routing information so the encapsulated payload can traverse an intermediate internetwork (also known as a transit internetwork). The encapsulated packets are then routed between tunnel endpoints over the transit internetwork. Once the encapsulated payload packets reach their destination on the transit internetwork, the frame is de-encapsulated and forwarded to its final destination.

The entire process of encapsulation, transmission, and de-encapsulation of packets is known as tunneling. The logical path through which the encapsulated packets travel through the transit internetwork is called a tunnel.

Figure 1.8 Tunneling

The transit internetwork can be any internetwork. The Internet is a good example as the most widely known public internetwork. There are also many examples of tunnels that are carried over corporate internetworks.

Some common types of tunneling:

  • SNA Tunneling over IP internetworks

    To send System Network Architecture (SNA) traffic across a corporate IP internetwork, the SNA frame is encapsulated with a user datagram protocol (UDP) and IP header. This is known as Data Link Switching (DLSw) and is described in Request for Comments (RFC) 1434.

  • IPX Tunneling for Novell NetWare

    IPX packets are sent to a NetWare server or IPX router that wraps the IPX packet with a UDP and IP header and sends them across an IP internetwork. The destination IP router removes the UDP and IP header and forwards them to the appropriate IPX destination.

  • Point-to-Point Tunneling Protocol (PPTP)

    PPTP allows IP, IPX, or NetBEUI traffic to be encrypted and encapsulated in an IP header to be sent across a corporate IP internetwork or public internetworks like the Internet. PPTP is discussed in greater detail in “Virtual Private Networking” in this book.

  • Layer 2 Tunneling Protocol (L2TP)

    L2TP allows IP, IPX, or NetBEUI traffic to be encrypted and then sent over any medium that supports point-to-point datagram delivery such as IP, X.25, Frame Relay, or ATM. L2TP is discussed in greater detail in “Virtual Private Networking” in this book.

  • IP Security (IPSec) Tunnel Mode

    IPSec Tunnel Mode allows IP payloads to be encrypted and then encapsulated in an IP header to be sent across a corporate IP internetwork or public internetworks like the Internet. For more information about IPSec, see “Internet Protocol Security” in the Windows 2000 TCP/IP Core Networking book.

Note

Windows 2000 Server only ships with support for the PPTP, L2TP, and IPSec tunneling discussed above.


Foundations of Routing Protocols

Dynamic routers use routing protocols to facilitate the ongoing communication and dynamic updating of routing tables. Routing protocols are used between routers and represent additional network traffic overhead on the network. This additional traffic can become an important factor in planning WAN link usage. RIP and OSPF for IP, and RIP and NLSP for IPX are all routing protocols. In some cases, such as RIP for IP (version 1) and RIP for IPX, the routing information is exchanged using MAC-level broadcasts.

An important element of a routing protocol implementation is its ability to sense and recover from internetwork faults. How quickly it can recover is determined by the type of fault, how it is sensed, and how the routing information is propagated through the internetwork.

When all the routers on the internetwork have the correct routing information in their routing tables, the internetwork has converged. When convergence is achieved, the internetwork is in a stable state and all routing occurs along optimal paths.

When a link or router fails, the internetwork must reconfigure itself to reflect the new topology. Information in routing tables must be updated. Until the internetwork reconverges, it is in an unstable state in which routing loops and black holes can occur. The time it takes for the internetwork to reconverge is known as the convergence time. The convergence time varies based on the routing protocol and the type of failure (downed link or downed router).

Routing protocols are based either on a distance vector or link state technology. The main differences between distance vector and link state routing protocols include the following:

  • What routing information is exchanged.
  • How the information is exchanged.
  • How quickly the internetwork can recover from a downed link or a downed router.


Distance Vector

Routers use distance vector–based routing protocols to periodically advertise the routes in their routing tables. Routing information exchanged between typical distance vector–based routers is unsynchronized and unacknowledged. Table 1.1 lists some distance vector–based routing protocols.

Table 1.1 Distance Vector–based Routing Protocols

Routable Protocol | Distance Vector–based Routing Protocols
IP | Routing Information Protocol (RIP) Interior Gateway Routing Protocol (IGRP)
IPX | Routing Information Protocol (RIP)
AppleTalk | Routing Table Maintenance Protocol (RTMP)

Advantages of distance vector–based routing protocols

  • Simpler. Distance vector–based routing protocols are simple router advertisement processes that are easy to understand.
  • Easy to configure. In its simplest incarnation, configuring a distance vector–based routing protocol is as easy as enabling it on the router interfaces.

Disadvantages of distance vector–based routing protocols

  • Large routing tables. Multiple routes to a given network ID can be reflected as multiple entries in the routing table. In a large internetwork with multiple paths, the routing table can have hundreds or thousands of entries.
  • High network traffic overhead. Route advertising is done periodically even after the internetwork has converged.
  • Does not scale. Between the size of the routing table and the high overhead, distance vector–based routing protocols do not scale well to large and very large internetworks.
  • High convergence time. Due to the unsynchronized and unacknowledged way that distance vector information is exchanged, convergence of the internetwork can take several minutes. While converging, routing loops and black holes can occur.


Link State

Routers using link state–based routing protocols exchange link state advertisements throughout the internetwork to update routing tables. Link state router advertisements consist of a router’s attached network IDs and are advertised upon startup and when changes in the internetwork topology are sensed. Link state updates are sent using directed or multicast traffic rather than broadcasting. Link state routers build a database of link state advertisements and use the database to calculate the routing table. Routing information exchanged between link state–based routers is synchronized and acknowledged. Table 1.2 lists some link state routing protocols.

Table 1.2 Link State–based Routing Protocols

Routable Protocol | Link State–based Routing Protocol
IP | Open Shortest Path First (OSPF)
IPX | NetWare Link Services Protocol (NLSP)

Advantages of link state routing protocols

  • Smaller routing tables. Only a single optimal route for each network ID is stored in the routing table.
  • Low network overhead. Link state–based routers do not exchange any routing information when the internetwork has converged.
  • Ability to scale. Between the smaller routing tables and low overhead, link state–based routing protocols scale well to large and very large internetworks.
  • Lower convergence time. Link state–based routing protocols have a much lower convergence time and the internetwork is converged without routing loops.

Disadvantages of link state routing protocols

  • Complex. Link state–based routing protocols are much more complex and difficult to understand than distance vector–based routing protocols.
  • More difficult to configure. A link state–based routing protocol implementation requires additional planning and configuration.


Routing Infrastructure

The routing infrastructure is the entire structure of the routed internetwork. The infrastructure has important attributes to consider when you are deciding on which routable protocols and routing protocols to use.


Single vs. Multipath

In a single-path routing infrastructure, only a single path exists between any two networks in the internetwork. While this may simplify the routing tables and the packet flow paths, single-path internetworks are not fault tolerant. A fault can be sensed with a dynamic router, but the networks across the failure are unreachable for the duration of the fault. A downed link or a downed router must be brought back up before packets can be delivered successfully across the downed link or router.

In a multipath routing infrastructure, multiple paths exist between networks in the internetwork. Multipath internetworks are fault tolerant when dynamic routing is used, and some routing protocols, such as OSPF, can balance the load of network traffic across multiple paths with the same metric value. Multipath internetworks, however, can be more complex to configure and can have a higher probability of routing loops during convergence when using distance vector–based routing protocols.


Flat vs. Hierarchical

In a flat routing infrastructure, each network ID is represented individually in the routing table. The network IDs have no network/subnetwork structure and cannot be summarized. RIP-based IPX internetworks use flat network addressing and have a flat routing infrastructure.

In a hierarchical routing infrastructure, groups of network IDs can be represented as a single routing table entry through route summarization. The network IDs in a hierarchical internetwork have a network/subnetwork/sub-subnetwork structure. A routing table entry for the highest level (the network) is also the route used for the subnetworks and sub-subnetworks of the network. Hierarchical routing infrastructures simplify routing tables and lower the amount of routing information that is exchanged, but they require more planning. IP implements hierarchical network addressing, and IP internetworks can have a hierarchical routing structure.

In hierarchical routing infrastructures, the internetwork can be divided into routing domains (also known as regions or areas). A routing domain is a collection of contiguous networks connected by routers that share the routing information for the routes within the domain. Routing domains are connected by a common routing domain called the backbone. Intra-domain routing is performed by the routers within the domain. Inter-domain routing is performed by domain routers connected to the backbone.


Autonomous Systems

In very large internetworks, it is necessary to divide the internetwork into separate entities known as autonomous systems, as shown in Figure 1.9. An autonomous system (AS) is a portion of the internetwork under the same administrative authority. The administrative authority can be an institution or corporation but can also be defined by the use of a routing protocol such as OSPF. The contiguous portion of an IP internetwork that is using OSPF to distribute routing information is under OSPF administrative authority and is, therefore, an OSPF AS. The AS may be further divided into regions, domains, or areas that define a hierarchy within the AS.

The protocols used to distribute routing information within an AS are known as Interior Gateway Protocols (IGPs). The protocols used to distribute routing information between ASs are known as Exterior Gateway Protocols (EGPs).

Figure 1.9 Autonomous Systems with IGPs and EGPs

Interior Gateway Protocols (IGPs)

IGPs are intra-AS routing protocols. IGPs distribute routes within the AS in either a flat or hierarchical manner.

The following are IGPs for IP internetworks:

RIP for IP. An RFC-based distance vector IGP.

OSPF. An RFC-based link state IGP.

Interior Gateway Routing Protocol (IGRP). A distance vector IGP developed by Cisco Systems, Inc.

Exterior Gateway Protocols (EGPs)

EGPs are inter-AS routing protocols. EGPs define the way that all of the networks within the AS are advertised outside of the AS. This can include a list of network routes in a flat routing infrastructure or a list of summarized network routes in a hierarchical routing infrastructure. EGPs are independent of the IGPs used within the AS. EGPs can facilitate the exchange of routes between ASs that use different IGPs.

The following are EGPs for IP internetworks:

Exterior Gateway Protocol (EGP).
An RFC-based EGP that was developed for use between ASs on the Internet. EGP is no longer used on the Internet due to its lack of support for complex, multipath environments and Classless Inter-Domain Routing (CIDR).
Border Gateway Protocol (BGP).
An RFC-based EGP that is currently used between ASs on the Internet. BGP overcomes the weaknesses of EGP.


Unicast IP Routing

Microsoft® Windows® 2000 provides extensive support for unicast (Internet Protocol) IP routing (routing to a unicast destination IP address) with the unicast IP routing protocols and features of the Windows 2000 Router. Your implementation of unicast routing can be simple or complex depending on the size of your IP internetwork, the use of Dynamic Host Configuration Protocol (DHCP) to allocate IP address configuration, connectivity to the Internet, the presence of non-Microsoft or legacy hosts on your internetwork, and other factors.

In This Chapter

Windows 2000 and IP Routing

RIP for IP

OSPF

DHCP Relay Agent

Network Address Translator

IP Packet Filtering

ICMP Router Discovery

Related Chapters in the Resource Kit

  • For more information about unicast routing, see “Unicast Routing Overview” in this book.
  • For more information about Windows 2000 and IPX routing, see “IPX Routing” in this book.
  • For more information about the Windows 2000 Router, see “Windows 2000 Router” in this book.

Additional Resources

  • For more information about Internet routing see, Routing in the Internet by Christian Huitema, 1995, Englewood Cliffs, NJ: Prentice Hall.
  • For more information about Internet routing see, Interconnections: Bridges and Routers by Radia Perlman, 1992, Reading, MA: Addison-Wesley.


Windows 2000 and IP Routing

An Internet Protocol (IP) router is an IP node that can forward IP packets that are not addressed to the router. Microsoft® Windows NT® version 4.0 and earlier provided a static IP router for simple IP routing. Microsoft® Windows NT® version 3.51 (Service Pack 2 and newer) and Microsoft® Windows NT® Server 4.0 provided a Routing Information Protocol (RIP) for IP service using RIP for IP version 1 (v1). The Routing and Remote Access Service (Rremote access) for Windows NT 4.0 (Service Pack 3 and later) provided an integrated IP router with support for RIP for IP (v1 and v2), Open Shortest Path First (OSPF), IP packet filtering, demand-dial routing, and other features.

Windows 2000 Server provides Rremote access with support for RIP for IP, OSPF, IP packet filtering, demand-dial routing, and network address translation. For more information about the components in Windows 2000 that make up the IP router, see “Windows 2000 Router” in this book.


Windows 2000 Router Features for IP Routing

The Windows 2000–based computer running Rremote access, known as the Windows 2000 Router, provides a rich set of features to support IP internetworks:

  • RIP for IP

    Support for version 1 and version 2 of RIP for IP, the primary routing protocol used in small to medium IP internetworks.

  • OSPF

    Support for an RFC 1542–compliant Dynamic Host Configuration Protocol (DHCP) Relay Agent, also known as a Boot Protocol (BOOTP) Relay Agent, that transfers messages between DHCP clients and DHCP servers located on separate networks.

  • Network Address Translator (NAT)

    Support for network address translation to translate private and public addresses to allow the connection of small office or home office networks to the Internet.

  • IP Packet Filtering

    Support for separately configured input and output filters for each IP interface based on key fields in the IP, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP) headers.

  • ICMP Router Discovery

    Support for ICMP Router Advertisement messages to allow the automated discovery of default routers by hosts.

  • Platform to Support Other IP Routing Protocols

    Application Programming Interface (API) support that provides a platform to support additional routing protocols such as the Border Gateway Protocol (BGP) for IP. The Windows 2000 Router does not provide BGP, but BGP can be written by third-party independent software vendors. For more information on the API support for third-party routing protocols, see “Windows 2000 Router” in this book.


RIP for IP

RIP for IP is a distance vector routing protocol that facilitates the exchange of IP routing information. Like RIP for IPX, RIP for IP has its origins in the Xerox Network Services (XNS) version of RIP and became a popular routing protocol due to its inclusion in Berkeley UNIX (BSD 4.2 and later) as the routed server daemon (a daemon is similar to a Windows 2000 service). There are two versions
of RIP. RIP version 1 (v1) is defined in RFC 1058. RIP version 2 (v2) is defined in RFC 1723. In this chapter, information on RIP for IP applies to both versions
of RIP. Additional information on the differences between RIP v1 and RIP v2 is also included in this chapter.


RIP and Large Internetworks

While simple and well supported in the industry, RIP for IP suffers from some problems inherent to its original LAN-based design. The combination of the these problems makes RIP a desirable solution only in small to medium-sized IP internetworks.

RIP and Hop Counts

RIP uses a hop count as the metric for the route stored in the IP routing table. The hop count is the number of routers that must be crossed to reach the desired network. RIP has a maximum hop count of 15; therefore, there can only be 15 routers between any two hosts. Networks 16 hops and greater away are considered unreachable. Hop counts can be customized so that slow links are set to multiple hops; however, the accumulated hop count between any two networks must not exceed 15.

The RIP hop count is independent of the Time-to-Live (TTL) field in the IP header. On an internetwork, a network 16 hops away would normally be reachable for an IP packet with an adequate TTL; however, to the RIP router, the network is unreachable and attempts to forward packets to hosts on the network result in ICMP Destination Unreachable–Network Unreachable messages from the RIP router.

RIP and Routing Table Entries

RIP allows for multiple entries in the routing table for a network if there are multiple paths. The IP routing process chooses the route with the lowest metric (lowest hop count) as the best route. However, typical RIP for IP router implementations, including Windows 2000, only store a single lowest metric route for any network. If multiple lowest hop count routes are received by RIP, the first lowest metric route received is stored in the routing table.

If the RIP router is storing a complete list of all the networks and all of the possible ways to reach each network, the routing table can have hundreds or even thousands of entries in a large IP internetwork with multiple paths. Because only 25 routes can be sent in a single RIP packet, large routing tables have to be sent as multiple RIP packets.

RIP Route Advertising

RIP routers advertise the contents of their routing tables every 30 seconds on all attached networks through an IP subnet and MAC-level broadcast. (RIP v2 routers can be configured to multicast RIP announcements.) Large IP internetworks carry the broadcasted RIP overhead of large routing tables. This can be especially problematic on WAN links where significant portions of the WAN link bandwidth are devoted to the passing of RIP traffic. As a result, RIP-based routing does not scale well to large internetworks or WAN implementations.

RIP Convergence

By default, each routing table entry learned through RIP is given a timeout value of three minutes past the last time it was received in a RIP announcement from a neighboring RIP router. When a router goes down due to a hardware or software failure, it can take several minutes for the topology change to be propagated throughout the internetwork. This is known as the slow convergence problem.


Convergence in RIP Internetworks

RIP for IP, like most distance vector routing protocols, announces its routes in an unsynchronized and unacknowledged manner. This can lead to convergence problems. However, you can enable modifications to the announcement algorithms to reduce convergence time in most situations.

The Count-to-Infinity Problem

The classic distance vector convergence problem is known as the count-to-infinity problem and is a direct result of the asynchronous announcement scheme. When RIP for IP routers add routes to their routing table, based on routes advertised by other routers, they keep only the best route in the routing table and they update a lower cost route with a higher cost route only if is being announced by the same source as the current lower cost route. In certain situations, as illustrated in Figures 3.1 through 3.5, this causes the count-to-infinity problem.

Assume that the internetwork in Figure 3.1 has converged. For simplicity, the announcements sent by Router 1 on Network 1 and Router 2 on Network 3 are not included.

Figure 3.1 Converged Internetwork

Now assume that the link from Router 2 to Network 3 fails and is sensed by Router 2. As shown in Figure 3.2, Router 2 changes the hop count for the route to Network 3 to indicate that it is unreachable, an infinite distance away. For RIP for IP, infinity is 16.

Figure 3.2 Link to Network 3 Fails

However, before Router 2 can advertise the new hop count to Network 3 in a scheduled announcement, it receives an announcement from Router 1. The Router 1 announcement contains a route to Network 3 which is 2 hops away. Because 2 hops away is a better route than 16 hops, Router 2 updates its routing table entry for Network 3, changing it from 16 hops to 3 hops, as shown in Figure 3.3.

Figure 3.3 Router 2 After Receiving Announcement From Router 1

When Router 2 announces its new routes, Router 1 notes that Network 3 is available 3 hops away through Router 2. Because the route to Network 3 on Router 1 was originally learned from Router 2, Router 1 updates its route to Network 3 to 4 hops. (See Figure 3.4.)

Figure 3.4 Router 1 After Receiving Announcement From Router 2

When Router 1 announces its new routes, Router 2 notes that Network 3 is available 4 hops away through Router 1. Because the route to Network 3 on Router 2 was originally learned from Router 1, Router 2 updates its route to Network 3 to 5 hops. (See Figure 3.5.)

Figure 3.5 Router 2 After Receiving Another Announcement from Router 1

The two routers continue to announce routes to Network 3 with higher and higher hop counts until infinity (16) is reached. Then, Network 3 is considered unreachable and the route to Network 3 is eventually timed out of the routing table. This is known as the count-to-infinity problem.

The count-to-infinity problem is one of the reasons why the maximum hop count of RIP for IP internetworks is set to 15 (16 for unreachable). Higher maximum hop count values would make the convergence time longer when count-to-infinity occurs. Also note that during the count-to-infinity in the previous example, the route from Router 1 to Network 3 is through Router 2. The route from Router 2 to Network 3 is through Router 1. A routing loop exists between Router 1 and Router 2 for Network 3 for the duration of the count-to-infinity problem.

Reducing Convergence Time

To help reduce the convergence time of RIP for IP internetworks and to avoid count-to-infinity and routing loops in most situations, you can enable the following modifications to the RIP announcement mechanism:

  • Split horizon
  • Split horizon with poison reverse
  • Triggered updates

Split Horizon

Split horizon helps reduce convergence time by not allowing routers to advertise networks in the direction from which those networks were learned. The only information sent in RIP announcements are for those networks that are beyond the neighboring router in the opposite direction. Networks learned from the neighboring router are not included.

Split horizon eliminates count-to-infinity and routing loops during convergence in single-path internetworks and reduces the chances of count-to-infinity in multi-path internetworks. Figure 3.6 illustrates how split horizon keeps the RIP router from advertising routes in the direction from which they were learned.

Figure 3.6 Split Horizon

Split Horizon with Poison Reverse

Split horizon with poison reverse differs from simple split horizon because it announces all networks. However, those networks learned in a given direction are announced with a hop count of 16, indicating that the network is unreachable. In a single-path internetwork, split horizon with poison reverse has no benefit beyond split horizon. However, in a multi-path internetwork, split horizon with poison reverse greatly reduces count-to-infinity and routing loops. Count-to-infinity can still occur in a multi-path internetwork because routes to networks can be learned from multiple sources.

In Figure 3.7, split horizon with poison reverse advertises learned routes as unreachable in the direction from which they are learned. Split horizon with poison reverse does have the disadvantage of additional RIP message overhead because all networks are advertised.

Figure 3.7 Split Horizon with Poison Reverse

Triggered Updates

Triggered updates allow a RIP router to announce changes in metric values almost immediately rather than waiting for the next periodic announcement. The trigger is a change to a metric in an entry in the routing table. For example, networks that become unavailable can be announced with a hop count of 16 through a triggered update. Note that the update is sent almost immediately, where a time interval to wait is typically specified on the router. If triggered updates were sent by all routers immediately, each triggered update could cause a cascade of broadcast traffic across the IP internetwork.

Triggered updates improve the convergence time of RIP internetworks but at the expense of additional broadcast traffic as the triggered updates are propagated.


RIP for IP Operation

The normal operation of a RIP for IP router consists of an initialization process, during which the router learns the routes of the internetwork from neighboring routers; an ongoing periodic advertisement process; and the proper advertisement of unreachable routes when the router is brought down through an administrative action.

Initialization

Upon startup, the RIP for IP router announces its locally attached networks on all of its interfaces. The neighboring RIP routers process the RIP announcement and add the new network or networks to their routing tables as appropriate.

The initializing RIP router also sends a General RIP Request on all locally attached networks. The General RIP Request is a special RIP message requesting all routes. The neighboring RIP routers receive the General RIP Request and send a unicast reply to the requesting router. The replies are used to build the initializing RIP router’s routing table.

Ongoing Maintenance

By default, every 30 seconds the RIP router announces it routes on all of its interfaces. The exact nature of the routing announcement depends on whether the RIP router is configured for split horizon or split horizon with poison reverse. The RIP router is also always listening for RIP announcements from neighboring routers in order to add or update the routes in its own routing table.

Administrative Router Shutdown

If a RIP for IP router is downed properly through an administrative action, it sends a triggered update on all locally attached networks. The triggered update announces the networks available through the router with a hop count of 16 (unreachable). This topology change is propagated by neighboring RIP routers throughout the IP internetwork using triggered updates.

As dynamic routers, RIP for IP routers also react to changes in the internetwork topology from downed links or downed routers.

Downed Link

If a link goes down corresponding to one of the router’s interfaces and this failure is detected by the interface hardware and indicated to the router, this change is sent out as a triggered update.

Note

Most LAN-based interface hardware does not currently detect media faults and therefore this change is not sensed and propagated. Many WAN adapters, however, have the ability to sense that a link to the WAN service provider is down.

Downed Router

If a router goes down due to a power outage or other hardware or software failure, it does not have the ability to inform neighboring routers that the networks available through it have become unavailable. To prevent the lingering existence of unreachable networks in routing tables, each route learned by RIP for IP has a maximum lifetime of 3 minutes (by default). If the entry is not refreshed by the receipt of another announcement in 3 minutes, the entry’s hop count is changed to 16 and it is eventually removed from the routing table.

Therefore, if a RIP for IP router goes down, it takes up to 3 minutes for the neighboring routers to mark the routes learned from the downed router as unreachable. Only then do they propagate the topology change throughout the internetwork using triggered updates.


RIP for IP Version 1

RIP version 1 (v1) is defined in RFC 1058 and is widely deployed in small to medium-sized intranets.

RIP v1 Message Format

RIP messages are encapsulated in a User Datagram Protocol (UDP) datagram sent from the router interface IP address and UDP port 520 to the subnet broadcast IP address and UDP port 520. The RIP v1 message consists of a 4-byte RIP header and up to 25 RIP routes. The maximum size of the RIP message is 504 bytes. With the 8-byte UDP header, the maximum size of the RIP message is a 512-byte IP payload. Figure 3.8 illustrates the RIP v1 message format.

Figure 3.8 The RIP Version 1 Message Format

  • Command

    A 1-byte field containing either 0x01 or 0x02. 0x01 indicates a RIP request for all (a General RIP Request) or part of the routing tables of neighboring routers. 0x02 indicates a RIP response consisting of all or part of a neighboring router’s routing table. A RIP response can be sent in response to a RIP request or as the periodic or triggered update message.

  • Version

    A 1-byte field set to the value of 0x01 for RIP v1.

  • Family Identifier

    A 2-byte field identifying the protocol family. This is set to the value of 0x00-02 to indicate the IP protocol family.

  • IP Address

    A 4-byte field set to the IP network ID which can be a class-based network ID, a subnetted network ID (advertised only within the subnetted network), an IP address (for a host route), or 0.0.0.0 (for the default route). For a General RIP Request, the IP Address is set to 0.0.0.0.

  • Metric

    A 4-byte field for the number of hops to the IP network that must be a value from 1 to 16. The metric is set to 16 in a General RIP Request or to indicate that the network is unreachable in a RIP response (announcement).

Problems with RIP v1

RIP v1 was designed in 1988 to suit the dynamic routing needs of LAN technology-based IP internetworks. Shared access LAN technologies like Ethernet and Token Ring support Medium Access Control (MAC)-level broadcasting where a single packet can be received and processed by multiple network nodes. However, in modern internetworks, the use of MAC-level broadcasts is undesirable because all nodes must process all broadcasts. RIP v1 was also designed in a time when the Internet was still using network IDs based on the Internet address classes. Today, however, the use of Classless Inter-domain Routing (CIDR) and variable length subnetting is almost required to conserve IP addresses.

Broadcasted RIP Announcements

All RIP v1 route announcements are addressed to the IP subnet (all host bits are set to 1) and MAC-level broadcast. Non-RIP hosts also receive RIP announcements. For large or very large RIP internetworks, the amount of broadcast traffic on each subnet can become significant.

While producing additional broadcast traffic, the broadcast nature of RIP v1 also permits the use of Silent RIP. A Silent RIP computer processes RIP announcements but does not announce its own routes. Silent RIP could be enabled on non-router hosts to produce a routing table with as much detail as the RIP routers. With more detailed routes in the routing table, a Silent RIP host can make better routing decisions.

Subnet Mask Not Announced with Route

RIP v1 was designed for class-based IP internetworks where the network ID can be determined from the values of the first 3 bits of the IP address in the RIP route. Because the subnet mask is not included with the route, the RIP router must determine the network ID based on a limited set of information. For each route in a RIP v1 message, the RIP v1 router performs the following process:

  • If the network ID fits the address classes (Class A, Class B, or Class C), the default class-based subnet mask is assumed.
  • If the network ID does not fit the address class, then:
    • If the network ID fits the subnet mask of the interface on which it is received, the subnet mask of the interface on which it was received is assumed.
    • If the network ID does not fit the subnet mask of the interface on which it is received, the network ID is assumed to be a host route with the subnet mask 255.255.255.255.

As a result of the assumptions listed previously, supernetted routes may be interpreted as a single network IDs rather than the range of network IDs that they are designed to represent and subnet routes advertised outside of the network ID being subnetted may be interpreted as host routes.

As a mechanism for supporting subnetted environments, RIP v1 routers do not advertise the subnets of a subnetted class-based network ID outside the subnetted region of the IP internetwork. However, because only the class-based network ID is being advertised outside the subnetted environment, subnetworks of a network ID in a RIP v1 environment must be contiguous. If subnetworks of a IP network ID are noncontiguous, known as disjointed subnets, the class-based network ID is announced by separate RIP v1 routers in different parts of the internetwork. As a result, IP traffic can be forwarded to the wrong network.

No Protection from Rogue RIP Routers

RIP v1 does not provide any protection from a rouge RIP router starting up on a network and announcing false or inaccurate routes. RIP v1 announcements are processed regardless of their source. A malicious user could use this lack of protection to overwhelm RIP routers with hundreds or thousands of false or inaccurate routes.


RIP for IP Version 2

RIP version 2 (v2) as defined in RFC 1723 seeks to address some of the problems associated with RIP v1. The decision to refine RIP was controversial in the context of newer, smarter routing protocols such as OSPF. However, RIP has the following advantages over OSPF:

  • RIP for IP is easy to implement. In its simplest default configuration, RIP for IP is as easy as configuring IP addresses and subnet masks for each router interface and then turning on the router.
  • RIP for IP has a large installed base consisting of small and medium-sized IP internetworks that do not wish to bear the design and configuration burden of OSPF.

Features of RIP v2

To help today’s IP internetworks minimize broadcast traffic, use variable length subnetting to conserve IP addresses, and secure their routing environment from misconfigured or malicious routers, several key features were added to RIP v2.

  • Multicasted RIP Announcements

    Rather than broadcasting RIP announcements, RIP v2 supports sending RIP announcements to the IP multicast address of 224.0.0.9. Non-RIP nodes are not disturbed by RIP router announcement traffic. Because RIP v2 multicasted announcements are sent to 224.0.0.9 with a TTL of 1, Internet Group Membership Protocol (IGMP) is not needed to register host group membership.

    The disadvantage of this new feature is that Silent RIP nodes must also be listening for multicast traffic sent to 224.0.0.9. If you are using Silent RIP, verify that your Silent RIP nodes can listen for multicasted RIP v2 announcements before deploying multicasted RIP v2.

    The use of multicasted announcements is optional. The broadcasting of RIP v2 announcements is also supported.

  • Subnet Masks

    RIP v2 announcements send the subnet mask along with the network ID. RIP v2 can be used in subnetted, supernetted, and variable-length subnet mask environments. Subnets of a network ID do not have to be contiguous (they can be disjointed subnets).

  • Authentication

    RIP v2 supports the use of authentication mechanisms to verify the origin of incoming RIP announcements. Simple password authentication was defined in RFC 1723, but newer authentication mechanisms such as Message Digest 5 (MD5) are available.

Note

Windows 2000 supports only simple password authentication.

  • RIP v1 Routers Are Forward Compatible with RIP v2

    RIP v1 was designed with forward compatibility in mind. If a RIP v1 router receives a message and the RIP version in the RIP header is not 0x01, it does not discard the RIP announcement but processes only the RIP v1 defined fields.

    Also, RIP v2 routers send a RIP v1 response to a RIP v1 request except when configured to send only RIP v2 announcements.

RIP v2 Message Format

To ensure that RIP v1 routers can process RIP v2 announcements, RIP v2 does not modify the structure of the RIP message format. RIP v2 makes use of fields that were defined in RIP v1 as Must be Zero.

The use of the Command, Family Identifier, IP Address, and Metric fields are the same as previously defined for RIP v1. The Version field is set to 0x02 to indicate a RIP v2 message. Figure 3.9 illustrates the RIP v2 message format.

Figure 3.9 RIP Version 2 Message Format

  • Route Tag

    The Route Tag field is used as a method of marking specific routes for administrative purposes. Its original use as defined by RFC 1723 was to distinguish routes that were RIP-based routes (internal to the RIP environment) from non-RIP routes (external to the RIP environment). The Route Tag is configurable on routers that can support multiple routing protocols.

Note

Windows 2000 supports the configuration of the Route Tag for RIP v2 interfaces.

  • Subnet Mask

    The 4-byte Subnet Mask field contains the subnet mask of the network ID in the IP Address field.

  • Next Hop

    The 4-byte Next Hop field contains the forwarding IP address (also known as the Gateway Address) for the network ID in the IP Address field. If the next hop is set to 0.0.0.0, the forwarding IP address (the next hop) for the route is assumed to be the source IP address of the route announcement.

    The Next Hop field is used to prevent non-optimal routing situations. For example, if a router announces a host route for a host that resides on the same network as the router interface advertising the route and the Next Hop field is not used, the forwarding IP address for the host route is the IP address of the router’s interface, not the IP address of the host. Other routers that receive the announcement on that network forward packets destined for the host’s IP address to the announcing router’s IP address rather than to the host. This creates a non-optimal routing situation.

    Using the Next Hop field, the router announces the host route with the host’s IP address in the Next Hop field. Other routers receiving the announcement on that network forward packets destined for the host’s IP address to the host’s IP address rather than forwarding them to the announcing router.

    Because the Next Hop field becomes the Gateway Address field in the IP routing table, the IP address in the Next Hop field should be directly reachable using a router interface.

Authentication in RIP v2

The authentication process for RIP v2 announcements uses the first route entry in the RIP message to store authentication information. The first route entry must be used, leaving a maximum of 24 routes in a RIP v2 authenticated announcement. To indicate authentication, the Family Identifier field is set to 0xFF-FF. The Authentication Type field, normally used as the Route Tag field for a route, indicates the type of authentication being used. Simple password authentication uses the Authentication Type value of 0x00-01.

The 16 bytes after the Authentication Type are used to store the authentication value. For simple password authentication, the 16-byte Authentication Value field stores the left-justified, null-padded, case-sensitive, clear-text password. Figure 3.10 illustrates the RIP v2 authentication message.

Figure 3.10 RIP v2 Message Format Using Authentication

RIP v1 routers disregard the first route in a RIP v2 authenticated announcement because the Family Identifier for the route is unknown.

Note

Simple password authentication for RIP v2 prevents unauthorized or misconfigured RIP routers from being placed on the network. The simple password is not secure, however, because it is sent on the network in clear text. Anyone with a protocol analyzer such as Microsoft Network Monitor can capture the RIP v2 packets and view the authentication password.

Mixed RIP v1 and RIP v2 Environments

RIP v2 routers and RIP v1 routers should be used together with caution. Because RIP v1 routers do not interpret the Subnet Mask field in the route, RIP v2 routers must not announce routes which can be misinterpreted by a RIP v1 router. Variable length subnet masks (VLSM) and disjointed subnets cannot be used in mixed environments.

For an interface using RIP v2 to make announcements such that RIP v1 routers can process the announced routes, the RIP v2 routers must summarize subnet routes when announcing outside a subnetted environment. A specific subnet route announced to a RIP v1 router can be misinterpreted as a host route. Also, the RIP v2 routers cannot announce supernet routes. A RIP v1 router would misinterpret the route as a single network, rather than a range of networks.

If RIP v2 routers are on the same network as RIP v1 routers, the RIP v2 router interface must be configured to broadcast its announcements. Multicasted RIP v2 announcements are not processed by the RIP v1 routers.


Windows 2000 as a RIP for IP Router

Windows 2000 RIP for IP is RFC 1058 and 1723 compliant and has the following features:

  • Split horizon, poison reverse, and triggered updates convergence algorithms.
  • Ability to modify the announcement interval (default is 30 seconds).
  • Ability to modify the routing table entry timeout value (default is 3 minutes).
  • Ability to be a Silent RIP host.
  • Peer Filtering: Ability to accept or discard updates of announcements from specific routers identified by IP address.
  • Route Filtering: Ability to accept or discard updates of specific network IDs or from specific routers.
  • RIP Neighbors: Ability to unicast RIP announcements to specific routers to support nonbroadcast technologies like Frame Relay. A RIP neighbor is a RIP router that receives unicasted RIP announcements.
  • Ability to announce or accept default routes or host routes.

Note

When a Windows 2000 Router advertises a non-RIP learned route, it advertises it with a hop count of two. Non-RIP learned routes include static routes (even for directly attached networks), OSPF routes, and SNMP routes.


Troubleshooting RIP for IP

If a RIP environment is properly configured, RIP routers learn all the best routes from neighboring routers after convergence. The exact list of routes added by RIP to the IP routing table depends, among other factors, on whether or not the router interfaces are inside a subnetted region, whether or not RIP v2 is being used, and whether or not host routes or default routes are being advertised.

Problems with RIP can occur in a mixed RIP v1 and v2 environment, with the use of Silent RIP hosts, or when all the appropriate RIP routes are not being received and added to the IP routing table.

Improper Routes in a Mixed RIP v1 and RIP v2 Environment

On networks containing RIP v1 routers, verify that RIP v2 is configured to broadcast its announcements on networks containing RIP v1 routers.

On networks containing RIP v1 routers, verify that the RIP v2 router interfaces are configured to accept both RIP v1 and RIP v2 announcements.

Silent RIP Hosts Are Not Receiving Routes

If there are Silent RIP hosts on a network that are not receiving routes from the local RIP router, verify the version of RIP supported by the Silent RIP hosts. For example, if the Silent RIP hosts only support listening for broadcasted, RIP v1 announcements, you cannot use RIP v2 multicasting.

If you are using the RIP listener component available on Microsoft® Windows NT® Workstation version 4.0, Service Pack 4 and later, you must configure your RIP routers for RIP v1 or RIP v2 broadcasting.

RIP Routers Are Not Receiving Expected Routes

  • Verify that you are not deploying variable length subnetting, disjointed subnets, or supernetting in a RIP v1 or mixed RIP v1 and RIP v2 environment.
  • If authentication is enabled, verify that all interfaces on the same network are using the same case-sensitive password.
  • If RIP peer filtering is being used, verify that the correct IP addresses for the neighboring peer RIP routers are configured.
  • If RIP route filtering is being used, verify that the ranges of network IDs for your internetwork are included or are not being excluded.
  • If RIP neighbors are configured, verify that the correct IP addresses are configured for the unicasted RIP announcements.
  • Verify that IP packet filtering is not preventing the receiving (through input filters) or sending (through output filters) of RIP announcements on the router interfaces enabled for RIP.
  • For dial-up demand-dial interfaces using auto-static updates, configure the demand-dial interfaces to use RIP v2 multicast announcements. When a router calls another router, each router receives an IP address from the other router’s IP address pool, which are on different subnets. Because broadcasted RIP announcements are addressed to the subnet broadcast address, each router does not process the other router’s broadcasted announcement. Using multicasting, RIP announcements are processed regardless of the subnet for the router interfaces. For more information on demand-dial interfaces and auto-static updates, see “Demand Dial Routing” in this book.


OSPF

Open Shortest Path First (OSPF) is a link-state routing protocol defined in RFC 1583. It is designed to be run as an Interior Gateway Protocol (IGP ) to a single Autonomous System (AS). In a link-state routing protocol, each router maintains a database of router advertisements called Link State Advertisements (LSAs). LSAs for routers within the AS consist of a router, its attached networks, and their configured costs. An OSPF cost is a unitless metric that indicates the preference of using a link. There are also LSAs for summarized routes and routes outside of the AS.

The router distributes its LSAs to its neighboring routers. LSAs are gathered into a database called the link state database (LSDB). By synchronizing LSDBs between all neighboring routers, each router has each other router’s LSA in its database. Therefore, every router has the same LSDB. From the LSDB, entries for the router’s routing table are calculated using the Dijkstra algorithm to determine the least cost path, the path with the lowest accumulated cost, to each network in the internetwork.

OSPF has the following features:

  • Fast Convergence

    OSPF can detect and propagate topology changes faster than RIP. Count-to-infinity does not occur with OSPF.

  • Loop-Free Routes

    OSPF calculated routes are always loop-free.

  • Scalability

    With OSPF, an AS can be subdivided into contiguous groups of networks called areas. Routes within areas can be summarized to minimize route table entries. Areas can be configured with a default route summarizing all routes outside the AS or outside the area. As a result, OSPF can scale to large and very large internetworks. In contrast, RIP for IP internetworks cannot be subdivided and no route summarization is done beyond the summarizing all subnets of a network ID.

  • Subnet Mask Advertised with the Network

    OSPF was designed to advertise the subnet mask with the network. OSPF supports variable-length subnet masks (VLSM), disjointed subnets, and supernetting.

  • Support for Authentication

    Information exchanges between OSPF routes can be authenticated. Windows 2000 OSPF supports simple password authentication.

  • Support for External Routes

    Routes outside of the OSPF AS are advertised within the AS so that OSPF routers can calculate the least cost route to external networks.

Note

Windows 2000 OSPF does not support Type of Service (TOS) routing and load balancing for equal cost routes as defined in RFC 1583.

Note

Simple password authentication for OSPF is designed to prevent unauthorized OSPF routers from being placed on the network. The simple password is not secure, however, because it is sent on the network in clear text. Anyone with a protocol analyzer such as Microsoft Network Monitor can capture the OSPF messages and view the authentication password.


OSPF Operation

The main operation of the OSPF protocol occurs in the following consecutive stages and leads to the convergence of the internetwork:

  1. Compiling the LSDB.
  2. Calculating the Shortest Path First (SPF) Tree.
  3. Creating the routing table entries.

Formation of the LSDB Using Link State Advertisements

The LSDB is a database of all OSPF router LSAs, summary LSAs, and external route LSAs. The LSDB is compiled by an ongoing exchange of LSAs between neighboring routers so that each router is synchronized with its neighbor. When the AS has converged, all routers have the appropriate entries in their LSDB.

To create the LSDB, each OSPF router must receive a valid LSA from each other router in the AS. This is performed through a procedure called flooding. Each router initially sends out an LSA which contains its own configuration. As it receives LSAs from other routers, it propagates those LSAs to its neighbor routers.

In this way, an LSA from a given router is flooded across the AS so that each other router contains that router’s LSA. While it appears that the flooding of LSAs across the AS causes a large amount of network traffic, OSPF is very efficient in the propagation of LSA information. Figure 3.11 shows a simple OSPF AS, the flooding of LSAs between neighboring routers, and the LSDB.

The exact details of the synchronization of the LSDB between neighboring routers is discussed in the section on creating adjacencies.

Figure 3.11 OSPF Link State Database (LSDB)

The Router ID

To keep track of LSAs in the LSDB, each router is assigned a Router ID, a 32-bit dotted decimal number that is unique to the AS. The Router ID identifies the router in the AS, not the IP address of one of the router’s interfaces. The Router ID is not used as a destination IP address for sending information to the router. It is a common industry convention to use the largest or smallest IP address assigned to the router as the Router ID. Because IP addresses are unique, this convention ensures that the OSPF Router ID is unique.

Calculating the SPF Tree Using Dijkstra’s Algorithm

Once the LSDB is compiled, each OSPF router performs a least cost path calculation called the Dijkstra algorithm on the information in the LSDB and creates a tree of shortest paths to each other router and network with themselves as the root. This tree is known as the SPF Tree and contains a single, least cost path to each router and network in the AS. Because the least cost path calculation is performed by each router with itself as the root of the tree, the SPF tree is different for each router in the AS.

The Dijkstra algorithm is from a branch of mathematics called graph theory and is an efficient method of calculating a set of least cost paths relative to a source node.

To Calculate the SPF Tree Using the Dijkstra Algorithm

The result of the Dijkstra algorithm is the set SPF{}, a cost sorted list of least cost paths containing the path (the series of nodes and links) and its accumulated cost from the source node S.

  1. Define the set E{} to be the set of nodes (routers) that have been evaluated.
  2. Define the set R{} to be the set of nodes (routers) that are remaining (have not been evaluated).
  3. Define the set O{} to be a cost sorted list of ordered paths between nodes. An ordered path can consist of multiple nodes connected together in a multi-hop configuration (they do not have to be neighboring).
  4. Define the set SPF{} to be a cost sorted list of least cost paths containing the path and its accumulated cost.
  5. Initialize the set E{} to contain the source node S and the set R{} to contain all other nodes. Initialize the set O{} to be the cost sorted list of directly connected paths from S. Initialize the set SPF{} to be the empty set.
  6. If O{} is empty or the first path in O{} has an infinite metric, mark all the nodes in R as unreachable and terminate the algorithm.
  7. From the set O{}, examine P, the shortest ordered path in O{}. Remove P from O{}. Let V be the last node on the ordered path of P.

    If V is already a member of E{}, return to step 6.

    – Or –

    If P is the shortest path to V. Move V from R{} to E{}. Add a member to the set SPF{}consisting of P and its accumulated cost from S.

  8. Build a new set of paths by concatenating P and each of the links adjacent to V. The cost of these paths is the sum of the cost of P and the metric of the link appended to P. Insert the new links in the set O{} and sort by cost. Return to step 6.

Calculating the Routing Table Entries from the SPF Tree

The OSPF routing table entries are created from the SPF tree, and a single entry for each network in the AS is produced. The metric for the routing table entry is the OSPF calculated cost, not a hop count.

To calculate the IP routing table entries from the SPF Tree, the resulting set SPF{} is analyzed. The result of the analysis is a series of OSPF routes containing the IP network ID and its subnet mask, the forwarding IP address of the appropriate neighboring router, the interface over which the neighboring router is reachable, and the OSPF-calculated cost to the network. The OSPF routes are added to the IP routing table.

OSPF Operation

The following examples illustrate how an OSPF internetwork compiles the LSDB, performs the least cost analysis, and creates routing table entries. This example is deliberately simplified to help you gain an understanding of the basic principles of OSPF convergence.

Compiling the LSDB

Consider the simple AS in Figure 3.12. At each router interface, a unitless cost metric is assigned as a reflection of the preference of using that interface. These cost values can be a reflection of bandwidth, delay, or reliability factors and are assigned by the network administrator.

Figure 3.12 AS with Link State Database Information

After convergence, when each router has an LSA from each other router in the AS, they each contain the LSDB shown in Table 3.1.

Table 3.1 Link State Database

Router | Attached Networks and Costs
R1 | Net 1-Cost 2, Net 3-Cost 5, Net 4-Cost 2
R2 | Net 1-Cost 1, Net 2-Cost 4, Net 6-Cost 2
R3 | Net 2-Cost 4, Net 3-Cost 2, Net 5-Cost 3, Net 7-Cost 2
R4 | Net 4-Cost 3, Net 5-Cost 2
R5 | Net 6-Cost 2, Net 7-Cost 3

Calculating the SPF Tree

The next step is to apply Dijkstra’s algorithm to our sample OSPF AS. Figure 3.13 illustrates the resulting SPF Tree calculation as performed by router R4. With R4 as the root, the SPF Tree calculation determines the series of connected routers and networks that represent the least cost path to each router and to each network.

Figure 3.13 SPF Tree

Creating Routing Table Entries

The routing table is created from the results of the SPF Tree as shown in Figure 3.14.

Figure 3.14 Routing Table Entries


OSPF Network Types

OSPF message addresses are determined by the type of network to which the OSPF interface is connected. One of the following OSPF network types must be selected when configuring an interface on an OSPF router.

  • Broadcast

    A network that can connect more than two routers with a hardware broadcast facility where a single packet sent by a router is received by all routers attached to that network. Ethernet, Token Ring, and FDDI are broadcast networks. OSPF messages sent on broadcast networks use IP multicast addresses.

  • Point-to-Point

    A network that can connect only two routers. Leased-line WAN links such as Dataphone Digital Service (DDS) and T-Carrier are point-to-point networks. OSPF messages sent on point-to-point networks use IP multicast addresses.

  • Non-Broadcast Multiple Access

    A network that can connect more than two routers but has no hardware broadcast facility. X.25, Frame Relay, and ATM are Non-Broadcast Multiple Access (NBMA) networks. Because multicasted OSPF messages do not reach all the OSPF routers on the network, OSPF must be configured to unicast to the IP addresses of the routers on the NBMA network.

OSPF communication on these network types is discussed in “OSPF Communication on OSPF Networks” later in this chapter.

Note

Windows 2000 does not support the use of OSPF over nonpermanent, dial-up WAN links such as analog phone lines or ISDN.


Synchronizing the LSDB Through Adjacencies

Link-state routing algorithms rely on the synchronization of LSDB information between routers in the AS. Rather than each router verify synchronization with every other router in the AS, each router is only required to synchronize with its neighboring routers. The relationship between neighboring routers for the purposes of synchronizing the LSDB is called an adjacency. Adjacencies are required to compile the proper entries in the LSDB before the calculation of the SPF Tree and the entries in the routing table. Failure to establish adjacencies is one of the main problems in converging OSPF internetworks. For information on troubleshooting OSPF adjacencies, see the section on “Troubleshooting OSPF” later in this chapter.

Forming an Adjacency

When an OSPF router initializes, it sends out a periodic OSPF Hello packet. The OSPF Hello packet contains configuration information such as the router’s Router ID and the list of neighboring routers for which the router has received a Hello packet. Initially, the neighbor list in the OSPF Hello packet does not contain any neighbors.

The initializing OSPF router also listens for neighboring routers’ Hello packets. From the incoming Hello packets, the initializing router determines the specific router or routers with which an adjacency is to be established. Adjacencies are formed with the designated router (DR) and backup designated router (BDR) which are identified in the incoming Hello packets. Designated routers and backup designated routers are discussed in more detail later in this chapter.

To begin the adjacency, the routers forming the adjacency describe the contents of their LSDBs through a sequence of Database Description Packets. This is known as the Database Exchange Process during which the two neighboring routers form a master/slave relationship. The contents of each router’s LSDB is acknowledged by its neighboring router.

Each router compares its LSAs with the LSAs of its neighbor and notes which LSAs need to be requested of the neighbor to synchronize the LSDB. The missing or more recent LSAs are then requested through Link State Request packets. Link State Update packets are sent in response to the Link State Request packets and their receipt is acknowledged. When all Link State Requests of both routers have been satisfied, the LSDBs of the neighboring routers are fully synchronized and an adjacency is formed.

After the adjacency has formed, each neighboring router sends a periodic Hello packet to inform its neighbor that the router is still active on the network. The lack of Hello packets from a neighbor is used to detect a downed router.

If an event occurs such as a downed link or router or the addition of new network which changes the LSDB of one router, the LSDB of adjacent routers are no longer synchronized. The router whose LSDB has changed sends Link State Update packets to its adjacent neighbor. The receipt of the Link State Update packets are acknowledged. After the exchange, the LSDBs of the adjacent routers are once again synchronized.

Neighbor States

The neighboring routers go through a series of states during the establishment of an adjacency. Table 3.2 lists these states in the adjacency relationship in progressive order.

Table 3.2 Neighbor States for Adjacent Routers

Neighbor State | Description
Down | The initial state. No information has been received from the neighbor router.
Attempt | No information has been received despite attempts to contact the neighbor (for NBMA networks only).
Init | A Hello packet has been received from the neighbor, but the router does not appear in the neighbor list in the neighbor router’s Hello packet.
2-Way | A Hello packet has been received from the neighbor, and the router does appear in the neighbor list in the neighbor router’s Hello packet.
ExStart | Master and slave roles for the Database Exchange Process are being negotiated. This is the first phase of the adjacency relationship.
Exchange | The router is sending Database Description packets to its neighbor.
Loading | Link State Request packets are being sent to the neighbor requesting missing or more recent LSAs.
Full | The neighboring routers’ LSDBs are synchronized, and the two routers are fully adjacent.

To view the neighbor state of neighboring routers

  • In the Routing and Remote Access Manager, in the IP Routing container, right-click OSPF, point to Task, and then point to Show neighbors.

    The OSPF Neighbors window displays all neighboring routers.

Because of the election of designated routers (DRs) and backup designated routers (BDRs), each OSPF router may not form an adjacency with each other router.

For those neighbor routers where an adjacency is established, Full should appear in the State column. For those neighbor routers where an adjacency is not established nor will be established because the router is not a DR or BDR, 2-way should appear in the State column. Designated routers and backup designated routers are discussed later in this chapter.

Adjacency Configuration Parameters

A common OSPF problem is that an adjacency which should form between two neighboring routers does not. The following parameters must match between the two routers in order for an adjacency to be established:

  • If authentication is being used, the neighboring routers must be using the same authentication type.
  • If simple password authentication is enabled, the neighboring routers must be using the same password.
  • The Hello Interval (default of 10 seconds), the periodic interval at which Hello packets are sent, must be the same.
  • The Dead Interval (default of 40 seconds), the amount of time after which an adjacent router is considered down after ceasing to hear that router’s Hello packets, must be the same. The RFC recommended value is four times the Hello interval.
  • The Area ID, which identifies the area of the AS to which the router is attached, must be the same. The Area ID is configured on each router interface. Areas are discussed in more detail later in this chapter.
  • The two neighbor routers must agree as to whether they are in a stub area or not. Stub areas are discussed in more detail later in this chapter.

The Router ID of the two neighboring routers must not match in order for an adjacency to be established. Router IDs are designed to be globally unique to the AS. Duplicate Router IDs prevent an adjacency.

Adding a Router to a Converged OSPF Internetwork

When a new OSPF router initializes on an existing and converged OSPF internetwork, the LSA for the new OSPF router must be propagated to all the OSPF routers in the internetwork through flooding. After the new LSA is received, each router must perform Dijkstra’s algorithm, recalculate the SPF Tree, and create new routing table entries. After all the routing tables on all the routers are updated, the internetwork has converged.

Figure 3.15 illustrates the convergence process for a new router and new adjacency propagation in our sample OSPF internetwork.

Figure 3.15 New Adjacency Propagation

  1. Router R1 initializes and begins sending periodic Hello packets across the point-to-point WAN link. Router R2 also sends periodic Hello packets across the link. R1 and R2 decide to form an adjacency.
  2. R1 and R2 exchange Database Description Packets. R1’s Database Description Packet contains only information about itself. R2’s Database Description Packet contains the latest LSAs of all the routers in the internetwork (except R1).
  3. R1 sends a Link State Request packet to R2 requesting the LSAs of all the routers on the internetwork. R2 sends the requested LSAs to R1 as Link State Update packets.
  4. R2 sends a Link State Request packet to R1 requesting its LSA. R1 sends its LSA to R2 as a Link State Update packet. R1 and R2 now have synchronized LSDBs. Upon receipt of the LSAs, R1 and R2 calculate their respective SPF trees and routing tables.
  5. Once synchronized with R1, R2 sends a Link State Update packet to all other OSPF routers to which it is adjacent (routers R3 and R4). The Link State Update packet contains the LSA learned from R1. Upon receipt of the LSA from R2, R3 and R4 calculate their respective SPF trees and routing tables.
  6. R3 and R4 flood the information in a separate Link State Update packet to their adjacent routers (routers R5 and R6). Upon receipt of the flooded LSA for R1, R5 and R6 calculate their respective SPF trees and routing tables.

The OSPF internetwork has reconverged after adding R1 and its associated network.

Designated Routers

On a point-to-point link (such as a dedicated WAN link), the adjacency must occur between the two routers on either side of the link. However, on multi-access networks (such as broadcast or NBMA networks) the adjacencies must be controlled. Consider a broadcast network with 6 OSPF routers. Without controlling the adjacency behavior, each router could establish an adjacency with each other router for a total of 15 adjacency relationships. On a broadcast network with n routers, a total of n*(n-1)/2 adjacencies would be formed. The number of adjacencies scales as O(n2). In addition, unneeded flooding traffic would occur as each router attempts to synchronize with all of its adjacent routers.

To solve this scaling problem, every multi-access network (broadcast and NBMA) elects a Designated Router (DR). The DR forms adjacencies with all other routers on the network. On a broadcast network with n routers, a total of (n-1) adjacencies need to be formed. Because the DR is adjacent with all other routers, it acts as a hub for the distribution of link state information and the LSDB synchronization process.

The DR is elected through the exchange of OSPF Hello packets. Each Hello Packet contains the current DR (if elected), the sending router’s Router ID, and the sending router’s Router Priority. The Router Priority is an interface-specific OSPF configuration parameter that is used to elect the DR. The router with the highest Router Priority is elected the DR. The default Router Priority is 1. A Router Priority of 0 means that the router does not become a DR. If multiple routers have the same highest Router Priority, the router with the highest Router ID is elected the DR.

Caution

Router Priorities must be assigned so that at least one router on the multi-access network (broadcast or NBMA) is configured with a Router Priority of 1 or greater. If all routers on a multi-access network are configured with a Router Priority of 0, no router becomes the DR and no adjacencies are established. Without adjacencies, the LSDB cannot be synchronized and no transit traffic (traffic across that network) can be passed.

Note

If a DR is already elected for a network, an initializing router on the network does not become the DR if it has a higher Router Priority than the current DR.

DRs on Broadcast Networks

Figure 3.16 illustrates the utility of the DR on a broadcast network. Without a DR, six separate adjacencies would be formed on a broadcast network containing four routers. The redundant adjacencies consume local and network resources maintaining the adjacencies and propagating changes to the LSDB.

With a DR, only three adjacencies are needed to maintain synchronization of the LSDB.

Figure 3.16 Designated Routers on Broadcast Networks

DRs on NBMA Nets

For NBMA networks, such as a Frame Relay network, in a hub and spoke configuration, the DR must be the hub router because only the hub router can communicate with all the other routers. To ensure that the hub router is the DR, set its Router Priority to 1 (or greater). To ensure that no spoke router becomes a DR, set spoke router Router Priorities to 0.

Figure 3.17 illustrates a DR in a Frame Relay network.

Figure 3.17 Designated Routers on a Frame Relay Network

Backup Designated Router

The DR acts as a central distribution point for topological changes on a multi-access network. If the DR becomes unavailable, all new adjacencies must be formed with a new DR. Until the adjacencies form and the internetwork converges, a temporary loss of connectivity for transit traffic may result.

To prevent the loss in connectivity associated with the loss of a DR, a Backup Designated Router (BDR) is also elected for each multi-access network. Like the DR, the BDR is adjacent to all routers on the network. When the DR fails, the BDR immediately becomes the DR by sending LSAs to all of its adjacent routers announcing its new role. There is a very short period of time where transit traffic could be impaired as the BDR takes over the role of the DR.

Like the DR, the BDR is elected by the exchange of Hello packets. Each Hello packet contains a field for the BDR of the network. If the BDR is not specified, the router with the highest Router Priority that is not already the DR becomes the BDR. If there are multiple routers with the highest Router Priority, the router with the highest Router ID is elected the BDR.

Interface States

Each OSPF interface can be in one of several states after forming adjacencies. Table 3.3 lists the possible interface states.

Table 3.3 Interface States for Adjacent Routers

Interface State | Description
Down | The initial interface state. No Hello packets have been sent or received.
Loopback | The interface to the network is looped back (internally configured so that no packets are sent) through hardware or software.
Waiting | The interface is sending and receiving Hello packets to determine the DR and BDR for the network.
Point-to-Point | The interface is adjacent to its neighbor on a point-to-point network or through a virtual link.
Other | The interface is on a multi-access network and is not the DR or BDR.
Designated Router | The interface is the DR for the attached network.
Backup Designated Router | The interface is the BDR for the attached network.

To view the interface state for an OSPF interface on a Windows 2000 OSPF router, in the Routing and Remote Access manager, in the IP Routing container, click OSPF. The contents pane displays the OSPF interfaces. The State column indicates the interface’s current state. By viewing the interface state for each OSPF interface on a given network, you can determine the DR and the BDR for the network.


OSPF Communication on OSPF Networks

The way in which OSPF routers address OSPF packets varies with the OSPF network type.

  • Broadcast Networks

    For broadcast networks, OSPF routers use the following two reserved IP multicast addresses:

    • - AllSPFRouters: Used to send OSPF messages to all OSPF routers on the same network. The AllSPFRouters address is used for Hello packets. The DR and BDR use this address to send Link State Update and Link State Acknowledgment packets.
    • - AllDRouters: Used to send OSPF messages to all OSPF DRs (the DR and the BDR) on the same network. All OSPF routers except the DR use this address when sending Link State Update and Link State Acknowledgment packets to the DR.
  • Point-to-Point Networks

    Point-to-Point networks use the AllSPFRouters address (224.0.0.5) for all OSPF messages.

  • NBMA Networks

    NBMA networks have no multicasting capability. Therefore, the destination IP address of any Hello or Link State packets is the unicast IP address of a specific neighbor. The neighbor IP address is a required part of OSPF configuration for NBMA network links.


OSPF Areas

In a very large AS with a large number of networks, each OSPF router must keep the LSA of every other router in its LSDB. Each router in a large OSPF AS has a large LSDB. The SPF calculation of a large LSDB can require a substantial amount of processing. Also, the resulting routing table can be very large, containing a route to each network in the AS.

In an effort to reduce the size of the LSDB and the processing overhead for the SPF tree and routing table calculation, OSPF allows the AS to be divided up into contiguous groups of networks called areas. Areas are identified through a 32-bit Area ID expressed in dotted decimal notation.

An Area ID is an administrative identifier and has no relation to an IP address or IP network ID. Area IDs are not used to reflect routing data. However, if all of the networks within an area correspond to a single subnetted network ID, the area ID can be set to reflect the network ID for administrative convenience. For example, if an area contains all of the subnets of the IP network 10.1.0.0, the area ID can be set to 10.1.0.0.

Reducing the Size of the LSDB

To keep the size of the LSDB for each router to a minimum, LSAs for an area’s networks and routers are flooded within the area but not to routers outside the area. Each area becomes its own link state domain with its own LSDB.

If a router is connected to multiple areas, it has multiple LSDBs and SPF Trees. The routing table is a combination of the routing table entries of all the SPF Trees for the router as well as static routes, SNMP configured routes, and routes learned from other routing protocols.

Reducing the Size of the Routing Table

To reduce the number of entries in the routing table of OSPF routers, the networks inside of the area can be advertised outside the area using summary route advertisements. In Figure 3.18, the router on the border of Area 0.0.0.1, known as an area border router (ABR), advertises a summary of all of the networks inside Area 0.0.0.1 in the form of {Network ID, Subnet Mask} pairs to the ABRs of Area 0.0.0.2 and Area 0.0.0.3. Through route summarization, the topology (the networks and their path costs) of an area is hidden from the rest of the AS.

Figure 3.18 OSPF AS and Areas

When the topology of an area is hidden, the rest of the AS is protected from route flapping, events that cause networks to come up or go down. If a network comes up, the event is propagated as a Link State Update and flooded through adjacencies to routers within the area. However, because all the networks within the area are advertised outside the area using summary routes, the Link State Update is not flooded outside the area.

The Backbone Area

An OSPF internetwork, whether or not it is subdivided into areas, always has at least one area called the backbone. The backbone has the reserved area ID of 0.0.0.0.

The backbone acts as a hub for inter-area transit traffic and the distribution of routing information between areas. Inter-area traffic is routed to the backbone, then routed to the destination area, and finally routed to the destination host within the destination area (for more information, see “Inter-Area Routing” later in this chapter). Routers on the backbone also advertise the summarized routes within their areas to the other routers on the backbone. These summary advertisements are flooded into area routers. Therefore, each router in an area has a routing table that reflects the routes available within its area and the routes corresponding to the summary advertisements of the ABRs of the other areas in the AS.

For example, in Figure 3.18, router R1 advertises all of the routes (the list of address ranges) in Area 0.0.0.1 to all backbone routers (routers R2 and R3) using a summary advertisement. R1 receives summary advertisements from R2 and R3. R1 is configured with summary advertisement information for Area 0.0.0.0. Through flooding, R1 propagates that summary routing information to all of the routers within Area 0.0.0.1. For each router within Area 0.0.0.1, the summary routing information from Areas 0.0.0.0, 0.0.0.2, and 0.0.0.3 is incorporated into the calculation of the routing table.

OSPF Router Types

When an OSPF AS is subdivided into areas, the routers are classified by one or more of the categories defined in Table 3.4.

Table 3.4 OSPF Router Types

Router Type | Description
Internal Router | A router with all interfaces connected to the same area. Internal routers each have a single LSDB.
Area Border Router (ABR) | A router with interfaces connected to different areas. ABRs have multiple LSDBs, one for each attached area.
Backbone Router | A router with an interface on the backbone area. This includes all ABRs and internal routers of the backbone area.
AS Boundary Router (ASBR) | A router that exchanges routes with sources outside of the OSPF AS. ASBRs advertise external routes throughout the OSPF AS.

Inter-Area Routing

Routing within an area is performed by OSPF routers using the least cost path to the destination network. Because routes within an area are not summarized, each router has a route to each network within its area or areas.

Routing between areas takes the following course:

  1. Routers within the source area forward the packet along the least cost path to the nearest ABR.
  2. Backbone routers forward the packet along the least cost path to the nearest ABR connected to the area containing the IP address of the destination host.
  3. Routers within the area containing the IP address of the destination host forward the packet along the least cost path to the destination host.

In Figure 3.19, the packet is forwarded across the routers of Area 0.0.0.1 to router R1, a backbone area router. Then, the packet is forwarded across the routers of the backbone area (Area 0.0.0.0) to Router R2. And finally, the packet is forwarded across the routers of Area 0.0.0.2 to the destination host.

Figure 3.19 Inter-Area Routing in OSPF

Note

OSPF routers do not make routing decisions based on area IDs. All routing decisions are based on the entries in the IP routing table. For example, in the inter-area routing shown in Figure 3.19, the backbone routers are not explicitly forwarding the packet to Area 0.0.0.2. They are forwarding it along the least cost path to the route that is the best match for the destination IP address in the packet.


Virtual Links

It is possible to define areas in such a way that they do not have an ABR physically connected to the backbone. Backbone connectivity for the area is still possible by configuring a virtual link between the non-backbone area and the backbone.

Virtual links can be configured between any two routers that have an interface to a single common non-backbone area. The common non-backbone area is known as the transit area. The transit area must have an ABR that is connected to the backbone. Virtual links cannot be configured across multiple transit areas.

A virtual link is not a physical link. It is a logical link using the least cost path between the ABR of the non-backbone connected area and the backbone ABR of the transit area. A virtual adjacency across the virtual link is formed, and routing information is exchanged. Just as in physical adjacencies, the settings of the two virtual link routers (such as the password, the Hello Interval, and Dead Interval) must match before an adjacency can be successfully established.

In Figure 3.20, Area 0.0.0.3 does not have a router physically connected to the backbone, Area 0.0.0.0. Therefore, a virtual link is configured across the transit area of Area 0.0.0.2 between routers R2 and R3. R2 and R3 are known as virtual link neighbors.

Figure 3.20 OSPF Virtual Link

Configuring Virtual Links

To configure a virtual link, configure each virtual link neighbor with the following:

  • The area ID of the transit area for the virtual link.
  • The OSPF Router ID of the virtual link neighbor.
  • Adjacency settings such as the Retransmit Interval, Hello Interval, Dead Interval, and Password. The Hello Interval, Dead Interval, and Password must match between the two routers on each side of the virtual link in order for an adjacency to be established. The Retransmit Interval specifies how long the OSPF router waits before retransmitting Link State packets.


External Routes

An external route is defined as any route that is not within the OSPF AS. External routes can come from many sources:

  • Other routing protocols such as RIP for IP (v1 and v2), EGP, or BGP.
  • Static routes.
  • Routes set on the router through SNMP.

External routes are learned and propagated throughout the OSPF AS through one or more ASBRs. The ASBR advertises the availability of external routes using a series of external route LSAs. The external route LSAs are flooded throughout the AS (except in stub areas) and become part of the SPF Tree and routing table calculation. Traffic to external networks are routed within the AS using the least cost path to the ASBR.

Figure 3.21 shows an AS with an ASBR and external routes.

Figure 3.21 OSPF External Routes

External Route Filters

By default, OSPF routers acting as ASBRs import and advertise all external routes. You may want to filter out external routes to protect the AS from improper or malicious routing information.

For the Windows 2000 Router, external routes can be filtered on the ASBR by the external route source or by the individual route. You can configure the ASBR to accept or ignore the routes of certain external sources such as routing protocols (RIP v2) or other sources (static routes or SNMP). You can also configure the ASBR to accept or discard specific routes by configuring one or multiple {Network ID, Subnet Mask} pairs.

A combination of these filters configured at the ASBR can ensure that the OSPF AS only receives the correct external routes from the proper sources.

ASBRs and Default Routes

When a router is configured to be an ASBR, it advertises by default all external routes including its own default static route. This default route needs to be valid for all OSPF routers in your AS. An example of an invalid default route is one that points to another router within the OSPF AS. The router used as the default gateway ends up with a default route with the next hop IP address of itself. If this occurs, the packets forwarded using the default route on that router are dropped.

If the default route is not valid for all OSPF routers, it should not be advertised. A valid default route would have the next hop gateway address external to your OSPF AS. This route would only be configured on the router that can directly reach the external network.

There are two ways to avoid this problem:

  1. Do not configure a default gateway on the ASBR.
  2. If the ASBR must have a default gateway, create an OSPF external route filter to filter out its own default route (network ID of 0.0.0.0 with a subnet mask of 0.0.0.0).


Stub Areas

To further reduce the amount of routing information flooded into areas, OSPF allows the use of stub areas. A stub area can contain a single entry and exit point (a single ABR), or multiple ABRs when any of the ABRs can be used to reach external route destinations. For stub areas with multiple ABRs, the external routes are advertised by an ASBR that is outside of the area. AS external routes are not flooded into and throughout a stub area. Routing to all AS external networks in a stub area is done through a default route (network ID 0.0.0.0 with the subnet mask of 0.0.0.0). Thus, a single entry in the routing tables of the routers in a stub area is used to route to all AS external network IDs.

To create the default route, the ABR of a stub area advertises a default route into the stub area. The default route is flooded to all the routers within the stub area, but not outside the stub area. The default route is used by the routers in a stub area for any destination IP address that is not reachable within the AS.

For example, Area 0.0.0.3 in Figure 3.22 is configured as a stub area because all external traffic must travel through its single ABR, router R3. R3 advertises a default route for distribution inside Area 0.0.0.3 instead of flooding the AS external networks into the area.

Figure 3.22 OSPF Stub Areas

All routers in a stub area must be configured so that they do not import or flood AS external routes within the stub area. Therefore, all area configurations for all router interfaces within a stub area must be configured for a stub area. Whether or not a router interface is in a stub area is indicated in a special option bit called the E-bit in the OSPF Hello packet. When the E-bit is set to 1, the router is allowed to accept and flood AS external routes. When the E-bit is set to 0, the router is not allowed to accept and flood AS external routes. Routers receiving Hello packets on interfaces verify that the E-bit of the received Hello packet matches their configuration before establishing an adjacency.

Stub areas have the following constraints:

  • Virtual links cannot be configured using a stub area as a transit area.
  • An ASBR cannot be placed inside a stub area.

Stub areas as defined in the OSPF RFC collapse all external routes into a single default route. Therefore, within a stub area, a router’s routing table contains intra-area routes, inter-area routes, and a default route. The Windows 2000 Router also supports the collapsing of all non-intra-area routes into a single default route. This is known as a totally stubby area. A router’s routing table within a totally stubby area contains intra-area routes and a default route. The default route summarizes all inter-area routes and all external routes.

To configure a stub area on a Windows 2000 Router, when configuring general properties for an area, select the Stub area check box and select the Import summary advertisements checkbox. To configure a totally stubby area on a Windows 2000 Router, select the Stub area check box but do not select the Import summary advertisements checkbox.


Troubleshooting OSPF

If an OSPF environment is properly configured, OSPF routers learn all the least cost routes from adjacent OSPF routers after convergence. The exact list of routes added by OSPF to the IP routing table depends, among other factors, on whether or not areas are configured to summarize their routes, whether or not stub areas or totally stubby areas are being used, and whether or not ASBRs and route filtering is being used.

Most OSPF problems are related to the formation of adjacencies, either physical or logical (through virtual links). If adjacencies cannot form, the LSDBs cannot be synchronized and the OSPF routes will not accurately reflect the topology of the internetwork. Other OSPF problems are related to the lack of routes or existence of improper routes in the IP routing table.

Adjacency Is Not Forming

  • Before proceeding, verify that the two neighboring routers should form an adjacency. If the two routers are the only routers on the network, an adjacency should form. If there are more than two routers on the network, adjacencies only form with the DR and BDR. If the two routers have already formed adjacencies with the DR and the BDR, they will not form adjacencies with each other. In this case, their neighbor should appear as 2-way under neighbor state.
  • Ping the neighboring router to ensure basic IP and network connectivity. Use the tracert command to trace the route to the neighboring router. There should not be any routers between the neighboring routers.
  • Use OSPF logging to log errors and warnings to record information on why the adjacency is not forming.
  • Verify that the routers are enabled for authentication and are using the same password. Windows 2000 OSPF routers have authentication enabled by default and the default password is “12345678”. Change the authentication to match all neighboring OSPF routers on the same network. The password can vary per network.
  • Verify that the routers are configured for the same Hello and Dead Intervals. By default the Hello interval is 10 seconds and the Dead interval is 40 seconds.
  • Verify that the routers agree as to whether the area to which the common network belongs is a stub area or not.
  • Verify that the interfaces of the neighboring routers are configured with the same Area ID.
  • If the routers are on a Non-Broadcast Multiple Access (NBMA) network such as X.25 or Frame Relay, their neighbors must be manually configured using the unicast IP address of the neighbor or neighbors to which the link state information needs to be sent.
  • On Broadcast networks (Ethernet, Token Ring, FDDI) or NBMA networks (X.25, Frame Relay), verify that all routers do not have a Router Priority of 0. At least one router must have a Router Priority of 1 or greater so that it can become the DR for the network.
  • Verify that IP packet filtering is not preventing the receiving (through input filters) or sending (through output filters) of OSPF messages on the router interfaces enabled for OSPF.

Virtual Link Is Not Forming

  • Verify that the virtual link neighbor routers are configured for the same password, Hello Interval, and Dead Interval.
  • For each router, verify that the virtual link neighbor’s router ID is correctly configured.
  • Verify that both virtual link neighbors are configured for the correct transit area ID.
  • For large internetworks with substantial round-trip delays across the transit area, verify that the re-transmit interval is long enough.

Lack of OSPF Routes or Existence of Improper OSPF Routes

  • If you are not receiving summarized OSPF routes for an area, verify that the ABRs for the area are configured with the proper {Network ID, Subnet Mask} pairs summarizing that area’s routes.
  • If you are receiving both individual and summarized OSPF routes for an area, verify that all the ABRs for the area are configured with the proper {Network ID, Subnet Mask} pairs summarizing that area’s routes.
  • If you are not receiving external routes from the ASBR, verify that the source and route filtering configured on the ASBR is not too restrictive, preventing proper routes from being propagated to the OSPF AS.
  • Verify that all ABRs are either physically connected to the backbone or logically connected to the backbone using a virtual link. There should not be backdoor routers—routers connecting two areas without going through the backbone.


DHCP Relay Agent

The Windows 2000 Router is an RFC 1542 compliant Boot Protocol (BOOTP) relay agent relaying Dynamic Host Configuration Protocol (DHCP) messages between DHCP clients and DHCP servers on different IP networks. In this role, the Windows 2000 Router functions as the DHCP Relay Agent. Without a DHCP Relay Agent, a DHCP server is required on every subnet that contains DHCP clients. The DHCP Relay Agent takes broadcasted DHCP messages from DHCP clients and forwards them to the IP addresses of DHCP servers. The responses from the DHCP server are sent to the IP address of the DHCP Relay Agent, which then forwards them to the DHCP client.

For more information about DHCP and its implementation in Windows 2000, see “Dynamic Host Configuration Protocol (DHCP)” in the Microsoft® Windows® 2000 TCP/IP Core Networking Guide.


DHCP Across IP Routers

In a large IP internetwork, DHCP servers should be placed in strategic locations servicing DHCP clients of multiple networks. For this configuration to work effectively, DHCP messages must be able to cross IP routers using a DHCP Relay Agent.

In addition to propagating DHCP messages, a DHCP Relay Agent takes an active role in recording information necessary for DHCP configuration and helps direct DHCP messages between the DHCP server and the DHCP client.

Initial DHCP Configuration

Initial DHCP configuration is done by a DHCP client that has never leased an IP address, has released its IP address, or has received a DHCPNACK in response to attempting to lease a previous IP address. The initial DHCP configuration process consists of four DHCP messages: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK.

DHCPDISCOVER

The DHCP client sends the DHCPDISCOVER, containing the MAC address of the DHCP client, to the limited broadcast IP address (255.255.255.255) and the MAC-level broadcast address. The DHCP Relay Agent receives and processes the DHCPDISCOVER.

As established in RFC 1542, the DHCP Relay Agent can forward the packet to an IP broadcast, multicast, or unicast address. In practice, DHCP Relay Agents forward DHCPDISCOVER messages to unicast IP addresses which correspond to DHCP servers. Before forwarding the original DHCPDISCOVER message, the DHCP Relay Agent makes the following changes:

  • Increments the Hop Count field in the DHCP header. The DHCP Hop Count is separate from the Time to Live (TTL) field in the IP header and is used to indicate on how many networks this DHCPDISCOVER has existed as a broadcast. When the configured maximum Hop Count is exceeded, the DHCPDISCOVER is silently discarded. The default maximum hop count for the Windows 2000 DHCP Relay Agent is 4.
  • If needed, updates the Relay IP Address field (also known as the Gateway IP Address field) in the DHCP header. When the DHCP client sends the DHCPDISCOVER, the Relay IP Address field is set to 0.0.0.0. If the Relay IP Address is 0.0.0.0, the DHCP Relay Agent records the IP address of the interface on which the DHCPDISCOVER message was received. If the Relay IP Address is not 0.0.0.0, the DHCP Relay Agent does not modify it. The Relay IP Address field records the first router interface encountered by the DHCPDISCOVER message.
  • Changes the source IP address of the DHCPDISCOVER to the IP address of the interface on which the broadcasted DHCPDISCOVER was received.
  • Changes the destination IP address of the DHCPDISCOVER to the configured unicast address of the DHCP server.

The DHCP Relay Agent sends the DHCPDISCOVER message as a unicasted IP packet rather than as an IP and MAC-level broadcast. If the DHCP Relay Agent is configured with multiple DHCP servers, it sends each DHCP server a copy of the DHCPDISCOVER.

DHCPOFFER

When responding to the DHCP client’s request for an IP address, the DHCP server uses the Relay IP Address field in the following ways:

  • The Relay IP Address and the subnet masks of the server’s configured scopes are compared through a logical AND to find a scope whose network ID matches the network ID of the Relay IP Address. When a match is found, the DHCP server allocates an IP address from that scope.
  • When sending the offer back to the client, the DHCP server sends the DHCPOFFER message to the Relay IP Address as the destination IP address.

Once received by the DHCP Relay Agent, the Relay IP Address is used to determine which interface to which the DHCPOFFER is to be forwarded. It then forwards the DHCPOFFER to the client using the offered IP address as the destination IP address and the client’s MAC address as the destination MAC address.

DHCPREQUEST

As it does with the DHCPDISCOVER message, the DHCP client sends the DHCPREQUEST, containing the MAC address of the client, to the limited IP broadcast address 255.255.255.255 and to the MAC-level broadcast address. The DHCP Relay Agent receives this packet and forwards it as a directed IP packet to the configured DHCP server or servers.

DHCPACK

The DHCP server initially sends the DHCPACK to the Relay IP Address, as it did with the DHCPOFFER message. When the DHCP Relay Agent receives the DHCPACK, it re-addresses it to the client’s offered IP address and MAC address.

Rebooted Renewal

When a Microsoft-based DHCP client shuts down, it does not send a DHCPRELEASE message to the DHCP server. Instead, when the DHCP client restarts, it attempts to obtain the IP address it was last using through a DHCPREQUEST and DHCPACK exchange of messages.

DHCPREQUEST

When a Microsoft-based DHCP client reboots, it attempts to lease its previously allocated IP address through a broadcasted DHCPREQUEST message. The DHCPREQUEST, sent to the limited IP broadcast address 255.255.255.255 and to the MAC-level broadcast address, contains the MAC address and the previously allocated IP address of the client. The DHCP Relay Agent receives this packet and treats the message in much the same way as a DHCPDISCOVER message. Before forwarding, the DHCP Relay Agent:

  • Increments the Hop Count field in the DHCP header.
  • Records the IP address of the interface on which the DHCPREQUEST message was received in the Relay IP Address field.
  • Changes the source IP address to the IP address of the interface on which the broadcasted DHCPDISCOVER was received.
  • Changes the destination IP address to the unicast address of the DHCP server recorded in the DHCPREQUEST and forwards it as a directed IP packet.

DHCPACK/DHCPNACK

When the DHCP server receives the DHCPREQUEST, it compares the network ID of client’s previously allocated IP address to the network ID of the Relay IP Address.

  • If the two network IDs are the same and the IP address can be reallocated to the DHCP client, the DHCP server initially sends a DHCPACK to the IP address found in the Relay IP Address field. When the DHCP Relay Agent receives the DHCPACK, it re-addresses it to the client’s offered IP address and MAC address.
  • If the two network IDs are the same and the IP address cannot be reallocated to the DHCP client, the DHCP server initially sends a DHCPNACK to the IP address found in the Relay IP Address field. When the DHCP Relay Agent receives the DHCPNACK, it re-addresses it to the client’s offered IP address and MAC address. At this point, the DHCP client must restart the IP address allocation process with a DHCPDISCOVER.
  • If the two network IDs are not the same, the DHCP client has moved to a different subnet, and the DHCP server sends a DHCPNACK to the IP address found in the Relay IP Address field. When the DHCP Relay Agent receives the DHCPNACK, it re-addresses it to the client’s offered IP address and MAC address. At this point, the DHCP client must restart the IP address allocation process with a DHCPDISCOVER.


Troubleshooting the DHCP Relay Agent

If the Windows 2000 DHCP Relay Agent is not providing relay services for DHCP clients on a network, check for the following:

  • Verify that the interface on the Windows 2000 Router that connects to the network where the DHCP clients are located is added to the DHCP Relay Agent IP routing protocol.
  • Verify that the Relay DHCP packets across this interface check box is selected for the DHCP Relay Agent interface connected to the network where the DHCP clients are located.
  • Verify that the IP addresses of DHCP servers configured on the global properties of the DHCP Relay Agent are the correct IP addresses for DHCP servers on your internetwork.
  • From the router with the DHCP Relay Agent enabled, use the PING utility to PING each of the DHCP servers configured in the global DHCP Relay Agent dialog. If you cannot PING the DHCP servers from the DHCP Relay Agent router, troubleshoot the lack of connectivity between the DHCP Relay Agent router and the DHCP server or servers.
  • Verify that IP packet filtering is not preventing the receiving (through input filters) or sending (through output filters) of DHCP traffic.


Network Address Translator

A Network Address Translator (NAT) is an IP router defined in RFC 1631 that can translate IP addresses and TCP/UDP port numbers of packets as they are being forwarded. Consider a small business network with multiple computers connecting to the Internet. A small business would normally have to obtain an Internet Service Provider (ISP)–allocated public IP address for each computer on their network. With the NAT, however, the small business can use private addressing (as described in RFC 1597) and have the NAT map its private addresses to a single or multiple public IP addresses as allocated by its ISP.

For example, if a small business is using the 10.0.0.0 private network for its intranet and has been granted the public IP address of 198.200.200.1 by its ISP, the NAT maps (using static or dynamic mappings) all private IP addresses being used on network 10.0.0.0 to the public IP address of 198.200.200.1.

When a private user on the small business intranet connects to an Internet resource, the user’s IP stack creates an IP packet with the following values set in the IP and TCP or UDP headers (bold text indicates the fields changed by the NAT):

  • Destination IP Address: Internet resource IP address
  • Source IP Address: Private IP address
  • Destination Port: Internet resource TCP or UDP port
  • Source Port: Source application TCP or UDP port

The source host or another router forwards this IP packet to the NAT, which translates the addresses of the outgoing packet as follows (bold text indicates the fields changed by the NAT):

  • Destination IP Address: Internet resource IP address
  • Source IP Address: ISP-allocated public address
  • Destination Port: Internet resource TCP or UDP port
  • Source Port: Remapped source application TCP or UDP port

The NAT sends the remapped IP packet over the Internet. The responding computer sends back the response to the NAT. When received by the NAT, the packet contains the following addressing information (bold text indicates the fields changed by the NAT):

  • Destination IP Address: ISP-allocated public address
  • Source IP Address: Internet resource IP address
  • Destination Port: Remapped source application TCP or UDP port
  • Source Port: Internet resource TCP or UDP port

When the NAT maps and translates the addresses and forwards the packet to the intranet client, it contains the following addressing information (bold text indicates the fields changed by the NAT):

  • Destination IP Address: Private IP address
  • Source IP Address: Internet resource IP address
  • Destination Port: Source application TCP or UDP port
  • Source Port: Internet resource TCP or UDP port

For outgoing packets, the source IP address and TCP/UDP port numbers are mapped to a public source IP address and a possibly changed TCP/UDP port number. For incoming packets, the destination IP address and TCP/UDP port numbers are mapped to the private IP address and original TCP/UDP port number.


Static and Dynamic Address Mapping

The NAT can use either static or dynamic mapping. A static mapping is configured so that traffic is always mapped a specific way. You could map all traffic to and from a specific private network location to a specific Internet location. For instance, to set up a Web server on a computer on your private network, you create a static mapping that maps [Public IP Address, TCP Port 80] to [Private IP Address, TCP Port 80].

Dynamic mappings are created when users on the private network initiate traffic with Internet locations. The NAT automatically adds these mappings to its mapping table and refreshes them with each use. Dynamic mappings that are not refreshed are removed from the NAT mapping table after a configurable amount of time. For TCP connections, the default timeout is 24 hours. For UDP traffic, the default timeout is one minute.


Proper Translation of Header Fields

By default, a NAT translates IP addresses and TCP/UDP ports. These modifications to the IP datagram require the modification and recalculation of the following fields in the IP, TCP, and UDP headers:

  • Source IP Address (outbound from private network), Destination IP Address (inbound to private network)
  • IP Checksum
  • Source Port (outbound from private network), Destination Port (inbound to private network)
  • TCP Checksum
  • UDP Checksum

If the IP address and port information is only in the IP and TCP/UDP headers—for example, with HTTP (or World Wide Web) traffic, the application protocol can be translated transparently. There are applications and protocols, however, that carry IP or port addressing information within their headers. FTP, for example, stores the dotted decimal representation of IP addresses in the FTP header for the FTP port command. If the NAT does not properly translate the IP address, connectivity problems can occur. Additionally, in the case of FTP, because the IP address is stored in dotted decimal format, the translated IP address in the FTP header can be a different size. Therefore, the NAT must also modify TCP sequence numbers to ensure that no data is lost.


NAT Editors

In the case where the NAT component must additionally translate and adjust the payload beyond the IP, TCP, and UDP headers, a NAT editor is required. A NAT editor is an installable component that can properly modify otherwise nontranslatable payloads so that they can be forwarded across a NAT.

Windows 2000 only includes NAT editors for the following protocols:

  • FTP
  • ICMP
  • PPTP
  • NetBIOS over TCP/IP Datagrams

Windows 2000 does not include NAT editors for the following protocols:

  • SNMP
  • LDAP
  • IPSec
  • Microsoft COM
  • RPC


NAT Processes in the Windows 2000 Router

In the Windows 2000 Router, the NAT component is a routing protocol known as Connection Sharing (NAT). The NAT component can either be enabled by adding the Connection Sharing (NAT) as a routing protocol in the Routing and Remote Access Manager or through the sharing of an Internet connection in the Connections Folder. When added and configured, the NAT component exchanges configuration information with the IP Router Manager component.

Installed with NAT are a series of NAT editors. NAT consults the editors when the payload of the packet being translated matches one of the installed editors. The editors modify the payload and return the result to the NAT component.

NAT interacts with the TCP/IP protocol in two important ways:

  • To support dynamic port mappings, the NAT component requests unique TCP and UDP port numbers from the TCP/IP protocol stack when needed.
  • NAT communicates with TCP/IP so that packets being sent between the private network and the Internet are first passed to the NAT component for translation.

Figure 3.23 shows the NAT components and their relation to TCP/IP and other router components.

Figure 3.23 NAT Components

Outbound Internet Traffic

For traffic from the private network that is outbound on the Internet interface, the NAT first assesses whether or not an address/port mapping, static or dynamic, exists for the packet. If not, a dynamic mapping is created. The NAT creates a mapping depending on whether there are single or multiple public IP addresses available.

  • If a single public IP address is available, the NAT requests a new unique TCP or UDP port for the public IP address and uses that as the mapped port.
  • If multiple public IP addresses are available, the NAT performs private IP address to public IP address mapping. For these mappings, the ports are not translated. When the last public IP address is needed, the NAT switches to performing address and port mapping as it would in the case of the single public IP address.

After mapping, the NAT checks for editors and invokes one if necessary. After editing, the NAT modifies the TCP, UDP, and IP headers and forwards the frame using the Internet interface.

Figure 3.24 shows the NAT processing for outbound Internet traffic.

Figure 3.24 NAT Processing of Outbound Internet Traffic

Inbound Internet Traffic

For traffic from the private network that is inbound on the Internet interface, the NAT first assesses whether an address/port mapping, static or dynamic, exists for the packet. If a mapping does not exist for the packet, it is silently discarded by the NAT.

This behavior protects the private network from malicious users on the Internet. The only way that Internet traffic is forwarded to the private network is either in response to traffic initiated by a private network user that created a dynamic mapping or because a static mapping exists so that Internet users can access specific resources on the private network.

After mapping, the NAT checks for editors and invokes one if necessary. After editing, the NAT modifies the TCP, UDP, and IP headers and forwards the frame using the private network interface.

Figure 3.25 shows the NAT processing for inbound Internet traffic.

Figure 3.25 NAT Processing of Inbound Internet Traffic


Troubleshooting NAT

If the Windows 2000 NAT is not providing expected translation services for private to public network traffic, check for the following:

  • Verify that the interface on the Windows 2000 Router that connects to the Internet is added to the Connection Sharing (NAT) routing protocol.
  • Verify that the Enable translation across this interface option on the General tab on the properties page of the Internet interface is selected.
  • If you only have a single public IP address, verify that the Translate TCP/UDP header option on the General tab on the properties page of the Internet interface is selected.
  • If you have multiple public IP addresses, verify that they are typed correctly in text boxes provided on the Address pool tab on the properties page of the Internet interface. If your address pool includes an IP address that was not allocated to you by your ISP, inbound Internet traffic that is mapped to that IP address is routed by the ISP to another location.
  • If you have some applications that do not seem to work through the NAT, try running them from the NAT computer. If they work from the NAT computer and not from a computer on the private network, the payload of the application may not be translatable. Check the protocol being used by the application against the list of supported NAT editors.
  • Verify that IP packet filtering on the private network and Internet interfaces is not preventing the receiving (through input filters) or sending (through output filters) of Internet-based traffic.


IP Packet Filtering

To provide security, an IP router can allow or disallow the flow of very specific types of IP traffic. This capability, called IP packet filtering, provides a way for the network administrator to precisely define what IP traffic is received and sent by the router. IP packet filtering is an important element of connecting corporate intranets to public networks like the Internet.

IP packet filtering consists of creating a series of definitions called filters, which define for the router what types of traffic are allowed or disallowed on each interface. Filters can be set for incoming and outgoing traffic.

  • Input Filters define what incoming traffic on that interface the router is allowed to route or process.
  • Output Filters define what traffic the router is allowed to send from that interface.

Because you can configure both input and output filters for each interface, it is possible to create contradictory filters. For example, the input filter on one interface allows the inbound traffic but the output filter on the other interface does not allow the same traffic to be sent. The end result is that the traffic is not passed across the Windows 2000 Router.

Packet filtering can also be implemented on a non-router computer running Windows 2000 to filter incoming and outgoing traffic to a specific subset of traffic.

Packet filters should be implemented carefully to prevent the filters from being too restrictive, which would impair the functionality of other protocols that may be operating on the computer. For example, if a computer running Windows 2000 is also running Internet Information Services (IIS) as a Web server and packet filters are defined so that only Web-based traffic is allowed, you can not use PING (which uses ICMP Echo Requests and Echo Replies) to perform basic IP troubleshooting. If the Web server is a Silent RIP host, the filters prevent the Silent RIP process from receiving the RIP announcements.

Note

When troubleshooting connectivity or IP-based network problems on a computer running Windows 2000 that is using packet filtering, first verify whether the packet filtering configured on that computer is preventing outgoing or incoming packets for the protocol having the problem.


Windows 2000 IP Packet Filtering

Windows 2000 IP packet filtering is based on exceptions. You can configure Windows 2000 to either pass all traffic except those disallowed by filters or to discard all traffic except those allowed by filters. For example, you may want to configure a filter to allow all traffic except Telnet traffic (TCP port 23). Or you may want to set up filters on a dedicated Web server to process only Web-based TCP traffic (TCP port 80).

Note

The Windows 2000 Router does not allow the use of user-definable filters where a network administrator can create a filter based on any field of the IP, TCP, UDP or ICMP header. The Windows 2000 Router does not support filtering on any protocols other than IP, TCP, UDP, and ICMP.

Windows 2000 allows filtering on various fields in IP, TCP, UDP, and ICMP headers of incoming and outgoing packets.

IP Header

In the IP header, filters can be defined for the following fields:

  • IP Protocol

    An identifier used to demultiplex the payload of an IP packet to an upper layer protocol. For example, TCP uses a Protocol of 6, UDP uses a Protocol of 17, and ICMP uses a Protocol of 1. When you select a protocol such as TCP, UDP, or ICMP in the IP Filters dialog box, the default values for those protocols are assumed. Windows 2000 allows you to type any value in the IP Protocol text box.

  • Source IP Address

    The IP address of the source host, which can be configured with a subnet mask, allowing an entire range of IP addresses (corresponding to an IP network) to be specified with a single filter entry.

  • Destination IP Address

    The IP address of the destination host which can be configured with a subnet mask, allowing an entire range of IP addresses (corresponding with an IP network) to be specified with a single filter entry.

TCP Header

In the TCP header, filters can be defined for two fields: the TCP Source Port field, used to identify the source process which is sending the TCP segment; and for the TCP Destination Port, used to identify the destination process for the TCP segment.

Note

The Windows 2000 Router does not support the configuration of a range of TCP ports. For a range of TCP ports, a separate filter for each port in the range must be configured.

UDP Header

In the UDP header, filters can be defined for two fields: the UDP Source Port field, used to identify the source process which is sending the UDP message; and for the UDP Destination Port, used to identify the destination process for the UDP message.

Note

The Windows 2000 Router does not support the configuration of a range of UDP ports. For a range of UDP ports, a separate filter for each port in the range must be configured.

ICMP Header

In the ICMP header, filters can be defined for two fields: the ICMP Type field, indicating the type of ICMP packet (such as Echo Request or Echo Reply); and for the ICMP Code field, indicating one of possible multiple functions within a given type. If there is only one function within a type, the Code field is set to 0.

Table 3.5 lists commonly used ICMP types and codes.

Table 3.5 Common ICMP Types and Codes

ICMP Type | ICMP Code | Use
0 | 0 | Echo Reply
8 | 0 | Echo Request
3 | 0 | Destination Unreachable - Network Unreachable
3 | 2 | Destination Unreachable - Protocol Unreachable
3 | 3 | Destination Unreachable - Port Unreachable
3 | 4 | Destination Unreachable - Fragmentation Needed and Don’t Fragment Flag set
4 | 0 | Source Quench
5 | 1 | Redirect - Redirected datagrams for the host
9 | 0 | Router Advertisement
10 | 0 | Router Solicitation
11 | 0 | Time Exceeded - TTL expiration
11 | 1 | Time Exceeded - Fragmentation Reassembly expiration
12 | 0 | Parameter Problem

Note

For a complete list of ICMP types and codes, see RFC 1700.


Input Filters

Input filters are configured on an exception basis. You can configure the filter action to either receive all traffic except that which is specified or to drop all traffic except that which is specified.

When multiple filters are configured, the separate filters applied to the incoming packet are compared through a logical OR. If the packet matches at least one of the configured filters, it is received or dropped depending on the filter action setting.


Output Filters

Output filters are configured on an exception basis. You can configure the filter action to either transit all traffic except that which is specified, or to drop all traffic except that which is specified.

When multiple filters are configured, the separate filters applied to the incoming packet are compared through a logical OR. If the packet matches at least one of the configured filters, it is transmitted or dropped depending on the filter action setting.


Configuring a Filter

When adding or editing an input or an output filter, you configure the parameters of the filter in the Add/Edit IP Filter dialog box. When multiple parameters are configured on a given filter, as the filter is applied to the incoming packet, the parameters of the filter are compared through a logical AND. The fields in the packet must match all of the configured parameters of the filter to meet the criteria of the filter.

Note

You cannot configure separate active filters for Receive all except listed below and Drop all except listed below.

You can configure the following fields in the Add/Edit IP Filter dialog box:

Source Network

  • IP Address: Type the source IP network ID or a source IP address.
  • Subnet Mask: Type the subnet mask corresponding to the source network ID or type 255.255.255.255 for a source IP address. The subnet mask bits must encompass all of the bits being used in the IP Address field. The IP address cannot be more specific than the subnet mask.

Destination Network

  • IP Address: Type the destination IP network ID or a destination IP address.
  • Subnet Mask: Type the subnet mask corresponding to the destination network ID, or type 255.255.255.255 for a destination IP address. The subnet mask bits must encompass all of the bits being used in the IP Address field. The IP address cannot be more specific than the subnet mask.

Protocol

  • TCP (Protocol = 6): Select this option to reach text boxes in which you type a source TCP port and a destination TCP port. One or both can be specified. If nothing is specified in these text boxes, they default to 0, meaning any port.
  • UDP (Protocol = 17): Select this option to reach text boxes in which you type a source UDP port and a destination UDP port. One or both can be specified. If nothing is specified in these text boxes, they default to 0, meaning any port.
  • ICMP (Protocol = 1): Select this option to reach text boxes in which you type an ICMP code and an ICMP type. One or both can be specified. If nothing is specified in these text boxes, they default to 255, meaning any code or any type.
  • Any: Select this option to make any IP protocol value assumed.
  • Other: Select this option to reach the text box in which you type any IP protocol.


Filtering Scenarios

This section illustrates filter configurations for commonly implemented filtering scenarios.

Caution

If you combine any of the sample sets of filters, make sure that the desired subset of traffic is allowed and the desired level of security is maintained. For example, if you combine the local host filtering and Web traffic filtering, due to the way that the filters are applied (AND is used within a filter; OR is used between filters), all traffic destined for the host is allowed. The Web traffic input filter is essentially ignored.

Local Host Filtering

Use local host filtering to ensure that only traffic destined for the host is allowed to be processed. This disables the forwarding of packets on the interface on which local host filtering is enabled. Local host filtering is used when an intranet is connected to the Internet and direct routing of packets between the intranet and the Internet is not desired. In this scenario, local host filtering is configured on the Internet interface.

To create a set of filters for local host filtering

  • To create a set of filters for local host filtering, configure the following filters on the Internet interface. With these filters configured, only traffic destined for this host or for all hosts on the host’s network, or multicast traffic is allowed in on the interface.

Using the Drop all except listed below filter action, create a series of input filters with the following attributes.

Destination IP Address of Host IP Address

  • In the Add/Edit IP Filter dialog box, select the Destination network check box, and then type the IP address of the host and the subnet mask of 255.255.255.255 in the appropriate text boxes.

Destination IP Address of Subnet Broadcast

  1. In the Add/Edit IP Filter dialog box, select the Destination network check box, and then type the IP address of the host’s subnet broadcast IP address and the subnet mask of 255.255.255.255 in the appropriate text boxes.
  2. To define the Subnet broadcast, set all the host bits to 1. For example, if a host is configured with an IP address of 172.16.5.98 with a subnet mask of 255.255.255.0 (a subnet of the private IP network 172.16.0.0), this filter would be filtering on the Destination IP address of 172.16.5.255.

Destination IP Address of All Subnets-Directed Broadcast

  • In the Add/Edit IP Filter dialog box, select the Destination network check box, and then type the IP address of the host’s all subnets-directed broadcast address and the subnet mask of 255.255.255.255 in the appropriate text boxes.

The all subnets-directed broadcast is class-based broadcast address where the host bits before subnetting are set to all 1. For the example host, this filter would be filtering on the Destination IP address of 172.16.255.255. The filter for the all subnets-directed broadcast is only necessary when subnetting.

Destination IP Address of the IP Limited Broadcast

  • In the Add/Edit IP Filter dialog box, select the Destination network check box, and then type the IP address of 255.255.255.255 and the subnet mask of 255.255.255.255 in the appropriate text boxes.

The Limited Broadcast is the destination IP address of 255.255.255.255.

Destination IP Address for All Possible Multicast Traffic

  • In the Add/Edit IP Filter dialog box, select the Destination network check box, and then type the IP address of 224.0.0.0 and the subnet mask of 240.0.0.0 in the appropriate text boxes. All possible multicast traffic is allowed in on the interface.

Note

Local host filtering on an interface effectively disables unicast routing on that interface because the only unicast traffic allowed through the interface is destined for the host. Transit traffic is dropped.

Web Traffic Filtering

Web traffic filtering is done on hosts that are Web servers so that only Web-based traffic to and from the Web server service on the host is allowed to be processed. This is done to secure the Web server from malicious attacks on other services running on the Web server. For a Web server connected to the Internet, Web traffic filtering is configured on the Internet interface.

Using the Drop all except listed below filter action, configure the following filters to confine the allowed traffic to packets to and from the Web server service:

  • An input filter for the Destination IP Address of Web server and the TCP Destination Port 80.
  • An output filter for the Source IP Address of Web server and the TCP Source Port 80.

If these filters are the only filters configured, the only traffic allowed through the interface is TCP traffic to and from the Web server service on the Windows 2000 Server–based computer.

Note

The preceding example assumes the default port of the Web server of 80. If you are using a port other than 80, substitute the appropriate port for port 80 in these filters.

FTP Traffic Filtering

FTP traffic filtering is done on hosts that are FTP servers so that only FTP-based traffic to and from the FTP server service on the host is allowed to be processed. This is done to secure the FTP server from malicious attacks on other services running on the FTP server. For a FTP server connected to the Internet, FTP traffic filtering is configured on the Internet interface.

Using the Drop all except listed below filter action, configure the following filters to confine the allowed traffic to packets to and from the FTP server service:

  • Input filters for the Destination IP Address of FTP Server and the TCP Destination Port 21 (the FTP control port), and for the Destination IP Address of FTP Server and the TCP Destination Port 20 (the FTP data port).
  • Output filters for the Source IP Address of FTP Server and the TCP Source Port 21 (the FTP control port), and for the Source IP Address of FTP Server and the TCP Source Port 20 (the FTP data port).

If these filters are the only filters configured, the only traffic allowed through the interface is TCP traffic to and from the FTP server service on the Windows 2000 Server–based computer.

Note

The preceding example assumes the default ports, 20 and 21, of the FTP server. If you are using ports other than 20 and 21, substitute the appropriate ports for ports 20 and 21 in the these filters.

PPTP Traffic Filtering

Point-to-Point Tunneling Protocol (PPTP) traffic filtering is done on hosts that are PPTP servers so that only PPTP-based traffic to and from the PPTP server service on the host is allowed to be processed. This is done to secure the PPTP server from malicious attacks on other services running on the PPTP server. For a PPTP server connected to the Internet, PPTP traffic filtering is configured on the Internet interface.

Using the Drop all except listed below filter action, configure the following filters to confine the allowed traffic to packets to and from the PPTP service running on the server:

  • Input filters for the Destination IP Address of the PPTP server and TCP Destination Port 1723, and for the Destination IP Address of the PPTP server and IP Protocol 47 (Generic Routing Encapsulation [GRE]).
  • Output filters for the Source IP Address of the PPTP server and the TCP Source Port 1723, and for the Source IP Address of the PPTP server and the IP Protocol 47 (GRE).

If the PPTP server is also to be used as a PPTP client to initiate tunneled connections to branch offices in a Virtual Private Network (VPN) scenario, configure the following additional filters:

  • An input filter for the Destination IP Address of the PPTP server and the TCP (established) Source Port 1723.
  • An output filter for the Source IP Address of the PPTP server and the TCP (established) Destination Port 1723.

The TCP (established) filter is used to allow only traffic on the TCP connection that was established by the PPTP client. If TCP (established) is not used, a malicious Internet hacker can penetrate the PPTP server by sending packets from applications using TCP port 1723.

If these filters are the only filters configured, the only traffic allowed through the interface is TCP traffic and tunneled data (GRE traffic) to and from the PPTP server and PPTP client on the Windows 2000 Server–based computer.

L2TP Server Filtering

Layer 2 Tunneling Protocol (L2TP) traffic filtering is done on hosts that are L2TP servers so that only L2TP-based traffic to and from the L2TP server service on
the host is allowed to be processed. This is done to secure the L2TP server from malicious attacks on other services running on the L2TP server. For a L2TP
server connected to the Internet, L2TP traffic filtering is configured on the Internet interface.

Using the Drop all except listed below filter action, configure the following filters to confine the allowed traffic to packets to and from the server running L2TP:

  • An input filter for the Destination IP Address of the L2TP server and UDP Destination Port 1701.
  • An output filter for the Source IP Address of the L2TP server and the UDP Source Port 1701.

If the L2TP server computer is also to be used as a L2TP client to initiate tunneled connections to branch offices in a VPN scenario, configure the following additional filters:

  • An input filter for the Source IP Address of the L2TP server and the UDP Source Port 1701.
  • An output filter for the Destination IP Address of the L2TP server and the UDP Destination Port 1701.

If these filters are the only filters configured, the only traffic allowed through the interface is UDP traffic to and from the L2TP server and client on the Windows 2000 Server–based computer.

Preventing the Ping of Death

The Ping of Death is a denial of service attack where malicious users send one or multiple 64KB ICMP Echo Request messages. The 64KB messages are fragmented and must be reassembled at the destination host. For each separate 64KB message, the TCP/IP protocol must allocate memory, tables, timers, and other resources. With enough fragmented messages, a Windows 2000 Server–based computer can become bogged down so that the servicing of valid information requests is impaired.

To prevent the Ping of Death with Windows 2000 packet filtering, input filters must filter out all ICMP messages. The following filter configuration accomplishes this.

Configure input filters to accept all packets except those for the Destination IP Address of the host and IP Protocol 1.

Note

This filter impairs the use of PING, TRACERT, and other utilities which rely on ICMP messages to provide troubleshooting information.

Denying Spoofed Packets from Private IP Addresses

Another method of performing denial of service attacks is to flood servers with packets, such as TCP connection request packets, from addresses to which there can be no reply. In these cases, the malicious users spoof, or substitute, the source IP address of the packets with something other than the IP address of the interface on which the packets originated. An easy address to spoof is a private address because a response sent to a private address on the Internet results in an ICMP Destination Unreachable message.

To drop Internet traffic from spoofed private IP addresses, configure input filters on the Internet interface to accept all packets except the following:

  • The Source IP Address of 10.0.0.0 with the subnet mask 255.0.0.0.
  • The Source IP Address of 172.16.0.0 with the subnet mask 255.240.0.0.
  • The Source IP Address of 192.168.0.0 with the subnet mask 255.255.0.0.


ICMP Router Discovery

The Windows 2000 Router includes support for the router advertisement and discovery scheme as documented in RFC 1256. To aid in the ease of configuring IP hosts with the IP addresses of local routers and to provide a way for hosts to sense downed routers, RFC 1256 describes the use of ICMP messages for the following two processes.

  • Router Advertisements

    Periodically (by default every 10 minutes), a router sends out a Router Advertisement using an ICMP message (Type 9, Code 0). The Router Advertisement can be sent to the IP multicast address of 224.0.0.1, the local IP broadcast address, or the limited broadcast address (255.255.255.255). In practice, the Router Advertisement is sent to the multicast address. Router Advertisements are explicit notifications to the hosts on the network that the router is still available.

    The Router Advertisement message contains an Advertisement Lifetime, the time after the last received Router Advertisement that the router can be considered down (default of 30 minutes), and a Preference Level, an indication of the router’s preferred status as the default gateway for the network.

  • Router Solicitations

    When a host that supports RFC 1256 needs to be configured with a default gateway (either upon initialization or because its default gateway is down), it sends out a Router Solicitation using an ICMP message (Type 10, Code 0). The Router Solicitation can be sent to the IP multicast address of 224.0.0.2, the local IP broadcast address, or the limited broadcast address (255.255.255.255). In practice, hosts send Router Solicitation messages to the multicast address. Routers on the host’s network that support RFC 1256 immediately respond with a Router Advertisement, and the host chooses the router with the highest preference level as its default gateway.

Note

ICMP Router Discovery is not a routing protocol. Routers only advertise their existence, not the best way to reach a given destination network. If a host uses a non-optimal route, ICMP Redirect messages redirect the host to the better route.

Table 3.6 describes the settings for ICMP Router Discovery.

Table 3.6 ICMP Router Discovery Settings

Router Discovery Setting | Description
Level of Preference | The preference level of this router to be the default gateway. Default value is 0.
Advertisement Rate (minutes) | How often, in minutes, the router is to periodically send Router Advertisement messages. Default is 10 minutes. Note that the advertisements are not sent out exactly every 10 minutes but at a randomized interval of up to 10 minutes.
Advertisement Lifetime (minutes) | The time, in minutes, after which a host considers a router down (after it has received its last Router Advertisement). The default time is 30 minutes.

Windows 2000, with the Enable router discovery advertisements option selected, enables the Router Advertisement process and responses to Router Solicitations from TCP/IP stacks using the IP multicast address of 224.0.0.1. TCP/IP for Windows 2000 and Windows 98 supports the use of Router Solicitation messages to discover the default gateway.


IPX Routing

The Microsoft® Windows® 2000 Server Router is a fully functional Internetwork Packet Exchange (IPX) router supporting Routing Information Protocol (RIP) for IPX, the primary routing protocol used in IPX internetworks; Novell NetWare Service Advertising Protocol (SAP) for IPX, a protocol for the collection and distribution of service names and addresses; and NetBIOS over IPX broadcast forwarding.

In This Chapter

Windows 2000 and IPX Routing

IPX Packet Filtering

RIP for IPX

SAP for IPX

NetBIOS Broadcasts

Related Chapters in the Resource Kit

  • For more information about unicast routing, see “Unicast Routing Overview” in this book.
  • For more information about the Windows 2000 Router, see “Windows 2000 Router” in this book.
  • For more information about Demand-Dial Routing, see “Demand-Dial Routing” in this book.
  • For more information about interoperability with NetWare, see “Interoperability with NetWare” in this book.

Additional Resources

  • For more information about the IPX router, see IPX Router Specification Version 1.10, Part 107 by Novell, Inc., October 16, 1992.
  • For more information about NetWare LANs, see NetWare LAN Analysis, 2nd Edition by Laura Chappel, 1996: Novell Press.

Note to Reviewers: All art in this document is not final.


Windows 2000 and IPX Routing

An Internetwork Packet Exchange (IPX) router is a combination of an IPX routing agent and a Service Advertising Protocol (SAP) agent. The IPX routing agent routes IPX packets between IPX networks and maintains its routing table using Routing Information Protocol (RIP) for IPX. The SAP agent collects and distributes SAP information (a list of services available on the network and their corresponding IPX internetwork addresses) and responds to client SAP requests. For more information about the IPX router components in Windows 2000 see “Windows 2000 Router.”

Microsoft® Windows NT® Server version 4.0 and earlier provided an SAP agent service that allowed Windows NT applications and services, such as File and Print Services for NetWare (FPNW) or Microsoft® Exchange Server, to advertise their service names and addresses for NetWare clients. Microsoft® Windows NT® version 3.51 (Service Pack 2 and later) and Windows NT Server 4.0 provided an IPX routing agent using the RIP for IPX routing protocol. Windows 2000 Server provides an integrated IPX router with an IPX routing agent using the RIP for IPX routing protocol and a SAP agent.


Windows 2000 Router Features for the IPX Protocol Suite

The Windows 2000–based computer running the Routing and Remote Access Service (Rremote access), known as the Windows 2000 Router, provides a rich set of features to support IPX internetworks:

  • IPX packet filtering

    Input and output filters for each interface, configured using key fields in the IPX header.

  • RIP for IPX

    Full support for Routing Information Protocol (RIP) for IPX, the primary routing protocol used in IPX internetworks.

  • IPX route filtering

    Filtering for incoming routes and for the announcement of routes.

  • Static IPX routes

    Static IPX routes that are advertised using RIP for IPX.

  • SAP for IPX

    Full support for Service Advertising Protocol (SAP), the mechanism by which the names and addresses of services running on IPX nodes are collected and distributed for NetWare clients.

  • SAP filtering

    The filtering of incoming service names and the announcement of service names.

  • Static SAP services

    Static SAP service names that are advertised using SAP.

  • NetBIOS broadcast propagation

    The forwarding of NetBIOS over IPX broadcasts, flexibly configured over local area networks (LAN) and demand-dial interfaces.

  • Static NetBIOS names

    Static NetBIOS names that can be configured so that NetBIOS over IPX name query broadcasts for specific NetBIOS names can be forwarded using specific interfaces.

  • Platform to Support Other IPX Routing Protocols

    A platform to support additional IPX routing protocols, such as NetWare Link Services Protocol (NLSP). (The Windows 2000 Router does not provide NLSP, but NLSP can be provided by third party independent software vendors.)


IPX Packet Filtering

In addition to routing IPX traffic, an IPX router can allow or disallow the flow of very specific types of IPX traffic. This capability, called IPX packet filtering, provides a way to precisely define the type of IPX traffic allowed to cross the router.

You can create a series of definitions called filters that indicate to the router the type of traffic allowed or disallowed on each interface. You can set these filters for incoming and outgoing traffic. Input filters define the incoming traffic on a given interface that is allowed to be routed or processed by the router. Output filters define the traffic that is allowed to be sent from that interface.

Figure 5.1 illustrates IPX packet filtering.

Figure 5.1 IPX Packet Filtering

Because both input and output filters can be defined for each interface, it is possible to create contradictory filters. For example, the input filter on one interface allows the inbound traffic, but the output filter on the other interface does not allow the outbound traffic. The result is that the desired traffic is not passed across the router.

The Windows 2000 Router has the capability to perform input and output filtering for each interface based on key fields in the IPX header. The next section explains the structure of an IPX header to help you gain an understanding of the types of IPX filtering that the Windows 2000 Router can perform.


IPX Header Structure

The IPX header, which comes immediately after media and Data Link Layer headers (such as Ethernet, Token Ring, or Point-to-Point Protocol [PPP]), is shown in Figure 5.2.

Figure 5.2 The IPX Header

  • Checksum

    A 16-bit checksum on the IPX header and its payload is typically unused. If unused, the Checksum field is set to 0xFF-FF. If the Checksum is used, the IPX node cannot be configured to use the ETHERNET_802.3 frame type.

  • Length

    The length field indicates the length of the IPX packet (IPX header and IPX payload) in bytes. To accommodate older routers and network adapters, sometimes an IPX node must be configured to ensure that the IPX packet is an even number of bytes. If the packet contains an odd number of bytes, an extra byte is used to fill out the packet to an even number of bytes. The extra byte is not included in the Length field.

  • Transport Control

    The Transport Control field indicates the number of IPX routers that have processed the IPX packet, known as the hop count. Sending nodes set this field to zero, and it is incremented by one by each IPX router in the path from the source to the destination. RIP for IPX routers limit the maximum number of routers in a network path to 16. At the 17th RIP for IPX router, the IPX packet is discarded by the router without notifying the sending node, known as a silent discard. NetWare Link Services Protocol (NLSP) for IPX routers can support a hop count of up to 127.

  • Packet Type

    The Packet Type field indicates the contents of the payload portion of the IPX packet. It allows a number of client protocols to use IPX and be identified by the IPX router. Table 5.1 lists some common defined values of the IPX Packet Type.

Table 5.1 IPX Packet Type Values

Client Protocol | Packet Type (Hex)
Unspecified | 00
RIP | 01
SAP/Normal IPX | 04
SPX | 05
IPX WAN Broadcast (used for NetBIOS over IPX Broadcasts) | 14 (20 in decimal)

Routers can filter out IPX traffic based on the Packet Type field. For example, some routers by default do not propagate NetBIOS over IPX Broadcast traffic and must be manually configured to enable packets with a packet type value of 20.

  • Network (Destination and Source)

    The Destination Network and Source Network fields each identify the network (a segment of the IPX internetwork bounded by IPX routers) to which an IPX node is connected. IPX network numbers are a flat addressing space. No subnetting (the subdivision of network IDs) or summarization of groups of IPX networks is possible with RIP for IPX routing. RIP for IPX routers must have a route to each network number in their routing tables. All IPX networks must be given a unique IPX network number.

  • Node (Destination and Source)

    The Destination Node and Source Node fields each identify a node on an IPX network. The 6-byte fields can be used to store physical addresses—also known as Media Access Control (MAC) addresses.

  • Socket (Destination and Source)

    The Destination Socket and Source Socket fields identify the software process addresses of the destination and source applications respectively. With multiple processes communicating between the same two computers, the IPX Network and Node numbers are the same. The IPX Socket number is a software process identifier that is used to forward the IPX payload to the proper process.

    Many socket numbers are well known. For example, the file server process running on Novell NetWare or compatible file servers uses the well-known socket address of 0x451. Any requests to socket 0x451 on the NetWare file server are forwarded to the NetWare file server process. NetWare file server clients and IPX applications that do not use a well-known socket number use dynamically allocated socket numbers. Table 5.2 lists some common, defined values for IPX socket numbers.

Table 5.2 IPX Socket Numbers

Process | Socket Number (Hex)
NCP Server | 451
RIP | 453
SAP | 452
NetBIOS | 455

Note

The IPX socket is not the same as a socket in the Windows Sockets 2.x API (WinSock). A socket in WinSock is a generalized process endpoint. A TCP/IP-based WinSock socket is a combination of the IP Address and port number that identifies a process endpoint on an IP internetwork. An IPX-based WinSock socket is a combination of the IPX Network, IPX Node, and IPX Socket numbers that identifies a process endpoint on an IPX internetwork.


Demultiplexing an IPX Packet

When an IPX packet arrives at its destination and is handed to the IPX protocol, the application data must be demultiplexed, or forwarded to the proper process.

The demultiplexing of the IPX packet within the destination host is done in two stages. First, the IPX module checks the Destination Network and Node numbers to ensure that they correspond to a locally configured IPX interface. Second, the IPX module checks the Destination Socket number and based on its value, passes the IPX payload (the resulting packet minus the IPX header) to the appropriate process.

Figure 5.3 illustrates the IPX demultiplexing process.

Figure 5.3 Demultiplexing an IPX Packet

For example, a NetWare client sends a file sharing request to a NetWare server. Upon arrival at the NetWare server’s IPX module, the destination Network and Node numbers are checked to verify that it corresponds to a local IPX interface. The IPX module then notes the Destination Socket field value of 0x451 and passes the IPX payload to the NetWare file server process.


The Windows 2000 Router IPX Packet Filtering

The Windows 2000 Router IPX packet filtering is based on exceptions. You can either configure the Windows 2000 Router to pass all IPX traffic except those disallowed by filters or to discard all IPX traffic except those allowed by filters. For example, you may want to set up output filters to forward all traffic except for SAP advertisements. Or, you may want to set up an input filter on a dedicated SQL server to disregard all but SQL-based Sequence Packet Exchange (SPX) traffic.

The Windows 2000 Router allows configuration of IPX filters based on the following fields:

  • IPX Packet Type
  • Source Network Number
  • Source Node Address
  • Source Socket
  • Destination Network Number
  • Destination Node Address
  • Destination Socket

Note

Both the Source and Destination Network Numbers can be configured with a network mask allowing a range of IPX Network Numbers to be specified with a single filter entry. To determine whether the Network Number of an IPX packet matches the filter, the Windows 2000 Router uses AND to combine the Network Mask and the Network Number in the IPX packet and compares the result to the filter Network Number. The digit 0 can be used as a wildcard for a hex digit and F for a specific hex digit.

Configuring an IPX Filter

You can configure IPX input or output filtering by selecting a filter action and adding a series of filters using the IPX Filters Configuration dialog box, as shown in Figure 5.4.

Figure 5.4 IPX Packet Filters Configuration Dialog Box

Note

You cannot configure separate active filters for Receive all except listed below and Drop all except listed below.

You can specify the parameters of an input or output filter using the Add/Edit IPX Filter dialog box shown in Figure 5.5. If multiple parameters are configured, the logical operation, AND, combines the parameters of the filter during the filtering process. For example, if the Packet Type and Destination Socket are specified in the filter, the IPX packet passes the filter if both the IPX packet’s Packet Type and its Destination Socket match those of the filter.

Note

All numbers in the Add/Edit IPX Filter dialog box shown in Figure 5.5 are entered in hexadecimal.

Figure 5.5 Add/Edit IPX Filter Dialog Box

The following two sample IPX filters provide examples of IPX filtering scenarios and the implementation of IPX filtering using the fields in the Add/Edit IPX Filter dialog box. These examples are provided to illustrate how IPX filters are configured, not as a recommendation of specific IPX filtering for your network.

To configure an IPX input filter using the network mask (Example)

To allow only the processing of received IPX packets with the Destination Network Number starting with the hex digits AB, configure the input filter as follows.

  1. In the IPX Packet Filters Configuration dialog box, click Add.
  2. In the Add/Edit IPX Filter dialog box in the Network Number text box, under Destination, type AB000000.
  3. In the Network Mask text box, under Destination, type FF000000.
  4. Click OK.
  5. In the IPX Packet Filters Configuration dialog box, select the Drop all except listed below option.
  6. Click OK.

This filter uses the network mask to express a range of IPX network numbers from AB000000 to ABFFFFFF.

To configure an IPX output filter using the network mask (Example)

To prevent the transmission or forwarding of all IPX traffic from the Source IPX Network Number of CC000001, configure the output filter as follows:

  1. In the IPX Packet Filters Configuration dialog box, click Add.
  2. In the Add/Edit IPX Filter dialog box, in the Network Number text box, under Source, type CC000001.
  3. In the Network Mask text box, under Source, type FFFFFFFF.
  4. Click OK.
  5. In the IPX Packet Filters Configuration dialog box, select the Receive all except listed below option.
  6. Click OK.

This filter uses the network mask to express the single IPX network number CC000001.

Note

The network mask in the IPX Add/Edit Filter dialog box is used only as an administrative convenience to express a range of IPX network IDs. This does not mean that the Windows 2000 Router is implementing a subnetting scheme for IPX internetworks. RIP for IPX internetworks use a flat network addressing space and do not support subnetting or route summarization.


RIP for IPX

RIP for IPX, a distance vector routing protocol, distributes routing information on an IPX internetwork. RIP for IPX was derived from the Xerox Network Systems (XNS) form of RIP but contains an additional field called the Tick Count. The Tick Count is an estimate of the amount of time it takes an IPX packet to reach the destination network. The Tick Count enables the RIP for IPX router to choose the route that has the lowest delivery delay.

To reduce convergence time, RIP for IPX uses split horizon and triggered updates. For information about split horizon and triggered updates, see “Unicast IP Support.”

RIP for IPX consists of the following types of messages:

  • RIP clients, such as workstations, can locate the optimal route to an IPX network number by broadcasting a RIP GetLocalTarget route request.
  • Routers can request routing information from other routers by broadcasting a RIP general route request.
  • Routers can respond to RIP GetLocalTarget and RIP general route requests.
  • Routers can periodically (every 60 seconds by default) broadcast their routing tables using split horizon.
  • Routers can perform a triggered-update broadcast to inform adjacent routers of a change in the IPX internetwork configuration.


IPX Routing Tables

The IPX routing table is maintained by the RIP for IPX routing protocol. An entry in an IPX routing table contains the following fields:

  • Network Number

    The IPX Network Number that is matched to the destination network number in a packet's IPX header.

  • Forwarding MAC Address

    The destination MAC address of the IPX packet when it is forwarded to the next hop. For directly attached networks, the Forwarding MAC Address field is blank.

  • Tick Count

    The number of ticks it takes to reach the destination network where one tick is approximately 1/18 of a second. This estimate is based on ongoing RIP requests and replies and is determined by the transmission speed of network segments. LAN links are typically one tick, and WAN links, such as a T-1 link, are usually six or seven ticks. The tick count is an estimated, not precise, measurement of delay.

  • Hop count

    The number of routers that must be crossed to reach the IPX network number.

  • Interface (or port)

    The interface (or network adapter) that is used when forwarding IPX traffic using this route. The router has one interface installed for each attached network segment.

Figure 5.6 shows the structure of the IPX routing table.

Figure 5.6 IPX Routing Table

If there are multiple routes to an IPX network number, IPX routers use the following process to select a route:

  1. Select the route with the lowest number of ticks.
  2. If there are multiple routes with the lowest number of ticks, select the route with the lowest number of hops.
  3. If there are multiple routes with the lowest number of ticks and the lowest number of hops, the router chooses from the routes with the lowest number of ticks and the lowest number of hops.


RIP for IPX Operation

The RIP operation for an IPX router consists of the following processes:

  • Initialization

    At startup, the IPX router broadcasts a RIP packet on each of its attached networks informing adjacent routers of the network numbers that are directly attached to the IPX router. Adjacent IPX routers process the broadcast and add appropriate entries to their routing tables. The initializing IPX router also broadcasts a RIP general request on all of its attached networks. The adjacent IPX routers respond to the RIP general request by sending their routing tables to the initializing IPX router, which uses them to build its own routing table.

  • Ongoing maintenance

    Every 60 seconds, the IPX router broadcasts its routing table (using split horizon) to all attached networks. Adjacent IPX routers receive the announced routes and update their routing tables accordingly.

  • Administrative router shutdown

    If an IPX router is brought down through an administrative action, it sends a RIP broadcast on all locally attached networks. In this broadcast all routes available through the router have a hop count of 16, indicating that these routes are no longer available. (All IPX routes must have a hop count of less than 16 to be considered reachable.) Neighboring routers propagate this change throughout the IPX internetwork through a triggered update.

  • Downed link

    If a link corresponding to one of the router’s interfaces goes down and this failure is detected by the interface hardware and indicated to the routing process, IPX routes learned through the interface are no longer reachable. The unreachable IPX network numbers are announced, with a hop count of 16, in a triggered update. Note that most LAN-based interface hardware does not detect media faults, and therefore, the downed link is not immediately sensed. Many WAN adapters, however, have the ability to sense that a link to the WAN service provider is down.

  • Downed router

    An IPX router that goes down due to a power outage or other hardware or software failure does not have the ability to inform neighboring routers that routes once available through it are now unavailable. To prevent the lingering existence of unavailable network numbers in routing tables, each learned entry in the IPX routing table has a timeout value of 3 minutes (default value). If the entry is not refreshed in 3 minutes, it is set to unreachable (it is given a hop count of 16) and eventually removed. Therefore, if an IPX router goes down, it takes up to 3 minutes for the neighboring routers to time out routing table entries for routes that had been available through the downed router. The adjacent routers then broadcast those changes through a triggered update.


RIP for IPX Packet Structure

The RIP for IPX header (shown in Figure 5.7) comes immediately after the IPX header. RIP for IPX packets have a Packet Type of 0x1 and Source and Destination Socket numbers of 0x453.

Figure 5.7 The RIP for IPX Packet Structure

  • Operation

    The 2-byte Operation field indicates the type of RIP for IPX message. Two values are defined:

    • 0x00-01 - RIP Request is set by a client attempting to find the best route to a destination network (a RIP GetLocalTarget request), or by a router to request all available routes from adjacent routers upon startup (a RIP general request).
    • 0x00-02 - RIP Response is set by a router replying to either a RIP GetLocalTarget or general request. Periodic announcements are also sent as RIP Response messages.

Following the Operation field is one or multiple RIP routes.

For RIP Requests, a single RIP route is included. For the RIP GetLocalTarget request, the single route includes the IPX network number of the desired destination network. For the RIP general request, the IPX network number is set to 0xFF-FF-FF-FF.

For RIP Responses, one or multiple RIP routes are included. For the response to the GetLocalTarget request, a single route is included. For the response to the RIP general request or a periodic announcement, up to 50 IPX routes can be sent in a single RIP for IPX packet. The maximum size for a RIP for IPX packet is 432 bytes. If more than 50 routes need to be sent, they are sent in multiple RIP for IPX packets.

  • Network Number

    The 4-byte Network Number field indicates the IPX Network Number.

  • Hop Count

    The 2-byte Hop Count field indicates the number of routers that are crossed when using this route.

  • Tick Count

    The 2-byte Tick Count field indicates the number of ticks it takes for an IPX packet to be sent using this route.


RIP for IPX Route Filters

RIP for IPX filters are available from the Input Filters and Output Filters options in the RIP for IPX Configuration dialog box. RIP route filtering allows input and output filtering on each interface and is based on exceptions. You can either configure the Windows 2000 Router to:

Accept or announce all RIP for IPX routes except those disallowed by filters.

– Or –

Discard or not announce all RIP for IPX routes except those allowed by filters.

Figure 5.8 shows the Input Route Filters and the Route Filter dialog boxes.

Figure 5.8 RIP for IPX Route Filter Dialog Boxes

The following two sample RIP route filters provide examples of route filtering scenarios and the implementation of route filtering using the fields in the Route Filter dialog box. These examples are provided to illustrate how route filters are configured, not as a recommendation of specific route filtering for your network.

To set a RIP for IPX route input filter (Example)

Set the following input filter in order to discard all RIP for IPX routes except those starting with the hexadecimal digit A.

  1. In the Input Route Filters dialog box, click Add.
  2. In the Network Number text box, type A0000000.
  3. In the Network Mask text box, type F0000000.
  4. Click OK.
  5. In the Input Route Filters dialog box, select the Deny Routes Except Listed Below option.
  6. Click OK.

This filter uses the network mask to express a range of IPX network numbers from A0000000 to AFFFFFFF.

To set a RIP for IPX route output filter (Example)

Set the following output filter in order to announce all RIP for IPX routes except the specific IPX Network ID of BB0000099.

  1. In the Output Route Filters dialog box, click Add.
  2. In the Network Number text box, type BB0000099.
  3. In the Network Mask text box, type FFFFFFFF.
  4. Click OK.
  5. In the Output Route Filters dialog box, select the Permit Routes Except Listed Below option.
  6. Click OK.

This filter uses the network mask to express the single IPX network number BB000009.

Note

The network mask above is used only as an administrative convenience to express a range of IPX network numbers. This does not mean that the Windows 2000 Router is implementing a subnetting scheme for IPX internetworks. RIP for IPX internetworks use a flat network addressing space and do not support subnetting or route summarization.

Note

You cannot configure separate active filters for Permit Routes Except Listed Below and Deny Routes Except Listed Below.


Static IPX Routes

The Windows 2000 Router allows the configuration of static IPX routes in the IPX routing table. Static IPX routes are typically used to define the IPX network numbers that are available across a dial-up connection. For more information about how static IPX routes are used over dial-up connections, see “Demand Dial Routing.”

Static IPX routes are announced over LAN interfaces using normal RIP for IPX processes.

To add a static route

  1. In the Routing and Remote Access Manager console tree, click the plus sign (+) next to IPX Routing, right-click Static Routes, and then click Add Static Route.
  2. To define a static IPX route, in the Static Route dialog box, shown in Figure 5.9, type the following in the appropriate text boxes:
    • Network Number (4-byte IPX Network Number in hexadecimal [8 hex digits]).
    • Next Hop MAC Address (6-byte MAC address of the next hop in hexadecimal [12 hex digits]).
    • Tick Count (number of ticks to get to the Network Number).
    • Hop Count (number of routers to be traversed to get to the Network Number).
    • Interface (Windows 2000 Router interface through which the Network Number can be reached. For dial-up connections, the name of the appropriate demand-dial interface is selected).

Figure 5.9 shows the IPX Static Route dialog box.

Figure 5.9 Static IPX Route Dialog Box


SAP for IPX

The Novell NetWare Service Advertising Protocol (SAP) for IPX provides a name resolution mechanism for clients to resolve the addresses of services on an IPX internetwork. Through SAP, service-providing hosts, such as file servers, print servers, and application servers advertise their service names, service types, and IPX internetwork addresses using broadcasts. The service and IPX internetwork address information is collected in a database called a SAP table by IPX routers and Novell NetWare servers.

The SAP table information is periodically advertised and propagated throughout the internetwork, in a way similar to that in which IPX routes are announced. Services are added and removed from the SAP table dynamically: they are added and maintained in the SAP table based on periodic announcements, and they are removed from the SAP table through a time-out mechanism when announcements are no longer received. To reduce convergence time, SAP uses split horizon and triggered updates. For information about split horizon and triggered updates, see “Unicast IP Support.”

SAP for IPX consists of the following types of messages:

  • SAP clients such as workstations request the name and address of the nearest server of a specific type by broadcasting a SAP GetNearestServer request.
  • Routers or SAP clients request the names and addresses of all services or of all services of a specific type by broadcasting a SAP general service request.
  • Routers respond to SAP GetNearestServer or SAP general service requests.
  • Routers periodically (every 60 seconds by default) broadcast their SAP tables using split horizon.
  • Service-providing hosts that are not routers periodically (every 60 seconds by default) broadcast their services.
  • Routers perform a triggered update broadcast to inform neighboring routers of a change in the SAP table.


IPX Routers and the Internal Network Number

To facilitate optimal communication to services running on IPX routers advertising themselves using Novell NetWare Service Advertising Protocol (SAP), IPX routers that are hosting services, such as Novell NetWare servers or Windows 2000 Server–based computers, require the configuration of an IPX internal network number. The IPX internal network is a virtual network inside the router. Attached to this virtual network is a virtual network adapter with the MAC address of 0x00-00-00-00-00-01. The IPX internal network is announced using RIP for IPX just as physical IPX networks are. When services running on the router are advertised with SAP, they are advertised with the IPX internetwork address of the internal network number and the virtual MAC address.

The IPX internal network allows for the optimal routing of packets to services running on the IPX router. The following analysis of the IPX traffic before and after the use of the IPX internal network clearly illustrate this optimization.

IPX Traffic Before the IPX Internal Network

Figure 5.10 depicts a simple IPX internetwork and a file server process where the IPX internal network is not being used.

Figure 5.10 Prior to Defining an IPX Internal Network Number

  1. The NetWare file server process running on IPX Router 1 advertises its location (using SAP) at the server address of AAAAAAAA:111111111111:0451 (IPX network:IPX Node:IPX Socket).
  2. The Host resolves the file server address by querying its default NetWare server (not shown in Figure 5.10).
  3. The Host broadcasts a RIP GetLocalTarget packet on network BBBBBBBB requesting the best route to IPX network AAAAAAAA.
  4. IPX Router 1 responds with a route that is 1 hop and 2 ticks away.
  5. IPX Router 2 responds with a route that is 1 hop and 2 ticks away.
  6. The Host chooses IPX Router 2’s response (either because it was the first response received or through a random selection of multiple routers with the lowest tick count).
  7. The Host sends a connection request packet to the file server process at AAAAAAAA:111111111111:0451 by forwarding it to IPX Router 2 at the MAC address of 44-44-44-44-44-44 on network BBBBBBBB.
  8. IPX Router 2 forwards the connection request packet to Router 1 at its MAC address 11-11-11-11-11-11 on network AAAAAAAA.
  9. The file server process on Router 1 responds to the connection request packet by forwarding it to the Host’s MAC address (not shown in the figure) on network BBBBBBBB.

The end result of the RIP GetLocalTarget sent by the Host is that packets sent from the Host to the file server process take a route that is not optimal. They are forwarded to IPX Router 2 when the optimal route is to IPX Router 1.

IPX Traffic After the IPX Internal Network

Figure 5.11 depicts the same simple IPX internetwork and file server process where the IPX internal network is being used.

Figure 5.11 After Defining an IPX Internal Network Number

  1. The NetWare file server process running on IPX Router 1 advertises its location (using SAP) on the internal network at the server address of CCCCCCCC:000000000001:0451 (IPX network:IPX Node:IPX Socket).
  2. The Host resolves the file server address by querying its default NetWare server (not shown in Figure 5.11).
  3. The Host broadcasts a RIP GetLocalTarget packet on network BBBBBBBB requesting the best route to IPX network CCCCCCCC.
  4. IPX Router 1 responds with a route that is 1 hop and 2 ticks away.
  5. IPX Router 2 responds with a route that is 2 hops and 3 ticks away.
  6. The Host always chooses IPX Router 1’s response because Router 1’s route to network CCCCCCCC has the lowest tick count.
  7. The Host sends a connection request packet to the file server process at CCCCCCCC:00000000001:0451 by forwarding it to IPX Router 1 at the MAC address of 22-22-22-22-22-22 on network BBBBBBBB.
  8. The file server process on Router 1 responds to the connection request packet by forwarding it to the Host’s MAC address (not shown in the figure) on network BBBBBBBB.

The end result of the RIP GetLocalTarget by the Host is that packets sent from the Host to the file server process always take the optimal route.

The Windows 2000 Router and the IPX Internal Network and Internal Adapter

A Windows 2000 Router supporting IPX routing can be configured with a unique IPX internal network number that is entered in the properties of the IPX/SPX/NetBIOS Compatible Transport. If the internal IPX network number is not configured, a unique IPX network number is automatically configured during the startup of the Windows 2000 Router.

The Windows 2000 Router automatic configuration process picks a random IPX network number and sends out a RIP GetLocalTarget packet requesting a route to the chosen IPX network number. If a RIP response is received, the chosen IPX network number cannot be used, and a new random IPX network number is chosen. If a RIP response is not received, the chosen IPX network number is automatically entered in the properties of the IPX/SPX/NetBIOS Compatible Transport.

To see the virtual network adapter corresponding to the IPX internal network, in the Routing and Remote Access Manager console tree, click the plus sign (+) next to your server, and then click Routing Interfaces. Internal appears in the details pane (see Figure 5.12). Internal is also found in many of the containers under IPX Routing.

Figure 5.12 The IPX Internal Adapter


SAP Tables

An entry in a SAP table contains the following fields:

Server Name.
The name of the server hosting the service.

Server Type.
The type of service (for example, file server, print server, or application server).

Server Address.
The full Network:Node:Socket IPX address of the service. For example, the file and print sharing process on a NetWare server might have the Server Address of 000000AA:0000000000001:0451.

Hop Count.
The number of routers to cross to reach the server hosting the service. The maximum hop count for services is 15. Services 16 hops away or greater are considered unreachable.

Interface (or Port).
The interface (network adapter) on which the SAP entry was learned.

Figure 5.13 illustrates the structure of the SAP table.

Figure 5.13 SAP Table

If there are multiple entries for the same Server Name and Server Type, IPX routers select the SAP table entry with the lowest number of hops. If multiple SAP table entries have equally low hop counts, the router chooses randomly from those.


SAP Operation for an IPX Router

SAP operation for an IPX router consists of the following processes:

  • Initialization

    If the IPX router is also a hosting service, such as a Novell NetWare server or Windows 2000 Server–based computer, it broadcasts a SAP packet onto each attached network informing adjacent routers of its own services. The IPX router then broadcasts a SAP general request for all services onto each attached network. The responses to the SAP general request are used to build the SAP table.

  • Ongoing maintenance

    Every 60 seconds, the IPX router broadcasts its SAP Table using split horizon on all attached networks. Adjacent IPX routers receive the advertised services and update their SAP tables appropriately.

  • Administrative router shutdown

    If an IPX router is brought down properly through an administrative action, it sends a SAP broadcast on all attached networks indicating that the services previously available through the router are no longer available. The SAP Agent sets the hop count for the services to 16 to indicate that these services are unreachable. Adjacent routers propagate this change throughout the IPX internetwork with a triggered update.

  • Downed link

    If a link corresponding to one of the router’s interfaces goes down and this failure is detected by the interface hardware and indicated to the router, SAP services learned through the interface are unreachable. The unreachable SAP services are advertised with a hop count of 16 in a triggered update. Note that most LAN-based interface hardware does not currently detect media faults and therefore this change is not immediately sensed and propagated. Many WAN adapters, however, have the ability to sense that a link to the WAN service provider is down.

  • Downed router

    If a router goes down due to a power outage or other hardware failure, it does not have the ability to inform the adjacent routers that the services available through the router are no longer available. To prevent the lingering existence of inaccessible services in SAP tables, each learned entry in the SAP table of each IPX router has a default timeout value of 3 minutes. If the entry is not refreshed in 3 minutes, it is given a hop count of 16 and eventually removed. Therefore, if an IPX router goes down, it takes up to 3 minutes for the adjacent routers to time out the entries in their SAP table for the services that were available through the downed router. The adjacent routers then broadcast those changes through a triggered update.


SAP Packet Structure

The SAP header, shown in Figure 5.14, immediately follows the IPX header. SAP packets have an IPX Packet Type of 0x4 or 0x0 and Source and Destination Socket numbers of 0x452.

Figure 5.14 The SAP for IPX Packet Structure

Note

Figure 5.14 depicts the packet structure for the SAP Response and SAP GetNearestServer Response. The SAP Request and SAP GetNearestServer Requests packets only contain the Operation and Service Type fields and are a 34-byte packet (30 bytes for the IPX header, 4 bytes for the SAP header).

  • Operation

    The 2-byte Operation field indicates the type of SAP message. Table 5.3 defines the values for the Operation field.

Table 5.3 SAP Operations

Operation | Type of Message | Description
1 | Request | Sent by a router or SAP client to request all services or all services of a specified type.
2 | Response | A reply to a SAP Request. Periodic SAP advertisements are also sent as a SAP Response.
3 | GetNearestServer Request | Sent by a workstation to request the IPX internetwork address of the nearest (quickest response) server of a specified service type.
4 | GetNearestServer Response | Sent in response to the SAP GetNearestServer Request and contains a single name and IPX internetwork address of the nearest server of a requested service type.

Following the Operation field is a series of up to 7 SAP services in the same SAP message for a maximum SAP packet size of 480 bytes. If more than 7 services need to be sent, they are sent in multiple SAP packets.

  • Service Type

    The 2-byte Service Type field indicates the type of service that the service provides. Service types are assigned uniquely by Novell, Inc. Some commonly defined SAP service types are listed in Table 5.4.

Table 5.4 SAP Service Types

Server | Service Type (hex)
Unknown | 00-00
NetWare File Server | 00-04
NetWare Print Server | 00-07
Microsoft RPC Server | 06-40
General SAP Request | FF-FF

  • Server Name

    The 48-byte Server Name field stores the name of the server advertising the service. The combination of Server Name and Service Type uniquely identifies a service on an IPX internetwork. Server names under 48 bytes are terminated with the ASCII NULL character.

  • Network Number

    The 4-byte Network Number field indicates the IPX network number where the server hosting the service resides.

    The 6-byte Node Number field indicates the IPX node number where the server hosting the service resides.

  • Socket Number

    The 2-byte Socket Number field indicates the socket number on which the service process is listening.

  • Intermediate Networks

    The 2-byte Intermediate Networks field indicates the number of routers to traverse to reach the server hosting the service.


SAP Filters

SAP filters are available from the Input Filters and Output Filters buttons in the SAP for IPX Configuration dialog box. You can configure input and output SAP filtering on each Windows 2000 Router interface to either permit or deny services based on exceptions, as shown in Figure 5.15.

Figure 5.15 SAP for IPX Input Filter Dialog Boxes

Note

You cannot configure separate active filters for Permit Services Except Listed Below and Deny Services Except Listed Below.

Note

When applying the filter, the logical operator, AND, is used to combine specified parameters within each filter. OR is used to combine the specified parameters between filters.


Static Services

The Windows 2000 Router allows the creation of static services in the SAP table. Static services are advertised using normal SAP processes. Static SAP services are typically used to define the services that are available across a dial-up connection. For more information about how static SAP services are used over dial-up connections, see “Demand Dial Routing.”

To add static services, in the Routing and Remote Access Manager console tree, click the plus sign (+) next to IPX Routing, right-click Static Services, and then click Add Static Services. Figure 5.16 shows the resulting Static Service dialog box.

Figure 5.16 SAP Static Services Dialog Box


NetBIOS Broadcasts

To facilitate the operation of NetBIOS-based applications on an IPX internetwork, NetBIOS over IPX provides standard NetBIOS services such as datagrams (single packets sent without acknowledgement such as broadcasts), sessions (multiple packets sent with acknowledgements between two endpoints) and name management (registering, querying, and releasing NetBIOS names).

For more information about NetBIOS, see the Microsoft® Windows® 2000 Resource Kit TCP/IP Core Networking Guide.

NetBIOS over IPX is implemented with two different packet structures:

  • NetBIOS over IPX broadcasts

    Used to perform NetBIOS datagram and name management functions, such as Name Queries and Name Registrations. IPX routers might or might not forward NetBIOS over IPX broadcast packets.

  • NetBIOS over IPX sessions

    Used to provide connection-oriented, reliable data transfer between two NetBIOS applications on an IPX internetwork. NetBIOS over IPX session traffic is unicast to a specific IPX internetwork address, rather than broadcasted. NetBIOS over IPX sessions are characterized by an IPX packet type of 0x04 (Normal IPX), and an IPX Source or Destination Socket of 0x455.

    Because all NetBIOS over IPX session traffic is forwarded by IPX routers, the following sections discuss only NetBIOS over IPX broadcasts and how the Windows 2000 Router supports them.


The IPX WAN Broadcast

An IPX router must be able to propagate broadcast traffic in order for nonroutable protocols (such as NetBIOS), which rely on broadcast traffic, to function properly in an IPX internetwork. (NetBIOS relies on broadcast traffic to register and resolve NetBIOS names.) Support for the propagation of broadcast traffic across IPX routers is provided by a special IPX packet called the IPX WAN Broadcast or IPX Packet Type 20.

The IPX WAN Broadcast header is characterized by an IPX packet type of 0x14 (20 in decimal) and the IPX Destination Node address of 0xFF-FF-FF-FF-FF-FF. IPX routers can be configured to either propagate or silently discard IPX WAN Broadcasts.

NetBIOS over IPX Broadcasts contain the IPX WAN Broadcast header.

IPX WAN Broadcasts and Microsoft Networking

In Windows 2000, Windows NT 4.0 and earlier, Windows for Workgroups, or Windows 95 or Windows 98 networking, server, and workstation services using Server Message Blocks (SMBs) for file and print sharing communication can use NetBIOS over IPX or just IPX. The process of sending SMBs over IPX without NetBIOS is known as direct hosting.

IPX WAN Broadcasts are used for the following NetBIOS over IPX SMB–based networking processes:

  • NetBIOS Name Registration
  • NetBIOS Name Query
  • Browser Host Announcement
  • NetLogon

IPX WAN Broadcasts are used for the following direct hosting SMB-based networking processes:

  • Locate Server Name Query
  • Browser Host Announcement

Disabling the propagation of IPX WAN Broadcasts can impair the ability of Microsoft SMB–based computers to propagate browsing information, resolve names, and establish connections on an IPX internetwork.

Note

When direct hosting, an IPX over NetBIOS header is not used. Instead, the SMBs are sent directly over IPX. The Locate Server Name Query and Browser Host Announcement direct hosting messages are sent using an IPX WAN Broadcast without the corresponding NetBIOS fields.


NetBIOS Over IPX Broadcast Packet Structure

The NetBIOS over IPX Broadcast header, shown in Figure 5.17, is a combination of the IPX WAN Broadcast header and a NetBIOS header, which is placed immediately after the IPX header. NetBIOS over IPX Broadcast packets have a Packet Type of 0x14, a Destination Node number of 0xFF-FF-FF-FF-FF-FF, and a Source and Destination Socket number of 0x455.

Figure 5.17 NetBIOS over IPX Broadcast Packet Structure

Network 1–Network 8 (IPX WAN Broadcast Header)

The first eight fields (Network 1 through Network 8) are the IPX WAN Broadcast header. The series of IPX networks on which the IPX WAN Broadcast packet has traveled is recorded by IPX routers as the packet is propagated through an IPX internetwork. To prevent loops, this network path information is analyzed upon receipt at a router and the packet is forwarded to all networks except those on which it has already been.

After eight networks, the IPX WAN Broadcast packet is silently discarded by the last router in the path. However, recall that the maximum hop count for any IPX packet on a RIP for IPX-based internetwork is 16. The difference in the maximum number of hops between an IPX WAN Broadcast and a normal IPX packet can cause confusion in large IPX internetworks.

For example, a NetWare server 10 hops away is reachable from a NetWare client because its IPX internetwork address is discovered by querying the SAP table or directory tree of its default NetWare server. Connection requests sent to the NetWare server are unicast traffic that reach the NetWare server because it is within 16 hops.

On the other hand, a Windows 2000 Server–based computer 10 hops away is not reachable for a Microsoft SMB–based client because its IPX internetwork address is discovered using a NetBIOS Name Query sent using a NetBIOS over IPX Broadcast packet that is discarded after 8 networks. Because there is no response to the Name Query, the IPX internetwork address of the Windows 2000 Server–based computer is not resolved and a connection cannot be established. To prevent this problem, design your IPX internetwork so that there are no more than 7 IPX routers between any two Windows 2000 computers.

Name Type Flags (NetBIOS Header)

The 1-byte Name Type Flags field of the NetBIOS header contains a series of flags to indicate the state of the NetBIOS name. The individual bits are defined in Table 5.5.

Table 5.5 Name Type Flag Bits

Name Type Bit | Description
1 | Group Name (1) or Unique Name (0)
2 | Name in Use (1) or Name Unused (0)
3, 4, 5 | Unused
6 | Name Registered (1) or Name Not Registered (0)
7 | Name Duplicated (1) or Name Not Duplicated (0)
8 | Name Deregistered (1) or Name Not Deregistered (0)

Bits are numbered from the high order bit (Bit 1) to the low order bit (Bit 8).

Data Stream Type 2 (NetBIOS Header)

The 1-byte Data Stream Type 2 field of the NetBIOS header indicates the type of NetBIOS packet. Table 5.6 lists the defined values for the Data Stream Type 2 field.

Table 5.6 Data Stream Type 2 Values

Data Stream Type 2 | Description
1 | Find Name
2 | Name Recognized
3 | Add Name

  • NetBIOS Name (NetBIOS Header)

    The 16-byte NetBIOS Name field of the NetBIOS header stores the NetBIOS name.


Static NetBIOS Names

When the Only for Statically Seeded Names NetBIOS broadcast delivery option is selected in the NetBIOS Broadcast Configuration dialog box, NetBIOS over IPX broadcasts are only propagated for a defined series of NetBIOS names and in a preferred direction. Static NetBIOS names can be used to confine NetBIOS over IPX broadcast traffic in environments where client-side NetBIOS applications need to access a small set of server-side NetBIOS applications.

For example, in a NetBIOS over IPX Lotus Notes environment, numerous Lotus Notes clients need to access a relatively small number of Lotus Notes servers and to resolve the IPX internetwork addresses of those servers. In this situation, the network administrator configures the routers to pass NetBIOS over IPX broadcasts for only those NetBIOS names that correspond with the names of the Lotus Notes servers.

To add statically configured NetBIOS names, in the Routing and Remote Access Manager console tree, click the plus sign (+) next to IPX Routing, right-click Static NetBIOS Names, and then click Add NetBIOS Name. Figure 5.18 shows the resulting Static NetBIOS Name dialog box.

Figure 5.18 Static NetBIOS Name Dialog Box


Remote Access Server

Microsoft® Windows® 2000 has extensive support for remote access technology to connect remote clients to corporate networks or the Internet. This chapter clarifies how remote access works and details how to troubleshoot remote access problems.

This chapter is intended for network engineers and support professionals who are already familiar with TCP/IP, IP routing, IPX routing, and wide area network technology. This chapter assumes that you have read the section about remote access in Windows 2000 Server Help.

In This Chapter

Remote Access Overview

Remote Access Server Architecture

The Point-to-Point Protocol

PPP Authentication Protocols

Remote Access and LAN Protocols

Remote Access Policies

Multilink and Bandwidth Allocation Protocol

Remote Access Server and IP Multicast Support

Troubleshooting the Remote Access Server

Related Chapters in the Resource Kit

  • For more information about TCP/IP routing, see “Introduction to TCP/IP” in Microsoft® Windows® 2000 TCP/IP Core Networking.
  • For more information about unicast IP routing, see “Unicast IP Routing” in this book.
  • For more information about IPX routing, see “IPX Routing” in this book.
  • For more information about demand-dial routing, see “Demand-Dial Routing” in this book.
  • For more information about virtual private networking, see “Virtual Private Networking” in this book.


Remote Access Overview

With Windows 2000 remote access, remote access clients connect to remote access servers and are transparently connected to the remote access server, known as point-to-point remote access connectivity, or transparently connected to the network to which the remote access server is attached, known as point-to-LAN remote access connectivity. This transparent connection allows remote access clients to dial-in from remote locations and access resources as if they were physically attached to the network.

The Windows 2000 remote access provides two different types of remote access connectivity:

  1. Dial-up remote access

    With dial-up remote access, a remote access client uses the telecommunications infrastructure to create a temporary physical circuit or a virtual circuit to a port on a remote access server. Once the physical or virtual circuit is created, the rest of the connection parameters can be negotiated.

  2. Virtual private network (VPN) remote access

    With virtual private network remote access, a VPN client uses an IP internetwork to create a virtual point-to-point connection with a remote access server acting as the VPN server. Once the virtual point-to-point connection is created, the rest of the connection parameters can be negotiated.

Note

This chapter is primarily devoted to the discussion of dial-up remote access; however, many topics also apply to VPN remote access. For a complete understanding of VPNs, read this chapter first and then read the chapter covering “Virtual Private Networking” in this book.

Remote Access Versus Remote Control

The distinctions between remote access and remote control solutions are the following:

  • The remote access server is a software-based multi-protocol router; remote control solutions work by sharing screen, keyboard, and mouse over the remote link. In remote access, the applications are run on the remote access client computer.
  • In a remote control solution, users share a CPU or multiple CPUs on the server. In remote control, the applications are run on the server. The remote access server’s CPU is dedicated to communications, not to running applications.


Elements of a Dial-Up Remote Access Connection

A dial-up remote access connection consists of a remote access client, a remote access server and a wide area network (WAN) infrastructure as illustrated in Figure 7.1.

Figure 7.1 Elements of a Dial-Up Remote Access Connection

Remote Access Client

Windows 2000, Microsoft® Windows NT® 3.5 and later, Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows® for Workgroups, MS-DOS®, and Microsoft® LAN Manager remote access clients can all connect to a Windows 2000 remote access server. Third-party Point-to-Point Protocol (PPP) remote access clients can also connect with a Windows 2000 remote access server.

Remote Access Server

The Windows 2000 remote access server accepts dial-up connections and forwards packets between remote access clients and the network to which the remote access server is attached.

Note

The term remote access server as it is used in this chapter refers to a Windows 2000 Server computer running the Routing and Remote Access Service and configured to provide remote access.

Dial-Up Equipment and WAN Infrastructure

The physical or logical connection between the remote access server and the remote access client is facilitated by dial-up equipment installed at the remote access client, the remote access server, and the telecommunications infrastructure. The nature of the dial-up equipment and telecommunications infrastructure varies depending on the type of connection being made.

PSTN

The Public Switched Telephone Network (PSTN), also known as Plain Old Telephone Service (POTS), is the analog phone system designed to carry the minimal frequencies to distinguish human voices. Because the PSTN was not designed for data transmissions, there are limits to the maximum bit rate of a PSTN connection. Dial-up equipment consists of an analog modem for the remote access client and the remote access server. For large organizations, the remote access server is attached to a modem bank containing up to hundreds of modems. With analog modems at both the remote access server and the remote access client, the maximum bit rate supported by PSTN connections is 33,600 bits per second, or 33.6 kilobits per second (Kbps).

Figure 7.2 illustrates a PSTN connection.

Figure 7.2 Dial-Up Equipment and WAN Infrastructure for PSTN Connections

Digital Links and V.90

The maximum bit rate of the PSTN is a function of the range of frequencies being passed by PSTN switches and the signal-to-noise ratio of the connection. The modern-day analog phone system is only analog on the local loop, the set of wires that connects the customer to the central office (CO) PSTN switch. Once the analog signal reaches the PSTN switch, it is converted to a digital signal. The analog-to-digital conversion introduces noise on the connection known as quantization noise.

When a remote access server is connected to a CO using a digital switch based on T-Carrier or IDSN rather than an analog PSTN switch, there is no analog-to-digital conversion when the remote access server sends information to the remote access client. There is no quantization noise in the downstream path to the remote access client, and therefore, there is a higher signal-to-noise ratio and a higher maximum bit rate.

With this new technology, called V.90, remote access clients can send data at 33.6 Kbps and receive data at 56 Kbps. In North America, the maximum receive bit rate is 53 Kbps due to Federal Communications Commission (FCC) power rules.

To obtain V.90 speeds, the following must be true:

  • The remote access client must call using a V.90 modem.
  • The remote access server must be using a V.90 digital switch and be connected to the PSTN using a digital link, such as T-Carrier or ISDN.
  • There cannot be any analog-to-digital conversions in the path from the remote access server to the remote access client.

Figure 7.3 illustrates a V.90-based PSTN connection.

Figure 7.3 Dial-Up Equipment and WAN Infrastructure for V.90 Connections

ISDN

The Integrated Services Digital Network (ISDN) is a set of international specifications for a digital replacement of the PSTN providing a single digital network to handle voice, data, fax, and other services over existing local loop wiring. ISDN offers multiple channels; each channel operates at 64 Kbps and because the network is digital end-to-end, there are no analog to digital conversions.

Dial-up equipment consists of an ISDN adapter for the remote access client and the remote access server. Remote access clients typically use Basic Rate ISDN (BRI) with two 64 Kbps channels, and large organizations typically use Primary Rate ISDN (PRI) with 23 64 Kbps channels.

Figure 7.4 illustrates an ISDN connection.

Figure 7.4 Dial-Up Equipment and WAN Infrastructure for ISDN Connections

X.25

X.25 is an international standard for sending data across public packet switching networks. Windows 2000 remote access supports X.25 in two ways:

  1. The remote access client supports the use of X.25 smart cards, which can connect directly to the X.25 data network and use the X.25 protocol to establish connections and send and receive data. The remote access client also supports dialing into a packet assembler/disassembler (PAD) of an X.25 carrier using an analog modem.
  2. The remote access server only supports the use of X.25 smart cards.

For more information about the configuration of X.25 and PADs, see Windows 2000 Help.

Note

X.25 smart cards are adapters that use the X.25 protocol and can directly connect to an X.25 public data network. X.25 smart cards are not related to smart cards used for authentication and secure communications.

Figure 7.5 illustrates a X.25 connection.

Figure 7.5 Dial-Up Equipment and WAN Infrastructure for X.25 Connections

ATM over ADSL

Asymmetric Digital Subscriber Line (ADSL) is a new local loop technology for small business and residential customers. Although ADSL provides higher bit rates than PSTN and ISDN connections, the bit rate is not the same in the upstream and downstream directions. Typical ADSL connections offer 64 Kbps from the customer and 1.544 megabits per second (Mbps) to the customer. The asymmetric nature of the connection fits well with typical Internet use. Most Internet users receive a lot more information than they send.

ADSL equipment can appear to Windows 2000 as either an Ethernet interface or a dial-up interface. When an ADSL adapter appears as an Ethernet interface, the ADSL connection operates in the same way as an Ethernet connection to the Internet.

When an ADSL adapter appears as dial-up interface, ADSL provides a physical connection and the individual LAN protocol packets are sent using Asynchronous Transfer Mode (ATM). An ATM adapter with an ADSL port is installed in both the remote access client and remote access server.

Figure 7.6 illustrates an ATM over ADSL connection.

Figure 7.6 Dial-Up Equipment and WAN Infrastructure for ATM over ADSL Connections

Remote Access Protocols

Remote access protocols control the connection establishment and transmission of data over wide area network (WAN) links. The operating system and LAN protocols used on remote access clients and servers dictate which remote access protocol your clients can use.

There are four types of remote access protocols supported by Windows 2000 remote access:

  1. Point-to-Point Protocol (PPP) is an industry-standard set of protocols providing the best security, multi-protocol support, and interoperability.
  2. Serial Line Internet Protocol (SLIP) is used by older remote access servers.
  3. The AppleTalk Remote Access Protocol (ARAP) is used by some Apple Macintosh dial-up clients.
  4. Microsoft remote access protocol, also known as Asynchronous NetBEUI or AsyBEUI, is a remote access protocol used by legacy remote access clients running Microsoft operating systems, such as Microsoft® Windows NT® 3.1, Windows for Workgroups, MS-DOS, and LAN Manager.

Table 7.1 summarizes the remote access protocols and their use in Windows 2000.

Table 7.1 Remote Access Protocols and Their Use in Windows 2000

 | Remote Access Client | Remote Access Server
PPP | x | x
SLIP | x |
ARAP |  | x
AsyBEUI | x | x

LAN Protocols

LAN protocols are the protocols used by the remote access client to access resources on the network connected to the remote access server. Windows 2000 remote access supports TCP/IP, IPX, AppleTalk, and NetBEUI. For more information, see “Remote Access and LAN Protocols” later in this chapter.


Elements of Secure Remote Access

Because remote access is designed to transparently connect a remote access client to a network and its potentially sensitive data, security of remote access connections is an important consideration. Windows 2000 remote access offers a wide range of security features including secure user authentication, mutual authentication, data encryption, callback, and caller ID.

Secure User Authentication

Secure user authentication is obtained through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the Extensible Authentication Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 1 and version 2, Challenge Handshake Authentication Protocol (CHAP), or Shiva Handshake Authentication Protocol (SPAP) authentication protocols. The remote access server can be configured to require a secure authentication method. If the remote access client cannot perform the required secure authentication, the connection is denied.

Mutual Authentication

Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the EAP-Transport Level Security (EAP-TLS) or MS-CHAP version 2 authentication protocols. During mutual authentication, the remote access client authenticates itself to the remote access server, and then the remote access server authenticates itself to the remote access client.

Data Encryption

Data encryption encrypts the data sent between the remote access client and the remote access server. Data encryption is possible over dial-up remote access links when using the PPP remote access protocol and the EAP-TLS or MS-CHAP authentication protocols. The remote access server can be configured to require data encryption. If the remote access client cannot perform the required encryption, the connection attempt is rejected.

Remote access data encryption only provides data encryption on the communications link between the remote access client and the remote access server. If end-to-end encryption is needed, use IPSec to create an encrypted end-to-end connection after the remote access connection has been made.

Windows 2000, Microsoft® Windows NT® 4.0, Windows 98, and Windows 95 remote access clients and remote access servers support the Microsoft Point-to-Point Encryption Protocol (MPPE). MPPE uses the RSA RC4 stream cipher and either 40-bit or 128-bit secret keys. MPPE keys are generated from the MS-CHAP and EAP-TLS user authentication process.

Callback

With callback, the remote access server calls the remote access client after the user credentials have been verified. Callback can be configured to call the remote access client back at a number specified by the user of the remote access client during the time of the call. This allows a traveling user to dial-in and have the remote access server call them back at their current location, saving phone charges. Callback can also be configured to always call the remote access client back at a specific location, which is the secure form of callback.

Caller-ID

Caller-ID can be used to verify that the incoming call is coming from a specified phone number. Caller-ID is configured as part of the dial-in properties of the user account. If the Caller-ID number of the incoming connection for that user does not match the configured Caller-ID, the connection is denied.

Caller-ID requires that the caller’s phone line, the phone system, the remote access server’s phone line, and the Window 2000 driver for the dial-up equipment all support Caller-ID. If a Caller-ID is configured for a user account and the Caller-ID is not being passed from the caller to the Routing and Remote Access Service, then the connection is denied.

Caller-ID is a feature designed to provide a higher degree of security for telecommuters. The disadvantage of configuring Caller-ID is that the user can only dial-in from a single phone line.


Managing Remote Access

Remote access has the following management issues:

  • Where is the user account data to be stored?
  • How are addresses assigned to VPN clients?
  • Who is allowed to create VPN connections?
  • How does the VPN server verify the identity of the user attempting the VPN connection?
  • How does the VPN server record the VPN activity?
  • How can the VPN server be managed using industry-standard network management protocols and infrastructure?

Managing Users

Because it is administratively unsupportable to have separate user accounts for the same user on separate servers and to try to keep them all simultaneously current, most administrators set up a master account database at the primary domain controller (PDC) or on a Remote Authentication Dial-in User Service (RADIUS) server. This allows the remote access server to send the authentication credentials to a central authenticating device.

Managing Addresses

For PPP connections, IP, IPX, and AppleTalk addressing information must be allocated to remote access clients during the connection establishment process. The Windows 2000 remote access server must be configured to allocate IP addresses, IPX network and node addresses, and AppleTalk network and node addresses.

More information on address allocation for IP and IPX can be found later in this chapter.

Managing Access

Managing access for remote access connections for Windows 2000 is done through the configuration of the dial-in properties on user accounts and remote access policies.

Access by User Account

If you wish to manage remote access on an individual per-user basis, set the remote access permission on those user accounts that are allowed to create remote access connections to Allow access and modify the profile properties of the default remote access policy called Allow access if dial-in permission is enabled for the needed connection parameters.

If the remote access server is only providing dial-up remote access connections and no VPN connections, then delete the default remote access policy called Allow access if dial-in permission is enabled and create a new remote access policy with a descriptive name, such as Dial-up remote access if dial-in permission is enabled.

As an example of typical settings to allow dial-up remote access connections, configure the remote access policy permission to Deny remote access permission and set the conditions and profile settings as listed in Tables 7.2 and 7.3. For detailed information about configuring these settings, see Windows 2000 Server Help.

Table 7.2 Remote Access Policy Conditions for Dial-Up Access by User Account

Conditions | Setting
NAS-Port-Type | Select all except Virtual.

Table 7.3 Remote Access Policy Profile Settings for Dial-Up Access by User Account

Profile Tab | Setting
Authentication tab | Enable Extensible Authentication Protocol. Select Smartcard or other certificate (TLS). Enable Microsoft Encrypted Authentication (MS-CHAP).

Access by Policy

If you wish to manage remote access by remote access policy, set the remote access permission on all user accounts to Control access through remote access policy if the remote access server computer is a stand-alone server or a member of a Windows 2000 native domain. If the remote access server computer is a member of a Windows NT 4.0 domain or a Windows 2000 mixed domain, set the remote access permission on all user accounts to Allow access.

A typical use of policy-based access is to allow access through group membership. For example, create a Windows 2000 group with a name, such as DialUpUsers, whose members are those users who are allowed to create dial-up remote access connections.

If the remote access server is only allowing dial-up remote access connections, delete the default remote access policy called Allow access if dial-in permission is enabled and then create a new remote access policy with a descriptive name, such as Dial-up remote access if member of DialUpUsers group.

As an example of typical settings to allow dial-up remote access for only members of a specific group, configure the remote access policy permission to Grant remote access permission and set the conditions and profile settings as listed in Tables 7.4 and 7.5. For detailed information about configuring these settings, see Windows 2000 Server Help.

Table 7.4 Remote Access Policy Conditions for Dial-Up Access by User Account

Conditions | Setting
NAS-Port-Type | Select all except Virtual.
Windows 2000-Groups | DialUpUsers (example)

Table 7.5 Remote Access Policy Profile Settings for Dial-Up Access by User Account

Profile Tab | Setting
Authentication tab | Enable Extensible Authentication Protocol. Select Smartcard or other certificate (TLS). Enable Microsoft Encrypted Authentication (MS-CHAP).

Managing Authentication

The remote access server can be configured to use either Windows 2000 or RADIUS as an authentication provider.

Windows 2000 Authentication

If Windows 2000 is selected as the authentication provider, then the user credentials sent by users attempting remote access connections are authenticated using normal Windows 2000 authentication mechanisms.

If the remote access server is a member server in mixed or native Windows 2000 domain and is configured for Windows 2000 authentication, the computer account of the remote access server computer must be a member of the remote access and IAS Servers security group. The computer account is automatically added to the remote access and IAS Servers security group during the installation of the Routing and Remote Access Service.

RADIUS Authentication

If RADIUS is selected and configured as the authentication provider on the remote access server, then user credentials and parameters of the connection request are sent as a series of RADIUS request messages to a RADIUS server.

The RADIUS server receives a user-connection request from the remote access server and authenticates the client against its authentication database. A RADIUS server can also maintain a central storage database of other relevant user properties. In addition to the simple yes or no response to an authentication request, RADIUS can inform the remote access server of other applicable connection parameters for this user—such as maximum session time, static IP address assignment, and so on.

RADIUS can respond to authentication requests based upon its own database, or it can be a front end to another database server such as a generic Open Database Connectivity (ODBC) server or a Windows 2000 PDC. The latter server could be located on the same machine as the RADIUS server, or could be centralized elsewhere. In addition, a RADIUS server can act as a proxy client to a remote RADIUS server.

The RADIUS protocol is described in RFCs 2138 and 2139. For more information on remote access server authentication scenarios and the remote access server as a RADIUS client, see Windows 2000 Help. For more information on the Windows 2000 Internet Authentication Service, a RADIUS server, see “Internet Authentication Services” in this book.

Note

Internet Authentication Services do not support EAP-TLS authentication and password changes using the MS-CHAP authentication protocol.

Managing Accounting

The remote access server can be configured to use either Windows 2000 or RADIUS as an accounting provider. If Windows 2000 is selected as the accounting provider, then the accounting information is accumulated in a log file on the remote access server. If RADIUS is selected as the accounting provider, RADIUS accounting messages are sent to the RADIUS server for accumulation and later analysis.

Most RADIUS servers can be configured to place authentication request records into an accounting file. There are also a set of messages (from the remote access server to the RADIUS server) that request accounting records at the start of a call, the end of a call, and at predetermined intervals during a call. A number of third parties have written billing and audit packages that read these RADIUS accounting records and produce various useful reports.

Network Management

The computer acting as the remote access server can participate in a Simple Network Management Protocol (SNMP) environment as an SNMP agent by installing the Windows 2000 SNMP Service. The remote access server records management information in various object identifiers of the Internet Management Information Base (MIB) II that is installed with the Windows 2000 SNMP service. Objects in the Internet MIB II are documented in RFC 1213.


Remote Access Server Architecture

The architecture of the remote access server consists of the following elements, as illustrated in Figure 7.7.

  • The NDIS wrapper, Ndis.sys, providing the NDIS packet-level interface to protocols, such as TCP/IP, IPX, NetBEUI, and AppleTalk.
  • The NDISWAN driver, Ndiswan.sys, an intermediate NDIS driver that provides an IEEE 802.3 miniport interface to protocol drivers and a protocol interface to WAN miniport drivers. NDISWAN provides framing, compression, and encryption services for remote access connections.
  • WAN miniport drivers are NDIS miniport drivers that contain the necessary code to operate the dial-up equipment. In order to use an adapter supporting WAN media, such as ISDN or ATM with Windows 2000 remote access, the adapter vendor must create a WAN miniport driver.
  • Remote access components are a series of libraries that provide the Remote Access Service (remote access) programming interface for applications, PPP protocols (link control, authentication, and network control protocols), support for other remote access protocols, such as ARAP, and so on. Remote access components can communicate directly with the NDISWAN driver or by accessing the Telephone API (TAPI).
  • TAPI components are a series of libraries that provide a call control programming interface for all TAPI-aware applications. TAPI components communicate directly with the NDISWAN driver to manage connections. For more information about TAPI in Windows 2000, see “Telephony Integration” in this book.

Figure 7.7 Remote Access Architecture in Windows 2000

Connections are established by remote access clients that call the remote access programming interface, which in turn uses TAPI to pass call connection information to the dial-up equipment. Once the physical connection is made, TAPI is no longer used and additional remote access components negotiate the connection with link, authentication, and network control protocols by communicating directly with NDISWAN.

Once a remote access connection is established, protocol drivers can communicate over that connection using standard NDIS calls like NdisSend(). NdisSend() calls for dial-up connections are forwarded to NDISWAN, which then determines the appropriate device and port, performs compression and encryption, provides PPP framing, and then forwards the completed frame to the WAN miniport driver. The WAN miniport driver then forwards the frame to the dial-up adapter.

All inbound remote access client connections, initiated by remote access clients to the remote access server, are represented as a single adapter called the remote access server interface. For each outbound remote access client connection, initiated by the remote access server, a separate interface is created.

To accept calls, the remote access server instructs each WAN miniport driver to indicate when it goes into a line-up state. When the call is placed, the WAN miniport driver passes the line-up state indicator up through NDISWAN to the TAPI components. TAPI returns a call handle to NDISWAN to be used to refer to the physical connection, and then NDISWAN and the remote access components negotiate the rest of the remote access connection.


IP, IPX, and AppleTalk Router

Once the remote access connection is established, the remote access client can begin sending LAN protocol traffic to the remote access server or to locations beyond the remote access server. When the remote access client sends LAN protocol traffic that is not destined for the remote access server, the remote access server must forward the LAN traffic to its appropriate destination. To accomplish this, the remote access server must have forwarding capabilities enabled on its routable protocols and act as an IP, IPX, and AppleTalk router.

When the Routing and Remote Access Service is installed and enabled to provide point-to-LAN remote access connectivity, it enables forwarding between the installed LAN adapters and the remote access server interface.

Figure 7.8 illustrates the remote access server architecture as it appears when routing packets. (In an effort to simplify the illustration, only IP routing is shown.) However, IPX and AppleTalk routing work in the same fashion.

Figure 7.8 IP Routing on the Remote Access Server

Packets from Remote Access Clients

The following process describes how IP packets sent by the remote access client are forwarded by the remote access server.

  1. Depending on the dial-up technology, either the entire PPP frame is received by the WAN hardware and passed up as a single frame to the appropriate WAN miniport driver or individual bits of the PPP frame are passed up to the appropriate WAN miniport driver.
  2. The WAN miniport driver passes the PPP frame to Ndiswan.sys.
  3. Ndiswan.sys verifies the PPP checksum and uses the PPP protocol ID to determine that it is an IP datagram. For more information on PPP, see “Point-to-Point Protocol” later in this chapter.
  4. The IP datagram is passed to the TCP/IP protocol driver.
  5. The TCP/IP protocol driver, which is enabled for IP forwarding, determines a forwarding interface and an IP address based on the destination IP address in the IP datagram and the contents of its routing table.
  6. To forward the IP datagram using the LAN adapter, the TCP/IP protocol calls NDIS with an NdisSend(), along with instructions to send it using the LAN adapter.
  7. NDIS forwards the IP datagram to the appropriate LAN miniport driver.
  8. The LAN miniport forwards the IP datagram to the LAN adapter through NDIS.

The end result is that packets from the remote access client are forwarded using the same IP routing process used for all IP routing. The success of the IP forwarding process depends on whether the remote access server can find a suitable entry in the IP routing table. Therefore, either the remote access server is configured with a default gateway, or the remote access server has specific routes to all the locations on the intranet to which the remote access server is attached. Specific routes can be added through static routes, or by enabling a routing protocol on the remote access server.

Packets to Remote Access Clients

The following process describes how IP packets sent by intranet hosts to the remote access client are forwarded by the remote access server.

  1. The LAN adapter passes a frame to its appropriate LAN miniport driver through NDIS. The details of how an IP datagram is forwarded to the MAC address of the remote access server can be found in “TCP/IP On-Subnet and Off-Subnet Addressing.”
  2. The LAN miniport driver passes the IP datagram to the TCP/IP protocol driver through NDIS.
  3. The TCP/IP protocol driver, which is enabled for IP forwarding, determines a forwarding interface and IP address based on the destination IP address in the IP datagram and the contents of its routing table. When the remote access client connects, a host route is created in the IP routing table for the IP address allocated to the remote access client that points to the remote access server interface.
  4. To forward the IP datagram using the WAN adapter, the TCP/IP protocol calls NDIS with an NdisSend() with instructions to send it using NDISWAN and a specific connection handle.
  5. NDISWAN resolves the connection handle to a specific device and port, adds a PPP header and trailer, and forwards the IP datagram to the appropriate WAN miniport driver through NDIS.
  6. The WAN miniport forwards the IP datagram to the WAN adapter through NDIS.

The end result is that packets from intranet hosts are forwarded using the same IP routing process used for all IP routing. The success of the IP forwarding process depends on whether the IP addresses of remote access clients are reachable from the hosts on intranet.


TCP/IP On-Subnet and Off-Subnet Addressing

The exact mechanism of how an IP node on a subnet to which the remote access server is attached resolves the MAC address of the LAN interface of the remote access server depends on whether the remote access server is configured for on-subnet or off-subnet addressing:

  • On-subnet addressing is the allocation of IP addresses to remote access clients that are in a range defined by a subnet to which the remote access server is attached. On-subnet addressing uses a subset of addresses of an attached subnet.
  • Off-subnet addressing is the allocation of IP addresses to remote access clients that are not in a range defined by a subnet to which the remote access server is attached. Off-subnet addressing uses a separate subnet address space that is unique to the intranet.

On-Subnet Addressing and Proxy ARP

With on-subnet addressing, remote access clients are logically on the same subnet as a subnet attached to the remote access server. Proxy ARP is used by the remote access server to receive IP datagrams being forwarded to remote access clients.

There are two cases where Proxy ARP is used:

  1. When the remote access server is configured to use DHCP to obtain addresses for IP-based remote access clients
  2. When the remote access server is configured with a static IP address pool that is a subset of addresses for a subnet to which the remote access server is attached.

In either case, the remote access clients are logically on the same subnet as the remote access server. Therefore, IP nodes on that subnet forwarding IP datagrams to a remote access client perform a direct delivery by sending a broadcast Address Resolution Protocol (ARP) Request frame for the remote access client’s IP address.

The remote access client cannot respond to the ARP Request because the remote access server does not forward the ARP Request frame to the remote access client, and the remote access client does not have a Media Access Control (MAC) address corresponding to the remote access connection.

Therefore, the remote access server responds with an ARP Reply frame with its own MAC address. The node forwarding the packet then sends the IP datagram to the remote access server’s MAC address. The remote access server then uses the IP routing process to forward the IP datagram across the dial-up connection to the remote access client.

Off-Subnet Addressing and IP Routing

With off-subnet addressing, remote access clients are logically on a separate subnet reachable across the remote access server. In this case, Proxy ARP is not used. The remote access server is acting as a router between the subnet of the remote access clients and the subnet(s) to which the remote access server is attached. IP nodes on the LAN-based subnet(s) attached to the remote access server forwarding IP datagrams to a remote access client perform an indirect delivery by sending a broadcast Address Resolution Protocol (ARP) Request frame for the remote access server’s IP address.

In order for the remote access clients to be reachable from IP nodes on the intranet, a route representing the IP address pool and pointing to the LAN interface of the remote access server must be present in intranet routers.

When the first TCP/IP-based remote access client connects, a route corresponding to the off-subnet address pool pointing to the remote access server interface is added to the IP routing table of the remote access server. If the remote access server is configured with an IP routing protocol, the new route is advertised to neighboring routers using the normal advertising process of the configured routing protocol. If the remote access server is not configured with an IP routing protocol, a static route corresponding to the off-subnet address pool pointing to the remote access server’s LAN interface must be added to the routers of the intranet.


NetBIOS Gateway

Windows 2000 includes the NetBIOS gateway for remote access clients that use either the NetBEUI protocol with the PPP remote access protocol or the AsyBEUI remote access protocol. With the NetBIOS gateway, a remote access client using NetBEUI can access any NetBIOS-based network resource that is reachable from the remote access server.

With the NetBIOS gateway, the remote access client can access any of the following resources:

  • Network resources available from the remote access server using NetBEUI.
  • Network resources available from the remote access server using NetBIOS over TCP/IP.
  • Network resources available from the remote access server using NetBIOS over IPX.

The NetBIOS gateway component is responsible for:

  • NetBIOS Name Management

    When the initial connection is made, the remote access client passes its NetBIOS name and it is added to the NetBIOS name table at the remote access server.

  • Passing NetBIOS packets from the remote access client to the LAN.

    When the remote access client sends NetBEUI packets across the phone line, those packets are submitted to the NetBIOS gateway and sent over the NetBIOS providing protocol(s).

  • Passing NetBIOS packets from the LAN to the remote access client.

    NetBIOS packets from the LAN, from any of the NetBIOS providing protocols, are inspected for the NetBIOS computer name of the remote access client and sent back to the remote access client using NetBEUI.

Note

The NetBIOS gateway cannot be used to access non-NetBIOS resources, such as Web servers, FTP servers, and other types of Windows Sockets–based resources.

Figure 7.9 illustrates the NetBIOS gateway architecture of the remote access server.

Figure 7.9 The NetBIOS Gateway


The Point-to-Point Protocol

The Point-to-Point Protocol (PPP) is an industry standard method of utilizing point-to-point links to transport multi-protocol datagrams. PPP is documented in RFC 1661.

PPP performs the following functions:

  • Provides multi-protocol data link layer encapsulation

    PPP creates frames that contain separate IP datagrams, IPX datagrams, or NetBEUI frames.

  • Establishes, maintains, and ends the logical link

    The PPP protocol uses the Link Control Protocol (LCP) to establish and configure the parameters of the data-link connection. Part of the LCP negotiation authenticating the credentials of the remote access client.

  • Provides protocol configuration

    After the data-link connection has been negotiated, network layer protocols such as IP, IPX, and AppleTalk are configured. For example, for TCP/IP, an IP address is allocated to the remote access client by the remote access server. Compression and encryption are also negotiated.


PPP Encapsulation

PPP encapsulation uses a variant of the ISO High Level Data Link Control (HDLC) protocol to encapsulate multi-protocol datagrams as the payload of PPP frames. The PPP header and trailer is shown in Figure 7.10 and contains the following fields:

  • Flag - Set to 0x7E (bit sequence 011111110) to signify the start and end of a PPP frame. In successive PPP frames only a single Flag character is used.
  • Address - In HDLC environments, the Address field is used to address the frame to the destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, the broadcast address. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Address field is not included.
  • Control - In HDLC environments, the Control field is used for data link layer sequencing and acknowledgments. PPP does not provided link-to-link reliable data transfer. Therefore, for all PPP frames, the Control field is set to 0x03 to indicate an unnumbered information (UI) frame. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Control field is not included.
  • Protocol ID - The two byte Protocol ID field identifies the protocol of the PPP payload. If both PPP peers agree to perform protocol field compression during LCP negotiation, the Protocol ID field is one byte for Protocol IDs in the range 0x00-00 to 0x00-FF.
  • Frame Check Sequence (FCS) - A 16-bit checksum that is used to check for bit level errors in the PPP frame. If the receiver’s calculation of the FCS does not match the FCS in the PPP frame, the PPP frame is silently discarded.

The maximum size of a PPP frame, known as the maximum receive unit (MRU), is determined during the negotiation of the logical link. The default MRU is 1,500 bytes. If negotiated lower, a PPP host must still have the ability to receive 1,500-byte frames in the event of link synchronization failure.

Figure 7.10 PPP Encapsulation

Typical values for the PPP protocol ID are listed in Table 7.6.

Table 7.6 PPP Protocol IDs

Protocol | Protocol ID/Compressed Value
Internet Protocol (IP) | 0x00-21 / 0x21
AppleTalk | 0x00-29 / 0x29
IPX | 0x00-2B / 0x2B
Van Jacobsen Compressed TCP/IP | 0x00-2D / 0x2D
Multilink | 0x00-3D / 0x3D
NetBEUI | 0x00-3F / 0x3F
Microsoft Point-to-Point Compression Protocol (MPPC) | 0x00-FD / 0xFD
Microsoft Point-to-Point Encryption Protocol (MPPE) | 0x00-FD / 0xFD

If MPPE or MPPC are negotiated, then the PPP protocol ID is set to 0x00-FD. With MPPE and MPPC both using the same PPP Protocol ID, each peer must know that the resulting PPP payload either is encrypted or compressed, or both.

  • If just MPPC is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is compressed.
  • If only MPPE is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is encrypted.
  • If both MPPC and MPPE are negotiated, then compression always occurs before encryption. The compressed PPP frame, consisting of the PPP protocol ID field set to 0xFD and the compressed data, is then encrypted and encapsulated with another PPP header consisting of the protocol ID field set to 0xFD and 2-byte MPPE header.

Preventing the Occurrence of the Flag Character

The use of the Flag character introduces a problem. What if the Flag character (0x7E) appears elsewhere in the PPP frame besides the beginning or end of the PPP frame? PPP employs two different methods to prevent the occurrence of the Flag character depending on whether PPP is being used on an asynchronous link or a synchronous link.

PPP on Asynchronous Links

On asynchronous links, such as analog phone lines, PPP uses a technique called character stuffing to prevent the occurrence of the Flag character within the PPP frame. If the Flag character (0x7E) occurs elsewhere in the PPP frame, the sender replaces it with the sequence 0x7D-5E. The 0x7D character is known as the PPP Escape character. If the PPP Escape character occurs, the sender replaces it with the sequence 0x7D-5D. The receiver translates 0x7D-5E sequences back to 0x7E and 0x7D-5D sequences back to 0x7D.

Additionally, character values less than 0x20 can be modified to prevent the serial drivers from interpreting them as control characters. If negotiated by LCP, characters below 0x20 are modified by sending the sequence: 0x7D-[Original character with the 6th bit complemented]. For example, the byte 0x01 would be transmitted as 0x7D-0x21.

PPP on Synchronous Links

With synchronous links, such as T-Carrier, ISDN, or other digital links, a technique called bit stuffing is used to prevent the occurrence of the FLAG character within the PPP frame. Recall that the Flag character is the bit sequence 01111110. Bit stuffing ensures that six 1 bits in a row occur only when the Flag character is sent. To accomplish this, bit stuffing sends the Flag character unmodified and elsewhere inserts a 0 bit whenever a sequence of five 1 bits occurs. Therefore, the bit sequence 111111 is encoded on the medium as 1111101 and the bit sequence 111110 is encoded as 1111100 (the stuffed bits are underlined). Bit stuffing means that a byte can be encoded on the medium as more than 8 bits, but the stuffed bits are added and removed by the synchronous link hardware.


PPP Link Negotiation with LCP

The PPP Link Control Protocol (LCP) is documented in RFC 1661. LPC negotiates link and PPP parameters to dynamically configure the data link layer of a PPP connection. Common LCP options include the PPP MRU, the authentication protocol, compression of PPP header fields, callback, and Multilink options.

LCP Packet Structure

LCP uses the PPP Protocol ID of 0xC0-21. The packet structure of LCP is illustrated in Figure 7.11. Each LCP packet is a single LCP message consisting of an LCP Code field identifying the type of LCP packet, an Identification field so that requests and replies can be matched, a Length field indicating the size of the LCP packet and LCP packet type–specific data.

Figure 7.11 LCP Packet Structure

Table 7.7 lists the LCP packet types documented in RFC 1661.

Table 7.7 LCP Packet Types

LCP Code | LCP Packet Type | Description
1 | Configure-Request | Sent to open or reset a PPP connection. The Configure-Request contains a list of LCP options with changes to default option values.
2 | Configure-Ack | Sent when all of the values of all of the LCP options in the last Configure-Request received are recognized and acceptable. When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete.
3 | Configure-Nack | Sent when all the LCP options are recognized, but the values of some options are not acceptable. The Configure-Nack includes the offending options and their acceptable values.
4 | Configure-Reject | Sent when LCP options are not recognized or not acceptable for negotiation. The Configure-Reject includes the unrecognized or non-negotiable options.
5 | Terminate-Request | Optionally sent to close the PPP connection.
6 | Terminate-Ack | Sent in response to the Terminate-Request.
7 | Code-Reject | Sent when the LCP code is unknown. The Code-Reject message includes the offending LCP packet.
8 | Protocol-Reject | Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the offending LCP packet. A Protocol-Reject is typically sent by a PPP peer in response to a PPP NCP for a LAN protocol not enabled on the PPP peer.
9 | Echo-Request | Optionally sent to test the PPP connection.
10 | Echo-Reply | Sent in response to an Echo-Request. The PPP Echo-Request and Echo-Reply are not related to the ICMP Echo Request and Echo Reply messages.
11 | Discard-Request | Optionally sent to exercise the link in the outbound direction.

LCP Options

When using the Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject LCP packet types, the LCP data portion of the LCP packet consists of one or more LCP options as illustrated in Figure 7.12. Each LCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option and the data associated with the option.

Figure 7.12 LCP Options

Table 7.8 lists common LCP options negotiated by Microsoft PPP peers. For information about other LCP options, see RFC 1661.

Table 7.8 LCP Options

Option Name | Option Type | Option Length | Description
Maximum Receive Unit | 1 | 4 | The maximum size (up to 65,535) of the PPP frame. The default MRU is 1500. If neither peer is changing the default, this option is not negotiated.
Asynchronous Control Character Map (ACCM) | 2 | 6 | A bit map that enables (bit set to 1) or disables (bit set to 0) the use of character escapes for asynchronous links for the 32 ASCII control characters from 0x00 to 0x20. By default, character escapes are used. The ACCM bit map is set to 0x00-00-00-00 for links with XON/XOFF software flow control.
Authentication Protocol | 3 | 5 or 6 | Indicates the authentication protocol used during the authentication phase of the connection. Values for this field for Microsoft PPP peers are 0xC2-27 for EAP, 0xC2-23-80 for MS-CHAP version 1, 0xC2-23-81 for MS-CHAP version 2, 0xC2-23-05 for MD5-CHAP, 0xC0-27 for SPAP, and 0xC0-23 for PAP.
Magic Number | 5 | 6 | A random number chosen to distinguish a peer and detect looped back lines.
Protocol Compression | 7 | 2 | A flag indicating that the PPP protocol ID be compressed to a single octet when the two-byte protocol ID is in the range 0x00-00 to 0x00-FF.
Address and Control Field Compression | 8 | 2 | A flag indicating that the PPP Address field (always set to 0xFF) and the PPP Control field (always set to 0x03) be removed from the PPP header.
Callback | 13 or 0x0D | 3 | A 1-octet indicator of how callback is to be determined. For remote access clients and server running Microsoft® Windows 32-bit operating systems, the callback option octet is set to 0x06, indicating that the callback is determined during Callback Control Protocol (CBCP) negotiation.

LCP Negotiation Process

The LCP negotiation is a series of LCP packets exchanged between PPP peers to negotiate a set of options and option values when sending data. The LCP negotiation is actually two separate dialogs between two PPP peers (Peer1 and Peer 2):

  1. Peer 1 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to Peer 2. This dialog starts with Peer 1 sending a Configure-Request and ends when Peer 2 sends a Configure-Ack.
  2. Peer 2 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to peer 1. This dialog starts with Peer 2 sending a Configure-Request and ends when Peer 1 sends a Configure-Ack.

Peer 1 and Peer 2 do not have to use the same set of LCP options.

When a PPP peer sends its initial Configure-Request, the response is any of the following:

  • A Configure-Nack because one or more options have unacceptable values.
  • A Configure-Reject because one or more of the options are unknown or not negotiable.
  • A Configure-Ack because all of the options have acceptable values.

When a PPP peer receives a Configure-Nack or Configure-Reject in response to its Configure-Request, it sends a new Configure-Request with modified options or option values. When a Configure-Ack is received, the PPP peer is ready to send data.

Figure 7.13 shows a hypothetical LCP negotiation process for Peer 1 using the fictional options W, X, Y, Z.

Figure 7.13 Sample LCP Negotiation

From the LCP messages in Figure 7.13:

  1. Peer 1 sends a Configure-Request requesting option W, option X set to 100, option Y set to 0, and option Z. Options W and Z are flag options.
  2. Peer 2 does not understand option Z so it sends a Configure-Reject containing option Z.
  3. Peer 1 sends a new Configure-Request packet requesting option W, option X set to 100, and option Y set to 0.
  4. Peer 2 prefers that option X be set to 200 so it sends a Configure-Nack containing option X and its preferred value.
  5. Peer 1 sends a new Configure-Request packet requesting option W, option X set to 200, and option Y set to 0.
  6. Peer 2 sends a Configure-Ack.

Each time Peer 1 sends a new Configure-Request, it changes the Identifier value in the LCP header so that Configure-Requests can be matched with their responses.

The previous process only configures how Peer 1 sends data to Peer 2. A separate LCP negotiation must be done so that Peer 2 can be configured to send data to Peer 1. Very often, the LCP packets for the two dialogs are intermixed during the connection process. Peer 1 is configuring the way it sends data at the same time as Peer 2.


Callback Negotiation with the Callback Control Protocol

The Callback Control Protocol (CBCP) is documented in ftp://ftp.microsoft.com/developr/rfc/cbcp.txt. CBCP negotiates the use of callback where the remote access server, after authenticating the remote access client, terminates the physical connection, waits a specified amount of time, and then calls the remote access client back at either a static or dynamically configured phone number. Common CBCP options include the phone number being used by the remote access server to call the remote access client back.

Packet Structure

CBCP uses the PPP Protocol ID of 0xC0-29. The packet structure of CBCP is exactly the same for LCP; however, only the Callback-Request (type 1), Callback-Response (type 2), and Callback-Ack (type 3) types are used. For all CBCP packet types, the CBCP data portion of the CBCP packet consists of one or more CBCP options. Each CBCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7.9 lists the CBCP options negotiated by Microsoft PPP peers.

Table 7.9 CBCP Options

Option Name | Option Type | Option Length | Description
No callback | 1 | 2 | Specifies that no callback is used for the connection.
Callback to a user-specified number | 2 | variable | The user of the remote access client computer determines the callback number.
Callback to an administrator-defined number | 3 | variable | Settings on the remote access server determine the callback number.
Callback to any of a list of numbers | 4 | variable | The remote access server callbacks to one of a list of phone numbers.


PPP Network Layer Negotiation with NCP

Once the link and PPP parameters have been negotiated with LCP, the PPP peers then use a series of Network Control Protocols (NCPs) to negotiate the parameters of individual LAN protocols. Microsoft PPP supports the following NCPs:

  • Internet Protocol Control Protocol (IPCP) to negotiate the use of IP.
  • Internetwork Packet Exchange Control Protocol (IPXCP) to negotiate the use of IPX.
  • AppleTalk Control Protocol (ATCP) to negotiate the use of AppleTalk.
  • NetBIOS Frames Control Protocol (NBFCP) to negotiate the use of NetBEUI.

IPCP

Internet Protocol Control Protocol (IPCP) as used by Microsoft PPP peers is documented in RFC 1332 and 1877. IPCP negotiates IP-based parameters to dynamically configure a TCP/IP-based PPP peer across a point-to-point link. Common IPCP options include an IP address and the IP address(es) of DNS and NetBIOS name servers.

Packet Structure

IPCP uses the PPP Protocol ID of 0x80-21. The packet structure of IPCP is exactly the same for LCP, except only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject IPCP packet types, the IPCP data portion of the IPCP packet consists of one or more IPCP options. Each IPCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7.10 lists the IPCP options negotiated by Microsoft PPP peers.

Table 7.10 IPCP Options

Option Name | Option Type | Option Length | Description
IP Compression Protocol | 2 | 4 | Van Jacobsen TCP compression protocol.
IP Address | 3 | 6 | The IP address to be allocated to the remote access client
Primary DNS server Address | 129 or 0x81 | 6 | The primary DNS server for the remote access client.
Primary NBNS Server Address | 130 or 0x82 | 6 | The primary WINS server for the remote access client.
Secondary DNS server Address | 131 or 0x83 | 6 | The secondary DNS server for the remote access client.
Secondary NBNS Server Address | 132 or 0x84 | 6 | The secondary WINS server for the remote access client.

Notice that there are no IPCP options for these common TCP/IP configuration items:

  • Subnet mask

    The subnet mask is assumed by the remote access client to be the class-based subnet mask of the IP address that is allocated to the remote access client.

  • Default gateway

    The default gateway IP address is not allocated by the remote access server. However, a default route is created on the remote access client, which points to the remote access connection. If a default route already exists in the routing table, then the metric of the existing default route is increased and a new default route is added with a lower metric. This is the default behavior for remote access clients running Windows 32-bit operating systems and can be modified by disabling the Use Default Gateway on Remote Network setting on the TCP/IP properties of a remote access client’s phonebook entry or dial-up connection object.

  • DNS domain name

    The DNS domain name configured from the TCP/IP protocol properties is not allocated during IPCP.

  • NetBIOS Node Type

    If the IP addresses of primary or secondary NetBIOS name servers are negotiated, then the hybrid NetBIOS node type (H-node) is assumed.

IPXCP

Internetwork Packet Exchange Control Protocol (IPXCP) as used by Microsoft PPP peers is documented in RFC 1552. IPXCP negotiates IPX-based parameters to dynamically configure a IPX-based PPP peer across a point-to-point link. Common IPXCP options include IPX network and node addresses.

Packet Structure

IPXCP uses the PPP Protocol ID of 0x80-2B. The packet structure of IPXCP is exactly the same for LCP, except only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject IPXCP packet types, the IPXCP data portion of the IPXCP packet consists of one or more IPXCP options. Each IPXCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7.11 lists the IPXCP options negotiated by Microsoft PPP peers.

Table 7.11 IPXCP Options

Option Name | Option Type | Option Length | Description
IPX Network Number | 1 | 6 | The IPX network number for the remote access client.
IPX Node Number | 2 | 6 | The IPX node number for the remote access client.

ATCP

AppleTalk Control Protocol (ATCP) as used by Microsoft PPP peers is documented in RFC 1378. ATCP negotiates AppleTalk-based parameters to dynamically configure an AppleTalk-based PPP peer across a point-to-point link. Common ATCP options include an AppleTalk address and server information.

Packet Structure

ATCP uses the PPP Protocol ID of 0x80-29. The packet structure of ATCP is exactly the same as LCP, except that only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject ATCP packet types, the ATCP data portion of the ATCP packet consists of one or more ATCP options. Each ATCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7.12 lists the ATCP options negotiated by Microsoft PPP peers.

Table 7.12 ATCP Options

Option Name | Option Type | Option Length | Description
AppleTalk Address | 1 | 6 | Negotiates the AppleTalk network and node number.
Server Information | 3 | 16 | Used to convey information about the remote access server.

NBFCP

NetBIOS Frames Control Protocol (NBFCP) as used by Microsoft PPP peers is documented in RFC 2097. NBFCP negotiates NetBEUI-based parameters to dynamically configure an NetBEUI-based PPP peer across a point-to-point link. Common NBFCP options include multicast filtering options and peer information.

Packet Structure

NBFCP uses the PPP Protocol ID of 0x80-3F. The packet structure of NBFCP is exactly the same for LCP, except that only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject NBFCP packet types, the NBFCP data portion of the NBFCP packet consists of one or more NBFCP options. Each NBFCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7.13 lists the NBFCP options negotiated by Microsoft PPP peers.

Table 7.13 NBFCP Options

Option Name | Option Type | Option Length | Description
Multicast filtering | 3 | 5 | Negotiates the handling of multicast packets.
Peer information | 2 | 17 | Used to convey NetBIOS configuration information.

Compression Control Protocol

Compression Control Protocol (CCP) is documented in RFC 1962. CCP negotiates parameters to dynamically configure, enable, and disable data compression algorithms between PPP peers across a point-to-point link. Common CCP options include an organization identifier and the use of MPPC.

Packet Structure

CCP uses the PPP Protocol ID of 0x80-FD. The packet structure of CCP is exactly the same for LCP, except only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject CCP packet types, the CCP data portion of the CCP packet consists of one or more CCP options. Each CCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7.14 lists the CCP options negotiated by Microsoft PPP peers.

Table 7.14 CCP Options

Option Name | Option Type | Option Length | Description
Organization Unique Identifier | 0 | 6 or larger | Used to negotiate an organization’s proprietary compression protocol.
MPPC | 18 or 0x12 | 6 | Used to indicate the use of MPPC, MPPE, and the encryption strength.

MPPE and MPPC

With CCP option 18, Microsoft PPP peers negotiate both MPPC and MPPE at the same time. The option data field for CCP option 18 is 4 bytes (32 bits) long. Bits within this data field are used as flags to indicate:

  • Whether compression is enabled (0x00-00-00-01).
  • Whether 40-bit session keys are derived from the LAN Manager version of the user’s password (0x00-00-00-10).
  • Whether 40-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-02-00).
  • Whether 128-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-00-40).
  • Whether the encryption keys are refreshed with each PPP frame (0x01-00-00-00).

For multiple choices, the flag values are added together. For example, for compression (0x00-00-00-01) and 128-bit encryption keys (0x00-00-00-40), the resulting 32-bit option data field is set to 0x00-00-00-41.

For more information about MPPE, see the Internet draft, draft-ietf-pppext-mppe-x.txt.

ECP

The Encryption Control Protocol (ECP) is used to negotiate a specific encryption method and is documented in RFC 1968. However, for Microsoft PPP peers, the only encryption that is supported is MPPE and MPPE is negotiated during CCP with the negotiation of MPPC. Therefore, Microsoft PPP peers do not use ECP.


The PPP Connection Process

There are four distinct phases of negotiation of a PPP connection. Each of these four phases must complete successfully before the PPP connection is ready to transfer user data. The four phases of a PPP connection are:

  1. Phase 1: PPP configuration
  2. Phase 2: Authentication
  3. Phase 3: Callback
  4. Phase 4: Protocol configuration

Phase 1: PPP Configuration

PPP configures PPP protocol parameters using LCP (Link Control Protocol). During the initial LCP phase, each peer negotiates communication options that are used to send data and include:

  • PPP parameters, such as MRU, address and control field compression, and protocol ID compression.
  • Which authentication protocols are used to authenticate the remote access client. An authentication protocol is selected but not implemented until the authentication phase.
  • Multilink options.

Phase 2: Authentication

After LCP is complete, the authentication protocol agreed upon by the remote access server and the remote access client is implemented. The nature of this traffic is specific to the PPP authentication protocol. For more details, see “PPP Authentication Protocols” later in this chapter.

Phase 3: Callback

Microsoft’s implementation of PPP includes an optional callback phase using the Callback Control Protocol (CBCP) immediately after authentication. In order for a remote access client user to get called back, the dial-in properties of the user account must be enabled for callback and either the remote access client can specify the callback number or the remote access server must specify the callback number.

If a connection is implementing callback, both PPP peers hang up and the remote access server calls the remote access client at the negotiated number.

Phase 4: Protocol Configuration

Once the PPP is configured and callback is complete (optional), network layer protocols can be configured. With remote access on Windows 32-bit operating systems, the remote access server sends the remote access client Configuration-Request packets for all of the LAN protocols enabled for remote access on the remote access server. The remote access client either continues the negotiation of the LAN protocols enabled at the remote access client or sends an LCP Protocol-Reject message containing the Configuration-Request message.

IPCP, IPXCP, ATCP, and NBFCP each go through a negotiation process very similar to LCP negotiation to configure their corresponding network layer protocol. CCP packets are exchanged to configure MPPC and MPPE.


A Sample PPP Connection

To actually see the PPP connection establishment process in Windows 2000, there are two tools available:

  1. Network Monitor, a packet capture and analysis tool, is used to capture all PPP packets sent over a serial link including connection establishment and PPP-encapsulated user data.
  2. PPP tracing is used to create a log of the PPP packets exchanged during the PPP connection establishment process.

Network Monitor

To capture PPP packets with Network Monitor, set the capture network to the network 000000000000 and begin capturing PPP frames as desired. Network Monitor can capture any PPP frames. You can use Network Monitor to:

  • Troubleshoot the PPP connection establishment process.
  • Ensure that PPP payloads are being encrypted.
  • Ensure that PPP payloads are being compressed.

Note

If compression or encryption is being used, then the PPP payload is not interpreted by Network Monitor. Compressed or encrypted payloads are indicated with the PPP protocol ID of 3D (assuming protocol ID compression). To see the structure of user data within PPP payloads, disable compression and/or encryption.

When using Network Monitor, keep the following in mind:

  • Captured PPP frames do not contain a Flag character but do contain an Ethernet-like source address and destination address. This behavior is due to the fact that Network Monitor receives the packets from the Ndiswan.sys driver. Recall that Ndiswan.sys is an intermediate NDIS driver that looks like an Ethernet adapter to protocols.

    For each PPP frame, the Ethernet-like source and destination address are both set to either SEND or RECV to indicate that the PPP frame was either sent or received by the computer on which the capture was taken. The SEND and RECV addresses do not necessarily identify the traffic of a remote access server or remote access client. If the capture was taken on the remote access server, then SEND frames were sent by the remote access server and RECV frames were sent by the remote access client. If the capture was taken on the remote access client, then SEND frames were sent by the remote access client and RECV frames were sent by the remote access server.

  • Captured PPP frames contain an Address or Control field regardless of whether address and control field compression are negotiated.
  • Protocol ID compression is usually negotiated with Microsoft PPP peers, making the PPP Protocol ID a single byte when possible.
  • Use Network Monitor display filtering to view only the traffic of desired protocols. For example, to view only the IPCP negotiation, set the display filters to disable the display of all protocols except IPCP.

The below printout is an example of a PPP connection establishment process captured with Network Monitor showing only the frame summaries. The entries are indented to improve readability.

1       8.726   SEND         SEND         LCP
                Config Req Packet, Ident = 0x00, Length = 36
2       8.796   RECV         RECV         LCP
                Config Req Packet, Ident = 0x00, Length = 25
3       8.796   SEND         SEND         LCP
                Config Ack Packet, Ident = 0x00, Length = 25
4       8.816   RECV         RECV         LCP
                Config Reject Packet, Ident = 0x00, Length = 17
5       8.816   SEND         SEND         LCP
                Config Req Packet, Ident = 0x01, Length = 23
6       8.886   RECV         RECV         LCP
                Config Ack Packet, Ident = 0x01, Length = 23
7       8.886   SEND         SEND         LCP
                Ident Packet, Ident = 0x02, Length = 18
8       8.886   SEND         SEND         LCP
                Ident Packet, Ident = 0x03, Length = 23
9       8.886   RECV         RECV         PPPCHAP
                Challenge, ID = 0x 1: Challenge
10      8.886   SEND         SEND         PPPCHAP
                Challenge, ID = 0x 1: Response, administrator
11      8.976   RECV         RECV         PPPCHAP
                Challenge, ID = 0x 1: Success
12      8.976   RECV         RECV         CBCP
                Callback Request, Ident = 0x01
13      8.976   SEND         SEND         CBCP
                Callback Response, Ident = 0x01
14      8.996   RECV         RECV         CBCP
                Callback Acknowledgement, Ident = 0x01
15      8.996   SEND         SEND         CCP
                Configuration Request, Ident = 0x04
16      8.997   SEND         SEND         IPCP
                Configuration Request, Ident = 0x05
17      8.997   RECV         RECV         CCP
                Configuration Request, Ident = 0x01
18      9.017   RECV         RECV         IPCP
                Configuration Request, Ident = 0x02
19      9.037   RECV         RECV         IPXCP
                Configuration Request, Ident = 0x03
20      9.037   RECV         RECV         NBFCP
                Configuration Request, Ident = 0x04
21      9.117   SEND         SEND         IPXCP
                Configuration Request, Ident = 0x06
22      9.147   SEND         SEND         CCP
                Configuration Acknowledgement, Ident = 0x01
23      9.147   SEND         SEND         IPCP
                Configuration Acknowledgement, Ident = 0x02
24      9.167   SEND         SEND         IPXCP
                Configuration Acknowledgement, Ident = 0x03
25      9.167   SEND         SEND         LCP
                Protocol Reject Packet, Ident = 0x07, Length = 32
26      9.237   RECV         RECV         CCP
                Configuration Reject, Ident = 0x04
27      9.237   RECV         RECV         IPCP
                Configuration Reject, Ident = 0x05
28      9.237   SEND         SEND         IPCP
                Configuration Request, Ident = 0x08
29      9.257   RECV         RECV         IPXCP
                Configuration No Acknowledgement, Ident = 0x06
30      9.257   SEND         SEND         IPXCP
                Configuration Request, Ident = 0x09
31      9.287   RECV         RECV         IPCP
                Configuration No Acknowledgement, Ident = 0x08
32      9.287   SEND         SEND         IPCP
                Configuration Request, Ident = 0x0A
33      9.287   RECV         RECV         IPXCP
                Configuration Acknowledgement, Ident = 0x09
34      9.327   RECV         RECV         IPCP
                Configuration Acknowledgement, Ident = 0x0A
35      10.729  SEND         SEND         CCP
                Configuration Request, Ident = 0x04
36      10.960  RECV         RECV         CCP
                Configuration Reject, Ident = 0x04
37      10.960  SEND         SEND         CCP
                Configuration Request, Ident = 0x0B
38      10.960  RECV         RECV         CCP
                Configuration Acknowledgement, Ident = 0x0B

The trace was captured on the remote access client. Therefore, the SEND frames were sent from the remote access client and the RECV frames were sent from the remote access server. In this trace, you can see the four phases of the PPP connection establishment:

  • Phase 1:

    PPP configuration is done in frames 1–8 through the exchange of LCP configuration packets.

  • Phase 2:

    Authentication is done in frames 9–11 where the user’s credentials are verified.

  • Phase 3:

    Callback is done in frames 12–14.

  • Phase 4:

    Protocol configuration is done in frames 15–38 where compression, encryption, IP, and IPX is configured.

In addition to the summary view, Network Monitor can also expand frames for detailed analysis. For example, frame 1 from this trace is displayed as:

  FRAME: Base frame properties
      FRAME: Time of capture = Nov 18, 1998 15:23:6.967
      FRAME: Time delta from previous physical frame: 0 milliseconds
      FRAME: Frame number: 1
      FRAME: Total frame length: 50 bytes
      FRAME: Capture frame length: 50 bytes
      FRAME: Frame data: Number of data bytes remaining = 50 (0x0032)
  PPP: Link Control Protocol Frame (0xC021)
      PPP: Destination Address =  SEND_
      PPP: Source Address =  SEND_
      PPP: Protocol = Link Control Protocol
  LCP: Config Req Packet, Ident = 0x00, Length = 36
      LCP: Code = Configuration Request
      LCP: Identifier = 0 (0x0)
      LCP: Length = 36 (0x24)
      LCP: Options: ASYNC.MAP:00 00 00 00-MAGIC#:0x0C05-PROT.COMP-                            ADR/CF.COMP-CALL.BACK:Unkn---
          LCP: ASYNC.MAP:00 00 00 00
              LCP: Option Type = Async Control Character Map
              LCP: Option Length = 6 (0x6)
              LCP: Async Control Character Map = 00 00 00 00
          LCP: MAGIC#:0x0C05
              LCP: Option Type = Majic Number
              LCP: Option Length = 6 (0x6)
              LCP: Magic Number = 3077 (0xC05)
          LCP: PROT.COMP
              LCP: Option Type = Protocol Field Compression
              LCP: Option Length = 2 (0x2)
          LCP: ADR/CF.COMP
              LCP: Option Type = Address and Control Field Compression
              LCP: Option Length = 2 (0x2)
          LCP: CALL.BACK:Unkn
              LCP: Option Type = Calback
              LCP: Option Length = 3 (0x3)
              LCP: CallBack = 0x06
          LCP: Multilink Maximum Receive Reconstructed Unit
              LCP: Option Type = 0x11
              LCP: Option Length = 4 (0x4)
          LCP: Multilink Endpoint Discriminator
              LCP: Option Type = 0x13
              LCP: Option Length = 9 (0x9)

Network Monitor captures can also be saved as files and sent to Microsoft PSS engineers for analysis.

PPP Tracing

Tracing is a facility of Windows 2000 remote access and routing components that allow you to optionally enable and disable the recording of programming code and network events to either a console window or to a file on the disk.

To enable PPP tracing, change the value of the EnableFileTracing registry entry (in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\PPP) to 1.

The file Ppp.log is created in the <SystemRoot>\tracing folder and contains information on the PPP connection establishment process. The PPP logs generated by PPP tracing contain the programming calls and actual packet contents of PPP packets for PPP control protocols. PPP tracing cannot be used to view PPP user data sent across the connection.

The following printout is an excerpt from a PPP trace of a PPP connection establishment process. The entries are indented to improve readability.

[1472] 15:57:50:094: Line up event occurred on port 5
[1472] 15:57:50:104: Starting PPP on link with IfType=0x0,IPIf=0x0,
                     IPXIf=0x0
[1472] 15:57:50:104: RasGetBuffer returned ae70054 for SendBuf
[1472] 15:57:50:104: FsmInit called for protocol = c021, port = 5
[1472] 15:57:50:104: ConfigInfo = 273e
[1472] 15:57:50:104: APs available = 1
[1472] 15:57:50:104: FsmReset called for protocol = c021, port = 5
[1472] 15:57:50:104: Inserting port in bucket # 5
[1472] 15:57:50:104: Inserting bundle in bucket # 6
[1472] 15:57:50:104: FsmOpen event received for protocol c021 on port 5
[1472] 15:57:50:104: FsmThisLayerStarted called for protocol = c021,
                     port = 5
[1472] 15:57:50:104: FsmUp event received for protocol c021 on port 5
[1472] 15:57:50:104: <PPP packet sent at 11/04/1998 23:57:50:104
[1472] 15:57:50:104: <Protocol = LCP, Type = Configure-Req, Length =
                     0x2f, Id = 0x0, Port = 5
[1472] 15:57:50:104: <C0 21 01 00 00 2D 02 06 00 00 00 00 03 05 C2 23
                     |.!...-.........#|
[1472] 15:57:50:104: <80 05 06 72 5F 50 9A 07 02 08 02 0D 03 06 11 04
                     |...r_P..........|
[1472] 15:57:50:104: <06 4E 13 09 03 00 60 08 3E 46 07 17 04 00 03 00
                     |.N....`.>F......|
[1472] 15:57:50:104: InsertInTimerQ called portid=6,Id=0,Protocol=c021,
                     EventType=0,fAuth=0
[1472] 15:57:50:104: InsertInTimerQ called portid=6,Id=0,Protocol=0,
                     EventType=3,fAuth=0
[1472] 15:57:50:104: >PPP packet received at 11/04/1998 23:57:50:104
[1472] 15:57:50:104: >Protocol = LCP, Type = Configure-Req, Length =
                     0x26, Id = 0x0, Port = 5
[1472] 15:57:50:104: >C0 21 01 00 00 24 02 06 00 00 00 00 05 06 00 00
                     |.!...$..........|
[1472] 15:57:50:104: >C0 05 07 02 08 02 0D 03 06 11 04 06 4E 13 09 03
                     |._..........N...|
[1472] 15:57:50:104: >00 60 08 52 F9 D8 00 00 00 00 00 00 00 00 00 00
                     |.`.R............|

The last three lines of this trace excerpt is a hexadecimal display of the same LCP packet as frame 1 of the previous Network Monitor trace. To understand this frame, you must manually parse this frame according to the PPP and LCP packet structure. An example of the parsing of this PPP frame is listed in Table 7.15.

Table 7.15 Parsing of the LCP Configuration-Request

Bytes | Meaning
C0 21 | PPP Protocol ID for LCP.
01 | LCP Code for a Configure-Request.
00 | LCP Identifier for this Configure-Request.
00 24 | Length in bytes of the LCP packet (36 bytes long).
02 | LCP option for Asynchronous Control Character Map (ACCM).
06 | Length in bytes of the ACCM option.
00 00 00 00 | Data for the ACCM option.
05 | LCP option for the magic number.
06 | Length in bytes of the magic number option.
00 00 C0 05 | Data for the magic number option.
07 | LCP option for protocol compression.
02 | Length in bytes of the protocol compression option.
08 | LCP option for address and control field compression.
02 | Length in bytes of the address and control field compression option.
0D | LCP option for callback.
03 | Length in bytes of the callback option.
06 | Callback option data.
11 | LCP option for the Multilink Maximum Receive Reconstructed Unit. Multilink LCP options are discussed in the “Multilink and Bandwidth Allocation Protocol” section of this chapter.
04 | Length in bytes of the Multilink Maximum Receive Reconstructed Unit option.
06 4E | Multilink Maximum Receive Reconstructed Unit option data.
13 | LCP option for the Multilink Endpoint Discriminator option.
09 | Length in bytes of the Multilink Endpoint Discriminator option.
03 00 60 08 52 F9 D8 | Multilink Endpoint Discriminator option data.

As you can see, Network Monitor is the easier tool for the interpretation of PPP traffic. However, the PPP trace contains valuable internal component interaction information that can be useful to troubleshoot connection problems and behavior. When in doubt, obtain both a Network Monitor capture and a PPP trace.

Note

PPP tracing in Windows 2000 is the same as the PPP log feature found in Windows NT 4.0 and earlier.


PPP Connection Termination

PPP can terminate the link at any time. Termination generally occurs due to carrier loss, authentication failure, link quality failure, time-out, or link closure by the dial-up client or system administrator. When the link is closing, PPP informs the network layer protocols so that they can take appropriate action.


PPP Authentication Protocols

Phase 2 of the PPP connection establishment process is the authentication of the remote access client. Authentication for PPP is accomplished through a PPP authentication protocol. During phase 1, both PPP peers agree on a single, specific PPP authentication protocol.

Windows 2000 remote access supports Extensible Authentication Protocol (EAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP).

A secure authentication scheme provides protection against replay attacks, remote access client impersonation, remote access server impersonation.

  • A replay attack occurs when a person captures the packets of a successful connection attempt and then replays those packets in an attempt to obtain an authenticated connection.
  • Remote access client impersonation occurs when a person takes over an existing authenticated connection. The intruder waits until the connection is authenticated and then obtains the connection parameters, disconnects the user, and takes control of the authenticated connection.
  • Remote server impersonation occurs when a computer appears to the remote access client, as the remote access server. The impersonator appears to verify the remote access client credentials and then captures all of the traffic from the remote access client.


PAP

Password Authentication Protocol (PAP) is a simple, clear text authentication scheme. The user name and password are requested by the remote access server and returned by the remote access client in clear text. PAP, however, is not a secure authentication protocol. A person capturing the PAP packets between the remote access server and remote access client can easily determine the remote access client’s password. PAP offers no protection against replay attacks, remote client impersonation, or remote server impersonation.

The use of PAP is negotiated during LCP negotiation by specifying the Authentication Protocol LCP option (type 3) and the authentication protocol 0xC0-23. Once LCP negotiation is complete, PAP messages use the PPP protocol ID of 0xC0-23.

PAP is a simple exchange of messages:

  1. The remote access client sends a PAP Authenticate-Request message to the remote access server containing the remote access client’s user name and clear text password.
  2. The remote access server checks the user name and password and sends back either a PAP Authenticate-Ack message when the user’s credentials are correct, or a PAP Authenticate-Nak message when the user’s credentials are not correct.

PAP is included in Windows 2000 so that remote access clients running Windows 32-bit operating systems can connect to older remote access servers that do not support a secure authentication protocol, and remote access clients not running a Microsoft operating systems that do not support a secure remote access protocol can connect to a remote access server running Windows 32-bit operating systems.

Note

To make your remote access server more secure, ensure that PAP is disabled. However, older remote access clients not running a Microsoft operating systems that do not support secure authentication protocols are unable to connect.


SPAP

The Shiva Password Authentication Protocol (SPAP) is a two-way, reversible encryption mechanism employed by Shiva remote access servers. A Windows 2000 remote access client can use SPAP to authenticate itself to a Shiva remote access server. A remote access client running Windows 32-bit operating systems can use SPAP to authenticate itself to a Windows 2000 remote access server. SPAP is more secure than PAP but less secure than CHAP or MS-CHAP. SPAP offers no protection against remote server impersonation.

The use of SPAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC0-27. Once LCP negotiation is complete, SPAP messages use the PPP protocol ID of 0xC0-27.

Like PAP, SPAP is a simple exchange of messages:

  1. The remote access client sends an SPAP Authenticate-Request message to the remote access server containing the remote access client’s user name and encrypted password.
  2. The remote access server decrypts the password, checks the user name and password, and sends back either an SPAP Authenticate-Ack message when the user’s credentials are correct, or an SPAP Authenticate-Nak message with a reason why the user’s credentials were not correct.


CHAP

The Challenge Handshake Authentication Protocol (CHAP) is a challenge-response authentication protocol documented in RFC 1994 that uses the industry-standard Message Digest 5 (MD5) one-way encryption scheme to hash the response to a challenge issued by the remote access server.

CHAP is used by various vendors of dial-in servers and clients. CHAP is supported by both the Windows 2000 remote access server and remote access client. CHAP is only supported on Windows 2000 Server computers that are a member of a Windows 2000 mixed or native domain.

CHAP is an improvement over PAP and SHAP in that the password is never sent over the link. Instead, the password is used to create a one-way hash from a challenge string. The server, knowing the client’s password, can duplicate the operation and compare the result with that sent in the client’s response.

The use of CHAP is negotiated during phase 1 by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x05. Once LCP negotiation is complete, CHAP messages use the PPP Protocol ID of 0xC2-23.

CHAP authentication is an exchange of three messages:

  1. The remote access server sends a CHAP Challenge message containing a session ID and an arbitrary challenge string.
  2. The remote access client returns a CHAP Response message containing the user name in clear text and a hash of the challenge string, session ID, and the client’s password using the MD5 one-way hashing algorithm.
  3. The remote access server duplicates the hash and compares it to the hash in the CHAP Response. If the hashes are the same, the remote access server sends back a CHAP Success message. If the hashes are different, a CHAP Failure message is sent.

CHAP protects against replay attacks by using an arbitrary challenge string per authentication attempt. However, CHAP does not protect against remote server impersonation.


MS-CHAP v1

The Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 1 (MS-CHAP v1) is an encrypted authentication mechanism very similar to CHAP. As in CHAP, the remote access server sends a challenge to the remote client that consists of a session ID and an arbitrary challenge string. The remote client must return the user name and an MD4 hash of the challenge string, the session ID, and the MD4-hashed password.

One difference between CHAP and MS-CHAP v1 is that, in CHAP, the clear-text version of the password must be available to validate the challenge response. With MS-CHAP v1, the remote access server only requires the MD4 hash of the password to validate the challenge response. In Windows 2000, the user’s password is stored as an MD4 hash and in a reversibly encrypted form. When CHAP is used, the remote access server decrypts the reversibly encrypted password to validate the remote access client’s response.

MS-CHAP v1 authentication is an exchange of three messages:

  1. The remote access server sends an MS-CHAP Challenge message containing a session ID and an arbitrary challenge string.
  2. The remote access client returns an MS-CHAP Response message containing the user name in clear text and a hash of the challenge string, session ID, and the MD4 hash of the client’s password using the MD4 one-way hashing algorithm.
  3. The remote access server duplicates the hash and compares it to the hash in the MS-CHAP Response. If the hashes are the same, the remote access server sends back a CHAP Success message. If the hashes are different, a CHAP Failure message is sent.

The use of MS-CHAP v1 is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x80. Once LCP negotiation is complete, MS-CHAP v1 messages use the PPP protocol ID of 0xC2-23.

MS-CHAP v1 also allows for error codes including a "password expired" code and password changes. MS-CHAP v1 protects against replay attacks by using an arbitrary challenge string per authentication attempt. MS-CHAP v1 does not provide protection against remote server impersonation.

If MS-CHAP v1 is used as the authentication protocol and MPPE is negotiated, then shared secret encryption keys are generated by each PPP peer.


MS-CHAP v2

Windows 2000 includes support for MS-CHAP version 2 (MS-CHAP v2) that provides stronger security for remote access connections. MS-CHAP v2 offers the additional security features:

  • LAN Manager encoding of responses and password changes is no longer supported.
  • Two-way authentication verifies the identity of both sides of the connection. The remote access client authenticates against the remote access server and the remote access server authenticates against the remote access client. Two-way authentication, also known as mutual authentication, ensures that the remote access client is dialing into a remote access server that has access to the user's password. Mutual authentication provides protection against remote server impersonation.
  • Separate cryptographic keys are generated for transmitted and received data.
  • The cryptographic keys are based on the user's password and the arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used.

The use of MS-CHAP v2 is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x81. Once LCP negotiation is complete, MS-CHAP messages use the PPP protocol ID of 0xC2-23.

MS-CHAP v2 authentication is an exchange of three messages:

  1. The remote access server sends an MS-CHAP v2 Challenge message to the remote access client that consists of a session identifier and an arbitrary challenge string.
  2. The remote access client sends an MS-CHAP v2 Response message that contains:
    • The user name.
    • An arbitrary peer challenge string.
    • An MD4 hash of the received challenge string, the peer challenge string, the session identifier, and the MD4 hashed version of the user's password.
  3. The remote access server checks the MS-CHAP v2 Response message from the client and sends back an MS-CHAP v2 Response message containing:
    • An indication of the success or failure of the connection attempt.
    • An authenticated response based on the sent challenge string, the peer challenge string, the client's encrypted response, and the user's password.
  4. The remote access client verifies the authentication response and if it is correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.


EAP

The Extensible Authentication Protocol (EAP) is an extension to PPP that allows for arbitrary authentication mechanisms to be employed for the validation of a PPP connection. With PPP authentication protocols such as MS-CHAP and SPAP, a specific authentication mechanism is chosen during the link establishment phase. Then, during the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order.

With EAP, the specific authentication mechanism is not chosen during the link establishment phase. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. Once the connection authentication phase is reached, the PPP peers must first negotiate the use of a specific EAP authentication scheme known as an EAP type. Once the EAP type is agreed upon, EAP allows for an open-ended conversation between the remote access client and the remote access server that can vary based on the parameters of the connection. The conversation consists of requests for authentication information and the responses. The length and detail of the authentication conversation is dependent upon the EAP type.

For example, when EAP is used with security token cards, the remote access server could separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the user passes through another level of authentication. When all questions have been answered satisfactorily, the user is authenticated and permitted access to the network.

The use of EAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC2-27. Once LCP negotiation is complete, EAP messages use the PPP Protocol ID of 0xC2-27. Windows 2000 includes support for the EAP-MD5 and EAP-TLS EAP types.

Architecturally, EAP is designed to allow authentication plug-in modules at both the client and server ends of a connection. By installing an EAP type library file on both the remote access client and the remote access server, a new EAP type can be supported. This presents vendors with the opportunity to supply a new authentication scheme at any time. EAP provides the highest flexibility in authentication uniqueness and variations.

EAP-MD5

EAP-MD5 is the CHAP authentication mechanism used within the EAP framework. Rather than negotiating to perform MD5 authentication during the link establishment phase, the authenticator and peer negotiate to do EAP during the connection authentication phase.

Once the connection authentication phase is reached, the following process verifies the client:

  1. The authenticator sends an EAP-Request message requesting the identity of the client.
  2. The client sends their user ID to the authenticator as an EAP-Response message.
  3. The authenticator sends an EAP-Request message containing the MD-5 challenge string.
  4. The client sends the MD-5 hash of their user ID and password to the authenticator as an EAP-Response message.
  5. If the response is proper, the authenticator sends a Success message to the client.

EAP-MD5 is a required EAP type and can be used to test EAP interoperability.

EAP-TLS

The Transport Layer Security (TLS) protocol, based on the Secure Sockets Layer, allows applications to communicate securely. TLS provides authentication (user and data), data integrity, and data confidentiality services. To achieve these services, TLS specifies a framework that allows the following:

  • Client and two-way authentication using symmetric or asymmetric encryption.
  • Negotiation of the specific encryption algorithm (the cipher-suite).
  • Secured exchange of encryption keys to be used for encrypting messages.
  • Message integrity and user authentication using a message authentication code (MAC).

The details of TLS can be found in the Internet draft, draft-ietf-tls-protocol-x.txt, where x is the current version number.

EAP-TLS is the use of TLS during the establishment of a PPP connection. With EAP-TLS, mutual authentication between the PPP client and the authenticator is done through the exchange and verification of certificates. The user attempting the connection sends a user certificate, and the authenticator sends a machine certificate.

EAP-TLS is only supported on Windows 2000 Server remote access server computers that are a member of a Windows 2000 mixed or native domain. Standalone Windows 2000 remote access servers do not support EAP-TLS.

EAP-RADIUS

EAP-RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by the remote access server to a RADIUS server for authentication. The EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server. The remote access server becomes a pass-through device passing EAP messages between the remote access client and the RADIUS server. All processing of EAP messages occurs at the remote access client and the RADIUS server.

EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server.

In a typical use of EAP-RADIUS, the remote access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client.

Note

Windows 2000 includes a RADIUS server called Internet Authentication Services. However, Internet Authentication Services does not support EAP-TLS and password changes using the MS-CHAP authentication protocol.


Remote Access and LAN Protocols

The following sections describe how the Windows 2000 remote access server allocates network configuration parameters for TCP/IP and IPX-based remote access clients.


TCP/IP

To configure a TCP/IP-based remote access client with IPCP, the remote access server allocates an IP address and assigns the IP addresses of DNS and WINS servers (a primary and a backup).

IP Address Allocation

To allocate an IP address to a remote access client, the remote access server is either configured to use Dynamic Host Configuration Protocol (DHCP) to obtain IP addresses, or with a static IP address pool.

DHCP and AutoNet

When the remote access server is configured to use DHCP to obtain IP addresses, the DHCP server instructs the DHCP client component to obtain 10 IP addresses from a DHCP server. The remote access server uses the first IP address obtained from DHCP for the remote access server interface, and subsequent addresses are allocated to TCP/IP-based remote access clients as they connect. IP addresses freed due to remote access clients disconnecting are reused.

When all 10 IP addresses are used, the remote access server uses the DHCP client component to obtain 10 more. You can modify the number of IP addresses obtained at a time by changing the value of the InitialAddressPoolSize registry entry (in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess \Parameters\Ip)

With the Windows NT 4.0 remote access server, the DHCP allocated addresses are recorded and reused when the remote access service is restarted. The Windows 2000 remote access server now releases all DHCP allocated IP addresses using DHCPRELEASE messages each time the service is stopped.

If the remote access server initially starts using DHCP-allocated addresses and the DHCP server becomes unavailable, then an IP address cannot be allocated to additional TCP/IP-based remote access clients.

If a DHCP server is not available when the Routing and Remote Access Service is started, then the DHCP client returns 10 AutoNet addresses in the range 169.254.0.1 to 169.254.255.254 to allocate to remote access clients. AutoNet addresses for point-to-LAN remote access connectivity work only if the network to which the remote access server computer is attached is also using AutoNet addresses. If the local network is not using AutoNet addresses, remote access clients are only able to obtain point-to-point remote access connectivity.

If a DHCP server does become available, the next time IP addresses are needed by the Routing and Remote Access Service, DHCP-obtained addresses are then allocated to remote access clients that connect after the DHCP addresses were obtained.

The remote access server uses a specific LAN interface to obtain DHCP-allocated IP addresses for remote access clients. You can select which LAN interface from which IP addresses are obtained for allocation to remote access clients, from the TCP/IP tab on the properties of a remote access router in the Routing and Remote Access snap-in. By default, Allow remote access to select adapter is selected, which means that the Routing and Remote Access Service randomly picks a LAN adapter to use.

Static IP Address Pools

When a static IP address pool is configured, the remote access server uses the first IP address in the range for the remote access server interface, and subsequent addresses are allocated to TCP/IP-based remote access clients as they connect. IP addresses freed due to remote access clients disconnecting are reused.

If the static IP address pool is an off-subnet address pool, either enable an appropriate routing protocol on the remote access server or add a static route corresponding to the IP address pool to the routers of your intranet. For more information, see “TCP/IP On-Subnet and Off-Subnet Addressing” earlier in this chapter.

DNS and WINS Address Assignment

As part of the IPCP negotiation, the remote access server assigns the IP addresses of DNS and WINS servers. Exactly which set of DNS and WINS server IP addresses that are assigned to the remote access client depends on the following factors:

  • Whether DNS and WINS server IP address assignment is prohibited.
  • Whether DNS and WINS server IP addresses for remote access clients are globally configured by using data stored in the registry.
  • Whether the remote access server has more than one LAN interface.
  • Whether the DNS and WINS server IP addresses for the remote access server are configured statically or are obtained through DHCP.

Prohibiting DNS and WINS IP Address Assignment

If you do not want the remote access server to assign DNS and WINS IP addresses, set the values of SuppressDNSNameServers and SuppressWINSNameServers in

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess \Parameters\Ip to 1.

Configuring Global DNS and WINS IP Address Assignment

To globally configure DNS and WINS server IP addresses for remote access clients, enter the IP addresses in the values of DNSNameServers and WINSNameServer in

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess \Parameters\Ip.

Multiple LAN Interfaces

If the DNS and WINS server IP address assignment is not prohibited or globally configured, then the remote access server allocates the DNS and WINS server IP address(es) of a LAN interface on the remote access server to remote access clients. If there is only one LAN interface, which is the typical configuration of a dial-up remote access server, the remote access server allocates the DNS and WINS server IP addresses of the single LAN interface to remote access clients. If there is more than one LAN interface, the DNS and WINS server IP addresses of a specific LAN interface must be determined.

With multiple LAN interfaces, which is the typical configuration of a VPN remote access server, the remote access server by default picks one LAN interface randomly during startup and uses the DNS and WINS server IP addresses of the chosen LAN interface to allocate to remote access clients. To override this behavior, you can select the desired LAN interface through the TCP/IP tab on the properties of a remote access router in the Routing and Remote Access snap-in. By default, Allow remote access to select adapter is selected.

Static Configuration or DHCP

Once the LAN adapter for DNS and WINS server IP address assignment has been determined:

  • If the LAN adapter has a static IP configuration, then the IP addresses of the statically configured DNS and WINS servers are allocated to remote access clients.
  • If the LAN adapter obtained its IP configuration using DHCP, then the IP addresses of the DHCP-obtained DNS and WINS servers are allocated to remote access clients.

The way that the remote access server determines the set of DNS and WINS server IP addresses to assign to remote access clients during IPCP negotiation is illustrated in Figure 7.14.

Figure 7.14 DNS and WINS server IP Address Determination

Overriding IPCP-Allocated DNS and WINS server IP Addresses with DHCPINFORM

After IPCP is completed, Windows 2000 and Windows 98 remote access clients send their remote access servers a DHCPINFORM message. DHCPINFORM is a DHCP message used by DHCP clients to obtain DHCP options. While PPP remote access clients do not use DHCP to obtain IP addresses for the remote access connection, Windows 2000 and Windows 98 remote access clients use the DHCPINFORM message to obtain DNS server IP addresses, WINS server IP addresses, and a DNS domain name. The DHCPINFORM message is sent after the IPCP negotiation is concluded.

The DHCPINFORM message received by the remote access server is then forwarded to a DHCP server. The remote access server forwards DHCPINFORM messages, if it has been configured with the DHCP relay agent as discussed in the following section. The response to the DHCPINFORM message is forwarded back to the requesting remote access client.

If the DHCPINFORM response contains DNS and WINS server IP address options, then these new values override what was allocated during IPCP.

Remote Access Server and the DHCP Relay Agent

To facilitate the forwarding of DHCPINFORM messages between remote access clients and DHCP servers, the remote access server uses the DHCP Relay Agent, a component of the Windows 2000 remote access router. To configure the remote access server to use the DHCP Relay Agent, add the Internal interface to the DHCP Relay Agent IP routing protocol with the Routing and Remote Access snap-in.

If the remote access server is using DHCP to obtain IP addresses for remote access clients, then the remote access server uses the DHCP Relay Agent to forward DHCPINFORM messages to the DHCP server of the selected LAN interface, on the TCP/IP tab on the properties of a remote access router in the Routing and Remote Access snap-in.

If the remote access server is using a static IP address pool to obtain IP addresses for remote access clients, then the DHCP Relay Agent must be configured with the IP address of at least one DHCP server. Otherwise, DHCPINFORM messages sent by remote access clients are silently discarded by the remote access server.


IPX

To configure an IPX-based remote access client with IPXCP, the remote access server allocates an IPX network number and an IPX node number. The network number allocation behavior is configured from the IPX tab on the properties of a remote access router with the Routing and Remote Access snap-in. The main elements of IPX configuration are:

  • IPX network numbers for remote access clients can be automatically allocated or specified as a range by the network administrator. For automatically allocated IPX network numbers, the remote access server ensures that the IPX network number is not being used on the IPX internetwork by sending a RIP GetLocalTarget packet on its LAN interfaces. If there is a response to the RIP GetLocalTarget, then the IPX network number is in use and another IPX network number is chosen.
  • The same IPX network number can be assigned to all remote access clients.
  • Specific IPX node numbers can be requested by remote access clients.
  • You can set the first IPX node number as a 12-digit hexadecimal number to be allocated to IPX remote access clients. To do so, add the FirstWanNode (REG_SZ) registry entry to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess \Parameters\Ipx) and enter the desired IPX node number in the value of the entry.
  • Subsequent IPX clients are assigned incrementally increasing node numbers. If this registry entry does not appear in the registry, a random IPX node number, in the form 0x2E-XX-XX-XX-XX-XX, is assigned when the remote access client does not request a specific IPX node number.


Remote Access Policies

In Windows 2000, remote access connections are accepted based on the dial-in properties of a user account and remote access policies. A remote access policy is a set of conditions and connection parameters that define the characteristics of the incoming connection and the set of constraints imposed on it. Remote access policies can be used to specify allowed connections conditioned by the time of day and day of the week, the Windows 2000 group to which the dial-in user belongs, the type of remote access client (dial-up or VPN), and so on. Remote access policies can be used to impose connection parameters such as maximum session time, idle disconnect time, required secure authentication methods, required encryption, and so on.

With multiple remote access policies, different sets of conditions can be applied to different remote access clients or different requirements can be applied to the same remote access client based on the parameters of the connection attempt. For example, multiple remote access policies can be used to:

  • Allow or deny connections if the user account belongs to a specific group.
  • Define different days and times for different user accounts based on group membership.
  • Configure different authentication methods for dial-up and VPN remote access clients.
  • Configure different maximum session times for different user accounts based on group membership.
  • Send network access server-specific RADIUS attributes to a RADIUS client.

For more information about remote access policies, including common remote access policy scenarios and their configuration, see Windows 2000 Help.


Connection Attempt Processing

To process a connection attempt, the parameters of the connection attempt are compared to the user name, password, and dial-in properties of the user account and the configured remote access policies.

Some general characteristics of remote access connection attempt processing are:

  • If a connection attempt does not use a valid user name and password, then the connection attempt is denied.
  • If there are no configured policies, then all connection attempts are denied.
  • If the connection attempt does not match any of the remote access policies, then the connection attempt is denied.
  • If the remote access permission of the user account for the remote access user is set to Deny Access, the connection attempt is always denied for that remote access user.
  • The only time that a connection attempt is allowed is when it matches the conditions of a remote access policy, and remote access permission is enabled either through the dial-in properties of the user account or through the remote access permission of the remote access policy (assuming the user’s remote access permission is set to control access through remote access policies), and the parameters of the connection attempt match or conform to the parameters and conditions of the dial-in properties of the user account and the remote access policy profile properties.

Figure 7.15 depicts the specific processing of remote access connection attempts using the dial-in properties of the user account and remote access policies. Figure 7.15 assumes that the user name and password sent during the authentication process match a valid user account.

Figure 7.15 Connection Attempt Processing


Troubleshooting Remote Access Policies

A common problem with remote access policies is that a connection attempt is denied when it should be allowed. When in doubt, apply the logic of Figure 7.7 to the parameters of the connection attempt, the dial-in properties of the user account, and the remote access policies. However, troubleshooting the denial of the connection attempt can be very time consuming when there are multiple remote access policies in place.

When multiple remote access policies are configured and you want to determine which remote access policy is denying the connection attempt, perform the following:

  1. Verify that the remote access permission of the user account is set to either Allow access or control access through remote access policies.
  2. Create a new remote access policy called Troubleshooter. Configure the remote access policy to grant remote access permission and set the Time-of-Day condition for all times and all days.
  3. Move the Troubleshooter remote access policy so that it is the first remote access policy to be processed.
  4. Attempt the connection.
  5. If the connection attempt is denied, troubleshoot the connection based on the dial-in properties of the user account and the default profile settings of the Troubleshooter remote access policy.
  6. If the connection attempt succeeds, terminate the connection and move the Troubleshooter remote access policy down one level.
  7. Attempt the connection.

    If the connection attempt is denied, troubleshoot the connection based on the dial-in properties of the user account and the default profile settings of the remote access policy just above the Troubleshooter remote access policy.

  8. If the connection attempt succeeds, terminate the connection and move the Troubleshooter remote access policy down one level.
  9. Repeat steps 6 and 7 until the remote access policy that is denying the connection attempt is found.
  10. When troubleshooting is complete, delete the Troubleshooter remote access policy.


Multilink and Bandwidth Allocation Protocol

Windows 2000 remote access supports Multilink PPP (MP), the Bandwidth Allocation Protocol (BAP), and the Bandwidth Allocation Control Protocol (BACP):

  • MP allows multiple physical links to appear as a single logical link over which data can be sent and received.
  • BAP is a PPP control protocol that is used to dynamically add or remove additional links to an MP connection.
  • BACP is a PPP NCP that elects a favored peer in case both PPP peers request to add or remove a connection at the same time.

Each of these protocols is discussed in greater detail in the following sections.


Multilink

The Multilink PPP (MP) protocol is defined in RFC 1990 and used to aggregate multiple physical links into a single logical link. A good example is the aggregation of both B-channels of an ISDN Basic Rate Interface (BRI) connection. MP fragments, sequences, and re-orders alternating packets sent across multiple physical connections so that the end result is a single logical link with the combined bandwidth of all of the aggregated physical links. MP is the recommended method of combining multiple B-channels of a BRI connection because the support for bonding — the combining of ISDN B-channels through hardware support — can be specific to the ISDN adapter. MP can be done for any ISDN adapter. MP must be supported on both sides of the connection.

Figure 7.16 illustrates the structure of an MP frame. The payload of a Multilink PPP packet is either a fragment of a PPP frame or the entire PPP frame. Multilink PPP fragmentation need not occur if the Multilink PPP packet fits within the MRU of the link. To prevent misordering of the datagrams or fragments across multiple links, additional fields are used between the PPP Protocol field and the IP datagram. Multilink PPP uses the PPP Protocol ID of 0x00-3D.

Figure 7.16 Multilink PPP

RFC 1717 defines two different packet formats for short sequence numbers and long sequence numbers. When using either short or long sequence numbers, the sequence number is used to prevent misordering of frames that are sent across multiple links, not to sequence fragments.

For short sequence numbers, a two byte Delimitation/Sequence # field consists of four bits used for delimitation and 12 bits used for the sequence number. Within the delimitation field are two flags. The first bit (the Beginning bit) is an indicator that this fragment begins a sequence of fragments corresponding to a packet. The second bit (the Ending bit) is an indicator that this fragment ends a sequence of fragments corresponding to a packet. The other bits in the first four bits of the short sequence number header are set to 0.

For a PPP frame that is sent without fragmentation, both the Beginning and Ending bits are set. For a PPP frame that is larger than the MRU of the physical link, the PPP frame is fragmented, and each fragment is sent as a separate PPP packet. MP performs a Data Link layer fragmentation that is not related to IP fragmentation.

For long sequence numbers, a four byte Delimitation/Sequence # field consists of eight bits (one byte) used for delimitation, and 24 bits (3 bytes) used for the sequence number. Within the delimitation field, the same bits as the short sequence number header define the Beginning bit and the Ending bit. The other bits in the first byte of the long sequence number header are set to 0. The long sequence number header is used by default, unless the short sequence number is chosen during LCP negotiation.

Table 7.16 lists Multilink PPP LCP options negotiated by Microsoft PPP peers. For information about other Multilink PPP options, see RFC 1990.

Table 7.16 Multilink LCP Options

Option Name | Option Type | Option Length | Description
Multilink Maximum Receive Reconstructed Unit | 17 or 0x11 | 4 | Specifies the number of octets that a peer can reconstruct when performing reassembly of fragmented MP frames.
Short Sequence Number Header Format | 18 or 0x12 | 2 | Specifies the use of the short sequence number in the MP header.
Multilink Endpoint Discriminator | 19 or 0x13 | 9 | A unique system identifier to differentiate links from two PPP peers with the same authenticated name.


Bandwidth Allocation Protocol (BAP)

While MP allows for multiple physical links to be aggregated, MP does not provide a mechanism to adapt to changing conditions by adding extra links when needed or terminating extra links when unneeded. This additional capability is provided by the Bandwidth Allocation Protocol (BAP) and the Bandwidth Allocation Control Protocol (BACP) defined in RFC 2125. BAP is a PPP control protocol that is used on an MP connection to dynamically manage links. BAP uses the PPP Protocol of ID 0xC0-2D.

For example, an MP and BAP-enabled remote access client and remote access server create an MP connection consisting of a single physical link. As the utilization of the single link rises to a configured level, the remote access client uses a BAP Call-Request message to request an additional link. The BAP Call-Request message specifies the type of link desired, such as analog phone, ISDN, or X.25. The remote access server then sends a BAP Call-Response message containing the phone number of an available port on the remote access server of the same type specified by the remote access client in the BAP Call-Request.

When the utilization on the second link drops to a specific level, either the remote access client or the remote access server can send a BAP Link-Drop-Query-Request message to drop the link.

BAP also supports a Callback-Request message where the requesting peer specifies the link type and the number to call back to. For more information about BAP messages, see RFC 2125.

Table 7.17 lists BAP LCP options negotiated by Microsoft PPP peers.

Table 7.17 Multilink LCP Options

Option Name | Option Type | Option Length | Description
BAP Link Discriminator | 23 or 0x17 | 4 | A unique number used to identify a particular link in a Multilink PPP connection.

Multilink and BAP are enabled on the remote access server through the PPP tab on the properties of the remote access router in the Routing and Remote Access snap-in. Properties of Multilink and BAP are configured from the Multilink tab on the properties of a remote access policy profile.

To set the phone number of a port that is sent in the BAP Call-Response message

  1. Use the Routing and Remote Access snap-in and obtain properties on the Ports object.
  2. Select the desired port, and click Configure.
  3. Type the phone number in the Phone number of this device text box.


Bandwidth Allocation Control Protocol (BACP)

The Bandwidth Allocation Control Protocol (BACP) is a PPP NCP that negotiates a single option: the election of a favored peer. If both peers of an MP and BAP-enabled connection send BAP Call-Request or BAP Link-Drop-Query-Request messages at the same time, the favored peer is the peer whose requests are implemented.

BACP uses the PPP Protocol ID of 0xC0-2B. The packet structure of BACP is exactly the same for LCP, except that only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject BACP packet types, the BACP data portion of the BACP packet consists of the single BACP Favored-Peer option listed in Table 7.18.

Table 7.18 BACP Favored Peer Option

Option Name | Option Type | Option Length | Description
Favored-Peer | 1 | 6 | A randomly allocated 4-byte magic number used to elect a favored BAP peer. The favored peer is the peer with the lowest magic number.


Remote Access Server and IP Multicast Support

The Windows 2000 remote access server also supports the forwarding of IP multicast traffic between remote access clients and the networks to which the remote access server is attached.

IP multicast support for remote access clients requires the following three elements, as illustrated in Figure 7.17.

  1. The Windows 2000 IGMP Router is enabled on the interface connected to all of the remote access clients. In the Routing and Remote Access snap-in, this is the Internal interface.
  2. The Windows 2000 IGMP Proxy is enabled on a single interface.
  3. The network corresponding to the interface on which the IGMP Proxy is enabled is part of an IP multicast–enabled network. An IP multicast–enabled network uses multicast routing protocols to propagate IP multicast traffic from multicast sources located on any network, to hosts located on any network. For example, the IP-multicast network portion of the Internet is called the Multicast Backbone or MBone.

Figure 7.17 Multicast Support for Remote Access

Multicast Traffic to Remote Access Clients

To facilitate the forwarding of IP multicast traffic from multicast sources on the IP multicast–enabled network to remote access clients:

  1. The multicast groups being listened to by remote access clients must be registered with the IP multicast routers of the IP multicast-enabled network.
  2. IP multicast traffic from multicast sources must be forwarded to the remote access clients.

Remote Access Client Group Registration

Remote access clients register the IP multicast addresses from which they want to receive traffic by sending IGMP Membership Report messages across the remote access connection. The remote access server records the multicast groups registered by each remote access client and then forwards the IGMP Membership Report message using the interface on which the IGMP Proxy is enabled.

The forwarded IGMP Membership Report message is received by the IP multicast routers attached to the remote access server’s network segment. The IP multicast routers of the IP multicast–enabled network use multicast routing protocols to create entries in their multicast forwarding tables, so that multicast traffic sent to the multicast groups— registered by the remote access clients— are forwarded to the network segment of the remote access server.

Forwarding Multicast Traffic

When the multicast source sends multicast traffic to the multicast group registered by the remote access clients, IP multicast routers forward the multicast traffic to the network segment of the remote access server for the interface on which the IGMP Proxy is enabled.

When the remote access server receives multicast traffic on the interface on which the IGMP Proxy is enabled, the multicast traffic is checked to determine whether any connected remote access client has registered an IGMP Membership Report for that multicast group. If the multicast traffic corresponds to a multicast group registered by a remote access client, the multicast traffic is forwarded to the remote access client.

Multicast Traffic from Remote Access Clients

To facilitate the forwarding of IP multicast traffic from remote access clients that are multicast sources:

  1. The multicast groups being listened to by hosts must be registered with the IP multicast routers of the IP multicast–enabled network.
  2. IP multicast traffic from the remote access clients must be forwarded to the listening hosts.

Host Group Registration

Hosts on the IP multicast–enabled network register the IP multicast addresses for which they want to receive traffic from by sending IGMP Membership Report messages on their local network segments. The IP multicast routers of the IP multicast–enabled network use multicast routing protocols to create entries in their multicast forwarding tables. Therefore, multicast traffic sent to the multicast groups registered by the hosts are forwarded to the host’s network segment.

Forwarding Multicast Traffic

When the remote access client sends multicast traffic across the remote access connection, the multicast traffic is forwarded to the network segment of the interface on the remote access server on which the IGMP Proxy component is enabled. IP multicast routers on that network segment receive the forwarded multicast traffic and forward it to the network segments of the listening hosts.

Additionally, the remote access server forwards the IP multicast traffic to other remote access clients that are listening for the IP multicast traffic of the remote access client that is the multicast source.

Internet-Based IP Multicast Traffic

If the remote access server is being used to provide Internet access to dial-up clients, then the following configuration allows IP multicast traffic to and from connected remote access clients:

  1. The remote access server has a direct connection to the Internet’s MBone or an indirect connection to the MBone through a logical tunnel.
  2. The interface corresponding to the direct or indirect connection to the MBone is added to the IGMP routing protocol and enabled for the IGMP Proxy.
  3. The Internal interface is added to the IGMP routing protocol and enabled for the IGMP Router.

The Install Routing and Remote Access Wizard attempts to configure the IGMP Proxy and IGMP Router components automatically.

Organization-Based IP Multicast Traffic

If the remote access server is being used to provide a connection to an organization’s intranet to dial-up or VPN clients, then the following configuration allows IP multicast traffic to and from connected remote access clients:

  1. The remote access server has a LAN interface on the organization’s intranet, which is a network segment on the organization’s IP multicast-enabled network.
  2. The LAN interface connection to the organization intranet is added to the IGMP routing protocol and enabled for the IGMP Proxy.
  3. The Internal interface is added to the IGMP routing protocol and enabled for the IGMP Router.

The Install Routing and Remote Access Wizard attempts to configure the IGMP Proxy and IGMP Router components automatically.


Troubleshooting the Remote Access Server

Troubleshooting remote access is a combination of troubleshooting IP connectivity, addressing, routing, and dial-up hardware. A firm understanding of all of these topics is required. The following sections outline common remote access problems and the troubleshooting tools provided with Windows 2000.

To troubleshoot VPN connections, see “Virtual Private Networks” in this book. To troubleshoot demand-dial routing connections, see “Demand-Dial Routing” in this book.


Common Remote Access Problems

Remote access problems typically include the following:

  • Connection attempt is rejected when it should be accepted.
  • Connection attempt is accepted when it should be rejected.
  • Unable to reach locations beyond the remote access server.
  • Miscellaneous remote access problems.

The following sections give troubleshooting tips to isolate the configuration or infrastructure problem causing the remote access problem.

Connection Attempt Is Rejected When It Should Be Accepted

  • Verify that the Routing and Remote Access Service is running on the remote access server.
  • Verify that remote access is enabled on the remote access server.
  • Verify that the dial-up ports on the remote access server are configured to allow inbound remote access connections.
  • Verify that all of the dial-up ports on the remote access server are not already connected.
  • Verify that the remote access client and the remote access server are enabled to use at least one common authentication method.
  • Verify that the remote access client and the remote access server are enabled to use at least one common encryption method.
  • Verify that the LAN protocol(s) being used by the remote access clients is enabled for remote access.
  • Verify that the remote access client's credentials consisting of user name, password, and domain name are correct and can be validated by the remote access server.
  • Verify that the parameters of the connection attempt are accepted by the currently configured dial-in properties of the user account and remote access policies.

    In order for the connection to be established, the parameters of the connection attempt must:

    1. Match all of the conditions of at least one remote access policy.
    2. Be granted remote access permission, either through the remote access permission of the user account (set to Allow access), or the user account is set to Control access through Remote Access Policy and the remote access permission of the matching remote access policy is set to Grant remote access permission.
    3. Match all the settings of the profile.
    4. Match all the settings of the dial-in properties of the user account.
  • Verify that the settings of the remote access policy profile are not in conflict with properties of the remote access router.

    The properties of the remote access policy profile and the properties of the remote access router both contain settings for:

    • TCP/IP address assignment
    • Multilink
    • Bandwidth allocation protocol
    • Authentication protocols

    If the settings of the profile of the matching remote access policy are in conflict with the settings of the remote access router, then the connection attempt is denied. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP-TLS is not enabled through the properties of the remote access router, then the remote access server denies the connection attempt.

  • If the remote access server is configured with a static IP address pool, verify that there are enough addresses in the pool.

    If all of the addresses in the static pool have been allocated to connected remote access clients, then the remote access server is unable to allocate an IP address. If the remote access client is only configured to use TCP/IP as a LAN protocol, the connection attempt is denied.

  • If the remote access client is configured to request its own IPX node number, verify that the server is configured to allow IPX clients to request their own IPX node number.
  • If the remote access server is configured with a range of IPX network numbers, verify that the IPX network numbers in the range are not being used elsewhere on your IPX internetwork.
  • Verify the configuration of the authentication provider.

    The remote access server can be configured to use either Windows 2000 or RADIUS to authenticate the credentials of the remote access client.

  • For a remote access server that is a member server in mixed or native Windows 2000 domain configured for Windows 2000 authentication, verify that the machine account of the remote access server computer is a member of the remote access and IAS Servers security group.
  • Verify that if Windows 2000 fax and the Routing and Remote Access Service are sharing the same modem, that the modem supports adaptive answer. If the modem does not support adaptive answer, you must disable fax on the modem to receive incoming remote access connections.

Connection Attempt Is Accepted When It Should Be Rejected

  • Verify that the parameters of the connection does not have permission through remote access policies.

    In order for the connection to be rejected, the parameters of the connection attempt must be denied remote access permission either through the remote access permission of the user account (set to Deny access) or the user account is set to Control access through Remote Access Policy and the remote access permission of the first remote access policy that matches the parameters of the connection attempt is set to Deny remote access permission.

Unable to Reach Locations Beyond the Remote Access Server

  • Verify that the LAN protocols being used by the remote access clients are enabled to allow access to the network to which the remote access server is attached.
    • Verify the IP address allocation settings of the remote access server. If the remote access server is configured to use a static IP address pool, verify that the route to the range of addresses defined by the static IP address pool is reachable by the hosts and routers of the intranet. If not, then an IP route consisting of the remote access server static IP address pool, as defined by the IP address and subnet mask of the range, must be added to the routers of the intranet. If the route is not added, then remote access clients do not receive traffic from locations on the intranet. A route for the network can be implemented through static routing entries, or through a routing protocol, such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF).

    If the remote access server is configured to use DHCP for IP address allocation and no DHCP server is available, the remote access server allocates addresses from the AutoNet address range of 169.254.0.1 to 169.254.255.254. Allocating AutoNet addresses for remote access clients works only if the network to which the remote access server is attached is also using AutoNet addresses.

    If the static IP address pool is a range of IP addresses that is a subset of the range of IP addresses for the network to which the remote access server is attached, verify that the range of IP addresses in the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.

Miscellaneous Remote Access Problems

  • Callback Is Not Working

    Verify that callback is enabled on the dial-in properties of the user account. Also verify that LCP Extensions is enabled on the PPP tab on the properties of a remote access router using the Routing and Remote Access snap-in.


Troubleshooting Tools

The following tools, which enable you to gather additional information on the source of your problem, are included with Windows 2000.

remote access Event Logging

On the remote access Event logging tab on the properties of a remote access router, there are four levels of logging. Select Log the maximum amount of information and try the connection again. After the connection fails, check the system event log for events logged during the connection process. After you are done viewing remote access events, select the Log errors and warnings option on the remote access Event logging tab.

Network Monitor

Network Monitor is a packet capture and analysis tool that you can use to view the traffic sent between a remote access server and remote access client during the remote access connection process and during data transfer. Network Monitor does not interpret the compressed or encrypted portions of remote access traffic.

The proper interpretation of the remote access traffic with Network Monitor requires an understanding of PPP protocols described in this chapter and the referenced RFCs. Network Monitor captures can be saved as files and sent to Microsoft Product Support Services (PSS) for analysis.

Tracing

Tracing records the sequence of programming functions called during a process, either to a console window or to a file. Enable tracing for remote access components and try the connection again. After you are done viewing the traced information, reset the tracing settings back to their default values.

The tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft PSS engineers, or to network administrators who are very experienced with the routing and remote access server. The tracing information can be saved as files and sent to Microsoft PSS for analysis.


Virtual Private Networking

Microsoft® Windows® 2000 includes extensive support for virtual private networking technology, which leverages the IP connectivity of the Internet to connect remote clients and remote offices. As a network professional, you should understand the important uses of virtual private networking for your organization and the underlying technologies that make it work: the Point-to-Point Tunneling Protocol (PPTP), the Layer Two Tunneling Protocol (L2TP), virtual private networks and security, virtual private networks and routing and translation, virtual private networks and firewalls, and the troubleshooting of virtual private network connections. You should already be familiar with TCP/IP, IP routing, IP Security (IPSec), and the Windows 2000 remote access server.

In This Chapter

Virtual Private Networking Overview

Point-to-Point Tunneling Protocol

Layer Two Tunneling Protocol and Internet Protocol Security

VPN Security

Addressing and Routing for VPNs

VPNs and Firewalls

VPNs and Network Address Translators

Pass-Through VPN Scenario

Troubleshooting VPNs

Related Chapters in the Resource Kit

  • For more information about TCP/IP, see “Introduction to TCP/IP” in the Microsoft® Windows® 2000 TCP/IP Core Networking Guide.
  • For more information about IPSec, see “Internet Protocol Security” in the Microsoft® Windows® 2000 TCP/IP Core Networking Guide.
  • For more information about unicast IP routing, see “Unicast IP Routing” in this book.
  • For more information about demand-dial routing, see “Demand-Dial Routing” in this book.
  • For more information about the Windows 2000 remote access server, see “Remote Access Server” in this book.


Virtual Private Networking Overview

A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. A VPN enables you to send data between two computers across a shared or public internetwork in a manner that emulates the properties of a point-to-point private link. The act of configuring and creating a virtual private network is known as virtual private networking.

To emulate a point-to-point link, data is encapsulated, or wrapped, with a header that provides routing information allowing it to traverse the shared or public internetwork to reach its endpoint. To emulate a private link, the data being sent is encrypted for confidentiality. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is known as a virtual private network (VPN) connection.

Figure 9.1 illustrates the logical concept of a VPN.

Figure 9.1 Virtual Private Network (VPN)

VPN connections allow users working at home or on the road to obtain a remote access connection to an organization server using the infrastructure provided by a public internetwork such as the Internet. From the user’s perspective, the VPN is a point-to-point connection between the computer, the VPN client, and an organization server, the VPN server. The exact infrastructure of the shared or public network is irrelevant because it appears logically as if the data is sent over a dedicated private link.

VPN connections also allow organizations to have routed connections with geographically separate offices or with other organizations over a public internetwork such as the Internet while maintaining secure communications. A routed VPN connection across the Internet logically operates as a dedicated WAN link.

With both the remote access connection and with the routed connection, VPN connections allow an organization to trade in long distance dial-up or leased lines for local dial-up or leased lines to an Internet service provider (ISP).


Elements of a VPN Connection

A Windows 2000 VPN connection includes the following components as illustrated in Figure 9.2.

VPN server
A computer that accepts VPN connections from VPN clients. A VPN server can provide a remote access VPN connection or a router-to-router VPN connection. For more information, see “VPN Connections” later in this chapter.

VPN client
A computer that initiates a VPN connection to a VPN server. A VPN client can be an individual computer that obtains a remote access VPN connection or a router that obtains a router-to-router VPN connection. Microsoft® Windows NT® version 4.0, Windows 2000, Microsoft® Windows® 95, and Microsoft® Windows® 98–based computers can create remote access VPN connections to a Windows 2000–based VPN server. Microsoft® Windows® 2000 Server and Windows NT Server 4.0–based computers running the Routing and Remote Access Service (Rremote access) can create router-to-router VPN connections to a Windows 2000–based VPN server. VPN clients can also be any non-Microsoft Point-to-Point Tunneling Protocol (PPTP) client or Layer Two Tunneling Protocol (L2TP) client using IPSec.

Tunnel.
The portion of the connection in which your data is encapsulated.

VPN connection
The portion of the connection in which your data is encrypted. For secure VPN connections, the data is encrypted and encapsulated along the same portion of the connection.

Note

It is possible to create a tunnel and send the data through the tunnel without encryption. This is not a VPN connection because the private data is sent across a shared or public network in an unencrypted and easily readable form.

Tunneling protocols
Used to manage tunnels and encapsulate private data. (Data that is tunneled must also be encrypted to be a VPN connection.) Windows 2000 includes the PPTP and L2TP tunneling protocols. For detailed information about these protocols, see “Point-to-Point Tunneling Protocol” and “Layer Two Tunneling Protocol and Internet Protocol Security” later in this chapter.

Tunneled data.
Data that is usually sent across a private point-to-point link.

Transit internetwork.
The shared or public internetwork crossed by the encapsulated data. For Windows 2000, the transit internetwork is always an IP internetwork. The transit internetwork can be the Internet or a private IP-based intranet.

Figure 9.2 Components of a VPN Connection


VPN Connections

Creating the VPN is very similar to establishing a point-to-point connection using dial-up networking and demand-dial routing procedures. There are two types of VPN connections: the remote access VPN connection and the router-to-router VPN connection.

Remote Access VPN Connection

A remote access VPN connection is made by a remote access client, a single user computer, and connects to a private network. The VPN server provides access to the resources of the VPN server or to the entire network to which the VPN server is attached. The packets sent from the remote client across the VPN connection originate at the remote access client computer.

The remote access client (the VPN client) authenticates itself to the remote access server (the VPN server) and, for mutual authentication, the server authenticates itself to the client.

Router-to-Router VPN Connection

A router-to-router VPN connection is made by a router and connects two portions of a private network. The VPN server provides a routed connection to the network to which the VPN server is attached. On a router-to-router VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers.

The calling router (the VPN client) authenticates itself to the answering router (the VPN server), and, for mutual authentication, the answering router authenticates itself to the calling router.


VPN Requirements

For a connection to be a VPN, the following requirements must be met:

  • Encapsulation
  • Authentication
  • Data encryption
  • Address and name server allocation

Encapsulation

VPN technology provides a way of encapsulating the private data with a header that allows it to traverse the transit internetwork.

Authentication

Authentication for VPN connections takes two forms:

  • User authentication. For the VPN connection to be established, the VPN server authenticates the VPN client attempting the connection and verifies that the VPN client has the appropriate permissions. If mutual authentication is being used, the VPN client also authenticates the VPN server, providing protection against masquerading VPN servers.
  • Data authentication and integrity. To verify that the data being sent on the VPN connection originated at the other end of the connection and was not modified in transit, the data can contain a cryptographic checksum based on an encryption key known only to the sender and the receiver.

Data Encryption

To ensure confidentiality of the data as it traverses the shared or public transit internetwork, it is encrypted by the sender and decrypted by the receiver. The encryption and decryption processes depend on both the sender and the receiver having knowledge of a common encryption key.

Intercepted packets sent along the VPN connection in the transit internetwork are unintelligible to anyone who does not have the common encryption key. The length of the encryption key is an important security parameter. Computational techniques can be used to determine the encryption key. Such techniques require more computing power and computational time as the encryption keys get larger. Therefore, it is important to use the largest possible key size.

In addition, the more information that is encrypted with the same key, the easier it is to decipher the encrypted data. With some encryption technologies, you are given the option to configure how often the encryption keys are changed during a connection.

For more information about how encryption keys are managed for the VPN technologies in Windows 2000, see “VPN Security” later in this chapter.

Address and Name Server Allocation

When a VPN server is configured, it creates a virtual interface that represents the interface on which all VPN connections are made. When a VPN client establishes a VPN connection, a virtual interface is created on the VPN client that represents the interface connected to the VPN server. The virtual interface on VPN client is connected to the virtual interface on the VPN server creating the point-to-point VPN connection.

The virtual interfaces of the VPN client and the VPN server must be assigned IP addresses. The assignment of these addresses is done by the VPN server. By default, the VPN server obtains IP addresses for itself and VPN clients using the Dynamic Host Configuration Protocol (DHCP). You can also configure a static pool of IP addresses defined by an IP network ID and a subnet mask.

Name server allocation, the allocation of domain name system (DNS) and Windows Internet Name Service (WINS) servers, also occurs during the VPN connection establishment process. The VPN client obtains the IP addresses of the DNS and WINS servers from the VPN server for the intranet to which the VPN server is attached.


Internet and Intranet-Based VPN Connections

VPN connections can be used whenever a secure point-to-point connection is needed to connect users or networks. Typical VPN connections are either Internet-based or intranet-based.

Internet-Based VPN Connections

Using an Internet-based VPN connection, you can avoid long-distance and 1-800 telephone charges while taking advantage of the global availability of the Internet.

Remote Access over the Internet

Rather than a remote access client having to make a long distance or 1-800 call to a corporate or outsourced network access server (NAS), the client can call a local ISP. By using the established physical connection to the local ISP, the remote access client initiates a VPN connection across the Internet to the organization’s VPN server. Once the VPN connection is created, the remote access client can access the resources of the private intranet.

Figure 9.3 illustrates remote access over the Internet.

Figure 9.3 A VPN Connection Connecting a Remote Client to a Private Intranet

Connecting Networks over the Internet

When networks are connected over the Internet (illustrated in Figure 9.4), a router forwards packets to another router across a VPN connection. To the routers, the VPN operates as a data-link layer link.

Figure 9.4 A VPN Connecting Two Remote Sites Across the Internet

  • Connecting Networks Using Dedicated WAN Links

    Rather than using an expensive long-distance dedicated WAN link between offices, the office routers are connected to the Internet using local dedicated WAN links to a local ISP. A router-to-router VPN connection is then initiated by either router across the Internet. Once connected, routers can forward directed or routing protocol traffic to each other using the VPN connection.

  • Connecting Networks Using Dial-Up WAN Links

    Rather than having a branch office router make a long distance or 1-800 call to a corporate or outsourced NAS, the branch office router calls a local ISP. Using the established connection to the local ISP, a router-to-router VPN connection is initiated by the branch office router to the corporate hub router across the Internet. The corporate hub router acting as a VPN server must be connected to a local ISP using a dedicated WAN link.

    For more information about configuring VPN connections using a dial-up connection to a local ISP, see “Addressing and Routing for VPNs” later in this chapter.

It is possible to have both offices connected to the Internet using a dial-up WAN link. However, this is only feasible if the ISP supports demand-dialing routing to customers; the ISP calls the customer router when an IP datagram is to be delivered to the customer. Demand-dial routing to customers is not widely supported by ISPs.

Intranet-Based VPN Connections

The intranet-based VPN connection takes advantage of IP connectivity in an organization intranet.

Remote Access over an Intranet

In some organization intranets, the data of a department, such as a human resources department, is so sensitive that the department’s network segment is physically disconnected from the rest of the organization’s intranet. While this protects the department’s data, it creates information accessibility problems for those users not physically connected to the separate network segment.

VPN connections allow the sensitive department’s network segment to be physically connected to the organization intranet but separated by a VPN server. The VPN server does not provide a direct routed connection between the corporate intranet and the separate network segment. Users on the corporate intranet with the appropriate permissions can establish a remote access VPN connection with the VPN server and can gain access to the protected resources of the sensitive department’s network. Additionally, all communication across the VPN connection is encrypted for data confidentiality. For those users who do not have permissions to establish a VPN connection, the separate network segment is hidden from view.

Figure 9.5 illustrates remote access over an intranet.

Figure 9.5 A VPN Connection Allowing Remote Access to a Secured Network over an Intranet

Connecting Networks over an Intranet

You can also connect two networks over an intranet using a router-to-router VPN connection. This type of VPN connection might be necessary, for example, for two departments in separate locations, whose data is highly sensitive, to communicate with each other. For instance, the finance department might need to communicate with the human resources department to exchange payroll information.

The finance department and the human resources department are connected to the common intranet with computers that can act as VPN clients or VPN servers. Once the VPN connection is established, users on computers on either network can exchange sensitive data across the corporate intranet.

Figure 9.6 illustrates networks connected over an intranet.

Figure 9.6 A VPN Connection Connecting Two Networks over an Intranet

Combined Internet and Intranet VPN Connections

A VPN connection is a networking tool that can provide secured point-to-point connections in whatever manner you see fit. A less common combined Internet and intranet VPN connection, called a pass-through VPN connection, illustrated in Figure 9.7, allows a remote access client connected to one company’s intranet to access the resources of another company’s intranet using the Internet. In this scenario, a remote access VPN connection passes through one intranet and the Internet to access a second intranet.

Figure 9.7 Pass-Through VPN Connection

For more information about pass-through VPNs, see “Pass-Through VPN Scenario” later in this chapter.


Managing Virtual Private Networking

Virtual private networking must be managed just like any other network resource, and VPN security issues, particularly with Internet VPN connections, must be addressed carefully. Consider the following questions:

  • Where is the user account data to be stored?
  • How are addresses assigned to VPN clients?
  • Who is allowed to create VPN connections?
  • How does the VPN server verify the identity of the user attempting the VPN connection?
  • How does the VPN server record the VPN activity?
  • How can the VPN server be managed using industry-standard network management protocols and infrastructure?

Managing Users

Because it is administratively unsupportable to have separate user accounts on separate servers for the same user and try to keep them all simultaneously current, most administrators set up a master account database at the primary domain controller (PDC) or on a Remote Authentication Dial-in User Service (RADIUS) server. This allows the VPN server to send the authentication credentials to a central authenticating device. The same user account is used for both dial-in remote access and VPN-based remote access.

Managing Addresses and Name Servers

The VPN server must have IP addresses available in order to allocate them to the VPN server’s virtual interface and to VPN clients during the IP Control Protocol (IPCP) negotiation phase of the connection establishment process. The IP address allocated to the VPN client is assigned to the virtual interface of the VPN client.

For Windows 2000–based VPN servers, the IP addresses allocated to VPN clients are obtained through DHCP by default. You can also configure a static IP address pool.

The VPN server must also be configured with DNS and WINS server addresses to allocate to the VPN client during IPCP negotiation. For more information about how the VPN server allocates the IP addresses of DNS and WINS servers, see “Remote Access Server” in this book.

Managing Access

For Windows 2000, you configure the dial-in properties on user accounts and remote access policies to manage access for dial-up networking and VPN connections.

Access by User Account

If you are managing remote access on a user basis, set the remote access permission on those user accounts that are allowed to create VPN connections to Allow access. If the VPN server is only allowing VPN connections, delete the default remote access policy called Allow access if dial-in permission is enabled. Then create a new remote access policy with a descriptive name such as VPN access if allowed by user account.

If the VPN server is also allowing dial-up remote access services, do not delete the default policy, but move it so that it is the last policy to be evaluated.

As an example of typical settings, configure the remote access policy permission to Deny remote access permission and set the conditions and profile settings as listed in Tables 9.1 and 9.2. For detailed information about configuring these settings, see Windows 2000 Server Help.

Table 9.1 Remote Access Policy Conditions for VPN Access by User Account

Conditions | Setting
NAS-Port-Type | Virtual
Called-Station-ID | IP address of the VPN server interface accepting VPN connections

Table 9.2 Remote Access Policy Profile Settings for VPN Access by User Account

Profile settings | Setting
Authentication tab | Enable Extensible Authentication Protocol. Select Smartcard or other certificate (TLS). Enable Microsoft Encrypted Authentication (MS-CHAP).
Encryption tab | Select Require encryption. Select Automatic (as negotiated with client).

Access by Group Membership

If you are managing remote access on a group basis, set the remote access permission on all user accounts to Control access through remote access policy. Create a Windows 2000 group with members who are allowed to create VPN connections. If the VPN server only allows VPN connections, delete the default remote access policy called Allow access if dial-in permission is enabled. Then create a new remote access policy with a descriptive name such as VPN access if member of VPN-allowed group.

If the VPN server also allows dial-up networking remote access services, do not delete the default policy but move it so that it is the last policy to be evaluated.

As an example of typical settings, configure the remote access policy permission to Grant remote access permission and set the conditions and profile settings as listed in Tables 9.3 and 9.4. For detailed information about configuring these settings, see Windows 2000 Server Help.

Table 9.3 Remote Access Policy Conditions for VPN Access by Windows 2000 Group

Conditions | Setting
NAS-Port-Type | Virtual
Called-Station-ID | IP address of the VPN server interface accepting VPN connections
Windows-2000-Groups | Windows 2000 group whose members are allowed to create VPN connections

Table 9.4 Remote Access Policy Profile Settings for VPN Access by Windows 2000 Group

Profile settings | Setting
Authentication tab | Enable Extensible Authentication Protocol. Select Smartcard or other certificate (TLS). Enable Microsoft Encrypted Authentication (MS-CHAP).
Encryption tab | Select Require encryption. Select Automatic (as negotiated with client).

Managing Authentication

The VPN server can be configured to use either Windows 2000 or RADIUS as an authentication provider. If Windows 2000 is selected as the authentication provider, the user credentials sent by users attempting VPN connections are authenticated using typical Windows 2000 authentication mechanisms.

If RADIUS is selected and configured as the authentication provider on the VPN server, user credentials and parameters of the connection request are sent as a series of RADIUS request messages to a RADIUS server.

The RADIUS server receives a user-connection request from the VPN server and authenticates the user using its authentication database. A RADIUS server can also maintain a central storage database of other relevant user properties. In addition to a yes or no response to an authentication request, RADIUS can inform the VPN server of other applicable connection parameters for this user—such as maximum session time, static IP address assignment, and so on.

RADIUS can respond to authentication requests based on its own database, or it can be a front end to another database server such as a generic Open Database Connectivity (ODBC) server or a Windows 2000 PDC. The latter could be located on the same computer as the RADIUS server, or elsewhere. In addition, a RADIUS server can act as a proxy client to a remote RADIUS server.

The RADIUS protocol is described in RFC 2138 and RFC 2139. For more information about the RADIUS protocol and the Windows 2000–based RADIUS server known as Internet Authentication Services, see “Internet Authentication Services” in this book.

Managing Accounting

You can configure the VPN server to use either Windows 2000 or RADIUS as an accounting provider. If you select Windows 2000 as the accounting provider, the accounting information accumulates on the VPN server for later analysis. If you select RADIUS, RADIUS accounting messages are sent to the RADIUS server for accumulation and later analysis.

You can configure most RADIUS servers to place authentication request records into an accounting file. A number of third parties have written billing and audit packages that read RADIUS accounting records and produce various useful reports. For more information about RADIUS accounting, see RFC 2139.

Network Management

The computer acting as the VPN server can participate in a Simple Network Management Protocol (SNMP) environment as an SNMP agent if the Windows 2000 SNMP Service is installed. The VPN server records management information in various object identifiers of the Internet Management Information Base (MIB) II, which is installed with the Windows 2000 SNMP service. Objects in the Internet MIB II are documented in RFC 1213.


Point-to-Point Tunneling Protocol

The Point-to-Point Tunneling Protocol (PPTP) encapsulates Point-to-Point Protocol (PPP) frames into IP datagrams for transmission over an IP-based internetwork such as the Internet or a private intranet.

Note

PPTP is documented in "Point-to-Point Tunneling Protocol," an Internet draft titled “pptp-draft-ietf-ppext-pptp-x.txt” where x denotes the current version of the draft. This Internet draft was submitted to the Internet Engineering Task Force (IETF) by the companies of the PPTP Forum, which include Microsoft Corporation, Ascend Communications, 3Com, ECI Telematics, and US Robotics (now 3Com). Internet draft documents are works in progress. See www.ietf.org for copies of Internet drafts.

The PPTP uses a TCP connection known as the PPTP control connection to create, maintain, and terminate the tunnel and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames as tunneled data. The payloads of the encapsulated PPP frames can be encrypted or compressed or both.

PPTP assumes the availability of an IP internetwork between a PPTP client (a tunnel client using the PPTP tunneling protocol) and a PPTP server (a tunnel server using the PPTP tunneling protocol). The PPTP client might already be attached to an IP internetwork that can reach the PPTP server, or the PPTP client might have to dial into a network access server (NAS) to establish IP connectivity as in the case of dial-up Internet users.

Authentication that occurs during the creation of a PPTP-based VPN connection uses the same authentication mechanisms as PPP connections, such as Extensible Authentication Protocol (EAP), Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP), CHAP, Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP). PPTP inherits encryption or compression, or both, of PPP payloads from PPP. For Windows 2000, either EAP-Transport Level Security (EAP-TLS) or MS-CHAP must be used in order for the PPP payloads to be encrypted using Microsoft Point-to-Point Encryption (MPPE).

MPPE provides only link encryption, not end-to-end encryption. End-to-end encryption is data encryption between the client application and the server hosting the resource or service being accessed by the client application. If end-to-end encryption is required, IPSec can be used to encrypt IP traffic from end-to-end after the PPTP tunnel is established.

For Internet-based PPTP servers, the PPTP server is a PPTP-enabled VPN server with one interface on the Internet and a second interface on the intranet.

Tunnel Maintenance with the PPTP Control Connection

The PPTP control connection is between the IP address of the PPTP client using a dynamically allocated TCP port and the IP address of the PPTP server using the reserved TCP port 1723. The PPTP control connection carries the PPTP call control and management messages that are used to maintain the PPTP tunnel. This includes the transmission of periodic PPTP Echo_Request and PPTP Echo_Reply messages to detect a connectivity failure between the PPTP client and PPTP server. PPTP control connection packets consist of an IP header, a TCP header, and a PPTP control message as illustrated in Figure 9.8. The PPTP control connection packet in Figure 9.8 also includes a data-link layer header and trailer.

Figure 9.8 PPTP Control Connection Packet

Table 9.5 lists the primary PPTP control messages that are sent over the PPTP control connection. For all of the PPTP control messages, the specific PPTP tunnel is identified by the TCP connection.

Table 9.5 PPTP Call Control and Connection Management Messages

Message Type | Purpose
Start-Control-Connection-Request | Sent by the PPTP client to establish the control connection. Each PPTP tunnel requires a control connection to be established before any other PPTP messages can be issued.
Start-Control-Connection-Reply | Sent by the PPTP server to reply to the Start-Control-Connection-Request message.
Outgoing-Call-Request | Sent by the PPTP client to create a PPTP tunnel. Included in the Outgoing-Call-Request message is a Call-ID that is used in the GRE header to identify the tunneled traffic of a specific tunnel.
Outgoing-Call-Reply | Sent by the PPTP server in response to the Outgoing-Call-Request message.
Echo-Request | Sent by either the PPTP client or PPTP server as a keep-alive mechanism. If the Echo-Request is not answered, the PPTP tunnel is eventually terminated.
Echo-Reply | The reply to an Echo-Request. Note: The PPTP Echo-Request and Echo-Reply messages are not related to the ICMP Echo Request and Echo Reply messages.
WAN-Error-Notify | Sent by the PPTP server to all VPN clients to indicate error conditions on the PPP interface of the PPTP server.
Set-Link-Info | Sent by the PPTP client or PPTP server to set PPP-negotiated options.
Call-Clear-Request | Sent by the PPTP client indicating that a tunnel is to be terminated.
Call-Disconnect-Notify | Sent by the PPTP server in response to a Call-Clear-Request or for other reasons to indicate that a tunnel is to be terminated. If the PPTP server terminates the tunnel, a Call-Disconnect-Notify is sent.
Stop-Control-Connection-Request | Sent by the PPTP client or the PPTP server to inform the other that the control connection is being terminated.
Stop-Control-Connection-Reply | Used to reply to the Stop-Control-Connection-Request message.

For the exact structure of PPTP control connection messages, see the PPTP Internet draft.

PPTP Data Tunneling

PPTP data tunneling is performed through multiple levels of encapsulation.

Figure 9.9 shows the resulting structure of PPTP tunneled data.

Figure 9.9 PPTP Tunneled Data

Encapsulation of PPP Frame

The initial PPP payload is encrypted and encapsulated with a PPP header to create a PPP frame. The PPP frame is then encapsulated with a modified GRE header. GRE is documented in RFC 1701 and RFC 1702 and was designed to provide a simple, lightweight, general purpose mechanism to encapsulate data sent over IP internetworks. GRE is a client protocol of IP using IP protocol 47.

For PPTP, the GRE header is modified in the following ways:

  • An acknowledgement bit is used to indicate that a 32-bit acknowledgement field is present and significant.
  • The Key field is replaced with a 16-bit Payload Length field and a 16-bit Call ID field. The Call ID field is set by the PPTP client during the creation of the PPTP tunnel.
  • A 32-bit Acknowledgement field is added.

Within the GRE header, the Protocol Type is set to 0x880B, the EtherType value for a PPP frame.

Note

GRE is sometimes used by ISPs to forward routing information within an ISP’s network. To prevent the routing information from being forwarded to Internet backbone routers, ISPs filter out GRE traffic on the interfaces connected to the Internet backbone. As a result of this filtering, PPTP tunnels can be created using PPTP control messages, but PPTP tunneled data is not forwarded. If you suspect that this is a problem, contact your ISP.

Encapsulation of GRE Packet

The resulting GRE and PPP encapsulated payload is then encapsulated with an IP header containing the appropriate source and destination IP addresses for the PPTP client and PPTP server.

Data-Link Layer Encapsulation

To be sent on a LAN or WAN link, the IP datagram is finally encapsulated with a header and trailer for the data-link layer technology of the outgoing physical interface. For example, when IP datagrams are sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP datagrams are sent over a point-to-point WAN link such as an analog phone line or ISDN, the IP datagram is encapsulated with a PPP header and trailer.

Processing of the PPTP Tunneled Data

Upon receipt of the PPTP tunneled data, the PPTP client or PPTP server:

  1. Processes and removes the data-link header and trailer.
  2. Processes and removes the IP header.
  3. Processes and removes the GRE and PPP headers.
  4. Decrypts or decompresses, or both, the PPP payload (if needed).
  5. Processes the payload for receipt or forwarding.

PPTP Packets and Windows 2000 Networking Architecture

Figure 9.10 illustrates the path that tunneled data takes through the Windows 2000 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline this process:

  1. An IP datagram, IPX datagram, or NetBEUI frame is submitted by its appropriate protocol to the virtual interface that represents the VPN connection using NDIS.
  2. NDIS submits the packet to NDISWAN, which encrypts or compresses the data, or both, and provides a PPP header consisting of only the PPP Protocol ID field. No Flags or Frame Check Sequence (FCS) fields are added. This assumes that address and control field compression were negotiated during the Link Control Protocol (LCP) phase of the PPP connection process. For more information about PPP and LCP, see “Remote Access Server” in this book.
  3. NDISWAN submits the data to the PPTP protocol driver, which encapsulates the PPP frame with a GRE header. In the GRE header, the Call ID is set to the appropriate value to identify the tunnel.
  4. The PPTP protocol driver then submits the resulting packet to the TCP/IP protocol driver.
  5. The TCP/IP protocol driver encapsulates the PPTP tunneled data with an IP header and submits the resulting packet to the interface that represents the dial-up connection to the local ISP using NDIS.
  6. NDIS submits the packet to NDISWAN, which provides PPP headers and trailers.
  7. NDISWAN submits the resulting PPP frame to the appropriate WAN miniport driver representing the dial-up hardware (for example, the asynchronous port for a modem connection).

Figure 9.10 PPTP Packet Development

Note

It is possible to negotiate an encrypted PPP connection for the dial-up connection with the ISP. This is unnecessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted. The additional level of encryption is not needed and can impact performance.


Layer Two Tunneling Protocol and Internet Protocol Security

Layer Two Tunneling Protocol (L2TP) is a combination of PPTP and Layer 2 Forwarding (L2F), a technology proposed by Cisco Systems, Inc. Rather than having two incompatible tunneling protocols competing in the marketplace and causing customer confusion, the IETF mandated that the two technologies be combined into a single tunneling protocol that represents the best features of PPTP and L2F.

Note

L2TP is documented in "Layer Two Tunneling Protocol - ‘L2TP’," an Internet draft titled draft-ietf-pppext-l2tp-x.txt where x denotes the current version of the draft.

L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or ATM networks. Currently, only L2TP over IP networks is defined. When sent over an IP internetwork, L2TP frames are encapsulated as UDP messages. L2TP can be used as a tunneling protocol over the Internet or over private intranets.

L2TP uses UDP messages over IP internetworks for both tunnel maintenance and tunneled data. The payloads of encapsulated PPP frames can be encrypted or compressed, or both; however, Windows 2000 L2TP clients do not negotiate the use of MPPE for L2TP connections. Encryption for L2TP connections is provided by IPSec ESP.

It is possible to create L2TP connections in Windows 2000 that are not encrypted by IPSec. However, this is not a VPN connection because the private data being encapsulated by L2TP is not encrypted. Non-encrypted L2TP connections can be used temporarily to troubleshoot an L2TP over IPSec connection by eliminating the IPSec authentication and negotiation process.

L2TP assumes the availability of an IP internetwork between a L2TP client (a tunnel client using the L2TP tunneling protocol and IPSec) and a L2TP server (a tunnel server using the L2TP tunneling protocol and IPSec). The L2TP client might already be attached to an IP internetwork that can reach the L2TP server, or the L2TP client might have to dial into a NAS to establish IP connectivity as in the case of dial-up Internet users.

Authentication that occurs during the creation of L2TP tunnels must use the same authentication mechanisms as PPP connections such as EAP, MS-CHAP, CHAP, SPAP, and PAP.

For Internet-based L2TP servers, the L2TP server is a L2TP-enabled dial-up server with one interface on the external network, the Internet, and a second interface on the target private network.

L2TP tunnel maintenance and tunneled data have the same packet structure.

Tunnel Maintenance with L2TP Control Messages

Unlike PPTP, L2TP tunnel maintenance is not performed over a separate TCP connection. L2TP call control and management traffic is sent as UDP messages between the L2TP client and the L2TP server. In Windows 2000, the L2TP client uses UDP port 1701 and the L2TP server uses UDP port 1701.

Note

The L2TP client and L2TP server in Windows 2000 always use UDP port 1701. The Windows 2000 L2TP server supports L2TP clients that use a UDP port other than 1701.

L2TP control messages over IP are sent as UDP datagrams. In the Windows 2000 implementation, L2TP control messages sent as UDP datagrams are sent as the encrypted payload of IPSec ESP as illustrated in Figure 9.11.

Figure 9.11 L2TP Control Messages

Because a TCP connection is not used, L2TP uses message sequencing to ensure delivery of L2TP messages. Within the L2TP control message, the Next-Received field (similar to the TCP Acknowledgment field) and the Next-Sent field (similar to the TCP Sequence Number field) are used to maintain the sequence of control messages. Out-of-sequence packets are dropped. The Next-Sent and Next-Received fields can also be used for sequenced delivery and flow control for tunneled data.

L2TP supports multiple calls for each tunnel. In the L2TP control message and the L2TP header for tunneled data is a Tunnel ID that identifies the tunnel and a Call ID that identifies a call within the tunnel.

Table 9.6 lists the primary L2TP control messages

Table 9.6 L2TP Control Messages

Message Type | Purpose
Start-Control-Connection-Request | Sent by the L2TP client to establish the control connection. Each L2TP tunnel requires a control connection to be established before any other L2TP messages can be issued. It includes an Assigned Tunnel-ID that is used to identify the tunnel.
Start-Control-Connection-Reply | Sent by the L2TP server to reply to the Start-Control-Connection-Request message.
Start-Control-Connection-Connected | Sent in reply to a Start-Control-Connection-Reply message to indicate that the tunnel establishment was successful.
Outgoing-Call-Request | Sent by the L2TP client to create an L2TP tunnel. Included in the Outgoing-Call-Request message is an Assigned Call-ID that is used to identify a call within a specific tunnel.
Outgoing-Call-Reply | Sent by the L2TP server in response to the Outgoing-Call-Request message.
Start-Control-Connection-Connected | Sent in reply to a received Outgoing-Call-Reply message to indicate that the call was successful.
Hello | Sent by either the L2TP client or L2TP server as a keep-alive mechanism. If the Hello is not acknowledged, the L2TP tunnel is eventually terminated.
WAN-Error-Notify | Sent by the L2TP server to all VPN clients to indicate error conditions on the PPP interface of the L2TP server.
Set-Link-Info | Sent by the L2TP client or L2TP server to set PPP-negotiated options.
Call-Disconnect-Notify | Sent by either the L2TP server or L2TP client to indicate that a call within a tunnel is to be terminated.
Stop-Control-Connection-Notification | Sent by either the L2TP server or L2TP client to indicate that a tunnel is to be terminated.

For the exact structure of L2TP control messages, please see the L2TP Internet draft.

L2TP Data Tunneling

L2TP data tunneling is performed through multiple levels of encapsulation.

Figure 9.12 shows the resulting structure of L2TP over IPSec tunneled data.

Figure 9.12 L2TP Packet Encapsulation

L2TP Encapsulation

The initial PPP payload is encapsulated with a PPP header and an L2TP header.

UDP Encapsulation

The L2TP encapsulated packet is then encapsulated with a UDP header with the source and destination ports set to 1701.

IPSec Encapsulation

Based on IPSec policy, the UDP message is encrypted and encapsulated with an IPSec ESP header and trailer and an IPSec Auth trailer.

IP Encapsulation

The IPSec packet is encapsulated with a final IP header containing the source and destination IP addresses of the VPN client and VPN server.

Data-Link Layer Encapsulation

To be sent on a LAN or WAN link, the IP datagram is finally encapsulated with a header and trailer for the data-link layer technology of the outgoing physical interface. For example, when IP datagrams are sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP datagrams are sent over a point-to-point WAN link such as an analog phone line or ISDN, the IP datagram is encapsulated with a PPP header and trailer.

De-Encapsulation of L2TP over IPSec Tunneled Data

Upon receipt of the L2TP over IPSec tunneled data, the L2TP client or L2TP server:

  1. Processes and removes the data-link header and trailer.
  2. Processes and removes the IP header.
  3. Uses the IPSec ESP Auth trailer to authenticate the IP payload and the IPSec ESP header.
  4. Uses the IPSec ESP header to decrypt the encrypted portion of the packet.
  5. Processes the UDP header and sends the L2TP packet to L2TP.
  6. L2TP uses the Tunnel ID and Call ID in the L2TP header to identify the specific L2TP tunnel.
  7. Uses the PPP header to identify the PPP payload and forward it to the proper protocol driver for processing.

L2TP over IPSec Packets and Windows 2000 Networking Architecture

Figure 9.13 illustrates the path that tunneled data takes through the Windows 2000 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline the process:

  1. An IP datagram, IPX datagram, or NetBEUI frame is submitted by the appropriate protocol to the virtual interface that represents the VPN connection using NDIS.
  2. NDIS submits a packet to NDISWAN, which optionally compresses and provides a PPP header consisting of only the PPP Protocol ID field. No Flags or FCS fields are added.
  3. NDISWAN submits the PPP frame to the L2TP protocol driver, which encapsulates the PPP frame with a L2TP header. In the L2TP header, the Tunnel ID and the Call ID are set to the appropriate value identifying the tunnel.
  4. The L2TP protocol driver then submits the resulting packet to the TCP/IP protocol driver with information to send the L2TP packet as a UDP message from UDP port 1701 to UDP port 1701with the IP addresses of the VPN client and the VPN server.
  5. The TCP/IP protocol driver constructs an IP packet with the appropriate IP header and UDP header. IPSec then analyzes the IP packet and matches it with a current IPSec policy. Based on the settings in the policy, IPSec encapsulates and encrypts the UDP message portion of the IP packet using the appropriate ESP and Auth headers and trailers.

    The original IP header with the Protocol field set to 50 is added to the front of the ESP encapsulated packet.

    The TCP/IP protocol driver then submits the resulting packet to the interface that represents the dial-up connection to the local ISP using NDIS.

  6. NDIS submits the packet to NDISWAN.
  7. NSIDWAN provides PPP headers and trailers and submits the resulting PPP frame to the appropriate WAN miniport driver representing the dial-up hardware.

Figure 9.13 L2TP Packet Development

Note

It is possible to negotiate an encrypted PPP connection for the dial-up connection with the ISP. This is not necessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted with IPSec. The additional level of encryption is not needed and can impact performance.


VPN Security

Security is a vital part of a VPN. Described in the following sections are the security facilities of PPTP and L2TP over IPSec VPN connections.


PPTP Connections

PPTP offers user authentication and encryption.

User Authentication with PPP

The user attempting the PPTP connection is authenticated using PPP-based user authentication protocols such as EAP, MS-CHAP, CHAP, SPAP, and PAP. For PPTP connections, EAP-TLS using smart cards or MS-CHAP version 2 is highly recommended as they provide mutual authentication and are the most secure methods of exchanging credentials.

Encryption with MPPE

PPTP inherits MPPE encryption, which uses the RSA RC4 stream cipher. MPPE is only available when either the EAP-TLS or MS-CHAP (version 1 or version 2) authentication protocols are used.

MPPE can use either 40-bit or 128-bit encryption keys. The 40-bit key is designed for international use and adheres to United States encryption export laws. The 128-bit key is designed for North American use. By default, the highest key strength supported by the VPN client and VPN server is negotiated during the connection establishment process. If the VPN server requires a higher key strength than is supported by the VPN client, the connection attempt is rejected.

MPPE was originally designed for encryption across a point-to-point link where packets arrive in the same order in which they were sent with little packet loss. For this environment, the decryption of each packet depends on the decryption of the previous packet.

However, for VPNs, IP datagrams sent across the Internet can arrive in a different order from the one in which they were sent, and a higher proportion of packets can be lost. Therefore, MPPE for VPN connections changes the encryption key for each packet. The decryption of each packet is independent of the previous packet. MPPE includes a sequence number in the MPPE header. If packets are lost or arrive out of order, the encryption keys are changed relative to the sequence number.

PPTP Packet Filtering

A PPTP-based VPN server typically has two physical interfaces: one interface on the shared or public network like the Internet, and another on the private intranet. It also has a virtual interface connecting to all VPN clients. For the VPN server to forward traffic between VPN clients, IP forwarding must be enabled on all interfaces. However, enabling forwarding between the two physical interfaces causes the VPN server to route all IP traffic from the shared or public network to the intranet. To protect the intranet from all traffic not sent by a VPN client, PPTP packet filtering must be configured so that the VPN server only performs routing between VPN clients and the intranet and not between potentially malicious users on the shared or public network and the intranet.

PPTP packet filtering can be configured on either the VPN server or on an intermediate firewall. For more information, see “VPNs and Firewalls” later in this chapter.


L2TP over IPSec Connections

L2TP over IPSec offers user authentication, mutual computer authentication, encryption, data authentication, and data integrity.

User Authentication with L2TP over IPSec

Authentication of the VPN client occurs at two different levels: the computer is authenticated, and then the user is authenticated.

IPSec Computer Authentication

Mutual computer authentication of the VPN client and the VPN server is performed when you establish an IPSec ESP security association (SA) through the exchange of computer certificates. IPSec Phase I and Phase II negotiation occurs, and an IPSec SA is established with an agreed encryption algorithm, hash algorithm, and encryption keys.

To use L2TP over IPSec, a computer certificate must be installed on both the VPN client and the VPN server. You can obtain computer certificates automatically by configuring an auto-enrollment Windows 2000 Group Policy or manually through the browsing of the certificate authority with Microsoft® Internet Explorer. For more information, see Windows 2000 Server Help.

L2TP User-Level Authentication

The user attempting the PPTP connection is authenticated using PPP-based user authentication protocols such as EAP, MS-CHAP, CHAP, SPAP, and PAP. Because the PPP connection establishment process is encrypted by IPSec, any PPP authentication method can be used. Mutual user-level authentication occurs if you use MS-CHAP v2 or EAP-TLS.

Encryption with L2TP over IPSec

Encryption is determined by the establishment of the IPSec SA. The available encryption algorithms include:

  • Data Encryption Standard (DES) with a 40-bit key, which is designed for international use and adheres to United States export encryption laws.
  • DES with a 56-bit key, which is designed for North American use.
  • Triple DES (3DES), which uses two 56-bit keys and is designed for high-security environments in North America.

Because IPSec was designed for IP internetworks where packets could be lost and arrive out of order, each IPSec packet is decrypted independent of other IPSec packets.

The initial encryption keys are derived from the IPSec authentication process. By default, new encryption keys are generated after each hour or 500 megabytes of data transferred. For more information about IPSec, see “Internet Protocol Security” in the Microsoft® Windows® 2000 TCP/IP Core Networking book.

Data Authentication and Integrity with L2TP over IPSec

Data authentication and integrity is provided by one of the following:

  • The hash message authentication code (HMAC) Message Digest 5 (MD5): a hash algorithm producing a 128-bit hash of the authenticated payload.
  • The HMAC Secure Hash Algorithm (SHA): a hash algorithm producing a 160-bit hash of the authenticated payload.

L2TP over IPSec Packet Filtering

Just as in PPTP-based VPN connections, the enabling of forwarding between the interfaces on the public or shared network and the intranet causes the VPN server to route all IP traffic from the shared or public network to the intranet. To protect the intranet from all traffic not sent by a VPN client, you must configure L2TP over IPSec packet filtering so that the VPN server only performs routing between VPN clients and the intranet and not between potentially malicious users on the shared or public network and the intranet.

L2TP over IPSec packet filtering can be configured on either the VPN server or on an intermediate firewall. For more information, see “VPNs and Firewalls” later in this chapter.


Addressing and Routing for VPNs

To understand how VPNs work, you must understand how addressing and routing is affected by the creation of remote access VPNs and router-to-router VPNs. A VPN connection creates a virtual interface that must be assigned a proper IP address, and routes must be changed or added to ensure that the proper traffic is sent across the secure VPN connection instead of the shared or public transit internetwork.


Remote Access VPN Connections

For remote access VPN connections, a computer creates a remote access connection to a VPN server. During the connection process the VPN server allocates an IP address for the remote access VPN client and changes the default route on the remote client so that default route traffic is sent over the virtual interface.

IP Addresses and the Dial-up VPN Client

For dial-up VPN clients who connect to the Internet before creating a VPN connection with a VPN server on the Internet, two IP addresses are allocated:

  • When creating the PPP connection, IPCP negotiation with the ISP NAS allocates a public IP address.
  • When creating the VPN connection, IPCP negotiation with the VPN server allocates an intranet IP address. The IP address allocated by the VPN server can be a public IP address or private IP address, depending on whether your organization is implementing public or private addressing on its intranet.

In either case, the IP address allocated to the VPN client must be reachable by hosts on the intranet and vice versa. The VPN server must have appropriate entries in its routing table to reach all the hosts on the intranet and the routers of the intranet must have the appropriate entries in their routing tables to reach the VPN clients.

The tunneled data sent through the VPN is addressed from the VPN client’s VPN server-allocated address to an intranet address. The outer IP header is addressed between the ISP-allocated IP address of the VPN client and the public address of the VPN server. Because the routers on the Internet only process the outer IP header, the Internet routers forward the tunneled data to the VPN server’s public IP address.

An example of dial-up client addressing is shown in Figure 9.14 where the organization uses private addresses on the intranet, and the tunneled data is an IP datagram.

Figure 9.14 Public and Private Addresses in PPTP Tunneled Data

Default Routes and Dial-up Clients

When a typical dial-up client dials the ISP, it receives a public IP address from the ISP NAS. A default gateway address is not allocated as part of the IPCP negotiation process. Therefore, in order to reach all Internet addresses, the dial-up client adds a default route to its routing table using the dial-up interface connected to the ISP. As a result, the client can forward the IP datagrams to the ISP NAS from where they are routed to its Internet location.

For dial-up clients with no other TCP/IP interfaces, this is the desired behavior. However, this behavior can cause confusion for dial-up clients that have an existing LAN-based connection to an intranet. In this scenario, a default route already exists pointing to the local intranet router. When the dial-up client creates a connection with their ISP, the original default route remains in the routing table but is changed to have a higher metric. A new default route is added with lower metric using the ISP connection.

As a result, the intranet locations that are not on the dial-up client’s directly attached network are not reachable for the duration of the connection to the ISP. If the new default route is not created, all intranet locations are reachable, but Internet locations are not.

A Windows 2000–based dial-up client creates the default route by default.

To prevent the default route from being created

  • In the properties of the TCP/IP protocol of the dial-up connection object, in the Advanced TCP/IP Settings dialog box, click the General tab, and then clear the Use default gateway on remote network check box.

To achieve connectivity to both intranet and Internet locations while the ISP connection is active, leave the Use default gateway on remote network option selected and add the routes of the intranet to the routing table of the dial-up client. The intranet routes can be added through static persistent routes using the route utility, or, if RIP version 1 is being used as the intranet routing protocol, you can use the Route Listening Service to listen to RIP version 1 routing protocol traffic and dynamically add intranet routes. When connected to the ISP, all intranet locations are reachable using the intranet routes and all Internet locations are reachable using the default route.

Default Routes and VPNs over the Internet

When the dial-up client calls the ISP, it adds a default route using the connection to the ISP as shown in Figure 9.15. At this point, it can reach all Internet addresses through the router at the ISP NAS.

Figure 9.15 Default Route Created When Dialing the ISP

Once the VPN client creates the VPN connection, another default route and a host route to the IP address of the tunnel server are added, as illustrated in Figure 9.16. The previous default route is saved but now has a higher metric. Adding the new default route means that all Internet locations except the IP address of the tunnel server are not reachable for the duration of the VPN connection.

Figure 9.16 Default Route Created When Initiating the VPN

Just as in the case of a dial-up client connecting to the Internet, when a dial-up VPN client using voluntary tunneling creates a VPN connection to a private intranet across the Internet, one of the following occurs:

  • Internet locations are reachable and intranet locations are not reachable when the VPN connection is not active.
  • Intranet locations are reachable and Internet locations are not reachable when the VPN connection is active.

For most Internet-connected VPN clients, this behavior does not represent a problem because they are typically engaged in either intranet or Internet communication, not both.

For VPN clients who want concurrent access to intranet and Internet resources when the VPN is connected, the solution depends on the nature of the IP addressing in the intranet. In all cases, configure the VPN connection object so that it does not add a default gateway. When the VPN connection is created, the default route remains pointed to the ISP NAS, allowing access to all Internet addresses.

Based on the type of intranet addressing you use, enable concurrent access to intranet and Internet resources as follows:

  • Public Address

    Add static persistent routes for the public network IDs of the intranet using the IP address of the VPN server’s virtual interface as the gateway IP address.

  • Private Addresses

    Add static persistent routes for the private network IDs of the intranet using the IP address of the VPN server’s virtual interface as the gateway IP address.

  • Overlapping or Illegal Addresses

    If the intranet is using overlapping or illegal addresses (IP network IDs that are not private and have not been registered by InterNIC or obtained from an ISP), those IP addresses might be duplicated by public addresses on the Internet. If static persistent routes are added on the VPN client for the overlapping network IDs of the intranet, the locations on the Internet for the overlapping addresses are not reachable.

In each of these cases, static persistent routes for the network IDs of the intranet need to be added to the VPN client. Once the persistent routes are added, they are saved in the registry. With Microsoft® Windows NT® version 4.0 Service Pack 3 and later and with Windows 2000, the persistent routes are not actually added to the IP routing table (and are not visible with the route print command at the Windows 2000 command prompt) until the IP address of the gateway is reachable. The IP address of the gateway becomes reachable when the VPN connection is made.

For each route, type the following route utility syntax at a Windows 2000 command prompt:

ROUTE ADD <Intranet Network ID> MASK <NetMask> <IP address of VPN server’s virtual interface> -p

The gateway IP address in the route commands for each intranet route is the IP address assigned to the VPN server’s virtual interface, not the IP address of the VPN server’s Internet interface.

You can determine the IP address of the VPN server’s virtual interface from the IP address of the Internal interface under IP Routing - General in the Routing and Remote Access snap-in. If you use DHCP to obtain IP addresses for dial-up networking and VPN clients, the IP address of the VPN server’s virtual interface is the first IP address obtained when requesting DHCP addresses. If you have configured a static IP address pool, the IP address of the VPN server’s virtual interface is the first IP address in the static IP address pool. You can also determine the IP address of the VPN server’s virtual interface by double-clicking the virtual private networking connection object when the VPN connection is active. In the resulting Status dialog box, click the Details tab.

Caution

For all of these cases, you must add the routes very carefully to ensure that the private traffic to the intranet is forwarded using the VPN connection and not the PPP connection to the ISP. If the wrong routes are added, the traffic that you intend to forward across the VPN in an encrypted form is instead sent unencrypted across the Internet. For example, if your intranet is using the public network ID 207.46.130.0/24 (subnet mask 255.255.255.0), and you mistakenly add a persistent static route for 207.46.131.0/24, all traffic to the intranet network 207.46.130.0/24 is forwarded across the Internet in plaintext, rather than being encrypted and sent across the VPN connection.


Router-to-Router VPN Connections

For router-to-router VPNs, the routing interface used to forward packets is a demand-dial interface configured as follows:

  • On the General tab, type the host name or IP address of the VPN server.
  • On the Security tab, select either Secure my password and data or Custom. If you select Custom, you must also select the appropriate encryption and authentication options.
  • On the Networking tab, select the appropriate server type and protocols to be routed.
  • Under Interface credentials, type the user name, password, and domain name used to verify the VPN client.

The creation of demand-dial interfaces is automated with the Demand Dial Interface Wizard.

The names of the demand-dial interfaces and the calling router credentials must be properly matched to ensure a router-to-router VPN connection. For more information, see “Demand-Dial Routing” in this book.

Temporary vs. Persistent Router-to-Router VPNs

Router-to-router VPN connections can be either temporary or persistent.

Temporary router-to-router VPN connections are made when there are packets to be routed across the VPN demand-dial interface and terminated after a specified amount of idle time. Idle time is configured on both the VPN client (the calling router) and the VPN server (the called router). The default idle time for demand-dial interfaces on the VPN client is unlimited. The default idle time for VPN connections on the VPN server is 20 minutes. Both idle times are configurable. Use temporary router-to-router VPN connections for branch offices who use dial-up connections to their local ISPs.

Persistent router-to-router VPN connections are made when the router is started and remain connected regardless of the traffic being sent. If the VPN connection is terminated, it is automatically attempted again. Use persistent router-to-router VPN connections to connect offices that have permanent connections to the Internet.

To select either a persistent or demand-dial connection

  1. In the Routing and Remote Access snap-in, select Routing Interfaces.
  2. Right-click the demand-dial interface object, and then select Properties.
  3. On the Options tab, under Connection Type, select either Demand dial or Persistent.

VPNs Using Dial-Up ISP Connections

When both the VPN server and the VPN client are directly connected to the Internet using a permanent WAN link such as T1 or Frame Relay, the VPN connection can be persistent and available 24 hours a day. However, when a permanent WAN link is not possible or practical, you can configure an on-demand router-to-router VPN connection using a dial-up ISP.

An on-demand router-to-router VPN connection using a dial-up ISP connection consists of two demand-dial interfaces:

  • A demand-dial interface to dial-in to a local ISP.
  • A demand-dial interface for the router-to-router VPN connection.

An on-demand router-to-router VPN connection is automatically established when traffic to be forwarded across the VPN connection is received by the branch office router. For example, when receiving a packet to be routed to the corporate office, the branch office router first uses a dial-up link to connect to a local ISP. Once the Internet connection is made, the branch office router, the VPN client, creates a router-to-router VPN connection with the corporate office router, the VPN server.

To configure an on-demand VPN connection at the branch office router

  1. Create a demand-dial interface for the Internet connection configured for the appropriate equipment (a modem or ISDN device), the phone number of the local ISP, and the user name and password used to gain Internet access.
  2. Create a demand-dial interface for the router-to-router VPN connection with the corporate office router configured for PPTP or L2TP, the IP address or host name of the corporate office VPN server's interface on the Internet, and a user name and password that can be verified by the VPN server. The user name must match the name of a demand-dial interface on the corporate office VPN server.
  3. Create a static host route for the IP address of the VPN server’s Internet interface that uses the demand-dial interface used to dial the local ISP.
  4. Create a static route (or routes) for the IP network IDs of the corporate intranet that uses the VPN demand-dial interface.

To configure the corporate office router

  1. Create a demand-dial interface for the VPN connection with the branch office configured for a VPN device (a PPTP or L2TP port). The demand-dial interface must have the same name as the user name in the authentication credential that is used by the branch office router to create the VPN connection.
  2. Create a static route or routes for the IP network IDs of the branch office that uses the VPN demand-dial interface.

The router-to-router VPN connection is automatically initiated by the branch office router through the following process:

  1. Packets sent to a corporate hub network location from a user in the branch office are forwarded by the user to the branch office router.
  2. The branch office router checks its routing table and finds a route to the corporate intranet network ID, which uses the VPN demand-dial interface.
  3. The branch office router checks the state of the VPN demand-dial interface and finds it is in a disconnected state.
  4. The branch office router retrieves the configuration of the VPN demand-dial interface.
  5. Based on the VPN demand-dial interface configuration, the branch office router attempts to initialize a router-to-router VPN connection at the IP address of the VPN server on the Internet.
  6. To establish a VPN, either a TCP connection (by using PPTP) or an IPSec negotiation must be established with the VPN server. The VPN establishment packet is created.
  7. To forward the VPN establishment packet to the corporate office router, the branch office router checks its routing table and finds the host route using the ISP demand-dial interface.
  8. The branch office router checks the state of the ISP demand-dial interface and finds it is in a disconnected state.
  9. The branch office router retrieves the configuration of the ISP demand-dial interface.
  10. Based on the ISP demand-dial interface configuration, the branch office router uses its modem or ISDN adapter to dial and establish a connection with its local ISP.
  11. Once the ISP connection is made, the VPN establishment packet is sent by the branch office router to the corporate office router.
  12. A VPN is negotiated between the branch office router and the corporate office router. As part of the negotiation, the branch office router sends authentication credentials that are verified by the corporate office router.
  13. The corporate office router checks its demand-dial interfaces and finds one that matches the user name sent during authentication and changes the interface to a connected state.
  14. The branch office router forwards the packet across the VPN and the VPN server forwards the packet to the appropriate intranet location.

Static vs. Dynamic Routing

Once the demand-dial interfaces are created and the choice has been made between temporary and persistent connections, you must choose one of the following methods for adding routing information to the routing table:

  1. For temporary connections, you can manually add the appropriate static routes to reach network IDs in the other offices. Manual configuration of static routes is appropriate for small implementations with a small number of routes.
  2. For temporary connections, you can use auto-static updates to periodically update the static routes that are available across the router-to-router VPN connection. Auto-static routes works well for larger implementations with a large amount of routing information. For more information about auto-static updates, see “Demand-Dial Routing” in this book.
  3. For persistent connections, run the appropriate routing protocols over the router-to-router VPN connection treating the VPN connection as a point-to-point link.

Note

Unlike demand-dial routing using direct physical connections, you cannot use a default IP route configured for the VPN demand-dial interface to summarize all the intranet routes available across the VPN. Because the router is connected to the Internet, you must use the default route to summarize all the routes of the Internet and configure it to use the Internet interface.


VPNs and Firewalls

A firewall employs packet filtering to allow or disallow the flow of very specific types of network traffic. IP packet filtering provides a way for you to define precisely what IP traffic is allowed to cross the firewall. IP packet filtering is important when you connect private intranets to public networks like the Internet.

VPN Server and Firewall Configurations

There are two approaches to using a firewall with a VPN server:

  • The VPN server is attached to the Internet and the firewall is between the VPN server and the intranet.
  • The firewall is attached to the Internet and the VPN server is between the firewall and the intranet.

VPN Server in Front of the Firewall

With the VPN server in front of the firewall attached to the Internet, as shown in Figure 9.17, you need to add packet filters to the Internet interface that only allow VPN traffic to and from the IP address of the VPN server’s interface on the Internet.

For inbound traffic, once the tunneled data is decrypted by the VPN server, it is forwarded to the firewall, which employs its filters to allow the traffic to be forwarded to intranet resources. Because the only traffic that is crossing the VPN server is traffic generated by authenticated VPN clients, firewall filtering in this scenario can be used to prevent VPN users from accessing specific intranet resources.

Because the only Internet traffic allowed on the intranet must go through the VPN server, this approach also prevents the sharing of File Transfer Protocol (FTP) or Web intranet resources with non-VPN Internet users.

Figure 9.17 VPN Server on the Internet in Front of the Firewall

For the Internet interface on the VPN server, configure the following input and output filters using the Routing and Remote Access snap-in.

Packet Filters for PPTP

Configure the following input filters with the filter action set to drop all except listed below:

  • Destination IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and TCP destination port of 1723 (0x06BB).

    This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 47 (0x2F).

    This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and TCP [established] source port of 1723 (0x06BB).

    This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is accepted only if the VPN server initiated the TCP connection.

Configure the following output filters with the filter action set to drop all except listed below:

  • Source IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and TCP Source Port of 1723 (0x06BB).

    This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

  • Source IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 47 (0x2F).

    This filter allows PPTP tunneled data from the VPN server to the VPN client.

  • Source IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and TCP [established] destination port of 1723 (0x06BB).

    This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is sent only if the VPN server initiated the TCP connection.

Packet Filters for L2TP over IPSec

Configure the following input filters with the filter action set to drop all except listed below:

  • Destination IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and UDP destination port of 500 (0x01F4).

    This filter allows Internet Security Association Key Management Protocol (ISAKMP) traffic to the VPN server.

  • Destination IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 50 (0x32).

    This filter allows IPSec ESP traffic from the VPN client to the VPN server.

Configure the following output filters with the filter action set to drop all except listed below:

  • Source IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and UDP source port of 500 (0x01F4).

    This filter allows ISAKMP traffic from the VPN server.

  • Source IP address of the VPN server’s Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 50 (0x2F).

    This filter allows IPSec ESP traffic from the VPN server to the VPN client.

There are no filters required for L2TP traffic for the UDP port of 1701. For L2TP over IPSec connections, all L2TP traffic including tunnel maintenance and tunneled data is encrypted as an IPSec ESP payload.

VPN Server Behind the Firewall

In a more common configuration, illustrated in Figure 9.18, the firewall is connected to the Internet and the VPN server is another intranet resource connected to a demilitarized zone (DMZ). The DMZ is an IP network segment that typically contains resources available to Internet users such as Web servers and FTP servers. The VPN server has an interface on the DMZ and an interface on the intranet.

In this approach, the firewall must be configured with input and output filters on its Internet interface to allow the passing of tunnel maintenance traffic and tunneled data to the VPN server. Additional filters can allow the passing of traffic to Web servers, FTP servers, and other types of servers on the DMZ.

Because the firewall does not have the encryption keys for each VPN connection, it can only filter on the plaintext headers of the tunneled data, meaning that all tunneled data passes through the firewall. However, this is not a security concern because the VPN connection requires an authentication process that prevents unauthorized access beyond the VPN server.

Figure 9.18 VPN Server Behind the Firewall on the Internet

For the Internet interface on the firewall, the following input and output filters need to be configured using the firewall’s configuration software.

Packet Filters for PPTP

Configure the following input filters with the filter action set to drop all except listed below:

  • Destination IP address of the VPN server’s DMZ interface and TCP destination port of 1723 (0x06BB).

    This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server’s DMZ interface and IP Protocol ID of 47 (0x2F).

    This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server’s DMZ interface and TCP [established] source port of 1723 (0x06BB).

    This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is accepted only if the VPN server initiated the TCP connection.

Configure the following output filters with the filter action set to drop all except listed below.

  • Source IP address of the VPN server’s DMZ interface and TCP Source Port of 1723 (0x06BB).

    This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

  • Source IP address of the VPN server’s DMZ interface and IP Protocol ID of 47 (0x2F).

    This filter allows PPTP tunneled data from the VPN server to the VPN client.

  • Source IP address of the VPN server’s DMZ interface and TCP [established] destination port of 1723 (0x06BB).

    This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is sent only if the VPN server initiated the TCP connection.

Packet Filters for L2TP over IPSec

Configure the following input filters with the filter action set to drop all except listed below.

  • Destination IP address of the VPN server’s DMZ interface and UDP destination port of 500 (0x01F4).

    This filter allows ISAKMP traffic to the VPN server.

  • Destination IP address of the VPN server’s DMZ interface and IP Protocol ID of 50 (0x32).

    This filter allows IPSec ESP traffic from the VPN client to the VPN server.

Configure the following output filters with the filter action set to drop all except listed below.

  • Source IP address of the VPN server’s DMZ interface and UDP source port of 500 (0x01F4).

    This filter allows ISAKMP traffic from the VPN server.

  • Source IP address of the VPN server’s DMZ interface and IP Protocol ID of 50 (0x2F).

    This filter allows IPSec ESP traffic from the VPN server to the VPN client.

There are no filters required for L2TP traffic at the UDP port of 1701. For L2TP over IPSec connections, all L2TP traffic including tunnel maintenance and tunneled data is encrypted as an IPSec ESP payload.


VPNs and Network Address Translators

A network address translator (NAT) is an IP router with the ability to translate the IP address and TCP/UDP port numbers of packets as they are forwarded. Consider the small business wanting to connect multiple computers to the Internet. It normally has to obtain a public address for each computer on the small business network. With NAT, however, the small business does not need multiple public addresses. It can use private addresses (as documented in RFC 1597) on the small business network segment and use the NAT to map the private addresses to one or more public IP addresses as allocated by an ISP. NAT functionality is documented in RFC 1631.

For example, if a small business is using the 10.0.0.0/8 network for its private network, and has been granted the public IP address of w.x.y.z by the ISP, the NAT statically or dynamically maps all private IP addresses used on network 10.0.0.0/8 to the IP address of w.x.y.z.

For outgoing packets, the source IP address and TCP/UDP port numbers are mapped to w.x.y.z and a possibly changed TCP/UDP port number. For incoming packets, the destination IP address and TCP/UDP port numbers are mapped to the private IP address and original TCP/UDP port number.

By default, a NAT translates IP addresses and TCP/UDP ports. If the IP address and port information is only in the IP and TCP/UDP headers, the application protocol can be translated transparently, such as with HyperText Transfer Protocol (HTTP) traffic on the World Wide Web.

However, some applications and protocols store IP address or TCP/UDP port information within their own headers. FTP, for example, stores the dotted decimal representation of IP addresses in the FTP header for the FTP PORT command. If the NAT does not properly translate the IP address within the FTP header, connectivity problems can occur. In addition, some protocols do not use TCP or UDP headers but use fields in other headers to identify data streams.

When the NAT component must additionally translate and adjust the payload beyond the IP, TCP, and UDP headers, a NAT editor is required. A NAT editor properly modifies otherwise non-translatable payloads so that they can be forwarded across a NAT.


Address and Port Mapping for VPN Traffic

In order for PPTP and L2TP over IPSec tunnels to work over a NAT, the NAT must be able to map multiple data streams to and from a single IP address.

PPTP Traffic

PPTP traffic consists of a TCP connection for tunnel maintenance and GRE encapsulation for tunneled data. The TCP connection is NAT-translatable because the source TCP port numbers can be transparently translated. However, the GRE-encapsulated data is not NAT-translatable without an editor.

With tunneled data, the tunnel is identified by the source IP address and the Call ID field in the GRE header. When there are multiple PPTP clients on the private side of a NAT tunneling to the same PPTP server, all the tunneled traffic has the same source IP address. Also, because the PPTP clients are unaware that they are being translated, they might pick the same Call ID when establishing the PPTP tunnel. Therefore, it is possible for tunneled data from multiple PPTP clients on the private side of the NAT to have the same source IP address and same Call ID when translated.

To prevent this problem, a NAT editor for PPTP must monitor the PPTP tunnel creation and create separate mappings between a private IP address and Call ID as used by the PPTP client to a public IP address and unique Call ID received by the PPTP server on the Internet.

Connection Sharing, the NAT component of the Routing and Remote Access service, contains a PPTP editor that translates the GRE Call ID in order to distinguish between multiple PPTP tunnels on the private side of the NAT.

L2TP over IPSec Traffic

L2TP over IPSec traffic is not translatable by a NAT because the UDP port number is encrypted, and its value is protected with a cryptographic checksum. L2TP over IPSec is not translatable even with an editor for the following additional reasons:

Inability To Distinguish Multiple IPSec ESP Data Streams

The ESP header contains a field called the Security Parameters Index (SPI). The SPI is used in conjunction with the destination IP address in the plaintext IP header and IPSec security protocol (ESP or Authenticating Header (AH)) to identify an IPSec security association (SA).

For outbound traffic from the NAT, the destination IP address is not changed. For inbound traffic to the NAT, the destination IP address must be mapped to a private IP address. Just as in the case of multiple PPTP clients on the private side of a NAT, the destination IP address of inbound traffic for multiple IPSec ESP data streams is the same address. To distinguish one IPSec ESP data stream from another, the destination IP address and SPI can be mapped to a private destination IP address and SPI. However, because the ESP Auth trailer contains an cryptographic checksum that verifies the ESP header and its payload, the SPI cannot be changed without invalidating the cryptographic checksum.

Inability to change TCP and UDP checksums

In L2TP over IPSec packets, UDP and TCP headers contain a checksum that includes the source and destination IP address of the plaintext IP header. The addresses in the plaintext IP header cannot be changed without invalidating the checksum in the TCP and UDP headers. The TCP and UDP checksums cannot be updated because they are within the encrypted portion of the ESP payload.


Pass-Through VPN Scenario

As described in “Internet and Intranet-Based VPN Connections” earlier in this chapter, a pass-through VPN allows a remote access client connected to one company’s intranet to access the resources of another company’s intranet across the Internet. A remote access VPN connection is passed to one intranet through another intranet and the Internet.

In a typical case, company A and company B are business partners, and an employee of company A visits company B. When the employee of company A attends a meeting and connects a laptop computer to the company B intranet, a company B intranet IP address configuration is obtained. If the employee of company A needs to connect to the company A intranet, it can be done in one of two ways:

  • Using a phone line in the conference room, the employee of company A can directly dial a company A remote access server to make a dial-up connection to the company A intranet or can dial a local ISP and make a VPN connection to the company A intranet.
  • As illustrated in Figure 9.19, using VPN technology and the appropriate infrastructure, the employee of company A can create a tunnel across the company B intranet to the Internet and then create another tunnel across the company B intranet and the Internet to the company A intranet.

With the latter method, the VPN connection to the company A intranet is created by activating two connection objects in the Connections folder using the existing local physical network connection. Note that Tunnel 2 is inside Tunnel 1 on the company B intranet.

Figure 9.19 Pass-Through VPN Scenario


Configuration of the Company A VPN Server

Configure the company A VPN server to accept remote access VPN connections from remote clients on the Internet with the appropriate remote access policies to require strong authentication and encryption.

For more information, see Windows 2000 Server Help.


Configuration of the Company B VPN Server

Configure the company B VPN server as follows:

  1. Configure the company B VPN server to accept remote access VPN connections. For more information, see Windows 2000 Server Help.
  2. Manually configure the IP address pool that contains a range of public IP addresses.
  3. Create a Windows 2000 group to contain the user accounts for visiting employees of other companies that are making pass-through VPN connections. For example, create the group VPN_PassThrough.
  4. Create the user account that is used by the visiting employee of company A.

Assuming that this VPN server is only to be used for pass-through VPNs for the visiting employees of business partners, delete the default remote access policy called Allow access if dial-in permission is enabled and create a remote access policy called VPN Pass-Through for Business Partners with the remote access policy permission setting, Grant remote access permission, selected. Then set the conditions and profile settings as listed in Tables 9.7 and 9.8. For detailed information about configuring these settings, see Windows 2000 Server Help.

Table 9.7 Remote Access Policy Conditions for Company B VPN Server

Conditions | Setting
NAS-Port-Type | Virtual
Called-Station-ID | IP address of the VPN server interface accepting VPN connections
Windows-2000-Groups | For example, VPN_PassThrough

Table 9.8 Remote Access Policy Profile Settings for Company B VPN Server

Profile settings | Setting
Authentication tab | Enable Microsoft Encrypted Authentication (MS-CHAP).
Encryption tab | Select either Prohibit encryption or Allow IPSec or MPPE encryption.

The remote access policy settings outlined in Tables 9.7 and 9.8 assume that you are managing remote access on a group basis by setting the remote access permission on all user accounts to Control access through remote access policy.

Note

The remote access policy profile settings do not require encryption. The tunnel from the employee of company A to the company B VPN server does not need to be encrypted because the tunnel from the employee of company A to the company A VPN server on the Internet is encrypted. Forcing the encryption of the first tunnel causes encryption to occur twice when it is not necessary and can impact performance.

Filtering Configuration

To ensure that the company B VPN server connected to the Internet is confined to accepting and forwarding pass-through VPN traffic, configure the following filters using the Routing and Remote Access snap-in.

To configure PPTP filtering

  1. On the intranet interface, configure the following input IP filters with the filter action set to drop all except listed below:
    • Destination IP address of the VPN server intranet interface, subnet mask of 255.255.255.255, and TCP destination port of 1723.
    • Destination IP address of the VPN server intranet interface, subnet mask of 255.255.255.255, and IP protocol of 47.
  2. On the intranet interface, configure the following output IP filters with the filter action set to drop all except listed below:
    • Source IP address of the VPN server intranet interface, subnet mask of 255.255.255.255, and TCP source port of 1723.
    • Source IP address of the VPN server intranet interface, subnet mask of 255.255.255.255, and IP protocol 47.
  3. On the Internet interface, configure the following input IP filters with the filter action set to drop all except listed below:
    • Destination IP address and subnet mask of the public IP address pool and TCP source port of 1723.
    • Destination IP address and subnet mask of the public IP address pool and IP protocol of 47.
  4. On the Internet interface, configure the following output IP filters with the filter action set to drop all except listed below:
    • Source IP address and subnet mask of the public IP address pool and TCP destination port of 1723.
    • Source IP address and subnet mask of the public IP address pool and IP protocol of 47.

To configure L2TP over IPSec filtering

  1. On the intranet interface, configure the following input IP filters with the filter action set to drop all except listed below:
    • Destination IP address of the VPN server intranet interface, subnet mask of 255.255.255.255, and IP protocol of 50.
    • Destination IP address of the VPN server intranet interface, subnet mask of 255.255.255.255, and destination UDP port of 500.
  2. On the intranet interface, configure the following output IP filters with the filter action set to drop all except listed below:
    • Source IP address of VPN server intranet interface, subnet mask of 255.255.255.255, and IP protocol of 50.
    • Source IP address of VPN server intranet interface, subnet mask of 255.255.255.255, and source UDP port of 500.
  3. On the Internet interface, configure the following input IP filters with the filter action set to drop all except listed below:
    • Destination IP address and subnet mask of the public IP address pool and IP protocol of 50.
    • Destination IP address and subnet mask of the public IP address pool and source UDP port of 500.
  4. On the Internet interface configure the following output IP filters with the filter action set to drop all except listed below:
    • Source IP address and subnet mask of the public IP address pool and IP protocol of 50.
    • Source IP address and subnet mask of the public IP address pool and destination UDP port of 500.


Configuration of the VPN Client Computer for a Pass-through VPN

The following sections detail the configuration of a Windows 2000–based VPN client computer for PPTP and L2TP over IPSec for a pass-through VPN.

To configure a PPTP connection

  1. Create a VPN connection object that connects the employee of company A with the VPN server of company B as follows:
    • On the General tab, type the host name or IP address of the intranet interface of the Company B VPN server.
    • On the Security tab, select Secure my password but not my data.
    • On the Networking tab, select Point-to-Point Tunneling Protocol (PPTP) as the type of server into which you are dialing.
  2. Create a VPN connection object that connects the employee of company A with the Internet VPN server of company A as follows:
    • On the General tab, type the host name or IP address of the Internet interface of the company A VPN server.
    • On the Security tab, select either Secure my password and data or Custom. If you select Custom, you must also select the appropriate encryption and authentication options.
    • On the Networking tab, select Point-to-Point Tunneling Protocol (PPTP) as the type of server into which you are dialing.

To configure a L2TP over IPSec connection

  1. Create a VPN connection object that connects the employee of company A with the VPN server of company B as follows:
    • On the General tab, type the host name or IP address of the intranet interface of the company B VPN server.
    • On the Security tab, select Secure my password but not my data.
    • On the Networking tab, select Layer-2 Tunneling Protocol (L2TP) as the type of server into which you are dialing.
  2. Create a VPN connection object that connects the employee of company A with the Internet VPN server of company A as follows:
    • On the General tab, type the host name or IP address of the Internet interface of the company A VPN server.
    • On the Security tab, select either Secure my password and data or Custom. If you select Custom, you must also select the appropriate encryption and authentication options.
    • On the Networking tab, select Layer-2 Tunneling Protocol (L2TP) as the type of server into which you are dialing.


Creating the Pass-Through VPN Connection

After the following pass-through VPN connection is made, the employee of company A can access any company A intranet resource for the duration of the VPN connection with the company A VPN server.

To create a pass-through connection

The employee of company A creates a pass-through VPN connection to the company A VPN server on the Internet using the following process:

  1. In the Connections folder, double-click the connection object that creates the tunnel to the company B VPN server on the company B intranet.
  2. When prompted for user credentials, type the credentials corresponding to the company B user account.
  3. In the Connections folder, double-click the connection object that creates the VPN to the company A VPN server on the Internet.
  4. When prompted for user credentials, type the credentials corresponding to the company A corporate account.


Troubleshooting VPNs

To troubleshoot VPNs, you must troubleshoot IP connectivity, remote access connection establishment, routing, and IPSec.


Common VPN Problems

VPN problems typically fall into the following categories:

  • Connection attempt is rejected when it should be accepted.
  • Connection attempt is accepted when it should be rejected.
  • Unable to reach locations beyond the VPN server.
  • Unable to establish a tunnel.

Use the following troubleshooting tips to isolate the configuration or infrastructure problem causing the stated VPN problem.

Connection Attempt is Rejected when it Should be Accepted

  • Using the ping command, verify that the host name or IP address of the VPN server is reachable. If a host name is being used, verify that the host name is resolved to its correct IP address. If the ping is not successful, Internet Control Message Protocol (ICMP) packet filtering might be preventing the delivery of ICMP messages to or from the VPN server.
  • Verify that the Routing and Remote Access service is running on the VPN server.
  • Verify that all of the PPTP or L2TP ports on the VPN server are not already being used. If necessary, change the number of PPTP to L2TP ports to allow more concurrent connections.
  • Verify that the tunneling protocol of the VPN client is supported by the VPN server.

    By default, Windows 2000-remote access VPN clients have the Automatic server type option selected, which means that they try to establish a PPTP-based VPN connection first, and then they try an L2TP over IPSec-based VPN connection. If either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option is selected, verify that the selected tunneling protocol is supported by the VPN server.

    By default, a Windows 2000 Server–based computer running the Routing and Remote Access service is a PPTP and L2TP server with five L2TP ports and five PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to zero.

  • Verify that the VPN client and the VPN server are configured to use at least one common authentication method.
  • For PPTP connections, test whether a PPTP connection can be made without encryption.

    If so, check the MPPE settings on the VPN client and VPN server.

  • For L2TP over IPSec connections, test whether an L2TP connection can be made without encryption (without IPSec).

    If so, check the L2TP over IPSec encryption settings on the VPN client and VPN server.

  • Verify that the parameters of the connection have permission through remote access policies.

    In order for the connection to be established, the parameters of the connection attempt must:

    • Match all of the conditions of at least one remote access policy.
    • Be granted remote access permission through the remote access permission of the user account (set to Allow access) or that the user account has the Control access through Remote Access Policy option selected and the remote access permission of the matching remote access policy has the Grant remote access permission option selected.
    • Match all the settings of the profile.
    • Match all the settings of the dial-in properties of the user account.

    For more information about remote access policies, see “Remote Access Server” in this book.

  • Verify that the settings of the remote access policy profile are not in conflict with properties of the remote access router.

    The properties of the remote access policy profile and the properties of the remote access server both contain settings for:

    • Multilink
    • Bandwidth allocation protocol
    • Authentication protocols

    If the settings of the profile of the matching remote access policy are in conflict with the settings of the VPN server, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP-TLS is not enabled on the VPN server, the VPN server rejects the connection attempt.

  • Verify that the VPN client's credentials, consisting of user name, password, and domain name, are correct and can be validated by the VPN server.
  • If the VPN server is configured with a static IP address pool, verify that there are enough addresses in the pool.

    If all of the addresses in the static pool have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address, and the connection attempt is rejected.

  • Verify the configuration of the authentication provider.

    The VPN server can be configured to use either Windows 2000 or RADIUS to authenticate the credentials of the VPN client.

  • For a VPN server that is a member server in a mixed or native Windows 2000 domain configured for Windows 2000 authentication, verify that the computer account of the VPN server computer is a member of the remote access and IAS Servers security group.
  • For remote access VPN connections, verify that remote access is enabled on the VPN server.
  • For remote access VPN connections, verify that the PPTP or L2TP ports, or both, are enabled for inbound remote access requests.
  • For remote access VPNs, verify that the LAN protocols being used by the VPN clients are enabled for remote access.
  • For router-to-router VPN connections, verify that routing is enabled and that LAN and WAN router is selected on the VPN server.
  • For router-to-router VPN connections, verify that the PPTP and L2TP ports are enabled for inbound and outbound demand-dial routing connections.

Connection Attempt is Accepted when it Should be Rejected

  • Verify that the parameters of the connection do not have permission through remote access policies.

    For the connection to be rejected, the parameters of the connection attempt must be denied remote access permission through the remote access permission of the user account (with Deny access selected), or because the user account has the control access through Remote Access Policy option selected, and the remote access permission of the first remote access policy that matches the parameters of the connection attempt has the Deny remote access permission selected.

    For more information about remote access policies, see “Remote Access Server” in this book.

Unable to Reach Locations Beyond the VPN Server

  • For remote access VPNs, verify that the Entire network option is selected for LAN protocols being used by the VPN clients.
  • Verify the IP address pool of the VPN server.

    If the VPN server is configured to use a static IP address pool, verify that the route to the range of addresses defined by the static IP address pool is reachable by the hosts and routers of the intranet. If not, an IP route consisting of the VPN server’s static IP address pool, {IP Address, Subnet Mask}, must be added to the routers of the intranet. If the route is not added, remote access clients cannot receive traffic from resources on the intranet. A route for the network can be implemented through static routing entries or through a routing protocol such as RIP or OSPF.

    If the VPN server is configured to use DHCP for IP address allocation and no DHCP server is available, a route to 169.254.0.0/16 (subnet mask 255.255.0.0) must be added to the routers of the intranet. When the VPN server is configured to use DHCP, and no DHCP server is found, the VPN server allocates addresses from the AutoNet address range of 169.254.0.0/16.

    If the static IP address pool is a range of IP addresses that is a subset of the range of IP addresses for the network to which the VPN server is attached, verify that the range of IP addresses in the static IP address pool are not assigned to other TCP/IP nodes either statically or through DHCP.

  • For router-to-router VPNs, verify that the router-to-router VPN connection is not interpreted by the VPN server as a remote access connection.

    If the user name of the calling router’s credentials appears under Dial-In Clients in the Routing and Remote Access snap-in, the VPN server has interpreted the calling router as a remote access client. Verify that the user name in the calling router’s credentials matches the name of a demand-dial interface on the VPN server.

Unable to Establish Tunnel

  • Verify that packet filtering on a router interface between the VPN client and the VPN server is not preventing the forwarding of tunneling protocol traffic.

    On a Windows 2000–based VPN server, IP packet filtering can be configured from the advanced TCP/IP properties and from the Routing and Remote Access snap-in. Check both places for filters that might be excluding VPN connection traffic.

    For more information about VPN connection traffic and packet filtering, see “VPNs and Firewalls” earlier in this chapter.

  • Verify that the WinSock Proxy client is not currently running on the VPN client.

    When the WinSock Proxy client is active, WinSock API calls such as those used to create tunnels and send tunneled data are intercepted and forwarded to a configured proxy server.

    A proxy server–based computer allows an organization to access specific types of Internet resources (typically Web and FTP) without directly connecting that organization to the Internet . The organization can use InterNIC-allocated private IP network IDs (such as 10.0.0.0/8).

    Proxy servers are typically used so that private users in an organization can have access to public Internet resources as if they were directly attached to the Internet. VPN connections are typically used so that authorized public Internet users can gain access to private organization resources as if they were directly attached to the private network. A single computer can act as a proxy server (for private users) and a VPN server (for authorized Internet users) to facilitate both exchanges of information.


Troubleshooting Tools

The following tools, which enable you to gather additional information about the source of your VPN problem, are included with Windows 2000.

Unreachability Reason

When a demand-dial interface fails to make a connection, the interface is left in an unreachable state. Right-click in the interface, and then select Unreachability reason to obtain more information about why the interface was unable to connect.

remote access Event Logging

On the remote access Event logging tab in the properties of a routing and remote access server, there are four levels of logging. Select Log the maximum amount of information, and then try the connection again. After the connection fails, check the system event log for events logged during the connection process. After you are done viewing remote access events, select the Log errors and warnings option on the remote access Event logging tab to conserve system resources.

Network Monitor

Use Network Monitor, a packet capture and analysis tool, to view the traffic sent between a VPN server and VPN client during the VPN connection process and during data transfer. You cannot interpret the encrypted portions of VPN traffic with Network Monitor.

The proper interpretation of the remote access and VPN traffic with Network Monitor requires an in-depth understanding of PPP, PPTP, IPSec, and other protocols. For more information about PPP, see “Remote Access Server” in this book. Network Monitor captures can be saved as files and sent to Microsoft Product Support Services for analysis.

Tracing

Tracing records the sequence of programming functions called during a process either to a console window or to a file. Enable tracing for remote access components as described in “The Windows 2000 Remote Access Router” in this book, and then try the connection again. After you have viewed the traced information, reset the tracing settings back to their default values to conserve system resources.

Tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft Product Support Services engineers or to network administrators who are very experienced with the Routing and Remote Access service. Tracing information can be saved as files and sent to Microsoft Product Support Services for analysis.


Interoperability with IBM Host Systems

Microsoft® SNA Server is Microsoft’s solution for integrating personal computer-based clients and servers with IBM host systems and IBM SNA networks. Using SNA Server, you can provide Microsoft and non-Microsoft-based clients with secure access to IBM host data, applications, and network services. You can integrate SNA Server into your existing IBM host environment, and you can develop solutions that allow users to gain transparent access to host resources from their desktop operating system or Web browser interface.

In This Chapter

Overview of Microsoft SNA Server

Network Integration Methods

Communications with Hierarchical SNA Networks

Communications with Peer-to-Peer SNA Networks

Heterogeneous Client Services

Host Print Services

LAN-to-Host Security

Host Data Access

Host Application Integration Using COMTI

Host Transaction Integration

Web-to-Host Integration

Network Management Integration

Note

The interoperability solutions in this chapter are based on Microsoft® Windows NT® version 4.0–based applications and technologies. Future versions of these applications and technologies might change. Therefore, the material included in this chapter is also subject to change.

Related Chapters in the Resource Kit

  • For more information about IBM Host Systems and SNA Networks, see “Introduction to IBM Host Systems and SNA Networks” in this book.

Additional Resources

  • For information about configuring and managing SNA Server, see SNA Server Help and the Microsoft® BackOffice® Resource Kit.
  • For updated versions of SNA Server, evaluation disks, and white papers, see the SNA Server Web site at http://www.microsoft.com/sna/.


Overview of Microsoft SNA Server

SNA Server provides you with a comprehensive solution to integrate heterogeneous networks and intranets with IBM mainframe, midrange, and AS/400 host systems (see Figure 12.1). SNA Server is a Microsoft® BackOffice® application that runs on the Microsoft® Windows® 2000 Server operating system, providing advanced network-to-host and Web-to-host integration services.

SNA Server provides interoperability between host systems that run SNA or TCP/IP protocols. If your IBM host system runs SNA protocols, SNA Server provides network connectivity by acting as a secure, high performance gateway between heterogeneous clients and IBM host systems. Because SNA Server runs on Windows 2000, heterogeneous clients can connect to SNA Server through standard networking protocols such as TCP/IP, IPX/SPX, NetBEUI, Banyan VINES IP, AppleTalk, and Windows 2000 Remote Access Service (remote access). SNA Server then completes the network connection to the mainframe or AS/400 system using standard IBM SNA protocols.

Once SNA or TCP/IP-based network connectivity is established, clients can use SNA Server’s advanced host integration features to gain secure access to IBM host data, applications, and network services without leaving their familiar desktop or Web browser interface.

Figure 12.1 SNA Server Integrates Heterogeneous Networks with IBM Host Systems

The core of SNA Server’s power is its ability to provide a wide range of host integration services. As such, SNA Server supports interoperability at each layer of the Windows 2000 Interoperability Model:

  • Network Integration

    Cross-platform network connectivity and protocols, security integration, and single sign-on. (Single sign-on allows users to log on once to access multiple servers, systems, or applications.)

  • Data Access

    Transparent file transfer services, Universal Data Access technologies such as OLE DB and ODBC, and host data replication.

  • Application Interoperability

    Terminal access, integrated transaction services, and Web-to-host integration.

  • Network Management Integration

    Integration between Windows 2000 network management services and IBM NetView–based management services.


Network Integration Services

When implementing cross-platform interoperability solutions, the first step is to establish secure and reliable connectivity between network platforms. SNA Server integrates heterogeneous networks with IBM mainframe, midrange, and AS/400 host systems using two types of connections, server-to-host and client-to-server.

The server-to-host connections are the physical units (PUs) and logical units (LUs) that connect the SNA Server to the host system.

The client-to-server network connections enable network clients and application programs to connect to SNA Server over the LAN or WAN.

Because SNA Server operates on Windows 2000 Server, it can support a wide range of clients and protocols and can scale to support the needs of large enterprise networks. Table 12.1 introduces the services that SNA Server provides on the network integration level.

Table 12.1 Network Integration Services

Network Integration Services | Description
Supported Host Systems | IBM Mainframe Systems; AS/400 Systems; Advanced System 36; System/36; System/38; and IBM compatible mainframe systems from Amdahl, Fujitsu, Hitachi, Tandem, and Unisys.
Server Capacity | Up to 3,000 users operating up to 30,000 concurrent sessions on each server.
Hot Backup and Load-Balancing | Up to 15 computers running SNA Server can be configured to provide failover for each other. LU pools can be shared across up to 15 servers to provide load-balancing.
Host Connection Methods | Supports standard connection methods including Channel (ESCON and Bus and Tag), Twinax, Open Systems Adapter (Token Ring, Ethernet, FDDI), SDLC, X.25, and DFT.
SNA Remote Access Service (SNA remote access) | Integrates the LU 6.2 transport with Windows 2000 remote access.
Heterogeneous Client Support | Microsoft® Windows® 2000 Professional, Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows® 3.x, Microsoft® MS-DOS®, Macintosh, OS/2, and UNIX.
Protocol Support | SNA, TCP/IP, IPX/SPX, Named Pipes, Banyan VINES IP, and AppleTalk.
Distributed Link Service | SNA Server computers can share host connections with other SNA Server computers. Allows efficient tunneling of SNA data between SNA Server computers over standard WAN infrastructures such as TCP/IP-based networks.
Downstream Connections | Supports communications to PU 2.0–type devices using only SNA protocols. To downstream devices, SNA appears to be the actual host system, reducing host PU configuration requirements.
PU Pass-through Service | Full SNA-capable products can connect to the host by passing PU 2.1 or PU 2.0 data through SNA Server. SNA Server behaves like an IBM 3174 cluster controller.
Integrated Single Sign-on | Administrators can configure SNA Server to provide USERID/Password information to the host based on Windows 2000 domain authentication credentials, eliminating the need to manage multiple sign-on combinations.
Password Synchronization | Supports third-party bi-directional password synchronization for ACF2, Resource Access Control Facility (RACF), and Top Secret security.
Data Encryption | Encrypts data streams between clients and SNA Server computers, isolating the transmission of clear text data (required by many host applications) to the secure network environment in the data center.
LU Level Security | Administrators can give users access to LU pools or can restrict users to specific LUs.
Bulk Migration Tool for Host Security | Creates Windows 2000 domain accounts, enrolls users in the Host Security Domain, and synchronizes critical account information.


Data Access

The purpose of integrating heterogeneous networks is to provide users with cross-platform access to data and applications. Table 12.2 summarizes the advanced services SNA Server uses to provide users with access to host data and the associated host files and printing resources.

Table 12.2 Host Data Access and Integrated File and Printing Services

Database and File Transfer Services | Description
OLE DB Provider for AS/400 and VSAM | Provides read/write record-level access to mainframe VSAM files and OS/400 files. Supports the development of multiple-tier applications that give users transparent access to nonrelational host data.
ODBC/DRDA Driver for DB2 | Applications designed to use the ODBC interface and SQL can dynamically interact with host database systems (such as DB2) using the DRDA protocol. Can also be used with OLE DB–based applications.
Shared Folders Gateway | Allows users to gain access to AS/400 shared folders–based files as if they were local drives on a computer running Windows 2000 Server. Allows you to use Windows 2000 security permissions and access rights on host shared folders.
Advanced Program-to-Program Communication (APPC) File Transfer Protocol (AFTP) Service | Provides access to AFTP file transfer (the SNA APPC equivalent to TCP/IP File Transfer Protocol [FTP]).
FTP-AFTP Gateway Service | Allows standard FTP clients to access host AFTP files.
VSAM File Transfer Service | Allows authorized users to copy mainframe VSAM files to Windows 2000 Server.
Host Data Replicator Support | Acts as a gateway for the replication of host data to Microsoft® SQL Server™.
Host Print Services | Allows mainframe and AS/400 print jobs to be printed on LAN-attached printers.


Application Interoperability

Organizations often use IBM host systems for online transaction processing (OLTP) that supports real-time, line of business applications. Traditionally, users have relied on terminal emulation programs to gain access to these host applications. However, information technology departments are increasingly deploying solutions that provide a more seamless level of interoperability between modern intranet services and IBM host data and applications.

Table 12.3 summarizes the services SNA Server supports to integrate desktop clients with host applications and transaction services.

Table 12.3 Integration with Host Applications and Transaction Services

Application and Transaction Integration Services | Description
Supports 3270, TN3270, TN3270E, TN3287 Terminal Emulation | Supports third-party terminal emulation products for native access or TCP/IP-based access to mainframe applications. SNA Server includes a single license 3270 emulator for testing purposes.
Supports 5250 and TN5250 Terminal Emulation | Supports third-party terminal emulation products for native access or TCP/IP-based access to AS/400 applications. SNA Server includes a single license 5250 emulator for testing purposes.
COM Transaction Integrator (COMTI) for CICS and IMS | Allows integration of Microsoft® Transaction Server (MTS) with host CICS and IMS transactions, including distributed two-phase commit between MTS and CICS.
Common Programming Interface for Communications (CPI-C) | Communicates with applications on any platform that supports APPC and CPI-C including mainframes, AS/400s, Windows 2000, and UNIX.
Web-to-Host Integration Technologies | Supports integration between host data and applications and Windows 2000–based applications such as Microsoft® Internet Information Services (IIS), SQL Server and Windows-based desktop applications.


Network Management Integration

Providing users with the ability to communicate, share data, and run applications across platforms allows organizations to develop more efficient and productive business processes. However, the integration process is not complete until network managers can monitor and control the integrated environment.

Table 12.4 summarizes the services SNA Server uses to integrate Windows 2000 Server–based management systems with IBM host management systems.

Table 12.4 Network Management Integration Services

Network Management Integration Services | Description
SNA Server Manager | Single console for adding, configuring, monitoring, and controlling all SNA Server components. Allows simultaneous, remote management of subdomains, servers, services, connections, LUs, sessions, users, and groups.
Integration with Windows 2000 Server management services | Full integration with Microsoft Management Console (MMC) and Windows 2000 event monitoring, security, and performance monitoring.
Integration with IBM NetView network management system | Automatic reporting of host link alerts to NetView; supports Response Time Monitor (if supported by the 3270 emulator). Also supports Windows 2000 NVAlert Services and NVRunCmd for remote management of SNA Server from the host NetView console.


Network Integration Methods

Using the SNA Server features described in the preceding tables you can connect Windows 2000–based networks to hierarchical SNA networks and APPN networks, and provide network integration services for your users. To accomplish this goal, you must first choose a deployment model, organize your SNA Server computers within your Windows 2000 domains, and select your LAN-to-host connection methods.


Deployment Models

Consider the following when deciding how to deploy SNA Server throughout your enterprise:

  • The type of host systems with which your users need to connect.
  • The location of the users who require host access.
  • Your existing network infrastructure.
  • The level of performance and host availability your organization requires.
  • The costs of deploying and managing the systems.

To accommodate different host connectivity requirements, SNA Server offers three deployment models.

  • Branch Deployment Model

    Consists of computers running SNA Server placed away from the host system and near your users.

  • Centralized Deployment Model

    Consists of SNA gateways placed close to the host system.

  • Distributed Deployment Model

    Consists of SNA gateways placed near the host system and close to your users.

These three models can also be combined to achieve the best configuration for your enterprise. The following sections explore the advantages and disadvantages of each SNA Server deployment model and assist you in making deployment decisions based on your current network model and your interoperability goals.

Branch Deployment Model

Traditionally, enterprises deploy SNA gateways using the branch-based deployment model. Clients use LAN protocols, such as TCP/IP, to communicate with a computer running SNA Server located on the LAN in the branch office.

The computer running SNA Server, in turn, communicates with the host using SNA protocols. With the branch approach, computers running SNA Server are connected to a host through 802.2 (using routers), SDLC, or X.25 connections (see Figure 12.2). Each computer running SNA Server can be administered locally or remotely using Windows 2000 Remote Access Service (remote access) or IBM NetView.

Figure 12.2 Branch-based SNA Server Deployment Model Using SDLC Connections

Advantages of the Branch Model

The branch deployment model offers four primary advantages:

  • Isolates SNA Traffic

    A branch-based deployment model is ideal when a limited amount of bandwidth is available over the SNA Server-to-host connection. In general, network traffic is greater between the client and the computer running SNA Server. If your organization has implemented TCP/IP or another routable WAN protocol, isolating the SNA traffic over specific connections that require host connections—in this case between the SNA Server and the host—prevents unnecessary network traffic from being propagated over non-SNA WAN connections.

  • Leverages Existing SNA Infrastructure

    The branch model is also ideal for organizations that are migrating toward a single, routable WAN protocol solution because it leverages existing investments in SNA data links. As you migrate toward an SNA-free WAN, you can tunnel SNA protocols (such as 802.2 and SDLC) from the branch office LANs to the central site LAN by deploying routers or Frame Relay Assembler/Disassemblers (FRADs) that support Data Link Switching (DLSw), frame relay (RFC 1490), or Asynchronous Transfer Mode (ATM) connections.

  • Provides Flexible Support Options

    Because computers running SNA Server are located physically near the clients that request host access services, local SNA Server administrators can usually manage users for their branch, responding more quickly to their needs. If necessary, however, computers running SNA Server can be configured and managed remotely across your WAN links.

  • Can Use Local Multi-Purpose Servers

    By deploying SNA Server in branch offices, you can take advantage of other applications designed to run on Windows 2000 Server. The branch-based server can assume a number of roles in addition to performing SNA Server functions, such as messaging server, database server, and Web server. Components in the Microsoft BackOffice suite of server applications can work together to provide integrated groupware solutions for your users.

Disadvantages of the Branch Model

The Branch Deployment Model has two primary disadvantages:

  • Does Not Use High-Speed Mainframe Connections

    In a branch-based network, you cannot implement high-speed mainframe connections such as channel attachment, Token Ring, or Ethernet. Local high-speed connections often face physical limitations or difficulty in implementing SNA protocols over a WAN connection. Traditionally, branch-based SNA gateways employ an SDLC-type solution that supports only one physical unit (PU) for each host adapter and only 254 logical units (LUs) over the connection.

  • Requires Sophisticated Routing

    If you decide to use routers rather than dedicated SNA links to pass WAN traffic between the branch and SNA host systems, the routers must be sophisticated enough to prioritize interactive communications over the WAN, as multiple protocols in addition to SNA may be operating over the connection.

Centralized Deployment Model

In a centralized model, computers running SNA Server are deployed physically near the host to which they provide connectivity. The centralized computers running SNA Server provide 3270 and 5250 access for local and remote desktops that connect to the gateways using a routable protocol such as TCP/IP. Other desktop or server-based LU 0, LU 6.2 (APPC), or telnet applications can connect through these gateways from anywhere on the WAN. Figure 12.3 illustrates the centralized deployment model.

Figure 12.3 Centralized SNA Server Deployment Model Using Routers or Bridges

Advantages of the Centralized Model

The centralized model offers three primary advantages:

  • Supports Efficient Load-Balancing and Fault Tolerance

    Using the centralized model, LU pools and APPC session pairs can be configured across multiple computers running SNA Server in a logical organization called a subdomain to provide load-balancing and fault tolerance services. Load-balancing distributes server loads across all configured servers and prevents one server from being overworked. Fault tolerance, or hot backup, ensures that other computers running SNA Server in a subdomain can automatically take over for a failed server. To your users, the switch to a backup computer is transparent. For more information about subdomains, see “Grouping Servers” later in this chapter.

  • Centralizes Administration

    A centralized deployment model is also easier to administer and to secure than a branch-based model because all computers running SNA Server are located close to one another (in the branch-based model, SNA expertise is usually required in each branch office to maintain the servers). Also, changes to mainframe definitions can be coordinated between host and SNA Server administrators more readily if all personnel are located near one another.

  • Supports High-Speed Mainframe Connections

    When computers running SNA Server are physically close to the SNA host, they can be linked by high-speed connections. The channel attachment method provides the highest throughput between SNA Server and a mainframe. In many cases, a channel-attached computer running SNA Server can bypass the front-end processor (FEP), thereby minimizing transaction response time. For AS/400 hosts, you can implement high-speed Token Ring or Ethernet connections.

Disadvantages of the Centralized Model

The centralized model has two primary disadvantages:

  • Requires an Efficient yWAN Infrastructure

    A centralized deployment model presupposes the existence of an efficient WAN environment. If a suitable WAN infrastructure is not in place, you must account for the cost in equipment, installation, and possible downtime while you deploy the required hardware. Because client/server transactions generate more network traffic than server/host transactions, this deployment model may yield less responsive client/server connections than a branch model.

  • Cannot Use Local Multi-Purpose Servers

    With no computers running SNA Server in the branch offices, you cannot use the Windows 2000 Server–based computers, upon which SNA Server runs, as multipurpose servers. If other server applications need to be implemented at the branch locations, you need to install additional computers and hardware.

Distributed Deployment Model

The distributed deployment model combines the best elements of the branch and centralized deployment models. As shown in Figure 12.4, computers running SNA Server are deployed both in a central location near the SNA host and in the branch LANs near the clients.

Typically, the computers located near the host are linked by a high-performance connection, such as channel-attachment. These link services are then made available for distribution to the branch computers running SNA Server using the Distributed Link Services, a feature that allows an SNA Server–based computer to share configured link services with other SNA Server–based computers. When implemented, the branch-based servers communicate with the SNA host through a virtual link service over a routable WAN protocol, such as TCP/IP.

Figure 12.4 Distributed SNA Server Deployment Model

Advantages of the Distributed Model

The distributed model has the advantages of the two previous models while minimizing the disadvantages of each.

  • Combines the Benefits of the Branch and Centralized Models

    The distributed model combines the high-capacity, server-to-host communication benefits of the centralized model with the branch model’s ability to contain heavy client/server traffic to a localized WAN segment, such as a branch office LAN.

  • Supports Optimal Fault Tolerance and Load-Balancing

    The distributed model provides even greater flexibility than the branch or centralized plans when fault tolerance and load-balancing are implemented. For example, multiple computers running SNA Server at a branch location can be configured to provide hot backup and load-balancing for each another. These servers in turn can be connected to the SNA host using distributed link services shared by the centralized computers running SNA Server. If any of the servers fails, the other servers at the same location can take over for the failed unit.

  • Uses Standard WAN Protocols

    The use of distributed link services can also simplify your routing and network protocol choices. For your branch offices, you can use any of the LAN protocols supported by SNA Server, including IPX/SPX. You can implement a more efficient, routable protocol like TCP/IP between the branch and central SNA Server–based computers. SNA traffic is isolated to the connection between the high-speed SNA Server–based computers and the host system. SNA protocols do not need to be routed or bridged across the WAN, thereby simplifying network management.

Disadvantage of the Distributed Model

The one possible disadvantage of the distributed model is that it may require more servers.

Depending on your requirements, deploying SNA Server–based computers both in the central location and in your branch offices could require that you deploy more servers than you would use in a centralized or branch model. However, the additional reliability and performance offered by this model, combined with the ability to eliminate multi-protocol WAN infrastructures can more than offset any requirements for additional servers.

In general, the distributed deployment model provides the most flexible and robust SNA Server solution. This strategy is recommended for medium to large network environments that require the best performance and reliability. The distributed model is also easily scalable to meet your future needs.


SNA Server Integration with Windows 2000-based Networks

SNA Server Integration with Windows 2000–based Networks

Note: Update this section when a beta of the new NT5 compliant SNA Server is available

After you choose an appropriate deployment model, you need to determine how to logically group your computers running SNA Server to provide fault tolerance, hot backup, and load-balancing services. How you organize your servers affects your ability to provide secure and robust host connectivity services to your users.

Windows 2000 Domains

Windows 2000 Server Active Directory stores information about all objects on a local or global network and makes this information easy for users and administrators to find and use.

To accommodate the needs of diverse organizations, Active Directory can be partitioned into domains and, in larger networks, hierarchies of domain trees. A Windows 2000 domain is a group of computers and resources that share a common user account database and security policy. Windows 2000 domains contain domain controllers which manage user accounts and control access to network resources. The remaining computers in the domain are either user workstations or servers, such as computers running SNA Server, that provide resources to domain users.

For more information about Active Directory and domains, see the Microsoft® Windows® 2000 Distributed Systems Guide.

SNA Server Subdomains

This section replaces Windows 2000 domain with Active Directory domain. Is it valid to do this? What if Windows 2000 Server is running Novell Directory Service instead of Active Directory?

Every computer running SNA Server is a member of a Windows 2000 domain and is also a member of an SNA Server subdomain. An SNA Server subdomain is a logical grouping of SNA Server–based computers that share common configuration information. These subdomains allow clients running SNA Server Client software to use any of the SNA Server–based computers in the same subdomain to connect to the host system or systems. To the clients running SNA Server Client software, these computers appear to function as a unit, providing a single set of SNA resources.

Although SNA Server runs on the Windows 2000 Server operating system, SNA Server subdomains play no role in Windows 2000 user authentication. Rather, SNA Server relies on Windows 2000 Server to authenticate users.

Note

SNA Server can be configured to use Windows 2000 domain authentication to provide secure, single sign-on to designated host system resources. For more information, see “Securing the LAN-to-Host Environment” later in this chapter.

Organizing SNA Server–based Subdomains

Each SNA Server subdomain can contain up to 15 computers running SNA Server, and a Windows 2000 domain can contain an unlimited number of SNA Server subdomains. Because they rely on Windows 2000 domain security to control access to the network, all computers running SNA Server in a particular subdomain must belong to the same Windows 2000 domain.

When you are planning the scope of an SNA Server subdomain and the location of its members, you should consider the capacity of the network link that connects the subdomain members. Whenever the subdomain configuration is changed (by adding a new user or LU, for example), the changed configuration file is propagated to all SNA Server–based computers in a subdomain whose role is set to backup. (SNA Server roles are discussed in the following section.)

To minimize unnecessary replication traffic across slow WAN connections, a subdomain should usually be contained within an Active Directory site. An Active Directory site is one or more TCP/IP subnets that are connected by high-speed links. Windows 2000 allows administrators to control and optimize inter-site replications.

In the distributed deployment model presented earlier in this chapter, you could organize all computers running SNA Server at a branch office site into one subdomain and organize the computers running SNA Server at the central site (near the host) into a separate subdomain.

SNA Server offers additional mechanisms to specifically control SNA Server replication traffic. For example, using the SNA Server Manager, you can control replication traffic by configuring a parameter called Mean Time Between Server Broadcasts. For more information about fine-tuning SNA Server replications, see the SNA Server documentation.

Insert new or corrected material here when available

This note contains additional information about SNA Server 4 subdomains that may not be valid anymore.

Determining SNA Server Roles

After you have established your Windows 2000 domains and your subdomains, you must assign a role to each computer running SNA Server within each subdomain.

The designation of one of the following three roles identifies which computers running SNA Server have a copy of the SNA Server configuration for the SNA Server subdomain. SNA Server Client–based computers can connect to any computer running SNA Server in the subdomain regardless of its configuration role.

check to see if these primary and backup roles become equal peers in NT5 (like domain controllers do)

Primary. Provides host connectivity services to your users and contains the master copy of the configuration file. Only one computer can be designated as the primary SNA Server in a subdomain.

Backup. Contains a read-only copy of the configuration file maintained by the primary server. Backup servers can be promoted to a primary role if the primary server fails. An SNA Server subdomain can contain up to 14 backup servers.

Member. Does not contain a copy of the configuration file. Members rely on primary and backup servers to maintain configuration information. An SNA Server subdomain can contain up to 14 member servers.

Note

The concept of a backup SNA Server is different from the concept of hot backup. Hot backup is the ability of computers running SNA Server to work together to provide session support even when a server or a connection is not working. When computers running SNA Server provide hot backup, it means that LUs and other resources are configured so that they can fill in and support sessions required by other servers in the subdomain, even if another, similar resource is not available.

The primary computer running SNA Server should be the first server you install in an SNA Server subdomain. If possible, you should have one or more backup servers in the subdomain, as well, to maintain copies of the SNA Server configuration file in case the primary computer running SNA Server fails. If security is an issue, the backup servers should be kept physically secure because each one contains a copy of the SNA Server configuration file.

After you have designated one primary server and its backup servers, the remaining servers can be designated as member servers (computers running SNA Server without a configuration file).

As long as the primary server is running, you can administer SNA Server from a member server just as you would from any other server. You can also manage SNA Server from a computer running Windows 2000 Professional that has SNA Server Manager installed. You can limit the ability of users or groups to administer SNA Server by setting up SNA Server permissions.


Connection Methods

Once you have determined a suitable deployment model and subdomain configuration, you must determine:

  • How to connect computers running SNA Server to the IBM host systems.
  • Which network protocols to use for communications between client computers and SNA Server–based computers.
  • Which network protocols to use for communications between different computers running SNA Server.

Connecting SNA Server–based Computers to IBM Host Systems

This section explores how to connect computers running SNA Server to IBM mainframe and AS/400 host systems.

Understanding SNA Server-to-Host Connections

In SNA Server terms, a host connection is the data communications path between SNA Server and a host system. For a mainframe, this connection corresponds to a physical unit (PU) definition in the Virtual Telecommunications Access Method (VTAM). A PU is a combination of hardware and software that provides the services needed to use and manage a particular device. On the AS/400, this connection corresponds to an Advanced Program-to-Program Communications (APPC) controller definition. For more information about IBM host connection methods and other background information about SNA networking, see “Introduction to IBM Host Systems and SNA Networks” in this book.

For each physical adapter or connection, an appropriate link service is installed and configured within SNA Server. The link service is a Windows 2000 service or device driver that is used to control server-to-host communication adapters supported by SNA Server. Once configured, the link service is available for use not only on the configured SNA Server, but on any SNA Server in the subdomain using the Distributed Link Service feature of SNA Server.

Once you configure your link services, you create connections over a defined link service. As mentioned previously, a connection is the data communication path between a computer running SNA Server and the IBM host. Using a host connection, a client computer on a LAN can communicate with the mainframe system. For some link services, it is possible to define multiple connections over a single host link.

In SNA terms, the combination of a connection and the link service it uses is equivalent to a PU. In SNA networks, SNA Server provides PU 2 or PU 2.1 functionality similar to a cluster controller. For more information about cluster controller functions, see “Introduction to IBM Host Systems and SNA Networks” in this book.

Understanding Server-to-Host Connection Methods

To understand the connectivity options, you should first examine the different physical connections and network protocols that SNA Server supports. Table 12.5 summarizes all common connection methods that can be used with SNA Server.

Table 12.5 SNA Server-to-Host Connection Methods

Method | Throughput | Characteristics
Token Ring 802.2 Data Link Control (DLC) | 4 or 16 Megabits per second | Mainframe or AS/400. Midrange performance using DLC protocol. Supports multiple host connections using a single adapter. Easy and inexpensive to implement. Suitable for a wide range of purposes.
Standard Ethernet 802.2 DLC | 10 Megabits per second | Mainframe or AS/400. Midrange performance using DLC protocol. Supports multiple host connections using a single adapter. Easy and inexpensive to implement. Suitable for light to medium network traffic conditions. Ethernet contention can degrade performance under heavy loads.
Fast Ethernet 802.2 DLC | 100 Megabits per second | Mainframe or AS/400. High performance using DLC protocol. Supports multiple host connections using a single adapter. Easy and inexpensive to implement. Suitable for higher performance connections. Ethernet contention can degrade performance under heavy loads.
Fiber Distributed Data Interface (FDDI) 802.2 DLC | 100 Megabits per second | Mainframe or AS/400. High performance using DLC protocol. Supports multiple host connections using a single adapter. Relatively expensive to implement. Suitable for higher performance connections.
Synchronous Data Link Control (SDLC) | 9600 - 19200 bps | Mainframe or AS/400. Generally low performance using SDLC protocol. Supports 256 sessions over a single host connection. Easy and inexpensive to implement. Suitable for low-traffic WAN connections.
X.25 | 9600 - 19200 bps | Mainframes and AS/400. Generally low performance using Qualified logical link control (QLLC) protocol. Supports 256 sessions over a single host connection. Easy and inexpensive to implement. Suitable for low-traffic WAN connections.
Distributed Function Terminal (DFT) | 2.35 Megabits per second | Mainframes only. Low to midrange performance. Supports only five sessions over a single host connection. Inexpensive. Suitable for test environments or small networks with an existing DFT-based infrastructure.
Twinax | 1 Megabit per second | AS/400 systems only. Low performance. Supports five sessions over a single host connection. Inexpensive. Suitable for AS/400 host environments with an existing twinax infrastructure.
Channel - Bus & Tag | 4.5 MegaBytes per second | Mainframes only. High performance. Supports a high number of host connections. Expensive. Suitable for high-performance connections.
Channel - ESCON | 17 MegaBytes per second | Mainframes only. Highest performance. Supports a high number of host connections. Expensive. Suitable for conditions where maximum throughput is required.

When you choose a connection method, you should keep in mind several factors:

  • The host systems to which you are connecting.
  • The deployment model you are implementing.
  • The host networking infrastructure that is in place.
  • The expected usage level of host resources.
  • The level of performance and response expected by your users.
  • Cost.

In general, a high-speed Token Ring connection is a good choice when the same connection is used to connect a LAN to an SNA network that includes both a mainframe and AS/400 system. For greater performance in a dedicated mainframe environment, channel-type connections are generally recommended.

For some link services, multiple host connections are possible using a single adapter, most notably DLC and channel-type link services. Each instance of SNA Server supports up to 250 host connections, and up to four instances of SNA Server are supported on a single computer.

Connecting SNA Server to a Mainframe System

The hierarchical SNA network model provides access to a centralized processing resource from elements throughout the network. This model is most frequently associated with mainframe environments in which centralized applications are accessed from remote terminals across a network.

Devices in a hierarchical SNA network, such as terminals or cluster controllers, are called physical units (PUs). Each class of device is designated by a number. For example, the mainframe itself is known as a PU 5 device. For background information about hierarchical SNA networks, see “Introduction to IBM Host Systems and SNA Networks” in this book.

SNA Server participates in a hierarchical SNA network by emulating a standard IBM PU 2, or cluster controller, and multiple LUs (protocols that provide a standardized format for delivery of data for specific applications) of type LU 0, LU 1, LU 2, and LU 3. This allows client computers that emulate IBM terminals and applications to communicate with the IBM host (PU 5).

SNA Server can connect to a mainframe computer in one of two ways: either directly to the PU 5, the host; or through a PU 4, a front-end processor (FEP).

Direct and Indirect Physical Connections to a Mainframe

You can make a direct physical connection (a connection that does not involve an FEP) between computers running SNA Server and a mainframe system using any of the following physical connection methods:

  • Open Systems Adapter, supporting Token Ring, Ethernet, and FDDI connections
  • Bus & Tag channel connection
  • ESCON channel connection

Indirect physical connections between SNA Server–based computers and a mainframe system (connections through an FEP) are also supported. These connections may be easier to implement depending on your existing infrastructure and the physical proximity of the computers running SNA Server to the mainframe. For this type of connection, one of the following methods can be used:

  • Token ring
  • Ethernet
  • FDDI
  • SDLC

Figure 12.5 illustrates both direct and indirect physical connections to a mainframe.

Figure 12.5 Direct and Indirect Physical Connections to a Mainframe

Logical Connections to a Mainframe

In a hierarchical SNA network, SNA Server emulates a cluster controller and supports all standard protocols:

  • LU 2 for 3270 terminal sessions.
  • LU 1 or 3 for SCS or 3270 printer sessions.
  • LU 6.2 for APPC and Common programming Interface for Communications (CPI-C) applications.
  • LU 0, 1, 2, or 3 for LU application (LUA) Request User Interface (RUI) general-purpose, customized applications.

Any combination of these protocols may be used over a given physical connection, as illustrated in Figure 12.6.

Figure 12.6 Logical Connections to a Mainframe

Connecting SNA Server to an AS/400 System

In the peer-oriented SNA network model, all computers on the network can communicate directly with each other. Advanced Peer-to-Peer Networking (APPN) is the architecture developed by IBM that enables distributed data processing. APPN defines how components communicate with each other, and the level of network-related services, like routing sessions, that are supplied by each computer in the network. For background information about SNA APPN, see “Introduction to IBM Host Systems and SNA Networks” in this book.

In an APPN network, SNA Server emulates a type 2.1 physical unit device (PU 2.1). SNA Server operates as an APPN low entry network (LEN) node and communicates with other APPN nodes using the Advanced Program-to-Program Communications (APPC) or LU 6.2 protocol.

Computers running SNA Server can connect directly to an AS/400 using several connection methods, as shown in Figure 12.7:

  • SDLC
  • (Token Ring, Ethernet, FDDI)
  • Twinax
  • Frame Relay

Figure 12.7 SNA Server Connections in a Peer-Oriented Network

Choosing Network Protocols

After your SNA Server–based computer-to-host connection is determined, you must choose the protocol or protocols to use for two additional SNA Server communication paths: between client computers and SNA Server–based computers, and between different SNA Server–based computers.

You can use one protocol for both, or you can use a combination of different protocols, provided that all servers share at least one client/server protocol and use it for server-to-server communication.

Deploying a single protocol across your WAN is the easiest way to manage your network communications.

However, you may decide to gradually implement SNA Server throughout your enterprise. In this case, you may need to use existing protocols for certain connections. For example, you could use TCP/IP for server-to-server communications and use IPX/SPX for client-to-server communications. Similarly, other combinations of supported protocols can be used, provided that all the SNA Server–based computers share one protocol and use that protocol for server-to-server and client-to-server communication.

Choosing Client/Server Network Protocols

Computers running SNA Server Client software can communicate through a number of LAN protocols:

  • TCP/IP
  • IPX/SPX
  • Named Pipes
  • Banyan VINES IP
  • AppleTalk

TCP/IP is quickly becoming the standard network protocol for client/server applications. Its high performance and support for sophisticated routing features make it suitable for many WAN environments. In many cases, TCP/IP is the best protocol choice for your network, especially if TCP/IP is already deployed to some degree in the LAN segment on which servers and clients running SNA Server reside.

If you deploy TCP/IP, it is recommended that you assign static IP addresses to SNA Server–based computers because it is easier to administer workstations that have a fixed SNA Server address. For computers that run SNA Server Client software, you can use the Dynamic Host Configuration Protocol (DHCP) to dynamically allocate client IP addresses without difficulty.

For more information about TCP/IP and DHCP, see the Microsoft® Windows® 2000 TCP/IP Core Networking Guide.

SNA Server Client Software

SNA Server Client software allows workstations to support SNA Server advanced host integration features. SNA Server Client software also provides application programming interfaces (APIs) that are used by third-party vendors to gain access to IBM host systems and applications. Third-party vendors provide 3270 and 5250 terminal emulators and additional host integration utilities.

SNA Server Client software creates network transport independence, allowing clients and applications to communicate using any of SNA Server’s programmatic interfaces.

At this time, client software is available for the following platforms:

  • Windows NT
  • Windows 95
  • Windows 3.x
  • MS-DOS
  • IBM OS/2
  • Macintosh (third-party)
  • UNIX (third-party)

Note

SNA Server Client software is not required for clients that use TCP/IP for services such as TN3270, TN5250, and AFTP. Applications, such as TN3270 emulators, communicate directly with these services rather than using the SNA Server client/server interface.

For information about the host communication services and SNA application programming interfaces that SNA Server can support for each client platform, see “Providing Services for Heterogeneous Clients” later in this chapter.

Choosing Server-to-Server Network Protocols

Computers running SNA Server can communicate with each other using any of the following methods:

  • TCP/IP
  • IPX/SPX
  • Named Pipes
  • Banyan VINES IP

For more information about configuring protocols and optimizing server-to-server network traffic, see the SNA Server documentation.


Communications with Hierarchical SNA Networks

In traditional hierarchical SNA networks, remote terminals access centralized mainframe applications across a network.

This model uses the information display protocol for IBM mainframe computers known as 3270. This protocol facilitates conversations between the mainframe and devices such as terminals, printers, and controllers. SNA Server can provide access to these mainframe resources through the definition and assignment of 3270 LUs.

Once you have established the physical connection from SNA Server to the mainframe, you need to determine the types of 3270 connectivity that your users need.


3270 Access

SNA Server provides 3270 connectivity through dependent 3270 LUs. 3270 LUs are dependent because they require a mainframe to function. Each 3270 LU defined within SNA Server is configured to use an existing connection to the mainframe system and corresponds to a matching LU resource allocated on the host computer, usually specified within VTAM. The 3270 LU definition in SNA Server is identified by a number and a user-specified name. The number matches the number of the corresponding LU resource on the mainframe.

The 3270 LU is further classified by the type of service provided over the connection. Like PUs, LU types are designated by numbers. For example, 3270 display data streams are known as LU 2. A 3270 LU can be configured as one of the following (see Figure 12.8):

  • Display (LU 2)
  • Printer (LU 1 or LU 3)
  • Application (LUA)
  • Downstream

Figure 12.8 3270 Connectivity Using SNA Server

SNA Server Client software must be installed on each client computer that uses SNA Server LU services. The client software manages communications between a 3270 application and the server running SNA Server. Applications designed to use the SNA Server Client API use the LUs defined within SNA Server to establish a communications link from the client to the mainframe through SNA Server.

The link between the LU definition in SNA Server and the host LU resource is called a session. Sessions can be permanent and automatically started during initialization, or established on an as-needed basis. Concurrent sessions can share the same physical devices and communications links.


Using LU Pools

Although you can create individual LUs and assign them to users and groups, using LU pools to manage and deploy a large number of LUs is a more efficient method of administering these resources. LU pools are groupings of LUs that allow you to maximize access to these LUs (see Figure 12.9). A user, an application, or a downstream system can access the LUs as long as any LU assigned to the pool is free. If any one of the pooled LUs ceases to function, another free LU in the pool is used.

Figure 12.9 Creating and Assigning LU Pools

LU pools also allow groups of intermittent users to use a limited number of host resources more efficiently. Dedicating LUs to specific users who occasionally require host access wastes host resources. Using a pool, you can assign a smaller number of LUs to a group of users who require sporadic access. For example, if a group of 100 users requires host access 25 percent of the time, assigning a pool of 25 LUs to the group may fulfill their needs.


Assigning LUs to Workstations

LUs (and LU pools) can also be assigned to workstations rather than users, effectively locking LUs to a specific computer. This configuration makes it easier for users to find and access different resources.

For example, suppose you have 150 employees who share 50 workstations, each of which has a printer attached. Instead of assigning 50 printer LUs to a pool and making the pool available to each user, you can add each of the workstations to SNA Server and assign a printer LU to each workstation. Doing so allows users to log on to any of the 50 workstations, and the printer that is attached to the workstation is available in the list of LUs.


Providing Fault Tolerance

LU pools can also provide fault-tolerant connections to users. When a particular resource such as a host connection fails, hot backup allows for a similarly configured resource to automatically fill in and support the needed functions (see Figure 12.10). Hot backup can be implemented across host connections on the same server or across several servers in a domain. Hot backup is a recommended strategy for any size enterprise and helps to provide reliable host access to your users.

Figure 12.10 Hot Backup Across Connections and Servers


Providing Load-Balancing

Load-balancing is closely related to hot backup. Load-balancing evenly distributes sessions across multiple host connections and multiple servers using 3270 LU pooling. For example, if you have two connections that each support ten 3270 display LUs, load-balancing ensures that free LUs are allocated evenly from the two connections to users. Load-balancing is implemented when a pool is configured with LUs from multiple servers or connections.


TN3270 Access

TN3270 is a type of telnet service that allows access to mainframe computers over a TCP/IP network. Users can connect to mainframes using a TN3270 client and the TN3270 service provided with SNA Server, as shown in Figure 12.11.

The TN3270 service supports the following protocols:

  • TN3270 for display sessions.
  • TN3287 for printer sessions.
  • TN3270E for extended display and print sessions.

The TN3270 service uses SNA Server features to provide mainframe access and to address issues such as security and redundancy when the data communications path between the client and server contains one or more unsecured segments.

Figure 12.11 TN3270 Communications Through SNA Server

Because the TN3270 service communicates with SNA Server using the LUA API, LUA-type connections and LUs must be configured on the server. Once configured, LUAs and LU pools can be assigned to the TN3270 service and made available for use by TN3270 clients requesting mainframe access.

As with all TCP/IP services, TN3270 requires a free TCP port in which clients can locate the TN3270 service. The TN3270 service defaults to port 23, the same port as standard telnet services. Because no two services can share the same TCP port, it is recommended that you change the TN3270 service to use TCP port 24 or some other unused TCP port. When attempting to connect to the TN3270 service from a client application, you must also specify the new TCP port within the application’s connection settings.

Providing Hot Backup and Load-Balancing

As described in “SNA Server Integration with Windows 2000–based Networks” earlier in this chapter, a Windows 2000 domain can contain one or more SNA Server subdomains. Like 3270 LUs, LUA LUs from multiple servers in different subdomains can be assigned to the TN3270 service. This allows you to distribute client sessions among the participating servers in the subdomain, thereby balancing the load.

Creating redundant connections to the mainframe and assigning them to a TN3270 service increases service availability. If one server fails, a client can still access LUA LUs on a different server. If no other SNA Server–based computers are used in a particular site, you can increase fault tolerance and available bandwidth by configuring a single server with redundant host links.

Assigning LUs to IP Addresses

Just as you can assign 3270 LUs to a user or workstation, you can restrict access to LUA LUs or pools by specifying an IP address or subnet mask for clients that must access the resource. If a workstation has a name that can be resolved using name resolution services like DHCP, DNS, or WINS, the name can be associated with the resource instead of the individual workstation. For information about TCP/IP addressing and services, see the Microsoft® Windows® 2000 TCP/IP Core Networking Guide.

Restricting access to clients with specific IP addresses or workstation names increases the security of the LUA resources. For more information about host security issues, see “Securing Your SNA Environment” later in this chapter.


Downstream Connections

In hierarchical SNA environments, you configure 3270 communications between SNA nodes using SNA protocols. Usually those nodes are SNA Server–based computers and mainframes. A downstream system, however, is an SNA node that uses SNA Server as a PU gateway, as shown in Figure 12.12. To the downstream system, the SNA Server–based computer appears to be the actual mainframe providing the PUs and 3270 LUs.

Figure 12.12 Downstream Connections Using SNA Server

A downstream system in this type of environment must be a PU 2 device. For example, an IBM 3745 cluster controller can be a downstream device. A client running a terminal emulator that emulates a PU 2 and acquires LU sessions from the SNA Server–based computer can also be a downstream device.

On the computer running SNA Server, two connections are required to support downstream systems:

  • A host connection between the server and the mainframe. This can be any standard physical connection method supported by the mainframe.
  • A downstream connection between the server and the downstream system. This physical connection can be an 802.2/DLC, SDLC, or X.25 connection.

Once configured, SNA Server can manage the downstream LUs in a manner similar to how it manages other LUs, including assigning them to LU pools.

This type of configuration is useful in environments where the downstream system is unable to communicate directly with the mainframe because of hardware or network incompatibilities that the intermediate SNA Server–based computer can resolve.

Using SNA Server as a PU concentrator can also help reduce host configuration requirements. LUs from one or more PUs can be shared with multiple downstream devices, alleviating the need to configure each downstream device in VTAM on the mainframe system. The result is a more efficient use of host resources.

For more information about communications with hierarchical SNA networks, see the SNA Server documentation.


Communications with Peer-to-Peer SNA Networks

Devices in peer-oriented SNA networks participate in Advanced Peer-to-Peer Networking (APPN). Each APPN device, known as a type 2.1 physical unit (PU 2.1) can communicate directly with other PU 2.1 devices using Advanced Program-to-Program Communications (APPC) sessions.

Each PU 2.1 device relies on its own intelligence and does not require constant access to a centrally located host system.

Note

Although networks that use APPC are usually associated with AS/400 host systems, mainframe systems can also use APPC-based networking.

In an AS/400 environment, APPC is used for a variety of applications including 5250 access, TN5250 access, and file transfers. Programs that use APPC to communicate are called transaction programs (TPs). APPC TPs use LU 6.2 names to gain access to other systems and other transaction programs.

For background information about APPN networking, see “Introduction to IBM Host Systems and SNA Networks” in this book.


APPC Communications Using SNA Server

With SNA Server, a TP such as a 5250 terminal emulator may use an APPC LU alias to communicate with another TP. In this case, the LU alias maps to an LU name that is actually used to communicate with the TP on the other system.

When a client/server network TP requests a conversation with a TP on the AS/400 (the remote system), SNA Server (the local system) acts on behalf of the client request and negotiates an LU 6.2 to LU 6.2 session to the AS/400. The data sent or received from the AS/400 TP is handled by the server and sent to the client TP over the selected client/server protocol. Figure 12.13 shows an APPC conversation using SNA Server.

Figure 12.13 An APPC Conversation Using SNA Server

Note

In Figure 12.13, the perception of local and remote LUs depends on the system you are configuring. When configuring SNA Server, the local APPC LU corresponds to SNA Server and the remote LU corresponds to the AS/400. If you view the configuration from the AS/400 perspective, the AS/400 is the local APPC LU and SNA Server is the remote LU.


Common Programming Interface for Communications

Common Programming Interface for Communications (CPI-C) is an API that uses the LU 6.2 communications architecture. Many organizations implement CPI-C because several platforms that support APPC communications can use CPI-C, including AS/400 and mainframe systems, Windows 2000, and several UNIX-based operating systems. CPI-C comprises a set of C programming language routines that allow applications on computers to communicate with one another to accomplish a processing task, such as copying a file or accessing a remote database.

CPI-C programming provides a mechanism called client-side information that associates a set of parameters with a specified CPI-C symbolic destination name. The CPI-C program uses the symbolic destination name to initialize a conversation using APPC LUs that are associated with the CPI-C symbolic name.

SNA Server supports the CPI-C API and provides for configuration of CPI-C parameters. For more information about programming using the CPI-C API, see the SNA Server documentation.


APPC Applications

APPC can be used to support a wide range of applications including:

  • terminal access.
  • TN5250 terminal access.
  • APPC file transfers, including Shared Folders access.

5250 Access

AS/400 display sessions are provided through APPC using the 5250 data stream. Computers running SNA Server provide APPC access to AS/400s using 5250 emulation clients. Clients can only communicate with AS/400s using APPC.

To support 5250 services, the local APPC LU acts as an identifier for local SNA Server–based client computers; the remote APPC LU identifies the AS/400 system. Figure 12.14 shows the local and remote LUs used for this configuration.

Figure 12.14 Components of 5250 Access Through SNA Server

TN5250 Access

TN5250 is a telnet service that allows users to access AS/400 systems over a TCP/IP network using an appropriate TN5250 client terminal emulator. The TN5250 service provided with SNA Server enables any TN5250 client to connect to the AS/400 by means of SNA Server without installing or configuring TCP/IP on the AS/400 (see Figure 12.15). Full 5250 terminal emulation functions are supported by the service, as well as fault tolerance and security features similar to those provided with the TN3270 service.

Figure 12.15 TN5250 Access Through SNA Server

APPC File Transfers

Although it is possible to perform file transfers between the client and the host system using $INDFILE or other mechanisms, APPC file transfers offer a robust and high performance alternative to emulator-based solutions.

SNA Server supports three host file transfer mechanisms based on APPC connectivity:

  • APPC File Transfer Protocol (AFTP)
  • FTP to AFTP Gateway
  • Shared Folders

The file transfer method that you choose to deploy depends on the type of host system in your enterprise (mainframe or AS/400) and on the type of file transfer capabilities you wish to provide to your users.

APPC File Transfer Protocol

The APPC File Transfer Protocol (AFTP) is a client/server application that provides file transfer capabilities using APPC and LU 6.2 (FTP protocol is used on TCP/IP networks in a similar way). AFTP supports functions similar to standard FTP, including the ability to send, receive, and rename files, as well as to manipulate directories on a remote system.

The AFTP Service is installed and configured on the computer running SNA Server (or an SNA Server–based client computer) to allow AFTP client software (provided with SNA Server) to access specific directories on the server.

For more information about configuring and using AFTP, see the SNA Server documentation.

FTP-AFTP Gateway Service

The FTP-AFTP Gateway Service gives TCP/IP users the ability to access and manipulate files on a mainframe or an AS/400 using a conventional FTP client without installing TCP/IP on the host (see Figure 12.16). The service transparently converts incoming client FTP requests into AFTP commands and manages the communications and data between the two services. This capability can be used interactively by FTP users, or through applications that need access to SNA host data.

Figure 12.16 APPC FTP and FTP-AFTP Gateway Services

To run the FTP-AFTP Gateway Service, you must first install the FTP or AFTP client software as well as the AFTP service on the SNA Server–based computer.

Shared Folders

Users on workstations that do not have the SNA Server Client software installed, but who still require file transfer capabilities with an AS/400 host, can use the Shared Folders Gateway Service provided by SNA Server. With this service, network users can share or store files on the AS/400 system as though it were another volume on the SNA Server–based computer, as shown in Figure 12.17.

Figure 12.17 Using the Shared Folders Gateway Service


APPC Deployment Strategies

In most cases, deployment strategies are effective for APPC LUs regardless of the application that the LUs support. When deploying APPC connections with SNA Server, you should consider how to use the following types of LUs and LU configurations:

  • Independent LUs
  • Dependent LUs
  • LU pools

Using Independent APPC LUs

An independent LU can communicate directly with a peer system and does not need the support of a host computer. Independent APPC LUs, as used in AS/400 APPN networks, provide the ability to run multiple, concurrent, parallel sessions between a local and remote LU pair.

When configuring independent APPC LUs, you should note that when SNA Server is used to communicate with a TP on a mainframe over an independent APPC LU, the host system must be running VTAM V3R2 or later. The version of Advanced Communication Function/Network Control Function (ACF/NCP) required on the mainframe is dependent on the type of FEP used. For 3725 systems, ACF/NCP V4R3 or later is required. For 3745 systems, ACF/NCP V5R2 or later is required.

Instructions on configuring independent APPC LUs can be found in the SNA Server documentation.

Using Dependent LUs

A dependent local APPC LU requires the support of a mainframe to communicate with a remote TP. Dependent APPC LUs cannot be used to communicate with AS/400s. Unlike independent APPC LUs, dependent APPC LU only allow a single session for each LU.

Dependent APPC LUs are useful when configuring SNA Server to communicate with a mainframe using a version of VTAM earlier than V3R2 because independent LUs are not supported in earlier VTAM versions. Support for dependent APPC LUs is provided with SNA Server for compatibility with older VTAM versions. However, whenever possible, independent LUs should be used.

When configuring APPC dependent LUs, you should specify the network name and LU name, even though they are not required. They are used by software running on the SNA Server–based computer, such as the Windows 2000 Event Log. For example, if a remote APPC LU is partnered with a dependent local APPC LU, naming the remote APPC LU helps to identify any events associated with the it in the Windows 2000 Event Log.

Information about configuring dependent APPC LUs can be found in the SNA Server documentation.

Using LU Pools

Although you can create individual LUs and assign them to users and groups, using LU pools to manage and deploy a large number of LUs lets you administer these resources more efficiently.

LU pools also allow groups of intermittent users to use a limited number of host resources more efficiently. Dedicating LUs to specific users who occasionally require host access wastes host resources. Using a pool, you can assign a smaller number of LUs to a group of users who require sporadic access. For example, if a group of 100 users require host access 25 percent of the time, assigning a pool of 25 LUs to the group may meet their requirements.

For information about configuring LUs, see the SNA Server documentation and the Microsoft BackOffice Resource Kit.


Providing Fault Tolerance

In the AS/400 environment, SNA Server uses a combination of LU names and LU aliases over one or more servers to achieve transparent fault-tolerant connections to an AS/400, as shown in Figure 12.18.

Figure 12.18 Hot Backup Across Connections and Servers

A single computer running SNA Server can use multiple connections to provide fault tolerance. To use this method, two or more APPC connections to the same AS/400 are configured as hot backups for one another. If one of the connections fails, the clients are reconfigured to select a working configuration.

SNA Server can also use multiple SNA Server–based computers as backups for one another. If one of the servers fails, the clients are shifted from the failed server to a working server.

Using a combination of hot backup across both connections and servers is recommended to maintain a high level of host availability in your enterprise.

For more information about configuring hot backup for APPC connections, see the SNA Server documentation.


TN5250 IP Settings

IP settings assigned to the TN5250 definitions allow TN5250 clients to connect to the AS/400. By default, the TN5250 definition is not assigned an IP address or a subnet mask. This allows any TN5250 client to connect to the AS/400.

You can restrict access to the TN5250 service by specifying the IP address or subnet mask of a client workstation. When these values are specified, only clients whose IP and/or subnet mask match those specified in the TN5250 configuration are allowed access to the AS/400 through the TN5250 service. You can also specify the workstation name in place of the IP, and use a WINS, DHCP, or other name resolution service to resolve a friendly name to an IP address.


SNA Remote Access Service

SNA Remote Access Service (SNA remote access) integrates the LU 6.2 transport of SNA Server with Windows 2000 Remote Access Service (remote access), allowing administrators to create virtual LAN connections between Windows 2000 systems across an existing SNA network. Figure 12.19 shows how, using SNA remote access, the SNA network acts as a network backbone, passing network traffic between the Windows 2000 systems bridged with the host system.

Figure 12.19 SNA Remote Access Service (SNA remote access)

The functions available with SNA remote access are the same as those for remote access over ISDN or X.25 except for the dial-back connection feature, which is not supported by SNA remote access. The SNA remote access Service supports either the Windows 2000 Server remote access or Windows 2000 remote access client, depending on whether the computer on which SNA remote access is installed is an SNA Server–based client or server. In addition, a computer running Windows 2000 Professional, SNA Server Client software, and SNA remote access can dial out through the SNA Server–based computer that is running SNA remote access.

Because legacy SNA networks may include smaller bandwidth links like SDLC, and because LAN traffic typically generates more network traffic than can be effectively handled by slower connections, care should be taken to resolve bandwidth needs before deploying SNA remote access in your enterprise.

For information about configuring SNA remote access, see the SNA Server documentation.


Heterogeneous Client Services

SNA Server supports the LU types (and equivalent Telnet-based applications) and application programming interfaces (APIs) that support the most commonly used configurations for many desktop operating systems, including:

  • Windows NT
  • Windows 95
  • Windows 3.x
  • MS-DOS
  • IBM OS/2
  • Macintosh
  • UNIX-based operating systems


Integrating Heterogeneous Clients with Mainframes

Table 12.6 summarizes SNA Server client-to-mainframe services supported on each desktop platform.

Table 12.6 Heterogeneous Client to Mainframe Integration

Desktop Platform | LU Types/Telnet Services | SNA APIs
MS-DOS | LU0, LU1, LU2, LU3, and LU6.2. TN3720, TN3287, and TN3270E. | APPC, CPI-C, Common Service Verb (CSV), and LUA Request User Interface (RUI).
Windows 3.x, Windows for Workgroups | LU0, LU1, LU2, LU3, and LU6.2. TN3720, TN3287, and TN3270E. | APPC, CPI-C, CSV, LUA RUI, LUA Session Level Interface (SLI), and ODBC/DRDA.
OS/2 | LU0, LU1, LU2, LU3, and LU6.2. TN3720, TN3287, and TN3270E. | APPC, CPI-C, CSV, LUA RUI, and LUA SLI.
Macintosh | TN3720, TN3287, and TN3270E. | (Uses Telnet-based services.)
UNIX1 | LU0 and LU6.2. TN3720, TN3287, and TN3270E. | APPC, CPI-C, CSV, and LUA RUI.
Windows 95 and Windows 98 | LU0, LU1, LU2, LU3, and LU6.2. TN3720, TN3287, and TN3270E. | APPC, CPI-C, CSV, LUA RUI, LUA SLI, ODBC/DRDA, and AFTP.
Microsoft® Windows NT® Workstation 4.0 and Windows 2000 Professional | LU0, LU1, LU2, LU3, and LU6.2. TN3720, TN3287, and TN3270E. | APPC, CPI-C, CSV, LUA RUI, LUA SLI, ODBC/DRDA, and AFTP.
1 The UNIX client can use services beyond the Telnet-based services by using a third-party UNIX client for SNA Server developed by Parker Software in cooperation with Microsoft. For more information about the UNIX client for SNA Server, see http://www.microsoft.com/sna.

Session Types with Mainframes

SNA Server supports standard terminal and printer sessions with LU types 0 through 3. LU 0 is a device-independent LU used mainly in the financial industry to support teller terminals and automatic teller machines. LU types 1 and 3 are used to support printer emulation programs on client and server computers, including SNA Server’s Host Print Service. LU type 2 provides terminal emulation support for a broad range of client 3270 emulator programs.

LU 6.2 supports Application Program-to-Program Communications (APPC), Common Program for Communications (CPI-C) and Common Service Verbs (CSV). These APIs allow client- and server-based transaction programs and other processes to communicate with host systems, such as those running under IBM Customer Information Control System (CICS) and Information Management System (IMS). An example of a transaction-based process is a magnetic credit card reader at a point-of-sale terminal, such as a computer-based cash register that communicates from a branch store location to the home office through an SNA Server connection. The process to validate the cardholder’s credit status uses APPC as the API supporting the transaction.

Host Utilities with Mainframes

As shown in Table 12.6, SNA Server offers a number of utilities that complement standard terminal and printer emulation sessions. One such utility is APPC File Transfer (AFTP). AFTP is part of a group of applications supported by the IBM APPC applications suite running on OS/390, MVS, VM, or OS/400.

As a server-based solution, AFTP works with SNA Server’s FTP-to-AFTP gateway to provide a seamless means for clients to send and receive flat files to and from host systems. SNA Server converts the FTP commands to AFTP and uses APPC between the SNA Server–based computer and the host system. This allows the client to use an open TCP/IP protocol, while the host runs only its native SNA protocols. The result is greater efficiency and simplified management at the client and the host system.

Application Programming Interfaces with Mainframes

SNA Server includes a Software Development Kit (SDK), with online documentation and source code examples. This SDK provides the means to build complete AFTP, APPC, CPI-C, CSV, LUA solutions, as well as add-on products to SNA Server core functionality. LUA is a customizable API that allows you to develop either at a low level in the SNA protocol stack, at the Request User Interface (RUI), or at a higher level, at the Session Level Interface. These APIs are commonly used by large institutional organizations building upon their legacy of banking and insurance applications, many of which had previously relied upon specialized control unit devices, such as the IBM 4147 financial series controller.

One series of APIs not directly supported by the SNA Server SDK are HLLAPI, EHLLAPI, and WinHLLAPI, High Level Language API, Extended HLLAPI, and Windows HLLAPI.

SNA Server APIs comply with the Windows Open Service Architecture (WOSA) guidelines. This means that on all Windows operating systems, the SNA Server APIs are WOSA versions: WinAPPC, WinCPI-C, and WinCSV.

Several independent software vendors (ISVs) contributed to the WOSA SNA API standards, among them IBM and Novell. Most major Windows SNA ISVs support WOSA APIs directly in their products, including Andrew, Attachmate, Eicon, NetManage, NetSoft, Wall Data, and WRQ. SNA Server’s APIs comply with the standards published for other common operating systems as well. For example, on MS-DOS and OS/2, SNA Server APIs are binary compatible with IBM’s Communications Manager/2 standards.

SNA client emulation vendors also support host connectivity through SNA Server by adapting their products to support the SNA Server Function Management Interface (FMI)—also called the Emulator Interface Specification (EIS). The FMI or 3270 EIS API is encapsulated in the SNA Server Client software. The emulator communicates with this SNA Server Client software, which in turn communicates with SNA Server through an SNA Server client/server connection. When you use a full-featured 3270 emulator with SNA Server, you are connecting to the SNA Server through the FMI. FMI supports LU types 1 through 3.


Integrating Heterogeneous Clients with AS/400 Systems

SNA Server supports the LU types (and equivalent Telnet-based applications) and application programming interfaces (APIs) that support the most commonly used configurations for all popular desktop operating systems. Table 12.7 describes in detail SNA Server client-to-AS/400 services.

Table 12.7 Heterogeneous Client to AS/400 Integration

Desktop Platform | LU Types/Telnet Services | SNA APIs
MS-DOS | LU 6.2 (terminal and printer emulation) and TN5250. | APPC and CPI-C.
Windows 3.x, Windows for Workgroups | LU 6.2 and TN5250. | APPC, CPI-C, CSV, EHNAPPC, and ODBC/DRDA.
OS/2 | LU 6.2 and TN5250. | APPC, CPI-C, and CSV.
Macintosh | TN5250. | (Uses Telnet-based services.)
UNIX1 | TN5250. | APPC, CPI-C, and CSV.
Windows 95 and Windows 98 | LU 6.2 and TN5250. | APPC, CPI-C, CSV, EHNAPPC, ODBC/DRDA, and AFTP.
Windows NT Workstation 4.0 and Windows 2000 Professional | LU 6.2 and TN5250. | APPC, CPI-C, CSV, EHNAPPC, ODBC/DRDA, and AFTP.
1 The UNIX client can use services beyond the Telnet-based services by using a third-party UNIX client for SNA Server developed by Parker Software in cooperation with Microsoft. For more information about the UNIX client for SNA Server, see http://www.microsoft.com/sna.

Session Types with AS/400 Systems

SNA Server supports all AS/400 session types on most popular desktop operating systems using LU type 6.2. Some older client emulators use LU type 4 for printer emulation and LU type 7 for terminal emulation. However, SNA Server and most modern client emulators support standard 5250 terminal and printer emulation through LU type 6.2 and APPC.

SNA Server supports Macintosh and UNIX clients through the TN5250 Service, which provides basic terminal emulation. However, teamed with the Host Print Service, Shared Folders Service, and FTP-to-AFTP Gateway, SNA Server can satisfy all Macintosh and UNIX client needs.

Host Utilities with AS/400 Systems

Utilities based on a computer running SNA Server offer administrative control of desktop-to-AS/400 connectivity. For example, SNA Server offers an optional Shared Folders Service that allows any Windows 2000 Server–based client to access AS/400 files without any special SNA software or protocols being installed on the client computer. Another example is the Host Print Service, which places printer emulation on the computer running SNA Server. Both of these utilities concentrate administration at the server and alleviate the need for configuration of advanced features on the client computers.

Application Programming Interfaces with AS/400 Systems

AS/400 connectivity through SNA Server is fully compatible with EHNAPPC and supports the full range of Client Access/400 functions, including: shared folders, virtual print, and file transfer. EHNAPPC is the standard Windows-based API supported by IBM’s PC Support and Client Access/400 (CA/400) products. IBM has presented EHNAPPC to its ISV community as the way to write Windows-based applications that integrate with the AS/400.

The SNA Server Client software for Windows 32-bit operating systems can also support 16-bit Windows-based APPC and CPI-C applications that map the 16-bit APPC and CPI-C APIs to the native 32-bit SNA APIs. This allows users to run many of the 16-bit Windows-based applications that work with SNA Server in Windows 32-bit environments.

For more information about configuring and managing SNA Server Client software, see the SNA Server documentation.


Host Print Services

SNA Server supports three methods of printing host information to local or network-accessible printer resources.

  • Screen Printing

    Allows any 3270 or 5250 emulator to print what is on the display using the print screen features of the client operating system. The printer output can be directed to a printer attached to the client computer or to a network-accessible resource.

  • Client-based Redirected Printing

    Delivers an SNA host printer data stream (such as 3287) to the appropriate emulation application running on an SNA Server-based client. The client software converts the data stream into data that can be output to a locally attached or network-accessible printer resource.

  • Server-based Redirected Printing

    Uses a server process to convert SNA host printer data streams into data that can be redirected to a locally attached or network-accessible printer resource defined with the Windows 2000 Server Printer Manager.

The first two methods are provided using third-party products. The third method is supported by the SNA Server Host Print Service and third-party products.


SNA Server Host Print Service

The Host Print Service provides server-based 3270 and 5250 printer emulation, allowing host applications to print to a LAN printer supported by Windows 2000 Server or Novell NetWare. You can administer all Host Print Service functions using SNA Server Manager and control print characteristics, such as margin control and fonts. Printer output can also be redirected to files that are saved with incremental file names.

Each host printer definition also allows printing filters to be associated with print sessions. Filters are provided through third-party applications that allow the Host Print Service to participate in APF and other specialized print environments.

Mainframe Printing

For mainframe environments, shown in Figure 12.20, the Host Print Service supports both LU 1 and LU 3 print data streams, including transparent print jobs sent by host-based print preprocessors.

Figure 12.20 Mainframe Printing

To print 3270 print jobs, you need to perform the following steps in SNA Server Manager:

  • Define the session name, which is a descriptive name to identify different printers on the network.
  • Create a 3270 printer LU.
  • Assign the LU to the print session.

For more information about configuring mainframe print sessions, see the SNA Server documentation.

AS/400 Printing

For AS/400 printing, shown in Figure 12.21, the Host Print Service supports standard SCS line printing, and pass-through support for host-based 3812 graphics printing emulation using the IBM Host Print Transform function.

Figure 12.21 AS/400 Printing

For more information about configuring an AS/400 print session and customizing printer output, see the SNA Server documentation.


LAN-to-Host Security

As your network becomes integrated with the Internet and other external networks, the threat of unauthorized access to your network resources grows significantly. When you plan your networking environment, you must strike the right balance between protecting your resources and allowing your users unobstructed access.

As you plan how to secure your SNA Server environment, you should consider methods to:

  • Authenticate users who require host resources.
  • Control access to host resources.
  • Control sensitive data flowing between workstations and host applications.
  • Maintain security while connecting your host network to external sources like the Internet.
  • Make host resources easier to access for authenticated users, yet maintain a secure and easy-to-administer host environment.

The following sections address each of these issues and describe how to implement SNA Server security features and Windows 2000 security features to create a secure LAN-to-host environment.

For more information about Windows 2000 security, see the Microsoft® Windows® 2000 Distributed Systems Guide.


Authentication

When SNA Server receives a request for access to a host resource, such as an LU for a terminal session, the server must have some way to verify the request. User validation is a fundamental security issue that is addressed using one of two methods depending on the type of service being requested: domain authentication or workstation authentication.

Domain Authentication

A Windows 2000 Active Directory domain is a group of computers that share a common user account database and have a common security policy. An Active Directory domain contains domain controllers that store security information and replicate that information to other domain controllers.

Within a Windows 2000 domain, computers running SNA Server are logically grouped into entities called subdomains, as shown in Figure 12.22. Each SNA Server subdomain can contain up to 15 SNA Server–based computers. A Windows 2000 domain may contain an unlimited number of these subdomains.

Figure 12.22 SNA Server Subdomains Located in Windows 2000 Domains

SNA Server relies on the Windows 2000 domain to provide authentication services to users requesting access to host resources (see Figure 12.23). Only users who have been validated by Windows 2000 security can gain access to resources provided by servers in the SNA Server subdomain.

Domain authentication is used to verify the identity of users who request resources provided by the following services:

  • or 5250 terminal access from workstations using SNA Server Client software.
  • AS/400 Shared Folders Gateway Service.
  • Host Print Services.
  • APPC, CPI-C, or LUA that use SNA Server APIs.

Figure 12.23 Domain Authentication Process for 3270 Terminal Access

Each user who needs access to SNA Server resources must have a Windows 2000 domain account. Once enrolled as a Windows 2000 domain user, the user’s account is added to the SNA Server subdomain. After a user is added to the SNA Server subdomain, you can allocate specific SNA resources to that user.

Note

Each computer running SNA Server also needs its own Windows 2000 domain account through which SNA Server services are run. SNA Server uses this account to log on to the domain to perform such functions as host printing and data encryption using the Distributed Link Services.

Workstation Authentication

Hold this section until NT5 version of SNA Server has specs. This may all change or should become unnecessary because external users can use public key certificates that are mapped to Kerberos accounts will full ACL control. Check with SNA Server PMs.


Resource Allocation

In most cases, you need to control who can access SNA Server resources in your environment. The method you use to secure those resources depends on your host environment and the types of services you wish to offer your users.

3270 Terminal Access

Users or groups who require access to 3270 sessions from workstations using SNA Server Client applications must be members of the SNA Server subdomain. By virtue of their subdomain membership, users and groups are also members of the Windows 2000 domain of which the subdomain is a part. Once enrolled in the SNA Server subdomain, you can assign specific 3270 (LU type 2) resources to the appropriate accounts. Users can access only the specific resources you allocate to them.

To maintain security in your environment, it is recommended that you use domain security to authenticate users, and then limit their access by assigning them only specified resources.

5250 Terminal Access and APPC Access

Users who want Advanced Peer-to-Peer Communications (APPC) access need not be defined in the SNA Server subdomain, but they must be members of the Windows 2000 domain. For 5250 terminal access using a computer running SNA Server Client software within the network, the AS/400 supplies the required logon security for access to the AS/400. For APPC access programmed into specific applications, security is maintained through the actual programmatic conversation, if required.

TN3270 and TN5250 Services

TN3270 and TN5250 services are secured by specifying client workstation IP addresses that have permission to use the resources provided. In the case of TN3270E clients, a workstation name can be specified in place of the client IP address. The method used to verify workstations can also be used to allow only specified IPs to request resources allocated to them.

Shared Folder Services

Access to AS/400 shared folders that are made available to Windows 2000 domain users using the Shared Folders Gateway Service can be controlled by specifying permissions for the resulting shared volumes and files. Permissions are set using the standard Windows 2000 method for local shares.

In some cases, you may want to provide open-ended access to LUs provided by SNA Server. To allow unrestricted access through Windows 2000 domain–authenticated services, you can use the Guest account or the Everyone group account.

To provide access using the Guest account, enable the account in the Windows 2000 domain as described in Windows 2000 Server Help. Add the Guest account to the SNA Server subdomain, and assign LUs to the account.

To provide access using the Everyone account, add the Everyone account to the SNA Server subdomain and assign LUs to the account.

To allow unrestricted access to TN3270 or TN5250 services, you can create LUs without specifying an IP or workstation name for each.


Data Encryption

SNA Server allows you to encrypt data for client-to-server and server-to-server communications, as shown in Figure 12.24.

Figure 12.24 Model of Client-to-Server and Server-to-Server Data Encryption

Client-to-server encryption prevents information from being sent in clear text between computers running SNA Server Client software and computers running SNA Server. Data encryption enhances network security on the client-to-server communications path for all applications using SNA Server Client connections, including 3270/5250 emulators and APPC logon IDs and passwords. Data encryption can be enabled on a user-by-user basis using the SNA Server Manager.

Server-to-server encryption can be used to provide secure communications across your network, the Internet, or any other wide area network (WAN). If a user enables data encryption, information transferred through the Distributed Link Services is secure.


Firewall Support

A firewall is a network security device that restricts access to network resources by allowing traffic only through specified port numbers. In many instances, the services of a firewall are provided in conjunction with a network router that bridges two network segments together.

If the SNA Server address is known, the client workstation configures the appropriate port and destination IP of the computer running SNA Server in the client software (1477 and 128.124.1.2, respectively, in Figure 12.25 below). Alternatively, the SNA Server–based computer’s service port numbers can be changed to the port number requested by the client.

Figure 12.25 Using SNA Server with a Firewall

If the SNA Server address is not known, the SNA Server IP transport replaces the real destination IP address with the address of a firewall. The firewall then maps the connection request to the actual computer running SNA Server. This takes place when the transport opens a connection to an SNA Server–based computer for application sessions or a sponsor connection.

SNA Server supports firewalls primarily on TCP/IP networks. It may also be possible to implement firewalls on IPX/SPX or Banyan VINES networks. Consult your network documentation for information about configuring a firewall in your specific installation.


Host Security Integration

In an enterprise-wide computing environment, users are likely to access different networking environments as they go about their day-to-day routines. A user may begin the day by turning on a computer running Windows 2000 Professional, logging on to a Windows 2000–based network, and then accessing an AS/400 database application through a terminal emulator.

Each system with which the user comes into contact enforces its own security requirements and logon procedures. For example, a Windows 2000 domain account may require a six-character user name and an eight-character, mixed-case password, whereas a mainframe environment may require a seven-character user name and seven-character alphanumeric password.

Frequently, users have to remember several different combinations of user names and passwords to gain access to various resources on the network. Despite policies to the contrary, users who must maintain multiple passwords often resort to writing their passwords down and keeping them in a convenient location near their computer, compromising network security.

One of SNA Server’s most powerful security features is its ability to integrate the Windows 2000 domain security environment with your host security system. The Host Security Integration feature is a combination of tools and services that automate the process of synchronizing passwords and logging on to the different systems. Using these tools can help your users uphold corporate security standards and ease the administration required to maintain user accounts on your network and your host system.

Host Security Integration Components

Host Security Integration uses a host security domain concept to manage user accounts on your network and your host system. Your host security domain defines the different security domains that share a common user accounts database. A simple security domain may consist of a host domain, a Windows 2000 domain, and an SNA Server subdomain, as shown in Figure 12.26.

Figure 12.26 Elements of a Typical Host Security Domain

Host Security Integration is composed of three separately installable components:

  • Host Account Cache
  • Host Account Synchronization Service
  • Windows 2000 Account Synchronization Service

Host Account Cache

The Host Account Cache maintains an encrypted database that maps host user accounts to Windows 2000 domain user accounts. The Host Account Cache is a Windows 2000 service that is installed on Windows 2000 domain controllers. For smaller networks, SNA Server itself may be installed on a Windows 2000 domain controller and, therefore, can be used to store the Host Account Cache.

Optionally, a backup Host Account Cache can be installed on any other Windows 2000 domain controller. The backup cache maintains a local copy of the user database for recovery purposes, or to eliminate network traffic for single sign-on lookups when installed on the same computer as SNA Server.

Host Account Synchronization Service

Host Security Integration Service is an SNA Server installation option that contains the Host Account Synchronization Service. This service can be installed on primary, backup, or member computers running SNA Server within the SNA Server subdomain. For more information about SNA Server roles, see “Determining SNA Server Roles” earlier in this chapter.

You may also install the service on non-SNA Server-based computers. The Host Account Synchronization Service supports third-party interfaces to various host security databases, allowing you coordinate password changes between the Windows 2000 security domain and the host security domain.

The Host Account Synchronization Service is not necessary if you use the single sign-on feature with manual password updates in which the administrator or users store host account information in the Host Account Cache through the Host Account Manager application (UDConfig). For more information about using the UDConfig tool, see the SNA Server documentation and the Microsoft BackOffice Resource Kit.

Windows 2000 Account Synchronization Service

The Account Synchronization component lets you automatically synchronize the passwords for your host accounts and Windows 2000 domain accounts. This component includes the Windows 2000 Password Synchronization Service and must be installed even if automatic password synchronization is not used because it coordinates the internal operation of other services.

The Windows 2000 Account Synchronization Service is installed on a Windows 2000 domain controller. Only one instance of the Windows 2000 Account Synchronization Service can be designated as primary; all others must be backup servers.

The ability to synchronize passwords from the Windows 2000 domain to an AS/400 security domain is built into SNA Server. Third-party products can provide enhanced synchronization services, such as two-way and automatic synchronization, to other host systems.

Password Synchronization Options

When you define your host security domain, a Windows 2000 group account is automatically created with the same name. User accounts are then added to the group to specify them as members of the host security domain. Once a host security domain is defined, two types of password synchronization options are available to you:

The Replicated option assumes that you would like to have the same user name or password on each security domain defined in the host security domain.

The Mapped option allows you to have different account names and passwords in each security domain. A database controlled by the Host Account Cache Service maintains the associations between the various accounts and passwords.

You can specify either of these options for the user name and either of them for the password of a user account. For example, you can choose to map the user names but replicate passwords across the different security domains. This allows you to have the same password but different user names on the different systems in the host security domain.

Once defined, host connections are assigned to the domain. SNA Server uses the assignment to look up the host mapping for a Windows 2000 user based on the session he or she is trying to open. A defined host connection can only be assigned to one security domain at a time.

After the connections are assigned to a host security domain, you can add users to the security domain by adding user accounts to the Windows 2000 group account created earlier. For each account associated with the host security domain, you can enable password synchronization options and automated logon features commonly referred to as single sign-on services. Single sign-on allows users to log on to their host account automatically if they are already logged on to their Windows 2000 domain account.

If you are planning to map user names, perform and store the initial mapping of host user names to Windows 2000 domain user names in the Host Account Cache.


Automating Password Synchronization

Within the SNA Server network, automated, one-way, LAN-to-AS/400 password synchronization is supported without any additional tools or products. In this scenario, the Host Account Synchronization Service, the Windows 2000 Account Synchronization Service, and the AS/400’s host security system interoperate to provide password synchronization for SNA Server users.

In other corporate network environments, third-party tools are required when implementing automated, two-way password synchronization or mainframe support. On a network, the Host Account Synchronization Service, the Windows 2000 Account Synchronization Service, and third-party security integration dynamic-link libraries (DLLs) cooperate with each other to support password synchronization. On the host, third-party products are usually required to facilitate password synchronization.

These components collectively allow two-way password synchronization between Windows 2000 and AS/400 or mainframe host computers. Changes made on one host can be replicated to other Windows 2000 or host computers. Similarly, changes to your Windows 2000 security domain can be automatically sent to all host computers.

Host-Initiated Changes

For host-initiated changes, third-party software must be installed on the host system to trap password changes initiated by users logged on to the host computer, and on the SNA Server–based computer to receive changes from the host.

When a change is made on the host system, the host computer sends notification of changes to a third-party product’s security integration DLL, which is installed on the computer running SNA Server. The DLL then forwards the host-initiated changes to the Host Account Synchronization Service. This service then locates the network address of the primary Windows 2000 Account Synchronization Service using the resource location of the master Host Account Cache.

After the Host Account Cache is located, the Host Account Synchronization Service sends password changes to the Host Account Cache service using encrypted remote procedure call (RPC) messages. Once the changes are received by the service, it propagates the appropriate changes in all security domains defined in the host security domain.

Windows 2000–Initiated Changes

Windows 2000–initiated password synchronization works in a similar manner to host-initiated changes.

The Windows 2000 Account Synchronization Service is installed on a domain controller in one or more Windows 2000 domains. An associated DLL, installed in the same location, receives notice of any password changes that arise in the Windows 2000 domain, regardless of how the change was initiated. The DLL sends Windows 2000–initiated changes to the Windows 2000 Account Synchronization Service using encrypted RPC messages. Once the change is received, the service propagates the appropriate changes in all affected security domains.


Automating Logons

SNA Server can also automate the process of logging on to your host system as shown in Figure 12.27. This feature, commonly called single sign-on support, automatically logs users on to all security systems in a host security subdomain once they have been validated by any system within the subdomain. For example, if a user is logged on to the Windows 2000 domain, single sign-on can automate logon processes to host systems that are encompassed by the defined host security domain.

Figure 12.27 Automatic Logon Process

The following steps describe the automatic logon process, as illustrated in Figure 12.27:

  • Step 1

    When a user starts a terminal emulator or other SNA application on a client workstation, the application works with the SNA Server subdomain to perform a resource location operation to determine which SNA Server–based computer and connection to use to open the session.

    The SNA application provides a replacement keyword as a placeholder for security information during the session initialization phase. The exact format of this keyword is dependent on the type of LU session being established. For example, the string “MS$SAME” is used for APPC or CPI-C applications.

    SNA Server detects the replacement keyword and determines the Windows 2000 user name under which the client is logged on. Because this step requires the support of Windows 2000 domain authentication, the ability to be logged on automatically is only supported for users running native client/server sessions (for example, sessions using a computer running SNA Server Client).

Note

TN3270 users are not supported because the TN3270 service cannot determine the client’s Windows 2000 user name.

  • Step 2

    Once the user name is determined, the computer running SNA Server uses the resource location to locate the Host Account Cache in the SNA Server subdomain. The cache may be located on either the actual computer running SNA Server or on a Windows 2000 domain controller in the SNA Server subdomain depending on your installation. SNA Server then sends a lookup message to the Host Account Cache that contains the Windows 2000 user name and password, and requests the corresponding host user name and password.

    The Host Account Cache service verifies that the Windows 2000 account exists in the database, and that the account is a member of the Windows 2000 group in the host security domain. If either check fails, the user record is purged from the Host Account Cache.

  • Step 3

    If all checks pass, the service replies to the computer running SNA Server with a message containing the appropriate host account user name and password in an encrypted RPC network message.

  • Step 4

    SNA Server inserts the host account name and password into the SNA data stream, and sends a regular session initialization request to the host computer.

  • Step 5

    The host computer receives the regular session initialization request containing the correct host account information and authenticates the user.

    SNA Server natively supports single sign-on to an AS/400 host system. Single sign-on features are also available for APPC and CPI-C applications on both mainframes and AS/400 systems using third-party products. For a list of supported third-party vendors, see the SNA Server Web site at http://www.microsoft.com/sna/.

For more information about SNA Server security and security integration, see the SNA Server documentation and the Microsoft BackOffice Resource Kit.


Host Data Access

One of the primary purposes of integrating Windows 2000 networks with IBM host systems is to provide users with access to host data. Host systems have long excelled at providing database-related services. In many mid- to large-sized companies, host databases are used to store and process large amounts of information needed by users across an enterprise network. Because of their availability and performance, host systems continue to play a large role in data warehousing strategies for many organizations.

As companies adopt LAN-based desktop computers, many organizations are looking for ways to integrate host database systems to develop new client/server applications accessible from a user’s workstation. Using SNA Server, you can access host data sources through one of the following features:

  • Open Database Connectivity (ODBC) Driver for DB2, for access to Distributed Relational Database Architecture (DRDA) database systems using ODBC interfaces.
  • OLE DB Provider for AS/400 and VSAM, for record-level access of host data using OLE DB data access interfaces.
  • Microsoft SQL Server Host Data Replicator, works with SNA Server to provide high performance, bi-directional data replication between DB2 host databases and Microsoft SQL Server.

The first two methods are included with SNA Server. Host Data Replicator is a feature of Microsoft SQL Server version x.x.

The following section describes how each feature is used and which data access method best suits a given scenario.


Host Data Access Using ODBC

SNA Server lets applications designed to use the Open Database Connectivity (ODBC) interface and Structured Query Language (SQL) commands access host databases. Using the ODBC Driver for DB2, ODBC-enabled applications can be used to access and manipulate databases on a host system that uses the Distributed Relational Database Architecture (DRDA) protocol to manage distributed data without requiring a host-based database gateway. Drivers are provided for Windows NT, Windows 2000, Windows 95, Windows 98, and Windows 3.x. SNA Server–based clients are installed during the client setup process.

Figure 12.28 depicts host data access using the ODBC Driver for DB2.

Figure 12.28 Host Data Access Using the ODBC Driver for DB2

The ODBC Driver operates by translating commands between the SQL and DRDA systems as shown in Figure 12.28. Each driver accepts SQL requests from a client application through ODBC, translates them to DRDA commands, and then sends them to the host system. The host processes the DRDA commands and returns the results to the driver on the client computer through SNA Server. The driver then converts the DRDA information to SQL data and passes the data back to the client application using the ODBC interface.

The ODBC Driver supports the following features:

  • Transaction commit and rollback
  • Asynchronous processing
  • Canceled queries
  • Primary and foreign keys
  • Four levels of transaction isolation

The driver also supports the ability to pass SQL strings directly to the host database with translation. Supported database systems include:

  • DB2 for MVS
  • SQ/DS for VM and VSE
  • DB2/400 for OS/400

For information about specific ODBC functions and data types supported by the ODBC Driver, see the SNA Server online documentation.


Host Data Access Using OLE DB

SNA Server provides record-level access to mainframe and AS/400 files using the OLE DB Provider for AS/400 and VSAM feature.

Leveraging the advantages of OLE DB as a common interface to dissimilar data sources, as shown in Figure 12.29, OLE DB Provider for AS/400 and VSAM lets you:

  • Customize solutions for reading from and writing to AS/400 and mainframe file systems without first migrating the information to the client/server platform.
  • Integrate nonstructured data with desktop and server-based databases and tools.
  • Develop applications using high-level interfaces, such as ActiveX Data Objects (ADO), which support Microsoft® Visual Basic® (VB), Microsoft® Visual C++® (VC++), Microsoft® Visual J++™ (VJ++), Microsoft® Visual Basic® for Applications (VBA), and Microsoft Scripting.

By providing applications with the ability to access and manipulate host files at the record level, you can leverage investments in host-based storage, management, backup, and security systems.

Figure 12.29 Host Data Access Using OLE DB Provider for AS/400 and VSAM

OLE DB Provider uses the record-level input/output (RLIO) protocol of the IBM Distributed Data Management (DDM) architecture (level 2 and higher). This feature is implemented as a source DDM requester and interoperates with target DDM server implementations on most popular host environments, including MVS/ESA, OS/390, and OS/400.

Client applications communicate with a host database through an APPC (LU 6.2) connection to the host system established between the SNA Server Client software and SNA Server.

OLE DB Provider supports the following features:

  • File and record locking
  • File and record attribute preservation
  • Indexed and sequential record access
  • Fixed and variable logical record length

OLE DB Provider supports a variety of data file types for mainframe and AS/400 systems. For mainframe systems, OLE DB Provider supports SAM data sets, including BSAM and QSAM; VSAM data sets, including ESDS, KSDS, RRDS, VRRDS; alternate index for ESDS and KSDS data sets; and PDS/PDSE members. For AS/400, OLE DB Provider supports keyed and non-keyed physical files and logical files.

Complete information about using the OLE DB Provider for VSAM and AS/400 is provided in the Microsoft® SNA Server Software Development Kit, included with SNA Server.

Microsoft SQL Server Host Data Replicator

Insert H1 and info when available in SQL Server version x.x


Choosing a Host Data Access Method

The method with which you choose to integrate host databases depends on how you want to provide access to the database systems.

Enterprises that want to use ODBC-aware applications and SQL commands to access and manipulate tables on the host can use the ODBC/DRDA Driver. The widespread support of ODBC in many desktop applications, such as Microsoft Excel and Microsoft Access, makes it easy to create host-driven client/server solutions based on existing desktop applications.

In many environments, the OLE DB Provider for AS/400 and VSAM feature can be configured to perform the same functionality as the ODBC/DRDA Driver. In enterprises where little or no SQL expertise is present, however, OLE DB Provider is the better choice because no SQL understanding is required to access and manipulate host tables.

OLE DB support for the ADO interface in a wide variety of development environments, such as VB and VC++, also makes OLE DB Provider a good choice for highly customized client/server applications.


Host Application Integration Using COMTI

As SNA networks are integrated with client/server-based networks, many organizations are investigating ways to leverage the power of host systems to run new client/server applications accessible from the personal computer. One method is by using SNA Server’s COM Transaction Integrator (COMTI) feature for IBM’s Customer Information Control System (CICS) and IBM’s Information Management System (IMS).

COMTI simplifies the process of creating applications that consist of Automation clients running on the desktop or server with COBOL servers running under CICS or IMS. Any application or development platforms that support Distributed COM (DCOM) and Automation can use COMTI components. For example, an application written in VB, VBA, or VBScript, can provide access to host data from within Microsoft® Excel. This feature can also be used through Web browsers that connect to Microsoft® Internet Information Services (IIS).

COMTI provides an interface between Automation components and mainframe-based applications. Running on Windows 2000 Server, components appear as simple Automation servers that developers can easily add to their application. Behind the scenes, however, COMTI functions as a proxy that communicates with an application running on IBM's Multiple Virtual Storage (MVS) operating system.

Applications that run in part on Windows platforms and in part on the mainframe are distributed applications. COMTI supports all distributed applications that adhere to Automation and DCOM specifications, although not all parts of the application have to adhere to these standards.

COMTI is composed of three parts:

  • The Component Builder, which is used to create Automation components.
  • Microsoft Management Console (MMC), which is used to manage components created with the Component Builder.
  • The COM Transaction Integrator Runtime, which provides the Automation server interface for each component created with the Component Builder and which communicates with the mainframe programs. The runtime operates within MTS.

COMTI directly supports any transaction program (TP) that executes in CICS and is structured to use either distributed program linking or Advanced Program-to-Program Communication (APPC) verbs. It also directly supports IMS applications that are structured to use the IMS Message Queue. Because COMTI can access CICS programs, developers can extend the client application calls even further by using CICS to access any other program on an MVS mainframe, such as DB2.

Figure 12.30 shows how SNA Server can be integrated with a host application. A client application uses the COMTI feature hosted by MTS to access a TP running on the mainframe. The specific TPs supported by the feature are IBM’s CICS and IBM’s IMS. An example of this type of distributed application is one that reads a mainframe-based DB2 database to update data in a SQL Server database on Windows 2000 Server.

Figure 12.30 Integration with a Host Application

The client components can run on any platform that supports DCOM, including:

  • Windows NT Server
  • Windows NT Workstation
  • Windows 95 and Windows 98

Because DCOM is language-independent, developers can build their client applications using the languages and tools with which they are most familiar. Common client/server application development environments include:

  • Visual Basic (VB)
  • Visual Basic for Applications (VBA)
  • Visual C++ (VC++)
  • Visual J++ (VJ++)
  • Borland Delphi
  • Sybase Powerbuilder
  • Microfocus Object COBOL

Once created, the client components can make calls to the COMTI Automation object (or any other Automation object) registered on the computer running Windows 2000 Server.

Complete information about using COMTI, including sample applications, can be found in SNA Server COM Transaction Integrator Help.


Host Transaction Integration

Many organizations use host computer systems to support real-time transaction processing applications, such as IBM’s CICS. These applications are accessed through interactive sessions with the host system, such as a 3270 or 5250 session supported by a terminal emulator.

We have already described how the SNA Server’s COMTI feature can be used to access simple mainframe applications at the program level. This feature becomes an even more powerful tool when used to extend applications that use Windows 2000 Server MTS. Windows-based applications that use MTS can coordinate transactions with mainframe-based CICS applications.

When coupled with MTS, COMTI can be used for a variety of purposes:

  • Windows developers can describe, execute, and administer special MTS objects that access CICS or IMS transaction programs (TPs).
  • Mainframe developers can make mainframe TPs available to Windows-based Internet and intranet applications.
  • MTS component designers can include mainframe applications within the scope of MTS two-phase commit transactions.

Developers using MTS in their applications can decide which parts of the application require a transaction and which parts do not. COMTI extends this choice to the mainframe, as well, by handling both calls that require transactions and calls that do not.

For applications that require full integration between Windows-based two-phase commit and mainframe-based Sync Level 2 transactions, COMTI provides all the necessary functionality without requiring you to change the client application. Also, no executable code needs to be placed on the mainframe, and little or no changes to the mainframe TPs are required. The client application does not need to distinguish between the COMTI component and any other MTS component reference.

Figure 12.31 illustrates how a Windows-based client application implicitly uses the Distributed Transaction Coordinator (DTC) to coordinate a distributed transaction involving SQL Server and a CICS transaction program. The DTC is the part of MTS that coordinates two-phase commit transactions.

Figure 12.31 Integration with Host Transaction System

Complete information about using COMTI, including sample applications, can be found in the SNA Server documentation.


Transaction and Data Access Scenarios

COMTI should be considered for the following scenarios:

  • Application-level database integration.
  • COM integration with CICS and IMS.
  • ADO access to legacy data.
  • Integration of mainframe applications that own and control the host data. Transaction programs (TPs) often contain logic and data structures that define the rules for accessing host data. In some cases, these applications also contain integrity checks and consistency constraints. In these cases, accessing the host data through these TPs is the only safe option.
  • Positioning of mid-tier applications to take advantage of the scalability benefits MTS provides in addition to providing mainframe application access.
  • Deployment of high-integrity, distributed transaction systems that span Windows 2000, MVS/CICS, and other Extended Architecture (XA)–compliant environments that are MTS-enabled.
  • Mainframe connectivity only.

OLE DB Provider should be considered for these scenarios:

  • Record-level or file-level database integration.
  • OLE DB and ADO access to legacy data.
  • Rewriting of business rules, such as “Year 2000” solutions.
  • Direct access to host data without going through the host SQL processor.
  • Mainframe and AS/400 connectivity.

In some cases, you may wish to use both COMTI and OLE DB Provider to develop a complete host-connectivity solution.

Sample applications that use COMTI are installed when the COMTI component is selected during SNA Server setup. For more information about using the samples, see the samples folder on the SNA Server CD.


Web-to-Host Integration

The growth of the Internet and its related technologies has given corporate information technology departments new ways to extend client/server computing applications to both internal and external users. Information and resources that exist on internal, proprietary systems can now be accessed from a broader user base, giving corporations more ways to utilize their current investments in technology.

Enterprise networking is also experiencing a resurgence in popularity; the size of corporate databases that store mission-critical data continues to grow. As companies continue to use mainframe and AS/400 host systems for database hosting, transaction processing, and other applications, many organizations are investigating methods of integrating host networks with the Web.


SNA Server and Web Technology

The Microsoft Web-to-host model uses SNA Server to provide Web-to-host connectivity between an IBM host system and a Web server, such as IIS. In this model, as shown in Figure 12.32, Web browsers and servers communicate using the HTTP and TCP/IP protocols over the network. The Web server, in turn, communicates with SNA Server using a defined server interface, such as the Internet Server Application Programming Interface (ISAPI). The SNA Server–based computer then communicates with the host system using the SNA protocol over a defined connection.

Figure 12.32 Web-to-Host Communications

The components illustrated in Figure 12.32 may be deployed on one or more computers across your enterprise. For example, smaller enterprises may be able to deploy a Web server and SNA Server on the same Windows 2000 Server–based computer and still maintain the desired server response levels. As the number of server and connection requests increases, it is recommended that the Web server and SNA Server applications be installed on separate Windows 2000 Server–based computers.

IIS is the recommended Web server for Windows 2000 Server–based systems because of its tight integration with the management and administrative features of the operating system. Integration with Windows 2000 Server also lets you easily couple IIS with other BackOffice applications, such as SQL Server or Microsoft® Exchange Server, in order to Web-enable enterprise applications such as database access and e-mail.


Web-to-Host Access Methods

SNA Server provides host-connectivity services for Web-based users in several ways. The following Web-to-host solutions are commonly adopted by enterprises:

  • Browser-based terminal access solutions, which display 3270 and 5250 data streams in a Web browser window.
  • Web-to-host data access solutions, which provide access to relational or non-relational host data through a Web browser.
  • Web-to-host application access solutions, which provide access to transaction systems through a Web browser.

The following sections detail options for deploying SNA Server in each of these scenarios and describe the environments in which each is best deployed.

Browser-based Terminal Access

Using a Web browser to provide access to host applications through a traditional 3270 or 5250 terminal interface is a simple and effective way of providing terminal access to your users. This Web-to-host solution is ideal if your user base is already familiar with the character-based terminal interface and is adept at using existing host applications. In most environments where this solution is deployed, existing host access technology is already in place, either through dumb terminals or software-based emulators.

SNA Server can provide browser-based terminal emulation through the deployment of SNA Server Web Client (see Figure 12.33). SNA Server Web Client provides terminal emulation features through an ActiveX control that is part of a package downloaded to a user’s browser from a Web server such as IIS. Once downloaded and invoked, the control establishes a connection with the sponsor SNA Server computer that provides a connection to the host system.

Figure 12.33 SNA Server Web Client Terminal Access Installation

Using this method, no configuration is required on the client workstation because all connection information is specified by the administrator before SNA Server Web Client is downloaded into the browser. When a user downloads the ActiveX package, the connection information is contained in the download, allowing SNA Server Web Client to automatically establish a connection to the host system.

Once SNA Server Web Client software is downloaded to the client workstation, it does not need to be downloaded again unless the browser detects a newer version of the software on the Web server; this can speed up the client startup time and minimizes the load on your server. Because SNA Server Web Client software is distributed from a central location, updates and changes to host configurations are easily propagated to your users the next time they start the SNA Server Web Client application.

SNA Server Web Client is currently available for Windows NT, Windows 2000, Windows 95, and Windows 98–based clients running Internet Explorer 3.02 or later. Both 3270 and 5250 terminal emulation clients are provided.

Complete information about configuring and installing SNA Server Web Client is provided in the SNA Server documentation.

Web-to-Host Data Access

As mentioned earlier, host systems are ideal platforms on which to provide large-scale database services for enterprises. Using SNA Server, Web technology can extend host database access to a broader range of users.

A common way to integrate Web technology with host databases is to use the rich-text capabilities of HTML to create visually appealing, user-friendly interfaces for character-based host database systems.

For example, a Web browser could be used to collect database queries on an HTML form. The queries could then be transferred, using ISAPI or some other common gateway interface, from the Web server to a service that can communicate with the host database system. The results of the query could then be formatted into HTML and viewed through the user’s browser.

SNA Server is an ideal tool for deploying Web-to-host data access solutions because it can provide host database access without the need for host code or a modified database system. Using a feature such as OLE DB Provider, you can extend a wide range of services to Web users. Figure 12.34 illustrates how different data access components integrate with SNA Server and other services to provide access to host data files from a Web browser.

Figure 12.34 Web Access to Host Data File System

In the browser, the user loads and inputs data into an Active Server Page (ASP) hosted by the Web server (IIS). The ASP then sends the data through the ActiveX Data Objects (ADO) interface to the OLE DB Provider feature of SNA Server.

In this scenario, the OLE DB Provider uses the APPC record-level input/output (RLIO) protocol of the IBM Distributed Data Management (DDM) architecture (level 2 and higher) to communicate with the host database. This entire process is transparent to the host system and to the user.

The SNA Server OLE DB Provider is implemented as a source DDM requester and interoperates with target DDM server implementations on most popular host environments, including MVS/ESA, OS/390, and OS/400.

Web-to-Host Application Access

A Web browser can also be used to access TPs that operate on a mainframe, such as CICS or IMS applications. Using SNA Server’s COMTI feature, you can develop client/server applications that use Web browsers to interact with mainframe transaction systems. Because CICS programs can access DB2 databases, COMTI can also provide programmatic access to DB2 on a mainframe.

You can use any technique for accessing COM objects from the browser because COMTI creates a standard COM Automation server component that acts as a proxy for the mainframe CICS or IMS TPs. Figure 12.35 illustrates the components that could be involved in creating a Web application that uses server-side scripting to dynamically create objects and invoke methods.

Figure 12.35 Web Access to Host Transaction System

Other applications that use technologies such as Remote Data Services (RDS) and client-side scripting can also be developed. In these scenarios, object creation and method invocation are launched from a client script executed on the server and the RDS control directs records back to the client over HTTP. Retrieved records can then be bound to an HTML grid control for display purposes.

For more information about sample applications that use these Web-to-host technologies, see the samples folder on the SNA Server CD.


Network Management Integration

Your LAN-to-host integration project is not complete until you can manage the integrated network environment. SNA Server provides integrated management services that enable you, or your IBM host system administrators, to manage SNA Server from:

  • Windows 2000 Professional–based computers.
  • Remote computers, using SNA Server Remote Access Service (SNA remote access).
  • IBM NetView applications running on an IBM host system.


SNA Server Management Services

You can configure and manage SNA Server using a graphical user interface application, SNA Server Manager, or from the command-line interface.

SNA Server Manager is a graphical Microsoft Management Console (MMC) snap-in that supports simultaneous monitoring, diagnosis, and management of SNA Server resources and services, including:

  • SNA Server subdomains
  • Computers
  • Configurations
  • Link services
  • Connections
  • LUs
  • Sessions
  • Services
  • Users

SNA Server Manager integrates the administration of all services provided by SNA Server including TN3270 Service, TN5250 Service, Host Print Service, Shared Folders Gateway Service, and Host Security Integration.

With SNA Server Manager, you can view all computers running SNA Server in an SNA Server subdomain, and manage multiple subdomains at the same time, allowing for central configuration and administration of all SNA Server resources throughout an enterprise network.

You can remotely configure and manage computers running SNA Server across all common protocols, including:

  • TCP/IP
  • IPX/SPX
  • Banyan VINES IP
  • Named Pipes
  • Windows 2000 Remote Access Service (remote access)

SNA Server Manager runs on any computer running Windows 2000 Professional that is configured with SNA Server Client. In addition, SNA Server Manager allows more than one administrator to simultaneously view and manage the same SNA Server subdomain.

Note

SNA Server also provides a command-line management interface that allows you to store and use configuration commands in command files. For more information about command-line management functions, see the SNA Server documentation and the Microsoft BackOffice Resource Kit.


Integration with Windows 2000 Management Services

Because SNA Server is a Microsoft BackOffice application, SNA Server Manager is tightly integrated with the Windows 2000–based MMC snap-ins including:

  • User Manager
  • Performance Monitor
  • Event Viewer

Integration with User Manager provides a common user account database and security system for Windows 2000 users, SNA Server Client–based computers, and users of other BackOffice applications. Integration with Performance Monitor allows you to configure performance counters that monitor the SNA traffic volumes of your SNA Server–based computers. With Event Viewer you can quickly identify the type and sequence of events leading up to problems on any SNA Server subdomain.

For more information about managing SNA Server resources and services from the Windows 2000 MMC, see the SNA Server documentation and the Microsoft BackOffice Resource Kit.


Integration with IBM NetView Management Services

SNA Server can also support integrated management services with IBM NetView network management systems that run on IBM mainframes, as shown in Figure 12.36.

The NetView reporting system sends alerts and other information between a host system and the computers that connect to it. NetView functionality can be extended to encompass the Windows 2000/SNA Server environment through the following services:

  • NVAlert service
  • NVRunCmd service
  • Response Time Monitor
  • Link Alerts for SDLC and Token Ring

Figure 12.36 SNA Server Communication with IBM NetView

NVAlert Service

As shown in Figure 12.36, the NVAlert service sends events from the Windows 2000 event logs to IBM NetView system on the host computer. The events are sent as standard NetView alerts. NVAlert can send two categories of events: events generated by the Windows 2000 operating system and events generated by Windows 2000–based applications.

The events can be forwarded to the NetView console display on the host system or to a host system log file. NVAlert determines which events to forward to the NetView console by reading the NVAlert.ini file.

NVRunCmd Service

The NVRunCmd service allows commands issued from a host system NetView console to be carried out on the computer running Windows 2000 and SNA Server. The NVRunCmd service also returns the command results to the host NetView console in standard character or number formats.

Response Time Monitor

The Response Time Monitor (RTM) is an IBM host function that works in conjunction with NetView and 3270 sessions to measure the length of time it takes for a host to respond during a 3270 session. The SNA Server Response Time Monitoring tool allows you to specify when RTM should send data and to define the triggers that cause RTM to register that the host has responded.

Link Alerts for SDLC and Token Ring

When a Synchronous Data Link Control (SDLC) or Token Ring connection fails, SNA Server logs diagnostic information, called link alerts, about the connection failure. The alerts are logged in a log file that can be viewed using the Windows 2000 Event Viewer.

The link alerts are also used to build a network management vector transport (NMVT) alert, which includes probable causes and suggested actions for the alert. If a connection on the server running SNA Server has been designated for NetView, and the connection is active, the NMVT alert is sent on that connection.

For more information about SNA Server management services, including integration with Windows 2000 and IBM host management services, see the SNA Server documentation.

Security Considerations

Insert info about Public key security after beta2 and when incorporated into SNA Server 5.0

Legacy techniques described below

One of the greatest concerns about using Web technologies for business applications is security, especially when applications are extended to users of the Internet. Many applications, such as online banking, require the highest level of security to protect individuals and corporations from fraudulent use.

Two Internet security standards have been adopted:

update SSL to current NT5 standard

  • Secure Sockets Layer (SSL)
  • Secure Hypertext Transfer Protocol (S-HTTP)

SSL provides encryption and user authentication services at the network transport layer, making it ideal to secure not only HTTP messages but also applications such as FTP and telnet. SSL processes all data flowing between the applications. You cannot selectively encrypt a field on a form; this may increase processing time. Another drawback of SSL is that it only authenticates between server applications. In applications that need to authenticate a client, such as online banking, SSL should not be used.

S-HTTP is an extension of the HTTP protocol that lets you selectively encrypt field data. S-HTTP also supports client and server authentication, making it ideal for applications that provide access to untrusted sources like the Internet. Because S-HTTP is a derivative of HTTP, however, it can only be used to secure Web transactions; S-HTTP does not work with applications such as FTP and telnet.

Using a combination of these technologies, along with the services of a firewall, can help minimize your security risk when deploying Web-to-host solutions to a wide range of users from untrusted networks.

Additional Web-to-Host Solutions (don’t use this here?)

Other Web-to-host solutions are available from third-party vendors; however, there are drawbacks to using these technologies.

A solution adopted by many third-party host-connectivity providers involves “on-the-fly” conversion of 3270 data streams to HTML code. By using standard HTML code, this solution works with all Web browsers and does not require the downloading of an “applet” or other client-side code.

This method of Web-to-host integration is limited by the restrictions of HTML code and the Web’s client/server architecture. Representations of host sessions are usually crude in appearance, with no support for screen-scaling, file transfers, Automation scripting, or other features found in stand-alone terminal emulators.

The Web browser is also limited because it only supports “stateless” conditions—that is, the Web server does not retain any client state information between client requests. This can lead to synchronization problems between the host application and the host display as interpreted by the Web browser and the 3270-to-HTML conversion utility. In contrast, the SNA Server Web Client establishes an end-to-end session with the host system, thereby avoiding this problem.

A second popular solution involves using “screen-scraping” techniques to scan a host application display and convert strings of characters into HTML data. As with 3270-to-HTML conversion utilities, these solutions can be accessed with any browser. However, you can create more attractive interpretations of host data from applications not exclusively created for the 3270 data stream.

Because this technique relies on the physical layout of host screens, any changes made to the screen format or text orientation may cause applications to fail. Using this technique to create Web-based client/server applications is usually more labor-intensive than using technologies such as COM Transaction Integrator, OLE DB Provider, the ODBC/DRDA Driver, or other programmatic features of SNA Server.


Data Link Control

With the Data Link Control (DLC) protocol, as implemented in Microsoft® Windows® 2000, you can provide connectivity to IBM mainframes and to local area network (LAN) print devices directly attached on the network. DLC is a non-routable protocol used only on computers performing these tasks and is not configured as a primary protocol for use between desktop computers. A device driver for the DLC protocol interface is also included with Windows 2000.

In This Chapter

Overview of Data Link Control

Installing the DLC Protocol

DLC Driver Parameters in the Registry

Communicating with SNA Hosts Using DLC

Changing the Locally Administered Address

Using DLC to Connect to Print Devices

Related chapters in the Resource Kit

  • For more information about DLC and network printing, see “Printing” in the Microsoft® Windows® 2000 Professional Resource Kit, core technologies for Windows 2000 Professional and Windows 2000 Server.
  • For more information about IBM interoperability, see “IBM SNA Interoperability Concepts” in the Microsoft® Windows® 2000 Server Resource Kit Internetworking Guide.

Additional Resources

  • For more information about DLC, see the IBM Local Area Network Technical Reference.


Overview of Data Link Control

The DLC protocol driver is provided with Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows NT® version 4.0 and earlier, and Windows 2000. The driver enables the computer to communicate with other computers running the DLC protocol stack, such as IBM mainframes, and network peripherals, such as print devices that use a network adapter to connect directly to the network. The DLC protocol driver provides access to Institute of Electrical and Electronics Engineers, Inc. (IEEE) 802.2 class I and class II services. It also provides a direct interface to send and to receive 802.3 and other Ethernet-type network frames, as well as raw 802.5 frames.

The interface consists of a dynamic-link library (DLL) and a device driver. These services are available with network cards that use Windows 2000 network driver interface specification (NDIS)–compliant drivers. Windows 2000–based DLC works with either Token Ring or Ethernet Media Access Control drivers and can transmit and receive Digital Intel Xerox (DIX) format frames when bound to Ethernet Media Access Control.

Windows 2000–based DLC contains an 802.2 logical link control (LLC) finite state machine, which is used when transmitting and receiving type 2 connection-oriented frames. DLC can also transmit and receive type 1 connectionless frames, such as unnumbered information frames. Type 1 and 2 frames can be transmitted and received simultaneously.

The DLC interface can be accessed from 32-bit Windows 2000–based programs as well as from 16-bit MS-DOS-based and 16-bit Windows–based programs. The 32-bit interface conforms largely to the Command Control Block (CCB) 2 interface, in which the segmented 16-bit pointers are replaced with flat 32-bit pointers. The 16-bit interface conforms to the CCB1 interface.

Windows 2000–based DLC does not support the transport driver interface (TDI) as other Windows 2000–based transport protocols do. Because of this, DLC cannot be used for communication with TDI client applications such as the Windows 2000 redirector and server. Because the redirector cannot use DLC, this protocol is not used for normal session communication between Windows 2000–based computers.


Installing the DLC Protocol

The DLC protocol is installed separately after the Windows 2000 Setup.

To install DLC

  1. Click Start, point to Settings, and then double-click Control Panel.
  2. Double-click Network Connections.
  3. Right-click Local Area Connections and select Properties.
  4. Click Add.
  5. Select Protocols, and then click Add.
  6. Select DLC Protocols, and then click Add.

Network bindings consist of connections between network cards, protocols, and services. You can configure network bindings for DLC. The order of the bindings is significant to DLC because an adapter is specified at the DLC interface as a number—typically 0 or 1, although Windows 2000 DLC can support up to 16 physical adapters at one time. The number corresponds to the index of the adapter in the DLC bindings section.

If you have only one network adapter installed, DLC applications use a value of 0 to refer to this adapter, and you do not need to make any changes to the bindings. If you have more than one network adapter, you might want to modify the bindings.

You can make the following status changes to DLC bindings:

  • Enable a binding.
  • Disable a binding.
  • Move the order (priority) of the bindings up or down.

To change a DLC binding positions

  1. Click Start, point to Settings, and then double-click Control Panel.
  2. Double-click Network Connections.
  3. Click Advanced, and then select Advanced Settings.
  4. In the Advanced Settings - Connections window, select Local Area Connection.
  5. In the Bindings for Local Area Connections window, select the item whose binding position you want to adjust.
  6. Use the up and down arrows on the left of the Bindings for Local Area Connections window to adjust priority.


DLC Driver Parameters in the Registry

Unlike other Windows 2000 protocol drivers, DLC does not bind to a Media Access Control driver until an adapter open command is issued. When an adapter is opened for the first time, the DLC protocol driver writes default values into the Windows registry for that adapter. These values control the various timers that DLC uses, whether DIX frames should be used over an Ethernet link, and whether bits in a destination address should be swapped (used) when going over a bridge that swaps destination addresses.

The timer entries in the registry are supplied because program-supplied timer values might not be sufficient. There are three timers used by DLC link communication:

  • T1. The response timer.
  • T2. The acknowledgment delay timer.
  • Ti. The inactivity timer.

Warning

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Each timer is split into two groups,T x TickOne and T x TickTwo, where x represents “1,” “2,” or “i.” Typically, these timer values are set when a program opens an adapter or creates a Service Access Point (SAP). The registry contains entries used to modify timer values. Registry entries for DLC are found in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DLC\Parameters \<Adapter Name>

When you edit the value of a timer entry, the change takes effect when the adapter is next opened.


Communicating with SNA Hosts Using DLC

A major use of the DLC protocol is connecting personal computers to Systems Network Architecture (SNA) hosts, such as IBM mainframes or midrange computers such as the AS/400.

SNA provides functionality that is equivalent to the OSI model Network, Transport, Session, and Presentation levels (although functionality might differ at each level). The DLC layer and the OSI Data-link layer are almost identical in functionality, and a programming interface is available for programmers who want to work with the interface at the DLC layer level. The interface is described in the IEEE 802.2 standard.

Note

DLC is not robust enough to handle multithreaded programming.

Figure 14.1 Comparison of SNA and OSI Models

Microsoft® SNA Server uses the DLC protocol device driver when communicating to mainframes.


Changing the Locally Administered Address

When using the DLC protocol, it might be necessary to change or override the network address of the network adapter. For example, some configurations of mainframe software require that the network addresses of devices follow a set format. You can change the network address of the network adapter using the Registry Editor Regedt32.exe.

The following procedure, for an IBM Token Ring adapter, is supported for other network adapters, but not on all. Check with the network adapter manufacturer.

Warning

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

To change the address of an adapter card

  1. Click Start, and then click Run.
  2. Type the following:
regedt32
  1. Click OK.
  2. When the Registry Editor starts, select the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ibmTOKMC01
  1. On the Edit menu, click Add Value.
  2. Type Network Address in the Value text box, select REG_SZ for data type, and then click OK.
  3. Type the 12-digit Locally Administered Address (LAA) that you need to communicate to the mainframe.

    If you do not know this address, see your network administrator or operations group.

  4. Close the Registry Editor and restart your computer for the modification to take effect.
  5. At the command prompt, carry out the following command to report the active media access control address:
net config rdr

If the media access control address is the same as the LAA you typed in the Registry Editor, the LAA has taken effect.

For more information about the Registry Editors, see the Windows 2000 online documentation.


Using DLC to Connect to Print Devices

You can also use DLC to provide connectivity to LAN print devices that are directly attached to the network.

Note

The DLC protocol is not used for printers attached locally to workstations through parallel or serial ports.

To install the DLC protocol, follow the procedure in the section “Installing the DLC Protocol” earlier in this chapter.

To connect to and configure a Hewlett-Packard print device, you must install the Hewlett-Packard Network Port monitor on the Windows 2000–based print server. You can then use the Add Printer Wizard to install the Hewlett-Packard Network Port and to configure the print device.

Before starting the Add Printer Wizard:

  • Run a self-test on the Hewlett-Packard print device to obtain the network adapter address. The network adapter address is a unique 12-byte number that is supplied by the card manufacturer.
  • Choose a logical name for the printer. This logical name will be used to identify the printer and will be associated with the card address.

To configure a Hewlett-Packard print device that is directly connected to the network

  1. Click Start, point to Settings, and then click Printers.
  2. Double-click Add Printer.
  3. Click Next in the Add Printer Wizard.
  4. Select Network Printer, and then click the Next button.
  5. Select the network that the printer is to be added to, and type the printer name in the Printer text box.
  6. Click OK.

    The Add Printer Wizard will complete the configuration of the print device.

Note

When configuring Hewlett Packard network printers, or printers from manufactures other then Hewlett Packard, please refer to the manufacturer’s installation manual. For more information about configuring printers, see the Windows 2000 online documentation.


IBM SNA Interoperability Concepts

Microsoft®’s solution for integration with IBM host systems is Microsoft® SNA Server. To effectively use SNA Server, you need to understand the IBM mainframe and AS/400 host networking environments. IBM Systems Network Architecture (SNA) and Advanced Peer-to-Peer Networking (APPN) define the protocols used in traditional IBM host networks. SNA Server embraces these IBM networking protocols and additional technologies and standards that allow interoperability between Microsoft® Windows® 2000–based networks and IBM host data, applications, and network management systems.

In This Chapter

IBM Host Integration

Microsoft SNA Server

IBM Systems Network Architecture

Hierarchical SNA Networks

Advanced Peer-to-Peer Networking (APPN)

SNA in Transition

Host Application Standards

Terminal Access

Host Database Standards

Host Transaction Processing

IBM NetView Network Management System

Related Chapters in the Resource Kit

  • For more information about SNA Server and interoperability with IBM host systems, see “Interoperability with IBM Host Systems” in this book.

Additional Resources

  • For more information about SNA Server and related host integration technologies, see the SNA Server Web site at http://www.microsoft.com/sna.


IBM Host Integration

Many large organizations run their line-of-business applications on specialized IBM mainframe, midrange, and AS/400 computer systems. Consequently, SNA, the native networking architecture of IBM host systems, continues to be one of the most widely used networking protocols today.

To leverage the value of information that resides in IBM host systems, network managers must find ways to seamlessly integrate their Windows 2000–based networks and intranets with SNA-based host systems and the associated data, applications, and network services.


Microsoft SNA Server

SNA Server is a Microsoft® BackOffice® application that runs on the Microsoft® Windows® 2000 Server operating system. SNA Server provides you with a comprehensive solution to integrate Windows 2000–based networks and intranets with IBM SNA or TCP/IP-based mainframe, midrange, and AS/400 host systems.

Clients connect to SNA Server through standard networking protocols such as TCP/IP, IPX/SPX, NetBEUI, Banyan VINES IP, AppleTalk, and Windows 2000 Remote Access Services (remote access). If the IBM host system runs SNA networking protocols, SNA Server completes the network connection to the host system using standard IBM SNA protocols, as shown in Figure A.1.

Once network connectivity is established, clients can use SNA Server’s advanced host integration features to gain access to IBM host data, applications, and network services. Using SNA Server, Information Technology departments can build applications that allow users to maximize the value of IBM host data and applications without leaving their familiar desktop or Web browser interface.

Figure A.1 SNA Server Provides Seamless Access to IBM SNA Host Systems

SNA Server provides the full range of host integration services.

  • Network Integration

    Cross-platform network connectivity and protocols, directory utilization, security integration, and single sign-on.

  • Host Data Access

    Transparent file transfer services, Universal Data Access technologies such as OLE DB-based and ODBC-based solutions, and host data replication.

  • Application Interoperability

    Terminal Access, integrated transaction services, Web-to-host integration.

  • Network Management Integration

    Integration between Windows 2000 network management services and IBM NetView–based management services.

To understand how you can use SNA Server to integrate Windows 2000–based networks with IBM mainframe and midrange system networks, first you need to understand the basic components of IBM SNA.

The remainder of this chapter provides essential background information. If you are already familiar with IBM SNA and IBM mainframe and midrange systems, you can bypass this material and proceed to “Interoperability with IBM Host Systems” in this book.


IBM Systems Network Architecture

SNA is a computer networking architecture developed by IBM to provide a network structure for IBM mainframe, midrange, and personal computer systems. SNA defines a set of proprietary communication protocols and message formats for the exchange and management of data on IBM host networks.

SNA defines methods that accomplish the following:

  • Terminal access to mainframe and midrange computer applications.
  • File transfer of data between computer systems.
  • Printing of mainframe and midrange data on SNA printers.
  • Program-to-program communications that allow applications to exchange data over the network.

SNA can be implemented in the following two network models:

  • Hierarchical

    The hierarchical SNA networking model, also called subarea networking, provides geographically disparate terminal users access to centralized mainframe processing systems. In the hierarchical networking model, centralized host-based communication systems must provide the networking services for all users on the network.

  • Peer-to-Peer

    The more recently developed Advanced Peer-to-Peer Networking (APPN) model makes use of modern local area network (LAN) and wide area network (WAN) resources and client/server computing. APPN networking enables a form of distributed processing by allowing any computer on the network to use SNA protocols to gain access to resources on any other computer on the network. Computers on an APPN network do not have to depend on mainframe-based communication services.

    Because of the large installed base of legacy applications that run on IBM mainframe and midrange systems, both of these SNA networking models continue to be widely used in enterprise networks.

Note

SNA is gradually evolving into a more of a peer-to-peer networking structure. As part of that evolution, APPN networking is often combined with hierarchical SNA networking. APPN is described in “Advanced Peer-to-Peer Networking (APPN),” later in this chapter.


Hierarchical SNA Networks

In the SNA hierarchical model, also called subarea networking, communication begins with the mainframe at the top of the hierarchy and proceeds down the hierarchy to the end user.

Note

In SNA terminology, an end user represents either a person or an application program.

SNA defines several classes of components to support communications between the mainframe, or host system, and the end user.

  • Hardware Components, or Nodes

    Hardware that provides the computing platforms and network devices that implement specific SNA communications and management functions.

  • Connection Types

    Hardware and communication standards that provide the data communication paths between components in an SNA network.

  • Physical Units (PUs)

    A combination of hardware and software that provide the configuration support and control of the SNA network devices, connections, and protocols.

  • Logical Units (LUs)

    Protocols that provide a standardized format for delivery of data for specific applications, such as terminal access and printing.

These components provide the basis for IBM SNA. Thus, integrating Windows 2000–based networks and intranets with IBM host systems begins with an understanding of these SNA components. The following sections describe each of these components and how they interact in a hierarchical SNA environment.


Hardware Components on Hierarchical Networks

The construction of a hierarchical SNA network begins with its hardware components. Each hardware component is distinguished by a node type, which corresponds to a position in the SNA hierarchy and identifies its relationships to other hardware components on the network. Table A.1 defines SNA hardware components. Figure A.2 illustrates the hierarchical relationships between these components.

Table A.1 Hardware Components on a Hierarchical SNA Network

Hardware Component | Node | Function
Mainframe | Type 5 host node | Core component of a hierarchical network. Runs the centralized processing applications that are made available to users on the SNA network.
Front-end processor (FEP) | Type 4 node | Generally dedicated to the control of communication from the network to the mainframe. Offloads many network communication processes that would otherwise consume valuable mainframe processing resources. Also called a communications controller.
Cluster controller | Type 2 node | Controls a group, or cluster, of end-user terminals and printers. Often located at remote sites, connecting to the Front-end Processor (FEP) over WAN links.
End-user components | Peripheral nodes | Terminals and printers attached to the cluster controller that are used to access, display, and print mainframe application data.

Figure A.2 Hierarchy of SNA Hardware Components

Note

Some modern mainframe host systems can also support peer-to-peer networking functions. In such environments, type 2.1 (peer-oriented) end-user nodes can also be used.


Connection Types in Hierarchical Networks

Connections provide the lower-level data path between hardware components on an SNA network. These connections include paths from the mainframe to the FEP and from the FEP to the cluster controller.

Connections from the Mainframe to the FEP

FEPs can be connected to mainframes with either an IBM Channel connection or an Open Systems Adapter.

An IBM Channel connects components to a mainframe using a proprietary, high-speed communication link. The channel connection includes a microprocessor within the mainframe that is dedicated to a single purpose, such as directing input/output (I/O) from a mainframe hard disk drive or managing an FEP communications line. Fast and efficient communications through dedicated channel microprocessors represent the native method of connecting to IBM mainframes. Table A.2 describes two common types of IBM Channel connections.

Table A.2 IBM Channel Connections

Cable Type | Composition | Transmission Rate
Bus & Tag | Two heavy-gauge multiple lead copper cables with large multiple-pin connectors at each end. | 3.0 or 4.5 megabytes per second.
Enterprise System Connectivity (ESCON) | Fiber-optic cable. | Up to 17 megabytes per second.

An Open System Adapter, placed in the host, provides a direct network connection to Token Ring, Ethernet, and Fiber Distributed Data Interface (FDDI) networks.

Connections from the Front-end Processor to the Cluster Controller

Several connection types, also known as links, are available for connecting an FEP to a cluster controller or other components operating lower in the SNA hierarchy. Each connection type uses a different method to gain access to an FEP. Three of the most common links are:

  • Synchronous Data Link Control (SDLC)

    Enables a cluster controller to communicate with an FEP over standard (switched) telephone lines or leased (dedicated) telecommunication lines. SDLC has been available for many years and is widely used in the SNA networking environment.

  • Data Link Control (DLC)

    Enables a cluster controller to communicate with an FEP over standard networking topologies, such as Token Ring, Ethernet, or FDDI. Although DLC has not been available as long as SDLC, its efficiency and flexibility are making it very popular for new installations.

  • X.25/QLLC

    Enables a cluster controller to communicate with an FEP over standard packet-switching networks. X.25/QLLC is an International Telecommunications Union (ITU) standard for global packet-switching network communications that uses the qualified logical link control (QLLC) protocol, also known as X.25. An X.25 connection is slower than an 802.2-type connection but is comparable to an SDLC connection.

For more information about connection types, see “Interoperability with IBM Host Systems” in this book.


Physical Units in Hierarchical Networks

The creation of an SNA network requires the installation of specific networking software on SNA hardware components. Network software programs are available for each of the three primary hardware components: mainframes, FEPs, and cluster controllers. The combination of software and hardware installed in a device on an SNA network is referred to as a physical unit (PU), as shown in Figure A.3.

Figure A.3 A PU Is a Combination of Software and Hardware

In the preceding figure, note that the PU is the component that represents the hardware device (node) to the SNA network. Each PU type is identified by a number, with the highest number representing the top of the SNA hierarchy.

Note

The concept of a physical unit (PU) can be confusing. Please keep in mind that a PU is not an actual hardware device. Rather a PU is a combination of software and hardware that represents a device to the SNA network.

Table A.3 identifies the PU types, the hardware component with which each PU type is associated, and typical IBM model numbers for each PU type.

Table A.3 PU Types

PU Type | Hardware Component | Model Number
PU 5 | Mainframe (type 5 host node) | Type S/370, S/390
PU 4 | FEP (type 4 node or communication controller) | IBM 3745, 3720
PU 2 | Cluster controller (type 2 node) | IBM 3174, 3274

Note

PU type 3 has not been implemented. An additional PU type, PU 2.1 is identified in the section that describes peer-to-peer SNA networks, later in this chapter.

The following sections outline the software options for each hardware component, or node, and the resulting PU.

Mainframe Software

Virtual Telecommunications Access Method (VTAM) is the IBM mainframe program that controls communications between mainframe applications and the terminals and computers that connect to the mainframe.

VTAM contains the system services control point (SSCP), which is the networking focal point for a hierarchical network. The SSCP activates, controls, and deactivates network resources, such as FEPs, cluster controllers, terminals, and printers. The SSCP also monitors and logs the status of SNA components.

With the activation of VTAM and the SSCP, the mainframe becomes a PU 5.

Traditionally, VTAM and the SSCP communicate directly with the next lower level in the hierarchy, a PU 4 FEP. In an increasing number of cases however, the PU 5 communicates directly with a PU 2 that is either channel-attached or connected with an Open System Adapter.

FEP Software

The FEP, also called a communications controller or PU 4, runs a communications management program called Advanced Communication Function/Network Control Program (ACF/NCP). The FEP uses this software to manage the routing and communications on a hierarchical SNA network, offloading these tasks from the mainframe system. ACF/NCP is configured on the mainframe and then downloaded to the FEP. The FEP, as a PU 4, supports bi-directional communications with the next lower level in the hierarchy.

Cluster Controller Software

The cluster controller, or PU 2, contains administration software called the Configuration Support program, which controls the connections from the cluster controller to terminals and printers.

Note

A computer running SNA Server can be used in place of a traditional SNA cluster controller.


Logical Units in Hierarchical Networks

In an SNA network, type 5 and type 2 PUs transmit and control SNA networking protocols, called logical units (LUs).

An LU is the end user’s entry point into the SNA network. In SNA terminology, the end user can be a person or an application. For example, when an end user enters information into an SNA terminal, the data is passed to an LU for routing over the network to a host node. When the data reaches the host node, another end user passes it to an LU within the host for processing. In this example, the end user at the terminal is an actual person but the end user at the host node is the host application program.

In hierarchical networks, all LUs depend on the mainframe SSCP to establish and manage communications with other LUs, and are therefore referred to as dependent logical units.

As with PU types, each type of LU is identified by a number. Table A.4 identifies the LU types used in hierarchical networks, the hardware component with which each is associated, and the function of each in an SNA network.

Table A.44 LU Types Used in Hierarchical Networks

LU Type | Component | Function
LU 0 | Nonstandard, user-defined component interface. | Enables the development of specialized applications. LU 0 is a general purpose LU.
LU 1 | IBM 3287–type printers. | Handles transmission of printer data to system and network printers. LU 1 uses SNA character string format (SCS).
LU 2 | IBM 3278 (3270) monochrome terminals; 3279/3179 color terminals; graphics terminals. | Defines how terminal data streams are formatted and transmitted.
LU 3 | IBM 3270 type printers. | Uses SNA 3270 data stream format to control the transmission of data to system and network printers. LU 3 is the most often used printing LU type.

Note

Peer-oriented LU types, including LU 6.2, are described in “Advanced Peer-to-Peer Networking (APPN)” later in this chapter.


SNA Functional Layers

The functionality of each SNA layer operating in the context of a hierarchical network model is summarized in Table A.5. The transaction services layer and the physical layer are both outside of the original scope of SNA specifications but are included here to show the full range of IBM host networking.

Table A.5 Functional Layers in Hierarchical SNA Networks

SNA Functional Layers | Description
Transaction Services | A conceptual layer to represent host applications that establish and terminate SNA user-to-user sessions.
Functional Management | Formats data streams and converts character codes for presentation (for example, 3270 data streams). Also controls active sessions.
Data Flow Control | Provides protocols for managing data integrity in sessions, synchronizing data exchange, and packaging data units.
Transmission Control | Uses VTAM and NCP to manage active end-to-end sessions. Controls data sequencing and pacing. Optionally supports data encryption and decryption.
Path Control | Routes data between hierarchical SNA nodes using VTAM and NCP.
Data Link Control | Manages data transmissions between nodes and performs error detection and recovery. Manages transmissions over standard WAN (including SDLC), LAN (Token Ring, Ethernet, FDDI, Asynchronous Transfer Mode (ATM)) and channel interfaces.
Physical Control | Transmits bits over industry standard physical/electrical circuits. SNA generally relies on industry standard LAN and WAN specifications at this layer, although specifications for channel attachments are unique to SNA.

Note

APPN uses different methods to accomplish networking functions at some layers.

Because many networking professionals are familiar with the Open Systems Interconnection Reference Model (OSI model), it is sometimes helpful to describe the SNA functional layers within the context of the OSI model.

SNA functional layers define protocols and services that are similar in scope to layers in the OSI model. In fact, the OSI model was developed in response to SNA and was influenced by SNA functions. Originally, SNA did not include specifications for layers that correspond to the physical and applications services layers in the OSI model. However, recent descriptions of SNA include all seven layers, including the physical and transaction services layers (equivalent to the application layer in the OSI model). The transaction services layer plays an important role in IBM host system networking because transaction-based applications often initiate SNA networking sessions.

While the scope of the networking layers described by the SNA and OSI models are similar, the methods SNA uses to perform networking functions within each hierarchical networking layer are quite different from methods described by the OSI model, as is made apparent in Figure A.4.

Figure A.4 SNA Functional Layers Mapped to the OSI Model

Path Control

The three lower SNA functional layers comprise the SNA path control network components, also called the SNA transport network. These layers control the routing and flow of messages through the network and provide the interfaces to physical media that carry transmissions between network devices.

Network Addressable Units

The four upper SNA functional layers provide end-to-end communication protocols between network addressable units (NAUs). NAUs include the following SNA components:

  • Physical units
  • Logical units
  • Control points (such as SSCP in VTAM)

SNA nodes might each contain several NAUs to manage specific networking functions. Each NAU has a unique address so data can be routed to the NAU during an SNA session.


SNA Sessions

SNA communications are based on the establishment and termination of logical sessions between NAUs. Logical sessions are communication paths that support the operation of network devices and the flow of traffic through the network.

In SNA networks, routing information is dynamically determined when a session is established and only remains fixed until the session is terminated. During sessions, all SNA packets follow the same logical path from the source NAU to the destination NAU.

SNA packet transmissions are also time sensitive. If communication in an SNA session is interrupted, even for a short time, SNA terminates the session. As such, networks that tunnel SNA protocols across standard wide area network (WAN) connections must use routers that support Data Link Switching (DLSw), Frame Relay Assembler/Disassemblers (FRADs) that support frame relay (RFC 1490), or specialized Asynchronous Transfer Mode (ATM) switches.

Table A.6 summarizes the types of sessions that are used in hierarchical SNA networks.

Table A.6 Hierarchical SNA Session Types

Hierarchical SNA Session Type | Description
SSCP to SSCP | Supports communications between SSCPs in multi-domain, hierarchical networks.
SSCP to PU | Used by system administrators to communicate with network devices.
SSCP to LU | Used by logical units in hierarchical networks to obtain session services that are controlled by the SSCP, such as logon or logoff services.
LU to LU | Supports communications between end users and applications in both hierarchical and peer-to-peer networks.

Note

SNA APPNs support control point to control point (CP to CP) sessions in addition to LU to LU sessions. CP to CP sessions allow a peer-to-peer SNA network to manage all of its functions without relying on a mainframe SSCP.


Hierarchical Domains and Subareas

Hierarchical SNA networks organize nodes into domains and subareas. In a hierarchical SNA network, an SNA domain represents a set of network resources that are managed by a SSCP implemented within the host system VTAM. Each domain has only one SSCP.

Some large SNA networks contain hundreds of domains. When end users in different domains need to communicate through an LU to LU session, the SSCPs in each domain must first establish communications through an SSCP to SSCP session.

SNA domains typically include several subareas. A subarea is composed of one subarea node (a type 5 host node or a type 4 node [an FEP]) and the resources it controls, including type 2 nodes, as illustrated in Figure A.5.

Figure A.5 A Single Hierarchical SNA Domain with Three Subareas

Subarea nodes can communicate with the peripheral nodes in its subarea and can also establish one or more links with other subarea nodes. Links between subarea nodes are called transmission groups. The capability to establish transmission groups allows subarea nodes to create routing tables of other subareas, which are used for SNA network addressing and routing sessions.

Maintaining multiple links in a transmission group maximizes network availability and performance. If one link should fail, SNA reroutes the data over one of the other links in the transmission group.

Note

In SNA peer-to-peer networks, domains and routing functions are defined differently than in SNA hierarchical networks. Peer-oriented networks are described in the following section.


Advanced Peer-to-Peer Networking (APPN)

In 1981, IBM began to introduce communication standards that developed into a peer-oriented network architecture called Advanced Peer-to-Peer Networking (APPN). The development of APPN marks a significant change from the traditional top-down hierarchical SNA model because APPN supports a form of distributed processing. That is, all computers on an APPN network can communicate directly with each other, without having to depend on centralized type 5 hosts or type 4 communication controllers. This model provides an environment that is more flexible than the traditional top-down hierarchical model.

APPN defines how peer-oriented components communicate with each other, as well as the level of network services, such as routing sessions, that are supplied by each computer on the network.

The SNA APPN model defines its own standards for the following components:

  • Hardware Components, or Nodes

    Hardware that provides the computing platforms and network devices that implement specific SNA APPN communications and management functions.

  • Connection Types

    Hardware and communication standards that provide the data communication paths between components in an SNA APPN network.

  • Physical Units (PUs)

    Hardware and software that provide the configuration support and control of the SNA APPN network devices, connections, and protocols.

  • Logical Units (LUs)

    Protocols that provide a standardized format for delivery of data for specific applications, such as terminal access and printing.

Note

Although the SNA APPN network model is organized into the same component classes as the hierarchical SNA network model, the components themselves are often quite different from the components used in the hierarchical model.

The following sections describe each of these components and how they interact in an SNA APPN environment.


Hardware Components on Peer-to-Peer Networks

A typical APPN network is composed of several different devices, such as IBM host computers or personal computers connected to one or more LANs, as illustrated in Figure A.6.

The peer-oriented model can be employed within many different environments. The AS/400 midrange computer, because of its popularity and primary use of APPN, is the host that is most often associated with APPN and the peer-oriented networking model. Modern mainframe systems are beginning to support APPN as well.

Figure A.6 APPN Network Components

An APPN hardware component can be any device on the APPN network that can function as a PU type 2.1 node. PU 2.1, described later in this chapter, is an upgrade and extension of PU type 2 used in hierarchical networks. With the appropriate software, the following hardware components can be configured as PU 2.1 nodes:

  • AS/400 computers
  • Mainframes
  • Personal computers
  • Routers


Connection Types in Peer-to-Peer Networks

The most common connection types, also called links, used to connect APPN devices are listed in Table A.7. For a more detailed description of these connection types, see “Interoperability with IBM Host Systems” in this book.

Table A.7 Connection Types

Connection Type | Method of Connection
802.2 DLC | Token Ring
 | Ethernet
 | FDDI
SDLC | Public and private switched telephone lines
Twinax | Twinax protocols

Note

The Twinax link represents the native method for accessing AS/400 computers.


Physical Units in Peer-to-Peer Networks

As with the hierarchical network model, the type of software that is implemented in an APPN hardware component determines how it functions on an APPN network. Also, just as in an hierarchical network, the combination of hardware and software that is implemented in an APPN network device is called a PU. A PU represents a device, often called a node, to the SNA network.

In a pure APPN network, all nodes are PU type 2.1 nodes. PU type 2.1 is an upgrade to the PU type 2.0 standard used in hierarchical SNA networks. Like PU type 2.0 nodes in hierarchical SNA networks, peer-oriented type 2.1 nodes can communicate with type 5 host nodes. However, type 2.1 nodes provide the added capability to establish peer-to-peer communications with other type 2.1 nodes. As such, type 2.1 nodes do not require the use of mainframe system services control points (SSCPs) or communications controllers used in hierarchical SNA networks.

This capability allows SNA APPN networks to be constructed entirely of type 2.1 nodes, such as those implemented in IBM AS/400 systems and personal computers.

Node Types

There are three types of PU 2.1 nodes in APPN networks, as shown in Figure A.7:

  • APPN Network Nodes
  • APPN End Nodes
  • Low Entry Network (LEN) Nodes

Figure A.7 PU 2.1 Node Types in an APPN Network

APPN Network Nodes

APPN Network Nodes contain the highest level of functionality of the three APPN node types. APPN network nodes can perform all the basic functions supported by the other APPN type 2.1 nodes. These basic functions include the ability to establish sessions with other APPN PU type 2.1 nodes. To maintain compatibility with hierarchical networks, APPN PU type 2.1 nodes can also establish sessions with type 5 (mainframe) host nodes. However, APPN network nodes (such as those implemented in IBM AS/400 computers) can provide the following additional services for the other PU type 2.1 node attached to it:

  • LU to LU session control
  • Routing
  • Full directory services
  • CP to CP sessions (to support APPN management functions)

An APPN network node and the other PU type 2.1 nodes attached to it comprise an APPN domain. The APPN network node acts as a server for the other type 2.1 nodes in its domain. It can also act as an intermediate node, supporting routing functions in APPN networks that contain multiple APPN network nodes.

An APPN network node contains a control point (CP) that provides directory database updates and directory search services. The CP can establish sessions with CPs in adjacent APPN network nodes to keep the network structure and directory information up-to-date, without relying on the presence of a mainframe SSCP.

For example, when a new APPN end node is added to the APPN network, its APPN network node server automatically updates its directory and routing tables and propagates that information to the other APPN network nodes.

Note

APPN directory services differ from most other directory services that use non-SNA network protocols. Because no fixed addresses are assigned to APPN resources, APPN directories respond to LU directory requests by providing the location and route to the destination LU, rather than the address of the destination resource. Consequently, APPN network nodes must dynamically create route identifiers when LU to LU sessions are established.

APPN End Nodes

Like all type 2.1 nodes, APPN end nodes can establish peer-to-peer sessions with other PU type 2.1 nodes (and with PU type 5 mainframe host nodes used in hierarchical SNA networks).

Unlike APPN network nodes, APPN end nodes cannot perform routing functions and cannot function as intermediate nodes in APPN networks. However, APPN end nodes can provide a subset of APPN session services and directory services for its own LUs.

APPN end nodes can also be attached to an APPN network node, which acts as the server for routing, session, and directory services. An end node can have links to more than one network node, but only one network node acts as the server for the end node at any given time.

Low Entry Network End Nodes

Like APPN network nodes and APPN end nodes, LEN nodes can establish peer-to-peer sessions with other PU type 2.1 nodes (and with PU type 5 mainframe host nodes used in hierarchical SNA networks).

After discovering that SNA Server emulates a LEN node, I rewrote the original material I wrote about LEN nodes.

However, to communicate with APPN nodes that are controlled by other APPN network nodes, LEN nodes, must communicate through the APPN network node that is acting as its server. LEN nodes do not provide any APPN routing or session services for other nodes.

If SNA Server can act as a higher level node, then I could put the following material back in - find out from the SNA group.

However, the specifications for LEN nodes were implemented before the full development of APPN. Therefore, LEN nodes cannot perform any of the other services provided by the other 2.1 node types. Although LEN nodes contain some very basic control point software, LEN nodes are not able to establish sessions with a control point on its APPN network node server.

Due to these limitations, LEN nodes cannot automatically exchange network configuration information with its APPN network node server. Instead, system administrators must manually define the remote LUs for the LEN. The remote LUs are defined as if they existed in the APPN network node server. In this way, LEN nodes can gain indirect access to APPN network services such as routing and directory services. Through the APPN network node server, the LEN node can communicate with other nodes on the APPN network.


Logical Units in Peer-to-Peer Networks

LUs are SNA protocols that provide a standardized format for delivery of data for applications. APPN networks typically use type 6.2 LUs, also known as Advanced Program-to-Program Communication (APPC) LUs. LU 6.2 is the most recently developed and the most advanced LU type. Unlike dependent LUs that are used in hierarchical SNA networks, LU 6.2 does not depend on centralized mainframe communications software. Rather, LU 6.2 provides a foundation for distributed computing in which programs on separate computers can communicate directly with each other across the network.

Although LU 6.2 provides the foundation for APPN communications, APPN can use additional LU types for AS/400 printers and display terminals as described in Table A.8. However, LU 6.2 is the only widely implemented APPN LU type.

[Can LU 6.2 support all of the functions provided by LU4 and LU7? Does SNA server support only LU 6.2? If so, should I delete the table and put a note that identifies LU4 and LU7 but says 6.2 can be used in their place?]

Table A.8 APPN LU Types

APPN LU Type | Description
LU 6.2 | Supports APPC for a broad range of SNA nodes and includes functions to support any type of SNA-based application. The most recent and advanced LU type.
LU 4 | Supports printers that use the IBM 5250 data stream. Not widely implemented because it does not provide the broad functionality of LU 6.2.
LU 7 | Supports display terminals that use IBM 5250 data streams, such as AS/400 display stations. Not widely implemented because it does not provide the broad functionality of LU 6.2.

Advanced Program-to-Program Communications

LU 6.2 forms the basis for IBM’s Advanced Program-to-Program Communications (APPC), the network communications protocol most commonly associated with APPN. APPC is a general-purpose network access method that supports applications such as:

  • terminal access (to AS/400 systems)
  • TN5250 terminal access
  • File transfer
  • Network services

The programs that use APPC LU 6.2 to communicate are called transaction programs (TPs). Figure A.8 illustrates TPs communicating through APPC sessions.

Figure A.8 Transaction Programs Communicating Through APPC Sessions

APPC LU 6.2 serves as a translator between TPs and the network. When a TP on one computer passes information to the APPC software, APPC establishes a session and sends it to the destination node. On the receiving end, APPC translates the information back into its original format and passes it to the corresponding partner TP. APPC can be used across any of the standard types of connections supported by SNA.

Dependent and Independent LUs

APPC generally uses a local APPC LU and one or more remote APPC LUs. Local APPC LUs can be dependent or independent.

Dependent LUs are used to provide backwards compatibility with hierarchical networks. As such, dependent LUs require a host VTAM SSCP to establish and manage LU to LU sessions. Dependent LUs can support only a single session between a given pair of LUs.

A dependent LU must be used when an APPC TP needs to communicate with a mainframe that uses a version of VTAM earlier than V3R2. Independent LUs are not supported by earlier versions of VTAM. Also, dependent LUs cannot be used to communicate with AS/400 systems.

In full peer-oriented APPN networks, typically implemented in AS/400 environments, independent APPC LUs are used. Independent APPC LUs can establish and manage LU to LU sessions without the aid of a mainframe VTAM/SSCP. Independent LUs provide the ability to run multiple, concurrent, parallel sessions between a single pair of LUs. Support for independent LUs is one of the main advantages of APPN networks.


SNA in Transition

SNA is a legacy networking model that was created decades ago. However, it has never been a static networking environment. What began as a hierarchical model has evolved into a more flexible peer-to-peer environment. Recently, IBM has been making efforts to combine the SNA hierarchical and APPN models and to integrate both models with modern LAN and WAN protocols.


Hierarchical and Peer-to-Peer Integration

Although SNA hierarchical and APPN environments differ in many ways, IBM provides the means to integrate the two SNA networking models. As described in the previous section, APPN type 2.1 nodes can establish sessions with type 5 mainframe host nodes used in hierarchical networks. APPN networks can also serve as interchange networks to connect hierarchical network domains.

More recently, IBM is upgrading hierarchical network components to perform APPN functions. For example, VTAM can now support its own native hierarchical networking model and APPN simultaneously. VTAM can also act as an interchange node to connect APPN networks.

IBM is currently working to provide a migration path to upgrade traditional hierarchical SNA networks to the APPN network model.


The IBM Networking Blueprint

IBM is also implementing a networking blueprint that seeks to integrate protocols and standards beyond the traditional SNA networking model. The IBM Networking Blueprint specifies standards for network protocols, application services, and systems management services. As part of this model, IBM is seeking to further integrate IBM host systems and SNA models with standard network protocols such as TCP/IP, IPX, and NetBIOS.

Note

Because Microsoft SNA Server is fully integrated with Windows 2000 Server, it supports these and other protocols and services that permit authorized Windows and non-Windows clients to connect to IBM SNA host systems. For more information about integrating heterogeneous networks with IBM hierarchical SNA and APPN networks, see “Interoperability with IBM Host Systems” in this book.


Host Application Standards

The purpose of any networking model is to efficiently and reliably support applications that automate an organization’s business processes. In an SNA networking environment, these applications often rely on terminal access methods, relational and nonrelational database standards, transaction processing services, and network management systems that are provided by the IBM host system.

The following sections describe these host services and identify the standards that are essential for integrating heterogeneous networks with IBM host data, application, and network management services.


Terminal Access

Although SNA Server provides features that support advanced database integration and transaction oriented Web-to-host applications, traditional terminals and terminal emulation applications continue to play an important role in many organizations.

Users can use one of two types of terminal access, depending on the type of IBM host system that controls the session, 3270 terminal access to mainframe systems or 5250 terminal access to AS/400 systems.


Terminal Access to IBM Mainframes

Users who need access to IBM SNA–based mainframe computers generally use the 3270 data stream, a protocol that defines how components in hierarchical SNA networks can gain access to IBM mainframe computers. The 3270 data stream uses LUs to support 3270 Display Devices such terminals and terminal emulators (LU 2), 3270 Printer Devices (LU 1 or LU 3), and applications (LUA). A 3270 LU is known as a dependent LU because it requires a mainframe to function.

Clients can use several variations of 3270 type display terminals and terminal emulators (LU 2) to gain access to SNA resources:

  • terminals and terminal emulators.
  • terminals and terminal emulators (models 2, 3, 4, and 5).
  • Telnet-based (TN3270) terminal emulation types, including TN3270E (extended TN3270) and Web browser–based terminal emulators.

Telnet terminal emulators allow TCP/IP-based computers to gain access to host systems that support TCP/IP access or through gateways that convert TCP/IP communications to native SNA.

Note

SNA Server supports both 3270 and TN3270 access methods.


Terminal Access to AS/400 Systems

Users who need access to IBM AS/400 systems use the 5250 data stream. This protocol supports terminal emulation only. Variations include standard 5250 terminal emulators and TN5250 terminal emulators, including Web browser–based TN5250 terminal emulation services.

Note

SNA Server supports both of the AS/400 terminal access methods. For more information about terminal access, see “Interoperability with IBM Host Systems” in this book.


Host Database Standards

Although terminal access provides an appropriate interface to a wide range of host applications, most organizations also require applications that seamlessly integrate host data and applications with modern client/server and Internet-based information systems. Achieving this level of integration with IBM host systems begins with an understanding of the standards that support IBM host database applications.

IBM host applications often rely on an underlying database architecture provided by the host system. IBM uses the Distributed data management (DDM) architecture to provide a common language and set of rules for host data access. Programs adhering to this architecture can share data across multiple platforms.


Record-Level Data Access

Record-level access using DDM enables an application to go directly to the desired record within a physical file. For host data access, DDM supports two record-level protocols, shown in Figure A.9:

Distributed Relational Database Architecture (DRDA).
DRDA is a DDM protocol that provides access to relational data on host platforms, including Multiple Virtual Storage (MVS) and AS/400 systems that use the IBM DB2 relational database program.
Record Level Input/Output (RLIO).
RLIO is a DDM protocol that supports record-level access to nonrelational data on various host operating systems, including MVS, OS/390, and OS/400.

Figure A.9 IBM Relational and Nonrelational Data Formats


File-Level Data Access

DDM also supports the Stream Input/Output (Stream I/O) file-level protocol for host data access. Stream I/O provides access to IBM host data one file at a time, as opposed to one record at a time, such as with Structured Query Language (SQL). This process provides the basis on which to build fast bulk-data file transfer solutions, such as moving files from one host region to another or transferring entire files from the personal computer and the host.

Note

Microsoft SNA Server includes the ODBC Driver for DB2 and the Microsoft OLE DB Provider for AS/400 and VSAM to support access to relational and nonrelational host data. SNA Server can also support applications that replicate host database information to Windows 2000 Server–based database applications such as Microsoft® SQL Server™. For more information about how to use SNA Server host database drivers and replication methods, see “Interoperability with IBM Host Systems” in this book.


Host Transaction Processing

Organizations often use IBM host systems for online transaction processing (OLTP) applications that automate real-time business activities. These applications consist of transaction programs (TPs) that must maintain data integrity and security in line-of-business environments such as banking and financial services, insurance, reservation systems, and retail applications.


Reliable Transaction Standards

To ensure that these transactions are processed correctly, a TP must adhere to four key transaction properties known as ACID. An ACID-compliant TP ensures that each transaction is:

  • Atomic

    Each transaction must be carried out completely or not at all.

  • Consistent

    Data must be processed in a way that maintains the structural integrity of the database.

  • Isolated

    Transactions must be carried out sequentially so that a transaction cannot access data that is already involved in a transaction.

  • Durable

    Completed transactions must be stored in a way that enables recovery of the transaction results even if the system fails.


Transaction Processing Components

In the online transaction processing (OLTP) distributed environment, data can become corrupt if it is not managed correctly. A TP Monitor manages the operating environment of the OLTP application by optimizing the use of operating system resources and the network. The TP Monitor provides a management platform for the system administrator that supports:

  • Load balancing
  • Fault tolerance
  • Performance monitoring
  • Security

TP monitors typically include a software component known as a TP manager. TP managers use the two-phase commit (2PC ) protocol to ensure the reliable execution of transactions by enabling the TP manager to execute a transaction only if all systems carry out the transaction.

Note

On the Windows 2000 platform, Microsoft® Transaction Server (MTS) is the native TP monitor. MTS includes a TP Manager called the Distributed Transaction Coordinator. IBM provides different TP managers for different TP monitors.

For a TP to communicate directly with another TP by using SNA APPC, the two programs must first establish a logical unit (LU) 6.2 session with each other. LU 6.2 is the standard for distributed transaction processing in the mainframe environment.


Transaction Processing Synchronization

One program can interact with another program by using one of three levels of synchronization, as shown in Figure A.10:

  • Sync Level 0 has no message integrity.
  • Sync Level 1 supports limited data integrity.
  • Sync Level 2 uses the 2 Phase Commit (2PC) protocol to ensure the reliability of a transaction.

Figure A.10 Host TPs Synchronizing over an APPC Session

Of the three sync levels, only Sync Level 2 guarantees a true ACID-compliant transaction. Thus, in the host environment, the term transaction program may or may not imply the use of Sync Level 2 and the 2PC protocol.

Note

In the Component Object Model (COM) environment, any mention of transactions refers to true ACID-compliant, 2PC transactions.


IBM Host Transaction Processing Standards

IBM uses different transaction processing standards for different operating environments. The following are the two most popular host-based systems used to monitor and manage OLTP programs.

  • Customer Information and Control System (CICS)

    This system was developed to run OLTP programs on the IBM MVS operating system. It is a proprietary system that supports host-based transaction processing using a TP Monitor with an integrated TP Manager.

  • Information Management System (IMS)

    This system provides a TP monitor with an integrated TP manager and a hierarchical database. The TP monitor and the database can both coordinate transactions with non-IMS TP monitors and databases. Because CICS and IMS are so widely used, the Windows platform and COM programs must support interoperability with CICS and IMS data and transactions to effectively support OLTP.

Note

Microsoft SNA Server provides a feature called COM Transaction Integrator (COMTI) for CICS and IMS to enable COM-based programs to interact with IBM host-based CICS and IMS programs. Organizations can use COMTI with other SNA Server host integration technologies to build robust, multi-tier applications that make IBM host data and applications available to heterogeneous networks and intranets. For more information about SNA Server integration with host data and applications, see “Interoperability with IBM Host Systems” in this book.


IBM NetView Network Management System

The integration of Windows 2000–based networks with other network computing platforms is not complete until network administrators can monitor and control the integrated network environment. In IBM host environments, network managers often use proprietary network management products that are compatible with the IBM NetView management system.

This section introduces the IBM NetView management system to provide a context for understanding SNA Server network management integration features that are described in “Interoperability with IBM Host Systems” in this book.

IBM NetView is a network management system that was originally designed to monitor and control SNA networks. Subsequent updates extended the NetView architecture to provide integrated management services for non-SNA network resources. The NetView approach to network management is implemented in IBM’s NetView product and in compatible third-party products.


NetView Functions

Table A.9 summarizes the four major functions of IBM NetView.

Table A.9 IBM NetView Management Functions

Management Function | Description
Problem Management | Manages hardware, software, and communication problems from detection through resolution.
Configuration Management | Monitors the relationships between physical and logical network components.
Performance and Accounting Management | Monitors network availability and performance, and tracks network usage charges.
Change Management | Assists with the process of planning, tracking, and controlling changes to network software, hardware, and microcode.


NetView Management Architecture

As shown in Figure A.11, in a traditional SNA management environment, NetView is a centralized management model that specifies three points of network management control:

  • The Focal Point
  • Entry Points
  • Service Points

Figure A.11 NetView Network Management Control Points

  • The Focal Point

    Serves as the central point in the network that collects, analyzes, and stores network management data. This is also the point where network administrators can issue commands in response to network management issues. IBM NetView and compatible network management products can serve as the SNA network focal point. In hierarchical SNA networks, the focal point is typically implemented in a mainframe system. In APPN networks, one or more nodes can serve as focal points.

  • Entry Points

    Implemented in SNA devices to serve as distributed points of control for SNA resources. An entry point gathers information about itself (the SNA device) or about a group of SNA devices, and forwards that information to the focal point. Most IBM SNA network devices can function as entry points.

  • Service Points

    Serve as distributed points of control for hardware or software resources that are not specifically designed for the SNA environment. Service points gather information about non-SNA resources and forward that information to the focal point. Service points can also receive commands from a focal point to be executed on non-SNA resources. As such, service points act as gateways, translating network management information between SNA resources and non-SNA resources.

Since introducing the original version of NetView, IBM has expanded the NetView management model to include hierarchies of nested focal points and distributed collection points. In recent years, IBM has made efforts to upgrade its network management strategy to a more open, enterprise-wide approach that embraces modern, distributed computing platforms such as Windows 2000 .

For information about how SNA Server communicates with IBM NetView, see “Interoperability with IBM Host Systems” in this book.


Copywright

This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unpublished work. © 1998 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, and other names of Microsoft products and/or services referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Any RFC excerpts are subject to the following statement:

Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.