novembre 09, 2009

- Cisco Networking: Route Selection in Cisco Routers

Introduction

One of the intriguing aspects of Cisco routers, especially for those new to routing, is how the router chooses which route is the best among those presented by routing protocols, manual configuration, and various other means. While route selection is much simpler than you might imagine, to understand it completely requires some knowledge about the way Cisco routers work.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Processes Involved

There are three processes involved in building and maintaining the routing table in a Cisco router:

  • Various routing processes, which actually run a network (or routing) protocol, such as Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP), Intermediate System-to-Intermediate System (IS-IS), and Open Shortest Path First (OSPF).

  • The routing table itself, which accepts information from the routing processes and also replies to requests for information from the forwarding process.

  • The forwarding process, which requests information from the routing table to make a packet forwarding decision.

Let's examine the interaction between the routing protocols and the routing table to understand how the routing table is built.

Building the Routing Table

The main considerations while building the routing table are:

  • Administrative distance - This is the measure of trustworthiness of the source of the route. If a router learns about a destination from more than one routing protocol, administrative distance is compared and the preference is given to the routes with lower administrative distance. In other words, it is the believability of the source of the route.

  • Metrics - This is a measure used by the routing protocol to calculate the best path to a given destination, if it learns multiple paths to the same destination. Each routing protocol uses a different metric.

  • Prefix length

As each routing process receives updates and other information, it chooses the best path to any given destination and attempts to install this path into the routing table. For instance, if EIGRP learns of a path toward 10.1.1.0/24, and decides this particular path is the best EIGRP path to this destination, it tries to install the path it has learned into the routing table.

The router decides whether or not to install the routes presented by the routing processes based on the administrative distance of the route in question. If this path has the lowest administrative distance to this destination (when compared to the other routes in the table), it's installed in the routing table. If this route isn't the route with the best administrative distance, then the route is rejected.

To understand this better, let's look at an example. Assume a router has four routing processes running: EIGRP, OSPF, RIP, and IGRP. Now, all four of these processes have learned of various routes to the 192.168.24.0/24 network, and each has chosen its best path to that network through its internal metrics and processes.

Each of these four processes attempts to install their route toward 192.168.24.0/24 into the routing table. The routing processes are each assigned an administrative distance, which is used to decide which route to install.

Default Administrative Distances

Connected

0

Static

1

eBGP

20

EIGRP (internal)

90

IGRP

100

OSPF

110

IS-IS

115

RIP

120

EIGRP (external)

170

iBGP

200

EIGRP summary route

5

Since the internal EIGRP route has the best administrative distance (the smaller the administrative distance, the higher the preference), it's installed in the routing table.

Backup Routes

What do the other protocols, RIP, IGRP, and OSPF, do with the routes that weren't installed? What if the most preferred route, learned from EIGRP, fails? Cisco IOS® Software uses two approaches to solve this problem: The first is to have each routing process attempt to install its best routes periodically. If the most preferred route fails, the next best route (according to administrative distance) succeeds on the next attempt. The other solution is for the routing protocol that failed to install its route in the table to hang on to the route, and tell the routing table process to report if the best path fails.

For protocols that don't have their own routing information tables, such as IGRP, the first method is used. Every time IGRP receives an update about a route, it attempts to install the updated information in the routing table. If there's already a route to this same destination in the routing table, the installation attempt fails.

For protocols that have their own database of routing information, such as EIGRP, IS-IS, OSPF, BGP, and RIP, a backup route is registered when the initial attempt to install the route fails. If the route installed in the routing table fails for some reason, the routing table maintenance process calls each routing protocol process that has registered a backup route, and asks them to reinstall the route in the routing table. If there are multiple protocols with registered backup routes, the preferred route is chosen based on administrative distance.

Adjusting the Administrative Distance

The default administrative distance might not always be right for your network; you may want to adjust them so that RIP routes are preferred over IGRP routes, for instance. Before explaining how to adjust the administrative distances, we need to look at the implications of changing the administrative distance.

Changing the administrative distance on routing protocols can be very dangerous! Changing the default distances can actually lead to routing loops and other oddities in your network. We recommend you change administrative distance with caution, and only after you have thought through what you want to achieve, and all the consequences of your actions.

For entire protocols, changing the distance is relatively easy; simply configure the distance using the distance command in the routing process sub-configuration mode. You can also change the distance for routes learned from one source only in some protocols, and you can change the distance on just some routes.

For static routes, you can change the distance of each route by entering a distance after the ip route command:

ip route network subnet mask next hop distance

You can't change the administrative distance for all the static routes at once.

How Metrics Determine the Route Selection Process

Routes are chosen and built in the routing table based on the routing protocol's administrative distance. The routes learned from the routing protocol with the lowest administrative distance are installed in the routing table. If there are multiple paths to the same destination from a single routing protocol, then the multiple paths would have the same administrative distance and the best path is selected based on the metrics. Metrics are values associated with specific routes, ranking them from most preferred to least preferred. The parameters used to determine the metrics differ for different routing protocols. The path with the lowest metric is selected as the optimal path and installed in the routing table. If there are multiple paths to the same destination with equal metrics, load balancing is done on these equal cost paths. For more information on load balancing see How Does Load Balancing Work?

Prefix Lengths

Let's look at another scenario to see how the router handles another common situation: varying prefix lengths. Assume, again, that a router has four routing processes running on it, and each process has received these routes:

  • EIGRP (internal): 192.168.32.0/26

  • RIP: 192.168.32.0/24

  • OSPF: 192.168.32.0/19

Which of these routes will be installed in the routing table? Since EIGRP internal routes have the best administrative distance, it's tempting to assume the first one will be installed. However, since each of these routes has a different prefix length (subnet mask), they're considered different destinations, and they will all be installed in the routing table.

Let's see how the forwarding engine uses the information from the routing table to make forwarding decisions.

Making Forwarding Decisions

Let's look at the three routes we just installed in the routing table, and see how they look on the router.

router# show ip route
....
D 192.168.32.0/26 [90/25789217] via 10.1.1.1
R 192.168.32.0/24 [120/4] via 10.1.1.2
O 192.168.32.0/19 [110/229840] via 10.1.1.3
....

If a packet arrives on a router interface destined for 192.168.32.1, which route would the router choose? It depends on the prefix length, or the number of bits set in the subnet mask. Longer prefixes are always preferred over shorter ones when forwarding a packet.

In this case, a packet destined to 192.168.32.1 is directed toward 10.1.1.1, because 192.168.32.1 falls within the 192.168.32.0/26 network (192.168.32.0 to 192.168.32.63). It also falls within the other two routes available, but the 192.168.32.0/26 has the longest prefix within the routing table (26 bits verses 24 or 19 bits).

