Posts from ‘CCIE R&S Written’
Edit: The INE party will be at the Hard Rock *Hotel*, not the Hard Rock *Cafe*.
I would like to thank the over 600 people who RSVP’d for INE’s 2013 Party at the Hard Rock Hotel in Orlando during Cisco Live. Registration is closed as of today for our party but I wanted to be the first to let everyone know about the grand prize giveaway we are doing. On top of the standard giveaway prizes (iPads, MacBook Airs, AAP Memberships, Bootcamps, etc) we are giving away a Harley Davidson 2013 XL 1200X Forty-Eight to a lucky winner during our party.
On top of the Harley Davidson 2013 XL 1200X Forty-Eight we’re having a second grand prize giveaway. Details on the second grand prize giveaway will be revealed after the drawing for the winner of the Harley Davidson at the party.
As a side note I don’t personally ride anymore but that bike really does look cool when it’s all blacked out.
The top contributors in May for the following forums will receive their choice of either an iPad or Samsung Galaxy Note 10.1 tablet. The top overall contributor for IEOC for May will receive their choice of an Apple Macbook Air (13″ 256GB) or Google Pixel with 4G LTE.
Additionally the best CCIE success story (most details, inspirational, etc) post on IEOC in May will also receive their choice of either an iPad or Samsung Galaxy Note 10.1 tablet.
As many of you already know I’ve been teaching our brand new Routing and Switching CCIE bootcamps for the past couple months. I’ve recently restructured the bootcamp in that mock labs are not done during the second week to allow for expanded coverage of the CCIE blueprint topics. The mock labs are now done after the bootcamp and I give every student 1500 tokens to schedule them. The new structure allows for roughly 100+ hours of hands-on demonstration using my own rack over the course of the two weeks. I start at 9am and go until roughly 8pm each night (Friday’s included). After 8pm the students usually go for dinner and start working on the labs and/or review for the next day. Every topic is covered hands-on by me during the two weeks. Students are given the R&S CCIE ATC Videos free of charge when scheduling the bootcamp because even with 100+ hours we do not have time to cover the basics.
As far as my teaching style goes Continue Reading
A new update to INE’s CCIE Routing & Switching Written Exam Bootcamp is now available in streaming format for All Access Pass subscribers, and available for purchase as a download. This completely new video series, taught by me – Brian McGahan, 3 x CCIE #8593 (Routing & Switching, Security, Service Provider) – is specifically designed for students looking to focus on the topics and technologies covered in the CCIE Routing and Switching Written Exam version 4 blueprint.
As a precursor to our CCIE Routing & Switching Advanced Technologies Class and our CCIE Routing & Switching Lab Workbook Volume 1, the Written Exam Bootcamp helps to create a solid foundation of the concepts covered in the CCIE Routing & Switching version 4 Written Exam, as well to give students the knowledge they need to continue straight into their hands-on CCIE Lab Exam preparation. This bootcamp will also benefit current CCIEs who need to re-affirm their knowledge from a theoretical standpoint in order to recertify on the various technologies covered on the CCIE Routing & Switching Written Exam blueprint.
This blog post is the first in a series covering Performance Routing (PfR) formerly known as Optimized Edge Routing (OER) that I will be publishing over the coming weeks. I decided to cover PfR in a series of blog posts contrary to a single post as PfR is a very powerful and useful feature that leverages the power of Cisco’s IOS but at the same time PfR is potentially very complicated and often confusing feature to configure and troubleshoot. Trying to cover PfR in a single blog post would be the equivalent of trying to cover OSPF in a single blog post. In fact if you compare the IOS 12.4T OSPF Configuration Guide against the Optimized Edge Routing (OER) Configuration Guide you will notice that OER documentation is nearly 35% larger.
In this blog post the term PfR will be used in place of OER wherever possible as Cisco has started to depricate the OER terminology and commands as of IOS 15.0.
The primary focus of these blog posts will be how PfR relates to the Routing and Switching CCIE Lab Exam (PfR v2.2). The first couple posts will cover basic scenarios (static routing and BGP) with PfR, while introducing the reader to the PfR specific terminology and features as we use then and/or run across them. After we cover the basic scenarios I will get into more complicated scenarios using PfR to optimize routing based upon DSCP values, inbound routing optimization using BGP, routing based upon application response time and voice call quality. A final post will cover PfR in IOS 15.1 (PfR v3.0) and will focus on some of the newer PfR features. I will try to keep the details and complexities of PfR out of the first couple blog posts so that the reader can gain a solid grasp of PfR before moving forward. I spend roughly half a day in my new Routing and Switching CCIE 10 Day Bootcamp covering PfR as it’s important for the R&S CCIE candidate has a solid understanding before attempting the CCIE Lab exam. Additionally, I personally believe that in the future the concept of centralized route control and/or route manipulation as with PfR could become more common, similar to the concept of OpenFlow. With that being said lets get started.
Performance Routing (PfR), previously called Optimized Edge Routing (OER), introduces a new concept into IP routing. With traditional routing, path selection decisions do not consider a particular path’s traffic characteristics be it throughput, actual delay, packet loss, voice mean opinion score (MOS), monetary cost of a given path, or jitter. PfR enhances the classic destination-based routing concept centered on the shortest path (lowest-cost metric) by adding into the routing selection process, network performance and/or application performance aware intelligence. In the past when routing protocols were implemented in large-scale networks, routers did not have the resources to calculate the best path based upon anything other than a simple metric. Additionally, many of these networks would be considered simplistic in regard to the number of primary and redundant links compared to today’s networks. With the increase in CPU power and memory available in routers today, routing based solely upon a simple metric (hop count, cost, as-path length, etc.) is not the best use of these available resources. PfR will leverage these available resources to allow routing decisions based upon additional factors namely the networks performance and/or application performance across the network. Getting the most out of your network’s available bandwidth and/or the best possible performance for your applications across the network should be one of the primary goals of any network implementation. Let’s look at an example of how we can do this using PfR.
I recently received an email from a student with a question about an example I did in our multicast bootcamp. After an hour into testing and drafting my email response, I realized this commonly misunderstood multicast design would make a great blog writeup! The original question is as follows:
I am a customer of INE and bought the multicast bootcamp. Maybe I missed some important note, but I am confused related to the issue mentioned below. I am following the test bed you have shown in the presentation while describing the theory of sparse mode (Day 1 – Part 6) in which you have explained the RP Register, Join and SPT-Join.
Suppose the two trees are established, and traffic is flowing from the source to RP, and then RP to receiver. Also suppose that SPT-Join is disabled (e.g. threshold is infinity), and traffic always follows the shared trees.
Suppose that the multicast traffic flow is initiated from the source to the RP as follows:
R2 –> R4 –> R3 (RP)
Then traffic flows from the RP to receiver:
R3 –> R4 –>R5
When multicast traffic is coming from the RP on R4, will RPF check fail? I assume so, since multicast traffic is entering the interface in which RPF will be failed. Is there any other rule to follow if traffic is coming from RP?
Many times, students believe that they could use a bit of a boost when it comes to solving the very complex and difficult Practice Lab Exams featured in our famous Volume II workbook here at INE. To respond to this, Keith Barker and I came up with an idea for a new INE product unlike anything that had been created before.
We created a fully interactive video guide to lab exam strategy and actual solutions for the first five labs of the workbook. But we did not stop there. We also recorded bonus lessons on topic areas that students always seem to want extra guidance with. Such areas as:
- Am I fast enough when it comes to making configurations?
- What is the best way to master DOC-CD navigation?
- What are appropriate strategies for Troubleshooting?
- What should I do if I am struggling with Redistribution tasks?
Here are some sample lessons from the Interactive Video Companion for Volume II so you can see this remarkable product for yourself. I am also publishing the complete outline here so you can examine that as well.
The Course Outline:
Lab 1 – Dos and Donts – 20 minutes
Lab 1 – Lab Strategy – 30 minutes
Lab 1 – Backup Link – 20 minutes
Lab 1 – Spanning Tree Manipulation – 10 minutes
Lab 1 – Spanning Tree Security – 15 minutes
Lab 1 – Private VLANs – 30 minutes
Lab 1 – Layer 2 Traffic Engineering – 20 minutes
Lab 1 – OSPF Prefix Adv – 10 minutes
One of the most important technical protocols on the planet is Open Shortest Path First (OSPF). This highly tunable and very scalable Interior Gateway Protocol (IGP) was designed as the replacement technology for the very problematic Routing Information Protocol (RIP). As such, it has become the IGP chosen by many corporate enterprises.
OSPF’s design, operation, implementation and maintenance can be extremely complex. The 3-Day INE bootcamp dedicated to this protocol will be the most in-depth coverage in the history of INE videos.
This course will be developed by Brian McGahan, and Petr Lapukhov. It will be delivered online in a Self-Paced format. The course will be available for purchase soon for $295.
Here is a preliminary outline:
Day 1 OSPF Operations
● Dijkstra Algorithm
● Neighbors and Adjacencies
○ OSPF Packet Formats
○ OSPF Authentication
○ Link-State information Flooding
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.
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.
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!