IPexpert’s CCIE R&S Written and Lab Bundle -  Buy a Bundle, Save a Bundle

Buy a Bundle, Save a Bundle! This week IPexpert has an incredible deal for CCIE R&S Candidates! We have bundled some of our most requested materials together and are offering them at a significantly reduced price. This one of a kind bundle offers CCIE R&S aspirants the opportunity to build strong foundational knowledge of all the technologies encountered on the CCIE R&S Lab Exam. Become an an EXPERT in R&S Today!

 

What’s Included in IPexpert’s CCIE R&S Written & Lab Bundle?

• CCIE R&S Online Written and Lab Fundamentals Bootcamp Course with Special Guest CCIE Instructors
• CCIE R&S Blended Learning Solution (Streaming/Electronic)
• IPexpert’s New IPv4/6 Multicast Operation and Troubleshooting Guide

Retail Price $3097
Promotional Price $1449

Note:

• Offer ends Friday, February 17th, 2012 at 5:00 PM EST
• Valid for all new orders only, and orders must be placed through website (not called in or ordered via telephone).
• Cannot be combined with any other promotion or discount.

 

According to most in the “know” regarding IPv6, IPv4 is NOT going away in our lifetime. Pockets of the current protocol for networking will continue to exist for the foreseeable future; they might just get smaller and smaller, and more dispersed. Why is this? It is because of the rich transition mechanisms that exist to allow IPv4 and IPv6 to co-exist.

In this post, we are going to cover one of the IPv4 to IPv6 transition mechanisms that we ran out of time for when we conducted an evening session of our CCIE R&S Lab Fundamentals Bootcamp course here at IPexpert. This feature is termed a Manual Configured Tunnels (MCT). It is a statically defined, point-to-point type of method for connected two network areas of IPv6 that might be separated by IPv4-only network devices.

One of the beauties of this Manually Configured Tunnel (MCT) is that they are supported by most of the stacks and routers that you might run into within production networks today. This transition mechanism is specified in RFC 4213. This RFC specifies the methodology for manually configured IPv6-over-IPv4 tunnels for transporting IPv6 packets over an existing IPv4 network.

If you are a fan of history, this simple and direct approach is one of the first transition mechanisms developed with the intent of ensuring that IPv6 packets can be successfully transported through IPv4 only network devices. Manually Configured Tunnels use protocol 41(IPv6) to encapsulate the traffic, and the tunnel encapsulation is determined from the static configuration information present on the tunneling node. The tunneling node can actually be a dual-stack router or host. For MCTs, additional information such as the packets of interests are found out based on the configuration/routing table in the node.

In the Cisco world, you might consider MCTs for stable connections that might require regular communication between two edge routers. In order to create the tunnel, you assign an IPv6 address to the tunnel, and you use the existing IPv4 addresses on your edge dual-stack devices for tunnel source and destination.

Here is an example configuration on two dual-stack Cisco routers. Notice the use of RIPng to enable dynamic routing information to pass through the “sea” of IPv4-only devices:

ROUTERA

ROUTERA(config)# ipv6 unicast-routing

ROUTERA(config)# interface loopback 0

ROUTERA(config-if)# ipv6 rip ROUTERARIPNG enable

ROUTERA(config-if)# exit

ROUTERA(config)# interface tunnel 0

ROUTERA(config-if)# ipv6 address 2001:13::1/64

ROUTERA(config-if)# tunnel source fastethernet0/0

ROUTERA(config-if)# tunnel destination 10.20.20.3

ROUTERA(config-if)# tunnel mode ipv6ip

ROUTERA(config-if)# ipv6 rip ROUTERARIPNG enable

ROUTERA(config-if)# end

 

ROUTERB

ROUTERB(config)# ipv6 unicast-routing

ROUTERB(config)# interface loopback 0

ROUTERB(config-if)# ipv6 rip ROUTERBRIPNG enable

ROUTERB(config-if)# exit

ROUTERB(config)# interface tunnel 0

ROUTERB(config-if)# ipv6 address 2001:13::3/64

ROUTERB(config-if)# tunnel source fastethernet0/0

ROUTERB(config-if)# tunnel destination 10.10.10.1

ROUTERB(config-if)# tunnel mode ipv6ip

ROUTERB(config-if)# ipv6 rip ROUTERBRIPNG enable

ROUTERB(config-if)# end

Notice how straightforward this configuration is, and also notice the critical importance of the tunnel mode command in order to ensure the use of the Manually Configured Tunnel.

In future blog posts, we will examine other important options for the smooth transition between IPv4 and IPv6.

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

Facebook: http://www.facebook.com/compsolv

 

In this post, we are going to cover a feature that we ran out of time for when we conducted an evening session of our CCIE R&S Lab Fundamentals Bootcamp course here at IPexpert. This feature was the 802.1q tunneling feature. You will often hear it referred to as simply Q-in-Q tunneling.

In production network environments, Q-in-Q tunneling often shows up in Metro Ethernet environments. In these networks, service providers are interested in providing transparent Layer 2 services to clients. This option is appealing since the customer devices do not need special, high-end equipment to run things like MPLS, and the customer equipment can be freed from running a routing protocol, as would be found in a Layer 3 MPLS VPN environment.

