Let’s assume we have two switches, a multilayer distribution switch and a simple access layer switch. The switches are connected using two parellel links for redundancy.

Spanning tree will automatically put Gig0/11 on AccessSwitch in the blocking state (assuming the root bridge is above the distribution switch) because its sending port (Gig0/1) has the highest sending port number.

A quick review on STP path selection from the Spanning Tree page:

• Lowest root bridge ID – We are assuming a switch in the core claims this title
• Lowest path cost to the root – Again, the root is assumed to be above the distribution switch and that won’t influence which port is blocked here since both paths will have an identical cost
• Lowest sender bridge ID – Because both links on the access switch connect to the same switch, the sender bridge ID will be the same on both links
• Lowest sender port ID- This is how Gig0/11 goes into a blocking state – Gig0/0 is lower than Gig0/1 (again, lower sender port ID), which causes Gig0/10 to win, and transitions into forwarding

Recall that the port ID is actually made up of two parts: the port priority and the port index (or port number). Because we haven’t manually changed any port priorities yet, both distribution switch port priorities will be the default of 32 and the port index will be used as the tie breaker.

By default, all traffic for all VLANs will traverse the left path from the access switch to the distribution switch. Now let’s say we want to do some simple VLAN load balancing across the two links. Why not use both if we have the bandwidth?
 

STP Link Load Sharing

One way to accomplish this is with STP port priority. We can set one port priority value for the first half of VLANs and a different priority value for the other half.

DistSwitch(config)# interface gig 0/0
DistSwitch(config-if)# switchport mode trunk
DistSwitch(config-if)# spanning-tree vlan 1-10 port-priority 15
!
DistSwitch(config)# interface gig 0/1
DistSwitch(config-if)# switchport mode trunk
DistSwitch(config-if)# spanning-tree vlan 11-20 port-priority 15

Now VLAN 1-10 traffic will be forwarding on the left link (via gig0/10) and only use the right path as a backup. The reverse is also true. VLAN 11-20 traffic will be forwarding on the right link (via gig0/11) and only use the left path as a backup.

Both paths are forwarding in a deterministic manner and you have effectively doubled the bandwidth available between the two switches. The only major limitation of this design is that it only load balances on a per-VLAN basis. If the first half of your VLANs are passing much more traffic than the second half, the load balancing will not be equally distributed. A better approach would be to use an EtherChannel between the two switches, but it wouldn’t help demonstrate STP port priority.

I hope you found the example helpful. If you have further questions, feel free to leave a comment below.

Most of Cisco’s switches support the ability to forward frames in hardware based in layer 3 and 4 information. This dramatically improves forwarding performance between network segments and is known as mult-layer switching, or MLS.

Catalyst switches have supported different MLS types over the years, including process switching, route caching, and the most recent – CEF. You can find more details about each under the Switch Forwarding Arcetectures section on the Inter-VLAN Routing page.

Cisco refers to CEF as a topology-based solution because it uses the switch’s current routing table to prepopulate the entire known networking topology into a special table. That table, known as the FIB or Forwarding Information Base, is a mirror copy of the routing table and is contained in memory for very fast look up.

The longest match in the FIB is used for the layer 3 destination and as the routing table changes, the FIB is updated automatically.

So what’s the takeaway?

Remember that topology-based switching refers to CEF and that it uses the FIB for next-hop look ups.

If you have any questions related to CEF or inter-VLAN switching, feel free to leave a comment below.

Some benefits of converged voice, video, and data into a single network include:        

Expense reducer
If only a single cable drop is required per user, cabling and network provisioning costs go down.  PSTN costs also go down as more calls can use the existing data network and not the public phone service.

Efficiencies in bandwidth
For example, if a voice call is not in progress data can be transmitted on the same link.  That’s not the case with traditional phone lines.

Innovative features
VoIP allows new services to be added including unifying several modes of communication (ex. voicemail, email, IM).  Service providers can also sell new services and provide more flexible pricing arrangements.
  
        

AVVID    

Architecture for voice, video and integrated data, more commonly referred to by Cisco as AVVID, was an all-encompassing blueprint for converged enterprise networks pitched by Cisco.  While it was originally intended to include a very large cross-section of product families, it has been primarily focused on Cisco’s VoIP products.  For the exam you should simply be aware of the fundamental deployment concerns which AVVID addresses:          

• High availability
• QoS
• Security
• Mobility
• Scalability

VoIP Components

• IP Phones – Provides voice and applications to users
• Cisco Unified Communications Manager (UCM) – Essentially an IP PBX
• Voice Gateways – Translate between IP and PSTN
• Gatekeepers- Optional, usually in larger environments.  Performs call admission control, allocates bandwidth for calls, and resolves phone numbers to IP addresses
• Video Conferencing Units – Allow voice/video calls
• Multipoint Control Units - Allow multi-point audio and videoconferencing
• Application Servers – Provide application services like Unity Voicemail

 Note:  Voice traffic comes in two types, voice bearer and call control signaling.  The voice bearer traffic uses RTP (Real Time Protocol) over UDP, while the call control portion can use several different protocols to communicate between the phone and UCM and UCM to voice gateway.        

VoIP Network Requirements

When planning for a VoIP deployment, keep in mind the following factors:        

Features like call security, QoS, delay, etc.        

Cabling, use at least CAT-5.        

Power, either PoE from the switch, power inline module, or power brick connected to the phone itself.        

Bandwidth planning is crucial.  Commit no more than 75% capacity to allow for oversubscription and other types of traffic like video, and data.        

Network Management is important for proactively managing bandwidth and availability.        

High availability means redundant links, an auto-restart UPS, monitoring, and a response contract.        

Call Signaling

There are generally two separate traffic streams when placing a VoIP call.  The first is the call control signaling, used to setup, tear-down, maintain, and redirect calls.  Some examples of call signaling protocols include H.323, SIP, and MGCP.  Make sure you do not confuse these protocols with the voice compression protocols like G.729 and G.711.         

The second is the actual UDP voice traffic itself, which used RTP (Real-Time Transport Protocol) to encapsulate the traffic.         

Bandwidth Considerations

Each call uses somewhere around 21-106 kbs depending on the codec used, plus around 150 bps for control traffic.  Each voice packet is in the neighborhood of 60-120 bytes.        

A good formula for calculating call bandwidth is: (Packet payload + all headers) * Packets per second        

• Max one-way delay of 150 ms
• Under 1% packet loss
• Max average jitter (variable queue delays) of 30 ms
• The sum of every application’s bandwidth (including voice) should not exceed 75% of the total available bandwidth for each link.

Voice VLANs

