Archive for November, 2009

Dial-Peers, Part 2

Last post we looked at dial-peers and the syntax that is needed to address endpoints.  In this segment I want to explore the concept of creating destination-pattern that would be used on H.323 or SIP gateways to forward a call out of a POTS (Plain old Telephone System) port to the PSTN.  In order to accomplish this, we will need to use variables to represent numbers that can be reached.

The possible variables that could be used are:

. — represents a single number position in which the range of numbers would be 0 through 9 including # and *.

, — this is used for pausing before dialing additional digits

[ ] — used to indicate a range of numbers in which only one single digit is matched from this range. For instance [02-9] would match the following possibilities, 0 2 3 4 5 6 7 8 and 9.  Notice in the example 1 is not included in the range.

[^ ] — this is used to indicate an exclusion range of numbers. For instance [^289] would match 0 1 8 and 9 since it is not part of this exclusion range.  Exclusions are rarely used in destination-patterns to match numbers.

? — Indicates that the preceding digit occurred zero or one time. It is important to remember to enter ctrl-v before entering ? from your keyboard.

% — value is used to indicate the preceding digit occurred zero or more times. This functions the same as the “*” used in regular expression.

+ — Indicates that the preceding digit occurred one or more times.

T — Indicates the interdigit timeout. The router pauses to collect additional dialed digits.

Now let’s see how we can build destination patterns with these variable types to represent the NANP (North American Numbering Plan).

First, we want to include all the service codes within the NANP which would be 211 311 411 511 611 711 811 and 911.  The pattern on the gateway would be [2-9]11.

For seven digit dialing sequence we would include potentially two patterns:

[2-9][02-9]….. and [2-9].[02-9]…. the purpose behind this is not to overlap static emergency numbers that are set in the dial-plan being 911 and 9911.  The second statement would use a trunk access code of 9 if used.

For 10 digit local dialing we would simply add the area code directly. So for the San Diego Area, two patterns would look like:  619[2-9]…… and 858[2-9]…… the reason for [2-9] at the beginning of the NANP prefix is making sure the rule that the area code or prefix cannot begin with a 0 or 1.  0 would indicate operator request and 1 for long distance service.

For long distance you would use  1[2-9]..[2-9]…… making sure you included enough . to build a total of 11 digits.

The last pattern will be used to call countries with varying dial-plan lengths like Europe.  This would look like: 011T in which ‘011′ is the North American request for international access and the T would keep collecting digits until the interdigit timer would go into effect which would be approximately 10 seconds for most gateways.

Next blog we will address incoming versus outgoing dial-peers and how it is used to bring up call legs.

Author: Joe Parlas

References:
Variables used with destination patterns

 

OSPF, Part 5

In our previous discussion, we saw that dividing an OSPF autonomous system into multiple areas can improve the scalability. An example of a multi-area OSPF topology is shown in Figure 1:

Let’s imagine that we’ve allocated the IP address space as follows:

  • Area 0: 10.0.0.0/24 through 10.0.255.0/24 (256 subnets)
  • Area 1: 10.1.0.0/24 through 10.1.255.0/24 (256 subnets)
  • Area 2: 10.2.0.0/24 through 10.2.255.0/24 (256 subnets)

Our OSPF autonomous system contains a total of 768 subnets, and unless we prevent it, each subnet will be known by every router. With a little configuration, however, we can do much better. As you can see, the subnets within the areas fall into three blocks:

  • Area 0: 10.0.0.0/16
  • Area 1: 10.1.0.0/16
  • Area 2: 10.2.0.0/16

What we can do is configure the ABRs (R2 and R4) so that instead of advertising each individual prefix from one area to another, they will instead advertise summary blocks. For example, we will configure R2 to advertise the 10.1.0.0/16 block from Area 1 into Area 0, and likewise the 10.0.0.0/16 block from Area 0 to Area 1. Similarly, we’ll have R4 advertise the 10.2.0.0/16 block from Area 2 into Area 0, and the 10.0.0.0/16 block from Area 0 into Area 2. What will be the result?

Each internal router (R1, R3 and R5) has the LSDB for its particular area, and running SPF will send that area’s prefixes into its routing table. Thus, for the prefixes within their respective areas, the internal routers see things as follows:

  • R1: 10.1.0.0/25 through 10.1.255.0/24 (the 256 subnets in Area 1)
  • R3: 10.0.0.0/25 through 10.0.255.0/24 (the 256 subnets in Area 0)
  • R5: 10.2.0.0/25 through 10.2.255.0/24 (the 256 subnets in Area 2)

Being an ABR, R2 will have the LSDB for both Area 2 and Area 0, and therefore will see 512 prefixes total for those two areas. Likewise, R4, the ABR connecting Area 2 to Area 0, will also see 512 prefixes for those areas.

