In this short article we’ll take a look at Cisco IOS static multicast routes (mroutes) and the way they are used for RPF information selection. Multicast routing using PIM is not based on propagation of any type of multicast routes – the process that was used say, in DVMRP. Instead, router performs RPF checks based on the contents of unicast routing table, populated by regular routing protocols. The RPF checks could be classified as either data-plane or control-plane. Data-plane RPF check applies when router receives a multicast packet, to validate if the interface and upstream neighbor sending the packet match RPF information. For data-plane multicast, the packet must be received from an active PIM neighbor on the interface that is on the shortest path to the packet source IP address, or RPF check would fail. Control-plane RPF check is performed when originating/receiving control-plane messages, such as sending PIM Join or receiving MSDP SA message. For example, PIM needs to know where to send the Join message for a particular (S,G) or (*,G) tree, and this is done based on RPF lookup for the source IP or RP address. Effectively for PIM, RPF check influences the actual multicast path selection in the “reversed way”: it carves the route that PIM Join message would take and thus affects the tree construction. In both control and data-plane RPF check cases, the process is similar, and based on looking through all available RPF sources.
We are happy to congratulate our student, Ahmet Gokhan Yalcin on obtaining his prestigious CCIE Security certification! It is my personal pleasure to congratulate Ahmet, after meeting him in our CCIE Security Bootcamp in Tampa this year. Here is what Ahmet has to say about his road to CCIE:
I passed my CCIE Security lab exam on my first attempt on 21 April. It took my 6 months to overcome this exam. I attended to CCIE Security Bootcamp prepared by INE and intsructed by Petr Lapukhov, this was really helpful in understanding the nature of the exam and getting a detailed overview. Other than that I used the practice bundle containing the Volume 2 Workbook and rack rentals, this gave me the feeling of doing an actual lab exam and experiencing the real exam difficulties. I want to thank to INE team who prepare those beneficial documents, and also I want to thank to my family for their great support during my studies.
Once again, congratulations, Ahmet!
This blog post reviews and compares two most common types of traffic contracts – single rate and dual-rate agreements and their respective implementations using single-rate and dual-rate (two-rate) policing. We are also going to briefly discuss effects of packet remarking on end-to-end throughput and finally look at some examples of IOS configuration.
What is Traffic Contract
Service-providers network topology typically follows core/aggregation model, where network core has meshed topology and aggregation layers use some variation of tree topology. This design results in bandwidth aggregation when flows converge toward the core. Therefore, to avoid network resource oversubscription, accurate admission control is necessary at the network edge. The admission operation was trivial with circuit-switched TDM-based networks, but became significantly more complicated in packet switched networks. In a packet network, there is no such thing as a constant traffic flow rate, as flows only exist “temporarily” when packets are transmitted. In packet networks, it is common for service providers to connect customer using a sub-rate connection. Sub-rate a connection that provides only a fraction of the maximum possible link bandwidth, e.g. 1Mbps on a 100Mbps connection.
Implementing sub-rate access requires special agreement between service provider and customer – a specification known as “traffic contract”. Traffic contracts are enforced both at customer and SP sides by using traffic shaping and policing respectively. Traffic contracts may vary and include multiple QoS parameters, but there are two most common types that we are going to look at today: single-rate and dual-rate traffic contracts.
The whole INE team is happy to congratulate Rock Bassole, CCIE #28657! It was my personal pleasure to meet Rock in our CCIE R&S Bootcamps, and I’m glad to see him getting the so well-deserved CCIE title! Keep up the good work, Rock!
After many months of preparation, I finally passed the CCIE lab exam on April 14th. I want to thank INE for its great material that helped me in this preparation. I used the advanced technologies class on demand and the CCIE Workbooks VOL 1, 2 and 4 to deepen and perfect my knowledge. The CCIE Bootcamp was a nice and rewarding experience. It was a rich source of opportunity that allowed me to re-enforce the most important areas of the blueprint. A long side of the long days of hard work in Tampa, I had the opportunity to tie up new relationships in a relaxed and friendly atmosphere. Many thanks to INE Instructors for their precious advices and guidance. I finally want to thank my family and friends for their constant support. A page is now turned; hope to write another one, in the future, with INE.
Congratulations, Rock, and thank you for choosing INE to help you in pursuit of your goals! Everyone else – stay tuned for upcoming in-depth technical blog posts from INE!
The CCDE bootcamp is coming shortly on May 1st, and we would like to provide some information to those of you who have already registered for the class or considering to join us. The class will go for five days and finish right before the CCDE practical exam in Chicago. The class is interactive for the most part – instructor will present you documents, diagrams, slides and questions on board and then the whole class will go through the solutions in live mode, discussing various options and correct answers. The class is centered around three major “platforms”: generic “large-scale” network topologies that are used to construct various network design cases. There are three main platforms presented in the class:
- Internet Service Provider. A fictitious ISP that provides VPN and Internet services to enterprises in addition to wholesale Internet services. Generic two-layer network, featuring a mix of interconnection technologies and using ISIS/BGP for routing. This platform is mainly used to work with scenarios relating to transit traffic services.
- Application Service Provider. A company that has its own wide-area network interconnecting data-centers and points-of-presence. The company provides server application services – e.g. a virtual call-center, online support desk etc to multiple customers. Customers connect either directly or tunneling over Internet. This platform is used to demonstrate issues arising in networks that provide centralized services to different customers. This network uses OSPF and BGP for routing, traffic flows are mainly considered to be “client-server” flows between different networks.
- Large Enterprise Network. Presents a generic enterprise network with diverse set of offices and private WAN network. The network services just one company, but has to support a large variety of application and different connection types. Traffic flows are mainly contained to one network but there are multiple “concentration” points. The network uses EIGRP for routing.
Every platform is used to construct 5 different scenarios, featuring from 15 to 20 different questions each. Answering each question requires analyzing the network baseline and additional information presented through the course of the class and selecting the optimal answer. Similar to the actual exam, the scenarios will have one the the following logical structures:
- Merge two networks or spin off a new network.
- Add a service or application – e.g. deploy L3 VPNs or add VoIP.
- Scale the network – accommodate technologies to network growth, e.g. IGP/BGP/MPLS scaling.
- Replace a technology – e.g. replace routing protocol or link type with another one.
You will be required to do a “fresh” design or fix a faulty/suboptimal scenario and propose a better solution. For example, you may be asked to fix a network that has new application deployed that is not working as required. The class will focus on live discussion of design problems as well as strategy tips for passing the CCDE practical exam. One again, students are assumed to have knowledge equivalent in scope to CCIE Written exam blueprint. And lastly, the following is link to a sample CCDE scenario – baseline and questions in the format they are going to be presented during the class.
INE is happy to announce a new class dedicated to the recently introduced Cisco Certified Design Expert (CCDE) certification. The first CCDE Practical Bootcamp is to be run on May 1-5th in Chicago, right before the actual CCDE practical exam that is scheduled on May 6th. Our goal was designing a “last-week” refresher and booster class to finalize your CCDE exam preparation. Students are assumed to have solid theoretical knowledge of the exam’s technology base prior to attending. This blog posts gives you a quick overview of the class structure and pre-requisites you should meet in order to benefit the most from this training offer.
This is a short publication to help you get started with Graded Labs Racks Rentals for CCIE Routing and Switching. We often see people having repeating issues when renting the rack time, so this is guide on how to avoid them. This document is a companion to the following class-on-demand videos: Using the GradedLabs.com Rack Scheduling System and Access the Racks. It is recommended that you both read this publication and watch these short videos to fully benefit from Graded Labs rack rentals.
A popular task in CCIE-level scenarios requires creating an access-list matching a set of prefixes using the minimum number of access-list entries. Typically, such scenarios were relatively easy, so figuring out a combination of subnet prefix and wildcard mask was more or less intuitive. However, a good question would be if there exist a generic algorithm for constructing such “minimal” access-lists. To give you a better feel of the problem, let’s start with an example. Look at the following access-list matching nine different subnets:
ip access-list standard TEST permit 22.214.171.124 permit 126.96.36.199 permit 188.8.131.52 permit 184.108.40.206 permit 220.127.116.11 permit 18.104.22.168 permit 22.214.171.124 permit 126.96.36.199 permit 188.8.131.52
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