Voice VLANs(sometimes referred to as auxiliary VLANS) are a way for Cisco switches to dynamically tag and assign voice traffic including placing it in it’s own separate VLAN/subnet.  That allows for QoS and security to be applied as well as simplified troubleshooting.  Voice VLANs are disabled by default.         

Cisco IP phones have a small internal switch that places an 802.1q tag on the voice traffic and marks the Class of Service (CoS) bits in the tag.  Data traffic (from the attached PC) is sent over the native VLAN, while all voice traffic is sent over the configured VLAN on the access port.  Cisco calls this setup a multi-VLAN access port.  This whole process of enabling voice VLANs also enables the switch to forward frames with specific 802.1P markings.  802.1P designates how QoS is applied at the MAC layer.           

Power over Ethernet

PoE Switches

Two different power standards exist for PoE, Cisco Inline PoE and IEEE 802.3af.  Both have a mechanism to sense that a powered device is connected to a port  – 802.3af relies on the devices to let the switch know how much power it needs, while Cisco’s devices can additionally use CDP to send that information.  Most phones don’t require more that 15 Watts of power, but some PoE equipment still requires more.  The new 802.3at standard will specify up to 30 Watts of power.  Some current Cisco switches can supply up to 20W.     

Switch assumes all PoE devices require 15.4 W of power until the device tells the switch otherwise.  If the switch reboots, all PoE devices will receive 15.4 Watts at the same time, which is why you should budget 15.4 W for every PoE device when doing power planning.

Note:  Non-CDP devices always get 15.4 W allocated to them.       

PoE Configuration

Cisco switches automatically detect and provide power, but if you need to disable it or re-enable it – use the following commands:   

Switch(config-if)# power inline {never | auto}

To view power information for all ports:

Switch# show power inline [interface]

Video

Video traffic, from Cisco’s perspective, falls into one of three categories:

Many to many
Examples include Telepresence, WebEx, peer-to-peer video apps
Data flows client-to-client or MCU-to-client
Bandwidth requirements for high-def video can be up to 12 Mbs per location (with compression)

Many to few
Examples include IP surveillance cameras.
Typically require up to 4 Mbs of bandwidth

Few to Many
Example is Internet streaming from a single source
Quality not as critical
Traffic flows storage to client or server  to client

Quality of Service is a very important part of operating a VoIP platform on a campus network.  The ability to prioritize different traffic on the same link makes voice over IP a reality on a shared Ethernet fabric.  There are three main drivers for applying QoS: jitter, packet loss, and delay.     

QoS Strategies

Implimented on inbound interfaces:

Classification
Distinguishes one type of traffic from another by ACLs, ingress interfaces, and NBAR.  After it is classified, other QoS functions can be applied.     

Marking
(layer 2)  Within a frame, placing an 802.1p CoS value within the 802.1Q trunk tag.
(layer 3)  IP Precedence or Differentiated Services Code Point (DSCP) values in a packet’s IP header.     

Policing
Decides whether a specific type of traffic is within predefined bandwidth levels.  If not it is usually dropped (CAR and class-based routing are examples).      

Implemented on outbound interfaces:

Traffic Shaping
Defines an artificial maximum throughput for the interface, providing a steady stream that is throttled while congestion occurs by buffering traffic.     

Queuing
After traffic has been classified and marked, it can be placed into one of many queues to be sent at different rates and order.  Examples include First In First Out (FIFO), priority queuing, weighted fair queuing, and custom queuing.  Note:  the default queue method is FIFO.     

Dropping
By default, interface queues accept all traffic until they are full and drop everything after that.  Prioritized dropping can be configured to drop low-priority, re-transmittable packets first (ex. Weighted Random Early Detection [WRED]).     
 

DSCP

Differentiated services provides a mechanism to change levels of service based on the value of specific bits in the IP header or the 802.1Q tag.  Each hop along the way must be configured to treat the marked traffic the way you want, also known as per-hop behavior (PHB).

As mentioned, there are two ways to mark the DSCP values depending on what layer you are marking it at.  The first method (layer 2) uses the three 802.1p bits within the 802.1Q tag to set the CoS value.  Voice is commonly set to 5 and video 4.

For layer 3, the 8 bit ToS field within the IP header is used.  There are again two options here.  IP Precedence can be set using the top 3 bits or DSCP can be set using the top 6 bits.  The bottom 2 bits are used for congestion notification.  When setting DSCP values, 0 is the default, indicating best-effort delivery.

The six bit DSCP code consists of two parts, the first 3 bits define the DiffServ Assured Forwarding (AF) class and the next two bits define the drop probability.  The sixth bit is unused.

Note:  Voice bearer traffic uses an Expedited Forwarding value of DSCP 46 to give it high priority.
 

Trust Boundaries

The place where decisions about priority marking on incoming frames/packets is done is called the trust boundary.  When IP traffic comes into an interface and is already marked, the switch has the following options:

• Trust the DSCP value
• Trust the IP Precedence value
• Trust the CoS value in the frame
• Classify the traffic based on an IP ACL or MAC ACL

Cisco recommends marking the traffic as close to the source as possible.  IP phones can mark their own traffic and other clients can be marked at the access switch.  If that is not an option mark at the distribution layer, but never at the core.  Marking slows traffic down, so it has no place being in the core.  All devices within the network path should be configured to trust the marking and provide service based on that.     

Configuring QoS for VoIP

Before rolling out VoIP in your environment, think through the following planning steps:

1. PoE
Ensure there is enough power for all the phones and has a UPS backup

2. Voice VLAN
Think through the number of VLANs/subnets required, add DHCP scoped for the phones, add voice networks to routing protocols

3. QoS
Decide on which marking and queues you plan on using.  Cisco recommends implementing AutoQoS and then tuning as needed.

4. Fast Convergence
Tune routing and HSRP/VRRP/GLBP timers

5. Test Plan
Test the implementation before rolling it out to real users.  Some things to look for include making sure the phone and PC have the correct IP addresses, the phone registers itself, and calls can be made. 

Auto QoS

Auto QoS, when enabled, configures the switch interfaces using common best-practices including:  
 
•  Auto discovery and classification of network applications
•  Creates QoS policies for those apps
•  Configures the switch to support IP phones
•  Sets up SNMP traps for network reporting
•  Provides a consistent QoS configuration across the environment

Note:  Auto QoS uses CDP to function properly with an IP phone, so make sure it is not disabled if you plan on implementing Cisco’s Auto QoS.  

Configuring Auto QoS

Configures the interface to trust CoS on incoming traffic:

Switch(config-if)# auto qos voip trust

Configures the interface to trust CoS only if Cisco phone is connected (requires CDP):

Switch(config-if)# auto qos voip cisco-phone

Displays the Auto QoS configuration:

Switch# show auto qos

