Tuesday, August 13, 2019

Important Considerations To Get Your Zero Trust/MicroSegmentation Project Right ... A Network Artist's Perspective


Recently came across an interesting blog talking about When & How " Zero Trust " idea surfaced almost a decade ago and some really good approach author has put together when it comes to approach a Zero Trust project.

While the approach seems to be good for most part, I found few small gaps and some additional consideration those needs to well thought through in order to get it right in real world.

So here is quick summary - Feel free to add and correct. Again it's my personal perspective and nothing against the original blog author. 


1. By implementing Zero Trust, you just increased the Network Complexity in significant manner (I'll save P vs. NP analysis for later :)  ) and more importantly Operational Complexity. So Author sort of didn't touch on those important topics I guess. You don't want to end up increasing MTTR and MTTI.


2. It would require a big Cultural Change in the organization to be successful. Similar to NetDevOPS and other fancy stuff.



3. The point 2 and 3 seems to be going opposite to each other. You want every communication to be encrypted/Secure and you want to inspect every thing too. Probably no easy way to do that in real life.



4. Every encrypted communication will add into performance degradation probably. Even considering CPU and Memory are not issues any longer. You run into other fancy issues such as MTU, MSS. Having multiple hops involved for encryption/decryption for Inspection would add significant delay, Expose it to man in middle attack and breaks end to end communication flow. And never underestimate the madness things like NAT can add into this.



5. Convergence becomes a challenge. (Networking Convergence is not = Application Convergence)



6. How this model map to Overlay Networking is interesting area to get head around and think through. (Stitching those policies across Campus, WAN and DCs needs to considered too as most vendor solutions in these spaces are pretty much black boxes)



7. Is your NMS ready to Monitor such Network and Network Constructs ?



8. How do you map this model to Telco Services and SLAs will be worth taking a look



9. For application dependency mappings you need to invest into APMs. A pretty big investment usually I guess and takes good amount of time to not only deploy it but getting it right.



10. My Fav One - Are you solving the right problem to begin with. It's not only about doing right things but more importantly doing things right. :)

11. Impact on Customer Experience. Most organisations don't even want you to touch that area in case there is any impact....even if it's little.



It goes back to basic principle of Computer Science around State, Surface & Optimization. The Author seems to be more focussed on only single dimension of Surface (Though Surface itself has many micro areas to touch upon)



Maybe good time to look at OODA loop for Cyber Security ?



What would the governance model , business case to get funds will look like and how you would measure the success of such project ?


And never underestimate RFC 1925 rule 8 :)

HTH...
Deepak Arora
Evil CCIE

Wednesday, May 1, 2019

AWS Certified Solutions Architect - Associate (SAA) - Exam Review & Recommendations For Network Engineers



This exam review is written for Network Engineers in mind in order to help them with mindset required for the exam. If you are an existing Cloud Practitioner or DevOPS Engineer you probably wouldn't need my advice anyways. 😇

Study Resources I used for Preparation

- A Cloud Guru AWS Cloud Practitioner Video Course - Since this was the first time I started exploring AWS itself. I went through this quick course to get the required background and get familiar with AWS.

- A Cloud Guru AWS SAA (2018) Video Course that also includes practice exam for each section and a full length practice exam at the end. The video course is definitely good to get started and understand the AWS services in general with some nice demos on the console. Strongly recommended to lay the good foundation for exam prep.

- AWS Official SAA Certification Guide - It's not updated for current exam and is probably 2-3 years old. But still serves the purpose to prepare for some of core topics of exam. 


- AWS Live Lessons - Good Video Training Course to compliment A Cloud Guru Video Training Course. Some of topics are better covered.

- Free Practice Exam From Whizlabs - You can actually go ahead and buy paid ones as well. But I came to know about this few days before exam only. So only attempted their free exam and it was good experience. What I liked about them that they also give you explanations in case you get something wrong.

- AWS Recommended White papers and FAQs. - White papers are really important to go through cover to cover. FAQs are important but too many, I would recommend to at least go through Compute, Storage & Database FAQs.

- Practice on Live AWS Console using Free Tier Account - Just make sure you set up billing alerts to ensure you don't end up spending a lot of money from your credit card as people often forget to delete the configuration after practice sessions using free tier accounts. 

The Beginning & Initial Challenges
As I mentioned earlier, This was my first step to learn more about cloud and AWS in particular. Since I didn't have enough background on AWS Services so I started with A Cloud Guru AWS Cloud Practitioner Video Course. The course is quick and short introduction to give you high level perspective on AWS services in general. Some of the topics covered in course are unique in the sense that those are not covered later in AWS SAA Exam Blueprint. 

Later I went through A Cloud Guru AWS SAA Video Course 3 Times. Why 3 Times... I'll tell you later. :)