In addition, since the ABRs are advertising the blocks of subnets from one area to another, each router will see one prefix for each area to which it is not directly connected. Therefore, the total numbers of prefixes known to the routers will be:

  • R1: 258 prefixes (256 for Area 1, summaries for Area 0 and Area 2)
  • R2: 513 prefixes (256 for Area 1, 256 for Area 0, summary for Area 2)
  • R3: 258 prefixes (256 for Area 0, summaries for Area 1 and Area 2)
  • R4: 513 prefixes (256 for Area 2, 256 for Area 0, summary for Area 1)
  • R5: 258 prefixes (256 for Area 2, summaries for Area 0 and Area 1)

In the case of the internal routers (R1, R3 and R5), the routing tables have gone from 768 to 258 entries, a reduction of nearly two-thirds. In the case of the ABRs (R2 and R4), the number of routing tables has gone from 768 to 513, a reduction of nearly one-third. As you can imagine, as the total number of subnets goes up, the savings that can be realized by using multiple areas becomes even greater.

Since OSPF area numbers are thirty-two bit variables, they can be represented in dotted-decimal format, which can sometimes be convenient. For example, instead of numbering our areas 0, 1 and 2, we could make them Area 0.0.0.0, Area 10.1.0.0, and Area 10.2.0.0, deriving the area numbers from the IP address ranges within them.

What about Area 0, which contains the 10.0.0.0/16 block? Can we make that Area 10.0.0.0, then? No, because there are some rules we must follow when it comes to multiple areas.

  • First, if we have more than one area, one of them must be Area 0 (or Area 0.0.0.0, if you prefer).
  • Also, unless special arrangements are made, the topology of an OSPF autonomous system must be a simple hub-and-spoke, with Area 0 (the backbone) in the middle.
  • One last thing … we can’t run a link directly from Area 1 to Area 2, bypassing Area 0, because OSPF won’t like that at all!

There are additional rules and options, some of which we’ll discuss in the next installment.

Author: Al Friebe

IPv6 Transition Methods

The true transition of the global Internet from IPv4 to IPv6 is expected to span many years. And, during this period of transition, many organizations introducing IPv6 into their infrastructure will support both IPv4 and IPv6 concurrently. There is not a one-size-fits-all transition strategy for IPv6. The incremental, phased approach allows for a significant period where IPv4 and IPv6 can co-exist using one or more transition mechanisms to ensure interoperability between the two protocol suites. The most often-used methods of performing this transition is by operating in a dual-stack environment, or by using tunneling and translation between the two versions of Internet Protocol (IP).

IPv4/IPv6 Dual Stacks
Because IPv6 represents a conservative extension of IPv4, it is relatively easy to write a network stack that supports both IPv4 and IPv6 while sharing most of the code. Such an implementation is called a dual stack, and a host implementing a dual stack is called a dual-stack host.

The term “dual stack” means that the host or router uses both IPv4 and IPv6 at the same time. For hosts, this means that the host has both an IPv4 and IPv6 address associated with each Network Interface Card (NIC), and that the host can send IPv4 packets to other IPv4 hosts, and that the host can send IPv6 packets to other IPv6 hosts. For routers, it means that in addition to the usual IPv4 IP addresses and routing protocols, the routers would also have IPv6 addresses and routing protocols configured. To support both IPv4 and IPv6 hosts, the router could then receive and forward both IPv4 packets and IPv6 packets.

The dual stack approach can be a reasonable plan of attack to migrate an enterprise to IPv6 for communications inside the enterprise. The routers could be easily migrated to use dual stacks and today most desktop operating systems (OS) support IPv6. In some cases, the upgrade may require new software or hardware, and these conditions could cause a slower migration schedule. This situation is not necessarily a bad thing because a support staff could require additional time to learn how IPv6 works.

There are a number of factors that will affect the success and duration of the transition process. At the top of that list is training. IPv6, while built on many of the fundamental principles of IPv4, is different enough that most IT personnel will require formalized training. The level of training required will vary and depend upon the role a member of the organization’s IT staff plays in developing, deploying, and supporting IPv6 integration. (Check out this post discussing training issues for more on this).

Tunneling
The term tunneling refers to a means to encapsulate one version of IP in another so the packets can be sent over a backbone that does not support the encapsulated IP version. For example, when two isolated IPv6 networks need to communicate over an IPv4 network, dual-stack routers at the network edges can be used to set up a tunnel that encapsulates the IPv6 packets within IPv4, enabling the IPv6 systems to communicate without having to upgrade the IPv4 network infrastructure that exists between the networks.

