Posts from ‘CCDP’
Just ahead of our brand new CCNA Voice live online bootcamp beginning this Monday, I thought it might be nice to provide an easy-to-follow graphic for those starting out in Voice (or on any other Cisco networking track). This graphic was from last year, but remains quite easy to follow for each and every Cisco track.
Be sure you have a high resolution set if you wish to see the entire thing, otherwise scrolling may be necessary.
Cisco had promised us Christmas 2010 editions of these new exams. Those dates have slipped again.
The new Cisco CCDA 640-864 DESGN and CCDP 642-874 ARCH exams are now scheduled to hit by January 31, 2011.
Both exams promise to test new material regarding virtualization and data centers. Stay tuned to see if these new exams do actually materialize. For those tracking such things – this is the third new date for these exams.
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!
In our CCDP bootcamp, we examined Cisco’s implementation of Virtual Private LAN Services (VPLS) in some detail. One blog that I promised our students was more information about how large enterprises or Internet Service Providers can enhance the scalbility of this solution.
First, let us review the issues that influence its scalability. We covered these in the course, but they are certainly worth repeating here.
Remember that VPLS looks just like an Ethernet switch to the customers. As such, this solution can suffer from the same issues that could hinder a Layer 2 core infrastructure. These are:
- Control-plane scalability – classic VPLS calls for a full-mesh of pseudo-wires connecting the edge sites. This certainly does not scale as the number of edge sites grow – from both operational and control-plane viewpoints.
- Network stability as the network grows – Spanning Tree Protocol-based (STP) infrastructures tend not to scale as well as Multiprotocol Label Switching (MPLS) solutions.
- Ability to recover from outages – as the VPLS network grows, it could become much more susceptible to major issues for customer connectivity in the result of a failure.
- Multicast and broadcast radiation to all sites – remembering that the VPLS network acts as a Layer 2 switch reminds us that multicast and broadcast traffic can be flooded to all customers across the network.
- Multicast scalability – multicast traffic has to be replicated on ingress PE devices, which significantly reduces forwarding efficiency.
- IGP peering scalability issues – all routers attached to the cloud tend to be in the same broadcast domain and thus IGP peer, which results in full-mesh of adjacencies and excessive flooding when using link-state routing protocols.
- STP loops – it is certainly possible that a customer creating an STP loop could impact other customers of the ISP. STP may be blocked across the MPLS cloud, but it is normally used for multi-homed deployments to prevent forwarding loops.
- Load-balancing – the use of MPLS encapsulation hides the VPLS encapsulated flows from the core network and thus prevents the effective use of ECMP flow-based load-balancing.
BGP (see ) is the de-facto protocol used for Inter-AS connectivity nowadays. Even though it is commonly accepted that BGP protocol design is far from being ideal and there have been attempts to develop a better replacement for BGP, none of them has been successful. To further add to BGP’s widespread adoption, MP-BGP extension allows BGP transporting almost any kind of control-plane information, e.g. to providing auto-discovery functions or control-plane interworking for MPLS/BGP VPNs. However, despite BGP’s success, the problems with the protocol design did not disappear. One of them is slow convergence, which is a serious limiting factor for many modern applications. In this publication, we are going to discuss some techniques that could be used to improve BGP convergence for Intra-AS deployments.
BGP-Only Convergence Process
Tuning BGP Transport
BGP Fast Peering Session Deactivation
BGP and IGP Interaction
BGP PIC and Multiple-Path Propagation
Practical Scenario: BGP PIC + BGP NHT
Considerations for Implementing BGP PIC
Appendix: Practical Scenario Baseline Configuration
Cisco originally promised us a new CCDP exam (version 2.1) on Nov 8, 2010.
That date is now moved to December 23, 2010. Our Class On Demand was designed to cover you for the old blueprint and the new, so there should be no concern for students. Of course we will be taking the new exam the week following its release and we will be sure to provide any updates to the course that may be required free of charge.
In the meantime, watch blog.ine.com for many posts regarding valuable extra technical information regarding this popular new course. I also want to send out one more thank you to the many students we had that were active participants in the live event. It was an honor to have so many Cisco employees join us, as well as the many highly motivated students from around the world.
Here is the recommended reading list that several asked for from our CCDP Bootcamp. Thanks again to all that attended for the awesome participation and discussions.
The INE CCDP Bootcamp covers in depth information about the Nexus line from Cisco Systems. Here is some of the overview information from the course for those that desire a quick introduction to this line of equipment.
With the Nexus gear, Cisco introduces us to yet another operating system called NX-OS. The platforms that run this Operating System include:
- Nexus 7000
- Nexus 5000
- Nexus 2000
- Nexus 1000V
- Cisco MDS 9000
- Cisco Unified Computing System (UCS)
- Nexus 4000
What are the key features of this new Operating System? Capabilities include:
- Virtual Device Contexts (VDC) – devices can be segmented into virtual devices
- Virtual Port Channels (vPC) – switches or servers able to use EtherChannel across two upstream switches
- Continuos system operation – thanks to features like In-Service Software Upgrade (ISSU) and dynamic restart for processes
- Security – 802.1AE
- From Base Service licenses to Advanced Services and Transport Services