Posts from ‘CCIE R&S’
OSPF on the move? Include a Forwarding Address
I enjoyed Petr’s article regarding explicit next hop. It reminded me of a scenario where a redistributed route, going into OSPF conditionally worked, depending on which reachable next hop was used.
Here is the topology for the scenario:
Here is the relevant (and working 
) information for R1. Continue Reading
Tags: ccie, ospf, ospf fa, troubleshooting, vol2
Abstract
This publication briefly covers the use of 3rd party next-hops in OSPF, RIP, EIGRP and BGP routing protocols. Common concepts are introduced and protocol-specific implementations are discussed. Basic understanding of the routing protocol function is required before reading this blog post.
Overview
Third-party next-hop concept appears only to distance vector protocol, or in the parts of the link-state protocols that exhibit distance-vector behavior. The idea is that a distance-vector update carries explicit next-hop value, which is used by receiving side, as opposed to the “implicit” next-hop calculated as the sending router’s address – the source address in the IP header carrying the routing update. Such “explicit” next-hop is called “third-party” next-hop IP address, allowing for pointing to a different next-hop, other than advertising router. Intitively, this is only possible if the advertising and receiving router are on a shared segment, but the “shared segment” concept could be generalized and abstracted. Every popular distance-vector protocols support third party next-hop – RIPv2, EIGRP, OSPF and BGP all carry explicit next-hop value. Look at the figure below – it illustrates the situation where two different distance-vector protocols are running on the shared segment, but none of them runs on all routers attached to the segment. The protocols “overlap” at a “pivotal” router and redistribution is used to provide inter-protocol route exchange.
Tags: bgp, CCDE, ccie, eigrp, ospf, rip, third-party next-hop
Are you a CCNP or CCIE student looking to challenge your perfect knowledge of Catalyst switchport commands?
Take the latest SWITCH Command Recall exam by clicking the link below. Good luck – and let us know how you scored in the comments area of this post.
Remember to read, AND TYPE, very carefully! I failed my first attempt due to just plain sloppiness. 
One of the frequent questions I hear regarding L3VPNs, is regarding the bottom VPN label. In this article, we will focus on the control plane that provides both the VPN and transit labels, and then look at the data plane that results because of those labels.
In the topology, there are 2 customer sites (bottom right, and bottom left). The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane. Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.
A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.
In this blog post we’re going to discuss the fundamental logic of how MPLS tunnels allow applications such as L2VPN & L3VPN to work, and how MPLS tunnels enable Service Providers to run what is known as the “BGP Free Core”. In a nutshell, MPLS tunnels allow traffic to transit over devices that have no knowledge of the traffic’s final destination, similar to how GRE tunnels and site-to-site IPsec VPN tunnels work. To accomplish this, MPLS tunnels use a combination of IGP learned information, BGP learned information, and MPLS labels.
We wanted to provide our students with advance notification of some upcoming online classes here at INE. While we hope to see many students in the actual live events, on-demand versions will indeed be made available the week following the live, online version.
Join the INE Experts Online in September and October
September 13 – 17th, 2010 CCNA Wireless 5-Day Bootcamp
September 15 – 17th, 2010 Security for CCIE R&S Candidates 3-Day Bootcamp
September 29 – Oct 1, 2010 IPv4/IPv6 Multicast 3-Day Bootcamp
October 4 – 9th, 2010 Online 6-Day CCIE R&S Bootcamp with K. Barker and A. Sequeira
Our BGP class is coming up! This class is for learners who are pursuing the CCIP track, or simply want to really master BGP. I have been working through the slides, examples and demos that we’ll use in class, and it is going to be excellent. If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event. More information, can be found by clicking here.
One of the common questions that comes up is “Why does the router choose THAT route?
We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.
So now for the question. Take a look at the partial output of the show command below: Continue Reading
Abstract
In this blog post we are going to review a number of MPLS scaling techniques. Theoretically, the main factors that limit MPLS network growth are:
- IGP Scaling. Route Summarization, which is the core procedure for scaling of all commonly used IGPs does not work well with MPLS LSPs. We’ll discuss the reasons for this and see what solutions are available to deploy MPLS in presence of IGP route summarization.
- Forwarding State growth. Deploying MPLE TE may be challenging in large network as number of tunnels grow like O(N^2) where N is the number of TE endpoints (typically the number of PE routers). While most of the networks are not even near the breaking point, we are still going to review techniques that allow MPLS-TE to scale to very large networks (10th of thousands routers).
- Management Overhead. MPLS requires additional control plane components and therefore is more difficult to manage compared to classic IP networks. This becomes more complicated with the network growth.
The blog post summarizes some recently developed approaches that address the first two of the above mentioned issues. Before we begin, I would like to thank Daniel Ginsburg for introducing me to this topic back in 2007.
Tags: CCDE, ccie, hierarchical bgp, hierarchical lsp, MPLS, mpls-te, rsvp-te
Last week we wrapped up the MPLS bootcamp, and it was a blast! A big shout out to all the students who attended, as well as to many of the INE staff who stopped by (you know who you are ). Thank you all.
Here is the topology we used for the class, as we built the network, step by step.
The class was organized and delivered in 30 specific lessons. Here is the “overview” slide from class: Continue Reading
Time is a valuable resource in the lab. In a lab task, if asked to configure a policy-map named “BOB”, it doesn’t get the same point value if we happen to accidentally name it “bob”, especially if they are looking to see if you configured what they asked for.
The challenge is, that when reviewing a lab task, and we discover that we need to change a name, it could be a hassle, as we need to remove the policy-map, recreate the policy map, and then put it in place again.
So if you are down to the last minute, here is a time saving solution, that can assist with that process.
IOS allows us to rename a policy-map, and the IOS will swap out the name in other areas of the configuration that reference that policy map. Continue Reading
Loading ...
