Saturday, March 27, 2021

Are Networks Really Complex ?

A recent short article from an IBN Evangelist brought up an interesting point about how complex modern networks really are and how IBN (Intent Based Networking), assuming SDN is dead, would potentially transform your network and equip you with enough insight by virtue of using AI & ML in such a way that overall network will be much more predictive in nature & AI/ML magic will take care of all complexity.

Wow...by now if You are not sold to this such a great marketing sales pitch....I'll be disappointed 😈

But as an Individual Network Consultant & as a Network Architecture practitioner, I often help my Clients to look deeper under the hood and uncover insights which helps them transform their networks in such a way that's much more realistic and much more practical in nature.

So let's start uncovering some details around " What makes our Networks really Complex? " to understand the problem space at its core and not just at its surface and bring this idea to " How to go about this idea and bring it to reality".

Business Layer

+++++++++++

Often business people based on tons of marketing from vendor believe that the technology is and was the way to transform their businesses. And don't get me wrong but that's true for most part at it's surface. But on the flip side what they don't get it is that the Technology is part of solution and not heart of solution. At it's core you still got to get it right from People & Process perspective. That's one of the reason why over 80% of Digital Transformation projects which are technology centric often gets failed and they get failed miserably from ROI perspective.

To simplify this I often quote this to my friends and colleagues " In theory your Smart phone has more computing power than Apollo 11 which took men to moon, but doesn't that mean you know completely how to harness this power still today to it's potential"

So why most technology driven Digital Transformation Projects really fail today ?

1. Short Term Thinking

2. The Technology Fallacy - At its core in any business its the People make the difference not tech

3. Absence of Collaboration Culture - Start building trust at its core

4. Imposed Fake " Innovation " Culture - It's a big one in big Orgs.

5. Vendor driven Tech & Innovation - Vendor religions are still ruling the world

6. Most Valuable yet underrated skills:

A. Common Sense

B. Listening

C. Hard Work

D. Framing the Problem correctly and map it to its roots

E. Hypothesis Testing of your ideas, thoughts and frameworks

7. Fake Data Analytics - People using biased data & statistical models to prove their point and sound intelligent

8. The Generation Gap - This is actually a very big one

9. Absence of a comprehensive & mature "OEM/Partner/Solution benchmarking & onboarding process"

10. Moving away from Vendor A to Vendor B to save cost - If it's just CAPEX, just don't do that

11. OPs & Engineering are usually not invited in Business reviews as they seem irrelevant to many business folks still today

12. Most cross skill programs are fake and misleading

13. Too much of belief in - Cloud, SDN, IBN, Automation and the saga continues...

14. Believing that it's eventually the APP that matters and not the underlying tech...remember it's still Information Technology (IT) and not App Technology (AppT)

15. The urgent culture - Remember that most urgent things are unimportant

16. Let's not focus too much on those MBAs and CAs running companies at this point 😇

Technology

++++++++

1. The fake Application Aware Networking notion - It doesn't exist...Period !

2. Most Networking Managers & CTOs are still not investing into Core Network Architecture & Design skills and keep believing in OEM's Voodoo magic

3. Lack of Test bed environment - Over 90% of organizations still don't own dedicated Test bed environment that can validate those fresh configuration & configuration changes by replicating your production network at scale

4. The fake Architectural Skills - Just because someone owns an Expert Level networking certification or tons of experience on resume doesn't mean they own strong architectural & design skills

5. The old school & immature Interview Process

6. Common misunderstanding that if someone is working on new cool shiny tech, they are innovative

7. Tech people still believing understanding "How business really works" is boring & unimportant since that's why they chose to become Engineer

8. Vendor & Technology/Solution religions

9. All you need to pick on a new vendor and it's solution is that 3-5 days of training - Really ?

10. Tech folks still thinking in SLAs which BTW is a business metric and not a technology metric to begin with while still keep ignoring SLOs and SLIs

11. Tech Folks not being able to articulate changes they would need around People & Processes when introducing new shiny Tech, So how you handle change management in your SDN solution world and most importantly how different it is compare the what it was before introducing SDN ?

12. Outdated and non-standardized network documentation

13. The One Book Mentality - Not sure how many times and how often I came across his mentality. Usually the moment you ask a regular network engineer for example "How should we go about implementing IPv6 in our network ? ", the common set of responses you will hear back would be:

