Chris: 0:14

Hello and welcome back to another episode of the Cables to Clouds podcast. My name is Chris Miles at BGP Main 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 at Carpe-DMVPN on blue sky. Um, and today's episode is actually a continuation from a previous one.

Chris: 0:37

So, um, we had a uh part one to this series with, um, with our good guest, cam McGaughan, who is joining us again today. So we did. Part one of this episode was basically about how to prepare for an interview with the tech giant, specifically around the role of a cloud network engineer. So we've definitely seen kind of more of these roles popping up, typically at large enterprises, tech giants, so to say, and Cam has some great feedback on how to prepare for interviews whenever you're going up for one of these jobs. So if you did not listen to part 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 just popping in here, cam, can you give us a brief intro to who you are?

Kam: 1:22

Absolutely. Yeah, thank you so much for having me again. My first name, as you mentioned, is Cam and right now I'm Senior Director of Cloud Engineering with Oracle and I've been doing I've been in this field for probably 25 plus years but majority of that networking some systems and, like you mentioned last time, we recorded really good stuff. We covered a lot of things mostly around TCP, udp, IP, foundations and basics, so very happy to be here again and looking forward to having a great conversation once again.

Chris: 2:00

Absolutely yeah. So we kind of got started with a little bit of kind of just the lay of the land, setting the topic a bit, and got into a little bit of the foundational piece, talking about some kind of very foundational base level protocols that you need to be familiar with for jobs like this. And, if I recall correctly, I think we got some feedback from the listeners specifically about a couple of those topics. So do you want to? You want to address those real quick? Exactly, exactly. Oh, that's a couple of those topics, so do you want to address those real quick?

Kam: 2:26

Exactly exactly. Oh, that's a great, really good point. So some of the feedback and comments and messages that I got, especially through LinkedIn three people asked pretty much the same question. The question was around TCP IP and how to prepare for that. Last time we talked about TCP IP routing, volume one, and that's probably my go-to resource and there are some complaints that well, content might be a little dry, it's not very entertaining, it's not something that I'm attracted to and I want to be studying for a very long time. So I hear that actually all the time when I talk about this. Like this is going to be a big part of the interview, especially with tech giants, not just for cloud engineering positions, also any networking role this question comes up. So I guess there are two ways to answer this question. One of them is a little, I guess, brutal answer that it is what it is it is dry. It is dry part is because science part of this. When you go to computer science, computer engineering fields, this is part of the course. This is something that people actually study every one semester, so it's supposed to be a little like science-y part of the work and people actually get PhDs in this field. So there is that. But at the same time, I agree that it would be nice to see some practical examples to get your hands dirty, to kind of entertain yourself as you're learning all the theories. My recommendation is and I think to answer all questions that we've got is spend a lot of time in Wireshark. That's probably the easiest way, maybe even the cheapest way, to get that experience.

Kam: 4:08

There are two ways here, two ways. One of them is go in and capture packets different scenarios, you do it, you set up your own app and you start capturing packets. It could be a physical network, could be I want to start production non-prod network, but at the same time you could do this in simulations. Another interesting approach maybe a little tip here is most packets and types of traffic. Someone has already captured those. If you Google them, if you look them up, I'm sure you can find some packet captures. You can find some pcap file captured with someone and they will show you. You know that particular flow. Spend some time on those when you capture, when you study those. Probably it's going to be a little more entertaining at the end of the day.

Kam: 4:54

Uh, I guess from my perspective it's positive that it's not the 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, you know, yeah, spend 10-15 hours on this, and that could separate you from people who do not know that. So we, at least we know there is this thing here. It's not probably the easiest topic, but after spending 10-15 hours you can easily nail it. So why not? And that book is important. There are some other presentations on internet. What you could do is just look it up. There are some universities. They have PowerPoints there. Those PowerPoints are absolutely invaluable. I love them. There are some other businesses. They publish packet captures for their own types of traffic and you could capture yours. Of course, there is a TCP IP volume one. That's an interesting topic to learn.

Kam: 5:51

This is about the theory's practical side of it. Create your own scenarios. We talked about the far alarm system. We could talk about drones, talk about self-drive cars. Put yourself in those scenarios. Do I even need to have an acknowledgement back from the other side? Do I need to have a reliable connection? If the answer is yes, what are my options? In the app or let the protocol handle that altogether? So that's just to cover what I wanted to go back to the previous episode and answer. But thank you so much. We're pausing here for a second to close the loop there.

