Compartir a través de

How Unicast IPv4 Routing Protocols and Services Work

  • Artículo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Unicast IPv4 Routing Protocols and Services Work

In this section

  • Unicast IP Routing Architecture in Windows Server 2003

  • How RIP Works

  • How OSPF Works

  • How the DHCP Relay Agent Works

  • How IP Packet Filtering Works

  • How ICMP Router Discovery Works

  • IPv4 and Routing and Remote Access APIs

  • Related Information

The Microsoft Windows Server 2003 family of operating systems provides extensive support for unicast Internet Protocol version 4 (IPv4) routing — that is, routing IPv4 packets from a source node to a destination node identified by its unicast destination IPv4 address. IP, a part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite, is the routable network protocol that enables the routing of network traffic across any type of IP internetwork, including Windows internetworks, UNIX internetworks, and mixed network environments. Windows Server 2003 includes support for unicast IPv4 dynamic routing protocols as well as for additional unicast routing features provided by the Windows Server 2003 Routing and Remote Access service. IPv4 is frequently referred to as IP, and that convention is used in this document.

Note

  • Windows Server 2003 also supports Internet Protocol version 6 (IPv6). For information about Windows Server 2003 support for IPv6, including support for static routing in an IPv6 environment, see “How IPv6 Works” in IPv6 Technical Reference.

An organization’s implementation of unicast IP routing can be simple or complex, depending on factors such as the size of its internetwork, the use of Dynamic Host Configuration Protocol (DHCP) to allocate IP addresses, connectivity to the Internet, and the presence of non-Windows hosts on the internetwork. To determine how best to implement or modify the unicast IP routing infrastructure for your internetwork, the first step is to understand how unicast IP routing works.

The Windows Server 2003 Routing and Remote Access service does not include support for the Internetwork Packet Exchange (IPX) protocol, such as Routing Information Protocol (RIP) for IPX, Service Advertising Protocol (SAP) for IPX, Network basic input/output system (NetBIOS) over IPX, or IPX packet filtering.

Unicast IP Routing Architecture in Windows Server 2003

Unicast IP routing occurs on any TCP/IP-based internetwork by using IP routers to forward IP packets from one network segment to another. Unicast IP routing occurs on a Windows Server 2003 IP internetwork whether or not any computers run the Routing and Remote Access service. You can use hardware routers on your internetwork, software routers, or a combination of hardware and software routers. The Windows Server 2003 Routing and Remote Access service can play a role in implementing and supporting unicast IP routing features on a Windows network even when most, or all, routers are hardware routers.

To see an architectural diagram showing where IP fits within the TCP/IP protocol suite, see “TCP/IP Protocol Architecture” in “How TCP/IP Works” in TCP/IP Technical Reference. The following figure shows the architecture of the Routing and Remote Access service in Windows Server 2003. The components are differentiated in the figure as follows:

  • Clear boxes represent components that are used for unicast IP routing and multicast IP routing, as well as for other Routing and Remote Access–supported features.

  • Dark blue boxes represent components that are unique to unicast routing.

  • Light blue boxes represent components that are unique to multicast routing.

  • The orange box represents the only Routing and Remote Access component — Simple Network Management Protocol (SNMP) — that is used neither for unicast nor for multicast routing.

Unicast IP Components of the Windows Server 2003 Routing and Remote Access Service

Windows Server 2003 Routing and Remote Access

The following table describes the unicast IP routing components depicted in the figure, including components that are shared by unicast routing and multicast routing as well as components that are unique to unicast routing. Not included in the table are the non-unicast components: multicast-only components (light blue boxes) or SNMP (orange box). For information about SNMP, see “SNMP Technical Reference.” For information about multicast IP routing, see “IPv4 Multicasting Technical Reference.”

Unicast Routing Components in the Routing and Remote Access Service

Component Description

Routing and Remote Access snap-in

Management application in the Administrative Tools folder for administering unicast IP routing and other routing and remote access features.

Netsh

Command-line management application that provides sets of commands (known as contexts) used to perform a wide range of network configuration tasks, including unicast routing tasks. The Netsh contexts specific to unicast routing include netsh routing and netsh routing ip.

AAA

A set of components that provide authentication, authorization, and accounting (AAA) for the Routing and Remote Access service when it is configured to act as the Windows authentication provider or the Windows accounting provider. Alternatively, the computer running the Routing and Remote Access service can be configured with the Remote Authentication Dial-In User Service (RADIUS) authentication or accounting provider in the Internet Authentication Service (IAS), in which case, the local AAA components are not used.

Dynamic Interface Manager

(Mprdim.dll)

Component that provides the following services for unicast IP routing and other Routing and Remote Access–supported features:

  • Communicates configuration information to the IP Router Manager.

  • Manages all routing interfaces, including local area network (LAN), dial-up interfaces, non-persistent demand-dial interfaces, and persistent demand-dial interfaces. Unlike Windows 2000 Server, Windows Server 2003 Routing and Remote Access does not support IP-in-IP tunnels (which encapsulate an IP packet within another IP packet and forward the packet across the tunnel) and thus does not support IP-in-IP interfaces (logical interfaces used to send IP packets across an IP-in-IP tunnel).

  • Loads configuration information from the Windows Server 2003 registry.

  • Supports a remote procedure call (RPC) interface for SNMP-based management functions used by management tools such as the Routing and Remote Access snap-in.

  • Communicates with the Connection Manager for demand-dial connections.

Connection Manager

A set of components that provides the following services:

  • Manages wide area network (WAN) devices.

  • Establishes connections by using the Telephony application programming interface (TAPI).

  • Negotiates Point-to-Point Protocol (PPP) control protocols, including Extensible Authentication Protocol (EAP). PPP is an industry standard suite of protocols for the use of point-to-point links to transport multiprotocol datagrams. EAP is an extension to PPP that allows for arbitrary authentication mechanisms to be employed for the validation of a PPP connection.

  • Implements multilink protocol (MP) and Bandwidth Allocation Protocol (BAP). MP, also known as MLP or Multilink Point-to-Point Protocol (MPPP), is an extension to PPP that is used to aggregate multiple physical links into a single logical link. BAP is a PPP control protocol that is used on a multilink connection to add and remove links dynamically.

Note: Routing and Remote Access Connection Manager, described here, is not the same as the Connection Manager client dialer.

TAPI

An API used by communications programs to work with telephony and network services. Telephony API, or TAPI, provides services to create, monitor, and terminate connections in a hardware-independent manner. Connection Manager uses TAPI to create or receive demand-dial connections.

IP Router Manager

(Iprtrmgr.dll)

Component that starts and manages other routing components, including routing protocols, the routing table manager, and the multicast group manager. The IP Router Manager provides the following services:

  • Obtains configuration information from the dynamic interface manager.

  • Communicates IP packet filtering configuration to the IP filtering driver.

  • Communicates IP routing configuration information to the IP forwarder in the TCP/IP protocol.

  • Maintains an interface database of all IP routing interfaces.

  • Loads and communicates configuration information to IP routing protocols that are supplied with Windows Server 2003, such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF).

  • Initiates demand-dial connections for routing protocols by communicating with Dynamic Interface Manager.

IP RIP

(Iprip2.dll)

A unicast distance vector dynamic routing protocol. The RIP for IP routing protocol (also known simply as RIP) provides the following services:

  • Communicates RIP learned routes by using the Route Table Manager.

  • Uses Windows Sockets (Winsock) to send and receive RIP traffic. Winsock is an implementation of the industry-standard Sockets API for the Windows operating system.

  • Exports management APIs to support SNMP management information bases (MIBs) and other management applications by using the IP Router Manager. A MIB is a set of objects, which represent various types of information about a device that are used by SNMP to manage the device.

The Windows Server 2003 Routing and Remote Access service supports (for IPv4 only) both RIP version 1 and version 2 (RIP v1 and RIP v2). However, RIP v1 is considered outdated. For more information about RIP v1 and RIP v2, see “How RIP” later in this document.

OSPF

(Ospf.dll)

A unicast link state dynamic routing protocol. The OSPF routing protocol performs the following services:

  • Communicates OSPF learned routes by using the Route Table Manager.

  • Uses Winsock to send and receive OSPF traffic.

  • Exports management APIs to support SNMP MIBs and other management applications by using the IP Router Manager.

The OSPF routing protocol is available only on 32-bit versions of Windows Server 2003. For more information about OSPF, see “How OSPF Works” later in this document.

Route Table Manager

(Rtm.dll)

(Also called Routing Table Manager)

The central repository for routing information for all routing protocols that operate under the Routing and Remote Access service and for other components such as the IP Router Manager. The Route Table Manager provides the following services:

  • Maintains a user-mode routing table for all routes from all possible route sources.

  • Exposes APIs for adding, deleting, and enumerating routes that are used by the routing protocols.

  • Timestamps learned routes.

  • Provides routing information to routing protocols, management programs, and monitoring programs.

  • Communicates only the best routes to the appropriate IP forwarder driver. For IP routes, the best route is the route with the lowest cost based on specified criteria, such as the number of networks crossed, the type of network crossed (for example, private or public), or a monetary or bandwidth limit. The best routes become the routes in the IP forwarding table.

  • Supports multiple instances of the same protocol, such as the Microsoft implementation of OSPF and other implementations of OSPF.

IP Filtering

(Ipfltdrv.sys)

Component that performs the following services:

  • Obtains configuration information from the IP Router Manager.

  • Applies IP filters after the IP forwarder has found a route.

IP Unicast Forwarder

A component of the TCP/IP protocol (Tcpip.sys). The IP Unicast Forwarder performs the following services:

  • Obtains configuration information from the IP Router Manager.

  • Stores the IP forwarding table, a table of the best routes obtained from the Route Table Manager.

  • Determines the next-hop address and interface for IP packets being forwarded.

  • Forwards unicast IP traffic from one router interface to another router interface.

  • Initiates a demand-dial connection.

NDIS Wrapper

(Ndis.sys)

Code that surrounds all Network Driver Interface Specification (NDIS) device drivers. Windows Server 2003 NDIS (and Windows 2000 Server NDIS) is implemented by a file called Ndis.sys, referred to as the NDIS Wrapper. NDIS enables transport protocols such as TCP/IP to communicate with an underlying network adapter or other hardware device so that the network adapter can send or receive data over the network. The NDIS Wrapper provides a uniform interface between protocol drivers and NDIS device drivers.

Note

  • Network address translation (NAT) is a feature of the Routing and Remote Access service and is part of unicast routing. However, NAT is not shown in the preceding figure or table because NAT is not a routing protocol. For information about the NAT routing protocol component and Routing and Remote Access NAT architecture, see “How NAT Works” in NAT Technical Reference.

Routing and Remote Access Unicast IP Routing Processes

Typical unicast IP routing processes for the components of the Routing and Remote Access service described in the preceding section include the following types of communications.

Incoming and outgoing packet (transit traffic)

An incoming packet is passed by the TCP/IP driver to the IP forwarder, which finds a route and then passes the packet to the IP filtering driver to check for input and output filters. If the packet is approved for acceptance by the input filters and for forwarding by the output filters, it is passed back to the IP forwarder driver, which uses NDIS to forward the packet over the appropriate interface. If the input or output filters do not permit the packet to be received or forwarded, the packet is silently discarded. If a route is not found, an Internet Control Message Protocol (ICMP) Destination Unreachable-Host Unreachable message is sent back to the source of the packet.

Incoming packet (local host traffic)

An incoming packet is passed by the TCP/IP driver first to the IP forwarder, which notes that the packet is not to be routed (because the destination IP address is an address assigned to the router or it is a broadcast address). The IP forwarder then hands the packet to the IP filtering driver to check for input filters. If the packet is accepted by the input filters, it is passed up to the TCP/IP driver, which processes the packet. If the packet is not accepted by the input filters, the packet is silently discarded.

Outgoing packet (local host traffic)

An outgoing packet is passed by the TCP/IP driver to the IP filtering driver, which checks for output filters. If the packet is approved for sending by the output filters, the packet is passed to the IP forwarder, which sends the packet by using the best route over an appropriate interface that uses NDIS. If the packet is not approved by the output filters, the packet is silently discarded. If a route is not found, an IP routing error is passed to the source application of the packet.

Routing protocol network communication

The RIP for IP and OSPF routing protocols operate like any other Winsock application that sends or receives IP packets. For a brief description of the Windows Sockets 2 (Winsock2) API, see “IPv4 and Routing and Remote Access APIsW2K3TR” later in this document. For more information about the Windows Sockets API, see “Microsoft Platform SDK Windows Sockets 2.”

Routing table updates

The RIP and OSPF routing protocols update routes in the Route Table Manager. Based on the best route and route source ranking, the table of best routes (the IP forwarding table) is updated in the IP forwarder.

Routing and Remote Access Features by Windows Server Operating System

In addition to support for unicast IP routing features, the Routing and Remote Access service for Windows Server 2003 also includes a variety of other routing and remote access features, most of which interact with or support unicast IP routing — for example, LAN and WAN support, both of which are integral to unicast IP routing, and the Routing and Remote Access snap-in, which you can use to configure unicast IP routing features. The following table lists the routing and remote access features available in Windows operating systems from Windows NT 3.51 to Windows Server 2003.

Comparison of Routing and Remote Access Features in Windows Operating Systems

Feature Windows NT Server 3.51 SP2 Windows NT Server 4.0 SP3 Windows 2000 Server Windows Server 2003

Static IP routing

 Table Bullet Table Bullet Table Bullet Table Bullet

RIP for IP version 1 (RIP v1)

 Table Bullet Table Bullet Table Bullet Table Bullet

RIP for IP version 2 (RIP v2)

 

 Table Bullet Table Bullet Table Bullet

RIP for IPX

 Table Bullet Table Bullet Table Bullet

 

SAP for IPX

 Table Bullet Table Bullet Table Bullet

 

NetBIOS over IPX

 Table Bullet Table Bullet Table Bullet

 

Routing and remote access combined into one service

 

 Table Bullet Table Bullet Table Bullet

Inclusion of routing and remote access with Windows

 

 Table Bullet Table Bullet Table Bullet

OSPF

 

 Table Bullet Table Bullet Table Bullet

IP packet filtering

 

 Table Bullet Table Bullet Table Bullet

Basic stateful firewall

 

 

 

 Table Bullet

IPX packet filtering

 

 Table Bullet Table Bullet

 

ICMP router discovery

 

 Table Bullet Table Bullet Table Bullet

DHCP relay agent

 Table Bullet Table Bullet Table Bullet Table Bullet

Network address translation (NAT)

 

 

 Table Bullet Table Bullet

Remote Authentication Dial-In User Service (RADIUS) client

 

 Table Bullet Table Bullet Table Bullet

AppleTalk routing

 

 

 Table Bullet Table Bullet

Remote access routing (dial-up)

 

 Table Bullet Table Bullet Table Bullet

Remote access routing using Point-to-Point Tunneling Protocol (PPTP) virtual private networking

 

 Table Bullet Table Bullet Table Bullet

Remote access routing using Layer Two Tunneling Protocol over Internet Protocol Security L2TP/IPSec virtual private networking

 

 

 Table Bullet Table Bullet

IP-in-IP tunneling

 

 

 Table Bullet

 

SNMP MIB

 

 

 Table Bullet Table Bullet

LAN and WAN support1

 

 Table Bullet Table Bullet Table Bullet

Multicast IP forwarding

 

 

 Table Bullet Table Bullet

Graphical administrative tool:

Routing and RAS Admin

 

 Table Bullet

 

 

Graphical administrative tool:

Routing and Remote Access snap-in (MMC)

 

 

 Table Bullet Table Bullet

Command-line tool: Routemon.exe

 

 Table Bullet

 

 

Command-line toolset: Netsh.exe (Netsh routing IP commands)

 

 

 Table Bullet Table Bullet

1. The Routing and Remote Access service works with a wide variety of hardware platforms and can run over any of the many LAN and WAN network adapters supported by Windows. For information about supported network adapters, see “Windows Server Catalog.”

IPX routing is available only on Windows NT Server 3.51 Service Pack 2 (SP2), Windows NT Server 4.0 SP3, and the 32-bit versions of Windows 2000 Server. IPX is not available on any version of Windows Server 2003. OSPF is available only on Windows NT Server 3.51 SP2, Windows NT Server 4.0 SP3, and on 32-bit versions of Windows 2000 Server and Windows Server 2003.

For more information about the following topics, see the following references:

Unicast IP Routing in a Windows-based Internetwork

A typical IPv4 internetwork might contain a mix of computers running Windows Server 2003, Windows XP, Windows 2000 Server, Windows 2000 Professional, or UNIX operating systems. These computers might be located in multiple subnets connected by hardware routers from Cisco Systems and software routers running the Windows Server 2003 Routing and Remote Access service. Such an internetwork can easily communicate with computers on the global Internet because the Internet is also an IP internetwork.

A medium-size or enterprise-size Windows IP internetwork typically deploys the Active Directory directory service, DNS, and DHCP, and the following routing-related services:

  • A routing protocol, such as RIP v2 or OSPF, to enable routing information exchange between routers on an IP internetwork

  • DHCP relay agents to enable DHCP clients on a subnet with no DHCP server to request IP addresses from a DHCP server located on a different subnet

  • IP packet filtering, such as Web traffic filtering or L2TP/IPSec traffic filtering, to allow only specific types of traffic

  • ICMP router discovery to enable IP hosts to discover the best default gateway router on a subnet

How RIP Works

Routing Information Protocol (RIP) for IP facilitates the dynamic exchange of routing information between RIP routers over IP internetworks. Routers can add or remove routes automatically as networks are added or removed from the internetwork. RIP, the best known and currently most widely used of the distance vector dynamic routing protocols for IP internetworks, is an open standard developed by the Internet Engineering Task Force (IETF).