Manual QoS Configuration

Associates a voice VLAN with a switch port:

Switch(config-if)# switchport voice vlan vlan-ID

Trust markings on traffic entering an interface.  Effectively moves the trust boundary to the attached device (often an IP phone or server):

Switch(config-if)# mls qos trust {dscp | cos}

Trust markings only if a Cisco phone is connected:

Switch(config-if)# mls qos trust device cisco-phone

Instructs the IP phone to set/overwrite CoS values for data coming from a PC attached to the phone.  The phone would then be the new trust boundary because it is now doing the marking on the data traffic.  Also important to note that the CoS value assigned at the end of the statement is a number between 0 and 7..  7 being the highest priority and 0 being the default value:

Switch(config-if)# switchport priority extend cos cos-value

Instructs the phone to trust the priority of the data coming from the attached PC:

Switch(config-if)# switchport priority extend trust

Verify interface parameters:

Switch# show interfaces interface-id switchport

Verify QoS parameters on an interface:

Switch# show mls qos interface interface-id

Final VoIP QoS Considerations

•  If a voice VLAN is configured, untagged traffic is a sent according to the default CoS priority of the port
•  CDP is required to allow for voice VLANs
•  Portfast must be enabled on a switch interface configured as a voice VLAN
•  Several mechanisms can be used in combination to improve VoIP quality including queuing, classification and marking close to the source, and congestion prevention protocols like WRED

QoS for Video

Video traffic can change dramatically depending on what kind of compression is used and how static the picture is.  Video that is constantly changing will use much more bandwidth and be more bursty than more still-image video.  Voice traffic is much more steady in comparison.

Video should be placed in it’s own queue, especially if the organization is doing interactive video.  Consider creating separate queues for interactive and streaming video if the business uses it.  Less than 200 ms of latency is considered acceptable by most standards. 

I’ve wanted to start a blog for a long time on the site as a way to interact with those of you preparing for your certifications in a more direct fashion. I want to use this to do a few things including:

• Walk through some of the more difficult topics and explain them in depth
• Use more visuals to lay out topologies
• Answer to your exam questions (as long as we don’t violate any NDAs in the process)

Here’s where you come in…

I want to know what parts are most difficult for you to understand or those that you feel most underprepared for. If you have specific questions, I’d be happy to answer those as well.

So shoot me an email with your ideas or leave a comment below. I can’t wait to get started.

Aaron

The routing table pairs network prefixes with the router’s preferred next hop address or interface.  Packets are routed based on the output of the routing table by first matching the longest prefix and then using other IGP-specific metrics.  The show ip route command displays the contents of the routing table.

After the router has determined what the next-hop address is, the router then needs to translate that into a layer 2 MAC address.  The ARP table is exactly what this is for.  The show ip arp command will display the current ARP pairings.

Lastly, CEF is used in layer 3 switches to optimize routing and layer 2 headers.  To view the CEF entries, use the show ip cef command.

Troubleshooting Any Routing Protocol

Regardless of what routing protocols are in use, there are some common troubleshooting steps that can be applied.  First, try to ping the destination to determine reachability.  Next, look at the routing table to make sure a route to the destination exists.  Finally, run a traceroute from the source towards the destination to see where the last reachable hop is.

For further digging, the show ip protocols command gives some very helpful information on the current routing protocols in use (like timers, AS numbers, etc.).

Routing Protocol Troubleshooting Methodology

There are three key questions that can be extremely helpful when troubleshooting a routing issue – regardless if you are running EIGRP, OSPF, or BGP.

1. Is the route being advertised properly?

2. Is the route being received?

3. Is there a more desirable route being used (longer prefix or lower administrative distance)?

Now let’s dissect each of these for the major routing protocols one at a time.
 

EIGRP

First, verify connectivity to the remote networks using pings and by taking a look at the local routing table.

As a reminder, EIGRP stores its information in three different tables: the EIGRP interface table, neighbor table, and topology table.

EIGRP Interface Table
The EIGRP interface table displays interfaces participating in the local EIGRP processes.  Use the show ip eigrp interface command to display its contents.

EIGRP Neighbor Table
The EIGRP neighbor table contains a list of discovered EIGRP neighbors.  Use the show ip eigrp neighbors command to display its contents.

EIGRP Topology Table
The topology table contains a complete list of EIGRP-learned routes. Use the show ip eigrp topology command to display its contents.

Is the EIGRP route being advertised properly?

Remember those three troubleshooting questions listed above?  Let’s start with the first one – is the route being advertised properly?

The first step is to identify the router that is connected to the destination subnet as it should be advertising the route out.  There are two simple ways to check if that router is advertising the routes properly.

First, do a show run | section eigrp.  This will display the running EIGRP configuration, including what networks are being advertised with the network statements.

Another option is to do a show ip protocol.  The nice thing about this command is that it displays the EIGRP network statements.  Remember, EIGRP only advertises subnets of interfaces that match an EIGRP network statement.

Is the EIGRP route being received?

Routers must be EIGRP neighbors for the routing information to be shared.  To check this, issue a show ip eigrp neighbors on the two routers exchanging hellos.  You should see the neighbor listed on each device.

You can also perform a debug ip eigrp packets to make sure hellos are being sent out from each router.

If all of that looks good, look at the EIGRP running configuration and make sure the AS numbers match, the timers are close, and that any authentication configurations are the same.

Next, issue a show ip eigrp interface to make sure the interfaces you expect are participating in the EIGRP process.  Lastly, route maps or distribution lists could be blocking routing traffic.  Do a show ip protocols to display any distribute lists.

Is there a more desirable route being used?

It’s possible that EIGRP knows about the route, but it is not being used in the routing table.  If a more desirable path is known, that will be used instead.   Compare the EIGRP topology table to the local routing table.

OSPF

These steps for troubleshooting OSPF are very similar to EIGRP.  First, verify that there is a problem using pings and by taking a look at the routing table.

OSPF stores its information in three different tables: the OSPF interface table, neighbor table, and link-state database.

OSPF Interface TableThe OSPF interface table displays interfaces participating in the local OSPF processes.  Use the show ip ospf interface command to display its contents.

OSPF Neighbor TableThe neighbor table contains a list of discovered OSPF neighbors.  Use the show ip ospf neighbors command to display its contents.

OSPF Link State Database
The link state database contains the received LSAs. Use the show ip ospf database command to display its contents.

Is the OSPF route being advertised properly?

The first step is to identify the router that is connected to the destination subnet as it should be advertising the route out.  There are two simple ways to check if that router is advertising the routes properly. 

First, do a show run | section ospf.  This will display the running OSPF configuration, including what networks are being advertised with the network statements.  Another option is to do a show ip protocol. 