Likewise, if a packet destined for 192.168.32.100 arrives on one of the router's interfaces, it's forwarded to 10.1.1.2, because 192.168.32.100 doesn't fall within 192.168.32.0/26 (192.168.32.0 through 192.168.32.63), but it does fall within the 192.168.32.0/24 destination (192.168.32.0 through 192.168.32.255). Again, it also falls into the range covered by 192.168.32.0/19, but 192.168.32.0/24 has a longer prefix length.

IP Classless

Where the ip classless configuration command falls within the routing and forwarding processes is often confusing. In reality, IP classless only affects the operation of the forwarding processes in IOS; it doesn't affect the way the routing table is built. If IP classless isn't configured (using the no ip classless command), the router won't forward packets to supernets. As an example, let's again place three routes in the routing table and route packets through the router.

Note: If the supernet or default route is learned via IS-IS or OSPF, the no ip classless configuration command is ignored. In this case, packet switching behavior works as though ip classless were configured.

router# show ip route
....
172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.30.32.0/20 [90/4879540] via 10.1.1.2
D 172.30.32.0/24 [90/25789217] via 10.1.1.1
S* 0.0.0.0/0 [1/0] via 10.1.1.3

Remembering that the 172.30.32.0/24 network includes the addresses 172.30.32.0 through 172.30.32.255, and the 172.30.32.0/20 network includes the addresses 172.30.32.0 through 172.30.47.255, we can then try switching three packets through this routing table and see what the results are.

  • A packet destined to 172.30.32.1 is forwarded to 10.1.1.1, since this is the longest prefix match.

  • A packet destined to 172.30.33.1 is forwarded to 10.1.1.2, since this is the longest prefix match.

  • A packet destined to 192.168.10.1 is forwarded to 10.1.1.3; since this network doesn't exist in the routing table, this packet is forwarded to the default route.

  • A packet destined to 172.30.254.1 is dropped.

The surprising answer out of these four is the last packet, which is dropped. It's dropped because its destination, 172.30.254.1, is within a known major network, 172.30.0.0/16, but the router doesn't know about this particular subnet within that major network.

This is the essence of classful routing: If one part of a major network is known, but the subnet toward which the packet is destined within that major network is unknown, the packet is dropped.

The most confusing aspect of this rule is that the router only uses the default route if the destination major network doesn't exist in the routing table at all.

This can cause problems in a network where a remote site, with one connection back to the rest of the network, is running no routing protocols, as illustrated.

21a.gif

The remote site router is configured like this:

interface Serial 0
ip address 10.1.2.2 255.255.255.0
!
interface Ethernet 0
ip address 10.1.1.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.2.1
!
no ip classless

With this configuration, the hosts at the remote site can reach destinations on the Internet (through the 10.x.x.x cloud), but not destinations within the 10.x.x.x cloud, which is the corporate network. Because the remote router knows about some part of the 10.0.0.0/8 network, the two directly connected subnets, and no other subnet of 10.x.x.x, it assumes these other subnets don't exist and drops any packets destined for them. Traffic destined to the Internet, however, doesn't ever have a destination in the 10.x.x.x range of addresses, and is therefore correctly routed through the default route.

Configuring ip classless on the remote router resolves this problem by allowing the router to ignore the classful boundaries of the networks in its routing table and simply route to the longest prefix match it can find.

Summary

In summary, making a forwarding decision actually consists of three sets of processes: the routing protocols, the routing table, and the actual process which makes a forwarding decision and switches packets. These three sets of processes are illustrated, along with their relationship, below.

21b.gif

The longest prefix match always wins among the routes actually installed in the routing table, while the routing protocol with the lowest administrative distance always wins when installing routes into the routing table.

- Cisco Networking: IP Addressing and Subnetting for New Users

Introduction

This document gives you basic information needed to configure your router for routing IP, such as how addresses are broken down and how subnetting works. You learn how to assign each interface on the router an IP address with a unique subnet. There are many examples to help tie everything together.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Additional Information

If definitions are helpful to you, use these vocabulary terms to get you started:

  • Address—The unique number ID assigned to one host or interface in a network.

  • Subnet—A portion of a network sharing a particular subnet address.

  • Subnet mask—A 32-bit combination used to describe which portion of an address refers to the subnet and which part refers to the host.

  • Interface—A network connection.

If you have already received your legitimate address(es) from the Internet Network Information Center (InterNIC), you are ready to begin. If you do not plan to connect to the Internet, Cisco strongly suggests that you use reserved addresses from RFC 1918 leavingcisco.com.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Understanding IP Addresses

An IP address is an address used to uniquely identify a device on an IP network. The address is made up of 32 binary bits which can be divisible into a network portion and host portion with the help of a subnet mask. The 32 binary bits are broken into four octets (1 octet = 8 bits). Each octet is converted to decimal and separated by a period (dot). For this reason, an IP address is said to be expressed in dotted decimal format (for example, 172.16.81.100). The value in each octet ranges from 0 to 255 decimal, or 00000000 - 11111111 binary.

Here is how binary octets convert to decimal: The right most bit, or least significant bit, of an octet holds a value of 20. The bit just to the left of that holds a value of 21. This continues until the left-most bit, or most significant bit, which holds a value of 27. So if all binary bits are a one, the decimal equivalent would be 255 as shown here:

    1  1  1  1 1 1 1 1
128 64 32 16 8 4 2 1 (128+64+32+16+8+4+2+1=255)

Here is a sample octet conversion when not all of the bits are set to 1.

  0  1 0 0 0 0 0 1
0 64 0 0 0 0 0 1 (0+64+0+0+0+0+0+1=65)

And this is sample shows an IP address represented in both binary and decimal.

        10.       1.      23.      19 (decimal)
00001010.00000001.00010111.00010011 (binary)

These octets are broken down to provide an addressing scheme that can accommodate large and small networks. There are five different classes of networks, A to E. This document focuses on addressing classes A to C, since classes D and E are reserved and discussion of them is beyond the scope of this document.

Note: Also note that the terms "Class A, Class B" and so on are used in this document to help facilitate the understanding of IP addressing and subnetting. These terms are rarely used in the industry anymore because of the introduction of classless interdomain routing (CIDR).

Given an IP address, its class can be determined from the three high-order bits. Figure 1 shows the significance in the three high order bits and the range of addresses that fall into each class. For informational purposes, Class D and Class E addresses are also shown.

Figure 1

3an.gif

In a Class A address, the first octet is the network portion, so the Class A example in Figure 1 has a major network address of 1.0.0.0 - 127.255.255.255. Octets 2, 3, and 4 (the next 24 bits) are for the network manager to divide into subnets and hosts as he/she sees fit. Class A addresses are used for networks that have more than 65,536 hosts (actually, up to 16777214 hosts!).

In a Class B address, the first two octets are the network portion, so the Class B example in Figure 1 has a major network address of 128.0.0.0 - 191.255.255.255. Octets 3 and 4 (16 bits) are for local subnets and hosts. Class B addresses are used for networks that have between 256 and 65534 hosts.

