Meraki today

I'm off to Cisco Minneapolis today to be introduced to their recently acquired Meraki cloud-managed infrastructure.

The promise is fantastic, and in Managed IT offerings it holds incredible opportunities.  

I'll be updating as it goes forward.  The UCS/VNX installation yesterday went exceptionally well and I hope to post about some of the quirks I discovered when I have a little more time.

Stay tuned...more as it happens...

The new stuff

Setting up a Cisco UCS blade server and an EMC VNX 5100 today.  I hope to share more as I move deeper into this world.

Success

Troubleshooting Command Blitz

#show controllers serial 0/0
Shows clock rate and DCE/DTE

#show ip interfaces brief
Shows ip addresses, L1/L2 status

#debug ip nat
shows source IP->NAT IP, destination IP and time

#show ip nat translations
shows static nat with inside global, inside local and outside local/global

#show ip nat translations
shows inside and outside interfaces, hits and ACL number

#show ip route
Shows routing table, with indication of how route was learned

#sho ip protocols
info about routing protocols running on router, including interfaces included, networks being routed

#debug ip rip
shows updates, routing table being sent, flash or regular

#debug ip ospf
shows hello, timers, new adjacency

#sho ip ospf neighbor (no "s" at the end)
sho ID of neighbor routers, dead timers, neighbor IP and interface route was learned on (local)

#sho ip ospf database
Shows link states for neighbor (advertising) router, along with the age

#show ip ospf interface serial 0/0
Shows whether or not ospf is running on this interface, process ID, router ID, neighbor counts

# sho ip eigrp neighbors (note - add "s" to eigrp)
Shows address and receiving interface, hold timers,

#show ip eigrp topology
Shows routes in topology table, receiving interface and feasible distance

#sho ip eigrp interfaces
Which interfaces are participating in the eigrp AS

#show cdp neighbors
Connected Cisco devices, local interface they are connected on, capability of the devices, plaform and which port on the connected device

#sho cdp neighbors detail
 Also shows IOS version

#sho ip dhcp binding
Who received an IP address from our pool

#ping 192.168.1.1
U.U.U means that the packet is being blocked by an ACL

#show ip access-lists
#sho access-lists
Both do the same thing, show access lists and hits

#show interface serial 0/0
Find WAN encapsulation type, condition of line

#debug ppp packet
PPP negotiation, state, authentication and errors

#show frame-relay map
interface, IP address and DLCI

#sho frame-relay PVC
statistics for FR

#sho frame-relay lmi
LMI type, send/receive of status updates

#debug frame-relay lmi
shows LMI info, watch for "myseq" and "yourseq" incrementing, "status 0x2" means FR is operational

#show vlans
Which switch interfaces are included in which vlan - a missing interface indicates it is a trunk

#show interfaces trunk
Shows ports that are trunking, their status, encapsulation type and allowed vlans

#show vtp status
version, operating mode, domain name, config revision number

#show vtp password
--self-explanatory

Some random IPv6 thoughts

Nearing the big test day and I'm brushing up on a few things.  IPv6 is one of them.

(NOTE:  I don't know how many other network engineers have the same problem, but until I deploy a technology a couple times, I really don't feel like I know it at all.  Memorizing this stuff is just tedious and difficult without the tactile portion of the technology, so I always struggle on these sorts of topics and require constant review)

OK, IPv6 addresses are 128-bit written in 8 sections of 4 hex characters each, separated by colons.  The first 64 bits are the "prefix" and contain the global routing information, provider class and the provider's sub-class.  The second 64 bits are the host ID.

Leading and contiguous zeros are able to be dropped off the address for ease of reading, and contiguous zeros can be replaced with a double-colon (or ::) but that can happen only once in an address.

IPv6 has no broadcast addresses, rather it uses multicast and anycast packets.  Multicast packets function similarly to the IPv4 multicast, while anycast packets will be responded to by the first node within the group.  Anycast would typically be used for load balancing.

Unicast packets in IPv6 are like the unicast packets in IPv4 - the packet has a specific destination.

Some common prefixes:

