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.
Finally Cisco is Bringing ACI into CCIE Data Centre Ver 2.0 Exam. While this will simplify learning curve for ACI Fans, it's good way of indirect marketing as well from Cisco :) ... More ACI trained people should provide enough thrust to ACI market (or so called SDN in some way ) and also should help customers gain confidence from operational standpoint.
I have been getting into discussions on web and see people claiming or rather predicting how SDN is going to take over the current Network Industry . While SDN to me is not necessary a bad thing but something couldn't just be called as SDN just because it solves an old problem in a different way (Programming the network is just one of those).
Also IMHO its not necessarily to do some new things just because that's possible. For example I have been recently to a NSX session where trainer was telling about how VMware teams won't depend upon Network Engineers any longer to setup a network to grant access to new VM or Server since they usually takes weeks and now NSX solves this problem with overlay networks.
But is that really a Network Engineering Problem to begin with ? or Rather it's a Business Model / Process Design Issue ? :) ... So while SDN or NSX tries to solve this problem with overlay networks, they seem to be rather focusing on wrong areas. :) What Do You Think ? HTH... Deepak Arora Evil CCIE
Finally I found some time recently to study and move on with CCDE plan. The idea is to take CCDE written in next 6 months at max. Since I have been doing on and off study for quite a while, I decided to gear up this time and work based on attack plan I had per technology duing my CCIE R&S couple of years back since the approach did well for me. The plan is more likely to work since to me CCDE is just a getting into mindset of a Network Designer but otherwise it's just a vast collection of exam topics that carefully needs to be examined and prepared for.
So to start with I picked up one of my fav routing protocol (IGP) which is yet not very well known - Integrated IS-IS or IS-IS for IP or IS-IS in general.
There are many personal reasons that I would pick it as protocol of choice if I have to pick for an ISP Network Design over more popular OSPF. But let's not get into IS-IS vs OSPF discussion yet.
Below is the study plan I used so far and I am quite happy about with progress.
Under point '3' I chose Cisco Press IS-IS Network Design Solutions while there were some other good options too suggested by many CCIE and CCDE friends. But after carefully examining the contents through quick review I preferred Cisco Press book. But other books are no less either if you pick one of those like:
While I just started studying for CCDE I quick ran into a problem of how to approach a given technology or protocol while. While to most network engineers having significant experience - the design either looks more of a plumbing job or something they think they deal with on day to day basis. They reach to this state of mind probably considering they have seen & operate enough networks throughout their career and they know how most of technologies work and fit into those designs/requirement. We all deals with new customer requirements every now and then and try to provide solutions for those. But what people usually don't focus is there are many factors that plays a vital role into a successful Network Design. Let's discuss a quick example:- Most of the Network Engineers probably that passed CCNP Route Exam (BSCI in old days) are familiar with concept BGP Route Reflectors. The idea behind having route-reflectors in a network running BGP (ibgp) is to solve a simple problem of scalability within a Autonomous System. The golden rule of BGP says " A route learned by one iBGP neighbor cannot be advertised to another iBGP neighbor ". The rule basically was defined to work as Loop prevention mechanism within Autonomous System. Which essentially means either we follow this rule and create a full mesh of iBGP peerings or We break this golden rule by introducing things like Route Reflectors or Confederations. Even most of CCIE book texts doesn't talk about this decision further and create a mindset among Network Engineers that in a given BGP network they should rather use Route Reflectors all the time and it mimics a good BGP design. But a real Design Engineer would probably look at many other factors before making such decision like : - Business Requirements ( Though more of a Architect Guys Job ) - Do we really need a Route Reflector in a given BGP Network ? - What are the uptime and convergence requirements ? - Would introducing Route Reflectors alone solve my problems ? - What are different underlying technologies that would need to be introduced or would require fine tuning as well ? - Whats are the Pros & Cons of Introducing Route Reflectors ? - Why not BGP confederations ? - What are the best practices or considerations for a successful route reflector deployment ? - What about - " Hierarchical Route Reflector design " , " Shadow Route Reflectors " , " Optimal Route Reflection " " Diverse-Path Route Reflector" options etc ? - How to plan the migration (migration steps )? - During migration to Route Reflectors can we encounter temporarily Routing loops into the network ? - Should I have Route Reflectors per Service (IPv4 vs IPv6 vs VPNv4)/ (Intranet vs Internet) on different physical or virtual (NFV) boxes or not ? - What should be physical vs logical topology for route reflectors into the network ? - What are different options to solve "Next Hop Unchanged " problem of iBGP and what are options to solve this problem with respect to understanding pros and cons of each ? - Should we use One route reflector pair or more ? - Should we use same cluster id or different cluster id in a given pair or pairs - Hot Potato & Cold Potato Routing considerations (With and Without RR) - Do we want Load Balancing ? - What impact Route Reflector introduction may have in terms of increased network complexity...etc So as you can see there are way too many things to consider while just working on a Route Reflector Design alone :-) Also there is a misconception that Design & Architecture are same thing or terms that can be interchanged. While the short answer is "They are not " but I'll probably talk about difference between these two terms in a separate blog post in coming weeks. So while I just started my CCDE Journey ( Though at the moment I don't know how far I would go in terms of lab attempt but rather trying to be better Engineer), I break down the learning curve to have right mindset and approach for a given technology or protocol. Here is my list : - Understand Technology (Deep Dive) - Understand Use-Cases - Understand Design Guidelines & Best Practices - Understand Limitations of given technology - Compare with Similar technologies and assess pros and cons - Try to understand implementation/migration steps in Greenfield & Brownfield deployment/ Network Mergers/Replacement - Understand Scalability factors & limitations (Scale Out Vs Scale Up) - Understand HA Side - Understand Sec side - Understand Network Physical/Logical Topology Limitations - Understand Convergence Process - IPv4 vs IPv6 if applicable - Overlay Vs Underlay if applicable - QOS considerations if applicable - Enterprise vs SP vs DC Deployment considerations if applicable - Recent developments ( Drafts/RFCs/New Features in IOS/IOS-XE/ IOS-XR/NX-OS/JUNOS) - Multicast considerations if applicable - Operational challenges & considerations - Dependency on WAN design & topology if applicable - L1/L2/L3 dependencies from Transport Perspective etc - Stateful behavior vs not if applicable - Dependencies on SP/Partner for Deployment if applicable - Vendor interoperability considerations if applicable - Does it fit well in virtualized environment with single or multiple layers - Any sort of heartbeat mechanism involved and it's dependencies - Network Uptime requirements and SLAs - Is it a tunneling technique and what all it can tunnel (IP vs Non IP ? ) - Does it require hierarchical addressing & Network design in order to work better and scale ? - Impact on resources (CPU, Memoery etc...) /HW-SW requirements - Transition/Temp Solution vs Permanent/Long Term Solution - Immediate vs Long Term Benifits - Standard vs Proprietary Solution - Limitations in terms of supported interface types (P2P vs P2M vs M2M vs Logical vs Subinterfaces etc) - Overhead & MTU considerations - OAM considerations - Compatibility with Non IP Devices (ACT/PASS) - Can introduction/transition/merger can create Temp L2 or L3 loops - How it can be optimize from various points (Scalability, Covergence etc)
Well it's been a while or probably years ago I wanted to talk and write about this interesting Cisco baby called " Layer 2 Traceroute ". I called it Cisco Baby because it requires Cisco Discovery Protocol (CDP) to be enabled in order to function. Now Idea is simple, In traditional L2 Campus or Enterprise Network our Network Operations Team keep getting several requests such us tracing user port and change it's vlan to something else or maybe a troubleshooting call where we need to identify source port of user or server etc. The traditional approach usually was to first hop on to switch hosting SVI for given VLAN , Figure out Layer 2 address for given IP (User/Server IP) and do reverse engineering by tracing that Layer 2 Mac Address hop by hop until we hit the user port configured in access vlan or Server that might be using trunking in a virtualized network. Here is a quick example of traditional approach:
Now Here is how this wonderful IOS tool helps you trace quickly
It's been a while since I touched Cisco CLI during Non Office Hrs. There are lots of things keeping me busy enough these days like I have been doing a Proxy relocation to DC project which means tons of stuff to deal with as DC is a fairly complex structure with lots of moving pieces like Load Balancer ( SLB, GSLB, LLB), Firewalls and above that this particular DC runs all Juniper Devices for Routing , Switching & Security stuff. On the flip side I am thinking to seriously start working on CCDE from Mid May 2015 onwards with first lab attempt probably in Feb or May 2016. Though initially CCIE Wireless was on Radar for this and coming year but as Cisco has just announced new blueprint , the idea went on to backseat for a while now. Voice could have been interesting also but similarly CCNA and CCNP Collab tracks are going to replace existing NA and NP Voice track soon and moreover I haven't been doing much around Voice at work as well so should consider it some time next year. Now back on to idea of today's post about OSPF Address Family Structure. Well it's been a while since Network Industry was talking about one of advantage of IS-IS over OSPF which is IS-IS supports IPv6 natively. For IS-IS it was just a matter of adding new TLV (Type Length Value) to existing IS-IS packet ( TLV 232 & 236 ? I guess). Where as with OSPF it was a different story. They actually had to write a new routing protocol right from scratch now known as OSPFv3. Which introduced another problem from network design and management standpoint that if we just want to run OSPF as choice of routing protocol for both IPv4 & IPv6 on network as administrator, we got to run two separate routing protocol instances as OSPFv2 for IPv4 and OSPFv3 for IPv6. Which means two separate routing topologies. Now with OSPFv3 Address family (AF) structure support we get rid of this problem of running two separate routing instances somewhat. Why "somewhat" and not "completely" ? Well while this AF structure solves the multiple instances requirement problem, it has it's own limitations like: > Specific IOS version like 15.x required, which may or may not be supported across all existing routers & switches serving as Distribution block > The AFv4 requires IPv6 Link Local address on all IPv4 interfaces in order to function, otherwise it doesn't allow you to bind OSPFv3 AFv4 instance on interface. The Link local addresses are used as source address of packet over interfaces connecting OSPF enabled devices > The device with capability of AFv4 still couldn't talk to traditional OSPFv2 Device since there is a Address Family bit carried inside new Hello packets which traditional OSPFv2 device don't understand Which means the deployment is more likely to be successful only if it's a Green Field deployment. Here is a quick lab with quick results :)
For last couple of years I have been part of couple of Enterprise Level QOS Deployments. While some of them were tactical and others were completely strategic.
Now QOS is one of those topics in Network Industry which are considered to be highly complex and misunderstood at the same time. The part of the equation is there are lot of moving pieces that must fit together correctly in order to deploy QOS successfully in an Enterprise Environment.
At times I have seen Engineers just copy and paste QOS configurations from some other Enterprise they had access to in past and hoping that would solve the purpose. While in other cases people design QOS policies ensuring top priority for voice and video traffic in an Enterprise Network.
Now many Network Engineers while deploying QOS policies think that they should give highest priority to Voice and Video traffic in their Network. Now one of the common problem here is " Assumptions ".
As a Network Engineer you should always first observe the current state of Network Architecture, Hardware In Use, Documenting List of Critical Business Applications and Understanding their deployment along with Network requirements such as Transport (TCP vs UDP) (One to One Flow, One to Many Flow or Many to Many Flow) (Latency requirements) (Direct vs Redirected Access) (Realtime Vs Interactive) (Transport - LAN vs WAN, Wired vs Wireless) (SP Dependencies, SLA & Service Agreements) (MPLS Layer 2 vs Layer 3 VPNs) etc
The problem usually is that as Network Engineer we always try to understand and solve problems using technologies and tools. Now understanding technology and tools is definitely an important piece here but at the same time you should be able to convert a given business requirement into technical design and solution.
For example most books written around QOS would tell you to mark Voice with Highest Priority like EF and Video probably with AF41. While Voice and Video both are quite sensitive as traffic in a given network but does that also mean those are the most critical ones from Business Standpoint ?. Well if you think carefully that might not be the case in reality. For example an Enterprise client I have been recently working for was into News Paper Business. Now the Editorial Application they use to make news paper had a very tight Latency requirements end to end which was 40msec or less. While If we compare this with voice traffic latency guidelines which is 150msec or less we can certainly find the given requirements are very tight. At the same time this brings an interesting question from design standpoint which is " Shall we still give EF marking to Voice or Shall we use EF marking for Editorial Application ? ". Now if we think from business standpoint or talk to business to figure it out - The answer most likely is going to be that Editorial Application shall be given most priority. Now to make situation a little more complex they had an old Editorial application which was still in use while they were moving to new Editorial Application , so in that sense we now have two Editorial Applications with high latency sensitive requirements :). So we must take of these considerations while designing QOS policy.
Now would QOS policy alone solve the purpose now ?. Well as I mentioned the end to end latency requirements for given Editorial Applications were 40mses or less, which means you need to take a look at WAN Architecture of customer and see how this requirement can be met. Now the company had One Hub Locations in each region of India with approximately 50 remotes sites connecting to each hub site. All Hub locations were connected in partial mesh fashion.
Now the customer WAN comprises 2 MPLS L3 VPN service providers and tons of Point to Point WAN CKTs. Now at high level all looks good. At max we need to ensure that our MPLS VPN service providers are in agreement to accept our QOS markings and give our traffic proper treatment across SP core.
Now the twist here is that while most of remote locations had Cisco ISR G1 or G2 routers, the Core locations were using Cisco Metro Ethernet Switches as MPLS CE device. Now interestingly most Metro Ethernet switches don't support Layer 3 QOS for the purpose of Bandwidth based reservations under LLQ but only L2 QOS and MPLS QOS. So again from the traditional QOS deployment standpoint it could very well be a major pushback.
So as you can see the couple of technical reasons and less understanding or communication with Business makes QOS a complex and misunderstood topic.
The other problem I have seen in field is while Network Engineers try to make policies for things such as Bandwidth reservations under queuing , they don't do traffic pattern analysis properly to figure out correct bandwidth requirements. Ideally you should deploy tools such as NetFlow and let it run for couple of weeks and later analyse it to reach on conclusions for bandwidth usage vs reservation requirements.
So as you can see from this brief post on Non Technical Side of QOS, there are perhaps too many pieces involved to make a QOS deployment successful. While most people say that WAN is having highest potential in terms of SDN use, QOS is probably another key area where SDN and Automation have huge scope IMHO [ Ever tried to deploy LAN QOS with couple of 6500s, 4500s, 3750, 2950, Nexus in a single setup ? :) ]
Google Talk was one of those applications that I have been using on almost daily basis for years. Although google was keep sending notifications that they gonna stop gtalk for any further use and suggested to use Hang Out application, I think still many people out there were preferring to use old gtalk . But today they seem to kill the application finally
Anyways... Let's see how new Hangout App works. I need to install it's plugin into my chrome browser.
Also expect some interesting Technical posts in march... I know it's been a while.