Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Chris (00:14):
Hello and welcome back to
another episode of the Cables
to Clouds podcast.
My name is Chris Miles at BGPMain on Blue Sky.
At BGP main on blue sky,joining me is my co-host, who is
, um, always happy and smiling.
Uh, mr Tim McConaughey atCarpe-DMVPN on blue sky.
(00:35):
Um, and today's episode isactually a continuation from a
previous one.
So, um, we had a uh part one tothis series with, um, with our
good guest, cam McGaughan, whois joining us again today.
So we did.
Part one of this episode wasbasically about how to prepare
for an interview with the techgiant, specifically around the
role of a cloud network engineer.
So we've definitely seen kindof more of these roles popping
(00:58):
up, typically at largeenterprises, tech giants, so to
say, and Cam has some greatfeedback on how to prepare for
interviews whenever you're goingup for one of these jobs.
So if you did not listen topart one, I highly recommend you
go back and have a look at that, because this is going to be a
continuation of that episode.
But real quick for those justpopping in here, cam, can you
(01:19):
give us a brief intro to who youare?
Kam (01:22):
Absolutely.
Yeah, thank you so much forhaving me again.
My first name, as you mentioned, is Cam and right now I'm
Senior Director of CloudEngineering with Oracle and I've
been doing I've been in thisfield for probably 25 plus years
but majority of that networkingsome systems and, like you
(01:43):
mentioned last time, we recordedreally good stuff.
We covered a lot of thingsmostly around TCP, udp, IP,
foundations and basics, so veryhappy to be here again and
looking forward to having agreat conversation once again.
Chris (02:00):
Absolutely yeah.
So we kind of got started witha little bit of kind of just the
lay of the land, setting thetopic a bit, and got into a
little bit of the foundationalpiece, talking about some kind
of very foundational base levelprotocols that you need to be
familiar with for jobs like this.
And, if I recall correctly, Ithink we got some feedback from
the listeners specifically abouta couple of those topics.
(02:22):
So do you want to?
You want to address those realquick?
Exactly, exactly.
Oh, that's a couple of thosetopics, so do you want to
address those real quick?
Kam (02:26):
Exactly exactly.
Oh, that's a great, really goodpoint.
So some of the feedback andcomments and messages that I got
, especially through LinkedInthree people asked pretty much
the same question.
The question was around TCP IPand how to prepare for that.
Last time we talked about TCPIP routing, volume one, and
(02:48):
that's probably my go-toresource and there are some
complaints that well, contentmight be a little dry, it's not
very entertaining, it's notsomething that I'm attracted to
and I want to be studying for avery long time.
So I hear that actually all thetime when I talk about this.
Like this is going to be a bigpart of the interview,
especially with tech giants, notjust for cloud engineering
(03:10):
positions, also any networkingrole this question comes up.
So I guess there are two waysto answer this question.
One of them is a little, Iguess, brutal answer that it is
what it is it is dry.
It is dry part is becausescience part of this.
When you go to computer science, computer engineering fields,
this is part of the course.
(03:31):
This is something that peopleactually study every one
semester, so it's supposed to bea little like science-y part of
the work and people actuallyget PhDs in this field.
So there is that.
But at the same time, I agreethat it would be nice to see
some practical examples to getyour hands dirty, to kind of
(03:52):
entertain yourself as you'relearning all the theories.
My recommendation is and Ithink to answer all questions
that we've got is spend a lot oftime in Wireshark.
That's probably the easiest way, maybe even the cheapest way,
to get that experience.
There are two ways here, twoways.
One of them is go in andcapture packets different
(04:14):
scenarios, you do it, you set upyour own app and you start
capturing packets.
It could be a physical network,could be I want to start
production non-prod network, butat the same time you could do
this in simulations.
Another interesting approachmaybe a little tip here is most
packets and types of traffic.
Someone has already capturedthose.
(04:36):
If you Google them, if you lookthem up, I'm sure you can find
some packet captures.
You can find some pcap filecaptured with someone and they
will show you.
You know that particular flow.
Spend some time on those whenyou capture, when you study
those.
Probably it's going to be alittle more entertaining at the
end of the day.
Uh, I guess from my perspectiveit's positive that it's not the
(04:59):
easiest topic in the world,because, keep in mind, that's
our differentiation, that's our,uh, kind of selling point.
If I were to hire someone, youknow, yeah, spend 10-15 hours on
this, and that could separateyou from people who do not know
that.
So we, at least we know thereis this thing here.
It's not probably the easiesttopic, but after spending 10-15
(05:22):
hours you can easily nail it.
So why not?
And that book is important.
There are some otherpresentations on internet.
What you could do is just lookit up.
There are some universities.
They have PowerPoints there.
Those PowerPoints areabsolutely invaluable.
I love them.
There are some other businesses.
They publish packet capturesfor their own types of traffic
(05:44):
and you could capture yours.
Of course, there is a TCP IPvolume one.
That's an interesting topic tolearn.
This is about the theory'spractical side of it.
Create your own scenarios.
We talked about the far alarmsystem.
We could talk about drones,talk about self-drive cars.
Put yourself in those scenarios.
Do I even need to have anacknowledgement back from the
(06:08):
other side?
Do I need to have a reliableconnection?
If the answer is yes, what aremy options?
In the app or let the protocolhandle that altogether?
So that's just to cover what Iwanted to go back to the
previous episode and answer.
But thank you so much.
We're pausing here for a secondto close the loop there.
Tim (06:31):
So I mean, there's a ton of
public repositories for PCAPs
out there.
I honestly one of my favoritesand I don't know what's happened
to it yet.
I think multiple people havetaken and mirrored um, our uh,
nick russo's old uh pcap library.
Nick russo had a really goodpcap library that he spent a lot
(06:51):
of time putting together, likedoing the app, traffic and all
that to put together thatwonderful repo.
So it's out there.
Um, it's not on his websiteanymore.
Of course his website has beendefunct for some time, but um,
right, it's out there yeah,that's.
Chris (07:06):
That's that's one I
always plug um.
I will give another plug for,uh, chris greer, who I think
does a lot of good stuffspecifically around a lot around
um wireshark specifically, butobviously that that comes into
um the realm of tcp very often.
So um definitely check out hiscontent as well.
But I think that's the thingabout TCP and stuff like that
(07:28):
it's like it's probably boringand dry because it hasn't
changed in 40 years, because itworks so well, right, so it's
like it's still just as relevanttoday, right.
Kam (07:37):
That's very true, very,
very true, exactly.
So that's that point, a littlelike a very small point here
Kind of innovations in that area, new implementations, how
things change, how Google Edgewants to process that traffic,
how different businesses want toprocess that traffic.
I personally don't think theinterview is going to go in that
(07:58):
direction.
You have to know details of aspecific vendor and how they
handle that implement.
That's, uh, stack traffic, uh.
So for the most part, uh, justknowing theories that we covered
last time plus what wediscussed today should have you
fully covered yeah, gotcha goodpoint.
Chris (08:18):
Um.
So I guess let's um, like Isaid, we we did cover some stuff
in the last episode.
We kind of got into the initialfoundations and those topics.
Let's kind of reset the lay ofthe land.
Like, you as the interviewer,where are you at in this process
?
Like, have you potentially gonethrough your first kind of
candidate screening type thingand talked about some of this
(08:38):
stuff?
Where are you at and where arewe getting started today?
Kam (08:42):
Cool, yeah, that's a great
question and where are we
getting started today?
Cool, yeah, that's a greatquestion.
So, going back to thetraditional world, if you wanted
to hire a network engineer fortech giants you know not
everyone but majority of thepeople that I've seen they would
approach this First in everyyear we'd ask questions on
foundations.
So what we covered last timelet's talk about TCP, udp, ip,
(09:03):
the headers, details, flags,different stacks, different
behavior of those stacks.
How do we deal with packet lossand all that Slow start and the
whole package.
That's one interview In thisnew world with the whole cloud
engineering.
That's still valid.
The second part, the secondvertical here, is the routing
(09:25):
part of that.
In a traditional world, thatbucket, that would be most cases
an IGP.
People cover IGP, sometimesOSPF, sometimes ISIS.
Let's just dive into details ofthose and talk about the
details.
The third interview in atraditional world would be GP.
But in this case let's just goback to the second bucket.
(09:47):
What happens when we rolled outthe entire cloud into enterprise
world?
Well, the IGP today is not asimportant as it was in this
context, in this particularcontext, when you're preparing
for those interviews.
So that's the second part youwant to talk about what's
(10:08):
replaced that IGP part.
For that part we're going totalk we call this like a general
name connectivity and in thatconnectivity bucket we cover
things like how to connect youron-prem to data center to
on-prem and data center to acloud and how to provide
encryption, how to do routing onit and basically the entire
(10:29):
connectivity package.
So that's, I guess, good nextstep for us to talk about it and
see how on-prem would work withyour cloud, and under that, of
course, we have our own bulletpoints to cover yeah, definitely
okay.
Chris (10:46):
So, yeah, let's, I guess
let's, let's head right into it,
let's get started.
So what's the?
What's the first topic we wantto cover?
Kam (10:53):
yeah, absolutely so.
One of the very first topics assoon as you get into cloud, one
of the first questions thatpeople ask and it really doesn't
have anything to do with theinterview yet, it's just pure
engineering is well, I got thisgreat cloud footprint and
majority of customers?
(11:14):
They are not cloud-onlybusinesses.
There are cloud-only businessesout there, but majority of
customers probably I would say95% they have something
somewhere else, could be anothercloud, could be somewhere
on-prem in a data center or inone of your physical buildings,
and they need some kind ofconnectivity between those three
.
At that point, there are twogeneral options, a lot of
(11:36):
different varieties, but twogeneral options.
One of them is create a tunnel,like the old way IPsec tunnel
between your cloud and thatother place Could be another
cloud, could be your on-prem,could be in data center, could
be one of your buildings.
That's one option.
The other option is what wecall dedicated connection.
(11:57):
In the world of dedicatedconnections, depending on the
vendor, well, they havedifferent names Oracle, we call
it Fast Connect, amazon DirectConnect.
You have ExpressRoute withMicrosoft, interconnect with GCP
.
At the end of the day, thedifference between these two is
always a good and interestingquestion and how you're able to
(12:19):
articulate that or provideexamples.
Keep in mind IP Sec Tunnel.
It's the traditional IPsectunnel.
It's exactly what it was.
You're writing, writing a publicinternet.
You're exposed to all the youknow stuff that might happen in
the internet.
You're gonna have to deal withthe latency.
There's potential jitter,potential packet loss and all
(12:41):
that.
But guess what?
If you know how to do it, youcan quickly set this up in a
matter of minutes.
Bring it up and it's going togive you a decent connection,
decent bandwidth, differenttypes of bandwidth, different
CSPs.
But at the end of the day, it'sa dirty and quick solution to
connect your data center to thecloud or cloud to cloud.
(13:03):
That works.
That's a great solution thatworks.
On top of that, it also hasencryption.
Some people, please go ahead.
Tim (13:15):
Yeah, it's also kind of
universally supported for the
most part.
Right, ipsec is a veryuniversally supported technology
.
Like you said, it's quick, it'sdirty.
It's kind of a lowest commondenominator really for secure
connectivity.
That's very true, that's verytrue.
Kam (13:28):
That's very true,
especially in cases like proof
of concept.
When we talk about the secondone, I will show you why it's so
important because in this case,you're not really making huge
investments, so we're nottalking about big capx.
I don't have to make a capitalinvestment here.
I have a router, a firewallthat supports the IPsec.
We find some common parametersand bring up the IPsec tunnel
(13:49):
between the two environments,and that works.
However, most I would say,production environments.
Today we're talking 2025, Ipersonally recommend something
better, and that better optionis that dedicated solution.
There are different ways tobuild that option.
(14:09):
Is that dedicated solution.
There are different ways tobuild that you could go in
around the same data center, runFiverr and be directly
connected to that carrier, tothat CSP.
Yeah, that's one option and, ofcourse, it's probably, I would
say, the most reliable option,because you know there is no
anybody else in between.
That's just you and the CSP.
The other option is you go tosomeone else.
(14:30):
They provide that connectiontoday.
Some examples Equinix andMegaport for example yeah,
Minimal.
Oh yeah, they provide excellentconnection and great bandwidth
and all that.
So that's another possibility.
You have some kind of carrierin between might be AT&T,
verizon, someone else, some kindof network.
(14:50):
You use that network, ride itall the way to get to the CSP.
That's another option.
Either way, with that solutionnow you need to think about what
you had previously withIPsecTown, which is encryption,
and that's another nice questionthere.
There are different optionsthere and those options well,
(15:13):
pretty much just like thetraditional world.
Yeah, you could run an IPSectunnel, drop it somewhere inside
your cloud environment.
That's one option.
Bring it in if the CSP supportstermination of the IPSsec
tunnel on the routing construct,for example, we do support it
on our drg.
Go all the way from yourfirewall or router, bring it all
(15:36):
the way to our drg, which issomething like aws, tgw, yeah,
and terminated there.
We terminate that terminalhandle encryption for you.
Or now, you remember we had allthe problems with performance
of IPSec.
Ipsec is a high overload way ofdoing encryption.
You don't want to do it.
You want to see lighter andline rate encryption.
(15:59):
Macsec is there, the challengewith MACsec, and I see this in
production a lot, maybe,sometimes.
Maybe it's a good interviewquestion too.
Macsec is that lightweightsolution.
However, still after all theseyears several years, I see I
actually find it harder to setup MACSEC and find that you know
(16:21):
the common that's true.
Exactly the common parametersbetween the two, to bring up
that connection, compared towhat we have in IPsec.
Tim (16:32):
Well, and it's a single hop
.
It's a single hop encryptionand you have to have special
licensing or gear.
Essentially, that supports it.
I mean it's tough right.
Kam (16:42):
Exactly, exactly and with
MACsec or MACsec in general,
doesn't like layer 3.
So if you are doing MPLS, l3between the two, it's not really
an option.
So you are cross-connect, it isan option.
It's just a fiber who caresMost.
Layer 2, these line connections, you could do MACSEC.
But as you get into the bowelsof your service provider and
(17:06):
they start doing any kind ofMPBGP within their network and
all the L3, mpls, vpn, maxlackis not really an option.
That's true.
Tim (17:16):
It's very true.
Kam (17:18):
Yeah, you got to know these
options and be able to explain
details, and especially if thisis a more senior level role pros
and cons.
Architect's role is exactlywhat we just talked about, and
especially if this is a moresenior level role pros and cons.
Architect's role is exactlywhat we just talked about.
You have a bunch of options,pros and cons of each, and you
provide suggestions, please,yeah.
Chris (17:38):
Go ahead.
I was going to say.
I think another thing to kindof point out with either of
these solutions whether we'retalking about dedicated
connectivity or IPsec VPNssolutions, whether we're talking
about dedicated connectivity orIPsec VPNs is that you kind of
really need to know the subtledifferences to the traditional
way that these things are done,because they're being offered
from a cloud provider.
Tim (17:55):
They're being offered
Managed provider.
Chris (17:57):
It's a service, right?
So there's going to bedifferent behaviors Like you
can't just walk in and say like,oh well, I know how IPsec works
, so I'm going to know how itworks in the cloud, because
that's not always true, right.
There's subtle things liketermination points.
There's behaviors like you knowthe cloud isn't going to
initiate the tunnel for you.
You always have to be on theinitiation phase because you
know they're providing a serviceLike it changes the way things
(18:20):
operate right.
Tim (18:23):
Exactly.
Oh, yeah, I mean, you use it.
Basically, you are just likeany managed service, right, you
consume that service the waythat the provider wants you to
consume that service.
Right, they might give you someoptions, but you're still
locked into one of two, one ofthree options.
Right, that's true.
Kam (18:40):
It's very true, very true.
So that's a high level pictureof this.
But just imagine howembarrassing that situation
could be.
You are explaining to me as aninterviewer that well, I have
MACSEC, I have IPSEC, I haveclear checks.
Now my choice is IPSEC.
I want to do IPSEC, forwhatever reason, just like the
ones that you described.
(19:00):
Now my next question is couldyou just explain to me how IPSEC
works?
Maybe faces a little?
What's going on under the hood?
You got to know that.
So the moment you start talkingabout IPSec, you need to know
the details of it.
Unrelated to this, I recommendthe same thing for TLS and SSL
stuff.
(19:20):
Oh, for sure, if you want totalk encryption, you got to know
how the encryption works.
It's not just you drop names.
Oh, ipsec is the best option.
That's optional, I don't know.
So, yeah, you got to spend sometime and find out how IPSec
works, different phases and it'sactually very handy
Troubleshooting process.
If you don't know how IPSecworks, you can't do any
(19:41):
troubleshooting.
Same applies to MACsec and SSLand a bunch of other things.
Tim (19:45):
Yeah, I think you need to
be able to describe not only the
well.
So on the IPSec side, you gotto be able to talk about key
exchange, you got to be able totalk about algorithms and all of
that, and, of course, on theTLS side, you need to understand
certificate exchange and howsigning works and CAs and all of
that.
Yeah, for sure, exactly exactly, very true.
Kam (20:09):
So that kind of wraps up
the topic of connections or
connectivity between yourenvironment and your cloud
footprints.
You can get into details andspend more time on key exchange
and you know the whole conceptof encryption, different options
within PLS, maybe basics of howMPLS networks work, things like
that.
Connectivity in general.
Just familiarize yourself withthose terms, but that's not a
(20:30):
really challenging topic.
Connecting your on-premwhatever that is to the cloud
provider or your cloud one tocloud two, yeah, so that kind of
leads us to the next topic, andthat next topic is well, now we
have this connection in place,what is going on in that link?
(20:50):
How do I route traffic?
What are my options?
And that's the.
I guess there's more meat thereto cover and there's more, of
course, to learn.
Chris (20:59):
Yeah, for sure.
So yeah, let's kind of breakthat open a bit.
So I think we want to get intodetails about routing and BGP.
Kam (21:07):
Absolutely, absolutely.
That's probably my favoritepart of the interview because
well, not because I know thatwell, because it's used in every
single discussion, every singleconversation with the customer.
At some point you're going tohave this conversation with them
that, look, this is how routingworks works.
This is how traditionally itworked.
(21:29):
This is now.
It's done now.
So let's just go back to, Iguess, 20-25 years ago I promise
I won't bore you, but routingin general, routing in general,
when we wanted to learn routingand this has now changed a lot
um, it has, but not a lot.
We'll start with static routing.
Static routing creates simple,static routes and points this
(21:51):
traffic sent to this IP.
Static routes, the nextgeneration kind of one level up.
I don't think many peopleremember that it was something
called ODR.
Tim (22:00):
ODR.
Kam (22:01):
Here we go, here we go.
Oh yeah, ODR.
Actually some people got thatCCI question.
Tim (22:08):
I knew you were going with
that one.
Kam (22:11):
So there was this ODR thing
with CDP and all this stuff.
So ODR is gone, but static isstill there, right, static
routing is still there.
It's important.
And the next chapter, the nextsort of level, next conversation
, one level up was IGP.
People were talking about RIPv1, v1, rip, v2.
Those two are not applicabletoday.
(22:32):
I don't really see I maybe oncea year I see the rip v2
somewhere.
Always you defend ergrp, kindof important.
Sometimes there is a littleoverlap between what cloud
providers do and what you aredoing on-prem.
On-prem you have your own IGPrunning right.
Might be OSPF or EIGRP I don'tsee a lot of ISIs, but some kind
(22:57):
of IGP.
And if you look at your border,the boundaries of your
environment, you're doing manycases some kind of
redistribution or export betweenthose two and you're receiving
routes from your IGP, sendingthe routes back to me, and we
try not to get into details ofwhat's going on in your IGP.
(23:17):
So if you were going to workfor a CSP, that's pretty much
where your territory ends.
That's your boundaries.
You're not going to get intohow their IGP works.
However, there are cases whenyou're troubleshooting.
You need to know why you're notseeing this route, why they're
not seeing this route.
You just trace it back.
(23:37):
You get to the point wheretheir IGP is not injecting the
route into your BGP.
Well, that's pretty much theextent of what you need to know
about their IGP and your IGP ifyou work for that enterprise.
So I'm not going to get intothe details of IGP.
I suppose someone who's studyingBGP and knows BGP has already
(23:59):
studied and spent some time onBGP.
I guess that's a fairassumption.
And then there is this gianttopic of BGP.
It used to be a lot bigger intraditional networking giant
topic of BGP.
It used to be a lot bigger intraditional networking.
On the cloud side it's not asbig.
But let's get started and lookat two different interview
styles when it comes to BGP.
(24:25):
One interview style one I guessdirection that this could take
is some people just take thetraditional path and start
covering BGP.
You need to know the attributes, you need to know the whole
concept of optional, mandatory,transitive, non-transitive, and
then get into details of thosefor inbound and outbound traffic
and even sometimes aggregation.
I've seen Vrata, fectors,confederation, the whole BGP
(24:46):
package, and that's one way ofcovering this.
The other way is focus on whatthe candidate needs for the
cloud position and today 90,probably 5% of BGP is done
around a few topics Inbound andoutbound traffic.
How to influence that traffic?
(25:07):
Of course you have multipleconnections.
You want to prefer one over theother.
That's one.
Tim (25:12):
Traffic insurance.
Kam (25:13):
Oh yeah, convergence is a
good question.
You have the timer, you havethe whole BFT stuff and a little
bit on troubleshooting.
You need to know the attributesand how they work, but I'm not
going to get into details of,for example, ras reflectors I.
But I'm not going to get intodetails of, for example, ras
reflectors.
I'm not going to push youreally hard.
Do you know RFC 1966?
Do you know RAS reflectorsinside the Confederation, how
(25:37):
they interact?
That is not what I'm going tocover, at least from my
perspective.
That's not the fair scope.
But let's take a quick look atwhat it means to be prepared for
the routing interview.
I remember and this isinteresting because this goes
back to probably I don't knowover 15 years ago I had applied
(25:59):
for a role.
It was a network engineeringposition.
Of course Someone called me.
It was a recruiter.
Recruiter called me.
You know how the recruiterconversation is supposed to go.
You pick up a phone and youtalk how the recruiter
conversation is supposed to go.
You pick up the phone and youtalk about the water.
It's great.
Thank you so much for applyingfor the role and tell us about
yourself and your position, yourtitle, why you're looking, what
(26:21):
you're looking for and allkinds of things, right, your
compensation.
So right after greeting, sheasked me all all right, can you
name bgp optional attributes fora second?
I thought I misheard her.
Could you just repeat bgpoptional, are you?
Is this?
Is this an interview?
So we had those things we have.
(26:44):
We had the recruiters try tofilter out candidates right off
the bat and they would ask thosequestions.
That's kind of, I guess, bad wayof surprising anyone yeah there
was a better way and we wouldcover bgp a lot.
Put you know nice scenario,like we'll talk about um.
You're a network engineer,designer and you want to
(27:06):
influence your traffic inmountain to your environment and
let's talk about the MAD.
Right, if you could explain tome why right now I'm configuring
this, why I should use ASPathprepending and not MAD for the
internet, well then it probablytells me.
You know what transitive andnon transitive concept works,
(27:28):
that I'm gonna give you creditthere.
But if you just memorize whichone is transitive, which one is
non-transitive, probably that'snot the most senior way.
That's how I would approachthis.
So this was all about thetraditional world.
Today, when you look at this,let's just go back to what I was
talking about how to influencetraffic, inbound and outbound
(27:48):
communities, your BGP attributes, how to improve your
convergence time with timers andBFD.
Bfd is an interesting topic,just like what we just talked
about, ipsec, right, droppingnames is not going to help you.
So the fact that you know thereis something called BFD that
could help you, it's not goingto help a lot.
(28:10):
You want to know the messagingsystem.
You want to know the details ofBFT.
There is a nanotalk.
It's an old one I guess theremight be a newer version of it
and you can see details of BFTCapture packets.
If you're in doubt, go in andcapture packets and you will see
how BFT works.
Because at least when you'retalking to me and you say I'm
(28:31):
going to use BFD to improve myconvergence time, that's the
reason.
Because 10, 15 years agoprobably you could say well, I'm
going to use BFD because a veryaggressive timer is going to
bump up my CPU.
Today.
That's not the reason.
Today you do this to improveyour half.
Tim (28:49):
Have sub-second conversions
, so hang on a second.
Yeah, so hang on a second.
There's a couple things here,right?
So bfd is a very interestingtopic, with cloud specifically,
because, of course, cloud beingthis hypervisor environment, um,
often, even though you can usebfd to have like this kind of I
wouldn't say sub-second, I thinklike one second is probably the
best you're going to get withany provider is you can have
this kind of I wouldn't saysub-second, I think one second
(29:09):
is probably the best you'regoing to get with any provider.
You can have this kind offailover, but the hyperplane
often still doesn't necessarilyreact quickly enough to truly
take use of BFD.
It's BFD specifically.
I'm not disagreeing with you, bythe way.
I know we're talking abouttechnologies that matter and
that is one that you can usewith certain providers in
certain situations, like youknow, gcp or Google Cloud, you
(29:30):
can use it with NCC.
There's certain places you canuse it.
But I always thought it waskind of funny because for
specifically for BFD, you thinkabout like the data center use
case or like the campus use case, where you're looking for
sub-second convergence orfailure detection and read it's
just, you're not there.
It's a you know, but I do thinkyou still need to know it and I
think it still is faster thantraditional like BGP timers of
(29:52):
20 seconds or something likethis, right?
Kam (29:55):
Oh yeah, you don't want to
wait for a timer to expire.
We all know that.
So point is, make sure when yousay TLS, ipsec or BFD, you know
how they work.
This is again interview withtech giants is not a
configuration test.
Last time we talked about thiskind of half joking that when we
(30:15):
took CCIE.
Ccie was a config test.
This is not a configurationexam.
So the fact that you know BFDis the command is not going to
help you.
You need to know why and how.
So theory is still veryimportant around topics like how
so theory is still veryimportant around topics like BFD
.
And if you have time you wantto learn more about BGP,
(30:35):
absolutely go ahead and do it.
But just for the scope of thisand how it works in the context
of cloud, keep in mind you areinfluencing your traffic.
Whatever could be related tothat absolutely important.
Anything else extra topicswould be nice to know.
Agreed.
Chris (30:52):
Yeah, I think the thing
is here.
You can obviously deep dive onBGP and go very deep in the
weeds on, like you said, doingthings like route reflectors,
multi-protocol BGP.
There's endless rabbit holes.
You can go down right, right,um, and I think if you're
looking specifically aroundcloud, I think you really need
to make sure you're payingattention to the nuance as far
(31:13):
as what's available in cloudfrom that aspect right because,
yeah, there's, there's multiplescenarios where, like you know,
bgp is available, but maybe onlyum, only certain attributes are
supported, right, you knowthere's certain communities, oh
yeah, communities that are usedExactly.
Kam (31:30):
Oh yeah, communities.
That's a really good point, evenyou know some CSPs do not use
communities at all, do somethingelse.
So, as you know this, we'rekind of entering territory where
it's very cloud or CSPdependent.
So it goes back to theimportance of knowing job
description, doing a little bitof research, gathering a little
bit of intel.
What kind of cloud provider arewe talking about here?
(31:53):
Most people that we interview Ican't just speak for myself we
know other cloud providers.
So if your example is you'retrying to use community, we
might not support that community.
That's still fine.
We know which cloud provideryou're talking about.
But as you start talking toprobably smaller businesses this
(32:14):
is not TechGiant anymore orsome picky interviewers you want
to know more about which CSPyou're talking about, what they
have if that matters.
Chris (32:24):
Yeah, do the research
ahead of time.
Kam (32:26):
Exactly, exactly, so.
That's the routing part of thistime.
Exactly exactly so, that's therouting part of this.
We covered connect connectivity, your options and encryption
and how we route traffic.
That kind of should concludethe second part of the second
interview, if you will, andbeyond this we're going to enter
(32:46):
some other services that couldbe this time, uh, very much
dependent on the CSP.
Chris (32:51):
Yeah, totally so, yeah,
so just maybe a quick recap
there.
So we've kind of gone over theimportance of building
connectivity to and from thecloud using things like IPsec,
vpn, direct dedicatedconnections as well, connections
(33:13):
as well, and then theimportance of you know kind of
table stakes, routing constructsthat are in use in a lot of
traditional networks that havemoved up to the cloud, and how
they've changed a bit, the kindof main front runner being BGP,
but static routes definitelylive in the cloud very much so.
So that's definitely not goingany way.
We've consolidated, but westill have the two major players
still in play there, right,totally.
(33:33):
So yeah, let's keep going.
Kam (33:36):
Exactly, exactly, just
final points.
You know, further study, ifsomeone is interested, and
topics like ECMP in the contextof routing is still important.
So, you're not doing static,you're doing BGP.
You have multiple connections,you want to use them at the same
time.
Ecmp might still important.
So you're not doing static,you're doing BGP.
You have multiple connections,you want to use them at the same
time.
Ecmp might be important andECMP by itself.
(33:57):
What used to be pretty boggypeople had to troubleshoot like
am I getting kind of sort ofsimilar traffic.
Understand ECMP very well.
Once again.
It's not just I know ECMP, do Iknow how a cmp works.
Yeah, and it goes back to theplatform, and vendors at least
know one platform.
(34:18):
Familiarize yourself with how acmp works on this platform as
an interviewer.
If you were able to explainthat cmp to me and how it works
on just one famous vendor, it'smore than enough.
I know your stuff.
Tim (34:33):
So we should be aware that,
of course, some of the people
listening to this might be notready for an interview with a
tech giant.
So just FYI.
So ECMP, in this case we'retalking about equal cost
multi-path routing, so that's.
Kam (34:46):
Exactly.
I should have said that yeah,exactly, exactly.
Oh yeah, I should have saidthat yeah, exactly, exactly.
Oh yeah, I don't want to getquestions.
What was that thing?
You're right, it is important.
Oh yeah, thank you so much forreminding me.
Yeah, no worries, cool.
So we're sort of at the end ofthe second interview.
Tim (35:03):
So, yeah, so, if we were
going to pick it up, then from
here.
So you know, let's say you madeit to the end of your second
interview, like let's say that,and I and I, by the way, I
really appreciate and agree withthis, this thread that you've
pulled throughout the story,which is don't focus on configs,
(35:23):
don't focus on knowing timersof protocols, don't know, don't
focus on knowing some shit thatyou could go ask Chad, gpt or
Google in five seconds, right,understand the thing and why you
would use it and when you woulduse it.
That's the part you really needto care about because, at the
end of the day, that's whatyou're going to be making
decisions on.
Kam (35:43):
Oh, yeah, exactly, and not
just that.
At least I always appreciate alittle background.
In that background you had anexperience Let me give you a
little, maybe unrelated example,but it's not that bad of an
example With OSPF and BFT.
Today we talked about BFT.
We know IGP is not going to bepart of your interview, most
(36:05):
likely but when we talk aboutBFT in the OSPF context we come
a long way to get this point.
We had timers that we wouldchange for hello and everything
else, and then we ran into aproblem with the hardware.
Then we had a multiplier.
We were able to send multiplehellos per second.
(36:25):
That was one big step.
And then BFT to solve thatproblem.
And now here is the explanationof how BFT works.
When someone walks me throughthis, this is seriously like 15,
20 years of time.
This is the multiplegenerations of OSPF.
I really appreciate it.
So if you know any details, ifyou've seen them in production,
(36:46):
you read about them, go aheadand use it.
Do not hold it back.
I would love to hear that.
That shows me you have thatdepth and you spend time.
You see multiple generations.
Your knowledge is not limitedto a simulation.
It's just one particularscenario that you configured
last week.
Chris (37:01):
All right.
Well, if you have made it thisfar, I want to thank you very
much for listening to part twoof our series with Cam about how
to interview for a tech giant.
So we actually recorded thiswith cam as a three-part series.
So, um, this was obviously parttwo and we will have part three
coming up in the next few weeks.
Um.
So thanks, um once again forlistening to the latest episode
(37:23):
of the cables to clouds podcast.
If you want to check out, um,our fortnightly news update, um,
that is also available on ourYouTube channel.
There's also a link in the shownotes with several news
articles that we update on afortnightly basis.
If you want a link to a copy ofTim and I's book on the AWS
(37:44):
certified advanced networkingspecialty exam, that's also in
the show notes.
And if you need anything else,please reach to us.
We'd love to hear from you,gables to clouds at gmailcom,
and we will see you next week.
Goodbye.