The SAA Video course is good to gain intermediate level skills and each topic is covered in much more depth compared to Cloud Practitioner course. At the end of each section they have got practice quiz which are good to test you skills on a given topic. I pretty much scored 90 or above during all practice sessions in first go (After 3rd reading). Also scored 94 in full length practice exam in first go. Interestingly last 3-4 sections in the video course don't have any practice exams such as Application Services, Well Architected framework etc. if I remember correctly. Also you must try to go through all Demos that instructor walks you through on Live AWS Console on your own.

While Practice on the live console is really good way to get familiar with services. In the exam in particular you didn't get any questions around Configurations itself such as Configuration snippets to be verified, Steps to configure a given service or scenario etc. Or at least that was the case in my exam.

2 Weeks before exam I also purchased AWS Live Lessons on one friend's recommendation and quickly went through it. The course gives you fresh thoughts and few new perspectives. Some of the topics IMHO are better covered compared to A Cloud Guru Video Course. 

There are couple of Challenges I faced during the exam prep as follows. So you must have a plan to get rid of those.


1. The Cloud Practitioner Mindset - This is probably the toughest challenge to overcome for Network Engineers. There are couple of ways to looks at it. Adopting the mind set is probably the one part of it. But personally IMHO the other challenge is the assumption that most of self paced Video Courses have is that they assume you are an Application Guy. The SAA exam is 95% about Application and only 5% around stuff like Networking, Load Balancing & DNS etc theory that we as Network Engineers are mostly familiar with. I remember A Cloud Guru instructor Ryan mentioning at the end of VPC section that " This is by far probably the most difficult section for you guys" and I was like " Dude it was so easy and only section I understood 100%" :)

That's the reason I have to go through the Video Course 3 times. In the first run it's too much of new information around Application stuff you would need to get familiar with. Also details like different flavors of storage, compute etc and how pricing is done for each offers you too much of information to remember. So In first run I probably only understood and can remember 50% of stuff. To overcome this challenge I started taking notes in 2nd run. But it was very time consuming as you often got to pause the video and start writing. 


2. Learn Lot more about Application - This is another great challenge. It might be easier to overcome for people with Computer Science background from university education background perspective. Initially I thought I exam must be more IaaS focussed but I was completely wrong here. The exam is not about general Compute, Storage & Virtualization discussion. But more focussed around deep level storage understand, life cycle management, Event Logging, Monitoring , Different Types of Databases and Database Scalability techniques etc. Which means as a Network Engineer you got to spend lot of time researching to get more and detailed understanding of such topics. This is where none of Self Paced video training vendor met my expectations in particular including official exam certification guide. Since they only teach you very fundamental skills while exam requires much more advanced skills. 

For example a Database Scalability problem can be solved in many different ways - Scale Compute, Spin New Instances, Use Auto Scaling, Go multi AZ, Spin New Read Only Instances, Run Traffic Distribution with DNS and LB Techniques, Move to Non Relational DB, Using DB Caching Techniques, Use Database Acceleration Techniques etc. As you can see if you get a question in exam around Database Scalability issue, you really got to think through all these option based on what kind of scenario is given with specific requirements and current landscape including keeping in mind details like if given requirements are talking about a problem with read only scalability, read write scalability or write only scalability including scenario where it's queries that are taking longer to respond. Also it could be around data coming from multiple streaming resources such as IoT kind of setup or maybe online gaming. So as you can see there is could be lot of things going in parallel in exam. Now throw things like lambda in the mix :) 

3. Outdated Exam Certification Guide - The official exam certification guide is very outdated except it still helps with some core topics like EC2, Storage, DNS. If I were to study today using book, I would rather pick the following which seems to be updated for new exam. 

4. Practice Exams - None of full scale practice exams included under Self Paced Video training courses were anywhere close to the real exam in terms of complexity. 

5. Study Group - In past for all my Cisco CCIE and CCDE exams I use to run study groups. But this time the idea didn't work out for many reasons. Different Time Zones, Different Backgrounds etc were causing issues. But personally I would still recommend to create one if possible and throw challenges and scenarios on each other.

The Exam Day

In exam you gonna get 65 questions that to be answered in 130 Mins. Personally I think that time is more than enough if you are well prepared. I finished my exam in 90 mins or so. I spent 15 mins to review some questions and change my answers for those I tagged for review earlier. This was bit different from Cisco exams where you are not allowed to go back and make change or revisit a question later.

Some of the questions will have lot of text to read though covering requirements and current landscape & expected outcomes. I used A4 sheets given to me by exam center to note down key requirements from entire text to ensure I stay focussed and don't have to read through the entire question few times. They don't however allow you to highlight it on the screen itself like Cisco CCDE lab exam. IMHO that would be cool though. 😎