Remember, OSPF only advertises subnets of interfaces that match an OSPF network statement.

Is the OSPF route being received?

Routers must be OSPF neighbors for the routing information to be shared.  To check this, issue a show ip ospf neighbors on the two routers.  You should see the neighbor listed on each device.

You can also perform a debug ip ospf adj to show any issues that would prevent the routers from forming an adjacency.

OSPF is more particular about matching protocol variables than EIGRP.  OSPF requires that all of the following parameters match between devices:

• Bidirectional communication
• AS number
• Timers
• Common area type
• Common subnet prefix
• Authentication

The OSPF protocol values can be seen using the show ip ospf interfaces command.

Lastly, route maps or distribution lists could be blocking routing traffic.  Do a show ip protocols to display any distribute lists.

Is there a more desirable route being used?

It’s possible that OSPF knows about the route, but it is not being used in the routing table.  If a more desirable path is known, that will be used instead.   Compare the OSPF topology table to the local routing table.  Take the time to check each hop along the expected  path and look at the routing tables on each router.

BGP

BGP stores its information in two tables: the BGP neighbor table and the BGP table.

BGP Neighbor Table
The neighbor table contains a list of known BGP neighbors.  Use the show ip bgp neighbors command to display its contents.

BGP Table
This table contains all the received BGP prefixes as well as their associated attributes lists.  Perhaps most importantly, it also shows the BGP best path to each destination. Use the show ip bgp command to display its contents.

Are the BGP routers neighbors?

BGP neighbors must be administratively assigned on each router running BGP.  If the routers are not neighbors, BGP routing and network information will not be passed between them.  Start by doing a show ip bgp neighbors.  If the expected BGP peers do not show up in the output, make sure they have L3 connectivity using a simple ping test.  If you need to investigate further, a debug ip bgp updates should show the BGP hellos and advertisements.

Remember that BGP requires bidirectional communication as well as matching AS numbers and authentication.  The show run or show ip bgp command will display that information.

Also, consider that route maps or distribution lists could be blocking routing traffic.  Do a show ip protocols to display any distribute lists.

Is the BGP route being advertised?

As with the other routing protocols, make sure that the router connected to the destination subnet is advertising the route out.  There are two simple ways to check if that router is advertising the routes properly.

Perform a show run | section bgp to look at the neighbor statements.  You should also keep in mind that BGP will only advertise routes when (1) they are defined using neighbor statements and (2) the router knows about the route from another source.

Route Redistribution

Route redistribution can be a tricky situation to troubleshoot, but understanding the following concepts should be helpful.

1. Redistributed routes require an existing entry in the routing table.  If the redistributing router does not have a routing table entry for the route being redistributed, it will not work.  Seems simple, but it should checked right away.

2. Routing loops are a common problem with multi-router routing redistribution.  Use a single router to perform the redistribution if possible.

3. Understand that redistributed routes lose their native metric information.  When redistributing into EIGRP, a default metric MUST be set or no route will be imported.  When redistributing into OSPF, all routes will be imported as classful unless the subnets keyword is appended to the end of the redistribution statement.

Poor Switch Performance

Most performance issues on switches are related to one of three errors:

1. Cabling and port problems (layer 1)
2. Duplex mismatches between switch ports and an attached device
3. TCAM issues.

Physical layer Troubleshooting Commands

show interface

show interface counters

show interface counters errors

Look for the following errors:

FCS-Err
Usually a cabling issue.

Xmit-Err
The transmission buffers are full.  This is sometimes seen when switching from a fast link to a slower one.

Undersize, Giants
The transmitting NIC may have problems.

Single-Col, Multi-Col, Late-Col, Excess-Col
All of these are collision types, which can point to a duplex mismatch.  Cisco recommends setting all interfaces, switch and server, to auto.
 

Spanning Tree

Spanning Tree Protocol is a loop prevention mechanism to allow redundant Ethernet network connections.  Here is an important summary of how each switch determines Spanning Tree port roles:

1. Each switch periodically transmits BPDUs that include its bridge ID, current root bridge, and cost to that root bridge.  Additionally, each switch starts assuming it is the root bridge.

2. If a switch receives a BPDU from another switch with a different root, it does a comparison.  If the BPDU has a lower advertised root, the switch changes its root to match and recalculates the cost to the new root.  The port that received the BPDU is now the root port – all others become designated ports.

3. If a switch receives two BPDUs with the same root, it then compares costs and uses the port with the lowest cost.  The port with the higher cost is blocked – also called a non-designated port.

To quickly review STP costs, below is a list of link costs based on interface speed.

After the whole process, there will be only one root bridge – with each non-root switch having only one root port.

To see the status of spanning tree, do a show spanning-tree vlan vlan-id.

To view sent/received BPDU information for a switch, do a show spanning-tree interface interface detail.

Broadcast Storms

Broadcasts storms can occur due to Spanning Tree misconfigurations and/or rogue switches being added which closes a loop.  Regardless, a broadcast storm will be obvious when the switch slows way down, becoming unresponsive, and all the links light up solid green.

The CLI may be very slow to respond if you still have remote access to it, so often times to fastest way to fix the problem is to physically begin pulling redundant links.
 

Troubleshooting EtherChannels

EtherChannel issues usually fall into one of three categories:

1. Every port participating in an EtherChannel must have identical speed, duplex, access or trunk settings.  If an EtherChannel isn’t forming, check each port configuration.

2. Both sides of the EtherChannel must be configured as a bundle directly or be using a link aggregation protocol (LACP or PAgP).  If one side is configured as an EtherChannel and the other side is not, look for error-disabled EtherChannel ports on the EtherChannel-enabled switch.

3. If traffic is only flowing over a single link in a bundle, it is likely that the hash algorithm should be adjusted to use different seed values.  Also note that link bundles should be used in even numbered pairs like 2, 4, 8, etc.
 

VLANs

When troubleshooting issues that you suspect are related to VLAN logic, you should first make sure you have tested for physical layer issues like bad cabling, a power failure, or bad switch ports.  Also, check that you are not dealing with an issue with the switch itself – things like software bugs, loops, or ARP problems.

VLAN issues usually come in the form of misconfigured VLANs, improper VTP mode, trunk issues, or native VLAN mismatches. 

Switch Tables

It is important that you understand what show commands display information on what switch tables.  These will come in handy when you are isolating a switching issue.

MAC Address Table (MAC-to-port mapping)

show mac-address

VLAN Assignments (VLAN-to-port mapping)

show vlan

Trunk Assignments

show interface switchport

show interface switchport trunk

show etherchannel 

Troubleshooting Inter-VLAN Routing

Routing between VLANs can be done on either a router, or a layer 3 switch – but the data plane is different depending on the platform you are using.