In a Class C address, the first three octets are the network portion. The Class C example in Figure 1 has a major network address of 192.0.0.0 - 233.255.255.255. Octet 4 (8 bits) is for local subnets and hosts - perfect for networks with less than 254 hosts.

Network Masks

A network mask helps you know which portion of the address identifies the network and which portion of the address identifies the node. Class A, B, and C networks have default masks, also known as natural masks, as shown here:

Class A: 255.0.0.0
Class B: 255.255.0.0
Class C: 255.255.255.0

An IP address on a Class A network that has not been subnetted would have an address/mask pair similar to: 8.20.15.1 255.0.0.0. To see how the mask helps you identify the network and node parts of the address, convert the address and mask to binary numbers.

8.20.15.1 = 00001000.00010100.00001111.00000001
255.0.0.0 = 11111111.00000000.00000000.00000000

Once you have the address and the mask represented in binary, then identifying the network and host ID is easier. Any address bits which have corresponding mask bits set to 1 represent the network ID. Any address bits that have corresponding mask bits set to 0 represent the node ID.

8.20.15.1 = 00001000.00010100.00001111.00000001
255.0.0.0 = 11111111.00000000.00000000.00000000
-----------------------------------
net id | host id

netid = 00001000 = 8
hostid = 00010100.00001111.00000001 = 20.15.1

Understanding Subnetting

Subnetting allows you to create multiple logical networks that exist within a single Class A, B, or C network. If you do not subnet, you are only able to use one network from your Class A, B, or C network, which is unrealistic.

Each data link on a network must have a unique network ID, with every node on that link being a member of the same network. If you break a major network (Class A, B, or C) into smaller subnetworks, it allows you to create a network of interconnecting subnetworks. Each data link on this network would then have a unique network/subnetwork ID. Any device, or gateway, connecting n networks/subnetworks has n distinct IP addresses, one for each network / subnetwork that it interconnects.

In order to subnet a network, extend the natural mask using some of the bits from the host ID portion of the address to create a subnetwork ID. For example, given a Class C network of 204.17.5.0 which has a natural mask of 255.255.255.0, you can create subnets in this manner:

204.17.5.0 -      11001100.00010001.00000101.00000000
255.255.255.224 - 11111111.11111111.11111111.11100000
--------------------------|sub|----

By extending the mask to be 255.255.255.224, you have taken three bits (indicated by "sub") from the original host portion of the address and used them to make subnets. With these three bits, it is possible to create eight subnets. With the remaining five host ID bits, each subnet can have up to 32 host addresses, 30 of which can actually be assigned to a device since host ids of all zeros or all ones are not allowed (it is very important to remember this). So, with this in mind, these subnets have been created.

204.17.5.0 255.255.255.224     host address range 1 to 30
204.17.5.32 255.255.255.224 host address range 33 to 62
204.17.5.64 255.255.255.224 host address range 65 to 94
204.17.5.96 255.255.255.224 host address range 97 to 126
204.17.5.128 255.255.255.224 host address range 129 to 158
204.17.5.160 255.255.255.224 host address range 161 to 190
204.17.5.192 255.255.255.224 host address range 193 to 222
204.17.5.224 255.255.255.224 host address range 225 to 254

Note: There are two ways to denote these masks. First, since you are using three bits more than the "natural" Class C mask, you can denote these addresses as having a 3-bit subnet mask. Or, secondly, the mask of 255.255.255.224 can also be denoted as /27 as there are 27 bits that are set in the mask. This second method is used with CIDR. Using this method, one of these networks can be described with the notation prefix/length. For example, 204.17.5.32/27 denotes the network 204.17.5.32 255.255.255.224. When appropriate the prefix/length notation is used to denote the mask throughout the rest of this document.

The network subnetting scheme in this section allows for eight subnets, and the network might appear as:

Figure 2

3b.gif

Notice that each of the routers in Figure 2 is attached to four subnetworks, one subnetwork is common to both routers. Also, each router has an IP address for each subnetwork to which it is attached. Each subnetwork could potentially support up to 30 host addresses.

This brings up an interesting point. The more host bits you use for a subnet mask, the more subnets you have available. However, the more subnets available, the less host addresses available per subnet. For example, a Class C network of 204.17.5.0 and a mask of 255.255.255.224 (/27) allows you to have eight subnets, each with 32 host addresses (30 of which could be assigned to devices). If you use a mask of 255.255.255.240 (/28), the break down is:

204.17.5.0 -      11001100.00010001.00000101.00000000
255.255.255.240 - 11111111.11111111.11111111.11110000
--------------------------|sub |---

Since you now have four bits to make subnets with, you only have four bits left for host addresses. So in this case you can have up to 16 subnets, each of which can have up to 16 host addresses (14 of which can be assigned to devices).

Take a look at how a Class B network might be subnetted. If you have network 172.16.0.0 ,then you know that its natural mask is 255.255.0.0 or 172.16.0.0/16. Extending the mask to anything beyond 255.255.0.0 means you are subnetting. You can quickly see that you have the ability to create a lot more subnets than with the Class C network. If you use a mask of 255.255.248.0 (/21), how many subnets and hosts per subnet does this allow for?

172.16.0.0  -   10101100.00010000.00000000.00000000
255.255.248.0 - 11111111.11111111.11111000.00000000
-----------------| sub |-----------

You are using five bits from the original host bits for subnets. This allows you to have 32 subnets (25). After using the five bits for subnetting, you are left with 11 bits for host addresses. This allows each subnet so have 2048 host addresses (211), 2046 of which could be assigned to devices.

Note: In the past, there were limitations to the use of a subnet 0 (all subnet bits are set to zero) and all ones subnet (all subnet bits set to one). Some devices would not allow the use of these subnets. Cisco Systems devices allow the use of these subnets when theip subnet zero command is configured.

Examples

Sample Exercise 1

Now that you have an understanding of subnetting, put this knowledge to use. In this example, you are given two address / mask combinations, written with the prefix/length notation, which have been assigned to two devices. Your task is to determine if these devices are on the same subnet or different subnets. You can do this by using the address and mask of each device to determine to which subnet each address belongs.

DeviceA: 172.16.17.30/20
DeviceB: 172.16.28.15/20

Determining the Subnet for DeviceA:

172.16.17.30  -   10101100.00010000.00010001.00011110
255.255.240.0 - 11111111.11111111.11110000.00000000
-----------------| sub|------------
subnet = 10101100.00010000.00010000.00000000 = 172.16.16.0

Looking at the address bits that have a corresponding mask bit set to one, and setting all the other address bits to zero (this is equivalent to performing a logical "AND" between the mask and address), shows you to which subnet this address belongs. In this case, DeviceA belongs to subnet 172.16.16.0.

Determining the Subnet for DeviceB:

172.16.28.15  -   10101100.00010000.00011100.00001111
255.255.240.0 - 11111111.11111111.11110000.00000000
-----------------| sub|------------
subnet = 10101100.00010000.00010000.00000000 = 172.16.16.0