2000:: - Global unicast (Internet-routable)
FF02::1 - all nodes on the local network
FF02::2 - all routers
FF02::5 - OSPFv3 all routers
FF02::6 - OSPFv3 DR/BDR
FF02::9 - Ripng multicast
FF02::A - EIGRPv3

The last 64 bits of the address is the host identifier.  It is composed of the MAC address with FFFE inserted in the middle of it.  Then the U/L (Universal/Local) bit is inverted.  The U/L bit is the 7th bit from the left.

Today's stumbling blocks in my memory

These are just a few points I want to reconsider today.  It is best to be clear and particular about them.

One practice exam question I was incorrect in answering was the "host mask" vs. "inverse host mask."  I had incorrectly marked the answer for a host mask in an ACL as 255.255.255.255.  The reality is that a host mask in an ACL is 0.0.0.0 -which means that all bits must match.

From the Cisco website, I summarize:

In an inverse mask, a 0 must be an exact match to be considered for the traffic routing, and a 1 is a "don't care."  ACL equivalents:

• The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any". (although the source could be any IP address whatsoever - all will still apply)
• The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".  

DHCP configuration cheat-sheet

1. prepare your excluded addresses
2. Create your pool
3. Add the network
4. Add the domain name
5. Add the default router
6. Add the DNS servers

As an example:
R1(config)#ip dhcp excluded-address 10.1.1.1
R1(config)#ip dhcp pool MYPOOL
R1(dhcp-config)#network 10.1.1.0 /24
R1(dhcp-config)#domain-name madhouse.local
R1(dhcp-config)#default-router 10.1.1.1
R1(dhcp-config)#dns-server 8.8.8.8 8.8.4.4

Dynamic NAT

I configured a dynamic NAT lab tonight, also.  One of the things I wanted to remind myself was that the NAT statement when configuring dynamic NAT does not require the overload keyword, as this is doing IP-to-IP translation and not port translation (or PAT).

I also looked up what exactly a RIP flash update is.  A flash update is an update that is sent to neighbor routers when a route change takes place.  This occurs in both RIPv1 and RIPv2 - however that is a "triggered update" which is a characteristic of Link-State routing protocols, not distance-vector.  This leaves grey area in my understanding of RIP, but at least I understand it now.

And finally...RSTP

Rapid Spanning Tree, or RSTP, is an IEEE approved protocol designated 802.1w.  It shares some similarities and core function with STP, namely:

1. Same root bridge election process
2. Same path cost determination

It is fully backward-compatible, however the benefit of the "rapid" is lost when using RSTP along with STP.

RSTP changed the port states, replacing listening and learning with a single state of "discarding."  It also added some port types, which are "alternate" and "backup."

The alternate port takes the function of the root port should the root become in-operational, and the backup port takes the place of a designated port.  The port types are not "blocking" but "discarding" so they never need to go through the listening and learning states, allowing faster convergence.  The ports also have the ability to assume a different port role based on the condition of their links.  For instance - a port that is acting as a backup port can transition to a root port if its root port fails and the fastest path back to the root is through the other switch to which it is connected.

RSTP considers any port connected to another switch running in full-duplex to be a point-to-point link, while any half-duplex connection is considered to be link type "shared."  A half-duplex connection would typically be to a hub, although these are not in wide use any longer in 2013.  Any end-user devices such as PC or phone are considered to be edge-type links.  RSTP converges differently based on port type.

