Deploying IPv6 in Campus Networks
Available Languages
Table Of Contents
About Cisco Validated Design (CVD) Program
Deploying IPv6 in Campus Networks
Document Format and Naming Conventions
Benefits and Drawbacks of This Solution
Benefits and Drawbacks of This Solution
Benefits and Drawbacks of This Solution
Network and Address Management
Dual-Stack Model—Implementation
High-Availability Configuration
Infrastructure Security Configuration
Service Block Model—Implementation
Infrastructure Security Configuration
Deploying IPv6 in Campus NetworksLast Updated: February 27, 2012
Building Architectures to Solve Business Problems
About the Author
Shannon McFarland, Corporate Consulting Engineer, Office of the CTO, Cisco SystemsShannon McFarland, CCIE #5245, is a Corporate Consulting Engineer in the Office of the CTO and is focused on Enterprise IPv6 deployment, VDI, and Data Center technologies. Shannon has been responsible for the Enterprise IPv6 design and deployment effort at Cisco for the last 9 years. He has authored many technical papers and Cisco Validated Design guides, is a contributor to Cisco Press books, and is a frequent speaker at Cisco Live and other industry conferences. He co-authored a Cisco Press book, "IPv6 in Enterprise Networks". Prior to his time at Cisco corporate, Shannon was an SE in the Cisco Englewood, CO office. Shannon has been at Cisco for 11+ years.
About Cisco Validated Design (CVD) Program
The CVD program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit http://www.cisco.com/go/designzone.
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at http://www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Deploying IPv6 in Campus Networks
© 2011 Cisco Systems, Inc. All rights reserved.
Deploying IPv6 in Campus Networks
This document guides customers in their planning or deployment of IPv6 in campus networks. This document does not introduce campus design fundamentals and best practices, IPv6, transition mechanisms, or IPv4-to-IPv6 feature comparisons.
Introduction
Document Objectives
The reader must be familiar with the Cisco campus design best practices recommendations as well as the basics of IPv6 and associated transition mechanisms. The prerequisite knowledge can be acquired through many documents and training opportunities available both through Cisco and the industry at large. Following are a few recommended information resources for these areas of interest:
•
Cisco Design Zone for Campus
http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html•
http://www.cisco.com/ipv6•
http://www.ciscopress.com/bookstore/product.asp?isbn=1587142279•
http://www.ciscopress.com/bookstore/product.asp?isbn=1587052105&rl=1•
http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945Document Format and Naming Conventions
This document provides a brief overview of the various campus IPv6 deployment models and general deployment considerations, and also provides the implementation details for each model individually.
The following abbreviations are used throughout this document when referring to the campus IPv6 deployment models:
•
•
•
User-defined properties such as access control list (ACL) names and quality of service (QoS) policy definitions are shown in ALL CAPS to differentiate them from command-specific policy definitions.
Deployment Models Overview
This section provides a high-level overview of the following three campus IPv6 deployment models and describes their benefits applicability:
•
•
•
Dual-Stack Model
Overview
DSM is completely based on the dual-stack transition mechanism. A device or network on which two protocol stacks have been enabled at the same time operates in dual-stack mode. Examples of previous uses of dual-stack include IPv4 and IPX, or IPv4 and Apple Talk co-existing on the same device.
Dual-stack is the preferred, most versatile way to deploy IPv6 in existing IPv4 environments. IPv6 can be enabled wherever IPv4 is enabled along with the associated features required to make IPv6 routable, highly available, and secure. In some cases, IPv6 is not enabled on a specific interface or device because of the presence of legacy applications or hosts for which IPv6 is not supported. Inversely, IPv6 may be enabled on interfaces and devices for which IPv4 support is no longer needed.
The tested components area of each section of this paper gives a brief view of the common requirements for the DSM to be successfully implemented. The most important consideration is to ensure that there is hardware support of IPv6 in campus network components such as switches. Within the campus network, link speeds and capacity often depend on such issues as the number of users, types of applications, and latency expectations. Because of the typically high data rate requirements in this environment, Cisco does not recommend enabling IPv6 unicast or multicast layer switching on software forwarding-only platforms. Enabling IPv6 on software forwarding-only campus switching platforms may be suitable in a test environment or small pilot network, but certainly not in a production campus network.
Benefits and Drawbacks of This Solution
Deploying IPv6 in the campus using DSM offers several advantages over the hybrid and service block models. The primary advantage of DSM is that it does not require tunneling within the campus network. DSM runs the two protocols as "ships-in-the-night", meaning that IPv4 and IPv6 run alongside one another and have no dependency on each other to function except that they share network resources. Both IPv4 and IPv6 have independent routing, high availability (HA), QoS, security, and multicast policies. Dual-stack also offers processing performance advantages because packets are natively forwarded without having to account for additional encapsulation and lookup overhead.
Customers who plan to or have already deployed the Cisco routed access design will find that IPv6 is also supported because the network devices support IPv6 in hardware. Discussion on implementing IPv6 in the routed access design follows in Dual-Stack Model—Implementation.
The primary drawback to DSM is that network equipment upgrades might be required when the existing network devices are not IPv6-capable.
Conclusion summarizes the benefits and challenges of the various campus design models in a tabular format.
Solution Topology
Figure 1 shows a high-level view of the DSM-based deployment in the campus networks. This example is the basis for the detailed configurations that are presented later in this document.
Note
Figure 1 Dual-Stack Model Example
Tested Components
Table 1 lists the components that were used and tested in the DSM configuration.
Hybrid Model
Overview
The hybrid model strategy is to employ two or more independent transition mechanisms with the same deployment design goals. Flexibility is the key aspect of the hybrid approach in which any combination of transition mechanisms can be leveraged to best fit a given network environment.
The hybrid model adapts as much as possible to the characteristics of the existing network infrastructure. Transition mechanisms are selected based on multiple criteria, such as IPv6 hardware capabilities of the network elements, number of hosts, types of applications, location of IPv6 services, and network infrastructure feature support for various transition mechanisms.
The following are the three main IPv6 transition mechanisms leveraged by this model:
•
•
•
HM provides hosts with access to IPv6 services even when the underlying network infrastructure may not support IPv6 natively.
The key aspect of HM is the fact that hosts located in the campus access layer can use IPv6 services when the distribution layer is not IPv6-capable or enabled. The distribution layer switch is most commonly the first Layer 3 gateway for the access layer devices. If IPv6 capabilities are not present in the existing distribution layer switches, the hosts cannot gain access to IPv6 addressing (stateless autoconfiguration or DHCP for IPv6) router information, and subsequently cannot access the rest of the IPv6-enabled network.
Tunneling can be used on the IPv6-enabled hosts to provide access to IPv6 services located beyond the distribution layer. The HM leverages the ISATAP tunneling mechanisms on the hosts in the access layer to provide IPv6 addressing and off-link routing. The Microsoft Windows 7 (XP and Vista are also supported) hosts in the access layer need to have IPv6 enabled and either a static ISATAP router definition or DNS "A" record entry configured for the ISATAP router address.
Figure 2 shows the basic connectivity flow for HM.
Figure 2 Hybrid Model—Connectivity Flow
1.
2.
3.
4.
One method to help control where ISATAP tunnels can be terminated and what resources the hosts can reach over IPv6 is to use VLAN or IPv4 subnet-to-ISATAP tunnel matching.
If the current network design has a specific VLAN associated with ports on an access layer switch and the users attached to that switch are receiving IPv4 addressing based on the VLAN to which they belong, a similar mapping can be done with IPv6 and ISATAP tunnels.
Figure 3 illustrates the process of matching users in a specific VLAN and IPv4 subnet with a specific ISATAP tunnel.
Figure 3 Hybrid Model—ISATAP Tunnel Mapping
1.
2.
The host is also configured for ISATAP and has been statically assigned the ISATAP router value of 10.122.10.2. This static assignment can be implemented in several ways. An ISATAP router setting can be defined via a command on the host (netsh interface ipv6 isatap set router 10.122.10.2—details provided later in the document), which can be manually entered or scripted via a Microsoft PowerShell, Microsoft Group Policy, or a number of other scripting methods. The script can determine to which value to set the ISATAP router by examining the existing IPv4 address of the host. For instance, the script can analyze the host IPv4 address and determine that the value "2" in the 10.120.2.x/24 address signifies the subnet value. The script can then apply the command using the ISATAP router address of 10.122.10.2, where the "2" signifies subnet or VLAN 2. The 10.122.10.2 address is actually a loopback address on the core layer switch and is used as the tunnel endpoint for ISATAP.
A customer might want to do this for the following reasons:
•
•
Solution Requirements
The following are the main solution requirements for HM strategies:
•
•
As mentioned previously, numerous combinations of transition mechanisms can be used to provide IPv6 connectivity within the enterprise campus environment, such as the following two alternatives to the requirements listed above:
•
•
Note
Benefits and Drawbacks of This Solution
The primary benefit of HM is that the existing network equipment can be leveraged without the need for upgrades, especially the distribution layer switches. If the distribution layer switches currently provide acceptable IPv4 service and performance and are still within the depreciation window, HM may be a suitable choice.
It is important to understand the drawbacks of the hybrid model, specifically with HM:
•
•
•
As with any design that uses tunneling, considerations that must be accounted for include performance, management, security, scalability, and availability. The use of tunnels is always a secondary recommendation to the DSM design.
Conclusion summarizes the benefits and challenges of the various campus design models in a tabular format.
Solution Topology
Figure 4 shows a high-level view of the campus HM. This example is the basis for the detailed configurations that follow later in this document.
Note
Figure 4 Hybrid Model
Tested Components
Table 2 lists the components used and tested in the HM configuration. It is important to note that the only Cisco Catalyst components that need to have IPv6 capabilities are those terminating ISATAP connections and the dual-stack links in the data center. Therefore, the software versions in the campus access and distribution layer roles are not relevant to this design.
Table 2 HM Tested Components
Core layer
Catalyst 6500 Supervisor 720
12.2(33)SXI4
Service Block Model
Overview
SBM is significantly different compared to the other campus models discussed in this document. Although the concept of a service block-like design is not a new concept, the SBM does offer unique capabilities to customers facing the challenge of providing access to IPv6 services in a short time. A service block-like approach has also been used in other design areas such as Cisco Network Virtualization (http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns815/landing_cNet_virtualization.html), which refers to this concept as the "Services Edge". The SBM is unique in that it can be deployed as an overlay network without any impact to the existing IPv4 network, and is completely centralized. This overlay network can be implemented rapidly while allowing for high availability of IPv6 services, QoS capabilities, and restriction of access to IPv6 resources with little or no changes to the existing IPv4 network.
As the existing campus network becomes IPv6 capable, the SBM can become decentralized. Connections into the SBM are changed from tunnels (ISATAP and/or manually-configured) to dual-stack connections. When all the campus layers are dual-stack capable, the SBM can be dismantled and re-purposed for other uses.
The SBM deployment is based on a redundant pair of Catalyst 6500 switches with a Supervisor 32 or Supervisor 720. Alternatively, Cisco routing platforms, such as the Cisco ISR series, can be used to terminate the ISATAP tunnels in smaller environments. The key to maintaining a highly scalable and redundant configuration in the SBM is to ensure that a high-performance switch, supervisor, and modules are used to handle the load of the ISATAP, manually-configured tunnels, and dual-stack connections for an entire campus network. As the number of tunnels and required throughput increases, it may be necessary to distribute the load across an additional pair of switches in the SBM.
There are a few similarities between the SBM example given in this document and the HM. The underlying IPv4 network is used as the foundation for the overlay IPv6 network being deployed. ISATAP provides access to hosts in the access layer (similar to HM). IPv4 routing is configured between the core layer and SBM switches to allow visibility to the SBM switches for the purpose of terminating IPv6-in-IPv4 tunnels. In the example discussed in this paper, however, the extreme case is analyzed where there are no IPv6 capabilities anywhere in the campus network (access, distribution, or core layers). The SBM example used in this document has the switches directly connected to the core layer via redundant high-speed links.
Benefits and Drawbacks of This Solution
From a high-level perspective, the advantages to implementing the SBM are the pace of IPv6 services delivery to the hosts, the lesser impact on the existing network configuration, and the flexibility of controlling the access to IPv6-enabled applications.
In essence, the SBM provides control over the pace of IPv6 service rollout by leveraging the following:
•
•
•
•
•
As mentioned in the case of HM, there are drawbacks to any design that relies on tunneling mechanisms as the primary way to provide access to services. The SBM not only suffers from the same drawbacks as the HM design (lots of tunneling), but also adds the cost of additional equipment not found in HM. More switches (the SBM switches), line cards to connect the SBM and core layer switches, and any maintenance or software required represent additional expenses.
Because of the list of drawbacks for HM and SBM, Cisco recommends to always try to deploy the DSM.
Conclusion summarizes the benefits and challenges of the various campus design models in a tabular format.
Solution Topology
Two portions of the SBM design are discussed in this document. Figure 5 shows the ISATAP portion of the design and Figure 6 shows the manually-configured tunnel portion of the design. These views are just two of the many combinations that can be generated in a campus network and differentiated based on the goals of the IPv6 design and the capabilities of the platforms and software in the campus infrastructure.
As mentioned previously, the data center layers are not specifically discussed in this document because a separate document will focus on the unique designs and challenges of the data center. This document presents basic configurations in the data center for the sake of completeness. Based on keeping the data center portion of this document as simple as possible, the data center aggregation layer is shown as using manually-configured tunnels to the SBM and dual-stack from the aggregation layer to the access layer.
Figure 5 shows the redundant ISATAP tunnels coming from the hosts in the access layer to the SBM switches. The SBM switches are connected to the rest of the campus network by linking directly to the core layer switches via IPv4-enabled links. The SBM switches are connected to each other via a dual-stack connection that is used for IPv4 and IPv6 routing and HA purposes.
Figure 5 Service Block Model—Connecting the Hosts (ISATAP Layout)
Figure 6 shows the redundant, manually-configured tunnels connecting the data center aggregation layer and the service blocks. Hosts located in the access layer can now reach IPv6 services in the data center access layer using IPv6.
Figure 6 Service Block Model—Connecting the Data Center (Manually-Configured Tunnel Layout)
Tested Components
Table 3 lists the components used and tested in the SBM configuration.
Table 3 SBM Tested Components
Service block
Catalyst 6500 Supervisor 720
12.2(33)SXI4
General Considerations
Many considerations apply to all the deployment models discussed in this document. This section focuses on the general ones that apply to deploying IPv6 in a campus network regardless of the deployment model being used. If a particular consideration must be understood in the context of a specific model, this model is called out along with the consideration. Also, the configurations for any model-specific considerations can be found in the implementation section of that model.
All campus IPv6 models discussed in this document leverage the existing campus network design as the foundation for providing physical access, VLANs, IPv4 routing (for tunnels), QoS (for tunnels), infrastructure security (protecting the tunnels), and availability (device, link, trunk, and routing). When dual-stack is used, nearly all design principles found in Cisco campus design best practice documents are applicable to both IPv4 and IPv6.
It is critical to understand the Cisco campus best practice recommendations before jumping into the deployment of the IPv6 campus models discussed in this document.
The Cisco campus design best practice documents can be found at the following URL: http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html.
Addressing
As mentioned previously, this document is not an introductory document and does not discuss the basics of IPv6 addressing. However, it is important to discuss a few addressing considerations for the network devices. specifically for links.
Table 4 breaks down the options related to the use of various prefix lengths on links.
•
•
•
RFC 3627 (http://www.ietf.org/rfc/rfc3627.txt) discusses the reasons why the use of a /127 prefix is harmful and should be discouraged. At the time this document was written, the IETF draft "Using 127-bit IPv6 Prefixes on Inter-Router Links" (draft-kohno-ipv6-prefixlen-p2p) provides the best guidance on the use of /127.
Physical Connectivity
Considerations for physical connectivity with IPv6 are the same as with IPv4, with the addition of the following three elements:
•
This is an important factor for the deployment of any new technology, protocol, or application.
•
This document is not an introductory document for basic IPv6 protocol operation or specifications. Cisco recommends reading the following documentation for more information on MTU and fragmentation in IPv6. A good starting point for understanding MTU and Path MTU Discovery (PMTUD) for IPv6 is with RFC 2460 and RFC 1981 at the following URLs:
–
–
•
IPv6 should operate correctly over WLAN access points in much the same way as IPv6 operates over Layer 2 switches. However, the reader must consider IPv6 specifics in WLAN environments include managing WLAN devices (APs and controllers) via IPv6, and controlling IPv6 traffic via AP or controller-based QoS, VLANs, and ACLs. IPv6 must be supported on the AP and/or controller devices to take advantage of these more intelligent services on the WLAN devices.
Cisco supports the use of IPv6-enabled hosts that are directly attached to Cisco IP Phone ports, which are switch ports and operate in much the same way as plugging the host directly into a Catalyst Layer 2 switch.
In addition to the above considerations, Cisco recommends that a thorough analysis of the existing traffic profiles, memory, and CPU utilization on both the hosts and network equipment, and also the Service Level Agreement (SLA) be completed before implementing any of the IPv6 models discussed in this document.
VLANs
VLAN considerations for IPv6 are the same as for IPv4. When dual-stack configurations are used, both IPv4 and IPv6 traverse the same VLAN. When tunneling is used, IPv4 and the tunneled IPv6 (protocol 41) traffic traverse the VLAN. The use of private VLANs is not included in any of the deployment models discussed in this document and it was not tested, but is supported with IPv6.
The use of IPv6 on data VLANs that are trunked along with voice VLANs (behind IP Phones) is fully supported. For the current VLAN design recommendations, see the Cisco branch-LAN design best practice documents at: http://www.cisco.com/en/US/netsol/ns816/networking_solutions_program_home.html.
Routing
The decision to run an IGP in the campus network was made based on a variety of factors such as platform capabilities, IT staff expertise, topology, and size of network. In this document, the IGP for IPv4 is EIGRP, but OSPFv2 for IPv4 can also be used. The IGP configurations for IPv6 can either be EIGRP or OSPFv3. These IGPs are interchanged in some sections to show the reader what the basic configuration looks like for either IGP.
As previously mentioned, every effort has been made to implement the current Cisco campus design best practices. Both the IPv4 and IPv6 IGPs have been tuned according to the current best practices where possible. It should be one of the top priorities of any network design to ensure that the IGPs are tuned to provide a stable, scalable, and fast converging network.
High Availability
Many aspects of high availability (HA) are not applicable to or are outside the scope of this document. Many of the HA requirements and recommendations are met by leveraging the existing Cisco campus design best practices. The following are the primary HA components discussed in this document:
•
•
•
QoS
With DSM, it is easy to extend or leverage the existing IPv4 QoS policies to include the new IPv6 traffic traversing the campus network. Cisco recommends that the QoS policies be implemented to be application- and/or service-dependent instead of protocol-dependent (IPv4 or IPv6). If the existing QoS policy has specific classification, policing, and queuing for an application, that policy should treat equally the IPv4 and IPv6 traffic for that application.
Special consideration should be provided to the QoS policies for tunneled traffic. QoS for ISATAP-tunneled traffic is somewhat limited. When ISATAP tunnels are used, the ingress classification of IPv6 packets cannot be made at the access layer, which is the recommended location for trusting or classifying ingress traffic. In the HM and SBM designs, the access layer has no IPv6 support. Tunnels are being used between the hosts in the access layer and either the core layer (HM) or the SBM switches, and therefore ingress classification cannot be done.
QoS policies for IPv6 can be implemented after the decapsulation of the tunneled traffic, but this also presents a unique challenge. Tunneled IPv6 traffic cannot even be classified after it reaches the tunnel destination, because ingress marking cannot be done until the IPv6 traffic is decapsulated (ingress classification and marking are done on the physical interface and not the tunnel interface). Egress classification policies can be implemented on any IPv6 traffic now decapsulated and being forwarded by the switch. Trust, policing, and queuing policies can be implemented on upstream switches to properly deal with the IPv6 traffic.
Figure 7 illustrates the points where IPv6 QoS policies may be applied when using ISATAP in HM. The dual-stack links shown have QoS policies that apply to both IPv4 and IPv6 and are not shown because those policies follow the Cisco campus QoS recommendations. Refer to Additional References for more information about the Cisco campus QoS documentation.
Figure 7 QoS Policy Implementation—HM
1.
2.
Figure 8 illustrates the points where IPv6 QoS policies may be applied in the SBM when ISATAP manually-configured tunnels are used.
Figure 8 QoS Policy Implementation—SBM (ISATAP and Manually-Configured Tunnels)
1.
2.
Note
The DSM model is not shown here because the same recommendations for implementing QoS policies for IPv4 should also apply to IPv6.
The key consideration as far as Modular QoS CLI (MQC) is concerned is the removal of the "ip" keyword in the QoS "match" and "set" statements. Modification in the QoS syntax to support IPv6 and IPv4 allows for a new configuration criteria, as shown in Table 5.
Table 5 New Configuration Criteria
match ip dscp
match dscp
match ip precedence
match precedence
set ip dscp
set dscp
set ip precedence
set precedence
There are QoS features that work for both IPv6 and IPv4, but require no modification to the CLI (for example, WRED, policing, and WRR).
The implementation section for each model does not go into great detail on QoS configuration in relation to the definition of classes for certain applications, the associated mapping of DSCP values, and the bandwidth and queuing recommendations. Cisco provides an extensive collection of QoS recommendations for the campus, which is available on CCO, as well as the Cisco Press book End-to-End QoS Network Design.
Refer to Additional References for more information about the Cisco campus QoS recommendations and Cisco Press books.
Security
Many of the common threats and attacks on existing IPv4 campus networks also apply to IPv6. Unauthorized access, spoofing, routing attacks, virus/worm, denial of service (DoS), and man-in-the-middle attacks are just a few of the threats to both IPv4 and IPv6.
With IPv6, many new threat possibilities do not apply at all or at least not in the same way as with IPv4. There are inherent differences in how IPv6 handles neighbor and router advertisement and discovery, headers, and even fragmentation. Based on all these variables and possibilities, the discussion of IPv6 security is a very involved topic in general, and detailed security recommendations and configurations are outside the scope of this document. There are numerous efforts both within Cisco and the industry to identify, understand, and resolve IPv6 security threats. This document points out some possible areas to address within the campus and gives basic examples of how to provide protection for IPv6 dual-stack and tunneled traffic.
Note
The following are general security guidelines for network device protection that apply to all campus models:
•
–
interface Loopback0ipv6 address 2001:DB8:CAFE:6507::A111:1010/128To more tightly restrict access to a particular switch via IPv6, an ACL is used to permit access to the management interface (line vty) by way of the loopback interface. The permitted source network is from the enterprise IPv6 prefix. To make ACL generation more scalable for a wide range of network devices, the ACL definition can permit the entire enterprise prefix as the primary method for controlling management access to the device instead of filtering to a specific interface on the switch. The IPv6 prefix used in this enterprise site (example only) is 2001:db8:cafe::/48.
ipv6 access-list MGMT-INremark Permit MGMT only to Loopback0permit tcp 2001:DB8:CAFE::/48 host 2001:DB8:CAFE:6507::A111:1010deny ipv6 any any log-input!line vty 0 4session-timeout 3access-class MGMT-IN-v4 inpassword 7 08334D400E1C17ipv6 access-class MGMT-IN in #Apply IPv6 ACL to restrict accesslogging synchronouslogin localexec prompt timestamptransport input ssh #Accept access to VTY via SSH–
In the campus models discussed in this document, SNMPv3 (AuthNoPriv) is used to provide polling capabilities for the Cisco NMS servers located in the data center. Following is an example of the SNMPv3 configuration used in the campus switches in this document:
snmp-server contact John Doe - ipv6rocks@cisco.comsnmp-server group IPv6-ADMIN v3 auth write v1defaultsnmp-server user jdoe IPv6-ADMIN v3 auth md5 cisco1234snmp-server host 2001:DB8:CAFE:100::60 version 3 auth jdoe•
–
–
–
A basic example of implementing IPv6 per-user microflow policing follows. In this example, a downstream switch has been configured with a QoS policy to match IPv6 traffic and to set specific DSCP values based on one of the Cisco-recommended QoS policy configurations. The configuration for this particular switch (shown below) is configured to perform policing on a per-user flow basis (based on IPv6 source address in this example). Each flow is policed to 5 Mbps and is dropped if it exceeds the profile.
mls qos!class-map match-all POLICE-MARKmatch access-group name V6-POLICE-MARK!policy-map IPv6-ACCESSclass POLICE-MARKpolice flow mask src-only 5000000 8000 conform-action transmit exceed-action dropclass class-defaultset dscp default!ipv6 access-list V6-POLICE-MARKpermit ipv6 any any!interface GigabitEthernet3/1mls qos trust dscpservice-policy input IPv6-ACCESS
Note
More information on microflow policing can be found at the following URLs:
–
–
Note
Following is an example of the warning message:
001244: *Jun 13 09:33:22.426 mst: %FM_EARL7-2-IPV6_PORT_QOS_MCAST_FLOWMASK_CONFLICT: IPv6 QoS Micro-flow policing configuration on port GigabitEthernet3/1 conflicts for flowmask with IPv6 multicast hardware forwarding on SVI interface Vlan2, IPv6 traffic on the SVI interface may be switched in software.
001245: *Jun 13 09:33:22.430 mst: %FM_EARL7-4-FEAT_QOS_FLOWMASK_CONFLICT: Features configured on interface Vlan2 conflict for flowmask with QoS configuration on switch port GigabitEthernet3/1, traffic may be switched in software.
•
More information on CoPP can be found at the following URL: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/dos.html
•
ipv6 access-list HOST_PACLremark Deny Rogue DHCPdeny udp any eq 547 any eq 546remark Deny RA From Clientdeny icmp any any router-advertisementpermit ipv6 any any!interface GigabitEthernet1/0/6ipv6 traffic-filter HOST_PACL inThe following shows an example of RA Guard:
interface GigabitEthernet1/0/6ipv6 nd raguardMore information on IPv6 security can be found in Additional References.
Multicast
IPv6 multicast is an important service for any enterprise network design, and IPv6 multicast requirements may cause the reader to re-consider the models discussed in this document. The most important issue to understand with IPv6 multicast and the various models is that IPv6 multicast is not supported over ISATAP. This is not a limitation of equipment or software, but rather a shortcoming of the ISATAP tunneling mechanism (RFC4214).
One of the most important factors to consider in IPv6 multicast deployment is to ensure that host/group control is handled properly in the access layer. Multicast Listener Discovery (MLD) in IPv6 is the equivalent to Internet Group Management Protocol (IGMP) in IPv4. Both are used for multicast group membership control. MLD Snooping is the feature that enables Layer 2 switches to control the distribution of multicast traffic only to the ports that have listeners. Without it, multicast traffic meant for only a single receiver (or group of receivers) is flooded to all ports on an access layer switch. In the access layer, it is important that the switches support MLD Snooping for MLD version 1 and/or version 2 (this is only applicable when running dual-stack at the access layer).
Note
In this document, IPv6 multicast-enabled applications are supported in the DSM because no ISATAP configurations are used. The multicast-enabled application tested in this design is Windows Media Services with Embedded-RP and/or PIM-SSM groups. The multicast sources are running on Microsoft Windows Server 2008 servers located in the data center.
Several documents on cisco.com and within the industry discuss IPv6 multicast in detail. No other configuration notes are made in this document except for generic references to the commands to enable IPv6 multicast.
For more information, see:
•
•
Network and Address Management
Network Management
Many of the traditional management tools used today support IPv6 in much the same way as IPv4. In this document, the only considerations for management of the campus network are related to basic management services (Telnet, SSH, and SNMP). SNMP over IPv6 transport is supported on the latest versions of the software, depending on the Catalyst platform. Refer to the platform documentation for support for SNMP over IPv6 transport.
Address Management
Another area of management that the reader must thoroughly research is that of address management. Anyone who analyzes IPv6 even at an elementary level understands the size and potential complexity of deploying and managing the IPv6 address structure. Deploying large hexadecimal addresses on many network devices should, at some point, be automated or at least more user-friendly than it is today. Several efforts are underway within the industry to provide recommendations and solutions to the address management issues. Cisco is in the forefront of this effort.
Today, one way to help with the deployment of address prefixes on a campus switch is through the use of the "general prefix" feature. The general prefix feature allows the customer to define a prefix or prefixes in the global configuration of the switch with a user-friendly name. That user-friendly name can be used on a per-interface basis to replace the usual IPv6 prefix definition on the interface. Following is an example of how to use the general prefix feature:
•
6k-agg-1(config)#ipv6 general-prefix ESE-DC-1 2001:DB8:CAFE::/48•
6k-agg-1(config-if)#ipv6 address ESE-DC-1 ::10:0:0:F1A1:6500/64•
6k-agg-1#show ipv6 interface vlan 10Vlan10 is up, line protocol is upIPv6 is enabled, link-local address is FE80::211:BCFF:FEC0:C800Description: VLAN-SERVERFARM-WEBGlobal unicast address(es):2001:DB8:CAFE:10::F1A1:6500, subnet is 2001:DB8:CAFE:10::/64
Note
More information on the general prefix feature can be found at the Cisco IOS IPv6 documentation page (see Additional References).
IPv6 address allocation to hosts located in the campus access layer can be assigned via SLAAC, static assignment or DHCPv6. DHCPv6 assignment is the predominant method that is desired by most enterprise campus administrators. Until support for DHCPv6 Relay was available on the Catalyst products, the administrator had no other choice but to rely on SLAAC as the primary means of allocating IPv6 addressing to hosts in the access layer.
Figure 9 shows that the placement of the DHCPv6 Relay is on the campus distribution layer switches, which is the same place as the IP helper used in DHCP for IPv4.
Figure 9 DHCPv6 Relay Placement in the Campus
The configuration of the DHCPv6 Relay feature is straightforward. Implement the following configuration on the VLAN interface facing the access layer hosts:
interface Vlan2description ACCESS-DATA-2ipv6 address 2001:DB8:CAFE:2::A111:1010/64ipv6 nd prefix 2001:DB8:CAFE:2::/64 0 0 no-autoconfigipv6 nd managed-config-flagipv6 dhcp relay destination 2001:DB8:CAFE:11::9The ipv6 dhcp relay destination command defines the unicast address of the DHCPv6 server. The ipv6 nd managed-config-flag command sets the "managed address configuration" flag in the RA so the host knows to use a stateful address configuration mechanism, such as DHCPv6. More information on DHCPv6 Relay Agent can be found at: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp_ps10591_TSD_Products_Configuration_Guide_Chapter.html.
Having DHCPv6 Relay Agent support in the network is only part of the equation. The client must support DHCPv6 (such as Microsoft Windows 7) and there must be a DHCPv6 server. When this document was written, Apple did not have DHCPv6 client support on its products. In designs where Apple products need addresses, SLAAC is still the method to be used.
Currently, there are three DHCPv6 servers that have been tested by Cisco in the campus:
•
•
•
Cisco supports the management of IPv6-enabled network devices via a variety of network management products to include DNS, DHCPv6, device management, and monitoring; and also network management, troubleshooting, and reporting. For more information on the various Cisco Network Management solutions, refer to the following URL: http://www.cisco.com/en/US/products/sw/netmgtsw/index.html
Scalability and Performance
This document is not meant to analyze scalability and performance information for the various platforms tested. The discussion of scale and performance is more focused on general considerations when planning and deploying IPv6 in the campus versus a platform-specific view.
In general, the reader should understand the link, memory, and CPU utilization of the existing campus network. If any of these aspects are already stressed, adding IPv6 or any new technology, feature, or protocol into the design is a recipe for disaster. However, it is common to see in IPv6 implementations a change in traffic utilization ratios on the campus network links. As IPv6 is deployed, IPv4 traffic utilization is very often reduced as users leverage IPv6 as the transport for applications that were historically IPv4-only. There is an increase in overall network utilization that usually derives from control traffic for routing and also tunnel overhead when ISATAP or manually-configured tunnels are used.
Scalability and performance considerations for the DSM are as follows:
•
ARP entry for host in the distribution layer:
Internet 10.120.2.200 2 000d.6084.2c7a ARPA Vlan2IPv6 neighbor cache entry:
2001:DB8:CAFE:2:2891:1C0C:F52A:9DF1 4 000d.6084.2c7a STALE Vl22001:DB8:CAFE:2:7DE5:E2B0:D4DF:97EC 16 000d.6084.2c7a STALE Vl2FE80::7DE5:E2B0:D4DF:97EC 16 000d.6084.2c7a STALE Vl2The neighbor cache shows that there are three entries listed for the host. The first address is one of two global IPv6 addresses assigned (optional) and reflects the global IPv6 address generated by the use of IPv6 privacy extensions. The second address is another global IPv6 address (optional) that is assigned by stateless autoconfiguration (it can also be statically defined or assigned via DHCPv6), and the third address is the link-local address (mandatory) generated by the host. The number of entries can decrease to a minimum of one (link-local address) to a multitude of entries for a single host, depending on the address types used on the host.
It is very important to understand the neighbor table capabilities of the routed access and distribution layer platforms being used to ensure that the tables are not being filled during regular network operation. Additional testing is planned to understand whether recommendations should be made to adjust timers to time out entries faster, to rate limit neighbor advertisements, and to better protect the access layer switch against DoS from IPv6 neighbor discovery-based attacks.
Another consideration is with IPv6 multicast. As mentioned previously, it is important to ensure that MLD Snooping is supported at the access layer when IPv6 multicast is used to ensure that IPv6 multicast frames at Layer 2 are not flooded to all the ports.
•
–
–
•
Scalability and performance considerations for the HM are as follows:
•
•
•
–
–
–
Scalability and performance considerations for the SBM are as follows:
•
•
•
•
Dual-Stack Model—Implementation
This section is focused on the configuration of the DSM. The configurations are divided into specific areas such as VLAN, routing, and HA configuration. Many of these configurations such as VLANs and physical interfaces are not specific to IPv6. VLAN configurations for the DSM are the same for IPv4 and IPv6, but are shown for completeness. An example configuration is shown for only two switches (generally the pair in the same layer or a pair connecting to each other), and only for the section being discussed; for example, routing or HA.
Network Topology
The following diagrams are used as a reference for all DSM configuration examples. Figure 10 shows the physical port layout that is used for the DSM.
Figure 10 DSM Network Topology—Physical Ports
Figure 11 shows the IPv6 addressing plan for the DSM environment. To keep the diagram as simple to read as possible, the /48 prefix portion of the network is deleted. The IPv6 /48 prefix used in all the models in this paper is "2001:db8:cafe::/48".
Figure 11 DSM Network Topology—IPv6 Addressing
In addition to the physical interfaces, IPv6 addresses are assigned to loopback and VLAN interfaces. Table 6 shows the switch, interface, and IPv6 address for the interface.
Physical/VLAN Configuration
Physical p2p links are configured in much the same way as IPv4. The following example is the p2p interface configuration for the link between 6k-dist-1 and 6k-core-1.
•
ipv6 unicast-routing #Globally enable IPv6 unicast routingip cef distributed #Ensure IP CEF is enabled (req. for#IPv6 CEF to run).ipv6 cef distributed #Globally enable IPv6 CEF.!interface GigabitEthernet4/1description to 6k-core-1ipv6 address 2001:DB8:CAFE:7000::A111:1010/64 #Assign IPv6 addressipv6 nd suppress-ra #Disable RAs on this interface•
ipv6 unicast-routingip cef distributedipv6 cef distributed!interface GigabitEthernet2/4description to 6k-dist-1ipv6 address 2001:DB8:CAFE:7000::C333:3030/64ipv6 nd suppress-raOn the Catalyst 3750 and 3560 switches, it is required to enable the correct Switch Database Management (SDM) template to allow the ternary content addressable memory (TCAM) to be used for different purposes. The 3750-acc-1 has been configured with the "dual-ipv4-and-ipv6" SDM template using the sdm prefer dual-ipv4-and-ipv6 default command. For more information about the sdm prefer command and associated templates, see: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_55_se/configuration/guide/swsdm.html.
The access layer uses a single VLAN per switch; voice VLANs are not discussed. The VLANs do not span access layer switches and are terminated at the distribution layer. The following example is of the 3750-acc-1 and 6k-dist-1 VLAN2 configuration.
•
vtp domain ese-dcvtp mode transparent! #VTP and STP configurations! #shown for completeness, but not! #specific to IPv6spanning-tree mode rapid-pvstspanning-tree loopguard defaultspanning-tree portfast bpduguard defaultno spanning-tree optimize bpdu transmissionspanning-tree extend system-id!vlan internal allocation policy ascending!vlan 2name ACCESS-DATA-2!interface GigabitEthernet1/0/25 #Physical intf. to 6k-dist-1description TRUNK TO 6k-dist-1switchport trunk encapsulation dot1qswitchport trunk allowed vlan 2switchport mode trunkswitchport nonegotiate!interface Vlan2 #VLAN2 with IPv6 address used for mgmt.ipv6 address 2001:DB8:CAFE:2::CAC1:3750/64•
vtp domain ese-dcvtp mode transparent!spanning-tree mode rapid-pvstspanning-tree loopguard defaultno spanning-tree optimize bpdu transmissionspanning-tree extend system-idspanning-tree vlan 2-3 priority 24576 #6k-dist-1 is the STP root for #VLAN2,3!vlan internal allocation policy descendingvlan dot1q tag native!vlan 2name ACCESS-DATA-2!vlan 3name ACCESS-DATA-3!interface GigabitEthernet3/1 #Physical intf. to 3750-acc-1description to 3750-acc-1switchportswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 2switchport mode trunkswitchport nonegotiateno ip addressspanning-tree guard root!interface Vlan2 #VLAN2 termination#point for trunked VLAN from 3750-acc-1description ACCESS-DATA-2ipv6 address 2001:DB8:CAFE:2::A111:1010/64ipv6 nd prefix 2001:DB8:CAFE:2::/64 0 0 no-autoconfigipv6 nd managed-config-flag #Enable "managed" flag for DHCPv6ipv6 dhcp relay destination 2001:DB8:CAFE:11::9 #Define the DHCPv6 server addressAlthough switch stacks are not used in any of the models discussed here, they are commonly used on the Catalyst 3750 series in the access layer. IPv6 is supported in much the same way as IPv4 when using switch stacks. For more information on IPv6 with switch stacks, refer to: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_55_se/configuration/guide/swstack.html.
Routing Configuration
As previously mentioned, the routing for the DSM is set up using EIGRP for both IPv4 and IPv6. The EIGRP configuration follows the recommended Cisco campus designs as much as possible. The configuration for EIGRP for IPv6 is shown for the 6k-dist-1 and 6k-core-1 switches.
•
key chain eigrpkey 100key-string 7 1111!interface Loopback0ip address 10.122.10.9 255.255.255.255 #Address used for RID on EIGRPipv6 address 2001:DB8:CAFE:6507::A111:1010/128ipv6 eigrp 10!interface TenGigabitEthernet1/1description to 4k-dist-2ipv6 address 2001:DB8:CAFE:7004::A111:1010/64ipv6 eigrp 10ipv6 hello-interval eigrp 10 1ipv6 hold-time eigrp 10 3ipv6 authentication mode eigrp 10 md5ipv6 authentication key-chain eigrp 10 eigrp!interface GigabitEthernet4/1description to 6k-core-1ipv6 address 2001:DB8:CAFE:7000::A111:1010/64ipv6 eigrp 10ipv6 hello-interval eigrp 10 1ipv6 hold-time eigrp 10 3ipv6 authentication mode eigrp 10 md5ipv6 authentication key-chain eigrp 10 eigrp!interface GigabitEthernet4/2description to 6k-core-2ipv6 address 2001:DB8:CAFE:7001::A111:1010/64ipv6 eigrp 10ipv6 hello-interval eigrp 10 1ipv6 hold-time eigrp 10 3ipv6 authentication mode eigrp 10 md5ipv6 authentication key-chain eigrp 10 eigrp!interface Vlan2description ACCESS-DATA-2ipv6 address 2001:DB8:CAFE:2::A111:1010/64ipv6 eigrp 10!ipv6 router eigrp 10router-id 10.122.10.9 #RID using Loopback0no shutdownpassive-interface Vlan2 #Do not establish adjacency over#VLANspassive-interface Vlan3passive-interface Loopback0•
key chain eigrpkey 100key-string 7 1111!interface Loopback0ip address 10.122.10.3 255.255.255.255ipv6 address 2001:DB8:CAFE:6507::C333:3030/128ipv6 eigrp 10!interface GigabitEthernet2/1description to 6k-agg-1ipv6 address 2001:DB8:CAFE:7005::C333:3030/64ipv6 eigrp 10ipv6 hello-interval eigrp 10 1ipv6 hold-time eigrp 10 3ipv6 authentication mode eigrp 10 md5ipv6 authentication key-chain eigrp 10 eigrp!interface GigabitEthernet2/4description to 6k-dist-1ipv6 address 2001:DB8:CAFE:7000::C333:3030/64ipv6 eigrp 10ipv6 hello-interval eigrp 10 1ipv6 hold-time eigrp 10 3ipv6 authentication mode eigrp 10 md5ipv6 authentication key-chain eigrp 10 eigrp!ipv6 router eigrp 10router-id 10.122.10.3no shutdownpassive-interface Loopback0It is important to read and understand the implications of modifying various IGP timers. The campus network should be designed to converge as fast as possible. The campus network is also capable of running much more tightly-tuned IGP timers than in a branch or WAN environment. The routing configurations shown are based on the Cisco campus recommendations. The reader should understand the context of each command and the timer value selection before pursuing the deployment in a live network. Refer to Additional References for links to the Cisco campus design best practice documents.
High-Availability Configuration
The HA design in the DSM consists of running two of each switches (applicable in the distribution, core, and data center aggregation layers) and ensuring that the IPv4 and IPv6 routing configurations are tuned and completely fault-tolerant. All distribution pairs in the reference campus configuration are running HSRP for both IPv4 and IPv6. Optionally, GLBP can be used. The configuration for HSRP for IPv4 and IPv6 on the 6k-dist-1switch is shown below:
•
interface Vlan2description ACCESS-DATA-2standby version 2 #Standby Version 2 is required for IPv6 supportstandby 1 ip 10.120.2.1standby 1 timers msec 250 msec 750standby 1 priority 110standby 1 preempt delay minimum 180standby 1 authentication esestandby 2 ipv6 autoconfig #Allow the system to self-generate the IPv6#virtual addressstandby 2 timers msec 250 msec 750standby 2 priority 110standby 2 preempt delay minimum 180standby 2 authentication eseQoS Configuration
The policies for classification, marking, queuing, and policing vary greatly based on the customer service requirements. The types of queuing and number of queues supported also vary between platform-to-platform and line card-to-line card. The examples shown below are very basic and not meant to be a best practice recommendation.
The example shown below is doing classification/marking of Microsoft Windows Media Services on TCP 1755. The traffic is set to AF31 (DSCP 26) with basic policing and queuing applied.
Your own policies will differ from these. For the sake of brevity, not all interfaces are shown.
•
mls qos map policed-dscp 46 to 8mls qos map policed-dscp 26 to 28 #Policed DSCP QoS map 26 (AF31) to 28 mls qos srr-queue input threshold 1 40 60mls qos srr-queue input threshold 2 40 60mls qos srr-queue input buffers 33 67mls qos srr-queue input priority-queue 1 bandwidth 33mls qos srr-queue input dscp-map queue 1 threshold 3 46mls qos srr-queue input dscp-map queue 2 threshold 1 8mls qos srr-queue input dscp-map queue 2 threshold 2 0mls qos srr-queue input dscp-map queue 2 threshold 3 26 28mls qos srr-queue output dscp-map queue 1 threshold 3 46mls qos srr-queue output dscp-map queue 2 threshold 1 28mls qos srr-queue output dscp-map queue 2 threshold 3 26 #Queue/Drop threshold for#AF31mls qos srr-queue output dscp-map queue 3 threshold 3 0mls qos srr-queue output dscp-map queue 4 threshold 3 8mls qos queue-set output 1 threshold 1 100 100 100 100mls qos queue-set output 1 threshold 2 10 70 100 100mls qos queue-set output 1 threshold 3 100 100 100 100mls qos queue-set output 1 threshold 4 100 100 100 100mls qos queue-set output 1 buffers 33 25 37 5mls qos!class-map match-all IPV6-STREAMmatch access-group name IPV6-STREAM-DATA!policy-map TEST-CLASS #Basic policy to police/Classifyclass IPV6-STREAM #Windows Media trafficpolice 37500000 80000 exceed-action policed-dscp-transmitset dscp af31class class-defaultset dscp default !interface GigabitEthernet1/0/25description to Distribution Layersrr-queue bandwidth share 1 25 70 5srr-queue bandwidth shape 3 0 0 0priority-queue outmls qos trust dscp!interface GigabitEthernet1/0/7description to Access Portsrr-queue bandwidth share 1 25 70 5srr-queue bandwidth shape 3 0 0 0priority-queue outmls qos trust device cisco-phoneservice-policy input TEST-CLASS #Apply policy ingress from access port!ipv6 access-list IPV6-STREAM-DATA #Example ACL for Windows Mediapermit tcp any any eq 1755•
mls qos!interface GigabitEthernet3/1description to 3750-acc-1wrr-queue bandwidth 5 25 70wrr-queue queue-limit 5 25 40wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100wrr-queue random-detect min-threshold 2 80 100 100 100 100 100 100 100wrr-queue random-detect min-threshold 3 50 60 70 80 90 100 100 100wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100wrr-queue random-detect max-threshold 3 60 70 80 90 100 100 100 100wrr-queue cos-map 1 1 1wrr-queue cos-map 2 1 0wrr-queue cos-map 3 1 4wrr-queue cos-map 3 2 2wrr-queue cos-map 3 3 3 #Queue 3 WRED Threshold 3wrr-queue cos-map 3 4 6wrr-queue cos-map 3 5 7mls qos trust dscp #Trust DSCP markings!interface GigabitEthernet4/1description to 6k-core-1wrr-queue bandwidth 5 25 70wrr-queue queue-limit 5 25 40wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100wrr-queue random-detect min-threshold 2 80 100 100 100 100 100 100 100wrr-queue random-detect min-threshold 3 50 60 70 80 90 100 100 100wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100wrr-queue random-detect max-threshold 3 60 70 80 90 100 100 100 100wrr-queue cos-map 1 1 1wrr-queue cos-map 2 1 0wrr-queue cos-map 3 1 4wrr-queue cos-map 3 2 2wrr-queue cos-map 3 3 3wrr-queue cos-map 3 4 6wrr-queue cos-map 3 5 7mls qos trust dscpMulticast Configuration
IPv6 multicast is fully supported in the DSM. Although IPv6 multicast design is outside the scope of this document, configurations are shown for IPv6 multicast on the 3750-acc-1, 6k-dist-1, 6k-core-1, and 6k-agg-1 (acting as RP) switches. Most of the configuration examples are trivial, but are shown from the access layer to the aggregation layer for operational consistency.
•
ipv6 mld snooping #Globally enable MLD snooping (see note below)•
ipv6 multicast-routing #Globally enable IPv6 multicast routing•
ipv6 multicast-routing•
ipv6 multicast-routing!ipv6 pim rp-address 2001:DB8:CAFE:10::e555:5050 ERP #Embedded-RP is being used#which requires the local#definition of the RP.#This command line states#that this switch (v6 address#on VLAN10) is the RP for any#group permitted in the ACL#ERP!ipv6 access-list ERP #ACL to permit Embedded-RP group range#FF7E:140:2001:DB8:CAFE:10::/96permit ipv6 any FF7E:140:2001:DB8:CAFE:10::/96 log-inputThe first thing to understand is the lack of CLI input required to enable IPv6 multicast when using PIM-SSM or Embedded-RP. If PIM-SSM is used exclusively, it is only required to enable ipv6 multicast-routing globally, which automatically enables PIM on all IPv6-enabled interfaces. This is a dramatic difference from what is required with IPv4 multicast.
The Layer 2 switch (3750-acc-1) needs to have IPv6 multicast awareness to control the distribution of multicast traffic only on ports that are actively listening. This is accomplished by enabling MLD Snooping. With MLD Snooping enabled on the 3750-acc-1 switch and with IPv6 multicast routing enabled on the 6k-dist-1 (and 6k-dist-2) switch, it can be seen that the 3750-acc-1 can see both distribution layer switches as locally attached multicast routers.
3750-acc-1#sh ipv6 mld snooping mrouterVlan ports---- -----2 Gi1/0/25(dynamic), Gi1/0/26(dynamic)When a group is active on the access layer switch, information about the group can be displayed:
3750-acc-1#show ipv6 mld snooping addressVlan Group Type Version Port List-------------------------------------------------------------2 FF35::1111 mld v2 Gi1/0/25, Gi1/0/26On the 6k-dist-1, information about PIM, multicast route, RPF, and groups can be viewed in much the same way as with IPv4. Following is the output of an active group using PIM-SSM (FF35::1111). This stream is coming in from the 6k-core-1 switch and going out the VLAN2 (3750-acc-1) interface:
6k-dist-1#show ipv6 mroute #"show ipv6 pim topology" can also be usedMulticast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,C - Connected, L - Local, I - Received Source Specific Host Report,P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,J - Join SPTTimers: Uptime/ExpiresInterface state: Interface, State(2001:DB8:CAFE:11:2E0:81FF:FE2C:9332, FF35::1111), 19:58:58/never, flags: sTIIncoming interface: GigabitEthernet4/1RPF nbr: FE80::215:C7FF:FE24:7440Immediate Outgoing interface list:Vlan2, Forward, 19:58:58/neverRouted Access Configuration
The primary change to the campus implementation when using the routed access design applies to the access and distribution layer configurations. With the routed access design, the access layer performs routing where the previous (traditional) design had the access layer as a Layer 2-only component and the first Layer 3 component was in the distribution layer. This guide is not meant to discuss the advantages and disadvantages of the routed access design. However, the failover performance improvements realized along with the important fact that spanning tree is not an active component, make this design attractive to many customers. Because of customer demand, performance, and operational advantages with the routed access design, this paper discusses implementing IPv6 in this design.
Extending the DSM to now be a routed access design is quite easy. The removal of dependency on a redundant first-hop protocol is also a major improvement in the access layer. Basically, the access layer switches enable IPv6 routing and change the trunk links to routed links, and the distribution layer switches remove the trunks and VLANs for the access layer.
Figure 12 shows the updated DSM topology that has the routed access component included. Because nothing has changed upstream of the distribution layer, this diagram includes only the changed layers, which are the access and distribution layers.
Figure 12 DSM Topology—Routed Access Design
Figure 12 shows that the links between the access layer and distribution layer are now routed links instead of trunked Layer 2 links. IPv6 addressing and routing is configured on the new links, and the hosts in the VLANs use the IPv6 address of the VLAN interface on the access switch as the default gateway. Because the VLAN is terminated on the access layer switch, there is no need for a first hop redundancy protocol like HSRP. Availability is provided by routing between the access and distribution layers.
Note
The following configuration example shows the relevant configurations for the 3750-acc-1 and 6k-dist-1 switches.
•
ipv6 unicast-routing!interface GigabitEthernet1/0/25description To 6k-dist-1ipv6 address 2001:DB8:CAFE:700A::CAC1:3750/64ipv6 nd suppress-raipv6 ospf network point-to-point #OSPFv3 is configuredipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 2mls qos trust dscp!interface Vlan2ipv6 address 2001:DB8:CAFE:2::CAC1:3750/64 #VLAN2 on this switch becomes the#first layer 3 hop for the hosts#in VLAN2 - the link-local address#on VLAN 2 will be the default#gateway for the hostsipv6 ospf 1 area 2!ipv6 router ospf 1router-id 10.120.2.1log-adjacency-changesauto-cost reference-bandwidth 10000area 2 stub no-summary #Per the Routed Access Design guide - the#area (area 2) for the access layer#prefix is a totally stubby areapassive-interface Vlan2timers spf 1 5•
interface GigabitEthernet3/1description to 3750-acc-1ipv6 address 2001:DB8:CAFE:700A::A111:1010/64ipv6 nd suppress-raipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 2mls qos trust dscp!ipv6 router ospf 1router-id 10.122.10.9log-adjacency-changesauto-cost reference-bandwidth 10000area 2 stub no-summaryarea 2 range 2001:DB8:CAFE:2::/64 cost 10 #Send a summary into area 0 for#prefix "2" in area 2area 2 range 2001:DB8:CAFE:3::/64 cost 10area 2 range 2001:DB8:CAFE:7004::/64 cost 10area 2 range 2001:DB8:CAFE:700A::/64 cost 10area 2 range 2001:DB8:CAFE:700B::/64 cost 10passive-interface Loopback0timers spf 1 5The output of the show ipv6 route command for the 3750-acc-1 shows a default route coming from the two distribution layer switches (the default is injected by the upstream switches where the Internet edge connects to the core layer):
3750-acc-1#show ipv6 routeIPv6 Routing Table - 13 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGPU - Per-user Static routeI1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summaryO - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2OI ::/0 [110/11]via FE80::213:5FFF:FE1F:F840, GigabitEthernet1/0/26 #4k-dist-2via FE80::215:C7FF:FE25:9580, GigabitEthernet1/0/25 #6k-dist-1C 2001:DB8:CAFE:2::/64 [0/0]via ::, Vlan2L 2001:DB8:CAFE:2::CAC1:3750/128 [0/0]via ::, Vlan2
Note
The other configuration change that is made in the DSM when using the routed access design is with IPv6 multicast. Now that the access layer switch is actually routing, the switch needs to be configured to support PIM of whatever variety is used in the rest of the network. The previous multicast configurations shown for the 6k-dist-1 would work for generic PIM-SSM or PIM-SM with Embedded-RP. It is important to note that the customer needs to validate which access layer platforms have IPv6 multicast routing support and in which code version.
Additional information on the Cisco routed access design can be found at the following URLs:
•
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns815/landing_cHi_availability.html•
http://www.cisco.com/en/US/netsol/ns340/ns394/ns147/ns17/networking_solutions_white_paper0900aecd804c6e73.shtmlHybrid Model
Most of the campus network in the HM is IPv4-only. The IPv6 part of the campus network begins in the core layer. This section shows the core layer configuration as well as the basic ISATAP configuration on the host. As mentioned previously, the HM uses dual-stack from the core layer into the data center. Those configurations are not relevant to the HM because the configurations are the same as those in the DSM. As with the DSM implementation section, configuration snippets for each aspect of the deployment are shown in this section.
Network Topology
One difference in the HM topology is that the distribution layer is using a pair of Catalyst 3750 switches instead of the Catalyst 6500. This is not because of any particular issue or recommendation, but just the way the test lab is configured. Figure 13 shows the network topology for the HM.
Figure 13 HM Network Topology
The topology is focused on the IPv4 addressing scheme in the access layer (used by the host to establish the ISATAP tunnel), core layer (used as the termination point by the host for ISATAP), and also the IPv6 addressing used in the core layer for both the p2p link and the ISATAP tunnel prefix. The configuration shows that the ISATAP access high availability is accomplished by using redundantly configured loopback interfaces that share the same IPv4 address between both core switches. To maintain prefix consistency for the ISATAP hosts in the access layer, the same prefix is used on both the primary and backup ISATAP tunnels.
Physical Configuration
The configurations for both core layer switches are shown and include only the distribution and core layer-facing interfaces. Configurations for the IPv4 portion of the distribution and access layer are based on existing campus design best practices and are not discussed in this section.
•
interface GigabitEthernet1/1description to 3750-dist-1ip address 10.122.0.41 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3mls qos trust dscp!interface GigabitEthernet1/2description to 3750-dist-2ip address 10.122.0.45 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3mls qos trust dscp!interface GigabitEthernet2/3description to 6k-core-2ip address 10.122.0.21 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ipv6 address 2001:DB8:CAFE::c333:3030/64 #p2p link between core switchesipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0mls qos trust dscp•
interface GigabitEthernet1/1description to 3750-dist-1ip address 10.122.0.49 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3mls qos trust dscp!interface GigabitEthernet1/2description to 3750-dist-2ip address 10.122.0.53 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3mls qos trust dscp!interface GigabitEthernet2/3description to 6k-core-1ip address 10.122.0.22 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ipv6 address 2001:DB8:CAFE::d444:4040/64ipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0mls qos trust dscpTunnel Configuration
The ISATAP configuration at the tunnel level is relatively straightforward, but the potentially confusing part relates to the high availability design for the ISATAP tunnels. The basic configuration of ISATAP on a host consists of enabling IPv6 and configuring the ISATAP router name or IPv4 address. By default, Microsoft Windows performs a DNS query of "isatap.domain.com", where "domain.com" is the local domain name. If a DNS "A" record for "isatap" has been configured, the host begins to establish an ISATAP tunnel to that address. This default configuration works fine until something happens to the ISATAP router or the path to that router. All the configurations discussed in this paper include the ability to provide fault tolerance of IPv6 services as optimally as possible.
Providing high availability for ISATAP is crucial in the HM environment. Several methods provide redundancy of the ISATAP routers. The method discussed in this guide uses the two core layer switches to provide very fast failover of the ISATAP tunnels. The other method commonly used relies on DNS. Although the DNS method is faster to implement, it is also the most limiting in the overall IPv6 campus design and is the slowest for failover.
It is important to ensure that the tunnel destination (from the host point of view) is redundant across both core switches, and to ensure that both IPv4 and IPv6 routing is configured properly.
Note
One question commonly asked is: Should I have deterministic routing from the distribution layer (IPv4) to one ISATAP router or is there any value in load balancing? The following considerations apply:
•
•
To maintain low convergence times for ISATAP tunnels when a core layer switch fails, it is important to provide redundant and duplicated tunnel addresses across both core switches. When this is done, only one ISATAP router address or name is needed on the host, and DNS round-robin is not required. The following steps describe this process:
1.
2.
3.
4.
5.
To keep the ISATAP tunnels, HA, and routing configurations simple to understand, they are shown together.
For the sake of simplicity, the only configuration shown is that of the tunnels for VLAN2. The tunnels for VLAN3 are the same except for addressing specifics.
The following configurations illustrate the five steps described above.
•
interface Loopback2description Tunnel source for ISATAP-VLAN2ip address 10.122.10.102 255.255.255.255 #Address that will be used as the #ISATAP tunnel2 source!interface Tunnel2description ISATAP VLAN2no ip addressno ip redirectsipv6 address 2001:DB8:CAFE:2::/64 eui-64 #Tunnel prefix used for ISATAP#hosts connecting to this tunnel.#Interface-ID address for this#switch will be generated using#EUI-64no ipv6 nd suppress-ra #Tunnel interfaces disable the#sending of RA's. This command#re-enables RA'sipv6 ospf 1 area 2tunnel source Loopback2 #Tunnel2 uses loopback2 as the#sourcetunnel mode ipv6ip isatap #Define the tunnel as ISATAP!router eigrp 10passive-interface Loopback0passive-interface Loopback1passive-interface Loopback2passive-interface Loopback3network 10.0.0.0no auto-summaryeigrp router-id 10.122.10.9!ipv6 router ospf 1router-id 10.122.10.9log-adjacency-changesauto-cost reference-bandwidth 10000area 2 range 2001:DB8:CAFE:2::/64 cost 10 #Advertise a summary for the prefix on#Tunnel2 - just like a VLAN prefix#would be sent in the DSMarea 2 range 2001:DB8:CAFE:3::/64 cost 10passive-interface Loopback0passive-interface Loopback2passive-interface Loopback3passive-interface Tunnel2passive-interface Tunnel3timers spf 1 5•
interface Loopback2description Tunnel source for ISATAP-VLAN2ip address 10.122.10.102 255.255.255.255delay 1000 #Delay adjusted for EIGRP (IPv4)#in order to adjust preference#for the 10.122.10.102 host#route. This ensures that#6k-core-2 is SECONDARY to 6k-core-1!interface Tunnel2description ISATAP VLAN2no ip addressno ip redirectsipv6 address 2001:DB8:CAFE:2::/64 eui-64no ipv6 nd suppress-raipv6 ospf 1 area 2tunnel source Loopback2tunnel mode ipv6ip isatap!router eigrp 10passive-interface Loopback0passive-interface Loopback1passive-interface Loopback2passive-interface Loopback3network 10.0.0.0no auto-summaryeigrp router-id 10.122.10.10!ipv6 router ospf 1router-id 10.122.10.10log-adjacency-changesauto-cost reference-bandwidth 10000area 2 range 2001:DB8:CAFE:2::/64 cost 20 #Cost for prefix adjusted so that#the route from 6k-core-2 is not#preferred or equal to 6k-core-1#Not required.area 2 range 2001:DB8:CAFE:3::/64 cost 20passive-interface Loopback0passive-interface Loopback2passive-interface Loopback3passive-interface Tunnel2passive-interface Tunnel3timers spf 1 5Figure 14 shows the IPv4 routing view from the distribution layer switches to the ISATAP tunnels interfaces (loopbacks on core switches). Loopback2 on 6k-core-1 is set as the primary ISATAP router address for the host. As shown in the previous IPv4 IGP configuration, 6k-core-2 is configured to have the host route of 10.122.10.102 have a higher delay and therefore is not preferred. When a packet arrives from the host in VLAN2 for the ISATAP router (10.122.10.102), a lookup is performed in the distribution layer switch for 10.122.10.102 and the next hop for that address is 6k-core-1.
Figure 14 HM—Preferred Route for 6k-core-1
The routing table 10.122.10.102 on the distribution layer switches is as follows:
•
3750-dist-1#show ip route | b 10.122.10.102/32D 10.122.10.102/32[90/130816] via 10.122.0.41, 00:09:23, GigabitEthernet1/0/27 #3750-dist-1#has only one#route for#10.122.10.102#which is via#10.122.0.41#6k-core-1)•
3750-dist-1#show ip route | b 10.122.10.102/32D 10.122.10.102/32[90/130816] via 10.122.0.45, 00:10:03, GigabitEthernet1/0/27Figure 15 shows that 6k-core-1 has failed and therefore the route to loopback2 (10.122.10.102) is no longer available. When the 6k-core-1 route is removed, the new route for 10.122.10.102 is used and packets are then forwarded to 6k-core-2.
Figure 15 HM—Preferred Route for 6k-core-2 After Failure of 6k-core-1
The updated routing table entry for 10.122.10.102 on the distribution layer switches is as follows:
•
3750-dist-1#show ip route | b 10.122.10.102/32D 10.122.10.102/32[90/258816] via 10.122.0.49, 00:00:08, GigabitEthernet1/0/28•
3750-dist-1#show ip route | b 10.122.10.102/32D 10.122.10.102/32[90/258816] via 10.122.0.53, 00:00:08, GigabitEthernet1/0/28The following two ways enable the host for ISATAP communication in the HM environment:
•
•
Using the ISATAP IPv4 router address method is straightforward, but difficult to scale without some kind of script or host management tools. As previously mentioned, various tools such as Microsoft Group Policy and Windows PowerShell can be used to run the command locally on the host at login or another predetermined time.
On the Microsoft Windows hosts in VLAN 2, ISATAP is enabled and the IPv4 ISATAP router address is defined (IPv6 has already been enabled on the host). As previously mentioned, the HM design maps the host in a VLAN/subnet to a specific ISATAP router address. Here the host is in VLAN 2, which is in the 10.120.2.0/24 subnet and is therefore configured to use the ISATAP router of 10.122.10.102 where the "2" in "102" signifies VLAN or Subnet 2. The same would happen for VLAN 3 or 10.120.3.0/24 where the ISATAP router is 10.122.10.103:
C:\>netsh interface ipv6 isatap set router 10.122.10.102 enabledOk.The following command can be used to verify that the address has been accepted:
C:\>netsh interface ipv6 isatap show routerRouter Name : 10.122.10.102Use Relay : enabledResolution Interval : defaultThe host has successfully established an ISATAP connection to the primary core layer switch (6k-core-1) and received a valid prefix (2001:db8:cafe:2:0:5efe:10.120.2.101). ISATAP uses the IPv4 address on the host as the right-most 32-bit portion of the 64-bit interface ID. ISATAP "pads" the left-most 32-bits of the 64-bit interface ID with "0000:5efe" or "0200:5efe" (if using public IPv4 addresses). The IPv4 address (10.120.2.101) is used as the tunnel source on the host side of the tunnel, and loopback2 (10.122.10.102) on the core layer switches is used as the tunnel destination (previously configured ISATAP router address) for the host.
The tunnel adapter automatic tunneling pseudo-interface is as follows:
Connection-specific DNS Suffix . :IP Address. . . . . . . . . . . . : 2001:db8:cafe:2:0:5efe:10.120.2.101IP Address. . . . . . . . . . . . : fe80::5efe:10.120.2.101%2Default Gateway . . . . . . . . . : fe80::5efe:10.122.10.102%2Using the ISATAP IPv4 router name method is also straightforward, but requires DNS entries. It is also difficult to scale without some kind of script or host management tools. As previously mentioned, various tools such as PowerShell or login scripts can be used to run the command locally on the host at time of login or another predetermined time.
In this example, a name is used for the ISATAP router instead of an ISATAP IPv4 address. The default DNS name that ISATAP tries to resolve is "isatap" along with the domain suffix. For example, if this host is in domain "cisco.com", the host attempts to resolve "isatap.cisco.com". The user has the capability to alter this name similarly to altering the address selection.
C:\>netsh interface ipv6 isatap set router vlan2-isatap enabledOk.C:\>netsh interface ipv6 isatap show routerRouter Name : vlan2-isatapUse Relay : enabledResolution Interval : defaultOn the DNS server, the following entries were made for the two VLANs shown in this document:
•
•
QoS Configuration
The QoS policies for HM should match the existing IPv4 policies. As previously mentioned, the HM presents a challenge with respect to where the IPv6 packets are classified and marked. The IPv6 packets are encapsulated within ISATAP tunnels all the way from the host in the access layer to the core layer, and IPv6 QoS policies cannot see the packets inside the tunnel. The first point where the IPv6 packets can have policies applied is at the egress interfaces of the core layer switches. The following configuration is meant as a simple example only and is not based on Cisco campus QoS recommendations. In this policy, class maps are used to match against IPv6 access lists as listed in Table 7.
The policy is applied on egress interfaces (upstream from the access layer). Upstream switches can trust these DSCP settings and also apply queuing and policing as appropriate (see Dual-Stack Model—Implementation).
•
mls qos!class-map match-all CAMPUS-BULK-DATAmatch access-group name BULK-APPSclass-map match-all CAMPUS-TRANSACTIONAL-DATAmatch access-group name TRANSACTIONAL-APPS!policy-map IPv6-ISATAP-MARKclass CAMPUS-BULK-DATAset dscp af11class CAMPUS-TRANSACTIONAL-DATAset dscp af21class class-defaultset dscp default!ipv6 access-list BULK-APPSpermit tcp any any eq ftppermit tcp any any eq ftp-data!ipv6 access-list TRANSACTIONAL-APPSpermit tcp any any eq telnetpermit tcp any any eq 22!interface GigabitEthernet2/1description to 6k-agg-1mls qos trust dscpservice-policy output IPv6-ISATAP-MARK!interface GigabitEthernet2/2description to 6k-agg-2mls qos trust dscpservice-policy output IPv6-ISATAP-MARK!interface GigabitEthernet2/3description to 6k-core-1mls qos trust dscpservice-policy output IPv6-ISATAP-MARKInfrastructure Security Configuration
In addition to the security configurations discussed in Addressing, the customer may want to further tighten IPv6 access control for ISATAP tunnels at the access layer. An access list can be applied to either a host port or an uplink/trunk port at the access layer. It is easier to manage the ACL at the uplink rather than configuring ACLs on each host port.
One access list that can be used is an ACL to permit tunnels from the hosts on the access switch to the ISATAP router address for that VLAN. For example, the following ACL permits the ISATAP tunnels (via protocol 41) only if their destination is 10.122.10.102 (the ISATAP router address previously configured). Again, this ACL can be applied on a specific host port on input (ip access-group 100 in) or an uplink trunk or routed port (ip access-group 100 out).
access-list 100 remark Permit approved IPv6-Tunnelsaccess-list 100 permit 41 any host 10.122.10.102access-list 100 deny 41 any any log-inputaccess-list 100 permit ip any anyService Block Model—Implementation
The ISATAP deployment on the SBM is nearly identical to that of HM. Both models deploy a redundant pair of switches used to provide fault tolerant termination of ISATAP tunnels coming from the hosts in the access layer. The only difference between the SBM and HM is that the SBM is using a new set of switches that are dedicated to terminating connections (ISATAP, configured tunnels, or dual-stack) while the HM uses the existing core layer switches for termination.
This section is focused on the configuration of the interfaces on the service block switches (physical and logical) as well as the data center aggregation layer tunnel interfaces (show only for completeness). The entire IPv4 network is the same as the one described in the HM configuration.
Also, the host configuration for the SBM is the same as HM because the ISATAP router addresses have to be reused in this example. Similar to the HM configuration section, the loopback, tunnel, routing, and high availability configurations are all presented.
Network Topology
To keep the diagrams simple to understand, the topology is separated into two parts: the ISATAP topology and the manually-configured tunnel topology.
Figure 16 shows the ISATAP topology for the SBM. The topology is focused on the IPv4 addressing in the access layer (used by the host to establish the ISATAP tunnel), the service block (used as the termination point for the ISATAP tunnels), and also the IPv6 addressing used in the service block for both the p2p link and the ISATAP tunnel prefix. The configuration shows that the ISATAP availability is accomplished by using loopback interfaces that share the same IPv4 address between both SBM switches. To maintain prefix consistency for the ISATAP hosts in the access layer, the same prefix is used on both the primary and backup ISATAP tunnels.
Figure 16 SBM ISATAP Network Topology
Figure 17 shows the manually-configured tunnel topology for the SBM. The topology diagram shows the loopback addresses on the service block switches (used as the tunnel source for configured tunnels) and the IPv6 addressing used on the manually-configured tunnel interfaces.
Figure 17 SBM Manually-Configured Tunnel Topology
Physical Configuration
The configurations for both service block switches are shown, including the core layer-facing interfaces. Configurations for the IPv4 portion of the above topology is shown only for the service block switches. All other IPv4 configurations are based on existing campus design best practices and are not discussed in this section.
•
interface GigabitEthernet4/1description to 6k-core-1ip address 10.122.0.78 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ip authentication mode eigrp 10 md5ip authentication key-chain eigrp 10 eigrpmls qos trust dscp!interface GigabitEthernet4/2description to 6k-core-2ip address 10.122.0.86 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ip authentication mode eigrp 10 md5ip authentication key-chain eigrp 10 eigrpmls qos trust dscp!interface GigabitEthernet4/3description to 6k-sb-2ip address 10.122.0.93 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ip authentication mode eigrp 10 md5ip authentication key-chain eigrp 10 eigrpipv6 address 2001:DB8:CAFE:6505::A111:1010/64 #p2p link between SBM switchesipv6 nd suppress-raipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0mls qos trust dscp•
interface GigabitEthernet4/1description to 6k-core-1ip address 10.122.0.82 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ip authentication mode eigrp 10 md5ip authentication key-chain eigrp 10 eigrpmls qos trust dscp!interface GigabitEthernet4/2description to 6k-core-2ip address 10.122.0.90 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ip authentication mode eigrp 10 md5ip authentication key-chain eigrp 10 eigrpmls qos trust dscp!interface GigabitEthernet4/3description to 6k-sb-1ip address 10.122.0.94 255.255.255.252ip hello-interval eigrp 10 1ip hold-time eigrp 10 3ip authentication mode eigrp 10 md5ip authentication key-chain eigrp 10 eigrpipv6 address 2001:DB8:CAFE:6505::B222:2020/64 #p2p link between SBM switchesipv6 nd suppress-raipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0mls qos trust dscpTunnel Configuration
The tunnel and routing configuration for ISATAP is exactly the same as for HM. The configurations are shown below, but to avoid repeating information presented in previous sections, none of the configurations for the ISATAP tunneling and routing are explained (see the HM example explanations).
The manually-configured tunnel configurations are shown for the service block switches. The tunnel configurations for the data center aggregation switches (6k-agg-1/6k-agg-2) are identical to the service block except for address specifics.
•
interface Loopback0description Tunnel source for 6k-agg-1ip address 10.122.10.9 255.255.255.255!interface Loopback1description Tunnel source for 6k-agg-2ip address 10.122.10.19 255.255.255.255!interface Loopback2description Tunnel source for ISATAP-VLAN2ip address 10.122.10.102 255.255.255.255!interface Loopback3description Tunnel source for ISATAP-VLAN3ip address 10.122.10.103 255.255.255.255!interface Tunnel0description tunnel to DC 6k-agg-1no ip addressipv6 address 2001:DB8:CAFE:6501::A111:1010/64ipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0tunnel source Loopback0tunnel destination 10.122.10.1 #10.122.10.1 is loopback0 on 6k-agg-1tunnel mode ipv6ip!interface Tunnel1description tunnel to DC 6k-agg-2no ip addressipv6 address 2001:DB8:CAFE:6502::A111:1010/64ipv6 nd reachable-time 5000ipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0tunnel source Loopback1tunnel destination 10.122.10.2 #10.122.10.2 is loopback0 on 6k-agg-2tunnel mode ipv6ip!interface Tunnel2description ISATAP VLAN2no ip addressipv6 address 2001:DB8:CAFE:2::/64 eui-64no ipv6 nd suppress-raipv6 ospf 1 area 2tunnel source Loopback2tunnel mode ipv6ip isatap!interface Tunnel3description ISATAP VLAN3no ip addressipv6 address 2001:DB8:CAFE:3::/64 eui-64no ipv6 nd suppress-raipv6 ospf 1 area 2tunnel source Loopback3tunnel mode ipv6ip isatap!ipv6 router ospf 1router-id 10.122.10.9log-adjacency-changesauto-cost reference-bandwidth 10000area 2 range 2001:DB8:CAFE:2::/64 cost 10area 2 range 2001:DB8:CAFE:3::/64 cost 10passive-interface Loopback0passive-interface Loopback1passive-interface Loopback2passive-interface Loopback3passive-interface Tunnel2passive-interface Tunnel3timers spf 1 5•
interface Loopback0description Tunnel source for 6k-agg-1ip address 10.122.10.10 255.255.255.255!interface Loopback1description Tunnel source for 6k-agg-2ip address 10.122.10.20 255.255.255.255!interface Loopback2description Tunnel source for ISATAP-VLAN2ip address 10.122.10.102 255.255.255.255delay 1000!interface Loopback3description Tunnel source for ISATAP-VLAN3ip address 10.122.10.103 255.255.255.255delay 1000!interface Tunnel0description tunnel to 6k-agg-1no ip addressipv6 address 2001:DB8:CAFE:6503::B222:2020/64ipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf priority 255ipv6 ospf 1 area 0tunnel source Loopback0tunnel destination 10.122.10.11tunnel mode ipv6ip!interface Tunnel1description tunnel to 6k-agg-2no ip addressipv6 address 2001:DB8:CAFE:6504::B222:2020/64ipv6 ospf network point-to-pointipv6 ospf hello-interval 1ipv6 ospf dead-interval 3ipv6 ospf 1 area 0tunnel source Loopback1tunnel destination 10.122.10.12tunnel mode ipv6ip!interface Tunnel2description ISATAP VLAN2no ip addressip access-group 100 inno ip redirectsipv6 address 2001:DB8:CAFE:2::/64 eui-64no ipv6 nd suppress-raipv6 ospf 1 area 2tunnel source Loopback2tunnel mode ipv6ip isatap!interface Tunnel3description ISATAP VLAN3no ip addressno ip redirectsipv6 address 2001:DB8:CAFE:3::/64 eui-64no ipv6 nd suppress-raipv6 ospf 1 area 2tunnel source Loopback3tunnel mode ipv6ip isatap!ipv6 router ospf 1router-id 10.122.10.10log-adjacency-changesauto-cost reference-bandwidth 10000area 2 range 2001:DB8:CAFE:2::/64 cost 20area 2 range 2001:DB8:CAFE:3::/64 cost 20passive-interface Loopback0passive-interface Loopback1passive-interface Loopback2passive-interface Loopback3passive-interface Tunnel2passive-interface Tunnel3timers spf 1 5QoS Configuration
The same QoS configurations and discussions from the HM section apply to the SBM. Based on the example configuration shown in the case of HM, the only change relates to the interfaces where the classification and marking policies are applied. In the SBM, the service policy is applied to the egress on the manually-configured tunnels towards 6k-agg-1 and 6k-agg-2.
As an example for 6k-sb-1, the service policy would be applied to Tunnel0 and Tunnel1:
interface Tunnel0description tunnel to 6k-agg-1service-policy output IPv6-ISATAP-MARK!interface Tunnel1description tunnel to 6k-agg-2service-policy output IPv6-ISATAP-MARKInfrastructure Security Configuration
The security considerations and configurations discussed in HM apply directly to the SBM.
Conclusion
This document analyzes various architectures for providing IPv6 services in campus networks. The models discussed are certainly not the only ways to deploy IPv6 in this environment, but they provide options that can be leveraged based on environment, deployment schedule, and targeted services specifics.
Table 8 summarizes the benefits and challenges with each of the models discussed in this document.
Future Work
This document is one of several in a series focused on providing basic IPv6 implementation guidance for the enterprise customers. A similar document exists for IPv6 deployment in the branch: http://www.cisco.com/en/US/docs/solutions/Enterprise/Branch/BrchIPv6.html. Other documents will be published analyzing the deployment of IPv6 in the data center and enterprise edge.
This document is a "living document"; changes will be made to it as features mature. It is the goal, however, to fully integrate IPv6 into all enterprise architecture design guides where IPv6 will become another baseline component. This will provide one place to go to learn the latest design best practices for every area of the enterprise instead of reading about various technologies or designs in separate papers. The enterprise architecture design guides can be found at the following URL: http://www.cisco.com/go/designzone.
Additional References
Many notes and disclaimers in this document discuss the need to fully understand the technology and protocol aspects of IPv6. There are many design considerations associated with the implementation of IPv6 that include security, QoS, availability, management, IT training, and application support.
The following references are a few of the many that provide more details on IPv6, Cisco design recommendations, products and solutions, and industry activity.
•
–
–
–
–
–
–
–
–
–
–
Feedback