Posts from ‘CCIE R&S Written’

Jan
03

Continuing my review of titles from Petr’s excellent CCDE reading list for his upcoming LIVE and ONLINE CCDE Bootcamps, here are further notes to keep in mind regarding EIGRP.

About the Protocol

  • The algorithm used for this advanced Distance Vector protocol is the Diffusing Update Algorithm.
  • As we discussed at length in this post, the metric is based upon Bandwidth and Delay values.
  • For updates, EIGRP uses Update and Query packets that are sent to a multicast address.
  • Split horizon and DUAL form the basis of loop prevention for EIGRP.
  • EIGRP is a classless routing protocol that is capable of Variable Length Subnet Masking.
  • Automatic summarization is on by default, but summarization and filtering can be accomplished anywhere inside the network.

Neighbor Adjacencies

EIGRP forms “neighbor relationships” as a key part of its operation. Hello packets are used to help maintain the relationship. A hold time dictates the assumption that a neighbor is no longer accessible and causes the removal of topology information learned from that neighbor. This hold timer value is reset when any packet is received from the neighbor, not just a Hello packet.

Continue Reading

Tags: , , ,

Dec
30

To start my reading from Petr’s excellent CCDE reading list for his upcoming LIVE and ONLINE CCDE Bootcamps, I decided to start with:
EIGRP for IP: Basic Operation and Configuration by Russ White and Alvaro Retana
I was able to grab an Amazon Kindle version for about $9, and EIGRP has always been one of my favorite protocols.
The text dives right in to none other than the composite metric of EIGRP and it brought a smile to my face as I thought about all of the misconceptions I had regarding this topic from early on in my Cisco studies. Let us review some key points regarding this metric and hopefully put some of your own misconceptions to rest.

  • While we are taught since CCNA days that the EIGRP metric consists of 5 possible components – BW, Delay, Load, Reliability, and MTU; we realize when we look at the actual formula for the metric computation, MTU is actually not part of the metric. Why have we been taught this then? Cisco indicates that MTU is used as a tie-breaker in a situation that might require it. To review the actual formula that is used to compute the metric, click here.
  • Notice from the formula that the K (constant values) impact which components of the metric are actually considered. By default K1 is set to 1 and K3 is set to 1 to ensure that Bandwidth and Delay are utilized in the calculation. If you wanted to make Bandwidth twice as significant in the calculation, you could set K1 to 2, as an example. The metric weights command is used for this manipulation. Note that it starts with a TOS parameter that should always be set to 0. Cisco never did fully implement this functionality.
  • The Bandwidth that effects the metric is taken from the bandwidth command used in interface configuration mode. Obviously, if you do not provide this value – the Cisco router will select a default based on the interface type.
  • The Delay value that effects the metric is taken from the delay command used in interface configuration mode. This value depends on the interface hardware type, e.g. it is lower for Ethernet but higher for Serial interfaces. Note how the Delay parameter allows you to influence EIGRP pathing decisions without the manipulation of the Bandwidth value. This is nice since other mechanisms could be relying heavily on the bandwidth setting, e.g. EIGRP bandwidth pacing or absolute QoS reservation values for CBWFQ.
  • The actual metric value for a prefix is derived from the SUM of the delay values in the path, and the LOWEST bandwidth value along the path. This is yet another reason to use more predictive Delay manipulations to change EIGRP path preference.

In the next post on the EIGRP metric, we will examine this at the actual command line, and discuss EIGRP load balancing options. Thanks for reading!

Tags: , , , ,

Dec
02

After working with the December 2010 London Bootcamp on Multicast for the better part of Day 4 in our 12-day bootcamp, I returned to the hotel to find the following post on my Facebook page – “Multicast is EVIL!”

Why do so many students feel this way about this particular technology? I think one of the biggest challenges is that troubleshooting Multicast definitely reminds us of just what an “art” solving network issues can become. And speaking of troubleshooting, in the Version 4 Routing and Switching exam, we may have to contend with fixing problems beyond the scope of our own “self-induced” variety. This is, of course, thanks to the initial 2 hour Troubleshooting section which may indeed include Multicast-related Trouble Tickets.