Either way, show ip cef displays the CEF forwarding table and show adjacency will show you the layer 2 headers used in forwarding.

Keep in mind that routers always use layer 3 information to pass traffic between ports.  Switches can either use MAC address forwarding (for layer 2 forwarding), SVIs for inter-VLAN routing, or layer 3 routed ports.  The last category, routed ports do not run layer 2 protocols like Spanning Tree – very important.

Last thing to remember – SVIs will only go into down state when all interfaces within that particular VLAN are down.

HSRP, VRRP, & GLBP

First hop redundancy protocols allow a layer 2 segment to have two gateway routers for redundancy, while still only showing a single gateway IP and MAC address.

The three FHRPs Cisco supports are HSRP, VRRP, and GLBP.

HSRP is one of the original FHRPs that was developed by Cisco and is proprietary.  One router is active and another is a backup (using HSRP keepalives to maintain connectivity).  HSRP is extremely popular and you should make sure to understand how it works for the TSHOOT exam.  Check out the High-Availability page to learn more.

VRRP is another gateway redundancy protocol that is an open standard and very similar to HSRP.

GLBP is Cisco proprietary; its primary advantage is its ability to automatically load balance between gateway routers.

HSRP

HSRP is the primary FHRP covered on the TSHOOT exam, so let’s go through the basics one more time.

HSRP is configured using the standby command under interface configuration mode.  Routers in the same HSRP group share a common MAC and virtual IP address.  The standby configuration statements define the HSRP group as well as the virtual IP in use.

Each HSRP-enabled router has a default HSRP priority of 100 (remember, highest wins).  If another router joins the group with a higher priority it will still not become the active router unless the preempt command is applied.

An example HSRP configuration could look something like:

Router(config)# interface gig1/1
Router(config-if)# ip address 192.168.1.2
Router(config-if)# standby 4 ip 192.168.1.1
Router(config-if)# standby 4 priority 200
Router(config-if)# standby 4 preempt

To show the current HSRP status, issue either show standby or show standby brief depending on the level of detail you require.

There are a number of methods to tackle the same problem. To be honest, Cisco doesn’t promote a specific approach for the CCNP TSHOOT exam. The important part is that you are consistent and your troubleshooting methodology follows a structured approach.
 

Structured Troubleshooting

What Cisco calls structured troubleshooting simply means you use a system to solve a problem by collecting information about the problem, forming a hypothesis, and then test it. The structured approach also is helpful when the hypothesis you create fails. It may rule out many more scenarios and likely leads to the next hypothesis to test. The recovery time for a structured troubleshooting approach is usually much less than randomly changing configurations or settings in a hurry to try and get things working.
There are several common structured troubleshooting approaches, with these being the most common:

Bottom-Up

Start with the OSI physical layer and work your way up.

Top-Down

Start with the OSI application layer and work your way down.

Follow-the-Path

Consider the path a packet would take from source to destination, checking each node/device/configuration along the way.

Spot-the-Difference

This is where configurations are compared between what is currently running and what the expected configurations should be.

Move-the-Problem

Move a device to see if the problem moves with it.
 

Use the Scientific Method

The first step whenever you encounter a technical problem is to define the problem.  This will involve collecting input from those experiencing the issue directly – things like “the Internet is down…” or “my email is slow…” or “I can’t get to my Facebook account when I should be processing TPS reports”…  You get the idea.  Keep in mind that you will need to understand that they are explaining the symptoms – it’s your job to determine the problem behind the symptoms.

After you have identifies the problem, it’s time to trim it down.  What’s the scope?  How many users are affected?  What changed?  When did it happen?  Is it a constant problem or intermittent?

Now this is where your tool bag of structured troubleshooting methodologies should come out.  Try one that you think best matches your hypothesis of the root issue and work your way through it.  Did your test work?  If not, continue through the layers, the path, or whatever approach you are using.

When you find a test that is successful and determine that it in fact is the root cause, make sure to communicate the problem and recovery to all stakeholders and update any necessary documentation.  These are small, simple tasks – but they are rarely done consistently.

If a configuration change was the culprit, think about your current change control policy and ask if it needs to be updated.

Good troubleshooting reduces the time an outage lasts, good maintenance minimizes outages themselves.

Maintenance Methodologies

Several well known maintenance models have been defined by a number of organizations.  Many organizations use parts of several instead of adopting one method completely, but it is important as a network engineer to understand what models exist and how they translate into improving your organization.  A documented maintenance strategy is worth its weight in gold.
 

IT Infrastructure Library (ITIL)

ITIL focuses on creating a technology service framework within an organization and aligning it closely with the organization’s requirements and processes.  Note that ITIL is a large and comprehensive approach that was developed specifically for IT professionals.
 

FCAPS

FCAPS is an IT maintenance model created by ISO that categorizes network management into five parts.  FCAPS is an acronym using the first letters of the five categories it includes.

Fault management

■ Preventive maintenance
■ Minimizing network downtime

Configuration management

■ Both hardware and software installation and configuration
■ Change control
■ Inventory management

Accounting management

■ Capacity planning
■ Cost efficiency

Performance management

■ Maximize performance on existing network investments

Security management

■ Confidentiality, integrity, availability (CIA)
■ Authentication, authorization, accounting (AAA)
■ Encryption
■ Intrusion detection/prevention
 

Cisco Lifecycle Services

Cisco has come up with their own maintenance model, sometimes also referred to as PPDIOO, or Prepare, Plan, Design, Implement, Operate, and Optimize.  This model is specifically focused on deploying and operating Cisco’s product families.
 

Telecommunications Management Network (TMN)

TMN was developed by ITU-T and is a tailored version of FCAPS specific to the telecommunications industry.

Once the model has been selected, its parts should inform an IT organization’s processes and standard procedures.  After all, a model is meaningless unless it affects how a business operates.

After the maintenance model components have defined an organizational processes (ex. automated config backups, manual security audits, etc.), tools should be selected to carry out those processes.  FTP could be used for configuration backups for example.
 

Network Maintenance Core Tasks

Whatever model an IT organization chooses, there a some functions that should be included every time.  These include:

■ Managing adds, moves, and changes
■ Installing and configuring new network devices
■ Replacing failed hardware
■ Software backup
■ Configuration backup
■ Troubleshooting failure scenarios
■ Software upgrades
■ Network performance monitoring
■ Capacity planning
■ Creating/updating network documentation
 

Documentation

Up-to-date, clear, and complete infrastructure documentation is crucial to reduce recovery times and maintain a robust networked environment.  Different levels of detail are appropriate for different audiences, but some common details that should be documented include:

■ Production configurations
■ Inventory (including serial numbers, support info, etc.)
■ Circuit information
■ Network drawings
■ IP address assignments

Another important component to network documentation is a performance baseline, or snapshot.  It captures the expected performance of your network systems like link bandwidth, WAN jitter and delay, and port status.  This is a tremendous help during troubleshooting efforts because without knowing what normal levels are, detecting abnormal traffic behavior becomes very subjective.
 

IOS Tools

Configuration

Configurations should be backed up periodically or after changes are made.  One of the simplest methods is to save the configuration as a text file on a remote TFTP or FTP server.  TFTP and FTP servers are available on all modern operating systems and free, open source offerings are widely available.

Adding the date to the saved configuration can make rolling back changes easier in the future.  Here’s an example of a router saving it’s configuration to a local TFTP server:

RouterA# copy run tftp
Address of name of remote host []? 10.10.1.35
Destination filename [routera-config]?routera

Syslog

Syslog is a tool that collects alerts from network devices and stores them on a common log.  Obviously, this can be very handy when you need to troubleshoot an issue across many devices.

Know that every syslog message contains two parts, a severity level and a facility.  The severity level goes from 0 to 7 with 0 being the most severe to 7 being simply informational.
Syslog Priority (highest to lowest):

0.  Emergency (highest)
1.  Alert
2.  Critical
3.  Error
4.  Warning
5.  Notice
6.  Informational
7.  Debug (lowest)
 

NTP

Alerting is important, but if the timestamps that are included are not correct, then the alerts are unreliable (and next to useless).  NTP stands for Network Time Protocol and is used to keep accurate and consistent time on all network devices.  NTP works by using pulling the current time from a time server, each of which are assigned by stratum.  Stratum 1 clocks are synchronized directly with an atomic clock, stratum 2 clocks get their time from stratum 1 clocks, etc.

Configuring NTP is easy – just point the device to the proper time server:

Switch(config)# ntp server ip_address_of_ntp_server

To verify:

Switch# show ntp status

One last note for NTP, it is important to consider the time zone that each device is set to.  Make sure you have it consistent (ex. local time zones, GMT, HQ time zones, etc)
 

Archive

Cisco has developed a built-in configuration backup and restore feature, called archive.  The archive function maintains a copy of the current configuration as well as a set of past configurations.  If a configuration change is made with unpleasant results, the switch or router can roll back to a previous configuration relatively easily.

There are several keywords available inside archive configuration mode.  Here is a list of some of the most common:

path
Specifies where you want the backup configuration stored (ex. flash, tftp server, etc.)

Example:

archive
path flash://routerc

OR

archive
path tftp://192.168.1.22/routerc.txt

write-memory
When the write-memory keyword is configured, a backup of the configuration will be automatically saved every time the configuration is manually saved.

time-period
Sets the maximum time allowed before another backup is automatically saved

When the archive function backs up a configuration, it appends a -1, -2, -3, etc. to the end of the file name depending on how many have already been saved.  It will count up to 14 (represented as filename-14) and then cycle back to 1.  If your time-period is set too frequently, then you’re backups may be written over too often.

VPN tunnels and IPSec are two topics covered on the exam, but not in great detail.  You’ll need to know enough to verify a sample configuration and answer straightforward questions on both technologies.  Let’s start with IPSec.

IPSec Basics

IPSec allows the establishment of a secure connection between two hosts.  The IPSec protocol sets up a unidirectional SA (security association between the two endpoints).  Because the association is unidirectional, an SA is created on both ends, resulting in two SAs per IPSec tunnel.

IPSec tunnels are often used as a backup to a WAN link failure.  If a point-to-point WAN circuit drops, an IPSec tunnel can be configured to automatically be established over the internet to the remote site.  When the primary WAN circuit comes back up, the IPSec tunnel is disconnected.

Floating Static Routes

Configuring an IPSec tunnel to activate when a primary link drops is commonly inplemented as a floating static route.  The idea is to configure the IPSec VPN as a static route, but with an administrative distance higher than that of the WAN routing protocol’s.

If the primary route is active, the backup link is not placed into the routing table because it has a higher administrative distance.  If the primary route goes down, the static route becomes active.

To configure a floating static route, make sure you define a higher administrative distance value at the end of the statement:

R1(conf)# ip route prefix mask address|interface distance_value

VPN Tunnels

One major problem with standard IPSec sessions is that they do not support broadcast or multicast traffic.  If you want to use an IPSec VPN in an “always on” fashion, then the tunnel needs to allow routing information to pass through.  Of course dynamic routing protocols use broadcast or multicast to send hellos and updates, which creates a problem.

To get around this issue, a “tunnel within a tunnel” approach can be used.  A generic tunnel can be configured within the IPSec tunnel to allow routing protocol information (along with all the other traffic). There are generally four ways to do this paired with IPSec:

DMVPN and GET VPN
Both allow the creation of secure, “on-demand”, multipoint tunnels.

Virtual Tunnel Interface (VTI)
A secure, “always-on” tunnel that supports multicast traffic.  This allows routing protocols to operate within it.

Generic Routing Encapsulation (GRE)
GRE tunnels may be the most common of the bunch – they are also the default tunnel mode on Cisco routers.  GRE tunnels support many layer 3 protocols but perhaps most importantly allow multicast traffic accross the tunnel – permitting dynamic routing protocol traffic. Be aware that GRE tunnels add an additional 20 byte IP header as well as a 4 byte GRE tunnel header.

Branch Office Connectivity

The CCNP ROUTE exam covers several unusual topics related to managing and configuring the connectivity between an HQ site and a branch office.  You need to be familiar with some of the underlying technologies used. Cisco ISR routers are often a good choice for branch sites as they support a wide variety of incoming services.  In smaller offices, a single ISR may be used for a both remote connectivity and inter-VLAN routing.  In that case, know that an Ethernet Switch Module would be required for the ISR router.

DSL

DSL, or Digital Subscriber Line, can be used as a backup WAN connection to a branch office. DSL uses frequencies not used by TDM phone systems on a phone line – allowing the extra bandwidth to be used for data connectivity. Asymetrical DSL has higher downstream bandwidth than upstream, while with symetric DSL they are both the same rate.

There are two primary methods for pushing L2 data across a DSL line:

PPPoE
Point-to-Point Protocol over Ethernet is the most common method and encapsulates PPP traffic into Ethernet frames.

PPoA
Point-to-Point Protocol over ATM is less common and routes PPP traffic over an ATM network between the customer and the DSL service provider. Both options can be configured on a Cisco router to terminate the DSL connectivity. PPPoE is especially helpful because it frees the local office’s computers from running PPPoE

Cable

