In this ongoing series here at blog.ipexpert.com, we are going to answer the most common questions CCIE instructors hear. Here is the latest:

Question: Does the Proctor Reboot my Rack?

Answer: The answer…drumroll please…maybe. According to a proctor I spoke to (and trust), there is no reboot of the equipment typically. The rack (including the emulated devices) are left in the state that you last had them and the grading engine and proctor swoop in to do their work without reloading your devices.

But you should be aware of brownouts and blackouts that do occur in the facilities that house your equipment. This can certainly occur before the grading process has a chance to work its magic. This is reason number one why you want to always be saving your configurations throughout the day at all times.

Regarding your device rack and its ability to survive a reboot, I certainly would ensure that it can, especially if I have plenty of time after completing all tasks in the configuration section. I just think of it as an additional step in my final verifications. Save all of the devices one last time, and reboot. After the reboot, I can re-run my reachability script and  ensure there are no last minute issues.

NOTE: I am only going to do this rack reboot if I have time. If you complete the configuration section, and there are only a few precious minutes to spare, there is NO WAY I am recycling the equipment.

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

Print Friendly

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 GRE-IPv6 tunnel. 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.

In an earlier post we examined the Manual Configured Tunnel (MCT) for moving IPv6 traffic though IPv4 only networks. In this post, we are going to examine the Generic Routing Encapsulation (GRE) approach to tunneling IPv6 traffic through an IPv4 cloud.

With this approach, the IPv6 packet is encapsulated using a standard IPv4 GRE tunnel approach. Perhaps you are curious why we would add the overhead of GRE when we can encapsulate the packet for transport. Especially when you consider that we can encapsulate the packet directly as we did with the Manual Configured Tunnel (MCT).

The GRE approach is required within integrated IS-IS and IPv6 tunnel environments. If you plan on sending both IS-IS traffic and IPv6 traffic over the tunnel, the protocol field of the GRE header allows for the identification of the passenger protocol if you have both IS-IS and IPv6 traffic to send over this tunnel.

Here we demonstrate the configuration. Notice how similar this is to our MCT. Notice also that this would be the default tunnel encapsulation, we just show the commands here for illustration purposes.

ROUTERA

ROUTERA(config)# ipv6 unicast-routing

ROUTERA(config)# interface loopback 0

ROUTERA(config-if)# ipv6 rip MYRIPNG enable

ROUTERA(config-if)# exit

ROUTERA(config)# interface tunnel 0

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

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

ROUTERA(config-if)# tunnel destination 10.20.20.3

ROUTERA(config-if)# tunnel mode gre ip

ROUTERA(config-if)# ipv6 rip MYRIPNG enable

ROUTERA(config-if)# end

ROUTERB

ROUTERB(config)# ipv6 unicast-routing

ROUTERB(config)# interface loopback 0

ROUTERB(config-if)# ipv6 rip MYRIPNG enable

ROUTERB(config-if)# exit

ROUTERB(config)# interface tunnel 0

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

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

ROUTERB(config-if)# tunnel destination 10.10.10.1

ROUTERB(config-if)# tunnel mode gre ip

ROUTERB(config-if)# ipv6 rip MYRIPNG enable

ROUTERB(config-if)# end

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

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

Print Friendly

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

Print Friendly

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

Print Friendly

So what is the official process for this router on a stick configuration? Well, here is how it works:

Step 1 – traffic from a PC in VLAN 10 enters the switch. The switch access port configuration is simple and straightforward. For example, switchport mode access; switchport access vlan 10.

Step 2 – the traffic exits the trunk link to the router and arrives on the subinterface that is bound to VLAN 10.

Step 3 – the router examines the destination IP address and realizes that the packet must be routed out of another subinterface on the router. It sends the packet out of the other subinterface and that directs the packet over the trunk back to the switch.

Step 4 – the frame arrives at the Layer 2 switch and is sent to the destination VLAN port.

For both the written and the lab exam, you might be required to interpret, or perform this configuration. Here is a sample configuration on the switch. Notice how amazingly straightforward this configuration is:

SWITCH1

vlan 10,20
interface fa0/1
switchport mode trunk
switchport trunk native vlan 99
switchport trunk allowed vlan 10,20