RIP version 1 (RIP v1), which is now outmoded, was the first routing protocol accepted as a standard for TCP/IP. The updated RIP version 2 (RIP v2) supports simple password authentication (a form of router identification, not a security option) and, more important, provides improved support for classless networks. The Windows Server 2003 Routing and Remote Access service supports both RIP v1 and RIP v2 (for IPv4 only).

Note

  • The Windows Server 2003 Routing and Remote Access service does not support RIPng, the version of RIP for IPv6, or any other IPv6 routing protocol. For information about Windows Server 2003 support for IPv6, including support for static routing in an IPv6 environment, see “How IPv6 Works” in IPv6 Technical Reference.

RIP has its origins in the Xerox Network Systems (XNS) version of RIP. RIP for IP became a popular routing protocol due to its inclusion in the Berkeley Software Distribution (BSD) UNIX (BSD 4.2 and later) as the routed server daemon (a UNIX daemon is similar to a Windows Server 2003 service). The BSD 4.2 version of UNIX, introduced in 1983, incorporated the TCP/IP protocol suite and initiated the explosive growth of TCP/IP and what later became known as the Internet. RIP v1 is defined in RFC 1058 and RIP v2 is defined in RFC 2453. In this document, when neither RIP v1 nor RIP v2 is explicitly cited, information about RIP applies to both versions.

This section describes:

  • RIP features appropriate for small- to medium-sized internetworks

  • How RIP convergence works

  • Basic processes common to RIP v1 and RIP v2

  • How RIP v1 works

  • How RIP v2 works

RIP Features Adppropriate for Small- to Medium-Sized Internetworks

RIP is a useful solution for a small- to medium-sized IP internetwork (10 to 50 networks). As a dynamic routing protocol, it can update topology changes as networks are added or removed and as links fail and are restored.

Although RIP is simple to administer and well supported in the industry, it has some of the limitations inherent to its original LAN-based design. These limitations, in combination, make RIP an inappropriate solution for enterprise-sized IP internetworks.

RIP Hop Counts

RIP uses a hop count as the metric to determine the best route among multiple possible routes stored in an IP routing table. The hop count is the number of routers that must be crossed to reach a specific subnet. A computer on the local subnet is one hop, and each router crossed after that is an additional hop.

RIP has a maximum hop count of 15. Therefore, any two hosts can be separated by no more than 15 routers. Subnets that are 16 or more hops away are unreachable and are thus said to be an "infinite" distance away. Any attempt to forward packets to hosts on that subnet result in an ICMP Destination Unreachable–Host Unreachable message from the RIP router, indicating that the packet cannot be delivered. Although the accumulated hop count between any two subnets must not exceed 15 hops, this restriction is not as limiting as it might seem because, if routers are placed in a hierarchical structure, 15 hops can cover a large number of destinations.

The RIP hop count is independent of the Time-to-Live (TTL) field in the IP header. On an IP internetwork, a subnet 16 hops away would normally be reachable for an IP packet with an adequate TTL. However, to the RIP router, that subnet is unreachable.

Using the number of routers to cross as the basis for selecting the best route can produce an unwanted result. For example, if a T1 link is the primary connection between two sites and a slower satellite link is used as a backup in case the T1 link fails, RIP assigns both links the same metric. When a router chooses between these two routes, it might select either one. If the satellite link is selected, traffic is slower. To avoid this type of problem, the cost of each interface is configurable. Typically, the hop count value for slow links is set to multiple hops to ensure that fast links, which are assigned a lower hop count value, take precedence over slow links. In this example, you can assign a higher cost to the satellite interface to ensure that the T1 link is selected as the best route whenever both routes are available. Only if the T1 link fails will the satellite link be selected.

Although the maximum diameter of a RIP internetwork is defined by RFCs 1058 and 2453 to be 15 routers, for a server running the Routing and Remote Access service, the effective diameter is only 14 routers. This is because, for a Routing and Remote Access RIP router, all non-RIP learned routes — such as static routes (including static routes for directly connected networks), OSPF routes, and SNMP routes — have a fixed hop count of 2. Therefore, when the Routing and Remote Access RIP router advertises its directly connected networks, it advertises them at a hop count of 2 even though there is only one physical router to cross.

Note

  • In a networking environment that includes Routing and Remote Access RIP routers, make sure that the accumulated costs (hop counts) between any two endpoints on the internetwork does not exceed 14.

RIP Routing Table Entries

When a RIP router first starts up, its routing table contains only the networks to which it is physically connected. This router, as it initiates, sends periodic announcements that contain its routing table entries to inform neighboring RIP routers about the networks that it can reach. In turn, it receives route advertisements from other RIP routers that it adds to its own routing table.

For a subnet that has multiple paths, RIP allows storage of multiple entries in a routing table. For RIP routers that do store a complete list of all network IDs and all possible routes to reach each subnet, the routing table can have hundreds or even thousands of entries in a large multipath IP internetwork. The IP routing process chooses the route with the lowest metric (lowest hop count) as the best route. Because only 25 routes can be sent in a single RIP packet, large routing tables must be sent as multiple RIP messages.

Although in theory RIP can store multiple entries for a multipath subnet in a routing table, typical RIP router implementations — including Windows Server 2003 — store only a single lowest-metric route for any subnet in the routing table. If multiple lowest hop count routes are received by RIP, the first lowest-metric route received is stored in the routing table.

“RIP Route Advertising”

Typically, RIP either broadcasts or multicasts announcements. However, RIP can also unicast RIP announcements to specific RIP neighbors.

RIP broadcasting of announcements for mixed environment

Typically, a RIP router uses an IP subnet and MAC-level broadcast to advertise the entire contents of its routing table on all attached networks. The announcement interval is every 30 seconds by default. RIP v1 announcements are always broadcasted. RIP v2 announcements can be broadcasted or multicasted.

You must use broadcasting if your network is a mixed environment that includes both RIP v1 and RIP v2 routers. Both RIP v1 routers and RIP v2 routers can process a RIP v2 broadcast announcement.

RIP multicasting of announcements for the RIP v2 environment

RIP v2 routers are configured, by default, to broadcast RIP announcements, but they have the capability to multicast RIP announcements to the IP multicast address of 224.0.0.9 instead. The router does not register this multicast address by using Internet Group Management Protocol (IGMP) because the address is in the local network control block range, as defined by the Internet Assigned Numbers Authority (IANA).

Use RIP v2 multicast announcements only if all neighboring RIP routers on the network connected to this interface are configured for RIP v2. A RIP v1 router cannot process a RIP v2 multicast announcement.

RIP v2 announcements must be multicast if you are performing auto-static updates across demand-dial links. An auto-static update is a one-time, one-way transfer of routing information. A router that has a demand-dial interface configured for auto-static updates sends a message across an active connection requesting all of the routes of the router on the other side of the connection. This request is not automatic; the request is sent only when an administrator issues a command or a scheduled task initiates auto-static updates. When the remote router responds, the routes of the remote router are automatically entered in the routing table of the requesting router. The routes are saved in the routing table even if the router is restarted or the interface goes down.

For RIP v2 to support auto-static updates, you must configure a demand-dial interface on each router to use RIP v2 multicast announcements and to accept RIP v2 announcements. Otherwise, the RIP request for routes does not receive a response from the remote router. (OSPF does not support auto-static updates.)

For more information about RIP v2 support for multicast RIP announcements, see “RIP v2 Updates RIP for Modern Internetworks” later in this document.

RIP unicasting of announcements to specific RIP neighbors

Although RIP typically broadcasts or multicasts announcements, it can also unicast RIP announcements to specific RIP routers known as RIP neighbors.

Unicasting RIP announcements to RIP neighbors was originally developed specifically to support nonbroadcast multiple access (NBMA) network technologies. NBMA networks, such as Frame Relay, X.25, or Asynchronous Transfer Mode (ATM), can connect more than two routers but cannot broadcast a single frame to all routers attached to that network. However, the configuration of RIP neighbors is also useful for the wider purpose of ensuring that RIP announcements are directed to specific neighboring RIP routers. Configuring a RIP router to unicast RIP announcement to specified neighboring RIP routers helps prevent RIP traffic from being received by any other node.

Configuring RIP routers to unicast to neighboring RIP routers can interfere with the ability of silent RIP hosts to receive RIP traffic. Silent RIP is a feature that lets an IP host listen to routing traffic exchanged by RIP routers and update its routing table accordingly. If you use silent RIP hosts, you can solve this interference problem by adding silent RIP hosts as neighbors. Use a static IP address for a silent RIP host. Otherwise, if you let DHCP assign an IP address to a silent RIP host, that address might change, and this host will no longer receive the unicast RIP messages sent by the RIP router.

How you configure RIP for an NBMA network depends on how Frame Relay virtual circuits appear as network interfaces on a RIP server running Routing and Remote Access. Frame Relay virtual circuits appear in the Routing and Remote Access snap-in either as a single adapter or as multiple adapters. A virtual circuit is a logical path or connection between nodes in a network. After the nodes of a virtual circuit establish a connection, the nodes can communicate as if they were directly connected by physical wires.

The following descriptions assume that you have a Frame Relay network, but other NBMA technologies, such as X.25 and ATM, function in a similar manner:

  • Single-adapter model unicasts RIP announcements. All virtual circuits on a RIP router function as a single adapter. In the single-adapter model, also known as the NBMA model, the network of the Frame Relay service provider (also called the Frame Relay cloud) is treated as an IP network, and the endpoints on the cloud are assigned IP addresses from a designated IP network ID. To ensure that RIP traffic is received by all of the appropriate endpoints on the cloud, you must configure the Frame Relay interface to unicast its RIP announcements to each appropriate endpoint. On a Routing and Remote Access RIP router, you do this by designating the interface as an NBMA network and by configuring RIP to unicast announcements to the specified neighbor routers.

    In a hub-and-spoke Frame Relay topology in a RIP-based IP internetwork, the Frame Relay interface for the hub router must have split-horizon processing disabled. Otherwise, the spoke routers never receive each other’s routes. For more information, see “Split Horizon Processing” later in this section.

  • Multiple-adapter model broadcasts or multicasts RIP announcements. Each virtual circuit functions as a separate adapter. In the multiple-adapter model, each Frame Relay virtual circuit functions as a point-to-point link with its own network ID, and the endpoints on the cloud are assigned IP addresses from a designated IP network ID. Because each virtual circuit is its own point-to-point connection, you can either broadcast (assuming both endpoints are on the same IP network ID) or multicast RIP announcements.

On a RIP router running Windows Server 2003 Routing and Remote Access, broadcasting or multicasting RIP announcements is configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\RIP node, and then using the General tab of the InterfaceNameProperties page. Unicasting RIP announcements to specific RIP neighbors is configurable on the Neighbors tab of the same InterfaceNameProperties page.

RIP Convergence

Convergence is among the most important factors when considering features that make RIP appropriate for small- to medium-sized internetworks but unsuitable for large enterprise internetworks. Convergence is the process by which routers update routing tables after a change in network topology occurs — the change is replicated to all routers that need to know about it. When convergence is achieved, the internetwork is in a stable state and all routing occurs along optimal paths. If, after convergence is achieved, a link or router fails, the internetwork must reconfigure itself to reflect the new topology.

By default, on a RIP internetwork, each routing table entry that is learned through RIP is given a time-out value of three minutes after the last time the entry was received in a RIP announcement from a neighboring RIP router. Therefore, when a router stops responding because of a hardware or software failure, several minutes can elapse before RIP propagates the topology change throughout the entire internetwork. The delay that occurs before the successful propagation of routes is achieved is known as slow convergence, which is a characteristic of RIP internetworks.

For more information about RIP convergence, including how slow convergence occurs and how to improve convergence time on a RIP internetwork, see “How RIP Convergence Works,” described next.

How RIP Convergence Works

RIP, like most distance vector routing protocols, announces its routes in an unsynchronized and unacknowledged manner. Although this imprecise announcement scheme can lead to convergence problems, you can modify the announcement algorithms to reduce convergence time on a RIP network in most situations.

How Count-to-Infinity Occurs

The classic distance vector convergence problem, known as count-to-infinity, results from the asynchronous announcement scheme. When a RIP router updates its routing table based on RIP announcements from other routers, the RIP router stores only the best route to each network and it updates a lower-cost route with a higher-cost route only if the higher-cost route is announced by the same source as the current lower-cost route. In some situations, as illustrated in the following series of five figures, this causes the count-to-infinity problem.

Assume that the IP internetwork in the following figure has converged. For simplicity, only announcements sent by Router 1 on Network 2 and Router 2 on Network 2 are depicted; announcements sent by Router 1 on Network 1 and Router 2 on Network 3 are not included in the discussion.

Count-to-Infinity Phase 1: Converged RIP Internetwork

Internetwork

Now, assume that the link from Router 2 to Network 3 fails, and the failure is sensed by Router 2. As the next figure shows, Router 2 changes the hop count for the route to Network 3 to indicate that it is unreachable, an infinite distance away. For RIP, infinity is 16.

Count-to-Infinity Phase 2: Link to Network 3 Fails

Count-to-Infinity Phase 2: Link to Network 3 Fails

However, before Router 2 can advertise the new hop count to Network 3 in a scheduled announcement, Router 2 receives an announcement from Router 1. The Router 1 announcement contains a route to Network 3, which is two hops away. Because two 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 the following figure.

Count-to-Infinity Phase 3: Router 2 Updates from Router 1

Count-to-Infinity Phase 3: Router 2 Updates

When Router 2 announces its new routes, Router 1 notes that Network 3 is available three 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 four hops, as shown in the following figure.

Count-to-Infinity Phase 4: Router 1 Updates from Router 2

Art Image

Now, when Router 1 announces its new routes, Router 2 notes that Network 3 is available four 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 five hops, as shown in the following figure.

Count-to-Infinity Phase 5: Router 2 Updates Again from Router 1

Count-to-Infinity Phase 5: Router 2 Updates

The two routers continue to announce routes to Network 3 with higher and higher hop counts until infinity (16) is reached. At that point, Network 3 is considered unreachable, and the route to Network 3 is eventually timed out of the routing table. This routing loop 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). A higher maximum hop count would make the convergence time longer when count-to-infinity occurs.

Note also that during the count-to-infinity process in the preceding example, the route from Router 1 to Network 3 is through Router 2, and 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 speed recovery of RIP internetworks when topology changes occur and to help avoid the count-to-infinity problem and routing loops that persist for the duration of the count-to-infinity process, an administrator can modify the RIP announcement process by using the following algorithms:

  • Split horizon

  • Split horizon with poison reverse

  • Triggered updates

On a Routing and Remote Access RIP router, these options are configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\RIP node in the console tree, and then accessing the Advanced tab of the appropriate InterfaceNameProperties page. By default, all three options are enabled to improve convergence on a RIP internetwork.

Split Horizon

Split horizon is a routing technique that reduces convergence time by preventing or reducing the occurrence of the count-to-infinity problem and the associated routing loops that can occur in distance vector routing protocols such as RIP. When split-horizon processing is enabled, information about routes is not announced over the router interface through which that information was received. Thus, a router configured to use split horizon processing omits routes learned from a specific neighboring router in updates that it returns to that neighbor. If split-horizon processing is not configured, routes learned on a network are announced on the same network. The Windows Server 2003 Routing and Remote Access service enables split-horizon processing by default.

Split horizon eliminates the count-to-infinity problem and routing loops during convergence in single-path internetworks and reduces the chances of encountering count-to-infinity problems in multipath internetworks. The following figure shows how split horizon processing keeps the RIP router from advertising routes in the direction from which they were learned.

Split Horizon Announcement Process

Horizon Announcement Process

Split Horizon with Poison Reverse

Split horizon with poison reverse processing refers to routing updates that explicitly indicate that a network or a subnet is unreachable, rather than merely implying that a network is unreachable by not including it in updates. Whereas the simple split horizon method omits routes learned from one neighbor in updates sent to that neighbor, the split horizon with poison reverse method includes such routes in updates, but announces them with a hop count of 16, indicating that the subnet for these routes is unreachable. Split horizon with poison reverse processing can be enabled only if split horizon processing is enabled.

In a single-path internetwork, split horizon with poison reverse has no greater benefit than split horizon. However, in a multipath internetwork, split horizon with poison reverse greatly reduces count-to-infinity problems and routing loops. Count-to-infinity problems can still occur in a multipath internetwork because routes to networks can be learned from multiple sources.

In the following figure split horizon with poison reverse advertises learned routes as unreachable in the direction from which they are learned. Split horizon with poison reverse, however, has the disadvantage of requiring additional RIP message overhead because all networks are advertised.

Split Horizon with Poison Reverse Announcement Process

Horizon with Poison Reverse Announcement Process

On a Windows Server 2003 Routing and Remote Access RIP router, split-horizon processing and poison-reverse processing (both enabled by default) are configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\RIP node in the console tree, and then selecting or clearing the Enable split-horizon processing and Enable poison-reverse processing options on the Advanced tab of the InterfaceNameProperties page. Alternatively, if you do not want both options enabled, you can select Enable split-horizon processing and clear Enable poison-reverse processing. However, you cannot select Enable poison-reverse processing unless you first select Enable split-horizon processing.

Triggered Updates

In addition to making periodic announcements to other local RIP routers, a RIP router can also communicate routing information through triggered updates. A triggered update is an update that is announced as soon as a network topology change occurs; only the change is announced. Triggered updates improve the convergence time of RIP internetworks but do so at the expense of additional network traffic.