A. Let me read a good book on this and come back

B. Tell me what you want me to implement

C. Let me find the IPv6 deployment best practices document

But often they miss the point of first get a full understanding of following to fully understand the problem statement:

A. Why we are doing it in first place ?

B. What problem we are trying to solve ?

C. What changes we would need to make across Tech, People & Processes ?

D. What are my alternatives to meet same goal ?

E. How we would measure our success and more importantly our Business will measure it for us ?

14. Most Networking tech folks are still madly in love with Vendor stories & narratives when it comes to learning

15. Learning a product doesn't make You an Engineer, understanding how tech works behind the scene does

16. No tight & close feedback loop between Design & OPs team

Standard Bodies Failures
++++++++++++++++++

Like every other Industry, we got IEEE, IETF, MEF & ONUG and bunch of other standard governance bodies in Networking. But how robust their process are at their core ?

1. In most standardization documents, its not mandatory for You as author to talk through entire life cycle bits of your proposed protocol or solution. Always remember that building something new is perhaps always the easier part compare to operating it for next 5 years or so on daily basis. Under the hood the problem is very similar to " Why most hackathons are useless " for most part despite being chosen as one of popular tools to drive innovation.

2. Most RFCs are just boring lengthy texts...Not saying all of them since I am in love with RFC 1925 and RFCs do add lot more details in the equation, but why can't those be written in more interactive manner in a modern world where people predict that visual and AR/VR based learning is going to be the future despite we ignore based on evidences that people retain visual memories for longer. Perhaps they put on a dedicated track around this lead by Dan Roam at some point understanding its importance.

3. Networking & even Expert Level certifications only focus on Tech aspect and are still far from reality you have to face in real world...ping me to discuss those numerous examples 😇

4. Security aspects of any new protocol or solution is still an after thought in most cases

5. Lack of metrics defined to measure the quality of any protocol, solution & tech

Let's keep Complexity Theory & " Complex vs. Complicated " for some other time 👽

So what do you think now about " Are Networks really Complex ? "

Further Readings:

The Hard Thing About Hard Things

Navigating Network Complexity: Next-generation Routing with SDN, Service Virtualization, and Service Chaining

Your Strategy Needs a Strategy: How to Choose and Execute the Right Approach

Cloud Repatriation: Why Are Workloads Coming Back Out Of The Cloud?

High-Level Technology Guidelines

HTH...

A Network Artist

Sunday, December 20, 2020

BGP Nuts - The Crazy Metric Story

Recently ran into an interesting BGP behavior. In order to convey the issue, I have oversimplified the design.

R2 (AS 100) has a network host 22.22.22.22/32 which is trying to reach R7 (AS 200) attached network host 77.77.77.77/32.

As you can see, between AS 100 & AS 200 we have multiple exit points for the purpose of redundancy. However the interesting twist here is that those BGP next hops are learned from different IGPs.

54.0.0.5 <- Learned from EIGRP

63.0.0.6 <- Learned from OSPF

Given the scenario, what you think about which BGP route and next hop would make into the routing table ?

Well...most likely the answer would be BGP next hop learned from EIGRP because (Assuming... 1. " no auto-summary " is now default for EIGRP (resulting into same Prefix Length for route) , 2. EIGRP AD is 90 compare to OSPF Intra Area route which has AD 110. So based on theory how Router Process this information, the EIGRP learned Next hop (54.0.0.5) should be the one picked up by BGP Best Path Selection Algorithm and should be picked up as the best route over OSPF learned Next Hop (63.0.0.6)

All good ? ... Let's look at the BGP RIB to find it out and How IGP next hops are processed based on standard BGP Next Hop Processing approach that we know from standard BGP theory. Also let's run a quick traceroute towards 77.77.77.77 sourcing from 22.22.22.22 on R2

Now sure if you expected that...right ? :)

From BGP RIB standpoint we can clearly see that BGP route that's making into routing table & FIB essentially is the one that has OSPF learned BGP next hop.

Here is what our OSPF database looks like

Let's do a basic failover test by shutting down interface g6/0 on R3

So things works fine and as expected here, so let's "un-shut" the interface in order to dig deeper into the behavior ( a little unexpected one)