Tim: 6:31

So I mean, there's a ton of public repositories for PCAPs out there. I honestly one of my favorites and I don't know what's happened to it yet. I think multiple people have taken and mirrored um, our uh, nick russo's old uh pcap library. Nick russo had a really good pcap library that he spent a lot of time putting together, like doing the app, traffic and all that to put together that wonderful repo. So it's out there. Um, it's not on his website anymore. Of course his website has been defunct for some time, but um, right, it's out there yeah, that's.

Chris: 7: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 stuff specifically around a lot around um wireshark specifically, but obviously that that comes into um the realm of tcp very often. So um definitely check out his content as well. But I think that's the thing about TCP and stuff like that it's like it's probably boring and dry because it hasn't changed in 40 years, because it works so well, right, so it's like it's still just as relevant today, right.

Kam: 7:37

That's very true, very, very true, exactly. So that's that point, a little like a very small point here Kind of innovations in that area, new implementations, how things change, how Google Edge wants to process that traffic, how different businesses want to process that traffic. I personally don't think the interview is going to go in that direction. You have to know details of a specific vendor and how they handle that implement. That's, uh, stack traffic, uh. So for the most part, uh, just knowing theories that we covered last time plus what we discussed today should have you fully covered yeah, gotcha good point.

Chris: 8:18

Um. So I guess let's um, like I said, we we did cover some stuff in the last episode. We kind of got into the initial foundations and those topics. Let's kind of reset the lay of the land. Like, you as the interviewer, where are you at in this process? Like, have you potentially gone through your first kind of candidate screening type thing and talked about some of this stuff? Where are you at and where are we getting started today?

Kam: 8:42

Cool, yeah, that's a great question and where are we getting started today? Cool, yeah, that's a great question. So, going back to the traditional world, if you wanted to hire a network engineer for tech giants you know not everyone but majority of the people that I've seen they would approach this First in every year we'd ask questions on foundations. So what we covered last time let's talk about TCP, udp, ip, the headers, details, flags, different stacks, different behavior of those stacks. How do we deal with packet loss and all that Slow start and the whole package. That's one interview In this new world with the whole cloud engineering. That's still valid.

Kam: 9:22

The second part, the second vertical here, is the routing part of that. In a traditional world, that bucket, that would be most cases an IGP. People cover IGP, sometimes OSPF, sometimes ISIS. Let's just dive into details of those and talk about the details. The third interview in a traditional world would be GP. But in this case let's just go back to the second bucket.

Kam: 9:47

What happens when we rolled out the entire cloud into enterprise world? Well, the IGP today is not as important as it was in this context, in this particular context, when you're preparing for those interviews. So that's the second part you want to talk about what's replaced that IGP part. For that part we're going to talk we call this like a general name connectivity and in that connectivity bucket we cover things like how to connect your on-prem to data center to on-prem and data center to a cloud and how to provide encryption, how to do routing on it and basically the entire connectivity package. So that's, I guess, good next step for us to talk about it and see how on-prem would work with your cloud, and under that, of course, we have our own bullet points 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 want to cover?

Kam: 10:53

yeah, absolutely so. One of the very first topics as soon as you get into cloud, one of the first questions that people ask and it really doesn't have anything to do with the interview yet, it's just pure engineering is well, I got this great cloud footprint and majority of customers? They are not cloud-only businesses. There are cloud-only businesses out there, but majority of customers probably I would say 95% they have something somewhere else, could be another cloud, could be somewhere on-prem in a data center or in one of your physical buildings, and they need some kind of connectivity between those three. At that point, there are two general options, a lot of different varieties, but two general options. One of them is create a tunnel, like the old way IPsec tunnel between your cloud and that other 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 we call dedicated connection. In the world of dedicated connections, depending on the vendor, well, they have different names Oracle, we call it Fast Connect, amazon Direct Connect. You have ExpressRoute with Microsoft, interconnect with GCP. At the end of the day, the difference between these two is always a good and interesting question and how you're able to articulate that or provide examples. Keep in mind IP Sec Tunnel. It's the traditional IPsec tunnel. It's exactly what it was.