The trigger for an update to the routing table is one of the following:

  • The router starts advertising the network ID for a subnet attached to a newly operational interface on the router.

  • The router starts advertising the network ID for a subnet attached to a newly inoperational interface on the router as 16 hops (unreachable).

  • The router modifies its routing table in response to an update from a neighboring router.

  • The router removes a routing table entry because it has timed out.

For example, if a network becomes unavailable due to a problem such as a link or router failure, a RIP router updates its own routing table and can use a triggered update to announce the unavailable network with a hop count of 16. An interval to wait between sending triggered updates is typically specified on the router (on a Routing and Remote Access RIP router, the default is 5 seconds). Otherwise, if all routers immediately send triggered updates, these updates could cause a cascade of traffic across the IP internetwork.

On a Windows Server 2003 Routing and Remote Access RIP router, triggered updates processing (enabled by default) is configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\RIP node in the console tree, and then selecting the Enable triggered updates option on the Advanced tab of the InterfaceNameProperties page. The maximum time (in seconds) that elapses between triggered updates is configurable by using the General tab on the RIP Properties page.

Basic Processes Common to RIP v1 and RIP v2

The standard operation of a RIP for IP router consists of three processes: initialization, when the router learns the routes of the internetwork from neighboring routers; ongoing periodic advertisements; and advertisement of unreachable routes when a router is brought down intentionally or fails.

Initialization

During startup, the RIP router announces its locally attached networks on all of its interfaces. Neighboring RIP routers process the RIP announcement and add routes to their routing tables, as appropriate.

The initializing RIP router also sends a general RIP request to all locally attached networks. The general RIP request is a special RIP message that requests all routes. Neighboring RIP routers receive the general RIP request and send a unicast reply to the requesting router. The initializing RIP router uses the replies to build its routing table.

Ongoing Maintenance

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

RIP routers send announcements for routers that are shut down by administrators for reasons such as routine maintenance and for links or routers that fail unexpectedly.

Administrative Router Shutdown

If a RIP router is turned off correctly through an administrative action, it sends a triggered update to neighboring routers on all locally attached networks as it shuts down, to inform neighboring routers that networks available through it have become unavailable. The triggered update announces the networks with a hop count of 16 (unreachable). The neighboring RIP routers then use triggered updates to propagate this topology change throughout the IP internetwork.

Response to Topology Changes

As dynamic routers, functioning RIP routers react to changes in the internetwork topology from downed links or downed routers:

If a link that corresponds to one of the router’s interfaces fails, and if the failure is detected by the interface hardware and is indicated to the router, the router sends this change out to neighboring routers as a triggered update.

Downed router

If a router stops responding due to a power outage or other hardware or software failure, it cannot 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 that is learned by RIP 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 (unreachable) and is, therefore, eventually removed from the routing table.

Thus, if a RIP router fails unexpectedly, it takes up to 3 minutes for the neighboring routers to mark as unreachable the routes that are learned from the failed router. Only then do they propagate the topology change throughout the internetwork by using triggered updates.

How RIP v1 Works

RIP v1, defined in RFC 1058, is still deployed in many small- to medium-sized intranets. However, RIP v1 is now considered outdated because it does not fully support classless addressing — including variable length subnet masking (VLSM), which enables configuring subnets of variable size, and classless interdomain routing (CIDR), which enables route summarization.

RIP v2 and OSPF do support CIDR and VLSM, so there is no reason to deploy RIP v1 as the primary routing protocol even for a small network. However, if routers that do not support RIP v2 exist on an IP internetwork, it is possible to deploy a mixed environment that includes both RIP v1 and RIP v2 routers. For more information about mixed environments, see “Mixed RIP v1 and RIP v2 Environments” later in this section.

RIP v1 Message Format

RIP messages are sent as User Datagram Protocol (UDP) messages 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. The following figure illustrates the format of a RIP v1 message.

Message Format for RIP v1

Message Format for RIPA v1

The following table describes the fields depicted in the figure. The four fields named Must Be Zero were reserved for future use; as will be described later, RIP v2 uses three of these fields.

RIP v1 Message Fields

Field Description

Command

A 1-byte field that contains a value of either 1 or 2, indicating request or response, respectively.

  • Request. A value of 1 indicates a RIP request to neighboring routers asking for all (a general RIP request) or part of their routing tables.

  • Response. A value of 2 indicates a RIP response from a neighboring router, consisting of all or part of the neighbor's routing table. A RIP response can be sent in response to a RIP request from a requesting router, or as a periodic or triggered update message generated by the sending router.

Version

A 1-byte field that is set to 1 to indicate RIP v1.

Family Identifier

A 2-byte field that identifies the routable protocol family. In an IP internetwork, this field is set to 2 to indicate the IP routable protocol family.

IP Address

A 4-byte field that is set to the IP network ID, which can be any of the following:

  • A class-based network ID

  • A subnetted network ID (advertised only within the subnetted network)

  • An IP address (for a host route)

  • 0.0.0.0 (for the default route)

For a general RIP request, the IP Address field is set to 0.0.0.0.

Metric

A 4-byte field that indicates the number of hops to the IP subnet. This field must be a value from 1 to 16. The metric is set to 16 in a general RIP request or to indicate that the subnet is unreachable in a RIP response.

Why RIP v1 Is Outdated

The following sections explain the primary historical and technical reasons that make RIP v1 out-of-date in a modern IP internetwork.

MAC-level broadcasting of RIP announcements designed for LANs

RIP v1 was designed in 1988 to satisfy the dynamic routing needs of LAN-based IP internetworks. Shared-access LAN technologies, such as Ethernet or Token Ring, support MAC-level broadcasting, in which a single packet can be received and processed by nodes on a subnet. All RIP v1 route announcements are addressed to the IP subnet (all host bits are set to 1) and MAC-level broadcast addresses. Non-RIP nodes also receive RIP v1 announcements.

In modern IP internetworks, the use of MAC-level broadcasts is unsatisfactory because all nodes must process all broadcasts. For large or very large RIP internetworks, the amount of broadcast traffic on each subnet can become substantial enough to affect node performance.

Subnet mask not announced with the route

RIP v1 originated in an era when the Internet was still using network IDs based on the standard Internet address classes. Today, however, the use of CIDR (for route summarization) and VLSM (for configuring subnets of varying size) is widespread, making the standard address classes obsolete.

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 with RIP v1, 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 one of the standard address classes (Class A, Class B, or Class C), the default class-based subnet mask is assumed.

  • If the network ID does not fit any address class, one of the following occurs:

    • 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 preceding assumptions, RIP v1 can misinterpret summarized routes as a single class-based network ID rather than as a range of class-based network IDs. In addition, with noncontiguous subnets, RIP v1 can misinterpret subnet routes that are advertised outside the network ID being subnetted as host routes.

RIP v1 can support only physically contiguous, fixed-size subnets. RIP v1 routers can support subnetted environments to a limited extent because they do not advertise the subnets of a subnetted class-based network ID outside the subnetted region of the IP internetwork. Subnets of a network ID in a RIP v1 environment must be contiguous, because only the class-based network ID is advertised outside the subnetted environment. Noncontiguous subnets, also known as discontiguous subnets, occur when another network with a different network ID separates subnets of a classful network. If the subnets of a network ID are noncontiguous, 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 subnet.

No protection from rogue RIP routers

RIP v1 does not provide any protection from a rogue RIP router that starts up on a subnet and announces false or inaccurate routes. RIP v1 announcements are processed regardless of their source. A malicious user can use this lack of protection to overwhelm RIP routers with hundreds or thousands of false or inaccurate routes. However, on a RIP router running Windows Server 2003 Routing and Remote Access, you can configure RIP to accept only RIP announcements from specified IP addresses.

How RIP v2 Works

RIP v2, which is defined in RFC 2453, reduces or eliminates 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 was extended in the new RIP v2 implementation because RIP has the following advantages over OSPF:

  • Easy to implement. In its simplest form (when defaults are accepted), implementing RIP for IP is as easy as configuring IP addresses and subnet masks for each router interface and then turning on the router.

  • Widely in use. RIP is installed in a large number of small-sized and medium-sized IP internetworks.

RIP v2 Updates RIP for Modern Internetworks

RIP v2 adds several key features to RIP v1 that help today’s IP internetworks minimize broadcast traffic, conserve IP addresses by using VLSM and CIDR, and help secure the routing environment from incorrectly or maliciously configured routers.

Support for multicast RIP announcements

As explained earlier, RIP v2 supports sending RIP announcements to the IP multicast address of 224.0.0.9. In addition, in contrast to RIP v1, non-RIP nodes are not disturbed by RIP v2 router announcement traffic when multicasting is used.

A disadvantage of the new multicast announcement feature, however, is that silent RIP nodes, if they exist, must also listen for the multicast traffic that is sent to 224.0.0.9. If your computers use silent RIP, verify that the silent RIP nodes can listen for multicasted RIP v2 announcements before you deploy multicasted RIP v2. The Windows Server 2003 (or Windows 2000 Server) Routing and Remote Access service can be configured to send out RIP v1, RIP v2, or both types of packets.

For more information about multicast RIP announcements, see “RIP Route Advertising” earlier in this section.

Support for subnet masks

RIP v2 announcements send the subnet mask (also known as a network mask) along with the network ID. Because RIP v2 has this capability, it supports VLSM and CIDR, which means that RIP v2 can operate in variable-length subnetted internetwork environments and can use route summarization. It also means that RIP v2 can manage noncontiguous subnets without experiencing the routing errors that occur with RIP v1.

Support for simple password authentication

RIP v2 supports the use of simple password authentication to verify the origin of incoming RIP announcements. Simple password authentication for RIP v2 is defined in RFC 1723. Enabling simple password authentication helps prevent an unauthorized or incorrectly configured RIP router from corrupting RIP routes on a subnet.

Newer authentication mechanisms, such as Message Digest 5 (MD5), are also available in some RIP v2 environments. However, Windows Server 2003 Routing and Remote Access supports only simple password authentication for RIP v2.

If you use RIP v2 simple password authentication, you must configure all RIP v2 interfaces on the same network with the same case-sensitive password. A RIP v2 router discards RIP announcements received from any RIP v2 interface whose password does not match the password configured on the interface of this RIP v2 router. You can use the same password for all of the networks on your IP internetwork, or you can vary the password for each network.

Note

  • Simple password authentication is a form of router identification. It does not provide security for RIP messages. Because the password is sent in plaintext, any user with a protocol analyzer (also known as a network sniffer), such as the Network Monitor tool, can capture the RIP v2 announcements and view the authentication password.
Support for RIP v1 and RIP v2 compatibility

RIP v1 was designed to be compatible with future versions of RIP. If a RIP v1 router receives a message and if the RIP version indicated in the RIP header is not 1, the RIP v1 router does not discard the RIP announcement but instead processes only the RIP v1 defined fields.

In addition, RIP v2 routers send a RIP v1 response to a RIP v1 request, unless they are configured to send only RIP v2 announcements.

RIP v2 Message Format

RIP v1 routers can process RIP v2 announcements in a mixed environment that contains both types of routers, because RIP v2 does not modify the structure of the RIP message format. Instead, RIP v2 makes use of fields that were defined in RIP v1 as Must be Zero.

The Command, Family Identifier, IP Address, and Metric fields in RIP v2 are used as they are for RIP v1. For RIP v2, the Version field is set to 2 to indicate that the message is a RIP v2 message. The following figure illustrates the RIP v2 message format.

Message Format for RIP v2

Message Format for RIPA v2

RIP v2 uses three of the four fields that were named Must Be Zero in RIP v1. The following table describes the new fields for RIP v2.

Additional Message Fields Defined in RIP v2

Field Description

Route Tag

A 2-byte field used to distinguish routes announced by RIP routers from non-RIP routes. The Route Tag field is defined by RFC 1723.

Routers that can support multiple routing protocols typically allow the Route Tag to be configured to indicate routes imported from differing sources. For example, an administrator typically sets the Route Tag for routes imported from Exterior Gateway Protocol (EGP) or OSPF to an arbitrary value to differentiate them from RIP routes.

The Windows Server 2003 Routing and Remote Access snap-in supports the configuration of the Route Tag on RIP v2 interfaces on the General tab of the InterfaceName Properties page. Routing and Remote Access does not allow you to specify a Route Tag by route, only by interface. For example, a route tag can be used on a router that has OSPF enabled on all of its interfaces except one, on which RIP is used. The route tag for routes on the RIP interface can be configured to tag all of the OSPF routes learned on all the other interfaces.

Subnet Mask

A 4-byte field that contains the subnet mask (also known as a network mask) of the network ID specified in the IP Address field.

Next Hop

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

The Next Hop field is designed to prevent the occurrence of non-optimal routing situations. The usefulness of the Next Hop field is illustrated by the following example:

  • If the Next Hop field is not used, when a router announces a host route for a host that resides on the same subnet as the router interface that is advertising the route, the next-hop IP address for the host route is the IP address of the router’s interface, not the IP address of the host. Other routers on that subnet that receive the announcement forward packets destined for the host’s IP address to the announcing router’s IP address rather than to the host. This routing issue, which can occur with RIP v1, is avoided by RIP v2 because it uses the Next Hop field.

  • If the Next Hop field is used, the router announces the host route with the host’s IP address in the Next Hop field. Other routers on that subnet that receive the announcement correctly forward packets destined for the host to the host’s IP address, rather than incorrectly forwarding the packets to the announcing router.

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

RIP v2 Simple Password Authentication Message Format

The simple password 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 for this authentication mechanism, which leaves a maximum of 24 routes available in a RIP v2 authenticated announcement (because the RIP message format allows up to 25 routes per RIP message). To indicate authentication, the Family Identifier field is set to 0xFFFF. The Authentication Type field (which is usually used as the Route Tag field) indicates the type of authentication being used. A value of 1 in the Authentication Type field indicates simple password authentication.

The 16-byte Authentication Value field, which follows the Authentication Type field, stores the left-justified, null-padded, case-sensitive, plaintext password used for simple password authentication. The following figure illustrates the RIP v2 authentication message format for plaintext passwords.

RIP v2 Message Format Using Authentication

RIPA v2 Message Format Using Authentication

RIP v1 routers disregard the first route in a RIP v2 authenticated announcement because RIP v1 does not recognize the Family Identifier (that is, 0xFFFF) for the route.

Mixed RIP v1 and RIP v2 Environments

To take advantage of all RIP v2 features, use only RIP v2 in a RIP internetwork. For internetworks that contain one or more routers that do not support RIP v2, it is possible to establish a mixed environment that contains both RIP v1 and RIP v2 routers. However, you must exercise caution if you establish a mixed environment to avoid experiencing routing problems. Follow these guidelines to avoid routing problems in a mixed environment:

  • Because RIP v1 routers cannot interpret the Subnet Mask field in the route, RIP v2 routers must not announce routes that can be misinterpreted by a RIP v1 router. Therefore, do not use VLSMs or noncontiguous subnets in a mixed environment.

  • Because RIP v1 routers will misinterpret a summarized route as a single network ID rather than as a range of network IDs, do not use summarized routes in a mixed environment.

  • For a RIP v2 router interface to make announcements in a way that allows RIP v1 routers to 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. Therefore, in a mixed environment, use only contiguous, fixed-size subnets or clear the Disable subnet summarization setting on the Advanced tab of each interface.

  • If RIP v2 routers are on the same subnet as RIP v1 routers, you must configure the interface for each RIP v2 router to broadcast its announcements on that subnet. RIP v1 routers cannot process multicasted RIP v2 announcements.

How OSPF Works

Open Shortest Path First (OSPF) for IP enables OSPF routers to dynamically exchange routing information with each other over complex IP internetworks. Routers can add or remove routes automatically as networks are added or removed from the internetwork, dynamically building and synchronizing a database of the OSPF network topology. As its name implies, OSPF is designed to calculate the shortest path to any destination within an OSPF autonomous system (AS). OSPF, the best known and most widely used link state routing protocol, is an open standard developed by the Internet Engineering Task Force (IETF) as an alternative to RIP. OSPF is defined in RFC 2328. The Windows Server 2003 Routing and Remote Access service supports OSPF for IPv4 only.

Notes

  • The OSPF routing protocol is available only on 32-bit versions of Windows Server 2003

  • The Windows Server 2003 Routing and Remote Access service does not support OSPF (or any other dynamic routing protocol) for IPv6. For information about Windows Server 2003 support for IPv6, including support for static routing in an IPv6 environment, see “IPv6 Routing” in “How IPv6 Works” in IPv6 Technical Reference.

This section describes:

  • OSPF features appropriate for large internetworks

  • How OSPF convergence works

  • How OSPF forms adjacencies to synchronize the LSDB

  • How OSPF multiple-area autonomous systems work

OSPF Features Appropriate for Large Internetworks

OSPF, an Interior Gateway Protocol (IGP) used for routing IP traffic within a single autonomous system, is commonly used on a multipath, dynamic IP internetwork that consists of more than 50 (but fewer than 100) networks.

Typically, OSPF is deployed in large private IP internetworks, including internetworks that span multiple geographical regions, nations, or continents. OSPF functions efficiently in a WAN environment by using summarized routes to reduce the size of routing tables.

You can also easily take advantage of the advanced features of OSPF in a much smaller network by accepting the default OSPF settings and the default settings for OSPF interfaces.

Both the Internetwork Operating System (IOS) used by many hardware routers and the Windows Server 2003 Routing and Remote service support OSPF.

OSPF Database, Areas, and Routers

In an OSPF routed internetwork, an autonomous system is made up of one or more areas. An OSPF area is made up of a logical collection of networks, routers, and links, and each area includes special OSPF routers that enable communication between the constituent areas. Each OSPF area uses a database to store its routing information. OSPF updates this database dynamically as network topology changes.