Your very best defense against any issues in the lab exam regarding this technology – the new 3-Day Multicast technology bootcamp. Also, be sure to enjoy the latest free vSeminar from Brian McGahan – Troubleshooting IP Multicast Routing.

Tags: , ,

Nov
29

In this first of a series of blog posts regarding Catalyst QoS, we will exam the AutoQoS capabilities on the 3560 Catalyst devices. AutoQoS allows for the automation of QoS settings for the switch with an absolute minimum of configuration required from the engineer. In particular, the 3560 AutoQoS features automates the classification and congestion management configurations required in VoIP environments. You should note that the 3560 AutoQoS has much “catching up” to do when you compare this feature to AutoQoS for VoIP and AutoQoS for Enterprise that are both now possible in the pure router class of Cisco devices.

First, the easy part. The interface configuration command required for QoS is simply:

auto qos voip [cisco-phone | cisco-softphone | trust]

Notice the auto qos voip command is used in conjunction with keywords that specify what devices to “trust” when it comes to these important VoIP packets. The cisco-phone keyword instructs the AutoQoS feature to only trust and act upon the incoming voice packets if they are truly sent from a Cisco IP Phone. The phone’s presence is detected thanks to CDP. Similarly, the cisco-softphone keyword instructs the device to only trust and act upon the voice packets if they are sent from a Cisco phone running in software on a PC. Finally, the trust keyword instructs the device to trust markings for VoIP packets that are coming from another switch or router over the port.

Continue Reading

Tags: ,

Nov
27

Worried about topics like EEM, OER, IP SLA, SNMP and the seemingly endless list of Network Services that might appear in your CCIE R&S (or related track) Lab or Written Exam? The latest of the 3 Day Technology Bootcamps arrives just in time for the new year.

The 3-Day Network Services bootcamp will be help Live Online on Dec 27-29, 2010. Class will run each day from 11 AM EST US to approximately 6 PM EST US. We hope to see you in the Live Event, but a Class-On-Demand version will be available the week following.

Tags: , , ,

Sep
23

October 20-22, 2010. Book your seat now! Click here!

Cannot make those dates, purchase now and receive the on-demand version the week following the live event.

Module 1 IPv6 Addressing and Basic Connectivity

  • Address Types
  • IPv6 Neighbor Discovery
  • Basic Connectivity

Module 2 IPv6 Protocols

  • IPv6 ICMP
  • DHCP for IPv6
  • IPSec in IPv6
  • QoS for IPv6

Continue Reading

Tags: , ,

Sep
18

When we ask students “what are your weakest areas” or “what are your biggest areas of concern” for the CCIE Lab Exam, we typically always here non-core topics like Multicast, Security, QoS, BGP, etc. As such, INE has responded with a series of bootcamps focused on these disciplines.

The IPv4/IPv6 Multicast 3-Day live, online bootcamp, and the associated Class On-Demand version seeks to address the often confounding subject of Multicast. Detailed coverage of Multicast topics for the following certifications is provided:

Cisco Certified Network Professional (CCNP)

Cisco Certified Design Associate (CCDA)

Cisco Certified Design Professional (CCDP)

Cisco Certified Design Expert (CCDE)

Cisco Certified Internetwork Expert Routing & Switching (CCIE R&S)

Cisco Certified Internetwork Expert Service Provider (CCIE Service Provider)

Cisco Certified Internetwork Expert Security (CCIE Security)

To purchase the live and on-demand versions of the course for just an amazing $295 – just click here. The live course runs 11 AM to 6 PM EST US on September 29,30, and October 1.

The preliminary course outline is as follows:

  • Module 1 Introduction to Multicast

Lesson 1 The Need for Multicast

Lesson 2 Multicast Traffic Characteristics and Behavior

Lesson 3 Multicast Addressing