Broadband cable providers also provide internet connectivity which can be used for WAN backup or provide internet connectivity for telecommuters.  The internet signal is carried on the same line that the television is carried, but a cable modem allows the data traffic to be separated.

The international standard for sending data over a cable system is Data Over Cable Service Interface Specification (or DOCSIS).  Many different versions of the standard are used throughout the world.  Cable system connections are typically not terminated directly into a Cisco router.  Instead, a cable modem demodulates the incoming signal and converts the traffic to Ethernet frames, which a router can process.

IPv6 is an important topic – and not just for the exam.  The growth of web-based services and diminishing IPv4 addressing will continue to push organizations towards IPv6, especially on web-facing networks.

Basics

IPv4 addresses are 32 bits long and are represented in dotted-decimal format.  IPv6 addresses are 128 bits and are in hexadecimal format.

The first 64 bits of an IPv6 address are reserved for the network portion and the last 64 bits are used for the host portion.

IPv6 Shorthand

The ability to shorten IPv6 addresses is very important to understand because it makes reading and writing them much easier.

There are two ways to condense an IPv6 address:

1.  Leading zeros can be removed in any section.

For example,  0021:0001:0000:030A:0000:0000:0000:0987E can be abbreviated as: 21:1:0:30A:0:0:0:987E

2.  Sequential sections of all zeros can be shortened to a single double colon.

This can only be used once per address.  Using the same example address above, it can be further shortened to:

21:1:0:30A::987E

Unicast, Multicast, & Anycast

Unicast
Unicast is for sending traffic to a single interface.  In IPv6 there are actually two different unicast types, global unicast and link-local unicast.

Multicast
Unlike IPv4, IPv6 addressing does not support broadcasts.  Instead, it has replaced it with multicast (which is a more efficient variation).  This is used for sending traffic to a group of devices.

Anycast
IPv6 supports another new packet type – anycast.  Anycast allows the same address to be used on multiple devices for load balancing and redundancy.  Technically, it is used for sending traffic to the nearest interface in a group.  While multiple devices may be running the same anycast address, only one will be used per packet sent.

Be aware that with IPv6, an interface can be assigned multiple addresses.  Here is the list:

- Unicast address

- Link-local address

- loopback (::1/128)

- All nodes multicast (FF00::1)

- Site-local multicast (FF02::2)

- Solicited-nodes multicast

- Default Route (::/0)

Address Assignment

There are three different ways devices are assigned an IPv6 address: manual configuration, stateless autoconfiguration, or DHCPv6.

Manual Address Configuration

The first thing to know about manual IPv6 address configuration is that addresses assigned to a router interface use the address/prefix-length notation instead of the address mask notation.  This is so much easier than typing 255.255… after every IP address!

Also, make sure you first enable IPv6 routing with the ipv6 unicast-routing global configuration command.  Use the ipv6 address ipv6-address/prefix-length command to assign an address.

An example of an interface configured with an IPv6 address:

R1# conf t
R1(config)# ipv6 unicast-routing
R1(config)# int gig 1/1
R1(config-if)# ipv6 address 21:1:0:30A::987E/64

Manual Network Assignment

Another way to manually configure an IPv6 address is to configure the network and allow the host portion to be autopopulated based on the device’s MAC address.  This can work well because MAC addresses are 64 bits long – the exact same length as the host portion of an IPv6 address!

An example configuration with the network portion defined:

R1(config)# int gig 1/1
R1(config-if)# ipv6 address 21:1:0:30A::/64

Note: Some systems have a 48 bit MAC address.  In this case, it flips the 7th bit and inserts 0xFFEE into the middle of the MAC address.  This modified version is called an EUI-64 address.  To do this, add the keyword eui-64 to the end of the ipv6 address statement.

Stateless Autoconfiguration

Stateless autoconfiguration allows a device to self-assign an IP address for use locally without any outside information.  Remember that interfaces using IPv6 will often have more than one IPv6 address assigned, and in this case stateless autoconfiguraiton will generate a link-local address in addition to any other manually assigned addresses.  Link-local addresses are created using the prefix FE80:: and appending the device’s MAC address. Since every MAC address should be unique, it works well for auto-generated local IP addresses.

Link-local addresses are not routable within packets and are used for administrative purposes within the local segment.  For example, most IGPs use link-local addresses for neighbor relationships and the link-local address is listed as the next-hop address in the routing table.

Once a router has created an IPv6 link-local address using stateless autoconfiguration, it uses NDP to make sure it is actually unique within the local network.  NDP stands for Neighbor Discovery Protocol and uses ICMP packets as part of the neighbor discovery process.

To configure stateless autoconfiguration, use the ipv6 address autoconfig command.

Example:

R1(config)# int gig 1/1
R1(config-if)# ipv6 address autoconfig

IPv6 Routing

Static Routes

The configuration for IPv6 static routes is identical to IPv4, except for the ipv6 route keywords instead of ip route.  Other than that, it is exactly the same.

An example of a static IPv6 default route:

R1(config)# ipv6 route ::/0 serial1/1

An example of an IPv6 static route with a next-hop address:

R1(config)# ipv6 route 2003:2:1:A::/64 2003:2:1:F::1

To view the IPv6 routes in the routing table, use the command show ipv6 route.

IPv6 EIGRP

There are many differences in the way EIGRP is configured for IPv6.

• It still sends hellos out every 5 seconds to its neighbors, but when running EIGRP with IPv6 addresses it uses the multicast address FF02::A.
• EIGRP messages are exchanged using the link-local address as the source address.  Perhaps the biggest difference is that there is no network command.  Instead, EIGRP routing is enabled on each participating interface.
• Also, EIGRP running IPv6 requires a router ID be configured.  The format is that of an IPv4 address - 32 digits and it can be a private address (non-routable) with no issues.
• The last major change is that the EIGRP process starts in the shutdown state.  You have to issue a no shut to bring it up on the router.

To configure IPv6 EIGRP:

R1(config)# ipv6 unicast-routing
!
R1(config)# ipv6 router eigrp AS
R1(config-rtr)# router-id ipv4-address
R1(config-rtr)# no shut
R1(config-rtr)# exit
!
R1(config)# interface type number
R1(config-if)# ipv6 eigrp AS

OSPFv3

OSPFv3 is an updated version of OSPF designed to accommodate IPv6 natively.  Most of the configuration and function is identical to its predecessor, but a few changes were made starting with messaging.

• OSPFv3 uses the multicast address FF02::5 and FF02::6, but like EIGRP it now uses its link-local address as the source address in advertisements.
• It is possible to run multiple instances of OSPFv3 on each link.
• Like the IPv6 implementation of EIGRP, a 32 bit router ID must be manually created.  It will not automatically create one based on highest loopback or interface address.  The RID that is assigned will then be used to determine the DR and BDR on a segment (highest wins).
• OSPFv3 has dropped it’s native authentication options.  Instead, it relies on the underlying authentications built into IPv6, like IPSec.