Several types of IPv6-to-IPv4 tunnels exist. Three of the following types of tunnels are used by routers, where the fourth type (Teredo) is used by hosts.

  • Manually Configured Tunnels (MCT): This is a simple configuration in which tunnel interfaces, which are a type of virtual router interface, are created with the configuration referencing the IPv4 addresses used in the IPv4 header that encapsulates the IPv6 packet. Manually configured tunneling is used when network administrators manually configure the tunnel within the endpoint routers at each end of the tunnel, and is usually more deterministic and easier to debug than automatic tunneling, and is therefore recommended for large, well-administered networks. Any changes to the network, like renumbering, must be manually reflected on the tunnel endpoint. Tunnels result in additional IP header overhead because they encapsulate IPv6 packets within IPv4 (or vice versa).
  • Dynamic 6to4 Tunnels: This term refers to a specific type of dynamically created tunnel, typically done on the IPv4 Internet in which the IPv4 addresses of the tunnel endpoints can be dynamically found, based on the destination IPv6 address.
  • Intra-site Automatic Tunnel Addressing Protocol (ISATAP): ISATAP is another dynamic tunneling method, typically used inside an enterprise. ISATAP treats the IPv4 network as a virtual IPv6 local link, with mappings from each IPv4 address to a link-local IPv6 address. Unlike 6to4 and Teredo, which are inter-site tunneling mechanisms, ISATAP is an intra-site mechanism, meaning that it is designed to provide IPv6 connectivity between nodes within a single organization.
  • Teredo Tunneling: Teredo is a tunneling protocol designed to grant IPv6 connectivity to nodes that are located behind IPv6-unaware NAT devices. It defines a way of encapsulating IPv6 packets within IPv4 UDP datagrams that can be routed through NAT devices and on the IPv4 Internet. Many hosts are currently attached to the IPv4 Internet through one or several NAT devices, usually because of an IPv4 address shortage. In such a situation, the only available public IPv4 address is assigned to the NAT device, and the 6to4 tunnel endpoint needs to be implemented on the NAT device itself. Many NAT devices currently deployed, however, cannot be upgraded to implement 6to4 for technical or economic reasons.

    Teredo alleviates this problem by encapsulating IPv6 packets within UDP/IPv4 datagrams, which most NATs can forward properly. Thus, IPv6-aware hosts behind NATs can be used as Teredo-tunnel endpoints even when they don’t have a dedicated public IPv4 address. In effect, a host that implements Teredo can gain IPv6 connectivity with no cooperation from the local network environment.

Translating Between IPv4 and IPv6 with NAT-PT
Both classes of IPv6 transition features so far discussed-dual stack and tunnels-rely on the end hosts to at least support IPv6, if not both IPv4 and IPv6. However, in some cases, an IPv4-only host needs to communicate with an IPv6-only host. A third class of transition features need to be used in this case: a tool that translates the headers of an IPv6 packet to look like an IPv4 packet, and vice versa.

In Cisco routers, Network Address Translation-Protocol Translation (NAT-PT), which is defined in RFC 2766, can be used to perform the translation. To do its work, a router configured with NAT-PT must know what IPv6 address to translate to which IPv4 address and vice versa. This is the same kind of information held in the traditional NAT translation table. And, like traditional NAT, NAT-PT allows static definition, dynamic NAT, and dynamic PAT, which can be used to conserve IPv4 addresses.

As indicated previously, NAT-PT is defined in RFC 2766, but due to numerous problems it has been made obselete by RFC 4966 and deprecated to historic status. It is typically used in conjunction with a DNS Application-Level Gateway (DNS-ALG) implementation.

While almost identical to NAT-PT, Network Address Port Translation + Protocol Translation, which is also described in RFC 2766, adds translation of the ports as well as the address. This is done primarily to avoid two hosts on one side of the mechanism from using the same exposed port on the other side of the mechanism, which could cause application instability or security flaws.

As a final note, to support IPv6, all of the routing protocols had to go through varying degrees of changes, with the most obvious being that each had to be changed to support longer addresses and prefixes.

Author: David Stahl

Cisco Dial Peers, Part 1

Cisco Unified Communication H.323 and SIP gateways will require a dial plan on those gateways to extend calls to endpoints that may be configured. An endpoint may be either an analog or digital voice port that would provide connections to the public switch telephone (PSTN) network or to traditional private branch exchange (PBX) phone switches.

The dial plan configuration uses a construct called “dial peers” and is used on gateways to create, control, or re-direct what is called a call leg. The formal definition of a dial peer is “addressing endpoints” which reside on gateways. The command structure begins in configuration mode on a Cisco Voice Gateway using the following syntax:

