Posts Tagged ‘performance routing’
Monday May 6th at 11am PDT after the current 10 Day R&S CCIE Bootcamp here in Bellevue has concluded, I’ll be holding the second part of the PfR vSeminar. This second part will cover PfR in newer IOS versions. In particular I’ll be using the same topology but with a mixture of ISR G2′s, ASR1001′s and CSR1000v’s. The ISR G2′s are running 15.3T, the ASR1001′s are running 3.9S and the CSR1000v’s are also running 3.9S. Additionally I have two of the new 3850′s in my topology. They won’t be providing anything other than L2 switching for this vSeminar but if there is enough interest I can do 1 or 2 hour short vSeminar covering them. These are really nice switches and we’re starting to replace our current switches with them.
I’ll be making another post tomorrow in regards to doing another vSeminar the same week (May 6th week) before I head to my 10 Day R&S CCIE Bootcamp and 5 Day R&S CCIE Troubleshooting Bootcamp in San Jose, CA. I’m considering doing the vSeminar on IPv4 multicast, MPLS L3 VPNs or a full scale troubleshooting lab breakdown. If anyone has any ideas or preferences for a topic let me know.
Below is the topology that I will be using for tomorrow’s PfR vSeminar. This should work on just about any rack setup as I only used one Ethernet interface on each router. Additionally all of the switches are acting as the hosts (SW1 Host A, SW2 Host B, etc).
The initial configurations are available in the rack control panel for the R&S rental racks (PfR vSeminar Initial Configs) and available below. R1 and R2 are the “external” routers and they are running BGP with each other as later in the vSeminar they will peer with R4 and R5 via eBGP. R4 and R5 have static default routes and are originating a default into OSPF with R5′s default having a lower cost making R5 the primary egress router to reach the external networks. Also at the bottom is basic ping script you can use to test your initial configurations.
I will start off with an introduction to PfR. Then I will cover the basics of PfR. Next I will cover advanced PfR configuration along with troubleshooting. The session will start off using 12.4(15)T to cover the basics and around the second break I will switch the IOS to 15.1T and lastly switch over to IOS XE 3.9 using the CSR1000v. I will cover how PfR is used in production and how PfR can be used in your network today.
A standard topology will be followed throughout the session and all of the scenario configurations, diagrams, etc will be available after the session for you to either do on your own rack or our rental racks. I’ll publish the topology on Friday in the event you want to follow along with the live session. I’ve structured this session differently in that when the recordings are released you’ll be able to follow along with the videos which I think is key to learning a technology like this.
The previous session that I did covering PfR will be replaced with this session. The new session will be available for download on the 25th of April. This PfR session will be better than my previous PfR session but the jokes maybe the same.
Lastly this vSeminar is a great chance for everyone to see the style of bootcamps we run here at INE if you are looking for a training solution.
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.