So why this behavior ?...Well this is where BGP plays a little dumb. It actually ends up comparing METRICs across two IGPs since it doesn't have view of EIGRP Topology Table and OSPF Link State Database. Now if you go back and check IGP metrics for next hops learned from EIGRP vs. OSPF, The metric for EIGRP route is pretty high (in numeric ) as 3072 vs. OSPF route as 2 (Refer to first CLI screenshot in the post)

Now what if we make the OSPF metric look bigger than EIGRP by manually increasing OSPF cost to see if that would allow R2 to install EIGRP learned route as best route

And Yes it works as expected this time too :)

Now for fun let's make the metrics look same by again changing the OSPF cost manually

Well that works too as expected. Now interesting question here is - Since IGP metrics learned from OSPF and EIGRP look same, can we turn ON " i-BGP Multipath " and achieve load balancing.

Let's try that

Well that works well too and as expected.

One of the problem incase you haven't noticed yet with this design is - Assume the path through OSPF has many more hops added before you reach to the OSPF learned BGP ASN exit point. Since OSPF cost metrics are much lower value compare to EIGRP, You will end up taking sub-optimal path from R2's standpoint in this case which may not be desired behavior. Alternatively You can replace EIGRP with IS-IS and you will by default still end up following OSPF learned BGP next since in most IOS version 10 is the default IS-IS metric for each interface hop. Obviously in practice you should try to run Single IGP across AS 100 here to avoid such issues though M&A scearios are always interesting and challenging. :)

Try this with " DMZ Link-BW " for Unequal Cost Multi-Path and I am pretty sure it will be fun. BGP AIGP NLRI is another interesting bit if you care depending upon the design.

And of course, the above mentioned logic doesn't apply to following design where we have single exit point being reachable through both IGPs

To learn some more around BGP anomalies and somewhat un-predictable behavior:

BGP Wedgies

BGP Anomalies

And if You want to master BGP from Design Standpoint, I would highly recommend " BGP Zero to Hero Design Masterclass " from my friend Orhan Ergun

HTH...

A Network Artist

Thursday, May 28, 2020

The Mythical "Networking Expert" Unicorn - Part 1

" Expertise is a Myth " - Yes you read that right !!!

Recently there were couple of different posts/threads going on over Linkedin where people were asking a very common question that most people in Networking/Technology industry struggle to answer and in most cases it only causes the them anxiety - " Since there are just too many new Technologies & Solutions those have surfaced in last couple of years, how do I stay relevant moving forward and what should I focus on? "