Dial-peer voice {tag} {Pots, VOIP}

When using the above statement you must use a numerical tag value that uniquely defines one dial peer from another. The range of the tag values is from 1 to 2147483647. If the endpoint is a phone or fax station, it is not uncommon to use a tag that represents the number dialed to reach that station.

Finally, you need to define the type of endpoint being declared on your first dial-peer statement. Normally the types of dial-peers that one would normally create is POTS and VOIP. The POTS dial-peer type would point to a POTS (Plain Old Telephone System) port that is configured on the gateway itself. A VOIP dial-peer type would point to a Voice Over IP target like another gateway in which a POTS port has been defined.

An example of POTS dial-peer would be on the San Jose Gateway for Phone A would be:

SanJose (Config t) Dial-Peer voice 1 POTS
destination-pattern 4552468
port 1/0/1

Now if you want to setup a call to Raleigh gateway (assuming the ip address is 10.2.1.2) in which you are trying to call a station phone B from Phone A on the San Jose gateway would be:

dial-peer voice 3000 voip
destination-pattern 3006
session target ipv4:10.2.1.2

On the next post, dial-peer variables will be addressed.

Author: Joe Parlas

Editor’s Note: You can receive official training including experimenting with dial-peer configurations by attending Cisco’s IUC or CVoice 6.0 course.

OSPF – Part 4

Let’s talk about some issues that arise when we scale an OSPF internetwork up to a large size. As usual when it comes to scalability, there are three issues involved:

  • Bandwidth
  • RAM
  • CPU

First, as the internetwork grows, there are more routers. Recall that with link-state protocols such as OSPF, every router’s LSA (Link State Advertisement) is flooded throughout the internetwork. Obviously, the more routers, the more LSAs must be flooded, which results in more LSU (Link State Update) packets, consuming more bandwidth on the links.

Second, as the LSAs are flooded, each router makes a copy of each LSA, which it keeps in its LSDB (Link State Database). Therefore, the more routers, the larger will be each router’s LSDB, and a larger LSDB requires more RAM to store it. Also, since there are a lot of prefixes, the resulting routing table will be large, requiring even more RAM.

Third, every time a router’s LSDB changes, the router runs Dijkstra’s SPF algorithm to generate its revised routing table. The larger the internetwork, the larger the LSDB, and the more frequently it’s likely to be changing. Thus, each router is running SPF more often on a larger LSDB, consuming more CPU cycles.