Configuration

The configuration is now done on each individual interface.  The following is an example configuration:

R2(config)# ipv6 unicast-routing
!
R2(config)# ipv6 router ospf 100
R2(config-rtr)# router-id 10.10.10.1
R2(config-rtr)# area 1 stub no-summary
R2(config-rtr)# exit
!
R2(config)# interface gig1/1
R2(config-if)# ipv6 address 2003:2:1:2::1/64
R2(config-if)# ipv6 ospf 100 area 0
!
R2(config)# interface gig1/2
R2(config-if)# ipv6 address 2003:2:1:A::1/64
R2(config-if)# ipv6 ospf 100 area 1
R2(config-if)# ipv6 ospf priority 30

MP-BGP

MP-BGP, or multiple protocol BGP, was outlined in RFC 2858 and includes extensions to the original BGP standard that allows support for other protocols – one of which is IPv6!  The command address-family was added to specify which new protocol functionality is being configured and is used when applying IPv6 addressing.

Like EIGRP and OSPFv3, an IPv4 address must be configured as a router ID.  The BGP configuration is not done at the interface level, it still is done in router configuration mode.  The major difference is that neighbors must be first defined under router BGP configuration mode and then “activated” under IPv6 address-family mode submode.  Networks and other parameters are also configured under IPv6 address-family mode submode.

Configuration

R3(config)# ipv6 unicast-routing
!
R3(config)# router bgp 600
R3(config-rtr)# router-id 10.10.10.10
R3(config-rtr)# neighbor 2003:76:1:1::10 remote-as 700
R3(config-rtr)# address-family ipv6 unicast
R3(config-rtr-af)# neighbor 2003:76:1:1::10 activate
R3(config-rtr-af)# network 2003:2:2::/48
R3(config-rtr-af)# exit
R3(config-rtr)# exit

Migrating to IPv6

Three options exist for transitioning from IPv4 to IPv6: dual stack, tunneling, or NAT.

Dual Stack
This involves running IPv4 alongside IPv6 on the same system.

Tunneling
This option allows you to encapsulate IPv6 traffic within an IPv4 header.

NAT
A new network translation extension, NAT-PT allows IPv6-to4 translation.

Dual Stack

Using a dual-stack transition allows servers, clients, and applications to be slowly moved to IPv6.  Both protocols can run concurrently and neither communicating with the other.  If both IPv4 and IPv6 are running on a server for example, IPv6 will be used.

Configuration Example

R1# config t
R1(config)# ipv6 unicast-routing
R1(config)# ipv6 cef
!
R1(config)# interface serial1/0/1
R1(config-if)# ip address 192.168.1.1
R1(config-if)# ipv6 address 2001:1:3:1::1/64

IPv6 Tunneling

Dual-stacking IPv4 alongside IPv6 on systems works well, but it requires most of your infrastructure to support IPv6.  In many cases, the network core does not support IPv6 or it has not been implemented.  IPv6 tunnels solve this problem by allowing IPv6 islands to exist and bridges them over IPv4 systems.

Because IPv6 tunnels provide virtual IPv6 connectivity through an IPv4 transport, it does not matter what specific IPv4 transport is used.  The only requirement is that there is end-to-end IPv4 connectivity between both ends.

Manual Tunnels

The tunnels discussed here are from one router to another.  The source router (RouterA) encapsulates the IPv6 traffic in IPv4 headers, then forwards it to the other end of the tunnel (Router B).  Router B then decapsulates the packets and forwards them on to their destination using native IPv6.

Manual IPv6 tunnels are easy to configure using the tunnel mode ipv6ip command.  Using the  Router A/B example above, the configuration on Router A would look something like this:

RouterA(config)# interface tunnel0
RouterA(config-if)# ipv6 address 2001:2:0:7::/64
RouterA(config-if)# tunnel source 10.1.1.1
RouterA(config-if)# tunnel destination 10.3.3.1
RouterA(config-if)# tunnel mode ipv6ip
RouterA(config-if)# exit

GRE Tunnels

First, GRE tunnels are the default tunnel method on Cisco routers.  GRE tunnels are very flexible and work over most protocols.

The configuration is exactly the same as the manual configuration example above, but you do not have to specify the tunnel mode.  Also, routing protocols can be enabled on GRE tunnel interfaces just as if they were physical interfaces.

6to4 Tunnels

6to4 tunnels are similar to the manual tunnel, but set up the tunnel dynamically.

6to4 tunnels use 2002::/16 IPv6 addresses in front of the 32 bit IPv4 address of the edge router – creating a 48 bit prefix.  Each router on both sides of the tunnel needs a route to its peer.  They only support static and BGP routes, so be careful.

Configure the tunnel as if it was a manual tunnel, using the IPv4 address as the source, but don’t enter a destination.The tunnel requires an IPv6 address using the method just described.  Finally, use the command tunnel mode ipv6ip 6to4.

NAT

Translation is a unique solution because it allows IPv4 devices to communicate with IPv6 devices without the dual stack requirement.  NAT-PT allows bidirectional translation services.

1.  To enable NAT-PT IPv4 to IPv6 translation on a router, the first step is to use the ipv6 nat command on each interface participating in the translation.

2.  The second step is to define at least one NAT-PT prefix.  Only traffic matching the prefix will be translated.  To apply it globally on the router, enter ipv6 nat prefix/prefix_length in global configuration mode.  To apply it to traffic on a specific interface, enter ipv6 nat prefix/prefix_length in interface configuration submode.

3. Define the address mappings (either static or dynamic) using the options discussed below.

Static NAT-PT

For an IPv6 to IPv4 static mapping:

R1(config)# ipv6 nat v6v4 source ipv6_address ipv4_address

For an IPv4 to IPv6 static mapping:

R1(config)# ipv6 nat v4v6 source ipv4_address ipv6_address 

Dynamic NAT-PT

There are many ways to implement dynamic NAT using IPv6, but at its most basic level a pool of addresses is created and the router temporarily assigns them to hosts as they need them.

For an IPv4 to IPv6 static mapping:

R1(config)# ipv6 nat v4v6 pool name beginning_ipv6 ending_ipv6 prefix-length prefix-length
R1(config)# ipv6 nat v4v6 source list (access-list_number | name) pool name 

For an IPv6 to IPv4 static mapping:

R1(config)# ipv6 nat v6v4 pool name beginning_ipv4 ending_ipv4 prefix-length prefix-length
R1(config)# ipv6 nat v6v4 source list (access-list_number | name) pool name