While the easiest answer you always hear from people would be " It depends" and they are probably right (Let's keep it for another post as it's not really as hard as a problem if you apply some science to it, "Yes there are proven methods" and you don't necessarily need to completely depend upon "what your gut tells you" which is what I guess 99% in real world would people rely upon, if you ever doubt that - Please be my guest to show me how you plan your career decisions in terms of a structured approach you follow to make those decisions).

Perhaps the 5 Ws is a good place to start.

Now on the same linkedin thread, many people suggested to follow T-Shaped skill set which essentially says - Be an Expert in few selective areas while continue to me a generalist in rest of areas.

Sounds plain, simple & logical - isn't it ?

But that leads us to another interesting question which is "How do I know if I am an Expert in a certain area?" - Since in general no one tells us how to gauge our expertise or perhaps the real question is "Does Expertise exists for real ?"

Here is what Wikipedia says - "An expert is somebody who has a broad and deep competence in terms of knowledge, skill and experience through practice and education in a particular field."

Now as you can see, while those are some good statements and sensible ones too, they still don't tells us ways to measure expertise correctly. So still what we are struggling with is quantification of our Expertise persona.

Now obviously it just can't be unsolvable problem. But answer essentially lies in "How far you want to go on a quest to find these answers?" since it has its roots in Psychology, Critical thinking and many other places including:

- What's you motivation to be seen as an Expert ? Ever thought about it?

In general it has it's roots spread across - Emotional Reasons, Psychological

reasons, Social reasons, Financial reasons and so forth.

- Are you really trying to solve the real problem or just trying to address

that in the realm of your own area of experience/expertise ?

- And in real world in order to do what I just mentioned above, you got

to step out of your comfort zone, So are you willing to do that?

- Since every environment has its own set of nuances involved including

its own set of constraints, one solution won't meet everyone's needs.

- Are you good at interacting with people or you are just comfortable

talking to Network devices and consider yourself as an introvert?

- Are you keen to learn but more importantly put in practice lot of those

non-technical but essential skills which you would actually need to first

understand the problem landscape correctly?

- Are you keen to do actual hard-work to gather data points and validate

your understanding and hypothesis on a given topic or problem a

statement? - Trust me, this is where 99% people usually fail as in most

cases they have lot of hypothesis and solutions which only they think

makes sense with no validation and Data to prove their point. And in

many cases the data in question is too generic.

- Are you keen to constantly challenge yourself for good? (Since at times

it's a restless & never ending process - Though many enjoy that

pain being nerd)

- How do you find balance between Life, Work and Passion (Do you have

a method/approach to apply?)

- Do you have plans or just aspirations? (In my personal view aspirations

are 1000 kg a $ and plans are expensive)

- Are you another victim of Dunning Kruger effect or Big fish little pond

effect ?

- Are you in love with Problem or in love with Solutions? Unless a problem

is very well defined, it can't really be solved or else your solution in

most cases would be just another duct tape which will fix something

temporarily but increase complexity by large margin.

- Are you open to listen and learn from other or you are the smartest

person in the room that knows the answers always? The most complex

set of problems are solved best collectively rather than by just throwing

your point of views into the equation.

L&D Cartoon – Too Busy To Learn | L&D Generous

- And last but not least - Are you willing to fail many times before you

succeed or even partially succeed?

So as long as you have answers to those questions, that's a pretty good place to get started. :) , and if not - Keep continuing to play giant pretending game by projecting yourself as an Expert. :) ... since many people still love illusions or perhaps enjoy living under the rock.

Further stuff to go through: (Make sure you watch them few times)

https://www.youtube.com/watch?v=Hd_ptbiPoXM

https://youtu.be/g25jcvtjZjA

HTH...

A Network Artist

Thursday, April 23, 2020

Do You Really Need VxLAN in a Modern Data Center ?

It started as a thread on Linkedin yesterday when someone posted a sort of glimpse of his free Cisco ACI training on linkedin. Later a Network Architect joined the conversation thread by asking the Original poster "Would you prefer ACI or BGP EVPN VxLAN based standard fabric ?". Of course the Architect suggested he would prefer BGP EVPN VxLAN fabric (That's mouthful man :) )

As usual out of my curiosity (without being a DCN expert - Yes I only worked on 3 ACI projects and Zero Cisco Nexus 9K BGP EVPN VxLAN fabric (VTS) so far), I asked this self proclaimed Network Architect another question...very basic in my view:

In modern Data Center context, Where in VxLAN actually plays an important role. Or is it just another snowflake in Networking realm in order to keep your App guys happy since you are not good at Saying " NO " and push them to build better Apps those works well on L3 vs. Sure guys, I can help you with L2 stretches for your App Clusters and for those totally broken old legacy Apps which only works on L2 best.

The point being:

Most modern App works well on L3 in conjunction with DNS
From Cloud Native Apps perspective, L2 shouldn't happen to begin with
vMotion works well on L3 since 6.x release
Inter DC Cluster using L2 are well known bad design practices (Some people tried it with even firewalls and failed miserably)
At least in my personal view, Most Enterprises still run MLAG or vPC thingy for server redundancy compare to perfect world (Original Hyperscaler ideas) where you either run Routing with Servers and VxLAN boundary starts from Hypervisor layer to avoid broken MLAG and STP implementations
Let's agree on L3 based transport is much better compare to L2
Perhaps we have seen enough DC meltdowns in past due to broken L2 and broadcast loops by now ?
Did you ever notice that most Hyperscalers DCs don't run VxLAN in their DC fabrics (Pick your favorite one) - https://engineering.linkedin.com/blog/2016/03/project-altair--the-evolution-of-linkedins-data-center-network
Perhaps there are good reasons someone like AWS and AZURE don't let you run VxLAN between your On Prem DC and Virtual DC they host (VMware on AWS is a corner case and rather a joint GTM thingy)
How many of your Use Case requirements are persistent vs. temp in nature ( Migration and Maintenance were always temp requirements in my view at least)
What value Bridging over L3 really has today to begin with
Shouldn't we rather focus on solving real problems instead of pretending
Don't forget you can't have unlimited VxLANs in real world like most vendor slides tell you otherwise
Focus on your failure domains/blast radius and create a strategy to mitigate that - Which doesn't seems easy in VxLAN environment and more so in Controller based Clos Fabric (Single Plainer) running VxLAN
And since Overlays such as VxLAN seems to be the new norm in Enterprise DCs, Make sure you are familiar with some of well known Overlay Problems besides challenges such as Visibility, Security and so forth
Make sure you fully understand the VxLAN convergence process with EVPN added while understanding your dependencies on Physical Topology, Underlay Convergence and other nuances
Make sure you understand Leaky Abstractions & Grey Failures very well in context of VxLAN deployment
Understand some myths about Clos Fabric that your favorite vendor otherwise won't tell you - Part 1, Part 2, Part 3 & Fact Check

And of course I am totally ignoring:

Level of complexity VxLAN and EVPN brings into Design...You either got to read through few books to become an SME or your must be Genius
NSX over ACI never took off ... sort of
Most VxLAN implementations are still vendor specific and ACI runs modified VxLAN header
VxLAN & EVPN across multi vendors in Single environment... Good luck (Though things have improved a bit over time)
MPLS & SR in DCN Fabric...Perhaps needs a separate discussion
I am not aware of any strong one to one mapping in context of Overlay and Underlay correlation for simplified Day 2 and operations
VxLAN vs Geneve (What NSX-T uses now) vs STT vs NvGRE (Assuming you love MS) vs Dove....Needs separate discussion
This is not a scalability discussion but more around to find real world use cases for VxLAN
MS Fabric today (Not Originally) does run VxLAN since 2015. Spoke to few MS friends, seems like Bing was Broken from APP designs perspective so they had to do it in order to Keep Business and App guys happy....BTW who runs Bing anyway :)
If you are running HW VTEP with MLAG for servers. Perhaps you got to relook into your design and define what purpose VxLAN really serves
We still got plenty of other HW and SW in DC context that don't understand VxLAN and more importantly have no HW acceleration
Role of VxLAN offload on NIC, DPDK, SR-IOV and other stuff....perhaps needs a separate discussion
HW and SW VTEP Integration and how broken those are...let's keep it for another day
IPv6 DC/IPv6 Only DC and VxLAN v6... Perhaps need another thread
Control Plane, Data Plane & Policy Plane Security in Context of VxLAN - Requires a separate discussion
VxLAN Control Plane, Data Plane & Policy Plane in Multi DC, Multi Cloud and Active-Active DC - Needs separate discussion
Control Plane & Data Plane Optimization in VxLAN Context - Broadcast Suppression, Conversational MAC address Learning, BUM traffic (Watch out for those details in given implementation

So question remains - What value really VxLAN brings in the context of modern DC. (Please don't tell me scale, let's keep it as a topic of debate for another day) ?

Saturday, January 11, 2020

Why You Shouldn't Bother About Having An Inbuilt LTE Interface In Your SD-WAN Device

Very often I have seen Clients and Network Engineers being very much concerned about having inbuilt LTE/4G interface into their SD-WAN device. Here is my take on why it shouldn't matter or perhaps should be one of those things you should avoid. Because:

They can hook external LTE Modem to SD-WAN device using ethernet hand-off. More importantly external LTE device can offer Dual SIM in Active Standby design from two different provider and even Active-Active setup.
External LTE connectivity provider can offer their service on MRC (Monthly Recurring Charges) model.
Most enterprises usually have partner/promotion plans from Mobile operators those can be leveraged.
Makes deployment easy and consistent in Global Scenario. You don't need to chase several Telcos and keep track of usage etc.
They offer few basic SD-WAN capabilities from their box natively.
They offer external Antenna connectivity as well. Most DC floors running SD-WAN device with inbuilt LTE interface are likely to face Signal coverage issues sitting behind thick walls.
Moving to 5G seamlessly becomes easy as you don't own HW and nor dependency on SD-WAN device itself
Management interface/EMS to monitor, manage and troubleshoot Mobile connectivity centrally and central help desk model
With inbuilt LTE interface you always need to verify Band and other compatibilities for given HW and SW version. External LTE interface through ethernet handoff takes that pain away and lower that risk.

Further Readings:

https://www.sd-wan-experts.com/blog/sd-wan-buyer-alert-the-hidden-costs-of-4g-lte/

HTH...

A Network Artist