From these determinations, DeviceA and DeviceB have addresses that are part of the same subnet.

Sample Exercise 2

Given the Class C network of 204.15.5.0/24, subnet the network in order to create the network in Figure 3 with the host requirements shown.

Figure 3

3c.gif

Looking at the network shown in Figure 3, you can see that you are required to create five subnets. The largest subnet must support 28 host addresses. Is this possible with a Class C network? and if so, then how?

You can start by looking at the subnet requirement. In order to create the five needed subnets you would need to use three bits from the Class C host bits. Two bits would only allow you four subnets (22).

Since you need three subnet bits, that leaves you with five bits for the host portion of the address. How many hosts does this support? 25 = 32 (30 usable). This meets the requirement.

Therefore you have determined that it is possible to create this network with a Class C network. An example of how you might assign the subnetworks is:

netA: 204.15.5.0/27      host address range 1 to 30
netB: 204.15.5.32/27 host address range 33 to 62
netC: 204.15.5.64/27 host address range 65 to 94
netD: 204.15.5.96/27 host address range 97 to 126
netE: 204.15.5.128/27 host address range 129 to 158

VLSM Example

In all of the previous examples of subnetting, notice that the same subnet mask was applied for all the subnets. This means that each subnet has the same number of available host addresses. You can need this in some cases, but, in most cases, having the same subnet mask for all subnets ends up wasting address space. For example, in the Sample Exercise 2 section, a class C network was split into eight equal-size subnets; however, each subnet did not utilize all available host addresses, which results in wasted address space. Figure 4 illustrates this wasted address space.

Figure 4

3d.gif

Figure 4 illustrates that of the subnets that are being used, NetA, NetC, and NetD have a lot of unused host address space. It is possible that this was a deliberate design accounting for future growth, but in many cases this is just wasted address space due to the fact that the same subnet mask is being used for all the subnets.

Variable Length Subnet Masks (VLSM) allows you to use different masks for each subnet, thereby using address space efficiently.

VLSM Example

Given the same network and requirements as in Sample Exercise 2 develop a subnetting scheme with the use of VLSM, given:

netA: must support 14 hosts
netB: must support 28 hosts
netC: must support 2 hosts
netD: must support 7 hosts
netE: must support 28 host

Determine what mask allows the required number of hosts.

netA: requires a /28 (255.255.255.240) mask to support 14 hosts
netB: requires a /27 (255.255.255.224) mask to support 28 hosts
netC: requires a /30 (255.255.255.252) mask to support 2 hosts
netD*: requires a /28 (255.255.255.240) mask to support 7 hosts
netE: requires a /27 (255.255.255.224) mask to support 28 hosts

* a /29 (255.255.255.248) would only allow 6 usable host addresses
therefore netD requires a /28 mask.

The easiest way to assign the subnets is to assign the largest first. For example, you can assign in this manner:

netB: 204.15.5.0/27  host address range 1 to 30
netE: 204.15.5.32/27 host address range 33 to 62
netA: 204.15.5.64/28 host address range 65 to 78
netD: 204.15.5.80/28 host address range 81 to 94
netC: 204.15.5.96/30 host address range 97 to 98

This can be graphically represented as shown in Figure 5:

Figure 5

3e.gif

Figure 5 illustrates how using VLSM helped save more than half of the address space.

CIDR

Classless Interdomain Routing (CIDR) was introduced to improve both address space utilization and routing scalability in the Internet. It was needed because of the rapid growth of the Internet and growth of the IP routing tables held in the Internet routers.

CIDR moves way from the traditional IP classes (Class A, Class B, Class C, and so on). In CIDR , an IP network is represented by a prefix, which is an IP address and some indication of the length of the mask. Length means the number of left-most contiguous mask bits that are set to one. So network 172.16.0.0 255.255.0.0 can be represented as 172.16.0.0/16. CIDR also depicts a more hierarchical Internet architecture, where each domain takes its IP addresses from a higher level. This allows for the summarization of the domains to be done at the higher level. For example, if an ISP owns network 172.16.0.0/16, then the ISP can offer 172.16.1.0/24, 172.16.2.0/24, and so on to customers. Yet, when advertising to other providers, the ISP only needs to advertise 172.16.0.0/16.

For more information on CIDR, see RFC 1518 leavingcisco.com and RFC 1519 leavingcisco.com.

Appendix

Sample Config

Routers A and B are connected via serial interface.

Router A

  hostname routera
!
ip routing
!
int e 0
ip address 172.16.50.1 255.255.255.0
!(subnet 50)
int e 1 ip address 172.16.55.1 255.255.255.0
!(subnet 55)
int t 0 ip address 172.16.60.1 255.255.255.0
!(subnet 60) int s 0
ip address 172.16.65.1 255.255.255.0 (subnet 65)
!S 0 connects to router B
router rip
network 172.16.0.0

Router B

  hostname routerb