Kam: 12:29

You're writing, writing a public internet. You're exposed to all the you know stuff that might happen in the internet. You're gonna have to deal with the latency. There's potential jitter, potential packet loss and all that. But guess what? If you know how to do it, you can quickly set this up in a matter of minutes. Bring it up and it's going to give you a decent connection, decent bandwidth, different types of bandwidth, different CSPs. But at the end of the day, it's a dirty and quick solution to connect your data center to the cloud or cloud to cloud. That works. That's a great solution that works. On top of that, it also has encryption. Some people, please go ahead.

Tim: 13:15

Yeah, it's also kind of universally supported for the most part. Right, ipsec is a very universally supported technology. Like you said, it's quick, it's dirty. It's kind of a lowest common denominator really for secure connectivity. That's very true, that's very true.

Kam: 13:28

That's very true, especially in cases like proof of concept. When we talk about the second one, I will show you why it's so important because in this case, you're not really making huge investments, so we're not talking about big capx. I don't have to make a capital investment here. I have a router, a firewall that supports the IPsec. We find some common parameters and bring up the IPsec tunnel between the two environments, and that works. However, most I would say, production environments. Today we're talking 2025, I personally recommend something better, and that better option is that dedicated solution. There are different ways to build that option. Is that dedicated solution. There are different ways to build that you could go in around the same data center, run Fiverr and be directly connected to that carrier, to that CSP. Yeah, that's one option and, of course, 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 to someone else. They provide that connection today. Some examples Equinix and Megaport for example yeah, Minimal.

Kam: 14:36

Oh yeah, they provide excellent connection and great bandwidth and all that. So that's another possibility. You have some kind of carrier in between might be AT&T, verizon, someone else, some kind of network. You use that network, ride it all the way to get to the CSP. That's another option. Either way, with that solution now you need to think about what you had previously with IPsecTown, which is encryption, and that's another nice question there. There are different options there and those options well, pretty much just like the traditional world.

Kam: 15:16

Yeah, you could run an IPSec tunnel, drop it somewhere inside your cloud environment. That's one option. Bring it in if the CSP supports termination of the IPSsec tunnel on the routing construct, for example, we do support it on our drg. Go all the way from your firewall or router, bring it all the way to our drg, which is something like aws, tgw, yeah, and terminated there. We terminate that terminal handle encryption for you. Or now, you remember we had all the problems with performance of IPSec. Ipsec is a high overload way of doing encryption. You don't want to do it. You want to see lighter and line rate encryption. Macsec is there, the challenge with MACsec, and I see this in production a lot, maybe, sometimes. Maybe it's a good interview question too. Macsec is that lightweight solution. However, still after all these years several years, I see I actually find it harder to set up MACSEC and find that you know the common that's true.

Kam: 16:24

Exactly the common parameters between the two, to bring up that connection, compared to what we have in IPsec.

Tim: 16:32

Well, and it's a single hop. It's a single hop encryption and 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, l3 between the two, it's not really an option. So you are cross-connect, it is an option. It's just a fiber who cares Most. Layer 2, these line connections, you could do MACSEC. But as you get into the bowels of your service provider and they start doing any kind of MPBGP within their network and all the L3, mpls, vpn, maxlack is 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 this is a more senior level role pros and cons. Architect's role is exactly what we just talked about, and especially if this is a more senior level role pros and cons. Architect's role is exactly what 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 kind of point out with either of these solutions whether we're talking about dedicated connectivity or IPsec VPNs solutions, whether we're talking about dedicated connectivity or IPsec VPNs is that you kind of really need to know the subtle differences 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 be different 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 it works in the cloud, because that's not always true, right. There's subtle things like termination points. There's behaviors like you know the cloud isn't going to initiate the tunnel for you. You always have to be on the initiation phase because you know they're providing a service Like it changes the way things operate right.

Tim: 18:23

Exactly. Oh, yeah, I mean, you use it. Basically, you are just like any managed service, right, you consume that service the way that the provider wants you to consume that service. Right, they might give you some options, but you're still locked into one of two, one of three options. Right, that's true.

Kam: 18:40