Now here is the  configuration of the router. This is the rather unique part. Notice the assignment of the VLAN ID to the subinterfaces. This must be accomplished before a subinterface and be provided an IP address in this case:

ROUTER 1

interface fa0/0.10
encapsulation dot1q 10
ip address 10.10.10.1 255.255.255.0
interface fa0/0.20
encapsulation dot1q 20
ip address 10.20.20.1 255.255.255.0

Please not that your subinterface ID does not need to match the VLAN ID, but I certainly like to do it that way as it aids me in maintaining and troubleshooting the network.

For the written exam, we want to be sure that we are aware of the Advantages and Disadvantages of such a configuration. Here  are the advantages:

• Layer 3 services are not required on the switch
• It is a simple and easy to understand implementation
• The router enables inter-VLAN communication

The disadvantages of such a configuration are as follows:

• The router is a single point of failure
• The single traffic path of the single trunk is also a single point of failure
• The single trunk link might experience congestion
• There is increased latency in this design

So there you have readers! Everything you might need to know about the basics of this configuration for the written and lab exam!

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

Print Friendly

• 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/iproute_bfd/configuration/guide/irb_bfd_ps6441_TSD_Products_Configuration_Guide_Chapter.html

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

Print Friendly

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

Print Friendly

Question: Am I penalized for over-configuration in the lab exam?

Answer: This is another one of those great questions, especially when you consider the fact that the grading for the lab exam is quite complex. Depending on what track you are discussing, the lab is graded by a computer script, a human, or a combination of both. Given this fact, students begin to suspect that the grading is some mysterious “black art”, that might harshly penalize for the slightest deviation from the proctor’s expectations with a task.

I like to answer this question for students with an example. Say you get the task below:

Sample Task 1 – Switching

1.3 Trunking

Create a standards-based trunk between SW1 and SW4 according to the Layer 2 diagram provided.

2 pts

I recommend that students ask themselves the question here –  how would the proctor write a script to grade this task? I think they would issue the SHOW INTERFACE TRUNK command on each device. In your mind, run through the parameters that must exist.

• Correct two devices
• Correct two interfaces
• UP/UP status
• 802.1Q trunk established

If these parameters are met – you just achieved the 2 pts.

Here are three different configurations (from just one of the two devices) that get the full two points.

Solution 1

switchport trunk encapsulation dot1q
switchport mode trunk

Solution 2

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate

Solution 3

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk allowed-vlan 100,200,300,400,500,501,502

Always ask yourself two questions:

1. Could this additional configuration I am about to add help me gain these points?
2. Could this additional configuration I am about to add potentially cost me here or elsewhere in the lab?

If your answers are YES and NO respectively, then you can certainly consider this “additional” configuration. Notice that Solution 3 comes very close to a NO and YES answer respectfully and should be frowned upon as a result.

Another great rule of thumb in this regard – “do what they ask for, nothing more, nothing less!”

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

Print Friendly

A friend told me that I should check out the text Emotional Intelligence 2.0. As I was reading this book, I quickly realized how practical it can be for CCIE candidates. You see Emotional Intelligence is all about your ability to recognize and control your emotions and to understand the impact that they can have on your life.

You see, we are all familiar with IQ. This is a measure that can be assistance to judge how quickly and efficiently we can learn to pass the CCIE. But what about EQ. This is our Emotional Intelligence rating. This can be very important in the pursuit of CCIE. Remember my cornerstones for success?

-Tech Knowledge

- Psychological State

- Physical Wellness

- Strategy

Certainly IQ impacts your technological knowledge, but think about the impact that Emotional Intelligence can have on your psychological state. And remember, the cornerstones all impact each other. For example, if your emotions are out of control and your psychological state is ruined, it can effect all three of the others.

What are the emotions that we need to watch out for in this pursuit?

• Sad – we can feel lonely and isolated from family and friends as we immerse ourselves in study
• Angry – should we experience a NOT PASS this emotion can be powerful
• Afraid – we may be paralyzed with fear regarding a NOT PASS
• Ashamed – many experience this after a NOT PASS event

As I read more of this text, I will be sure to share what tools we should be able to use in our pursuit of CCIE.

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

Print Friendly