!
ip routing
!
int e 0
ip address 192.1.10.200 255.255.255.240
!(subnet 192)
int e 1
ip address 192.1.10.66 255.255.255.240
!(subnet 64)
int s 0
ip address 172.16.65.2 (same subnet as router A's s 0)
!Int s 0 connects to router A
router rip
network 192.1.10.0
network 172.16.0.0

Host/Subnet Quantities Table

Class B                   Effective  Effective
# bits Mask Subnets Hosts
------- --------------- --------- ---------
1 255.255.128.0 2 32766
2 255.255.192.0 4 16382
3 255.255.224.0 8 8190
4 255.255.240.0 16 4094
5 255.255.248.0 32 2046
6 255.255.252.0 64 1022
7 255.255.254.0 128 510
8 255.255.255.0 256 254
9 255.255.255.128 512 126
10 255.255.255.192 1024 62
11 255.255.255.224 2048 30
12 255.255.255.240 4096 14
13 255.255.255.248 8192 6
14 255.255.255.252 16384 2

Class C Effective Effective
# bits Mask Subnets Hosts
------- --------------- --------- ---------
1 255.255.255.128 2 126
2 255.255.255.192 4 62
3 255.255.255.224 8 30
4 255.255.255.240 16 14
5 255.255.255.248 32 6
6 255.255.255.252 64 2


*Subnet all zeroes and all ones included. These
might not be supported on some legacy systems.
*Host all zeroes and all ones excluded.

NetPro Discussion Forums - Featured Conversations

Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the most recent conversations available in this technology.

novembre 05, 2009

- Cisco Networking: TelePresence

A practical deployment guide

-Introduction

This article describes a typical Cisco TelePresence deployment and its related services from a practical standpoint. Cisco TelePresence is a high-definition conferencing environment, designed for virtualizing meetings from units set up anywhere in the world, and requiring only a standard TCP/IP-enabled network infrastructure. Cisco TelePresence allows new forms of collaboration and human interconnection, in which employees can connect easily and instantly with coworkers, customers, partners and so on anywhere in the world without leaving the office. From a practical perspective, Cisco TelePresence is a solution that brings people together at the same table, in the same office, despite the usual barriers such as time of day and distance. It is one of the flagship products of Cisco's vision of Unified Communications, converging voice, video and data over the same well-known IP network infrastructure.

Cisco TelePresence for partners and Cisco TelePresence Services

With its unique methodology and design, the Cisco TelePresence solution exists in a world of its own, which therefore calls for a special approach to its deployment, brought to end companies by Cisco or Cisco Authorized Technology Provider (ATP) partners.

As with any complex technology that offers simplicity to the end user, in a Cisco-enabled TelePresence virtual collaboration, the solution hides the usually overwhelming (and, in most cases, utterly unimportant) background technology details behind the scenes of what the TelePresence “experience.” This is done by incorporating this technology in the industry’s well-known and widely accepted Cisco Lifecycle Services, in which the TelePresence solution has a corner of its own, ultimately falling under the Unified Communications vision of all-around managed services.

Figure 1:

Cisco Lifecycle Services

Focusing our discussion on service providers and Cisco ATP partners, which will be involved in Cisco TelePresence deployments internally, or for their respective customers, this article will continue through the Lifecycle Services mentioned earlier, giving advice and commenting on every necessary step and procedure for successful TelePresence deployment. A few goals are set in advance – customer or management satisfaction, effectiveness, timeliness, and bringing Cisco TelePresence to the face of the end user (for overall amazement).

We will bring these topics into focus from the point of view of the Cisco Certified Voice Professional (CCVP), and therefore we will stay on the engineering side of the Cisco TelePresence deployment.

Although Cisco defines TelePresence as part of the Lifecycle Services, one small difference sets this solution apart from the others: going one step further, Cisco defined another set of enhanced service offerings, named “Cisco TelePresence Services.” Cisco TelePresence Services encompasses these offerings:

Cisco TelePresence Planning, Design, and Implementation Service

Cisco TelePresence Essential Operate Service

Cisco TelePresence Remote Management Service

Cisco TelePresence Select Operate Service

Cisco TelePresence Remote Assistance Service

Cisco TelePresence Expert Access Service (only for the CTS 500 system)

No matter which of these services you offer as a Cisco TelePresence technology provider, you will have to master the details of bringing the immersive experience to your customers and end users.

Cisco TelePresence Planning, Design, and Implementation Service

As its name unmistakably declares, the Cisco TelePresence Planning, Design, and Implementation Service is concerned with the preparation, design and implementation of the Lifecycle Services framework, originally composed of the PPDIOO (Prepare, Plan, Design, Implement, Operate and Optimize) phases.

Note:

Depending on the number of sites on which the solution will be installed, you should be able to complete a multipoint Cisco TelePresence Planning, Design, and Implementation Service for a customer with three sites located no more than 1,000 miles apart in a time window of approximately 16 to 20 weeks.

Cisco TelePresence Planning, Design, and Implementation Service subdivides further into project milestones or services such as deliverables that you must present to the customer, in cooperation and timely agreement with the Cisco Project Manager (Cisco PM) and Customer Project Manager (Customer PM). In practice, these milestones or services consist of the following:

Project management

Customer Requirements Validation

TelePresence Facilities Qualification Assessment

TelePresence Network Path Qualification

Detailed Design Document development

Network Implementation Plan development and execution

Solution and site acceptance test plan development and execution (or Network Ready For Use [NRFU] document)

Conducting the site survey

Furniture and hardware installation

Administrator and end-user training

Project Management

Project management is conducted and under control of the Project Manager. The PM will be your designated single point of contact for all issues throughout the project cycle.

Note:

Build and maintain an excellent contact with your PM, as this person is responsible for the project schedule, along with certain background details that need to be covered and/or explained to the Customer PM.

For every issue that seems problematic or irresolvable, turn to your PM. Be prepared to explain technical or other details and to develop custom questionnaires and technical documents that the PM will later forward to your customer. In all these questionnaires or interim documents and correspondence that are not part of the official services cycle, be precise and very straightforward. Ask engineering questions, numbered and bulleted, with spaces indicating the expected answers. In 90% of all cases, the customer does not know anything about the technology you are using. Stress the final product of your efforts and be exact in explaining your engineering goals, which will be easily achievable if you have the necessary information.

Another important issue is just “being there” for your PM. As you will be delivering a complex solution (the Cisco TelePresence), you will have to cooperate with and update the PM on all matters. This may mean starting conferencing sessions a bit earlier than scheduled, with only your PM on the line, and adding the Customer PM and customer engineers later. This approach builds confidence, ensures preparedness, and eases decision-making and answering questions later, when the Customer PM joins the conversation. No matter what topic is discussed, you will update all information with your PM and present yourselves as a winning team, ready to answer any question.

Your readiness and engineering knowledge will inevitably be tested with the first meeting – the project kickoff. Officially the “milestone definer,” the project kickoff meeting is your first direct contact with the people for whom you will be installing the Cisco TelePresence solution. First impressions count, so be ready to interact with the customer’s senior networking engineers. Expect to be asked everything from the normal (“What impact will the TelePresence solution have on my network bandwidth?”) to the unusual (“Who will unload the lorries with the equipment?”).

In the project kickoff meeting, you will have the chance to show off all your technical and engineering knowledge of the Cisco TelePresence solution and to connect it with much broader topics, such as security, routing and switching, and end-user or administration training. In this meeting you will be expected to answer questions precisely and correctly, so be swift and focused with your answers and explanations. Take your time with issues that warrant extra discussion, but keep the room’s interest at a desirable level.

Customer Requirements Validation

The next step in the Cisco TelePresence Planning, Design, and Implementation Service is the Customer Requirements Validation. This is the turning point of this phase, which inevitably differentiates between successful and less successful (or unsuccessful) project completions.

In this phase, you will gather customer-supplied documentation and/or conduct interviews with designated customer representatives, with the goal of learning essential features/functionality, as well as requirements for immersive conferencing experiences that pertain to the TelePresence solution. This means putting together the Detailed Design Document up front – knowing its main building points, and filling the document structure with the proper information that you will obtain through the Customer Requirements Validation. Directly connected with the Detailed Design Document, the Customer Requirements Validation builds from the recommendations for TelePresence network design and best practices of former TelePresence projects.

At minimum, you will need to obtain details from the customer about the following systems and documents:

LAN/WAN network architecture details

Network infrastructure connectivity

Call Manager design

Call Admission Control

Dial plan requirements

Redundancy

Directory access and integration

QoS details

Service capabilities and SLA

You need the LAN/WAN infrastructure details for a proper design of the TelePresence Quality of Service (QoS) traffic requirements, router and switch processing power, and connectivity details. Finding out the type of LAN/WAN devices and their interconnectivity will also define the planned redundancy in the core network, for the TelePresence solution and all servers. In practice, these steps depend heavily on whether the WAN network is owned by the customer or you are interconnecting the TelePresence endpoints through a service provider’s leased service. In the latter case, obtaining a proper service-level agreement (SLA) and service capabilities is of the outmost importance.

As part of the Unified Communications portfolio, the Cisco TelePresence solution is an endpoint that registers with the Cisco Unified Communications Manager or Call Manager, which functions as a back-to-back user agent between the TelePresence endpoints. It’s crucial to know your customer’s Call Manager implementation and design (such as the cluster where you will add the TelePresence endpoints), version, licensing requirements, and the Call Admission Control implementation.

Here’s a simple example to show how important it is that you have all of this background information. Suppose the Call Manager’s regions construct for enforcing Call Admission Control is set at the same value used to define Cisco Unified IP Phones. This would certainly lead to erratic behavior when you add the TelePresence endpoints to these predefined locations. The same cautious approach should be used when implementing the endpoint numbering and partition/calling search space details. Putting the TelePresence endpoints in partitions and assigning calling search spaces not privileged enough to reach these partitions could lead to absence of connectivity – for one of the most awkward reasons possible. Similar problems could emerge if the customer’s directory access and integration solution is not taken into account. Always remember to follow the compatibility matrices information, detailing versions and compatibility between third-party products and the Cisco TelePresence solution.

Armed with this priceless knowledge, you will be ready to integrate the TelePresence solution with the customer’s existing Unified Communications endpoints.

Note:

In case many IP phones are already deployed, a general rule is to devise a strategy of adding a new Cisco Unified Communications Manager cluster, designed in 1:1 or 2:1 redundancy, for the new TelePresence endpoints. This new cluster will interconnect with the existing one through an intercluster trunk.

Facilities Qualification Assessment

Assessing the facilities to determine whether they’re qualified for TelePresence could easily be your first personal contact with the customer. This step of the Cisco TelePresence Planning, Design, and Implementation Service might spotlight your practical knowledge and experience from past projects.

As part of the assessment, verify that the customer’s specified facility locations conform to Cisco requirements. Note all of the following:

Physical room dimensions

Door locations

Lighting

Windows position

AC power

Room acoustic characteristics

Network infrastructure connectivity

Be prepared to look at architectural blueprints, discuss possible solutions with architects or construction engineers, and try to be influential in the decision-making process. With regard to the room’s physical dimensions and properties, take a stand and be prepared to defend it with arguments and reasons. In many situations, an inadequate solution for TelePresence rooms will be given as the only possible solution.

Note:

Your responsibility is an installation in appropriate accommodations, without undesirable conditions such as noise, echo, outdoor sunlight, or unbearable room temperature at half an hour into the meeting.

Changing the arrangements is easier at this early stage of the project than at any later point, and your practical suggestions probably will be welcomed. Keep an open mind and collaborate with site architects. Often, it is possible to turn a dead-end option into a “by the book” solution just by applying a few touches or rotating a TelePresence endpoint. Adhering strictly to Cisco-specified requirements also may be too rigid a stance. You have to try to satisfy both sides, remembering that the Cisco TelePresence conference rooms are part of and also identify the corporate environment.

Note:

Allow the customer to make changes in the room, as long as acoustics, lighting, power, and network requirements are not affected.

Present all the different ranges and possibilities that Cisco supports for color and room design. Many of these options were extracted from real-life corporate environments. By working together, you will eventually find room patterns that satisfy TelePresence engineering needs as well as the customer’s taste in décor.

Throughout all these efforts, stress continuity of the TelePresence endpoint rooms. Room remediation is a prerequisite only for the Cisco TelePresence 3000 and 3200 systems, but that does not mean that you can just deploy the Cisco TelePresence 500, 1000, and 1300 systems wherever you like.

Note:

As a practical rule, the more you follow the prerequisites and requirements, the less risk is involved for implementing the Cisco TelePresence Planning, Design, and Implementation Service.

Figure 2:

Cisco TelePresence 500

Figure 3:

Cisco TelePresence 1000

Figure 4:

Cisco TelePresence 1300

Figure 5:

Cisco TelePresence 3000

Figure 6:

Cisco TelePresence 3200

TelePresence Network Path Qualification

The TelePresence Network Path Qualification identifies appropriate network paths between TelePresence site pairs and performs analysis on the site-to-site link to determine its compliance with requirements to support video, audio and signaling traffic, based on Cisco Unified Communications TelePresence network design requirements. Your engineering knowledge is put to the test in this step, as routing and switching, MPLS and MPLS VPNs are the most widely used high-speed WAN connections today. Especially important, but often set aside or not taken into account, are the quality of service (QoS) requirements for real-time video traffic such as the TelePresence.

At this point, you will be able to limit the number of possible paths traversing the network and carrying TelePresence traffic, simply by stating and discussing TelePresence network requirements for your respective departments or customers. In more than 90% of all cases, WAN department engineers know the paths that conform to network requirements by heart. For us, this differentiation is just the beginning of the TelePresence Network Path Qualification process.

If your customer or internal WAN network connectivity department defines the candidate paths, it is still up to you to perform the site-to-site data-link path capture, which must include the following:

bandwidth

delay

jitter

packet loss

Note:

Earlier, flexibility toward the customer could be respected and even be a virtue. The opposite is true during the TelePresence Facilities Qualification Assessment; you must strictly follow best practices and requirements.

If some of the equipment along the proposed TelePresence traffic network path does not fall within the recommended limits, escalate an immediate issue with your PM and Customer PM. All measurements need to be completed during a longer period or, for practical reasons, a valid time of approximately one week. Take special care when analyzing this data, watching for busy hour call attempts, network load and the parameters of bandwidth, delay, jitter and packet loss stated above.

Performance load-testing on the site-to-site links should be conducted using Cisco and/or third-party tools. Our recommendation is to use the Video SLA Assessment Agent (VSAA) tool that measures service-level agreement (SLA) metrics on network paths. This application utilizes actual TelePresence traffic profiles, making it faster and more efficient to collect network SLA metrics for your reports. Another possibility is to use routers and IP SLA commands embedded in the Cisco IOS. Yet another option is to take customer-provided or department-provided data, from internally deployed network monitoring and management systems.

We can easily argue at this point that all these options work only if the customer or department owns the WAN network. If service is leased from a service provider, a well-defined and precise SLA will have to be in place for successful completion of the TelePresence Network Path Qualification. Service-level agreements are burdened with legal vocabulary and items defining contract signers’ rights and privileges. In practice, you must rise above legal issues and see the real background of the SLA, extracting what is most important – the actual values and numbers for the TelePresence network quality attributes.

Detailed Design Document Development

The final result of all your previously described efforts comes in the shape of a Detailed Design Document (DDD). In this stage, the TelePresence certified engineer reviews all previously compiled documents and requirements.

The DDD is the crown jewel of all your work up to this moment. In most cases, building the DDD is a demanding activity. Do not skip through this document, thinking that some topics are very well known and you can put that information to good use at the time of implementation. Someone other than you might be setting up the system, or details you know now may slip from your mind at implementation. The Detailed Design Document is your only reference during the implementation stage at the customer’s premises. If you cannot rely on the information it contains, or the DDD lacks detail, the implementation will take longer – or may even fail.

The Detailed Design Document should include at least the following information:

IP addressing

LAN/WAN configuration to accommodate TelePresence video, audio and signaling traffic

QoS configuration with policing for LAN/WAN

Network services such as DHCP, DNS, TFTP or NAT that relate to the TelePresence solution

Power, network and physical environment requirements

Service provider integration

The Detailed Design Document must state in detail the architectural scope of the solution you will be implementing, define the current deployment plan, draw the current network topology with Cisco and third-party equipment to be deployed, and even design the solution to allow for future expansion of the original configuration, such as adding interoperability with other conferencing systems.

The Detailed Design Document will also encompass the Cisco Unified Communications Manager, Cisco TelePresence Multipoint Switch and Cisco TelePresence Manager deployment and design details. For the Cisco Unified Communications Manager, you will define server designation, services, groups, time zone configuration, regions, locations, device pools, dial plan and TelePresence endpoint configuration with the user interface – the Cisco Unified 7975G IP Phone. Best practice is to equip these subheadings with snapshots and figure materials for better understanding and familiarity.

Figure 7:

Cisco Unified 7970G IP Phone

Special considerations are necessary when defining the Cisco TelePresence Manager configuration and details. As this is the only interface to a third party product – a Microsoft Exchange or IBM Lotus Domino Server – it is very important for the integration to be defined clearly and precisely, with all configuration steps on both sides.

Note:

You will be expected to work closely with the directory administrator when defining the details of the room service accounts, AD integration and scheduling interfaces that end users will use when setting up new conferencing sessions.

This is the part of the Detailed Design Document where you can expect problems in practice, as it depends on more than just your skills. That is why you have to be prepared to define the integration in the Detailed Design Document, and request this information to be reviewed (and corrected, if necessary) by the directory administrator.

Network Implementation Plan Development

Having the proper information in the Detailed Design Document in your hands is invaluable and represents your starting point at the next step of the Cisco TelePresence Planning, Design and Implementation Service – the Network Implementation Plan (NIP) development.

The Network Implementation Plan details the information required to perform implementation of TelePresence network equipment, software and application configuration at end-customer sites. You have to write this document as a guide for engineers to assemble, install and configure the solution. These engineers must have experience with installation, configuration and troubleshooting of the products covered. Be careful writing this document, as you will have to gather information on site-specific contacts, locations, special considerations and installation requirements, as well as site-specific information from the Bill of Materials (BOM) and logistics for delivery of equipment for installation. Many of these tasks should be scheduled and completed before the physical assembly of the TelePresence endpoints.

Figure 8:

Network Implementation Plan Workflow Chart

The main focus of the Network Implementation Plan development is a workflow chart highlighting the planning and implementation flow that you will follow with the customer during the implementation. This is a typical phased approach with all dependencies noted and addressed. This step requires a plethora of additional documents:

Detailed Design Document

Site Survey Checklist

Cisco TelePresence Tool List

Cisco TelePresence System Administrator’s Guide

Troubleshooting the Cisco TelePresence System

Cisco TelePresence Manager Installation Guide

Cisco Unified Communications Manager Installation Guide for the Cisco TelePresence System

Cisco TelePresence 3000/1000/1300/500 Assembly, Use & Care and Field Replacement Unit Guide

Cisco TelePresence Multipoint Switch Administration Guide

Solution and Site Acceptance Test Plan

The Solution and Site Acceptance Test Plan that you compile in this step will be used subsequent to implementation to verify that the Unified Communications TelePresence system as implemented meets customer solution and site requirements as well as the requirements defined and developed in the Detailed Design Document, and that each site and the entire solution are certified as ready for the production environment.

The Solution and Site Acceptance Test Plan development actually consists of a few sets of tests carried out in two distinctive phases:

System verification

Room verification

The system verification phase is further broken down into call scheduling, call handling and call duration; the room verification is broken down into sound/acoustics and HDTV verification.

Note:

As these tests are completed before the Customer PM and your PM, it is very important to conduct and prepare for them at least one day in advance.

The expected duration of the TelePresence system tests is one working day.

Conduct Site Survey

Before the hardware implementation, the Conduct Site Survey step’s purpose is to survey and document each location where physical equipment will be installed as part of the proposed solution.

The site survey focuses on requirements for the following:

Space

Cabling

Conduits

Racks

Patch panels

Power

Heating, ventilation and air conditioning

This Conduct Site Survey step is directly connected with all possible logistics that you need to know before a successful implementation.

Furniture and Hardware Installation

After preparing for the implementation with all the information you gathered in the Conduct Site Survey step, you are ready to install the furniture and hardware.

Note:

A practical rule is to allow up to five working days for Cisco TelePresence 3000 and Cisco TelePresence 3200 endpoints, and up to three days for Cisco TelePresence 1300, 1000 or 500 endpoints.

The furniture and hardware installation for the endpoint is more handyman work than actual engineering.

Figure 9:

Furniture and hardware installation in progress

This physical part of the implementation requires good fitness and a practical approach to putting the equipment together in a timely fashion. Be ready to solve problems of moving objects into and out of elevators and leveling easily and quickly. Keep in mind that Cisco TelePresence equipment is heavy and assembly is demanding, especially for the plasma displays. Engineers will need special tools, protective knee pads, and tool belts for successful furniture and hardware installation.

Administration and End-User Training

The final step, training the administrator and end users, provides end-customer system administrators with knowledge about administration and usage of the TelePresence solution. Prepare the presentation with no more than 60 to 70 slides covering all aspects of the TelePresence system. Knowledge-transfer training takes place at the main location, where the TelePresence Manager server resides, and is expected to require no longer than 2–3 hours.

Note:

Stay relaxed during this session, ready to answer and give explanations for every question asked.

Conclusion

With the previous step concluded, this discussion of the Cisco TelePresence Planning, Design, and Implementation Service is complete.

novembre 03, 2009

- Windows 7: Seven Wonders of Windows 7

The number seven denotes grandeur, as with the Seven Wonders of the Ancient World. It's shouldn't come as a surprise, then, that following the Windows Vista debacle, Microsoft chose to return to a numerical naming system for the next version of Windows. But if Microsoft is going to impress users with Windows 7, it's going to have to do it with features and functionality, not just with a name. So, what amazing new capabilities await users in the latest -- and perhaps most complete -- client version of Windows ever? Here's a look at seven of the wonders of Windows 7.

1. Onboard PowerShell Version 2.0
While the typical user may not know what to do with Windows PowerShell just yet, IT is seeing the strength this tool gives them on the server level. With PowerShell now on the desktop comes the ability to perform remoting. Using WS-Management, users can employ cmdlets and scripting on literally hundreds of remote systems by fanning out remote commands. As a result, IT managers can use PowerShell commands to monitor or maintain systems, collect data, run scripts, distribute necessary updates and enforce changes uniformly on multiple systems. PowerShell remoting is like using Remote Desktop at the command-line level. One of the coolest factors it offers is that remote users don't even know a command is running -- unlike with Remote Desktop, which takes control of a system -- because PowerShell remoting runs the command or script in a hidden window.

2. AppLocker
Microsoft introduced Software Restriction Policies (SRP) in Windows XP and Windows Server 2003 as a means for identifying and controlling which applications can run on a system. XP and Server 2003 enforced those policies using a variety of simple factors, such as file names, path locations and hash calculations. Although SRP is generally a force for good in the world of network control, Windows 7 and Windows Server 2008 R2 replace it and provide new levels of control that can help protect a company's environment. Mark Russinovich, technical fellow in the Platform and Services division at Microsoft, has called AppLocker SRP "on steroids."

Through Group Policy or the Local Security Policy, IT managers can create rules and exceptions with a simple slider that allows them to dial up or down (up being more lenient, down being stricter) the level of network control.

3. Navigation Enhancements
Anything that allows users to perform work more easily is worth mentioning. The Instant Search feature, which first appeared in Vista, is an excellent time-saving feature.

Windows 7 follows up on that with Jump Lists. Jump Lists will become a staple to the navigation of pinned taskbar applications and open applications. The ability to quickly access recent Web sites or documents, or open an application directly to the appropriate mode through the taskbar or the start menu, is very helpful.

4. The Action Center
At first glance, Windows 7 users might think, "Isn't this just the Security Center with a new name?" In fact, the Action Center is a combination of both security and maintenance information as well as configuration options. The user not only sees security statistics such as virus protection, malware protection and updates, but also maintenance status, including backups and available drivers (see Figure 1).


Figure 1. The Windows 7 Action Center.

It's from within the Action Center that a user locates the User Account Control (UAC) slider. Users can also alter the Action Center settings; that allows you to turn on and off both security and maintenance messages. Users will never again have to deal with messages about not having anti-virus software installed.

In addition, under the maintenance settings, users can locate the link "view reliability history," which will take them to the Reliability Monitor. New in Vista, Microsoft originally combined the Reliability Monitor with the Performance Monitor. However, in Windows 7 the Reliability Monitor is now its own separate tool, and it's located in the Action Center.

5. The Problem-Steps Recorder
Remote Assistance is an incredible feature for assisting users online. Windows 7 offers a new twist on Remote Assistance with a feature called Easy Connect. Remote Desktop, though typically a tool one might use for working remotely, is also a good for remote diagnosis. There's also the problem-steps recorder, an easy-to-use application that lets users troubleshoot problems without having to be live online. The person with a problem turns on the recorder by typing "PSR" in the Instant Search option of the Start Menu, and proceeds to re-create the problem. Once the user with the problem stops the recording, the problem-steps recorder puts together a .ZIP file with an MHTML report of the step-by-step actions and screenshots that the user took. That user can then e-mail the file to an IT manager, who can diagnose the problem when he has the time.

Windows Live Applications

While Windows 7 still offers integrated Internet Explorer, Media Player, Media Center and DVD Maker, some applications have moved out of the OS and into a separate Windows Live Essentials download package. (One of the interesting things about Windows 7 is that users can go to the Programs and Features applet through Control Panel and remove preinstalled applications, including IE.) Users can pick and choose from among the applications, which will install on systems running Windows XP Service Pack 2 or Windows Vista, as well as Windows 7. At press time, these applications include the following:

-Live Messenger: This tool is for sending instant messages to contacts or groups, playing games, sharing pictures during a chat and keeping up to date on what's new with friends and colleagues.

-Live Mail: This provides access to one or multiple e-mail accounts within one program, while also providing newsgroups, feeds and a calendar. Through a Windows Live account users can maintain and view their calendars online and see when messenger contacts are available to chat.

-Live Photo Gallery: Here, users can edit, view, organize and share photos. It's possible to tag people in photos and stitch pictures together into panoramas.

-Live Toolbar: When added to IE, this toolbar gives at-a-glance access to Windows Live Hotmail, photos, calendars and more.

-Live Writer: This application lets users create formatted blog posts, including photos, videos, maps, events and tags, and publish them to almost any blog service, including Windows Live, WordPress, Blogger, Live Journal and TypePad.

-Live Family: Safety Taking Parental Control to a new, online level, this provides control of how kids experience the Internet. Users can block or allow certain Web sites and contacts and monitor through activity logging where their kids are going online.

-Live Movie Maker: This lets users add and arrange video clips and photos, add a soundtrack, preview a movie and then publish the results to any of several popular video sites.

Additional items for download include the Microsoft Office Outlook Connector, the Office Live Add-in and Microsoft Silverlight.


6. BranchCache
The purpose of BranchCache is to improve the speed with which users can obtain data from a remote location when working from a branch office with a slow or over-utilized WAN connection. When a Windows 7 client at a branch location accesses content that's stored on a Windows Server 2008 R2 system, Windows 7 can locally cache a copy of the data accessed, either from an intranet site or from a file server. This reduces the wait time for other branch-office users accessing the same data. When the next user attempts to access the same information, the access is near immediate.

BranchCache can work in one of two modes: Distributed Cache, where the Windows 7 clients retain the copies in a peer-to-peer architecture, which prevents the need for a server to be located at the branch location, or Hosted Cache, where a branch-located server retains a copy of the data.

7. Windows Explorer Enhancements
Vista users who open a Windows 7 Explorer window aren't likely to immediately see this "wonder." They may notice the new Show/Hide Preview Pane button in the top right-hand corner, along with a new location for the Views option. Upon first glance, users may not catch the concept of Libraries. And unless they've installed a Federated Search connector, users won't notice the ability to search Flickr, for example, from within Windows Explorer.

Starting with Libraries, Windows has preconfigured libraries for documents, music, pictures and videos. By opening the Document Library (see Figure 2), users see that the data in that library is actually aggregated from two folders: My Documents and Public Documents. Users can add others, too.


Figure 2. The Windows 7 Document Library.

In creating a new library, users have the ability to aggregate an unlimited number of folders and then optimize the library for storage of different types of files: music, videos, pictures and so on. With the current rate of desktop data sprawl coming from multiple sources -- e-mail, downloads, digital cameras and the like -- users need a way to organize that data. The Libraries feature is easy to use and works well. One handy feature is that a user can delete a library without having to worry about deleting any of the data stored in it. The data is in folders, but the library is just a view of that data coming from multiple sources.

Windows 7: Complete
Windows 7 certainly feels complete, and, indeed, Microsoft released it to manufacturing in July and will make it generally available next month. The new OS appears to be one that will calm the Vista critics and please users. Will wonders never cease?