It's very true, very true. So that's a high level picture of this. But just imagine how embarrassing that situation could be. You are explaining to me as an interviewer that well, I have MACSEC, I have IPSEC, I have clear checks. Now my choice is IPSEC. I want to do IPSEC, for whatever reason, just like the ones that you described. Now my next question is could you 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 talking about IPSec, you need to know the details of it.

Kam: 19:16

Unrelated to this, I recommend the same thing for TLS and SSL stuff. Oh, for sure, if you want to talk 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 some time and find out how IPSec works, different phases and it's actually very handy Troubleshooting process. If you don't know how IPSec works, you can't do any troubleshooting. Same applies to MACsec and SSL and 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 got to be able to talk about key exchange, you got to be able to talk about algorithms and all of that, and, of course, on the TLS side, you need to understand certificate exchange and how signing 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 your environment and your cloud footprints. You can get into details and spend more time on key exchange and you know the whole concept of encryption, different options within PLS, maybe basics of how MPLS networks work, things like that. Connectivity in general. Just familiarize yourself with those terms, but that's not a really challenging topic. Connecting your on-prem whatever that is to the cloud provider or your cloud one to cloud two, yeah, so that kind of leads us to the next topic, and that next topic is well, now we have this connection in place, what is going on in that link? How do I route traffic? What are my options? And that's the. I guess there's more meat there to cover and there's more, of course, to learn.

Chris: 20:59

Yeah, for sure. So yeah, let's kind of break that open a bit. So I think we want to get into details about routing and BGP.

Kam: 21:07

Absolutely, absolutely. That's probably my favorite part of the interview because well, not because I know that well, because it's used in every single discussion, every single conversation with the customer. At some point you're going to have this conversation with them that, look, this is how routing works works. This is how traditionally it worked. This is now. It's done now. So let's just go back to, I guess, 20-25 years ago I promise I won't bore you, but routing in general, routing in general, when we wanted to learn routing and 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 traffic sent to this IP. Static routes, the next generation kind of one level up. I don't think many people remember 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 that CCI 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 is still there, right, static routing is still there. It's important. And the next chapter, the next sort of level, next conversation, one level up was IGP. People were talking about RIPv1, v1, rip, v2. Those two are not applicable today. I don't really see I maybe once a year I see the rip v2 somewhere. Always you defend ergrp, kind of important.

Kam: 22:42

Sometimes there is a little overlap between what cloud providers do and what you are doing on-prem. On-prem you have your own IGP running right. Might be OSPF or EIGRP I don't see a lot of ISIs, but some kind of IGP. And if you look at your border, the boundaries of your environment, you're doing many cases some kind of redistribution or export between those two and you're receiving routes from your IGP, sending the routes back to me, and we try not to get into details of what's going on in your IGP. So if you were going to work for a CSP, that's pretty much where your territory ends. That's your boundaries. You're not going to get into how their IGP works. However, there are cases when you're troubleshooting. You need to know why you're not seeing this route, why they're not seeing this route. You just trace it back. You get to the point where their IGP is not injecting the route into your BGP. Well, that's pretty much the extent of what you need to know about their IGP and your IGP if you work for that enterprise. So I'm not going to get into the details of IGP.

Kam: 23:54

I suppose someone who's studying BGP and knows BGP has already studied and spent some time on BGP. I guess that's a fair assumption. And then there is this giant topic of BGP. It used to be a lot bigger in traditional networking giant topic of BGP. It used to be a lot bigger in traditional networking. On the cloud side it's not as big.

Kam: 24:12

But let's get started and look at two different interview styles when it comes to BGP. One interview style one I guess direction that this could take is some people just take the traditional 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 those for inbound and outbound traffic and even sometimes aggregation. I've seen Vrata, fectors, confederation, the whole BGP package, and that's one way of covering this. The other way is focus on what the candidate needs for the cloud position and today 90, probably 5% of BGP is done around a few topics Inbound and outbound traffic. How to influence that traffic? Of course you have multiple connections. You want to prefer one over the other. That's one.

Tim: 25:12

Traffic insurance.

Kam: 25:13

Oh yeah, convergence is a good question. You have the timer, you have the whole BFT stuff and a little bit on troubleshooting. You need to know the attributes and 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 into details of, for example, ras reflectors. I'm not going to push you really hard. Do you know RFC 1966? Do you know RAS reflectors inside the Confederation, how they interact? That is not what I'm going to cover, at least from my perspective. That's not the fair scope. But let's take a quick look at what it means to be prepared for the routing interview.