OSPF database

An OSPF area has a database that is shared by the routers in that area, a method to keep the database updated, and a method to calculate the routing table from the database.

All OSPF routers in an area share the same database

An OSPF router stores information about the state of each link between itself and other routers in an OSPF-specific database called a link state database (LSDB). The LSDB is a topological map of all routers in the same OSPF area. The LSDB maps either all routers within the autonomous system (if only one area exists) or it maps all routers within the local OSPF area (if multiple areas exist). If multiple areas exist, each OSPF router stores a separate LSDB for each connected area.

OSPF routers exchange advertisements to create and update the database

OSPF routers compile the shared LSDB by flooding link state advertisements (LSAs) within the autonomous system (if only one OSPF area exists) or within the local area (if multiple OSPF areas exist). Flooding means sending traffic received on one interface out all of the other interfaces on that device. An LSA is a multicast packet that an OSPF router uses to advertise information about network neighbors and path costs. Each OSPF router in an area must receive a valid LSA from each other router.

OSPF routers calculate the routing table from the database

After an OSPF router compiles its LSDB from the LSAs that it receives from other routers, each router, using itself as the root, calculates a tree of shortest paths to each other router and subnet, and then creates IP routing table entries from this tree, storing a single entry for each subnet.

For detailed information about how OSPF manages its database, advertisements, and routing table, see “How OSPF Convergence Works” later in this section.

OSPF areas

Each OSPF area is identified by an area identification number called an area ID*.* The 32-bit OSPF area ID is expressed in dotted decimal notation. The area ID is an administrative identifier that is unrelated to an IP address or an IP network ID. However, if all networks within one OSPF area correspond to a single subnetted network ID, for administrative convenience you can set the area ID to match the network ID. For example, if an area contains all of the subnets of the IP network 10.1.0.0/16, you can set the area ID to 10.1.0.0.

The following table describes the possible types of OSPF area. The only required area type is a backbone area.

Types of OSPF Areas

Area Type Description

Standard

An OSPF area that propagates intra-area, inter-area, and external routes:

  • Intra-area routes are communicated within the local OSPF area.

  • Inter-area routes are communicated between OSPF areas (connected by a backbone area) that are located in the same autonomous system. OSPF uses summarized routes for inter-area routes.

  • External routes are communicated from an external route source into the OSPF autonomous system by an Autonomous System Border Router (ASBR). An external resource can be either from another OSPF autonomous system or from a non-OSPF source, such as another routing protocol.

The LSDB in an area stores OSPF router LSAs for intra-area routes, summary LSAs for inter-area routes, and external route LSAs for external routes.

Backbone

A standard OSPF area that is either the sole area in the OSPF autonomous system or the central area to which all other OSPF areas of an OSPF autonomous system connect. The OSPF backbone area requires the reserved area ID of 0.0.0.0; an alternative notation, the area ID of 0, is sometimes used to denote the backbone area.

When more than one area exists in an OSPF autonomous system, the OSPF backbone area (typically, a single high-bandwidth network) distributes routing information among all attached areas. Traffic between areas is first routed to the backbone, then routed to the destination area, and then finally routed to the destination host within the destination area.

Transit

A non-backbone standard OSPF area that connects another OSPF area (that does not have a physical link to the backbone) to the backbone by using a logical point-to-point connection called a virtual link.

Stub

An OSPF area that, like a standard OSPF area, accepts and advertises inter-area and intra-area routes but, unlike a standard area, does not accept or distribute external routes from external OSPF autonomous systems or from non-OSPF sources.

Internal OSPF routers in a stub area use the default route (destination 0.0.0.0, network mask 0.0.0.0) to reach all destinations outside the autonomous system. A stub area, typically, has only one router (an Area Border Router, or ABR) that connects the stub area to the rest of the autonomous system.

Totally Stub

A type of stub area that propagates only intra-area routes and the default route within the area; it does not accept or advertise either inter-area routes or external routes.

Internal OSPF routers in a totally stub area use the default route to send traffic destined outside the area to the local ABR, which forwards the traffic towards its destination in another OSPF area or outside the autonomous system.

On a Windows Server 2003 Routing and Remote Access OSPF router, OSPF areas are viewable in the Routing and Remote Access snap-in by right-clicking OSPF under IP Routing in the console tree, and then clicking Show Areas.

For more information about OSPF areas, see “How OSPF Multiple-Area Autonomous Systems Work” later in this section.

OSPF Routers

When an OSPF autonomous system contains two or more areas and connects to other destinations outside the OSPF autonomous system, the routers it contains can operate in one of four roles. The following table describes these OSPF routers.

Types of OSPF Routers

Router Type Description

Internal router

An OSPF router that has two or more interfaces that all connect within the OSPF area in which the router resides. All internal routers within an area share the same LSDB.

Area border router (ABR)

An OSPF router that has two or more interfaces that connect directly to networks in two or more OSPF areas. One interface must connect to the backbone area; thus, an ABR is always a backbone router but the converse is not always true — a backbone router is not necessarily an ABR. An ABR stores multiple LSDBs, one for each attached area, including one for the backbone area.

An ABR routes traffic between the backbone area and all other areas connected to the backbone by sending routes for its attached area to the backbone, which, in turn, distributes this information to other OSPF areas not attached to this router within the autonomous system.

Backbone router

An OSPF router that has at least one interface connected to the backbone area and that routes traffic within the backbone area. All internal routers of the backbone area and all ABRs are backbone routers.

Autonomous system boundary router (ASBR)

An OSPF router that imports routing information from external sources and advertises external destinations throughout its own autonomous system. An ASBR in an OSPF autonomous system can connect to and exchange routes with:

  • An ASBR in another OSPF autonomous system, by connecting the two autonomous systems.

  • Non-OSPF sources, by connecting its own autonomous system to the external source. For example, an ASBR can connect to an external network running a different interior gateway protocol, such as RIP for IP.

Only a standard OSPF area can contain an ASBR. Each router in an OSPF autonomous system can reach the ASBRs within its autonomous system.

OSPF Unitless Metrics

In contrast to the RIP hop count cost metric, OSPF uses a unitless metric to indicate the preference for one link over another. Factors in the metric include the following:

  • Delay. The time that a packet requires to reach the destination network. Delay indicates the speed (LAN links have a low delay; WAN links have a high delay) or congestion level of the path.

  • Throughput (link speed). The amount of data that can be sent along the path per second. Throughput does not necessarily indicate the bit rate of the link because, for example, a very busy Ethernet link might have a lower throughput than an unused 64-kilobits per second (Kbps) WAN link.

  • Reliability. The path constancy. Some types of links are more likely to fail than others. For example, leased line WAN links are more reliable than dial-up lines.

The cost value is advertised as the link cost for this interface in the LSA of the router. The lower the cost assigned to an interface, the more often the OSFP router uses the interface to forward packets. Therefore, typically, you assign lower costs to the interfaces of preferred paths for IP traffic. The accumulated cost for network segments in an OSPF internetwork can be as great as 65,535, which enables OSPF to accommodate enterprise-size networks.

OSPF Route Advertising

OSPF route advertising includes the characteristics described in the following sections.

Advertises subnet mask

OSPF advertises the subnet mask of a route with its network ID. As a result, OSPF supports VLSM and CIDR and, therefore, supports subnetting, noncontiguous subnets, and route summarization.

Advertises external routes

In OSPF, an external route is a route that is learned from a non-OSPF source, such as a static route manually configured by a network administrator or a RIP route learned from a network that uses the RIP routing protocol. Routes outside an OSPF autonomous system are advertised within the autonomous system, which enables OSPF routers to calculate the least-cost route to external networks. OSPF can use the default route (destination 0.0.0.0, network mask 0.0.0.0) to summarize routes imported from external sources.

For more information about external routes, see “Propagating External Source Routes to the OSPF Autonomous System” later in this section.

Advertises summarized routes

In an OSPF autonomous system with multiple areas, OSPF can be configured to send summary route advertisements in the format {Destination, Network Mask} to advertise networks located inside one area to other OSPF areas. The destination and network mask specify a range of addresses to be summarized. Summarizing — consolidating multiple routes into a single advertisement — is configured on an ABR at the boundary between an OSPF area and the backbone area. After receiving the summarized route from one area, the ABR forwards the summarized route through the backbone area and then through another ABR into another area.

Because OSPF can include multiple areas and can use summarized routes (which reduces the size of OSPF routing tables), OSPF can scale to large and very large internetworks. In contrast, RIP internetworks cannot be subdivided and RIP v1 performs no route summarization beyond summarizing for all subnets of a class-based network ID.

For more information about using summarized routes for inter-area routing, see “Using Route Summarization Between OSPF Areas” later in this section.

Advertises based on network type

The address type, multicast or unicast, used for an OSPF announcement is determined by the type of network — broadcast, point-to-point, or nonbroadcast multiple access (NBMA) — to which the OSPF interface is connected.

OSPF multicasts announcements on broadcast networks (default)

A broadcast network is a multiple access network, that is, more than two routers are connected to the network, which can broadcast a single frame to all routers attached to that network. Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) are broadcast networks.

On broadcast networks, OSPF routers use the following two reserved multicast IP addresses to send OSPF messages:

  • 224.0.0.5 - AllSPFRouters. Used to send OSPF messages to all OSPF routers on the same subnet. OSPF routers use the AllSPFRouters multicast address to send OSPF Hello messages to each other in order to discover each other. In addition, the OSPF designated router (DR) and backup designated router (BDR) use this address to send Link State Update and Link State Acknowledgment messages. (For more information about OSPF designated routers, see “How OSPF Forms Adjacencies to Synchronize the LSDB” later in this section.)

  • 224.0.0.6 - AllDRouters. Used to send OSPF messages to all OSPF designated routers and BDRs on the same subnet. All OSPF routers, except designated routers themselves, use this multicast address to send Link State Update and Link State Acknowledgment messages to designated routers and BDRs.

The multicast protocol, Internet Group Management Protocol (IGMP), is not needed because these addresses are in the link-local range. The link-local range refers to addresses in the range of 224.0.0.0 to 224.0.0.255 (224.0.0.0/24). This multicast range is reserved for local subnet multicast traffic. IP routers do not forward packets sent to addresses in this range.

OSPF multicasts announcements on point-to-point networks

A point-to-point network is a network that connects only two routers. T1/E1, T3/E3, ISDN, and other types of dial-up WAN links as well as leased-line WAN links are point-to-point networks.

On point-to-point networks, OSPF routers use the AllSPFRouters multicast IP address (224.0.0.5) to send all OSPF messages.

OSPF unicasts announcements to specific OSPF neighbors on NBMA networks

A nonbroadcast multiple access (NBMA) network is a network that can connect more than two routers but cannot broadcast a single frame to all routers attached to that network. X.25, Frame Relay, and Asynchronous Transfer Mode (ATM) are NBMA networks. In addition to being unable to broadcast, NBMA networks also cannot multicast.

How you configure OSPF for an NBMA network depends on how Frame Relay virtual circuits appear as network interfaces on an OSPF server running Routing and Remote Access. Frame Relay virtual circuits appear in the Routing and Remote Access snap-in either as a single adapter or as multiple adapters. The following descriptions assume that you have a Frame Relay network, but other NBMA technologies, such as X.25 and ATM, function in a similar manner.

  • Single-adapter model unicasts OSPF announcements. All virtual circuits on an OSPF router function as a single adapter. In the single-adapter model, also known as the NBMA model, the network of the Frame Relay service provider (also called the Frame Relay cloud) is treated as an IP network, and the endpoints on the cloud are assigned IP addresses from a designated IP network ID. To ensure that OSPF traffic is received by all of the appropriate endpoints on the cloud, you must configure the Frame Relay interface to unicast its OSPF announcements to each appropriate endpoint. On a Routing and Remote Access OSPF router, you do this by designating the interface as an NBMA network and by configuring OSPF to unicast announcements to the specified neighbor routers. (Up to this point, the single-adapter model functions the same with both RIP and OSPF.)

    In a hub-and-spoke Frame Relay topology in an OSPF-based IP internetwork, the Frame Relay interface for the hub router must have a router priority set to 1 or greater and the Frame Relay interfaces for the spoke routers must have a router priority set to 0. Otherwise, the hub router, which is the only router that can communicate with all of the spoke routers, cannot become the designated router and adjacencies cannot form across the Frame Relay network. For more information about the router priority setting, see “Using Designated Routers” later in this section.

  • Multiple-adapter model multicasts OSPF announcements. Each virtual circuit functions as a separate adapter. In the multiple-adapter model, each Frame Relay virtual circuit functions as a point-to-point link with its own network ID, and the endpoints on the cloud are assigned IP addresses from a designated IP network ID. Because each virtual circuit is its own point-to-point connection, you can configure the interface as the point-to-point network type rather than as the NBMA network type.

On an OSPF router running Windows Server 2003 Routing and Remote Access, the network type (broadcast, point-to-point, or NBMA) is configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\OSPF node, and then using the General tab of the InterfaceNameProperties page. In addition, for the NBMA network type, neighbor routers on the NBMA network can be specified on the NBMA Neighbors tab of the same InterfaceNameProperties page.

Note

  • The use of OSPF to provide remote access over nonpermanent, non-persistent, dial-up WAN links, such as analog phone lines or dial-up ISDN, is not recommended.

OSPF Simple Password Authentication

OSPF supports the use of simple password authentication to verify the origin of incoming OSPF announcements. Simple password authentication, which is enabled by default on Windows Server 2003 Routing and Remote Access OSPF interfaces, helps prevent an unauthorized or incorrectly configured OSPF router from corrupting OSPF messages on a subnet. By default, Windows Server 2003 Routing and Remote Access OSPF routers send the default plaintext password "12345678" in their OSPF Hello messages.

If you specify that plaintext passwords are required for an OSPF area:

  • All interfaces on the same network segment must use an identical password.

  • Interfaces in the same area that are on different networks can have different passwords.

Note

  • Simple password authentication is a form of router identification. It is not a security option. Because the password is sent in plaintext, any user with a protocol analyzer (also known as a network sniffer), such as the Network Monitor tool, can capture the OSPF messages and view the authentication password.

OSPF Convergence

Of the features listed in this section that make it possible for OSPF to support large internetworks, fast convergence time is one of the most important. OSPF can detect and propagate topology changes faster than RIP. Unlike RIP, the count-to-infinity problem does not occur on an OSPF network and OSPF-calculated routes are always loop-free.

For more information about OSPF convergence, see “How OSPF Convergence Works,” described next.

How OSPF Convergence Works

OSPF-enabled routers go through the following stages to achieve convergence of an IP internetwork:

  1. Compiling the LSDB.

  2. Calculating the Shortest Path First tree.

  3. Creating routing table entries.

The following three sections describe this process in detail. The result of this process, sometimes referred to as fast convergence, is that OSFP can quickly recalculate routing information if routers fail and can avoid the occurrence of routing loops.

Compiling the LSDB

OSPF compiles the LSDB by means of an ongoing exchange of LSAs between neighboring routers, leading to a state in which each router is synchronized with its neighbors. After the autonomous system converges (if only one OSPF area exists) or after the local area converges (if multiple OSPF areas exist), each router has the appropriate entries in its LSDB.

To create the LSDB, each OSPF router must receive a valid LSA from each router in the autonomous system (if only one OSPF area exists) or from each router in the local area (if multiple OSPF areas exist). The process through which OSPF routers send and receive the LSAs is called flooding (sending traffic received on one interface out all other interfaces). Each router initially sends an LSA that 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 specific router is flooded across the autonomous system so that each other router learns that router’s LSA. Although the flooding of LSAs might appear to cause a large amount of network traffic, OSPF is very efficient in the propagation of LSA information.

The following figure shows a simple, single-area OSPF autonomous system, the flooding of LSAs between neighboring routers, and the resulting LSDB compiled on one router. After the process completes, all routers contain an identical LSDB.

Flooding LSAs to Create the LSDB in a Single-Area Autonomous System

Art Image

On a Windows Server 2003 Routing and Remote Access OSPF router, the OSPF LSDB is viewable in the Routing and Remote Access snap-in by right-clicking the OSPF routing protocol in the console tree, and then clicking Show Link State Database.

To keep track of LSAs in the LSDB, each router is assigned a router ID, which identifies the router in the autonomous system. The router ID is a 32-bit dotted decimal number that is unique to the autonomous system. The router ID is not the IP address of one of the router’s interfaces, and it is not used as a destination IP address for sending information to the router. Typically, the largest or smallest IP address assigned to the router is the router ID. Because IP addresses are unique, this convention ensures that OSPF router IDs are also unique.

Calculating the Shortest Path First Tree

After the LSDB is compiled, each OSPF router uses the Dijkstra algorithm to perform a least-cost path calculation on the information in the database. The Dijkstra algorithm, from a branch of mathematics called graph theory, is an efficient method of calculating a set of least-cost paths relative to a source node. The router, using itself as the root, performs this calculation to create a tree of shortest paths to each other router and subnet in the OSPF autonomous system (if only one OSPF area exists) or to each other router in the local area (if multiple OSPF areas exist). This tree, which contains a single least-cost path to each router and subnet, is known as the Shortest Path First (SPF) tree. A least-cost path is the path with the lowest accumulated cost. 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.

OSPF uses the Dijkstra algorithm to calculate the SPF tree. The result of the Dijkstra algorithm is the set SPF{}, which is a cost-sorted list of least-cost paths that contain the path (the series of nodes and links) and its accumulated cost from the source node S.

Creating Routing Table Entries

OSPF creates entries in the IP routing table of each router from the SPF tree. If only one OSPF area exists, the routing table stores a single route for each subnet in the autonomous system. For multi-area OSPF internetworks, typically you configure route summarization at each ABR so that only summary routes that represent the destinations of each area are added as routes to the routing table. As explained earlier, the metric for the routing table entry is the OSPF-calculated cost, not a hop count (as is the case for RIP).

To calculate the IP routing table entries from the SPF tree, OSPF analyzes the set SPF{} that results from calculating the SPF tree. The analysis produces a series of OSPF routes that are added to the routing table. Each route contains:

  • An IP destination (the network ID) and its associated network mask.

  • The next-hop IP address of the appropriate neighboring router.

  • The next-hop interface over which the neighboring router is reachable.

  • The OSPF-calculated cost to the subnet.

Example of OSPF Convergence

The example described in this section illustrates how an OSPF internetwork compiles the LSDB, performs the least-cost analysis, and creates routing table entries. This example is deliberately simplified to help provide an understanding of the basic principles of OSPF convergence.

Example: Compiling the LSDB in a single-area autonomous system

At each router interface, the network administrator assigns a unitless cost metric (reflecting bandwidth, delay, or reliability), indicating a preference for using that interface, as shown in the following figure.

Cost Assigned for Each OSPF Router Interface in an OSPF Area

Cost for Each OSPF Router Interface in OSPF Area

After the LSA flooding process completes convergence, each router in the single-area autonomous system has received an LSA from all other routers, and each router in the system now contains an identical LSDB. The following table illustrates the common LSDB now shared by all routers in the area.

After Convergence Occurs, All Routers Contain the Same LSDB Information

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
Example: Calculating the SPF Tree

In the next step, OSPF applies the Dijkstra algorithm to the example single-area OSPF autonomous system. The following figure illustrates the resulting SPF tree calculation, as performed by router R4. With R4 acting 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 subnet.

SPF Tree Calculation Performed by Router R4

SPF Tree Calculation Performed by Router R4

Example: Creating Routing Table Entries

Next, OSPF creates the routing table from the results of the SPF tree calculation, as illustrated in the following figure.

OSPF Derives Routing Table Entries from the SPF Tree Calculation

OSPF gets table entries from SPF Tree calculations

The exchange of LSAs by OSPF routers on a large IP internetwork might require a brief, but large, burst of bandwidth. After the exchange of advertisements and before convergence, a large amount of memory is required to process the LSDB. In addition, running the Dijkstra algorithm requires high CPU use. Therefore, networks with links that frequently appear and disappear can cause performance issues on routers because of the bandwidth needed to generate LSAs, to store the database, and to run the Dijkstra algorithm.

Instead of using one OSPF area for the entire autonomous system, you can minimize OSPF overhead and performance issues by dividing the OSPF autonomous system into multiple areas. For more information about OSPF areas, see “How OSPF Multiple-Area Autonomous Systems Work” later in this section.

How OSPF Forms Adjacencies to Synchronize the LSDB

Link state routing algorithms rely on the synchronization of LSDB information among routers in an autonomous system. However, if every router exchanges routing information with every other router, the exchange of redundant information can occur, which increases network traffic and enlarges the size of the LSDB. To avoid this unnecessary overhead, each router is required to synchronize only with specific neighboring routers known as adjacent routers. When the LSDBs of two neighboring OSPF routers are synchronized, the routers are said to be adjacent. OSPF enables the exchange of routing information only between those neighboring OSPF routers that share an adjacency relationship. Not every pair of neighboring routers becomes adjacent.

OSPF requires that adjacencies be established in order to compile the correct entries in the LSDB, and only then can OSPF calculate the SPF tree and create entries in the routing table. Failure to establish adjacencies is one of the main problems that can prevent convergence in an OSPF internetwork.

Establishing an OSPF Adjacency

When an OSPF router initializes, it multicasts periodic OSPF Hello messages onto all directly connected subnets in order to discover neighboring OSPF routers and to communicate its own existence to them. The OSPF Hello message contains configuration information, such as the router’s router ID and the list of neighboring routers from which the router has received a Hello message. Initially, however, the neighbor list in the OSPF Hello message does not contain any neighbors.

The initializing OSPF router, while multicasting its own OSPF Hello messages, also listens for Hello messages sent from neighboring routers. From incoming Hello messages, the initializing router determines the specific router or routers with which to form an adjacency. On a multiple-access network (broadcast or NBMA), adjacencies are formed with a designated router and a backup designated router (BDR) that are identified as such in the incoming Hello messages. The designated router forms adjacencies with other routers on its subnet, avoiding redundant adjacencies by establishing only the minimum required number of adjacencies. For more information about how designated routers avoid establishing redundant adjacencies, see “Using Designated Routers” later in this section.

To form an adjacency:

  1. Two routers describe the contents of their LSDBs in an exchange of database description packets known as the database exchange process. It is during the database exchange process that the two neighboring routers form a master and subordinate relationship if they become adjacent router’s. The content of each router’s LSDB is acknowledged by its neighboring router.

  2. Each router compares its LSAs with the LSAs of its neighbor and notes which LSAs it needs to request from the neighbor in order to synchronize the LSDB. The missing or more recent LSAs are then requested through Link State Request messages. Link State Update messages are sent in response to Link State Request messages and their receipt is acknowledged. When all Link State Request messages of both routers have received a response, the LSDBs of the router and its neighboring router are fully synchronized and an adjacency is formed.

  3. After the adjacency has formed, each adjacent router sends a periodic Hello message to inform the adjacent router that the router is still active on the subnet. OSPF uses the lack of Hello messages from a neighbor to detect a downed router.

  4. If an event, such as a downed link or router or the addition of a new subnet that changes the LSDB of one router occurs, the databases of adjacent routers are no longer synchronized. The changed router sends Link State Update messages to its adjacent neighbors, who acknowledge the messages. After this exchange, the LSDBs of the adjacent routers are again synchronized.

OSPF neighbor states as an adjacency forms

The neighboring OSPF routers go through a series of states (as defined in RFC 2328) during the establishment of an adjacency. The following table lists these states in the adjacency relationship in progressive order.

States of OSPF Neighbors as an Adjacency Forms

Neighbor State Description

Down

(initial state)

Router A has received no OSPF Hello message from neighbor router B. However, on NBMA networks, router A can send a Hello message to router B even though router B is in a Down state.

Attempt

(for NBMA networks only)

Router A has received no OSPF Hello message from neighbor router B recently, despite attempts to contact router B by sending OSPF Hello messages to it.

Init

Router A has received an OSPF Hello message from neighbor router B, but the router ID of router A does not appear in the neighbor list of the Hello message sent by router B. This indicates that bidirectional communication has not yet been established between router A and router B.

2-way

Router A has received an OSPF Hello message from neighbor router B, and the router ID of router A now appears in the neighbor list of the Hello message sent by router B. The same process occurs in reverse, establishing two-way communications between the two routers.

After the 2-way state is achieved, router A determines whether to become adjacent with router B. On a broadcast network (the typical case) or on an NBMA network, an OSPF router remains in a 2-way state with all other OSPF routers except the designated router and the BDR; it will establish a Full state (that is, a fully adjacent state) at a later stage only with the designated router and the BDR.

ExStart

Master and subordinate roles for the database exchange process are negotiated between router A and neighbor router B in this stage. This negotiation is the first phase of the adjacency relationship. The router with the higher router ID becomes the master and starts the exchange.

Exchange

Router A and neighbor router B exchange database description packets (also known as database descriptor packets). The contents of each database description packet is compared to the information stored in each router’s LSDB to determine whether new or more current link state information is available in the database description packet sent by the other router.

Loading

Based on information in the exchanged database description packets, router A and neighbor router B send each other Link State Request messages asking for missing or more recent LSAs. Each responds by sending the requested link state information in Link State Update messages (which contain the entire LSA) to the other router.

Full

The LSDBs of router A and neighbor router B are fully synchronized, and the two routers are now said to be fully adjacent with each other. This adjacency relationship is now advertised in LSAs.

On a broadcast network (the typical case) or on an NBMA network, after completing this series of states to establish an adjacency relationship, a Full state occurs only between an OSPF router and its designated router and BDR; the 2-way state is the normal state for most OSPF routers in a broadcast network.

On a point-to-point network, after completing this series of states to establish an adjacency relationship, the Full state is the normal state for the two OSPF routers on either side of the link.

On a Windows Server 2003 Routing and Remote Access OSPF router, the neighbor state of neighboring routers is viewable in the Routing and Remote Access snap-in by right-clicking OSPF in the IP Routing container in the console tree, and then clicking Show Neighbors. The window that opens, OSPF Neighbors, displays all neighboring routers and each neighbor's current state. In a broadcast network:

  • For neighbor routers where an adjacency is established (the designated router and BDR), Full appears in the State column.

  • For neighbor routers where no adjacency is established, nor will be established because the router is neither a designated router nor a BDR, 2-way appears in the State column.

For more information about designated routers and BDRs, see “Using Designated Routers” later in this section.

OSPF adjacency configuration requirements

A common OSPF problem is that a required adjacency between two neighboring routers does not occur. To successfully establish an adjacency, the following requirements must be met:

  • The router IDs of the two neighboring routers must not match. Router IDs must be globally unique within an autonomous system. Duplicate router IDs prevent an adjacency. A router ID is different from an IP address.

  • Settings on the two neighboring routers must match in all of the following parameters:

    • Authentication type. If authentication is used, the neighboring routers must use the same authentication type.

    • Simple password authentication password. If simple password authentication is enabled, the neighboring routers must use the same case-sensitive password.

    • Hello interval. The periodic interval at which Hello messages are sent must be the same on both routers. The default is 10 seconds.

    • Dead interval. The amount of time after which an adjacent router is considered down if the neighboring router does not receive a Hello message must be the same on both routers. In an Internet-Draft, titled “OSPF Benchmarking Terminology and Concepts,” IETF recommends that the dead interval value be four times the Hello interval. The default is 40 seconds.

    • Area ID. The area ID, which is configured on the interface of each router, must be the same on both routers. This is a 32-bit dotted decimal number that identifies the area of the autonomous system to which the router is attached. An OSPF area ID is different from an IP address.

    • Location in an OSPF stub area. The two neighbor routers must agree whether or not they are in a stub area.

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 existing OSPF routers on the internetwork through the process of flooding. After each existing router receives the new LSA, it performs the Dijkstra algorithm, recalculates the SPF tree, and creates new routing table entries. After all routing tables on all routers are updated, the internetwork has reconverged. For multi-area OSPF internetworks on which route summarization is used, the set of routes that summarize the networks of the new router must be configured on each ABR of the area in which the new router exists. This ensures that the networks attached to the new router are propagated across the entire OSPF autonomous system.

The following figure illustrates the convergence process for a new router, R1, and the new adjacency propagation process in an example single-area OSPF internetwork. In this example, the link between R1 and R2 is a dedicated WAN link, which is one type of point-to-point link.

Adjacency Propagation of a New Router

Art Image

The preceding figure shows the convergence process for the new OSPF router, R1. This process works as follows:

  1. After router R1 is turned on, it begins sending periodic Hello messages across the point-to-point WAN link to router R2. Router R2 also sends periodic Hello messages across the link to R1. R1 and R2 form an adjacency.

  2. R1 and R2 exchange database description packets. R1's packet contains information only about itself. R2’s packet contains the latest LSAs for all routers on the internetwork (except R1).

  3. R1 sends a Link State Request message to R2, requesting the advertisements of all routers on the internetwork. R2 sends the requested advertisements to R1 as Link State Update messages.

  4. R2 sends a Link State Request message to R1, requesting its advertisements. R1 sends its advertisements to R2 as a Link State Update message. R1 and R2 now have synchronized their respective LSDBs. When R1 and R2 receive the advertisements, they calculate their respective SPF trees and routing tables.

  5. When R2 is synchronized with R1, R2 sends a Link State Update message to all other OSPF routers to which it is adjacent (routers R3 and R4). The update message contains the advertisements learned from R1. When R3 and R4 receive the advertisements from R2, they recalculate their respective SPF trees and routing tables.

  6. R3 and R4 each floods the information in a separate Link State Update message to their respective adjacent routers (routers R5 and R6). When R5 and R6 receive the flooded advertisement about R1, they recalculate their respective SPF trees and routing tables.

The example single-area OSPF internetwork has reconverged after adding R1 and its associated subnet.

Using Designated Routers

On a point-to-point link, such as a dedicated WAN link, the OSPF adjacency relationship must be established between the two routers on either side of the link. However, on multiple access networks — broadcast or NBMA networks that contain multiple routers — the adjacencies must be controlled. On a broadcast network with n routers, a total of n (n–1)/2 adjacencies are formed if no control mechanism is present. For example, a broadcast network with six OSPF routers where each router establishes an adjacency with each other router would form a total of 15 adjacency relationships. In addition, unneeded flooding traffic would occur as each router attempts to synchronize with all of its adjacent routers.

Election of designated routers

To solve this scaling problem, every multiple access network (both broadcast and NBMA) elects a designated router, which forms adjacencies with all other routers on the subnet. On a multiple access network, the designated router establishes only the needed number of adjacencies (eliminating redundant adjacencies), which in turn reduces both network traffic and the size of the LSDB. On a broadcast network with n routers, a total of (n -1) adjacencies must be formed; any additional adjacencies are redundant. For example, a broadcast network with six OSPF routers will form a total of five adjacency relationships. Because the designated router is adjacent to all other routers, it acts as a hub for distributing link state information and for synchronizing LSDBs.

The designated router is elected through the exchange of OSPF Hello messages. Each Hello message specifies the current designated router (if elected), and the router ID and router priority of the sending router. The router priority is an interface-specific OSPF configuration parameter that is used to elect the designated router — the router with the highest router priority is elected. The default router priority is set to 1. Setting a router priority of 0 prevents a router from becoming a designated router. If multiple routers have the same highest router priority, the router with the highest router ID is elected designated router. The recommended practice is to assign router priorities to ensure that the least busy routers are the designated router and BDR.

On a Windows Server 2003 Routing and Remote Access OSPF router, the router priority setting is configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\OSPF node, and then specifying the desired priority for the Router priority option on the General tab of the InterfaceNameProperties page.

If a designated router is already elected for a subnet, a new router on the subnet does not become the designated router even if it has a higher router priority than the current designated router.

Note

  • At least one router on the multiple access network (broadcast or NBMA) must be configured with a router priority of 1 or greater. If all routers on a multiple access network are configured with a router priority of 0, no router becomes the designated router and no adjacencies are established. Without adjacencies, the LSDB cannot be synchronized and no transit traffic (traffic across that subnet) can be forwarded.
Designated routers on broadcast networks

The following figure illustrates why a broadcast network requires a designated router. Without a designated router, six separate adjacencies (illustrated in the top half of the figure) are formed on a broadcast network that contains four routers. The redundant adjacencies consume local and network resources in order to maintain the adjacencies and to propagate changes to the LSDB.

When the same network uses a designated router, only three adjacencies (illustrated in the bottom half of the figure) are needed to synchronize the LSDB.

Designated Router Eliminates Redundant Adjacencies on a Broadcast Network

Art Image

Designated routers on NBMA networks

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

The following figure illustrates a designated router on a Frame Relay network that uses a hub-and-spoke configuration.

Designated Routers on a Frame Relay Network

Designated Routers on a Frame Relay Network

Backup designated routers

The designated router forms adjacencies with other routers on its subnet and acts as a central distribution point for topological changes on a multiple access network. If the designated router becomes unavailable, adjacencies must be reestablished with a new designated router. Until the adjacencies re-form and the internetwork reconverges, a temporary loss of connectivity for transit traffic can result.

To prevent connectivity loss due to the loss of a designated router, a backup — the BDR — is also elected for each multiple access network. Like the designated router, the BDR is adjacent to all routers on the network. When the designated router fails, the backup immediately becomes the designated router by sending LSAs that announce its new role to all adjacent routers. For a brief time only, transit traffic might be impaired while the BDR takes over the role of the designated router.

Like the designated router, the BDR is elected by the exchange of Hello messages. Each Hello message contains a field for the BDR of the subnet. If a backup is not specified, the router with the highest router priority that is not already the designated router becomes the BDR. If multiple routers have the highest router priority, the router with the highest router ID is elected the BDR.

If a BDR is already elected for a subnet, a new router on the subnet does not become the BDR even if it has a higher router priority than the current BDR. After the initial election, the designated router and the BDR retain their status, even if a higher priority router joins the subnet. Only after both the designated router and the BDR fail does the current highest priority router become the new designated router, and the current router with the second highest router priority becomes the new BDR.

Interface states for adjacent routers

Each OSPF interface can be in one of several states after routers form an adjacency. The following table lists these interface states.

Interface States for Adjacent Routers

Interface State Description

Down

The initial interface state. No Hello messages have been sent or received.

Loopback

The interface to the network is looped back (internally configured so that outgoing packets are routed back to the source computer) through hardware or software.

Waiting

The interface is sending and receiving Hello messages to determine the designated router and the BDR for the subnet.

Point-to-point

The interface is adjacent to its neighbor on a point-to-point network or through a virtual link and is not the designated router or the BDR.

Other

The interface is on a multiple access network (broadcast or NBMA) and is not the designated router or the BDR.

Designated router

The interface is the designated router for the attached subnet.

Backup designated router

The interface is the BDR for the attached subnet.

On a Windows Server 2003 Routing and Remote Access OSPF router, the interface state for an OSPF interface is viewable in the Routing and Remote Access snap-in by clicking the IP Routing\OSPF node. In the details pane, which displays the OSPF interfaces, the State column indicates the interface’s current state. By viewing the interface state for each OSPF interface on a specific subnet, you can determine the designated router and the BDR for the subnet.

How OSPF Multiple-Area Autonomous Systems Work

In an OSPF autonomous system that includes a large set of contiguous networks in a single OSPF area, each OSPF router must maintain in its database the LSAs of every other router in that area. Therefore, each router in a large single-area OSPF autonomous system has a large LSDB. The SPF calculation for a large LSDB requires a substantial amount of processing. In addition, the resulting routing table is large because it contains a route for each subnet in the autonomous system. A large OSPF autonomous system is typically configured to contain more than one OSPF area because each area then has its own smaller LSDB. Using multiple areas in an OSPF autonomous system makes processing throughout the autonomous system more efficient.

OSPF is designed to support dividing the autonomous system into multiple OSPF areas in order to decrease the size of the LSDB and to reduce the processing overhead for calculating the SPF tree and the routing table. Dividing a large IP internetwork into several OSPF areas, each made up of groups of contiguous subnets, helps keep the size of the LSDB to a minimum. The size of the LSDB is more manageable and processing is faster because LSAs for networks and routers inside one area are flooded within that area but are not flooded to routers outside the area. Each area becomes its own link state domain with its own LSDB.

For a description of the possible types of OSPF areas and the types of OSPF routers needed inside and between OSPF areas, see “OSPF Database, Areas, and Routers” earlier in this section.

Routing Between OSPF Areas

Routing between OSPF areas in an autonomous system takes the following course:

  1. A host in one area sends a packet destined for a host in another area to an internal router within its area. The sending host has no knowledge of either its own area or the area of the destination.

  2. The internal router forwards the packet along the least-cost path to the nearest ABR, which (by definition) has an interface that connects to the backbone area. The ABR is also a backbone router.

  3. The ABR forwards the packet along the least-cost path to the nearest ABR that is connected to the area containing the IP address of the destination host.

  4. The ABR connected to the area containing the destination host forwards the packet along the least-cost path, including through intermediate internal routers, if any, to the destination host.

The following figure shows the route of a packet as it is forwarded across R1, an internal router in area 0.0.0.1, to ABR R2, across the backbone area (area 0.0.0.0) to router R3, and then to the destination host in area 0.0.0.2.

Inter-Area Routing in OSPF

Art Image

OSPF routers do not make routing decisions based on area IDs. All routing decisions are based on entries in the IP routing table. For example, in the inter-area routing shown in this figure, the backbone routers do not explicitly forward the packet to area 0.0.0.2. Rather, the routers forward the packet along the least-cost path to the router that is the best match for the destination IP address in the packet.

Using Route Summarization Between OSPF Areas

OSPF routers within an OSPF area perform routing within that area by using the least-cost path to the destination subnet. Each router in that area has a route to each subnet within the area. When multiple OSPF areas exist, OSPF can be configured to manage routing between areas by advertising networks located inside one area to other areas by using summary route advertisements in the format {Destination, Network Mask}. These destination/mask pairs, known as inter-area routes, summarize a range of addresses within this OSPF area to other areas in the same autonomous system. Using route summarization for inter-area routes reduces the number of entries in the routing table of OSPF routers within each area.

Using multiple OSPF areas in combination with route summarization makes very large OSPF internetworks feasible. When designing areas for an OSPF autonomous system, assign network IDs that can be expressed as a small number of summary routes. For example, assign network IDs for the private IP address space 10.17.0.0/16 and 10.29.0.0/16 to the subnets of an OSPF area so that all of the locations within the area can be summarized with two routes. If an area can be summarized with a single route, you can set the area ID of that area to the IP network ID that summarizes the entire area. If an area has multiple ABRs, ensure that they all are configured to summarize the same routes.

Configured ABRs on the OSPF backbone advertise summarized routes for all areas to which they are connected to all other routers on the backbone. Therefore, the routing table on each router in an OSPF area contains both the individual routes available within the local area and the routes corresponding to the summary advertisements received from configured ABRs connected to other areas in the autonomous system.

In the following figure, router R1 (the ABR on the border of area 0.0.0.1 and area 0.0.0.0) uses a summary advertisement to announce all routes (the list of address ranges) inside area 0.0.0.1 to all other backbone routers (including R2 in 0.0.0.2 and R3 in 0.0.0.3). In turn, R1 receives summary advertisements from R2 about area 0.0.0.2 and from R3 about area 0.0.0.3. In addition, R1 is configured with summary advertisement information for the backbone area, area 0.0.0.0. By flooding, R1 propagates incoming summary routing information to all routers within area 0.0.0.1. Each router within area 0.0.0.1 incorporates summary routing information from areas 0.0.0.0, 0.0.0.2, and 0.0.0.3 into its routing table.

Summary Routes Reduce Routing Table Size

Art Image

Using route summarization hides the topology — the networks and their path costs — of one area from the rest of the autonomous system. The network topology for each area is discoverable only by routers within that area. Conversely, routers within each area cannot discover detailed topological information about other areas.

Hiding the topology of an OSPF area from other areas by using route summarization protects the rest of the autonomous system from revising its routing tables when events cause a network in another area to alternately fail and reconnect. Whenever a subnet reconnects, OSPF propagates the event as a Link State Update message and floods the update through adjacencies to routers within the area. This condition, known as route flapping, causes routing table instability because numerous routes are withdrawn and re-advertised in rapid succession. However, because all subnets within the area are advertised outside the area by using summary routes, OSPF does not flood the Link State Update outside the area and route flapping is avoided.

OSPF areas in an IP internetwork are connected to a backbone area that links the areas in the autonomous system together. Typically, an ABR that connects an OSPF area to the backbone area has a physical connection to the backbone area. However, when it is not possible or practical to use a physical connection to the backbone, you can configure a virtual link between an OSPF area and the backbone. A virtual linkis a logical point-to-point connection between an ABR of an OSPF area that is not physically connected to the backbone area and an ABR that is physically connected to the backbone.

You can configure a virtual link between any two routers that have an interface to a single common non-backbone area, known as the transit area. The transit area must have an ABR that is connected to the backbone. You cannot configure virtual links across multiple transit areas. OSPF forms a virtual adjacency across the virtual link to enable the exchange of routing information between the two routers connected by the virtual link. Such routers are known as virtual link neighbors.

In the following figure, area 0.0.0.3 does not have a router physically connected to the backbone (area 0.0.0.0). Therefore, a virtual link between routers R2 and R3 is configured across the transit area (area 0.0.0.2). R2 and R3 are virtual link neighbors.

OSPF Virtual Link

OSPF Virtual Link

A virtual link requires values for the following settings on both virtual link neighbors:

  • The area ID of the transit area for the virtual link.

  • The OSPF router ID of the virtual link neighbor.

  • The transit delay interval, which specifies the estimated number of seconds that it takes to transmit OSPF packets to the virtual link neighbor router.

  • The retransmit interval, which specifies how long the OSPF router waits before retransmitting Link State messages. This number should be significantly larger than the expected round-trip delay between the two routers at either end of the transit area. Because this can be difficult to estimate for a virtual link, it is better to make this number too large rather than too small.

  • Adjacency settings, including the Hello interval, dead interval, and plaintext password. Just as in physical adjacencies, the adjacency settings of the two virtual link neighbors must match before OSPF can successfully establish an adjacency.

On a Windows Server 2003 Routing and Remote Access OSPF router, a virtual link is configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\OSPF node, and then using the Virtual Interfaces tab on the OSPF Properties page. Existing virtual links are viewable by right-clicking OSPF in the IP Routing container, and then clicking Show Virtual Interfaces. The Virtual Interfaces window displays all configured virtual interfaces and their states.

Propagating External Source Routes to the OSPF Autonomous System

An external route is defined as any route whose source is external to the OSPF autonomous system. By default, the set of OSPF routers that define an organization’s OSPF autonomous system propagate only OSPF routes that correspond to directly connected network segments within the OSPF autonomous system. OSPF can also import external routes by defining an OSPF router as an autonomous system boundary router (ASBR). External routes can come from the following sources:

  • RIP v2

  • Local routes

  • Static routes

  • Static (non-demand-dial) routes

  • Auto-static routes

  • Routes that SNMP sets on the router

OSPF uses one or more ASBRs to learn and propagate external routes throughout an OSPF autonomous system. The ASBR uses a series of external route LSAs to advertise the availability of external routes, flooding the external route LSAs throughout the autonomous system (except in stub areas). The external route LSAs become part of the SPF tree and are included in the routing table calculation. Traffic to external networks is routed within the autonomous system by using the least-cost path to the ASBR.

The following figure shows an autonomous system that uses an ASBR to manage external route traffic.

An ASBR Imports Routes from an External Source (RIP) into an OSPF Autonomous System

ASBR Imports Routes from External RPI to OSPF

ASBRs and External Route Filters

By default, an OSPF router configured to act as an ASBR imports and advertises all external routes from all external route sources. You can choose to block routes from one or more route sources, and you can filter out specific external routes. For example, on a Windows Server 2003 Routing and Remote Access OSPF router configured as an ASBR, you can set either or both of the following types of restrictions:

  • Exclude specific external route sources. You can configure the ASBR to accept or discard routes originating from one or more external sources, such as the RIP v2 routing protocol, static routes, or SNMP-generated routes. Accepting routes from all listed external route sources is the default option.

  • Exclude individual routes. You can configure the ASBR to accept or discard specific routes for all external route sources or for a particular external route source by specifying one or more {Destination, Network Mask} pairs.

A combination of these filters, configured at the ASBR, can prevent the ASBR from advertising inappropriate routes and help ensure that the OSPF autonomous system is protected from incorrect or malicious routing information.

ASBRs and Default Routes

A router configured to act an ASBR advertises, by default, all external routes, including its own default route. This default route is used by all OSPF routers in the autonomous system. A valid default route has a next-hop IP address that points to a router that can reach the external network outside the OSPF autonomous system. An invalid default route has a next-hop IP address that points to a router within the OSPF autonomous system.

If the default gateway configured on the ASBR has a next-hop IP address that points to itself (its own IP address), the default route is not valid and packets forwarded by using that default route are dropped. To avoid this problem, use either of the following solutions:

  • Do not configure an IP address for the default gateway on the TCP/IP properties of the ASBR.

  • If the ASBR must have a default gateway, create an OSPF external route filter to filter out its own default route (destination 0.0.0.0, network mask 0.0.0.0). The default gateway configured on the ASBR must point to an IP router that is external to the OSPF autonomous system. Then, all routers within the autonomous system can correctly use that external router as their default gateway.

ASBRs and Remote Access Servers

A Windows Server 2003 Routing and Remote Access OSPF router in an OSPF environment might also be configured to function as a remote access server in order to support remote or mobile users. Typically, when you create a static IP address pool for remote access connections, address ranges in the address pool can represent separate subnets (known as off-subnet address ranges).

For the router to advertise correctly the routes for off-subnet address ranges, you must:

  • Configure the router as an ASBR in the Routing and Remote Access snap-in by navigating to the IP Routing\OSPF node, and then selecting the Enable autonomous system boundary router option on the General tab of the OSPFProperties page.

  • Use the External Routing tab on the OSPF Properties page to select Route Filters, specify Accept listed routes, and then add the routes that correspond to the off-subnet address ranges of the static IP address pool used for remote access connections.

Note

  • The use of OSPF to provide remote access over nonpermanent, non-persistent, dial-up WAN links, such as analog phone lines or dial-up ISDN, is not recommended.

Using OSPF Stub Areas

OSPF provides two types of area designed to improve performance in an OSPF autonomous system: standard stub areas and an extension to stub areas known as totally stub areas. The Windows Server 2003 Routing and Remote Access service supports both. OSPF stub areas are defined in RFC 2328.

Stub areas summarize external routes

Using an OSPF stub area decreases the amount of routing information that floods into it and therefore reduces routing overhead on the stub area’s internal routers. OSPF does not flood routes external to the OSPF autonomous system into or through a stub area. To deliver packets from a stub area to any destination IP address outside of the OSPF autonomous system, OSPF uses only a single route, the default route (destination 0.0.0.0, network mask 0.0.0.0). In OSPF, any destination not reachable through an intra-area or inter-area route is reachable through the default route; thus, OSPF uses the default route to route packets from a stub area to any destination not reachable within the autonomous system.

A stub area:

  • Reduces memory load. Because a stub area does not advertise individual external networks, less memory is required on internal stub area routers than is required on internal routers in a standard non-stub OSPF area.

  • Reduces routing table size. Using the default route for routing to external networks reduces the size of the routing table.

All routers in a stub area must be configured as stub routers. Configuring a router as a stub router automatically sets the E-bit flag in the OSPF Hello message on its interface to 0. The 0 setting identifies this router as a stub router when it attempts to establish an adjacency with another router. Otherwise, by default, for an area that is not a stub area, OSPF sets the E-bit to 1, which allows the router to accept and flood external routes into the OSPF area.

Stub areas have the following constraints:

  • You cannot configure the backbone area as a stub area.

  • You cannot configure virtual links that use a stub area as a transit area.

  • You cannot place an ASBR inside a stub area.

Example Stub Area

Area 0.0.0.3 in the following figure is configured as a stub area. All traffic to external route locations must travel through its single ABR, R3. Router R3 advertises a default route for distribution inside area 0.0.0.3 instead of flooding external routes into the area.

OSPF Stub Areas

OSPF Stub Areas

A stub area can contain a single ABR (a single entry and exit point) as in the example figure, or it can contain multiple ABRs. If the stub area contains multiple ABRs, each ABR must be configured to advertise a default route instead of external routes. When configured, any of the ABRs can be used to reach external route destinations even if the path to the external destination through the closest ABR is not the optimal path.

Totally stub areas summarize external and inter-area routes

A totally stub area uses the default route for route summarization of routes that are external to the totally stub area’s OSPF autonomous system as well as for inter-area routes within its OSPF autonomous system. The following table compares stub areas and totally stub areas.

Contrasting an OSPF Stub Area with a Totally Stub Area

Stub Area Totally Stub Area

Does not advertise external routes.

Does not advertise external routes or OSPF inter-area routes.

Routing table contains:

  • Intra-area routes

  • Inter-area routes

  • A default route (to reach destinations external to its autonomous system)

Routing table contains:

  • Intra-area routes

  • A default route (to reach destinations in other OSPF areas within its autonomous system and to reach destinations external to its autonomous system)

One appropriate reason to deploy a totally stub area is to configure a branch office that does not have high traffic requirements to other branch offices. The branch office uses the default route to reach the central office and other branch offices.

On a Windows Server 2003 Routing and Remote Access OSPF router, a stub area or a totally stub area is configurable in the Routing and Remote Access snap-in by navigating to the IP Routing\OSPF node, selecting the Add option on the Areas tab of the OSPFProperties page, and then selecting Stub area on the General tab of the OSPF Area Configuration dialog box. A stub area is differentiated from a totally stub area by selecting the Import summary advertisements option for a stub area or ensuring that Import summary advertisements is not selected (which is the default) for a totally stub area.

How the DHCP Relay Agent Works

Any IP subnet that contains DHCP clients requires either a DHCP server or a DHCP relay agent to provide address leases to those DHCP clients. A computer acting as a DHCP relay agent, also known as a Bootstrap Protocol (BOOTP) relay agent, relays DHCP messages between DHCP clients on an IP subnet with no DHCP server and a DHCP server located on a different subnet.

Using one or more DHCP relay agents makes it unnecessary to install a separate DHCP server on each subnet in an IP internetwork because the DHCP relay agent enables a DHCP server to lease addresses to clients on a different subnet than the subnet on which the DHCP server is located. With DHCP relay agents, two DHCP servers (the second one is a backup) on one subnet can service an entire internetwork if the subnets with no DHCP server have an IP router configured to act as a DHCP relay agent.

The Windows Server 2003 Routing and Remote Access service provides a DHCP relay agent when the DCHP Relay Agent routing protocol component is added and configured with the IP address of one or more DHCP servers. The Routing and Remote Access DHCP relay agent is compliant with RFC 1542.

A DHCP relay agent mediates between a DHCP client and DHCP server in three steps:

  1. A client on a subnet that has no DHCP server but that does contain a DHCP relay agent broadcasts a request for a DHCP lease.

  2. The DHCP relay agent accepts the request and forwards it as a unicast message to the IP address of a DHCP server on another subnet.

  3. The DHCP server sends a response (a lease offer) to the unicast IP address of the DHCP relay agent, which then forwards the response as either a broadcast or unicast transmission to the DHCP client.

Note

  • Configuring the DHCP relay agent on a computer running any of the following will impair the proper functioning of DHCP:

  • The DHCP Server service

  • The Routing and Remote Access NAT routing protocol component with automatic addressing enabled

  • Internet Connection Sharing (ICS)

A DHCP relay agent helps direct DHCP messages between a DHCP server and a DHCP client located on different subnets and takes an active role in recording information required for DHCP configuration.

Initial DHCP Configuration

Initial DHCP configuration is initiated by a DHCP client that has never leased an IP address, has released its IP address, or has received a DHCPNack message (indicating a negative response to a DHCP request) when attempting to lease a previous IP address. As described next, the initial DHCP configuration process uses four DHCP messages: DHCPDiscover, DHCPOffer, DHCPRequest, and DHCPAck.

DHCPDiscover — DHCP client broadcasts initial request to discover a DHCP server

When a Windows DHCP client computer starts, it broadcasts a message to obtain or renew a lease from a DHCP server. The DHCP client sends a DHCPDiscover message, which contains the MAC address of the DHCP client, to the limited broadcast IP address (255.255.255.255) and the MAC-level broadcast address. If no DHCP server exists on the client’s subnet, the DHCP relay agent (if one is configured) receives the DHCPDiscover message and forwards it to a DHCP server on another subnet.

As defined 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 a DHCPDiscover message to unicast IP addresses that correspond to configured DHCP servers. Before forwarding the original DHCPDiscover message, the DHCP relay agent makes the following changes:

  1. Increments the Hop Count field in the DHCP header. The DHCP Hop Count field (which is different from the Time to Live [TTL] field in the IP header) is used to indicate how many DHCP relay agents have handled this DHCP message. When the configured maximum Hop Count is exceeded, the DHCPDiscover message is silently discarded. The default maximum hop count for the Windows Server 2003 DHCP relay agent is 4.

  2. 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 message, 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.

  3. Changes the source IP address of the DHCPDiscover message to the IP address of the interface on which the broadcasted DHCPDiscover message was received.

  4. Changes the destination IP address of the DHCPDiscover message to the unicast address of the DHCP server configured on the DHCP relay agent.

The DHCP relay agent sends the DHCPDiscover message to the DHCP server (located on another subnet) as a unicast 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 message.

DHCPOffer — DHCP server offers IP address to the DHCP client

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

  1. The relay IP address and the subnet masks of the server’s configured scopes are compared by using a logical AND operation. When the comparison finds a scope whose network ID matches the network ID of the relay IP address, the DHCP server allocates an IP address from that scope.

  2. When the DHCP server sends the lease offer back to the client, the server sends the DHCPOffer message to the source address of the DHCPDiscover message.

After the DHCP relay agent receives the relay IP address, it uses the address to determine which interface over which to send the DHCPOffer message. The DHCP relay agent then looks at the value of the Broadcast flag in the DHCPOffer message. The Broadcast flag is set by the original DHCP client to indicate, when set to 1, that the client cannot receive unicast IP traffic until the DHCP lease process for the unicast IP address is concluded. Based on the value of the Broadcast flag, the DHCP Relay Agent either readdresses and sends the DCHPOffer message to the limited broadcast IP address and MAC-level broadcast address (if the Broadcast flag is set to 1) or readdresses and sends the DHCPOffer message to the client using the offered IP address as the destination IP address and the client’s MAC address as the destination MAC address (if the Broadcast flag is set to 0). Windows Server 2003 and Windows XP DHCP clients set the Broadcast flag to 0.

DHCPRequest — Client requests to lease the IP address offered by the DHCP server

As it does with the DHCPDiscover message, the DHCP client sends the DHCPRequest message, 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 readdresses and sends it as a unicast IP packet to the configured DHCP server or servers.

DHCPAck — DHCP server acknowledges the DHCP client request and approves its lease

The DHCP server initially unicasts the DHCPAck message to the relay IP address, as it did with the DHCPOffer message. When the DHCP relay agent receives the DHCPAck message, it uses the Broadcast flag to forward it as a broadcast or unicast transmission to the DHCP client. The DHCPAck message is the signal from the DHCP server to the DHCP client that the server approves the lease that the client will now use, and the server updates its DHCP database.

When the client receives the acknowledgement, it configures its TCP/IP properties using any DHCP option information (such as default gateway and DNS server addresses) contained in the DHCPAck message and completes the initialization of TCP/IP.

Restarting a DHCP Client and Obtaining an IP Address

By default, when a Windows Server 2003, Windows XP, or Windows 2000 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 last used by exchanging DHCPRequest and DHCPAck messages.

Note

  • For Windows Server 2003, Windows XP, and Windows 2000 DHCP clients, you can override this default by configuring the DHCP server to send the Release DHCP lease on shutdown Microsoft-vendor-specific DHCP option.
DHCPRequest

When a Windows Server 2003, Windows XP, or Windows 2000 DHCP client restarts, it attempts to lease its previously allocated IP address by using a broadcasted DHCPRequest message. The DHCPRequest, which is 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 a way similar to the way that it treats a DHCPDiscover message (described earlier). Before forwarding the packet, the DHCP relay agent does the following:

  1. Increments the Hop Count field in the DHCP header.

  2. In the Relay IP Address field, records the IP address of the interface on which the DHCPRequest message was received.

  3. Changes the source IP address to the IP address of the interface on which the broadcasted DHCPDiscover message was received.

  4. Changes the destination IP address to the unicast address of the DHCP server that is recorded in the DHCPRequest, and then readdresses and sends the packet as a unicast IP packet to the DHCP server.

DHCPAck and DHCPNack

When the DHCP server receives the DHCPRequest, the server compares the network ID of the client’s allocated IP address to the network ID of the relay IP address. Based on the result of that comparison, the server does one of the following:

  • If the two network IDs are the same and if the IP address is available and thus can be reallocated to the DHCP client, the DHCP server sends a DHCPAck to the IP address of the DHCP relay agent. When the DHCP relay agent receives the DHCPAck, it readdresses and sends the message to the DHCP client.

  • If the two network IDs are the same and if the IP address is not available and thus cannot be reallocated to the DHCP client, the DHCP server sends a DHCPNack to the DHCP relay agent. When the DHCP relay agent receives the DHCPNack, it readdresses and sends the message to the DHCP client. The DHCP client then restarts 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 DHCP relay agent. When the DHCP relay agent receives the DHCPNack, it readdresses and sends the message to the DHCP client. The DHCP client then restarts the IP address allocation process by sending a DHCPDiscover message.

How IP Packet Filtering Works

Windows Server 2003 supports several types of IP packet filtering.

Routing and Remote Access IP Packet Filters

Windows Server 2003 supports the following types of IP packet filtering to protect interfaces of a Routing and Remote Access router:

  • Basic Firewall, provided by the NAT/Basic Firewall component of the Routing and Remote Access service. Basic Firewall is intended for use on Internet-connected interfaces (public interfaces). For more information about Basic Firewall packet filtering, see “Basic Firewall” later in this section.

  • IP packet filtering, enabled on the General tab of the Properties page of any IP interface. Although input and output filters configured in this way are typically referred to as “IP packet filters,” all of the other types of packet filters listed in this section introduction are also IP packet filters. For more information about IP packet filtering provided by Routing and Remote Access, see “IP Packet Filtering” later in this section.

Other Windows IP Packet Filters

In addition to the IP packet filter capabilities provided by the Routing and Remote Access service, Windows Server 2003 supports the following types of IP packet filtering:

  • Internet Connection Firewall (ICF) — a Network Connections component available in Windows XP, Windows XP SP1, and Windows Server 2003 — is a simple stateful firewall similar to Basic Firewall.

  • TCP/IP packet filtering, configured by using the Options tab of the Advanced TCP/IP Settings page of TCP/IP properties, is used only for inbound local host traffic.

  • Internet Protocol security (IPSec) packet filtering, provided as part of IPSec, is included with Windows Server 2003. IPSec can perform host-based packet filtering to provide limited firewall capabilities that help defend end systems against network-based attacks. An end system is a network device that cannot forward packets between portions of a network. For more information about IPSec packet filtering, see “IPSec Technical Reference.”

Basic Firewall

Basic Firewall, provided by the NAT/Basic Firewall component of the Routing and Remote Access service, is a simple stateful firewall that can be enabled to protect a public interface on a computer running the Windows Server 2003 Routing and Remote Access service. A stateful firewall uses dynamic packet filtering to examine incoming and outgoing packets. Basic Firewall, which combines stateful packet filtering of network traffic with a set of static packet filters, examines network traffic in order to prevent unsolicited traffic originating on the Internet from being processed by an Internet-connected interface. Basic Firewall uses technology similar to that used by ICF.

The network address translation capability provided by the Windows Server 2003 Routing and Remote Access service can be configured with or without the Basic Firewall feature enabled. Conversely, you can enable Basic Firewall on any Internet-connected interface even when you have not deployed NAT. For a Basic Firewall with NAT, all packets that are received on the Internet interface of a NAT router that do not correspond to traffic requested by the NAT router (either for itself or for private intranet clients) are discarded. For a Basic Firewall without NAT, all packets that are received on the Internet interface of a Routing and Remote Access server that does not perform network address translation that do not correspond to traffic requested by this server are discarded.

Basic Firewall in conjunction with Routing and Remote Access NAT is primarily for use by small office or home office (SOHO) customers. For more information about using NAT with Basic Firewall, including information about how Basic Firewall filters TCP and UDP unicast packets, broadcast and multicast packets, specially defined packets, and ICMP traffic, see “How NAT Works” in NAT Technical Reference.

You can also use the NAT/Basic Firewall component of Routing and Remote Access in conjunction with the IP packet filtering capability provided by IPSec. Alternatively, you can use IPSec with ICF, which also provides stateful packet filtering.

IP Packet Filtering

To increase security on an IP network, an IP router configured with packet filters can allow or prevent the flow of specific types of IP traffic. IP packet filtering, by providing a way for the network administrator to define precisely which IP traffic is received and sent by the router, is an important component of connecting corporate intranets to public networks like the Internet.

When packet filtering is configured, a packet arriving at a router might be forwarded to its destination, rejected with an error message returned to notify the sender, or dropped with no error message sent.

Filtering Inbound and Outbound Traffic

IP packet filtering consists of creating a series of definitions, called filters, which define for the router what types of traffic are allowed or blocked on each interface. Filters can be set for incoming and outgoing traffic. Input filters define what inbound traffic the router is allowed to process locally (as the destination) or to forward (as a router) on a specific interface. Output filters define what outbound traffic the router is allowed to send from that interface.

To filter incoming and outgoing traffic to allow a specific subset of traffic, you can implement packet filtering on a router or on a non-router computer. A computer running Routing and Remote Access that has only one interface is a non-router computer.

Planning Carefully When Configuring Packet Filters

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 certain inbound traffic, but the output filter on another interface does not allow the same traffic to be sent. The result is that the traffic is not passed across the router or exchanged with a non-router computer on which these contradictory packet filters are configured.

When planning how to implement packet filters, ensure that the filters are not too restrictive. Excessively restrictive filters can impair the functionality of other protocols that might be operating on the computer. For example, if a computer that is running Windows Server 2003 is also running Internet Information Services (IIS) as a Web server and if packet filters are defined so that only Web-based traffic is allowed, you cannot use the ping tool to perform basic IP troubleshooting. Likewise, the Web server cannot communicate with a domain controller. If the Web server is a silent RIP host, the filters prevent the silent RIP process from receiving the RIP announcements.

Therefore, when troubleshooting connectivity or IP-based network problems on a computer running Windows Server 2003, begin by determining whether that computer is using IP packet filtering. If it is, verify whether packet filtering on that computer prevents outgoing or incoming packets for the protocol experiencing the problem.

Windows Server 2003 IP Packet Filtering

You can configure a computer running the Windows Server 2003 Routing and Remote Access service either to pass all traffic except that which is blocked by filters, or to discard all traffic except that which is allowed by filters. For example, you might want to configure a filter to allow all traffic except Telnet traffic (TCP port 23), or you might want to set up filters on a dedicated Web server to process only Web-based TCP traffic (TCP port 80).

Routing and Remote Access Input and Output Filters

The following table shows that input and output filters work in a similar manner, differing only in that they apply either to inbound or to outbound traffic.

Similar Functionality of Input and Output Filters

Function Input Filters Output Filters

Filtering by exception

Configured on an exception basis. You can configure the filter action to either allow all traffic except that which is specified, or to block all traffic except that which is specified.

Configured on an exception basis. You can configure the filter action to either transmit all traffic except that which is specified, or to drop all traffic except that which is specified.

Using multiple filters

When multiple filters are configured, the separate filters applied to the inbound packet are compared by using a logical OR operation. If the packet matches at least one of the configured filters, it is allowed or blocked depending on the filter action setting.

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

Troubleshooting

You can quickly and temporarily disable input packet filtering while preserving the list of configured packet filters. Do this by adding a filter that allows all traffic and set the input filter action to block all traffic except that which is specified. After troubleshooting, remove the all-traffic filter and reset the input filter action to its original value.

You can quickly and temporarily disable output packet filtering while preserving the list of configured packet filters. Do this by adding a filter that allows all traffic and set the output filter action to block all traffic except that which is specified. After troubleshooting, remove the all-traffic filter and reset the output filter action to its original value.

Filterable Fields in IP, TCP, UDP, and ICMP Headers

Windows Server 2003 Routing and Remote Access can filter incoming and outgoing IP packets based on specified fields of the IP, TCP, UDP, and ICMP headers.

The Routing and Remote Access service does not support either of the following:

  • Creating a filter on any protocols other than IP, TCP, UDP, and ICMP.

  • Creating a filter based on all of the fields of the IP, TCP, UDP, or ICMP header. The Routing and Remote Access service does support creating a filter on specific fields of each of these headers.

For more information about the IP, TCP, UDP, and ICMP protocols, including the complete set of fields for each protocol’s header, see Microsoft Windows Server 2003 TCP/IP Protocols and Services Technical Reference by Joseph Davies and Thomas Lee, 2003, Microsoft Press.

IP Header

The IP header has 13 fields, including source and destination IP addresses and a field that identifies the upper layer protocol (such as TCP, UDP, or ICMP) contained within the IP packet payload. Because the IP header contains the packet’s source and destination addresses, the TCP, UDP, and ICMP headers do not need to contain these addresses.

To add or edit an IP packet filter, in the Routing and Remote Access snap-in select Inbound Filters or Outbound Filters on the General tab of the InterfaceNameProperties page in the IP Routing\General container. You can define filters for the following IP header fields:

  • Source IP Address. The IP address of the source network, which you can configure with a subnet mask to allow or block a single source or an entire range of IP addresses (corresponding to an IP subnet or a summarized route) to be specified with a single filter entry.

  • Destination IP Address. The IP address of the destination network, which you can configure with a subnet mask to allow or block a single destination or an entire range of IP addresses (corresponding to an IP subnet or a summarized route) to be specified with a single filter entry.

  • Protocol. An identifier used to indicate the upper layer protocol contained within the IP packet payload. For example, 6 indicates the TCP protocol, 17 indicates the UDP protocol, and 1 indicates the ICMP protocol.

TCP Header

TCP is one of two transport layer protocols within the TCP/IP protocol suite used for transporting data (the other is UDP). TCP, which supports only one-to-one communication between two hosts, guarantees delivery of data, and guarantees that packets are delivered in the same order in which they were sent. The TCP header has 11 fields, including fields for source and destination port.

If you select TCP as the protocol when adding or editing an IP packet filter, you can define filters for the following two TCP header fields:

  • Source Port

  • Destination Port

Note

  • Routing and Remote Access does not support the configuration of a range of TCP ports in one step. To configure a range of TCP ports, you must configure a separate filter for each port in the range.
UDP Header

UDP is one of two transport layer protocols within the TCP/IP protocol suite used for transporting data (the other is TCP). UDP is simpler than TCP, supports one-to-one and one-to-many communications, and, unlike TCP, sends packets without first negotiating a connection between the sending and receiving hosts, and provides only a few error recovery services. UDP thus supports a “best-effort” delivery in contrast to TCP’s guaranteed delivery. The UDP header has 4 fields, including fields for source and destination port.

If you select UDP as the protocol when adding or editing an IP packet filter, you can define filters for the following two UDP fields:

  • Source Port

  • Destination Port

Note

  • Routing and Remote Access does not support the configuration of a range of UDP ports in one step. To configure a range of UDP ports, you must configure a separate filter for each port in the range.
ICMP Header

ICMP enables the generation of delivery error messages, diagnostic messages, and informational messages related to IP (such as the ICMP redirect message used to dynamically update the IP routing table).

If you select ICMP as the protocol when adding or editing an IP packet filter, you can define filters for the following two ICMP header fields:

  • Type. Indicates the type of ICMP packet, such as an Echo or Echo Reply message.

  • Code. Indicates one of the possible multiple functions within a specified type. If a type has only one function, the Code field is set to 0.

The combination of ICMP Type and ICMP Code determines which ICMP message is sent. The following table lists commonly used ICMP types and codes.

Common ICMP Types and Codes and Associated Messages

ICMP Type ICMP Code Use

0

0

Echo reply

8

0

Echo

3

0

Destination unreachable - Network unreachable

3

1

Destination unreachable - Host unreachable

3

2

Destination unreachable - Protocol unreachable

3

3

Destination unreachable - Port unreachable

3

4

Destination unreachable - Fragmentation needed and the Don’t Fragment flag is 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 expired in transit

11

1

Time exceeded - Fragmentation reassembly expiration

12

0

Parameter problem

Note

  • For a complete list of ICMP message types, see “ICMP TYPE NUMBERS” at the Internet Assigned Numbers Authority Web site.

Routing and Remote Access Filters for IP Header Fields

The following table shows the IP header fields for which it is possible to create a filter and the corresponding fields of the dialog boxes in the Routing and Remote Access snap-in in which the filter is created. These settings are configurable in the Windows Server 2003 Routing and Remote Access snap-in by selecting Inbound Filters or Outbound Filters on the General tab of the InterfaceNameProperties page for an interface in the IP Routing\General container, and then selecting New or Edit to access the Add IP Filter dialog box or the Edit IP Filter dialog box, respectively. Typically, filters are configured in pairs, either {Destination Network/Protocol}, or {Source Network/Protocol}.

IP Header Fields and Corresponding Routing and Remote Access Name

IP Header Field Name in Routing and Remote Access Add IP Filter or Edit IP Filter Dialog Box

Source IP Address

Source Network

Destination IP Address

Destination Network

Protocol

Protocol

Filtering Scenarios

This section illustrates filter configurations for commonly implemented filtering scenarios.