Lesson 4 IGMP

Lesson 5 Protocol Independent Multicast

  • Module 2 IGMP

Lesson 1 IGMP Version 1

Lesson 2 IGMP Version 2

Lesson 3 IGMP Version 3

Lesson 4 CGMP

Lesson 5 IGMP Snooping

Lesson 6 IGMP Optimization

Lesson 7 IGMP Security

Lesson 8 Advanced IGMP Mechanisms


Continue Reading

Tags: , , , ,

Jul
12

We have completed a full, second practice exam for the Version 4 written. This means the CCIE R&S Written Bootcamp class comes with well over 200 practice exam questions now to assist you with this first certification step, or your recertification. Enjoy the new exam, and as always, enjoy your studies!

Tags: , ,

Jun
30

Summer was in full swing, and it was over 105 degrees Fahrenheit outside.   Bob was told it was a “dry heat”, but he thought “so is my oven”.  Needless to say, Bob was glad to be in the data center, where the temperature and humidity controls kept it very cold.   He had been asked to setup up a basic route-map with BGP, and here is the diagram he worked from.

BGP Triangle
The goal, was to modify BGP,  so that all traffic going towards the 1.1.1.0 network (which is sourced from AS1), traveling either from or through AS23, would only use the 13.0.0.0/24 segment (between R3 and R1), and not use the 10.0.0.0/24 segment (between R2 and R1) as a transit path.
Bob reviewed some of the BGP topics he had recently learned.   Here is the list he made of possibilities: Continue Reading

Tags: ,

Jun
02

This goal of this post is brief discussion of main factors controlling fast convergence in OSPF-based networks. Network convergence is a term that is sometimes used under various interpretations. Before we discuss the optimization procedures for OSPF, we define network convergence as the process of synchronizing network forwarding tables after a topology change. Network is said to be converged when none of forwarding tables are changing for “some reasonable” amount of time. This “some” amount of time could be defined as some interval, based on the expected maximum time to stabilize after a single topology change. Network convergence based on native IGP mechanisms is also known as network restoration, since it heals the lost connections. Network mechanisms for traffic protection such as ECMP, MPLS FRR or IP FRR offering different approach to failure handling are outside the scope of this article. We are further taking multicast routing fast recovery out of the scope as well, even though this process is tied to IGP re-convergence.

It is interesting to notice that IGP-based “restoration” techniques have one (more or less) important problem. During the time of re-convergence, temporary micro-loops may exist in the topology due to inconsistency of FIB (forwarding) tables of different routers. This behavior is fundamental to link-state algorithms, as routers closer to failure tend to update their forwarding database before the other routers. The only popular routing protocol that lacks this property is EIGRP, which is loop-free at any moment during re-convergence, thanks to the explicit termination of the diffusing computations. For the link state-protocols, there are some enhancements to the FIB update procedures that allow avoiding such micro-loops with link-state routing, described in the document [ORDERED-FIB].

Even though we are mainly concerned with OSPF, ISIS will be mentioned in the discussion as well. It should be noted that compared to IS-IS, OSPF provides less “knobs” for convergence optimization. The main reason is probably the fact that ISIS is being developed and supported by a separate team of developers, more geared towards the ISPs where fast convergence is a critical competitive factor. The common optimization principles, however, are the same for both protocols, and during the conversation will point out at the features that OSPF lacks while IS-IS has for tuning. Finally, we start our discussion with a formula, which is further explained in the text:

Convergence = Failure_Detection_Time + Event_Propagation_Time + SPF_Run_Time + RIB_FIB_Update_Time

The formula reflects the fact that convergence time for a link-state protocol is sum of the following components:

  • Time to detect the network failure, e.g. interface down condition.
  • Time to propagate the event, i.e. flood the LSA across the topology.
  • Time to perform SPF calculations on all routers upon reception of the new information.
  • Time to update the forwarding tables for all routers in the area.

Continue Reading

Tags: , , , , ,

Categories

CCIE Bloggers