Kam: 25:53

I remember and this is interesting because this goes back to probably I don't know over 15 years ago I had applied for a role. It was a network engineering position. Of course Someone called me. It was a recruiter. Recruiter called me. You know how the recruiter conversation is supposed to go. You pick up a phone and you talk how the recruiter conversation is supposed to go. You pick up the phone and you talk about the water. It's great. Thank you so much for applying for the role and tell us about yourself and your position, your title, why you're looking, what you're looking for and all kinds of things, right, your compensation. So right after greeting, she asked me all all right, can you name bgp optional attributes for a second? I thought I misheard her. Could you just repeat bgp optional, are you? Is this? Is this an interview? So we had those things we have. We had the recruiters try to filter out candidates right off the bat and they would ask those questions.

Kam: 26:50

That's kind of, I guess, bad way of surprising anyone yeah there was a better way and we would cover bgp a lot. Put you know nice scenario, like we'll talk about um. You're a network engineer, designer and you want to influence your traffic in mountain to your environment and let's talk about the MAD. Right, if you could explain to me why right now I'm configuring this, why I should use ASPath prepending and not MAD for the internet, well then it probably tells me. You know what transitive and non transitive concept works, that I'm gonna give you credit there. But if you just memorize which one is transitive, which one is non-transitive, probably that's not the most senior way. That's how I would approach this. So this was all about the traditional world.

Kam: 27:42

Today, when you look at this, let's just go back to what I was talking about how to influence traffic, inbound and outbound communities, your BGP attributes, how to improve your convergence time with timers and BFD. Bfd is an interesting topic, just like what we just talked about, ipsec, right, dropping names is not going to help you. So the fact that you know there is something called BFD that could help you, it's not going to help a lot. You want to know the messaging system. You want to know the details of BFT.

Kam: 28:14

There is a nanotalk. It's an old one I guess there might be a newer version of it and you can see details of BFT Capture packets. If you're in doubt, go in and capture packets and you will see how BFT works. Because at least when you're talking to me and you say I'm going to use BFD to improve my convergence time, that's the reason. Because 10, 15 years ago probably you could say well, I'm going to use BFD because a very aggressive timer is going to bump up my CPU. Today. That's not the reason. Today you do this to improve your half.

Tim: 28:49

Have sub-second conversions, so hang on a second.

Tim: 28:50

Yeah, so hang on a second. There's a couple things here, right? So bfd is a very interesting topic, with cloud specifically, because, of course, cloud being this hypervisor environment, um, often, even though you can use bfd to have like this kind of I wouldn't say sub-second, I think like one second is probably the best you're going to get with any provider is you can have this kind of I wouldn't say sub-second, I think one second is probably the best you're going to get with any provider. You can have this kind of failover, but the hyperplane often still doesn't necessarily react quickly enough to truly take use of BFD. It's BFD specifically.

Tim: 29:19

I'm not disagreeing with you, by the way. I know we're talking about technologies that matter and that is one that you can use with certain providers in certain situations, like you know, gcp or Google Cloud, you can use it with NCC. There's certain places you can use it. But I always thought it was kind of funny because for specifically for BFD, you think about like the data center use case or like the campus use case, where you're looking for sub-second convergence or failure detection and read it's just, you're not there. It's a you know, but I do think you still need to know it and I think it still is faster than traditional like BGP timers of 20 seconds or something like this, 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 you say TLS, ipsec or BFD, you know how they work. This is again interview with tech giants is not a configuration test. Last time we talked about this kind of half joking that when we took CCIE. Ccie was a config test. This is not a configuration exam. So the fact that you know BFD is the command is not going to help you. You need to know why and how. So theory is still very important around topics like how so theory is still very important around topics like BFD. And if you have time you want to learn more about BGP, absolutely go ahead and do it. But just for the scope of this and how it works in the context of cloud, keep in mind you are influencing your traffic. Whatever could be related to that absolutely important. Anything else extra topics would be nice to know. Agreed.

Chris: 30:52