Note

  • If you combine any sets of filters, ensure that the filters do not cancel each other out. Note that AND is used within a filter; OR is used between filters.

Local Host Filtering

Local host filtering configured on the Internet interface of an IP host permits the interface to receive only traffic that a non-router host can receive. This includes traffic to the unicast address of the host, broadcast addresses, and multicast addresses. This type of filtering allows the receipt of packets but disables the forwarding of packets on the interface on which local host filtering is enabled. Use local host filtering when an intranet is connected to the Internet and you do not want direct routing of packets between the intranet and the Internet.

Local host filtering on an interface effectively disables unicast routing on that interface because the only unicast traffic allowed through the interface is that which is destined specifically for that host. Transit unicast traffic is dropped. Local host filtering permits the interface to receive only the unicast traffic destined for this host, the broadcast traffic intended for all host’s on the host’s subnet, or multicast traffic.

As shown in the example in the following table, for the local host filtering scenario, five specific input filters are used on the Internet interface. In the example, the local host computer has the IP address 172.16.5.98 with the subnet mask of 255.255.255.0 (a subnet of the private IP network ID 172.16.0.0/12). The Internet interface is viewable in the Routing and Remote Access snap-in in the details pane of the IP Routing\General container. By adding the filters shown in the table on the General tab of the Properties page of the Internet interface, and then selecting the Drop all packets except those that meet the criteria below filter action, you can configure the computer to block all packets except those explicitly allowed by the configured filters. For the local host filters, the default protocol Any is used and no source network address is needed.

Example: Five Input Filters for Local Host Filtering

Filter Filter Characteristics

Host IP address input filter (allows packets unicast to this computer)

Destination network:

  • IP address of this host: 172.16.5.98

  • Subnet mask: 255.255.255.255

Note: An IP address for a particular computer in conjunction with a subnet mask of 255.255.255.255 represents a host route (a route to a specific IP address).

Subnet broadcast address input filter (allows packets broadcast to hosts on the local subnet)

Destination network:

  • IP address of this host’s subnet broadcast: 172.16.5.255

  • Subnet mask: 255.255.255.255

Note: On a classless network (as is the case in this example), the IP subnet broadcast address is formed by setting all host bits to 1 (255 in decimal notation represents eight ones in binary notation).

Only a classless network has a subnet broadcast address; it does not have a network broadcast address. (In contrast, a classful network does not have a subnet broadcast address; it has only a network broadcast address.)

All-subnets-directed broadcast address input filter (allows packets broadcast to hosts on all subnets of a subnetted class-based network ID)

Destination network:

  • IP address of this host’s all-subnets-directed broadcast: 172.16.255.255

  • Subnet mask: 255.255.255.255

Note: On a classless network (as is the case in this example), the all-subnets-directed broadcast address is formed by assuming that the network ID is the original classful network ID, and then setting all host bits to 1 (255 in decimal notation). If 172.16.5.98 were a class-based address, it would be a Class B address. Therefore, in the IP address, the last two octets are set to 255 for the all-subnets-directed broadcast address filter.

Limited broadcast address input filter (allows packets sent to the limited broadcast address)

Destination network:

  • IP address of the limited broadcast: 255.255.255.255

  • Subnet mask: 255.255.255.255

Note: The IP limited broadcast address is formed by setting all 32 bits in the IP address to 1 (255.255.255.255). All hosts, classful or classless, process packets addressed to the limited broadcast address, typically during an automated configuration process, such as the DHCP automated configuration process.

All possible multicast traffic input filter (allows all IP multicast packets)

Destination network:

  • IP address for multicast traffic: 224.0.0.0

  • Subnet mask: 240.0.0.0

Note: The address 224.0.0.0 with the subnet mask 240.0.0.0 is the entry in the routing table that informs IP to forward the multicast packet to the destination (in this example, to 172.16.5.98).

Web Traffic Filtering

Web traffic filtering is configured on Web servers that run the Routing and Remote Access service in addition to Microsoft Internet Information Services (IIS). Web traffic filtering ensures that only Web-based traffic to and from IIS is processed to protect against malicious attacks on other services running on the Web server.

For a Web server connected to the Internet, enabling Web traffic filtering requires adding one input filter and one output filter on the Internet interface. The Internet interface is viewable in the Routing and Remote Access snap-in in the details pane of the IP Routing\General container. For example, if the default port of your Web server is port 80, you can add filters on the General tab of the Properties page of the Internet interface that block all packets (by using the Drop all packets except those that meet the criteria below filter action) except those allowed to and from the Web server by the filters described in the following table.

Example: Input and Output Filters for Web Traffic Filtering

Filter Filter Characteristics

Input filter (allows packets sent specifically to this Web server)

Destination network:

  • IP address: IP address of this Web server

  • Subnet mask: 255.255.255.255

Protocol: TCP

  • Source port: None

  • Destination port: 80

Output filter (allows packets sent from this Web server)

Source network:

  • IP address: IP address of this Web server

  • Subnet mask: 255.255.255.255

Protocol: TCP

  • Source port: 80

  • Destination port: None

If these filters are the only filters configured, the only traffic allowed through the interface is TCP traffic to and from IIS through TCP port 80 on the Windows Server 2003–based computer.

FTP Traffic Filtering

File Transfer Protocol (FTP) traffic filtering is done on hosts that run IIS with the FTP service enabled and run the Routing and Remote Access service. FTP traffic filtering ensures that only FTP-based traffic to and from FTP is processed to protect against malicious attacks on other services running on the FTP server.

For an FTP server connected to the Internet, enabling FTP traffic filtering requires adding two input filters and two output filters on the Internet interface. The Internet interface is viewable in the Routing and Remote Access snap-in in the details pane of the IP Routing\General container. For example, you can add filters on the General tab of the Properties page of the Internet interface that block all packets (by using the Drop all packets except those that meet the criteria below filter action) except those allowed to and from the FTP server by the filters described in the following table.

Note

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

Example: Input and Output Filters for FTP Traffic Filtering

Filter Filter Characteristics

Input filter (allows packets sent specifically to the FTP control port on this FTP server)

Destination network:

  • IP address: IP address of this FTP server

  • Subnet mask: 255.255.255.255

Protocol: TCP

  • Source port: None

  • Destination port: 21 (the FTP control port)

Input filter (allows packets sent specifically to the FTP data port on this FTP server)

Destination network:

  • IP address: IP address of this FTP server

  • Subnet mask: 255.255.255.255

Protocol: TCP

  • Source port: None

  • Destination port: 20 (the FTP data port)

Output filter (allows packets sent from the FTP control port on this FTP server)

Source network:

  • IP address:. IP address of this FTP server

  • Subnet mask: 255.255.255.255

Protocol: TCP

  • Source port: 21 (the FTP control port)

  • Destination port: None

Output filter (allows packets sent from the FTP data port on this FTP server)

Source network:

  • IP address: IP address of this FTP server

  • Subnet mask: 255.255.255.255

Protocol: TCP

  • Source port: 20 (the FTP data port)

  • Destination port: None

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

PPTP Traffic Filtering

Point-to-Point Tunneling Protocol (PPTP) traffic filtering on hosts that are acting as PPTP VPN servers ensures that only PPTP-based traffic to and from the PPTP VPN service on the host is processed. PPTP traffic filtering helps secure the PPTP VPN server from malicious attacks on other services running on the PPTP VPN server. For a PPTP VPN server connected to the Internet, PPTP traffic filtering is configured on the Internet interface.

For information about IP packet filtering for PPTP traffic, see “How VPN Works” in VPN Technical Reference.

L2TP/IPSec Traffic Filtering

Layer Two Tunneling Protocol over IPSec (L2TP/IPSec) traffic filtering on hosts that are acting as L2TP/IPSec VPN servers ensures that only L2TP-based traffic to and from the L2TP/IPSec VPN service on the host is processed. L2TP traffic filtering helps secure the L2TP/IPSec VPN server from malicious attacks on other services running on the L2TP/IPSec VPN server. For an L2TP/IPSec VPN server connected to the Internet, L2TP traffic filtering is configured on the Internet interface.

For information about IP packet filtering for L2TP/IPSec traffic, see “How VPN Works” in VPN Technical Reference.

Denying Spoofed Packets from Private IP Addresses

One way to create 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-Host Unreachable message.

To drop Internet traffic from spoofed private IP addresses, you can use the Windows Server 2003 Routing and Remote Access snap-in to add three input filters on the Internet interface. The Internet interface is viewable in the Routing and Remote Access snap-in in the details pane of the IP Routing\General container. You can add filters on the General tab of the Properties page of the Internet interface that accept all packets (by using the Receive all packets except those that meet the criteria below filter action) except the following:

  • A source IP address of 10.0.0.0 with a subnet mask 255.0.0.0.

  • A source IP address of 172.16.0.0 with a subnet mask 255.240.0.0.

  • A source IP address of 192.168.0.0 with a subnet mask 255.255.0.0.

Filtering Fragmented IP Datagrams

The Windows Server 2003 Routing and Remote Access service also supports the filtering of fragmented IP datagrams, which are datagrams that contain a fragment of an IP payload. Source hosts or routers fragment IP payloads so that the resulting IP datagram is small enough to be sent on the subnet of the next hop. The filtering of fragmented IP datagrams by the Routing and Remote Access service applies only to incoming traffic.

All interfaces are viewable in the Routing and Remote Access snap-in in the details pane of the IP Routing\General container. You can enable filtering of fragmented IP datagrams on the General tab on the properties of each interface by selecting Enable fragmentation checking. This setting specifies that the router discard all fragmented IP packets that do not correspond with traffic allowed by the filters (if any) configured for this interface. To prevent the router from forwarding all fragmented IP packets for transit traffic on any interface, enable fragmentation checking on all interfaces of the router. This setting does not prevent the forwarding of fragmented packets sent from the router.

You can use filtering of fragmented IP datagrams to prevent the “ping of death,” which is a denial-of-service attack where malicious users send multiple 64-KB ICMP Echo messages. The 64-KB messages are fragmented and must be reassembled at the destination host. For each separate 64-KB message, the TCP/IP protocol must allocate memory, tables, timers, and other resources. If a server, including a Windows Server 2003–based computer, receives a substantial number of fragmented messages, it can become overloaded, with the result that the servicing of valid information requests is impaired. Enabling the filtering of fragmented IP datagrams causes incoming fragmented IP datagrams to be discarded immediately.

How ICMP Router Discovery Works

Windows Server 2003 TCP/IP and the Windows Server 2003 Routing and Remote Access service include support for the router advertisement and discovery capability that is documented in RFC 1256. ICMP itself is described in RFC 792. Enabling router discovery, an alternative to using manually or DHCP-configured default gateways, provides an improved method of configuring and detecting the default gateway. For IP nodes, the default gateway is the IP router (on the same subnet) that forwards traffic for the node to destinations not located on the local subnet.

Note

  • In IPv6, the Neighbor Discovery protocol replaces the IPv4 features ICMP Router Discovery, ARP, and ICMP Redirect. For information about IPv6, see “How IPv6 Works” in IPv6 Technical Reference.

ICMP Router Solicitation messages and Router Advertisement messages simplify how IP hosts are configured with the IP addresses of local routers and provide a way for hosts to determine whether routers are available. If enabled on both router and host, ICMP router discovery automates the discovery and configuration of the default gateway on the client. Client computers can dynamically discover the best default gateway to use on a subnet and can automatically switch to another default gateway if the first default gateway fails or if the network administrator changes router preferences.

ICMP router discovery governs the interaction between a host and a router in the following way:

  • A router periodically sends a Router Advertisement message to all hosts on the subnet to notify them that the router is available. A router also sends a Router Advertisement message in response to a Router Solicitation message sent by a host.

  • A host listens for Router Advertisement messages from routers. A host also sends a Router Solicitation message to discover active routers on its subnet and to discover whether known routers are currently unavailable.

On a computer running Windows Server 2003, ICMP Router Advertisement messages are disabled by default. TCP/IP for Windows Server 2003, Windows 2000, and Windows 98 supports ICMP Router Solicitation messages to discover the default gateway as well as the receipt of ICMP Router Advertisements; this capability is also disabled by default.

Router Advertisements Sent by Routers

Router Advertisements are explicit notifications sent by IP routers to IP hosts on the subnet that the router is available. A router sends out a pseudo-periodic Router Advertisement by using an ICMP message (Type 9, Code 0). The Router Advertisement message can be sent to the all-systems IP multicast address of 224.0.0.1, to the local IP broadcast address, or to the limited broadcast address (255.255.255.255). By default, a router sends a Router Advertisement to the all-systems IP multicast address.

Router Solicitations Sent by Hosts

When an IP host that supports ICMP router discovery needs to be configured with a default gateway (either upon initialization or because its default gateway is unavailable), the host sends out a Router Solicitation message by using an ICMP message (Type 10, Code 0). The Router Solicitation message can be sent to the all-routers IP multicast address of 224.0.0.2, to the local IP broadcast address, or to the limited broadcast address (255.255.255.255). By default, hosts send Router Solicitation messages to the all-routers IP multicast address when an interface initializes. Routers on the host’s subnet that support ICMP router discovery immediately respond with a Router Advertisement message, and the host chooses the router for which an administrator has configured the highest preference level as its default gateway. A host sends a maximum of three solicitations at intervals of approximately 600 milliseconds.

Note

  • ICMP router discovery is not a routing protocol. Routers advertise only their existence; they do not advertise the best way to reach a specific destination subnet. If a host uses a non-optimal route, an ICMP Redirect message redirects the host to the preferred route.

ICMP Router Discovery Settings

Settings for ICMP router discovery for a router are configurable in the Windows Server 2003 Routing and Remote Access snap-in on the General tab of the properties for an interface in the IP Routing\General container. If you select the Enable router discovery advertisements option on the General tab, you can configure the time interval after which a router is considered down, the level of preference for this router to act as a default gateway for hosts, and the maximum and minimum rate at which the router periodically sends ICMP router advertisements.

On a client computer running Windows XP Professional, you can use the netsh routing ip routerdiscoveryadd interface command to configure router discovery for the specified interface from a command prompt. On a client computer running Windows 2000 Professional, you can enable router discovery by using the Registry Editor to configure the PerformRouterDiscovery and SolicitationAddressBcast registry entries.

IPv4 and Routing and Remote Access APIs

Microsoft platform software development kits (SDKs) provide application programming interfaces (APIs) useful for third-party developers who create software that interacts with Windows operating systems. The following are important APIs for developers working in a unicast IPv4 routing environment that includes Windows Server 2003.

Internet Protocol Helper (IP Helper) API

This API assists network administration of the local computer by enabling applications to retrieve information about network configuration settings of the local computer and to modify that configuration. In addition, IP Helper notification mechanisms ensure that an application is informed when specific aspects of the local computer network configuration change. The IP Helper API is applicable in any computing environment where programmatically manipulating TCP/IP configuration is useful. Typical usage includes retrieving information about network configuration, managing network adapters, managing interfaces, managing IP addresses, using the address resolution protocol (ARP), retrieving information about IP and ICMP, managing routing, receiving notification of network events, and retrieving information about TCP and UDP. In Windows Server 2003, IP Helper has been extended to allow the retrieval of information for IPv6 and its components. For more information about the IP Helper API, see “Microsoft Platform SDK IP Helper.”

Routing and Remote Access Service API

This API makes the Routing and Remote Access service extensible. Third-party routing protocol developers can write additional routing protocols that interact with the routing table manager of the Routing and Remote Access service. Third-party software vendors can also create applications to administer the routing and remote access capabilities of Windows Server 2003 (as well as Windows 2000 Server). For example, to augment the built-in support for RIP and OSPF, a third-party vendor can develop support for Border Gateway Protocol (BGP) for IP that works with the Routing and Remote Access service. For more information, see “Microsoft Platform SDK Routing and Remote Access Service.”

Windows Sockets 2 (Winsock2) API

This API enables programmers to create advanced Internet, intranet, and other network-capable applications to transmit application data across the wire, independent of the network protocol being used. In Windows Server 2003, new Windows Sockets programming elements extend the capability of Winsock to simplify programming and to provide IPv6 compatibility. For more information about the Windows Sockets API, see “Microsoft Platform SDK Windows Sockets 2.”

For comprehensive information about APIs supported by Microsoft Windows, including Windows Server 2003; Windows XP; Windows Advanced Server Limited Edition; Windows Millennium Edition; Windows 2000; Windows NT versions 4.0 and 3.51; Windows 98 and Windows 95; as well as Microsoft Internet Explorer, see “Microsoft Platform SDK Windows API.”

To install the SDK for Windows Server 2003, see “Microsoft Platform SDK,” and then click “Windows SDK” in the left column.

The following resources contain additional information that is relevant to this section.

  • For more information about each of the RFCs cited in this document, see IETF RFC Database.

  • TCP/IP Technical Reference.

  • Routing and Remote Access.

  • IPv4 Multicasting Technical Reference.

  • Microsoft Windows Server 2003 TCP/IP Protocols and Services Technical Reference, by Joseph Davies and Thomas Lee, 2003, Redmond, WA: Microsoft Press.

  • Routing in the Internet, Second Edition, by Christian Huitema, 2000, Englewood Cliffs, NJ: Prentice Hall.

  • Interconnections: Bridges and Routers, Second Edition, by Radia Perlman, 2000, Reading, MA: Addison-Wesley.

  • Internetworking with TCP/IP: Volume 1 Principles, Protocols, and Architectures, Fourth Edition, by Douglas E. Comer, 2000, Englewood Cliffs, New Jersey: Prentice Hall.

  • OSPF: Anatomy of an Internet Routing Protocol, by John T. Moy, 1998, Reading, MA: Addison-Wesley.