The exam result be flashed momentarily at the end of exam and they don't show score right away. It took them around 24 hrs to post my score and certificate under my aws certification account online. You will likely only see a Congratulation message or a Sorry message when you end exam. Which means what is easy to figure out 😋

EC2, Storage, Database, DNS & Lambda itself covered 75% of my exam. Misc. topics such as Application Services, Cloud Trail and Cloud Watch, Beanstalk & Cloud Formation were also on exam. 


HTH...
Evil CCIE / A Network Artist

Thursday, November 23, 2017

Few Questions You Should Ask Your fav Self-Driving Networks Vendor



Since everyone is talking about Intent Based or Data Driven Networks for a while, I spent some time recently going through work done by Cisco, Juniper, Apstra, Veriflow & Forward Networks in the Area of Intent Based Networking AKA Data Driven Network AKA Self Driving Networks.

So far seems like everyone is trying to solve the different sets of problems with some overlap. Also mostly they use ML/AI in some form or shape. But my assumption is Algorithms under ML/AI umbrella are proprietary (Secret Sauce) for most part with little details available publicly.

Also the common buzzword " Automation " would mean totally different set of things in such world IMHO. So In the mean while below are quick questions you can ask to your fav. OEM vendor guys next time you go for a product/training session around same :) to get more clarity.

> What they really mean by Intent Based Networking ? (Everyone has some different definition for this)

> How do they describe the Intent to the system ?


> How do they map Business Intent & Technology intent and describe it to system ?


> Does the system translate the intent into configurations/policies on it's own or they use some sort of policy language for admin to be used to describe Business and Technical intents to system ?


> What sort of checks that system has to verify described intent and returns feedback to admin ?


> Are there any dry run capabilities into the system ?


> How they maintain the consistency for the intent throughout the life-cycle - Plan, Design, Deploy, Verify, Operate & Optimize ?


> How Intent gets documented and updated over time ?


> How do you describe intent for things like Backup path etc. ?


> How do they create visualization for Intent to present to management & Network Architects ?


> How to modify Intent over the period and what would be the touch points ?

> How their Intent Based Networking is different from policy based network (Remember Promise Theory that ACI Works on) ?


> OEMs AI/ML/DL & Algorithm Details (I doubt they would be willing though) ?