Yeah, I think the thing is here. You can obviously deep dive on BGP and go very deep in the weeds on, like you said, doing things 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 around cloud, I think you really need to make sure you're paying attention to the nuance as far as what's available in cloud from that aspect right because, yeah, there's, there's multiple scenarios where, like you know, bgp is available, but maybe only um, only certain attributes are supported, right, you know there's certain communities, oh yeah, communities that are used Exactly.

Kam: 31:30

Oh yeah, communities.

Kam: 31:31

That's a really good point, even you know some CSPs do not use communities at all, do something else. So, as you know this, we're kind of entering territory where it's very cloud or CSP dependent. So it goes back to the importance of knowing job description, doing a little bit of research, gathering a little bit of intel. What kind of cloud provider are we talking about here? Most people that we interview I can't just speak for myself we know other cloud providers. So if your example is you're trying to use community, we might not support that community. That's still fine. We know which cloud provider you're talking about. But as you start talking to probably smaller businesses this is not TechGiant anymore or some picky interviewers you want to know more about which CSP you'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 this time. Exactly exactly so, that's the routing part of this. We covered connect connectivity, your options and encryption and how we route traffic. That kind of should conclude the second part of the second interview, if you will, and beyond this we're going to enter some other services that could be 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 the importance of building connectivity to and from the cloud using things like IPsec, vpn, direct dedicated connections as well, connections as well, and then the importance of you know kind of table stakes, routing constructs that are in use in a lot of traditional networks that have moved up to the cloud, and how they've changed a bit, the kind of main front runner being BGP, but static routes definitely live in the cloud very much so. So that's definitely not going any way. We've consolidated, but we still have the two major players still in play there, right, totally. So yeah, let's keep going.

Kam: 33:36

Exactly, exactly, just final points. You know, further study, if someone is interested, and topics like ECMP in the context of routing is still important.

Kam: 33:47

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 and ECMP by itself. What used to be pretty boggy people had to troubleshoot like am I getting kind of sort of similar traffic. Understand ECMP very well. Once again. It's not just I know ECMP, do I know how a cmp works. Yeah, and it goes back to the platform, and vendors at least know one platform. Familiarize yourself with how a cmp works on this platform as an interviewer. If you were able to explain that cmp to me and how it works on just one famous vendor, it's more 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 not ready for an interview with a tech giant. So just FYI. So ECMP, in this case we're talking 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 said that yeah, exactly, exactly. Oh yeah, I don't want to get questions. What was that thing? You're right, it is important. Oh yeah, thank you so much for reminding me. Yeah, no worries, cool. So we're sort of at the end of the 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 made it to the end of your second interview, like let's say that, and I and I, by the way, I really appreciate and agree with this, this thread that you've pulled throughout the story, which is don't focus on configs, don't focus on knowing timers of protocols, don't know, don't focus on knowing some shit that you could go ask Chad, gpt or Google in five seconds, right, understand the thing and why you would use it and when you would use it. That's the part you really need to care about because, at the end of the day, that's what you're going to be making decisions on.

Kam: 35:43

Oh, yeah, exactly, and not just that. At least I always appreciate a little background. In that background you had an experience 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 be part of your interview, most likely but when we talk about BFT in the OSPF context we come a long way to get this point. We had timers that we would change for hello and everything else, and then we ran into a problem with the hardware. Then we had a multiplier. We were able to send multiple hellos per second. That was one big step. And then BFT to solve that problem. And now here is the explanation of how BFT works.

Kam: 36:34

When someone walks me through this, this is seriously like 15, 20 years of time. This is the multiple generations of OSPF. I really appreciate it. So if you know any details, if you've seen them in production, you read about them, go ahead and use it. Do not hold it back. I would love to hear that. That shows me you have that depth and you spend time. You see multiple generations. Your knowledge is not limited to a simulation. It's just one particular scenario that you configured last week.

Chris: 37:01

All right. Well, if you have made it this far, I want to thank you very much for listening to part two of our series with Cam about how to interview for a tech giant. So we actually recorded this with cam as a three-part series. So, um, this was obviously part two and we will have part three coming up in the next few weeks. Um. So thanks, um once again for listening to the latest episode of the cables to clouds podcast. If you want to check out, um, our fortnightly news update, um, that is also available on our YouTube channel. There's also a link in the show notes with several news articles that we update on a fortnightly basis. If you want a link to a copy of Tim and I's book on the AWS certified advanced networking specialty 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.