One major difference between RSTP and STP is that in STP, only the root bridge sends BPDUs, generally.  In RSTP, all switches send BPDUs to all other switches in the topology.  The BPDU is used for link state and root bridge identification, but also is used as a keep-alive.  If an RSTP switch misses 3 BPDUs (compared to STP's 20-second max age) it identifies that switch as dead and sends the TCN to all switches alerting to the change.

Edge type ports in RSTP are similar to using portfast and BPDU guard on that interface, except that by configuring the port with portfast it becomes an edge device and by default will transition to a point-to-point port type if it receives a BPDU.

Point-to-point ports handle convergence rapidly by following a different process than STP.  When a switch is introduced in to a network, and based on initial BPDU that alerts it that one of its local ports will become a designated port, it immediately transitions that port to the forwarding state and sends a proposal to the sending switch to start sending data.

The sending switch, upon receipt of the proposal, sets all other non-edge ports to discarding to deter loops and begins learning MAC addresses of its edge-type ports.  The process of putting nonedge ports into discarding state is called synchronizing the ports.

RSTP design and configuration is beyond the CCNA certification level, but it's good to know how and why it works.

Yet more Spanning Tree

Spanning-tree portfastome Cisco enhancements to STP are:

Portfast is a feature that skips the listening and learning states and the interface goes straight to forwarding, reducing the amount of time it takes for a port to come online.  This is useful when plugging in an end user device, such as a PC or phone.  However, if you plug in a switch or hub, you are going to want to enable BPDU Guard.

BPDU guard disables a portfast-enabled port if it receives a BPDU packet on that interface.  This way we avoid loops that would normally be discovered during the listening delay.

Uplinkfast is similar to portfast, but its use is in networks where there is a redundant uplink to from access-layer switches to core.  When a known uplink port goes offline, the second link will skip the listening and learning states and go straight to forwarding.

Backbonefast is similar to uplinkfast, however the access-layer switch does not have direct knowledge of the link failure, rather it exists between distribution switches.  Once the link between distribution switches goes offline, both think they are the root bridge and start advertising as such.  When the access layer switch forwards the distribution layer BPDU to the other distribution switch, it realizes it has a path to replace the link between switches and the topology converges.

These are all features of spanning-tree and their commands are:

R1(config-if)#spanning-tree portfast
R1(config-if)#spanning-tree bpduguard enable
R1(config-if)#spanning-tree uplinkfast
R1(config-if)#spanning-tree backbonefast

Or to enable BPDU guard globally, enter:

R1(config)#spanning-tree portfast bpduguard default

And you can tell if STP is configured on your switch by using:

R1# sho spanning-tree summary

Etherchannel is not necessarily a spanning tree enhancement, but is a means to utilize multiple links between switches.  Etherchannel will take up to 8 links and load balance across them in stead of disabling the extra links to avoid loops.  The ports must all be configured with the same speed and duplex to participate.  If one of the links in an etherchannel goes offline, the switch will still utilize the remaining ports and load balance accordingly.  To create an etherchannel, enter into each interface to participate in the etherchannel and use the channel-group <x> mode on command.  Cisco IOS then creates a logical interface called a port-channel interface so that parameters can be set on the entire port-channel from one location.

STP port transitions - I missed these somehow

Not sure how I missed this info in my last post, but it's important none the less.

Because STP is designed to remove switching loops while providing a redundant topology for the network, it needs a means to adjust port state if a failure occurs.  Spanning Tree goes through some transitional port states to move a port from blocking to forwarding, and each has a timer to keep the network from unnecessary loops during topology update.

The transition process and states of a port in a Spanning-Tree topology:

1. Disabled - either administratively or due to security violation.  No data sent
2. Blocking - no user data sent, but listening for BPDUs.  This state will wait 20 seconds before transitioning to the next state.  The 20 second timer is known as the max-age timer.  In essence, the switch needs to miss 10 BPDUs (2 seconds each) before it will transition
3. Listening - no user data sent, listening for and forwarding BPDUs with topology updates.  This lasts 15 seconds
4. Learning - no user data sent yet.  Adding MAC addresses it receives to the CAM table and building root path.  A port will take 15 seconds on this state as well.
5. Forwarding - normal operation, user data sent

Based on this information, STP can take up to 50 seconds for a network to converge.  In small networks, these forward-delay timers can be manually set to quicken convergence.

When a nonroot switch recieves a BPDU indicating a topology change, it sends a special BPDU back to the root bridge called a Topology Change Notification, or TCN.  This is one of the only times a BPDU does not originate from the root bridge.  Once received, the root bridge will alert the other switches to start expiring their MAC address tables 8 times faster than the normal 300 seconds and to rebuild the root paths.

 The max-age and forward-delay timers are configured based on a network diameter of 7 switches.  The network diameter is the number of switches between any two hosts on the network.  If you have a small network diameter, such as 2 switches, these timers can be adjusted to lower values to speed convergence, however, when the network grows (like it always does) you will need to reconfigure these timers on the root bridge and the information will propagate to the rest of the network from there.

VLAN Trunking Protocol

VLAN Trunking Protocol, or VTP, is a Cisco-proprietary protocol that propagates VLAN information from one switch acting as a server to other switches in the same domain.  The information is multicast from the switch configured as the server to other switches in the domain using the MAC address 01-00-0C-CC-CC-CC, to which only Cisco devices respond.

The three modes for VTP are:

1. Server - updates are made on any switch configured as a server and multicast to other participating members of the domain.  This is the default mode for Cisco switches
2. Client - updates are not allowed to be made, but they receive updates from servers
3. Transparent - updates are able to be made to the local vlan database only, although the switch will forward updates

 When a change is made on a VTP server, it updates its revision number and sends the update to other systems in the domain.  If a switch receives the update and the revision number is higher than the rev currently on that switch, it adds the update to its database and updates its own revision.  If the rev is lower than its current running revision, it sends a response to the sender to update.  If the rev is the same number, it ignores the update.

In client mode, switches simply get their vlan information from a VTP server.  Updates cannot be made on them, but the do forward VTP updates to keep the domain synchronized.  They do not store any VLAN information, so when they reboot there is no configuration retained.  Rather, they pull the latest revision from a server each boot.

Transparent mode in VTP will not accept revision changes in the VTP domain, but you are able to create and modify local VLANs on the switch.  Transparent mode switches will forward VTP updates to other downstream switches should there be any to keep the domain consistent.  Transparent mode switches store vlan information in the startup and running-config instead of in the vlan database, which is why they do not propagate VLAN info to other switches.  Also, when using VTP Transparent mode, you are able to use extended VLANs beyond the default 1-1005.  VTP transparent mode allows the use of 1006-4096 for local VLANs only.

Exercise caution when adding switches to your network in server mode.  If the revision number on the new switch is higher than the running configuration, and you have not added any VLANs to it when you introduce it to the network, all VTP members will overwrite their existing VLAN database with the empty database of the new switch.  (NOTE:  I have seen this happen in a large production environment.  It's what I call an "RGE" or "resume generating event.")  To avoid this trouble, configure new switches as client or transparent when introducing them to the domain.  To reset the revision number, change the domain to a bogus name and back again, or change the mode to client or transparent before introducing the new switch.

VLAN information is sent over trunk links to all other switches, whether or not the VLANs are in use on the downstream switches.  To conserve bandwidth on trunk links, a VTP server can enable VTP pruning.  Pruning essentially limits VTP updates to switches that have that VLAN active, or assigned to a port, in that VLAN.  If the VLAN doesn't exist on the receiving switch, it does not accept the update.

To configure VTP on a switch, enter config mode and use the vtp command.  The default domain is null, and you must match the case-sensitive domain and password on all switches to participate.  If a switch is in server or client mode, it will inherit the domain from a server's summary advertisement once introduced.

Use the command:

R1#show vtp status

to determine the VTP revisino number, the operating mode of the switch, the pruning status, domain and MD5 password hash.  This is the main troubleshooting tool for VTP.

VLAN trunking

OK, my last post said I was going to do some STP, but I think we're going to do some VLAN trunking before bed tonight.

VLAN trunks are links that carry multiple VLANs across them.  When a packet traverses a trunk, it is "tagged" with a VLAN number.

Cisco's default protocol for trunking is ISL - or Inter Switch Link.  ISL adds 26 bytes to the header with the VLAN info and 4 bytes to the end of the packet as a CRC.  Because the packet has these additional 30 bytes, it may exceed the default 1518 byte MTU on Cisco switches and drop the packet.  Because of this, an ISL trunk needs to be a point-to-point connection with no devices in between.

802.1q trunking is the IEEE's trunking protocol. Instead of adding to the header, it inserts the 4-byte VLAN information into frame after the source address.  Because the original size of the packet changes, a new CRC must be calculated and the frame's FCS modified.

A native VLAN is a feature of 802.1q trunks and not ISL.  Traffic reaching the switch on the VLAN defined as the native VLAN is not tagged as it goes across the trunk.  For this reason, it is important to make sure the native VLAN on both sides of a trunk is the same, or data will leak from one VLAN to another.

Cisco has a proprietary protocol called DTP, or Dynamic Trunking Protocol.  Depending on the port's condition, a trunk can be dynamically created when the switches are plugged in.  The trunk port types are:

1. Access - no trunking will take place
2. Trunk - the port trunks only
3. Dynamic desireable - the port will turn itself into a trunk if the other end is dynamic desirable, dynamic auto or trunk
4. Dynamic Auto - the port will become a trunk if the other end is dynamic desirable or trunk
5. Nonegotiate - the port will trunk permanently, but will not negotiate DTP to accommodate non-Cisco switches

 To determine a port's trunk status, use the

R1#show interface trunk

command.  This will show the status of the port as well as its trunking protocol and default vlan.  If a port is not seen in the

R1#show vlan

command output, it is configured as a trunk port and will only appear in the show interface trunk output.

OSPF - the final chapter (until the CCNP)

A stub zone can be configured in an area, which will replace any networks learned by the ABR with a default route pointing to that ABR.  This minimizes the routing updates that need to propagate that area, since any traffic not designated in that area gets sent to the default router.

All routers in a stub area need to be identified as such.  If the "stub" flag is not set on a router in the stub area, an adjacency will not form.  Also, networks within the stub area need to be manually summarized.  To do that, enter the command:

R1(config-router)#area 51 range 172.16.1.0 255.255.252.0

To redistribute the default route into the OSPF topology table, use:

R1(config-router)#default-information originate

And OSPF commands that can be applied to an interface:

R1(config-router)#ospf cost 2
Modifies the cost of the route to force preference over another interface.

R1(config-router)#ospf priority 22
Modifies the router priority to set the DR/BDR election to take place.  This is a best-practice in OSPF.

Comands used to verify OSPF and troubleshoot:

R1#show running-config
R1#show ip protocols
R1#sho ip ospf neigbor
R1#sho ip ospf database summary
R1#sho ip ospf interface
R1#debug ip ospf events

And onward we go!  I think it may be time for a little STP.  

Yet more OSPF

Picking up where we left off yesterday...

The router ID is determined by selecting the highest IP address of a loopback interface on the router, and if no loopback interface is defined, OSPF selects the highest IP address on a physical interface.  The loopback, or virtual interface is used because it can not go down due to L1 issues and will always be in an up/up state unless the router is not functioning correctly or powered off - in which case it won't participate in the OSPF process anyway...

OSPF may operate in one of three topologies, affecting the dead timers, hello packets and bandwidth conservation.  The topolgies are:

1. Broadcast, Multi-Access - several devices on a shared medium (such as ethernet).  Hello is sent every 10 seconds, dead-timer is 40 seconds
2. Non-Broadcast Multi-Access - several devices sharing medium, but clients are not privy to each others' broadcast and multicast traffic.  Frame Relay is an example, and hello packets are sent every 30 seconds, with dead timers being every 120 seconds.  NOTE:  Dead timers are 4 times the hello by default.
3. Point-to-point - only two devices share the medium, so there is no need to update hello and dead timers as often.  Consider an ISP connection or WAN link using a /30 subnet mask.

Designated Router and Backup Designated Router (DR/BDR) is an OSPF function designed to minimize multicast traffic on BMA and NBMA networks (there is no need for updates on point-to-point networks because there are only two devices).  When a link state changes on one interface, OSPF will send an LSU to all its neighbors.  In a broadcast multi access topology with several routers, each router will get an update, then send updates to all its neighbors.  Once those routers get the LSU, they send updates - this floods the network with updates that all these routers likely have anyhow.

To deter multicast storms, a DR and BDR are elected using first the router with the highest priority, which is an arbitrarily- assigned number with a default of 1, and if there is a tie the highest router ID. When there is a link state change, the DR and BDR are notified, and they update the other routers in the area.  If a router is assigned a priority of 0, it is ineligible for DR/BDR election.  In practice, however, the first router in an area to come online becomes the DR and the second becomes the BDR.  To change the DR/BDR election results, the preferred router must be brought online and the existing DR/BDR rebooted.  (NOTE:  In my humble opinion, that defeats the purpose of an "election.") 

This information is multicast to two different IP addresses.  The DR/BDR listen for LSUs on 224.0.0.6, then multicast to the remaining routers on 224.0.0.5.

OSPF initialization takes place by the following steps:

1. A router comes online and sends a hello packet out all interfaces participating in the OSPF process.  The hello packet contains the router ID, hello/dead intervals, authentication password and area as well as DR and BDR addresses, as well as known neighbors and stub flags.
2. Any router that receives the hello packet checks its configuration to make sure the area, password, hello/dead intervals and stub flags match  exactly (if one of these parameters is different, the router will not form an adjacency).  If the criteria is all identical, it will add that router to its topology table and respond with a hello and its information
3. Once the first router receives a hello from the second, it adds the second to its topology table along with its neighbors
4. Once all neighbor information is accumulated, the OSPF process runs the Dijkstra algorithm on its topology table to determine the shortest paths to the discovered networks
5. If the topology has a DR elected, it queries the DR for the topology table and enters it into its own

It is best practice to configure a loopback interface on all routers participating in the OSPF autonomous system to use as the router ID.  Because this IP address connects to noghing and is simply used as an identifier, it is customary practice to assign a host mask, or 255.255.255.255 (/32).

OSPF Review - especially stub zones

I've had OSPF on my list of important things to re-learn.  I had a pretty decent grasp of it a few years back, but simply haven't had much use of it in the field and need to go back over the particulars.  I remember there being questions and an interactive problem on the exam regarding a stub zone the first time I took the exam, so I want to be prepared.

So here goes, narrative on OSPF:

OSPF was developed in 1988 to address the scalability issues of RIP.  Where RIP is classful, OSPF is completely classless - so the subnet mask is sent along with every network of which OSPF is aware.  This resolves the problems with dis-contiguous networks, as each subnet and subnet mask is placed into the topology table, however, this can lead to increased router resource consumption.

OSPF will run Dijkstra's Shortest Path First (SPF) algorithm on each network as it arrives on the router. This can cause heavy load on the router if there are a large number of routers in the autonomous system, especially when a link rapidly goes up and down, which is called "link flapping."  Each router will receive an update each time the link changes state.

To minimize the effect of link state updates over a large network, OSPF breaks the autonomous systems into areas.  Routers that link multiple areas are called Area Border Routers (or ABR) and these routers have the responsibility to summarize routes within their area and present them to adjacent areas.  If there is a link failure within a summarized network, only the affected area is updated and the adjacent areas using the summary route are completely unaffected.

Area 0 is known as the backbone router, and all networks must be connected to the backbone in some way.  Routers that are either completely inside area 0 or have an interface in area 0 are known as "backbone routers."  The backbone is typically composed of fast network connections (100/1000 Mb/sec) because all interconnected areas send their traffic through it.  Routers that have an interface in are 0 and another area are ABRs for that connected area.

A stub area is used to minimize the amount of traffic and utilization on routers where a single path in and out of the area exists.  The stub area is an area where there is only one path in or out of the network.  This reduces the amount of information in the topolgy table, because the ABR replaces any routes learned through it with a default route to itself and advertises that default route to the other routers within that area.  Because area 0 is an interconnecting area, it can never be configured as a stub area.  All routers within the stub area must have it defined using the stub keyword, such as:

R1(config-router)#area 51 stub

Once configured as a stub on all routers, the routers that are not ABR have their gateway of last resort set, where they had none before the stub configuration.

OSPF path cost is calculated using Dijkstra's SPF algorithm, which is 10^8 divided by the link bandwidth in bps.  Therefore, costs to know are:

1 Gbs - cost 1
100 Mbs - cost 1
10 Mbs - cost 10
E1 - cost 48
T1 - cost 64
64K - cost 1562
56K -  cost 1785

Path cost is determined by adding all costs between two endpoints, and SPF will put the route with the lowest cost into the routing table.

I'll intend to lab this up tonight or tomorrow, and will have more thoughts on it.

Some random Layer 2 thoughts

802.1q inserts 4 bytes into the frame header and recalculates the FCS, and this identifies the VLAN.  This is called a "tag."

VTP traffic is sent over VLAN1, so all trunks must be configured to send traffic on that VLAN.

IPv6

I have yet to lab IPv6, so most of these comments are needing to be simply committed to memory for the exam.  I have every intention of labbing this up in the coming months, however, as the Internet (which we know drives all technology in the world of networking) is starting to move that direction.  But for now, we memorize facts and gather concepts in hopes of knowing enough to pass the exam...(I feel a little dirty about that last statement)

IPv6 was developed to address the fact that we are running out of IP addresses worldwide.  The growth of the Internet was not anticipated, and experts suggest that each individual on earth would one day require over 250 unique IP addresses for their own personal gadget use (Ed. note:  I find that disturbing and fascinating all at the same time)

Work on IPv6 began in 1991, once the coming exhaustion of IPv4 addresses was predicted to be between 2005 and 2015.

 Some of the shortfalls of IPv4:

1. LAN latency caused by ARP requests which are processed as interrupts on the Ethernet port
2. No mobility - no way to allocate addresses to mobile devices, such as phones or PDAs
3. Routing issues - with large routing tables, routing can become problematic
4. No built-in security, rather it is left to applications

IPv6 uses 128-bit addresses, compared to IPv4's 32-bits.  The first half of the address is the L2 and the second part of the address is the L3, and no subnet mask is required.  Rather, IPv6 uses NDP (Neighbor Discovery Protocol) for L2-L3 mapping, replacing ARP.  The first part of the address is the link-layer address which identifies the destination host, while the 2nd part identifies the destination network.

UPDATE:  I have to retract my above statement, as I think I misunderstood it.  The first 64 bits of an IPv6 address contains the global routing information, as well as the provider network.  The second half of the address is the host ID, and can be generated by inserting FFFE into the middle of the MAC address and inverting the U/L bit (which is the 7th bit from the left).  I apologize if I confused anyone beside myself...

RFC1884 is the specification for IPv6, and it states that addresses should be expressed as 8 groups of 4 hex digits separated by colons.  We therefor refer to it as "coloned hex."  There are 2^128 addresses available in IPv6, which means there are approximately 5*10^28 addresses for each individual on earth.

The RFC also states that leading zeros can be eliminated and successive zeros can be replaced with double colons in the expression of the address, but that there can only be one pair of double-colons in an address.  The double-colon can begin the address or end the address - beginning the address would be when using an IPv4-compatible or IPv4-mapped format where you tag the IPv4 address to the end of the IPv6 address.

In IPv6, broadcasts are replaced with multicasts and anycasts.

Unicast in IPv6 is the same as in IPv4, where a packet is sent to a single destination.

Anycast packets are sent to any address assigned to a group of interfaces, but will go to the first to accept the packet - such as used in load balancing.

Multicast delivered to all interfaces defined in the group.

Migrating to IPv6 from IPv4 will be done in one of two methods:

1. Dual-stack - preferred because both protocol stacks are running on the network and the stack to be used is identified by the destination address.  A DNS server is required, and all interfaces are assigned both an IPv4 and IPv6 address.  If you add the IPv6 address onto an interface along with an IPv4 address, you have a dual stack.
2. Tunneling - the IPv4 header of 20 bytes is appended on to the IPv6 address.  The IPv6 packet is encapsulated within the IPv4 packet.  All routers in the network need to support the dual stack, since they will need to route all traffic.

IPv6 requires that each interface on the network have a unique Interface Identifier, which is the MAC address with FFFE inserted into the middle of the address.

Routing for IPv6 can be done with:

1. Static routes
2. OSPFv3
3. RIPng
4. EIGRP for IPv6
5. ISIS for IPv6
6. MP-BGP4

Commands for configuring:

R1#(config) ipv6 unicast-routing
R1#(config)interface fast ethernet 0/0
R1#(config-if)ip address 192.168.1.2 255.255.255.0
R1#(config-if)ipv6 address 2eef:c001:b14:2::c12/125
R1#(config-if)end
R1#

 NOTE:  I added a couple IPv6 address to a GNS3 lab and was able to ping it.  I will need to do some further reading and lab work to fully grasp these concepts...