In Q-in-Q tunneling, the service provider takes the traffic received from a customer and “tunnels” this traffic by appending a new Ethernet header with a new 802.1Q tag. This outer tag that service provider adds is often referred to as the “Metro Tag” for the most obvious application in Metro Ethernet environments as we have described. Adding this special new tag allows the service provider to identify traffic as belonging to a certain customer, and allows the provider to transport the traffic through their cloud without worrying about overlapping customer VLAN IDs.

Q-in-Q tunneling can be combined with Layer 2 Protocol tunneling to allow customers to send Layer 2 protocols through the service provider cloud as well. Examples of such protocols would be CDP, STP, and VTP traffic.

When you engage in Q-in-Q tunneling, Cisco recommends that you increase the system MTU since the frame size is now larger. System MTU should be increased to 1504 bytes per Cisco’s documentation.

Here is a sample configuration of this Q-in-Q and Layer 2 Protocol tunneling configuration:

system mtu 1504
!
interface fa0/1
switchport access vlan 10
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable

While this information here has you ready for the Written Exam, if you are interested in studying this feature in greater depth for the Lab Exam, use the link below:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_37_se/configuration/guide/swtunnel.html

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

 

Sometimes Cisco written exams can throw a bit of a curve ball at students when it comes to the questions that can creep into the overall pool of queries. One way in which this can happen is when Cisco asks about a technology or two that is not supported on the current equipment that Cisco is using in the practical lab exam for the same track. Currently we know that for the Version 4.0 of the CCIE R&S exam, Cisco features the following:

• 1841 series routers – IOS 12.4(T) – Advanced Enterprise Services
• 3825 series routers – IOS 12.4(T) – Advanced Enterprise Services
• Catalyst 3560 Series switches running IOS version 12.2 – Advanced IP Services

Correctly so, students tend to study for the written exam against the backdrop of these Cisco devices and Operating Systems. That is a fine idea, but let us be sure to be ready for some features here and there there are not in the scope of our lab equipment.

In this post, I want to discuss Bidirectional Forwarding Detection (BFD) as this feature could very well find its way into a Cisco written exam on the subject of Routing and Switching. This technology is found on Cisco 6500/7600 series routers, as well as 12000 series and Carrier Routing System (CRS-1 Routers).

What is the point of this technology? Like so many protocols and techniques in modern Cisco networking, Bidirectional Forwarding Detection seeks to speed up routing protocol convergence. How does BFD seek to accomplish this? BFD focuses on the ultra-fast detection of node or link failures in the routing infrastructure.

What is the typical approach for the detection of a link or node failure? It is for some type of Hello or Keepalive mechanism to be used at Layer 3. In fact, we have seen these typical mechanisms attempt to evolve by permitting the use of sub-second intervals, as opposed to the long standing multi-second intervals that worked just fine in non mission critical data networks.

BFD operates in a similar fashion, except the fast link hellos are accomplished at Layer 2 instead of the traditional Layer 3. Why is this so exciting? It is not just the fact that there can be blindingly speedy detection of a failure, but also the fact that the CPU impact of the BFD process ends up being much less compared to other Layer 3 fast hello approaches. In testing accomplished by Cisco Systems, network devices running 100 concurrent BFD sessions experienced an increase in CPU utilization of a mere 2%.

For Bidirectional Forwarding Detection to operate correctly in your network environment, you obviously need to use the Cisco Feature Navigator (cisco.com/go/fn) and ensure that you are running the correct hardware and software version for full feature support. This feature does indeed require the cooperation of your Layer 3 protocols, and the great news is that Cisco implementations of EIGRP, IS-IS, and BGP, as well as such important support protocols like HSRP all support Bidirectional Forwarding Detection now.

Thanks for reading this blog post here at blog.ipexpert.com, and should you encounter this Cisco technology in your written, you are now MORE than ready for it! Continue to enjoy those studies!

Should you want more information on BFD at this time – here is a Cisco Documentation Link:

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bfd/configuration/12-4t/Bidirectional_Forwarding_Detection.html

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

UDLD is a Cisco proprietary feature that seeks to eliminate links the can either send or receive traffic, but cannot do both. For example, it can be quite common in Fiber links that a switch can send frames over the connection just fine, but the switch is not able to receive return frames.  Such a unidirectional link condition can be devastating for Spanning Tree Protocol (STP) of course, since a switch could fail to receive BPDUs and incorrectly converge and create a loop in the network.

UDLD functions by the neighbor switches sending specialized frames to a reserved MAC address on each device. The devices look for their returned ID in the frames from the neighbor. There is a normal mode of operation with the feature that serves to simply notify an administrator that the unidirectional link condition could be present. The aggressive mode of operation actually error disables the port when the condition is detected.

Like many Layer 2 features, UDLD can be enabled globally on a Cisco switch, or it can be enabled under a specific interface(s). When the feature is enabled globally, it only effects fiber ports. The command syntax is as follows:

udld {aggressive | enable |message time message-timer-interval}

The interface level command is:

udld port {aggressive |disable}

In an earlier post on LoopGuard, we mentioned how LoopGuard can catch issues that are related to software type problems on a switch and prevent a loop in a wider variety of circumstances. You should realize that UDLD is preferred for catching problems within EtherChannel configurations. While LoopGuard would block an entire EtherChannel bundle in the event of problems, UDLD can just disable the flawed link in the bundle.

For your written exam, it is also important to realize that this UDLD feature can be used to correct port mismatch errors that appear in the show cdp neighbors output as a result of miswirings.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv