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

VPN Filtering Options

Several postings previous to this one, some VPN misconceptions were discussed (ed. note: here). This post will elaborate, as promised, on the two filtering options briefly mentioned to secure the VPN tunnel: 1) Group policy based filters and 2) Downloadable ACLs. The first of these applies to both site-to-site and remote access VPNs, while the second applies only to client-based remote access with either IPSec or SSL.

Unless otherwise specified, all connection profiles, or tunnel groups, on the ASA utilize the group policy entitled DfltGrpPolicy. This corresponds to what was previously called the Base Group on the VPN Concentrator and arguably is a mix of both secure and insecure default settings.
Continue reading ‘VPN Filtering Options’

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.

“nat-control” versus “no nat-control”

ASA and PIX software version 7.0 introduced the configuration command nat-control which didn’t exist in previous versions of code. Although training course material for both the SNAF (Securing Networks with ASA Fundamentals) and SNAA (Securing Networks with ASA Advanced) assume that their audience will use this global configuration command, it should not be considered a “catch all” for all implementations.

The scenario depicted below is a crude approximation of what I encountered at a client location within the past 18 months. The objective of the consultation was to convert the site from using a PIX Firewall 506E (restricted to OS6.3 code) to using an ASA with version 7.x. Since the default behavior of PIX OS Code up to and including version 6.3 was effectively to enforce the use of configured nat, global and/or static config commands (essentially what nat-control does), the migration was most easily accomplished by moving the configuration over from the PIX to the ASA with a minimum of changes.

In hindsight (always 20-20 for consulting!) with the number of internal private networks and the distinct policies for connectivity between them, a simpler solution would probably have been to implement “no nat-control”. This solution would have the following advantages over using the one chosen:

  1. Elimination of the numerous static (intf1,intf2) A.B.C.D A.B.C.D statements in the config made necessary by nat-control. These would need to be configured for ALL possible internal interface-to-interface combinations.
  2. Troubleshooting such an implementation would be simpler, as using the security levels of the interfaces and access-lists would be all that would be required (vs needing the translation statements as well).
  3. If full unrestricted access would be required, version 7.0 and above code supports the “same-security-traffic permit inter-interface” command which corresponds to a checkbox in ASDM entitled “Enable traffic between two or more interfaces with the same security level”. This could be enabled and at least two of the internal networks could be assigned the same security level thus eliminating the need for any ACLs.

Now that we have mentioned the advantages, to be fair we should list some of the caveats:

  1. By using “no nat-control the potential danger exists of having your private networks “leak” out to the Internet untranslated. Although your ISP (and others, hopefully!) won’t be able route back to these networks, it provides unnecessary visibility of the actual identity of your internal networks.
  2. A recommended “fix” for the above problem would be not only to explicitly configure translation rules for ALL of the internal networks allowed access to the Internet but also to configure outbound access lists denying any private IP addresses exiting the outside interface.

Author: Doug McKillip

References
Configuring NAT Control

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

      ASA VPN Misconceptions

      Numerous experiences with clients and students implementing Virtual Private Networks (VPNs) with IPSec have shown me that some common misconceptions exist as to their operation and troubleshooting.  We will examine three of these using the scenario below between an ASA running version 8.0 code and a Cisco Router running IOS version 12.2 or higher code.

      Misconception #1: A Site-to-Site VPN created with the ASDM Wizard is Bidirectional

      The commands below are a portion of what would be displayed if the “Preview Commands…” option were selected in the ASDM preferences after finishing the Site-to-Site wizard.

      crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
      crypto map outside_map 1 match address outside_1_cryptomap
      crypto map outside_map 1 set pfs group2
      crypto map outside_map 1 set peer 192.168.11.2
      crypto map outside_map 1 set transform-set ESP-3DES-SHA
      crypto map outside_map interface outside

      Note the set pfs group2 statement above; this default deployment option with the wizard will result in the IKE Phase II proposal of Perfect Forward Secrecy using Diffie-Hellman Group #2.  While the IOS Router will support this and agree to it (even though it wasn’t explicitly configured), the tunnel CANNOT be successfully initiated by the site owning that router!  For this to happen, the router MUST be configured with the same statement for its Phase II policy in its crypto map.

       

      Misconception #2: The IKE keepalive keeps the Site-to-Site tunnel up

      Actually, the IKE keepalive merely insures that the remote peer is reachable. A little-known fact is that the Idle Timeout usually found in the Network (Client) Access for the IPSec client also impacts Site-to-Site tunnels being kept up.  A screenshot is provided below showing where this is configured for the default group policy, DfltGrpPolicy.

      Studies have shown that if this time interval is increased to be greater than 80% of the Phase II IPSec Security Association lifetime, the tunnel will stay up.

      Misconception #3: Allowing IPSec ACL bypass is insecure – Default Wizard option

      This appears as a checkbox in the wizard, or could be configured using the CLI command sysopt connection permit-vpn. Two very effective techniques can be used here, the mechanics of which will be discussed in future postings.  The first of these would be to configure a VPN Group Filter (done under the Group Policy settings), a feature which applies for both Site-to-Site or Remote Access VPNs. A second effective technique, applicable for both IPSec and SSL VPN Client access, would be to use downloadable access-control lists with RADIUS.

      Author: Doug McKillip

      References
      Most Common L2L and Remote Access IPSec VPN Troubleshooting Solutions Document ID #81824

      Next Page »