> How do they control AI and ML since they can create their own algorithms and break this closed loop over time ? (Remember what happened with Facebook's AI attempt)


> How do they track changes in such networks such as created by AI/ML dynamically ?


> How does AI/ML understand if it's actual pattern change in network during attack or just traffic pattern change driven by an special event such as heavy load on billing systems during financial year end for example ?


> Do they use graph approach (By building Network Graph such as Link State Protocol Does) or they use relation approach (Such as describing links with properties ) across network components to describe intent ?


> Which Data model they follow to describe intent and push/change configurations ? (Also understanding Data Normalization Techniques & Data Model details will be key to understand support across multiple vendors )


> Do they support APIs to describe intent and to work with other systems as part of larger eco-system ?


> How do they deal with scale ? (Everyone has different sets of limitations here)


> How do they deal with mix of legacy networks & Cloud Networks in hybrid environment ?


> How do they handle Leaky abstraction & Grey failures ?


> How do they operate across multi OEM platforms with different HW/SW capabilities ? (Which essentially means they must form a eco system with selective set of partners as it's going to be an ongoing effort)


> Does the intent description part only takes care of configuration side of things or they even go further with Network Design as part of another abstraction layer ?


Let's park Telemetry related stuff of solution for a while which is another area to dig into in order to fit all pieces together.  :) (Maybe another follow up post)

HTH...
Deepak Arora
Evil CCIE

Monday, December 5, 2016

Data Centre Fabric Design Considerations

Let's continue the SDN series.

Fabric based Data Centre architectures are becoming more and more common these days. While I mentioned in my earlier articles that some of the terminologies and other stuff that you hear under SDN umbrella are not technically new, it still gives us ability to solve some of Business and Design problems that were hard to solve in past probably for different reasons.




While some of large players like Microsoft, Facebook, Linkedin, Google and Amazon built their DC fabrics using Open Source ideas to meet their Hyper-scale Data Centre requirements, most mid and large Enterprise still seem to be little far going down that direction considering it's not an easy task to begin with. While people might be able to get things working to an extent, but in most cases the solution doesn't look very clean.

So as an alternate they have options like using someone else's brain child. For example Cisco ACI, VMware NSX, Juniper Contrail , Nokia Nuage are some of products that are designed and built to cater same set of requirements.

While there is plenty of material available on Web where people suggest different reasons to claim why one vendor solution is better than another. While I am sure some of things might be true considering someone with hands on exp. around these products might have encountered interesting issues along the way, I was recently asked by one friend to share my suggestions to figure out which solution they should pick over another while putting my love aside for a given vendor ;)

So here is my quick list, It's not very detailed but still give you some pointers to help with thought process:

- Network based overlay (ACI) vs. Host based overlay (understand pros and cons of each approach)

Would you need overlap between these two overlay models at some point , if so - would that require additional licensing, upgrades etc.

How availability domains will be supported in solution

What scale you would expect to hit down the line from control plane and data plane perspective 

What sort of Orchestration and Automation your customer require and how those needs map with particular solution capabilities

- How controller to controller communication happens, what are pre-requisites and do they allow overlay tunnels to go across different domains

- How particular OEM is going to avoid bug disasters. In theory if you are running same CODE, hitting any bug would potentially bring entire controller cluster down and defeat the purpose of running controllers in cluster or HA per say

- How open or close the API support is (Open doesn't mean completely open)

- How strong the partner ecosystem is in terms of integration and how well it ties with your Orchestrator

- How well your overlay model integrates with rest of network and what approaches they have to suggest as OEMs

- Do they allow to integrate the solution with other OEM solution down the line. For example Overlays like VxLAN don't specify the control plane. So while two OEMs may support VxLAN as possible common piece they might be taking different approaches to build control plane or might have some vendor specific twist added

- How well the solution works under multi hypervisor vendor environment

- Learning curve involved with new solution 

- Integration with current NMS deployment

- How your DCI connects and integrates between DC-DR or DC-DC (Active-Active)

- How well your fabric handles situations like customer using DR on cloud

- Support for containers (Corner case)

- How well solution is able to tie the virtual and physical workloads

- How fabric protects east west traffic (Micro-segmentation)

- How you move your virtual/physical workloads from OLD Architecture to New fabric architecture

HTH...
Deepak Arora
Evil CCIE

Thursday, September 15, 2016

Redefining SDN


For quite some time I have been sort of irritated (for lack of better word) by hearing and discussing about buzz word in the market called SDN. Let's first review some of interesting facts:

- Some people seems to be afraid of loosing there jobs thinking they will be irrelevant in near future, well lots of posts are there on web where people are throwing opinions about whats the value of CCIE now and if CCIE is relevant any longer. (Mostly these are people claiming themselves as SDN/NFV experts or evangelist)


- SDN means - STILL DON'T KNOW

- SDN is the only thing that the next generation networks would be build around or run

- SDN & NFV are future of networking

- Protocols like Open Flow will take over the world soon and re-define the networking completely 


Now let's not try to define SDN here and keep it for next post since I would wan't to clarify on some of misconceptions.

So coming back to idea of there is fundamentally something new. Well it depends upon what's your personal take on SDN to begin with in terms of :

- What it is
- How it works
- What problems does it solve
- What are the new models, frameworks and protocols that works in the background (Check under the hood)




Now if you take a closer look, most of these products are good mix of:

- Overlay Networks (Host Based, Network Based or Hybrid - e.g.:  VxLAN etc.)

- Good Orchestrator that really works well for most part (Numerous failed  
   attempts by vendors in past) 

- Network virtualization techniques (e.g. VRFs,Virtual instances etc.)

- Some better protocols/techniques to support workload mobility (e.g. LISP etc)

- Fixes applied to some traditional techniques (e.g. Poor programmability  
   support with CLI in past or missing shell access etc.)

- Some old fundamentals re-discovered (Cap theorem , Game theory, Clos  
   Fabric, BGP Labelled Unicast etc.)

- Enhancements into existing protocols considering their proven history 
   and robustness ( BGP LS, BGP EVPN, Segment Routing etc.) to meet 
   new requirements in terms of scales and get rid of some old challenges

- Better API support

- Better abstraction 

Now to me these are old ideas which are wrapped in nice package (Remember RFC 1925 Rule 11) but certainly needed to meet business demands and scale in current scenario and near future depending upon what all business problems you are trying to solve with technology.

On the other hand important question is " Should I be afraid ? "

Well there are couple of moving pieces which you need to consider:

- Most traditional network certifications, classes & courses don't cover 
   these things which really makes the situation tough

- There are very limited books and texts around these topics and some are   
   even misleading

- Lack of new networking models to define and shape these protocols and 
   other stuff well and standardize them across vendors

- Most of companies in these segments present their products like real  
   game changers

- Are you really bad at adopting change


- Well in the end of the day it's all about money...isn't it ? :)

So while it's really good to have SDN tools around to solve different problems with technology and get rid of some challenges and limitations from past, we are still far from having T-800 from Judgement Day in real life :) (While another interesting question would be if we really want to go to that stage)

 

Further Readings:

https://learningnetwork.cisco.com/blogs/vip-perspectives/2014/02/05/sdn-fight-or-flight--the-syndrome-of-new-technology-and-the-impact-on-networking-careers 

http://packetpushers.net/say-sdn/

HTH...
Deepak Arora
Evil CCIE