An Engineer by Heart !!!
A Dreamer, A Pioneer, A Blogger.
A Network Engineer Trying to overtake the world with his network engineering skills :)
Opinions expressed here are solely my own and do not express the views or opinions of my Present or Past employer.
Just in case you haven't noticed yet, Evil has returned back to training industry. It's been since Jan 2010 when Scott left INE and joined Nova DataCom and later Copper RiverIT. Since then we didn't see any learning products from him. Though he was quite active on CLN. Now Scott is returning back as part of CBT Nuggets Team and he will be mainly focusing on Juniper side of entertainment. So I have now absolute no excuse to not to learn Juniper this year and Make changes into my year 2014 Plans :)
One of the common challenge with almost every routing protocol is SCALABILITY. When it comes to BGP, one of the key requirement under IBGP Specification was to implement Full Mesh. Which is OK most most of Small Enterprises but the solution doesn't scale very well as the Number of IBGP speakers increases. Particularly in Full Mesh Design you need to have n*(n-1)/2 number of peerings which is potentially an Administrative Nightmare.
So couple of solutions were implemented to overcome this issue namely: > Route-Reflectors(RR) > Confederations Technically you can have Route-Reflectors within confederations also but we will not be discussing that or confederations today. Now one of the potential Scalability issue with Route-Reflector itself is How Many Number of IBGP sessions it can support before it becomes over loaded and we need to introduce another route reflector. But also part of equation is to figure out if there are any Inbuilt Features into BGP or IOS to help with this scalability problem. Now in most design or if we follow best practices, the Router Reflector don't need to be/shouldn't be in Traffic Flow Path (Data Plane). Which means Route Reflector doesn't need to waste it's memory to download BGP routes into its RIB or Routing Table. Which further means avoiding overhead of programming RIB into Hardware and Populate FIB and Going even further if it's a distributed platform and it's using dCEF or something. So most of the time Number of BGP routes are pretty large in count under most BGP implementations, specially if it's RR and reflecting Internet Routing Table which is about half a million routes these days. So won't it be cool if we can avoid Route-Reflector to download BGP routes into RIB and just keep it in BGP RIB (BGP Table). As now we can use lots of this extra memory to build more IBGP peerings and scale out. The answer to this is something called "TABLE MAP" in BGP. Table Map is a flexible tool which offers many cool features and one among those is to help with problem we just talked about - Stopping BGP Routes from installing in RIB at Route Reflector. Here is a quick example of how to use this cool feature:
While the World of BGP is keep on changing like any other routing protocol in terms of development, one of the thing that's commonly becoming standard these days or perhaps there is lot of push towards that direction in recent times is adopting the Address Family Structure to keep things neat and clear in terms of configuration review. Also when it comes to BGP, the configuration lines grow very quickly in Large Enterprise & Data Center environments. And BGP is taking a major place into DMVPN and Large Scale Data Center Environment where Cisco is pushing it under Best Practices in terms of Routing protocol choice.
So one of feature BGP supports to help us with Address Family Structure or it's adoption without creating much pain in butt is - BGP Upgrade CLI. Here is a quick Example:
Finally it's 1st Jan, 2014. So perhaps just the right time to plan things for 2014 by setting up goals. Of course both personal and professional. So starting with the interesting part which is CCIE :) , I'll be dedicatedly working on CCIE Data Center Lab Preparation from 1st Of Feb. Yes you read it right, I got to study and finish lots of other topics in the mean while which I would say are requirement of my current project at work. I had couple of things to choose between initially like : CCDE - Which is very very interesting as far as learning Design goes. But Designing is just part of my current job as Consultant but lots of other things also have been part of equation as well like Operations, Troubleshooting, Technical Account Management, Planning, Leadership, Helping Customers & Pre-Sales teams with Decision Making, POCs, Documentation etc. But I would more likely return back to CCDE after CCIE DC. Also I would still be trying to spend at least 5 Hrs a week to study Design. CCIE DC - I had spent couple of months earlier preparing for Storage & Nexus Portion of Lab Blueprint. Also worked quite a bit on Nexus Product line last year including implementing features like VPC, VDC & OTV etc. So possibly will be attempting lab in next 6-9 months. CCIE SP-OPS - Current Project have lot to do with NGN, ASR Product Line, Unified MPLS Network For Mobile Transport , Network Automation, CGN, EVC etc. I have spent a month time already to learn and grasp this new stuff and will be spending entire Jan too. It's always good to align your job requirements with professional goals. So as I go further with current project, this is something that may push me to go for CCIE SP-OPS. Also Cisco's IOS-XR Specialist certification might be good way to start with. Also I'll try to find sometime this year to learn some new stuff for which I have developed interests recently like - SDN/Open Flow/One PK, Java Programming, Python Scripting & Basics of Junos, VCP. Now enough of professional/Career goals. Let's talk about personal goals :) Lately I have put up lots of weight in last few years. Usually I tell people that I am getting closer in look to Brian M and Scott Morris And More CCIEs means More Weight :)
But I'll find time for Gym now for sure. Also very interested to learn swimming this year. But on the flip side life is always full of surprises which pushes us further to change or tweak the plans :) Also I'll try to keep blogging and maintain the difference by talking and writing more about Network Technologies and Products by not following typical or conventional ways but rather keep focusing on making things easier & simple. And maintaining the Fun as part of learning. With that being said, Happy New Year to All of you from Evil CCIE.