The bottom line is that since bandwidth, RAM, and CPU cost money (and we don’t have infinite money) there is some limit to how large an OSPF autonomous system can grow. There are two solutions to this scalability problem

    1. Limit OSPF to small internetworks (bad idea!)
    2. Modify OSPF to enhance its scalability (good idea!)

      Of the two options, the latter was used, and we call it “multi-area OSPF”. What we do is divide the OSPF autonomous system into regions called “areas”. An example of a multi-area OSPF topology is shown here:

      Here’s how it works

      A router that lies completely within an area is called an “internal router”. Internal routers, such as R1, know the entire topology for that specific area (in R1’s case it’s Area 1). Using SPF on its LSDB, R1 builds its routing table by calculating the best path from itself to any prefix within Area 1. At this point, R1 knows the best route to all prefixes within Area 1. Likewise, internal routers R3 and R5 calculate their routing tables for Area 0 and Area 2, respectively.

      A router that is attached to more than one area is called an Area Border Router (ABR), and it maintains an LSDB for each area to which it is attached. R2, for example, is an ABR which connects Area 0 and Area 1. R2 runs SPF on its Area 0 and Area 1 LSDBs, and the results go into its routing table. Thus, R2 knows the best path from itself to all prefixes within Area 0 and Area 1. In addition, R2 now advertises the prefixes that lie within Area 0 into Area 1, and vice-versa. Note that only the prefixes and their metrics are advertised, not the existence of individual routers within an area. Likewise, R4, the ABR between Area 2 into Area 0, advertises prefixes between them.

      For reasons of fault-tolerance, it’s possible that there could be two or more ABRs joining two areas. Since each ABR advertises the cost for each prefix from its perspective, the routers in the area receiving the advertisements can make optimal routing decisions about the prefixes that lie in the other area. At this point, all routers know the best route to all prefixes within the areas to which they are attached, and to the prefixes within the adjacent areas.

      Furthermore, the Area 1 prefixes that R2 is sending into Area 0 are flooded over to R4, which then floods them into Area 2. As a result, all routers in Area 2 know about the prefixes in Area 1. This happens in the opposite direction, as well, and when the flooding has completed, all routers will know about all of the prefixes within the entire OSPF autonomous system. Because it’s just the prefixes and their costs that are being advertised between areas, and not detailed topology information, this requires less bandwidth, RAM and CPU than if it were all one big OSPF area, with all routers knowing everything about the topology.

      In the next installment, we’ll continue our discussion of multi-area OSPF, including some techniques to further increase the scalability.

      Author: Al Friebe

      Cisco IP Phone Audio Codecs

      Cisco IP phones support a variety of different audio codecs. In this post, I will explain some of the differences and explain which versions of CUCM and the Cisco IP phones support the various audio codecs.

      Audio codecs are responsible for sampling human speech (a sine waveform) and representing human speech on a communications network (IP in our case). The digital signal processor (DSP) on the Cisco IP phone is responsible for sampling voice and the ASIC (application specific integrated circuit) is responsible for packetizing the audio sample with an IP/UDP/RTP header.

      All 7900 series Cisco IP phones support the G.711 and G.729 audio codec. G.711 is a 64kbps audio codec that has been used on the public switched telephone network (PSTN) for many decades. G.711 is considered a toll quality audio codec. G.711 utilizes 80kbps of bandwidth on the network due to the 16kbps of overhead incurred when sampling voice every 20 milliseconds (ms). G.711 has a mean opion score (MOS) rating of 4.0.

      The G.729 audio codec is a compressed audio codec, normally utilized on wide area network (WAN) links where bandwidth is limited. G.729 calls are sampled at 8kbps. The packetization overhead of 16kbps brings G.729 call bandwidth consumption to 24kbps without factoring layer 2 link overhead. G.729 voice has a MOS rating of 3.8, bringing the user experience very close to that of G.711 voice. G.729 quality degrades fast in unfavorable network conditions (packet loss). Packet loss must be kept under 1% to maintain high quality G.729 phone calls.

      Cisco introduced the G.722 and iLBC audio codecs in Cisco Unified Communications Manager (CUCM) 6.0. G.722 and iLBC will work on any Cisco Type B phone (7906, 7970, 79×1, 79×2, 79×5), but will not work on the older Cisco Type A phones (7905, 7910, 7912, 7940, 7960). G.722 is a high definition audio codec that provides much higher audio fidelity than G.711. G.711 has a frequency response range of 8khz, while G.722 has a range of 16khz. A wideband audio handset is required to fully experience the quality of G.722. The wideband audio handset ships with all 79×2 and 79×5 phone models, but can be ordered for the 7970 or 79×1 model phones. G.722 uses compression and has a bandwidth impact of 64kbps before packetization (same as G.711).

      iLBC (Internet Low Bandwidth Codec) is an Internet Engineering Task Force (IETF) open standard that has been used by Skype. iLBC is a compressed audio codec that utilizes 16kbps of bandwidth (32kbps after packetization). iLBC uses 8kbps more bandwidth than the G.729 compressed audio codec, but the quality of iLBC does not degrade as fast as G.729 when packet loss occurs.

      Author: Dennis Hartmann


      Editor’s Note: For more on this topic, consider taking the CVOICE: Cisco Voice over IP training class.

      IPv6 Basic Transition Concerns

      Internet Protocol Version 6 (IPv6) is considered to be the next generation protocol for the Internet. It is designed to support continued Internet growth in the number of users, along with greatly enhanced routing functionality. The current version, Internet Protocol Version 4 (IPv4), was developed in the 1970s and provides the basis for today’s Internet functionality. However, IPv4 suffers from some serious limitations that are now inhibitors to any more growth of the Internet which in turn, inhibits additional integration of the Internet as a global business networking solution. IPv4 provides 232 (4,294,967,296) addresses.  Although this appears to be a very large number, it is now insufficient to support the requirements of the maturing Internet.

      IPv6 has been under development by the Internet community for over ten years and is designed to overcome these limitations by greatly expanding available IP address space, and by incorporating features such as end-to-end security, mobile communications, quality of service, and system-management burden reduction.

      The true transition of the global Internet from IPv4 to IPv6 is expected to span many years. And, during this period of transition, many organizations introducing IPv6 into their infrastructure will support both IPv4 and IPv6 concurrently. There is not a one-size-fits-all transition strategy for IPv6. The incremental, phased approach allows for a significant period where IPv4 and IPv6 can co-exist using one or more transition mechanisms to ensure interoperability between the two protocol suites. The most often used methods of performing this transition is by operating in a dual-stack environment, and the use of tunneling and translation between the two versions of Internet Protocol (IP).

      Although there is seldom a viable dialogue between a company’s technical decision makers (TDMs) and business decision makers (BDMs), a professional CCNA must always recognize that any addition to, or modification of, an existing or newly installed network will require an additional amount of money, commonly known as transition costs. Transition costs can be classified as either recurring or non-recurring, and can stem from several sources. However, they are most commonly associated with software and hardware acquisition, employee training, consulting services, and operational costs.

      Transition to IPv6 can be phased into an organization’s infrastructure and applications through a lifecycle management process. Organizations expect to acquire IPv6 capability while upgrading infrastructure as part of the normal technology amortization-replacement lifecycle. The availability of transition mechanisms will enable organizations to replace only that equipment deemed necessary to facilitate IPv6 integration. As existing equipment is replaced with newer equipment, native IPv6 capability will be part of the equipment’s basic operating capability. Consequently, the cost of transition from equipment replacement should be significantly minimized.

      Training will be an important part of the integration process. IPv6, while built on many of the fundamental principles of IPv4, is different enough that most IT personnel will require formalized training. The level of training required will vary, and will depend on the role a member of the organization’s IT staff plays in developing, deploying, and supporting IPv6 integration.  Companies will potentially need to make plans for training their staff.

      There are four main categories of training that are considered to be the most critical for any organization that is transitioning from IPv4 to IPv6.

      • Awareness – This is generalized information about IPv6 and IPv6-related issues. This type of training is most commonly delivered through workshops, seminars, conferences, and summits. These types of events typically provide overviews of IPv6 technologies, identify vendors that support IPv6, and provide participants with a rudimentary understanding of the IPv6 technology, as well as business drivers, deployment issues, and potential services and/or products enabled by IPv6.
      • Architectural – Training in this category should be very detailed and oriented toward those individuals who will have primary responsibilities in designing the architecture and deploying IPv6. Although the type of subject matter will be quite broad, particular attention should be paid to the fundamentals of IPv6, DNS, and DHCPv6, auto-configuration, IPv6 address allocation, transition mechanism, security principles for IPv6 environments, and mobility. Additional topics covered should be routing, multicasting, and principles for connecting to the IPv6 Internet.

        These topics are the areas where participants will encounter the greatest number of new subjects relative to IPv6, and will have the greatest impact on the development of successful integration plans.

      • Operational – Once IPv6 has been integrated into the network, it will need to be supported. Operational training will consist mostly of job-specific training targeted to a participant’s job responsibilities. Core topics such as the fundamentals of IPv6, auto-configuration, and transition mechanisms will need to be covered.

        However, the bulk of operational training should focus on supporting applications or protocols that have IPv6 underneath them. One example is training for system administrators focusing on supporting IPv6-enabled e-mail and web servers. Operational training will often be hardware- or software-specific, generally produced by or for a particular vendor’s product.

      • Specialized – As IPv6 deployment advances and the base level of understanding becomes more pervasive, the need for specialized training will emerge. This type of training should focus less on IPv6 specifically and address greater technological topics where IPv6 plays an important role.

      All of my posts addressing the transition from IPv4 to IPv6 could be considered as falling into the Awareness category of training. And, my next one will specifically address the three most commonly used transition strategies, known as dual stack, tunneling, and translation between the two versions of IP.

      Author: David Stahl

      OSPF – Part 3

      Continuing on with our discussion of LSDB synchronization, we’ve seen that in the case of point-to-point links, the two OSPF neighbors always proceed to “Full” state. On multi-access media such as an Ethernet LAN or a Frame Relay WAN, however, things are more complicated. Let’s look at an Ethernet LAN as an example.

      A typical topology is that several routers are connected by a switch. Assuming that the switch ports connected to the routers lie within a common VLAN, the routers are within a common broadcast domain (an IP subnet). If every router on the subnet directly compares its LSDB to that of each of its neighbors on that subnet, the number of comparisons is governed by the “full mesh” equation:

      • c = n * (n – 1) / 2

      Where:

      • c = The number of comparisons
      • n = The number of routers on the subnet

      If we crank through the numbers, we obtain:

      • n = 2: c = 1 (two routers on a point-to-point link)
      • n = 3: c = 3
      • n = 4: c = 6
      • n = 5; c = 10
      • n = 6: c = 15
      • n = 10: c = 45
      • n = 20: c = 190

      If there are two routers on the subnet, only one comparison is required to ensure LSDB synchronization. In the case of five routers on the subnet (n = 5), ten comparisons are required. If the number of routers on the subnet doubles to ten (n = 10), the number of comparisons increases to 45. Doubling it again (n = 20) results in 190 comparisons. Thus, as the number of routers doubles, the number of comparisons approximately quadruples, which is what computer scientists would call “O(n2)” (order n-squared), an exponential increase.

      Also, once “Full” state is achieved, maintaining it will require that any router that detects a change to its LSDB will send an update to each of the other routers on the subnet, each of which will inform every other router on the subnet, etc. When many routers are involved, the large number of LSUs and LSAcks will consume excessive link bandwidth and router CPU cycles.

      To solve this scalability problem, once the neighbors have reached “Two-Way”, multi-access media can elect a Designated Router (DR). The DR’s job is to maintain synchronization of the LSDBs for all routers within a subnet.

      To elect the DR, the routers compare their DR election priorities, which are contained within the Hello packets. The DR priority is set per interface (or subinterface), and ranges from zero to 255, with a default value of 1. High priority wins, and the tie-breaker is highest OSPF router ID. The first runner-up is elected Backup DR (BDR). If the DR ever becomes unavailable, the BDR is promoted to DR, and a new BDR is elected.

      Once the DR and BDR for the subnet have been elected, all other routers in the subnet will synchronize their LSDBs (go to “Full” state) with the DR. This has the effect of synchronizing all LSDBs on the subnet. The equation controlling the number of comparison is now:

      • c = n – 1

      Where:

      • c = The number of comparisons
      • n = The number of routers on the subnet

      The number of comparisons now increases linearly with the number of routers on the subnet, and if we crank through the numbers we obtain:

      • n = 2: c = 1 (two routers on a point-to-point link)
      • n = 3: c = 2
      • n = 4: c = 3
      • n = 5; c = 4
      • n = 6: c = 5
      • n = 10: c = 9
      • n = 20: c = 19

      Key point: Because all routers on the subnet directly synchronize with the DR, they become synchronized with each other without having to directly compare their LSDBs.

      Whenever a change to the topology occurs, the router detecting the change will inform the DR, which will inform the other routers on the subnet. In this manner, LSDB synchronization is maintained between the routers within the subnet. Those routers will then flood the LSA to other subnets to which they are attached.

      Next time, we’ll examine multi-area OSPF, a technique for enhancing scalability.

      Author: Al Friebe

      Resource Reservation Protocol (RSVP)

      Resource Reservation Protocol (RSVP) is a quality of service (QoS) mechanism that was first introduced in the Internet Engineering Task Force (IETF) RFC 1633 (1994). RSVP was introduced as an integrated services model for implementing end-to-end QoS in the data network. RSVP provides an end-to-end guaranteed quality of service and relies on signaling mechanisms transmitted from source to destination. RSVP is a topology aware QoS mechanism, while the differentiated services model only makes a per hop guarantee, referred to as a per hop behavior (PHB). RSVP’s greatest disadvantage is the signaling messages that must be process level switched by every router in the end to end path.

      Many enhancements (RSVP passthrough, RSVP refresh reductions) have been made to the RSVP protocol in an effort to make the protocol more scalable, but the application in real world networks is still too processor intensive to be considered in any considerable size deployment. Service providers will not perform QoS guarantees using customer-initiated RSVP path messages due to the millions of microflows (IP sessions) that can possibly traverse service provider cores at the same time. Some service provider networks use RSVP-initiated MPLS Traffic Engineering tunnels in MPLS networks for the application of customer macro-flow tunnels. Service providers do not react to customer initiated RSVP signaling messages. Customer RSVP signaling is passed through the service provider cloud, while the service provider performs QoS based on the differentiated services code point (DSCP) marking.

      RSVP initiated phone calls can be synchronized from Cisco Unified Communications Manager (CUCM) as of CUCM 5.0. RSVP must be enabled on every router from source to destination unless the passthrough model is being utilized. The passthrough model does not guarantee QoS because passthrough devices may not implement any QoS. RSVP implementation in CUCM requires IOS 12.4(6T) or later and CUCM 5.0 or later. The configuration of RSVP requires a Media Termination Point (MTP) configuration on the router which will act as an RSVP agent to CUCM.

      I will not get into the details of implementing RSVP on CUCM since I do everything in my power to avoid the use of the RSVP protocol. I do not recommend the use of RSVP in CUCM even though it is the only topology aware call admission control (CAC) mechanism. The burden on the route processor is far too great and the RSVP mechanism is quite complex to properly provision in CUCM and the routers. Consider the deployment of an H.323 gatekeeper to provide CAC functionality in a production network.

      Author: Dennis Hartmann

      QoS Part 4 – QoS Mechanisms

      In the previous discussion on QoS, the uses of Per-Hop Behaviors DiffServ to mark packets were identified and discussed in detail. Today’s post will identify the mechanisms to implement QoS. The five main categories of tools used to implement QoS are as follows.

      • Classification and Marking
      • Congestion Management
      • Congestion Avoidance
      • Policing and Shaping
      • Link Efficiency

      Classification and Marking

      Classification and Marking, although lumped together as one, are two distinct items within the QoS mechanisms to implement QoS. In general terms they identify and split traffic into different classes and mark the traffic according to desired behaviors.

      Classification tools sort packets into different traffic types, to which different policies can be applied. Classification can be done at every node in the network or be implemented at the edge of the network when the packet enters the network. Classification of packets can happen without marking the packets. Classification inspects one or more fields in the packet to identify the type of traffic that the packet is carrying. After the identification process the traffic is handed to the treatment application such as, marking, remarking, queuing, policing, shaping or a combination of these.

      Marking writes a field within the packet, frame, cell or label to preserve the classification decision that was reached during the classification process. Marking is also known as coloring the packet, which involves marking each packet as a member of a network class so all devices throughout the rest of the network can quickly recognize the packet class. The marking process set bits in the DSCP or IP Precedence field of each IP packet according to the class that the packet is in. Packets that are marked as high priority, such as a voice packet, will generally never be dropped by congestion avoidance mechanisms. On the other hand, if packets are marked as low priority they will be dropped when congestion occurs.

      Congestion Management

      Congestion management queuing algorithms use the marking on each packet to determine which queue to place packets in. Each queue is given different treatment based on the class of packets in the queue. Congestion management tools are implemented on all output interfaces in a QoS enabled network. Cisco IOS uses the following congestion management queuing methods:

      • FIFO (First in First Out), Priority Queuing (PQ), Custom Queuing (CQ)
      • Weighted Fair Queuing (WFQ)
      • Class Based Weighted Fair Queuing (CBWFQ)
      • Low Latency Queuing (LLQ)

      Congestion Avoidance

      Congestion Avoidance monitors network traffic loads in an effort to anticipate and avoid congestion. Congestion Avoidance is achieved through packet dropping. Typically, congestion avoidance is implemented on output interfaces where high-speed links intersect with low speed links. Congestion Avoidance in Cisco products uses Weighted Random Early Detection (WRED) to avoid congestion by dropping low priority packets and allowing high priority packets to continue on their path.

       

      Policing and Shaping

      Policing or Shaping mechanisms are used to condition traffic before transmitting or when receiving traffic. Policers and Shapers can work in tandem, they are not mutually exclusive.

      Policing controls bursts and conforms traffic to ensure each traffic type gets the prescribed bandwidth. In some cases policing can help service providers maintain service level agreements (SLA). This is accomplished by throttling excess traffic above agreed SLA by dropping low priority traffic. Policing is implemented with Class-Based Policing and Committed Access Rate (CAR).

      Shaping helps smooth out speed mismatches in the network and limits transmission rates. These mechanisms are typically used to limit the flow from high speed links to low speed links, to prevent the low speed links from becoming over run. Cisco QoS uses Generic Traffic Shaping (GTS), and Frame Relay Traffic Shaping (FRTS) to implement shaping.

       

      Link Efficiency

      Although not exclusively QoS tools, link efficiency tools are categorized as QoS tools because they are often used in conjunction with QoS. Both of the link efficiency tools were created outside of the realm of QoS, and were used as independent Cisco IOS Tools.

      Header-compression is a tool that is used to reduce the IP overhead of a Real-Time Transport Protocol (RTP) voice packet which reduces the overall size of the IP packet. Large packets normally do not use header-compression because the ratio of the size of the IP header is not significant compared to the payload of the packet. Short voice packets’ IP header can more than triple the overall size of the packet which can increase the delay of transmitting the packet to its destination.

      A RTP packet has 40 bytes of IP Over head broken out as follows:

      • IP Header = 20 bytes
      • UDP Header = 8 bytes
      • RTP Header = 12 bytes
      • Total = 40 bytes

      When compressed, the IP/UDP/RTP header is reduced down to 2 or 4 bytes depending on if the cyclic redundancy check (CRC) is transmitted.

      Link Fragmentation and Interleaving (LFI) is used to reduce delay and jitter on slower speed links by breaking the larger packets, such as FTP file transfers, into smaller packets and interleaving them in with the small voice packets. LFI reduces serialization delay by fragmenting large packets such as file transfers on slow WAN links (768K or less). If these large packets are allowed to continue unimpeded the voice packets would exceed their delay and jitter tolerances, and would result in bad quality voice.

      The next few entries of this QoS blog will explore the Cisco IOS Modular QoS Command Line Interface (MQC), and how to configure the QoS mechanisms explained in this blog.

      References
      End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh
      DiffServ – The Scalable End-To-End QoS Model
      Integrated Services Architecture
      Definition of the Differentiated Services Field
      An Architecture for Differentiated Services
      Requirements for IP Version 4 Routers
      An Expedited Forwarding PHB (Per-Hop Behavior)

      Author: Paul Stryer

      Next Page »