|
22 Eargesplitten posted:I'm interviewing for a junior network administrator position on Friday. Is there any sort of list of "Know This poo poo" I should look at for networking? I have been studying for the CCNA, but I'm still on the CCENT section, so I don't know anything about (for example) Spanning Tree Protocol. Read through this - What happens when you go to Google
|
#
?
Oct 22, 2015 01:34
|
|
|
|
| # ? May 13, 2024 09:56 |
|
|
lampey posted:This is a surefire way to only end up hiring people exactly like the interviewer and excluding a ton of competent candidates. Try using open ended questions to find out what they know instead of focusing on if they know the specific answer you are looking for. There's a difference between expecting someone to know an obscure piece of information about an obscure piece of hardware, and expecting someone coming into a mid-level position (he mentioned ArcSight engineer, which is definitely not entry level) to know basic networking terminology.
|
|
#
?
Oct 22, 2015 02:06
|
|
|
Methanar posted:You and me both know what rfc 1918 You tell me. And the browser question was the only technical one I got in my most recent interview. It's a good question, signed a guy who works for a company that asks it
|
|
#
?
Oct 22, 2015 02:20
|
|
|
lampey posted:This is a surefire way to only end up hiring people exactly like the interviewer and excluding a ton of competent candidates. Try using open ended questions to find out what they know instead of focusing on if they know the specific answer you are looking for.
|
|
#
?
Oct 22, 2015 02:36
|
|
|
We've reached full goon. Complaining about someone asking technical questions in a technical interview.
|
|
#
?
Oct 22, 2015 02:41
|
|
|
Methanar posted:You and me both know what rfc 1918 is but still a very specific question to know offhand that doesn't mean a whole lot. This. The only RFC I actually know off the top of my head is the one in my name, but when I googled RFC1918(again, I do it every time I see it) I went 'Oh yeah, its that one!' e: Does knowing exactly which of the thousands of RFCs describes something somehow matter more than the actually content of the RFC for some reason? RFC2324 fucked around with this message at 02:56 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 02:53
|
|
|
Okay yes if you're specifically asking what RFC 1918 is then that's kind of dumb, but asking what the RFC 1918 private addresses are is not unreasonable. e: To be fair, I have seen RFC 1918 specifically referenced in documentation plenty of times. Like, without any actual indication as to what it is aside from contextual clues.
|
|
#
?
Oct 22, 2015 03:00
|
|
|
RFC2324 posted:This. The only RFC I actually know off the top of my head is the one in my name, but when I googled RFC1918(again, I do it every time I see it) I went 'Oh yeah, its that one!' I was 99% sure I knew what it was but I googled it anyway in the interest of not looking stupid on the internet. Roargasm posted:You tell me. I just think understanding the concepts of private addressing space is more important than knowing which document defined them. If I want to read about vxlans I'm going to google "vxlan rfc" and not RFC7348 quote:e: To be fair, I have seen RFC 1918 specifically referenced in documentation plenty of times. Like, without any actual indication as to what it is aside from contextual clues. You're right. I have too. Methanar fucked around with this message at 03:04 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 03:01
|
|
|
psydude posted:e: To be fair, I have seen RFC 1918 specifically referenced in documentation plenty of times. Like, without any actual indication as to what it is aside from contextual clues.
|
|
#
?
Oct 22, 2015 03:25
|
|
|
psydude posted:Know basic networking. What's a frame? What's a packet? Where do they fit on the OSI model? What is the OSI model? What's a MAC address and an IP address? What are the 3 RFC1918 private address spaces? How does a layer 3 device resolve a MAC address to an IP address and vice versa? How does a packet move through a network? What are different types of network devices and what do they do? What's a routing protocol? What's a route? What's NAT? I know most of those, knew some of them but forgot them, and there were a couple I don't know, so thanks. I'm more confident with the systems administrator stuff, I do a lot more with that in my current role than networking. I didn't know what RFC1918 was either, though. I could guess from you saying private addresses, but it also occurs to me I've forgotten where the 172.x.x.x private addresses start so I need to work on that too.
|
|
#
?
Oct 22, 2015 03:29
|
|
|
Vulture Culture posted:And from that moment forward you were never allowed to reference it to see what it referred to. Well no poo poo, but my point is that it's not some esoteric piece of information that you'll never come across. It's used in common parlance to refer to private address space. I don't care if a junior level person can give me the RFC, but I do expect them to be able to explain what a private address is, what its limitations are, and how it is integrated into public address space. psydude fucked around with this message at 03:37 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 03:34
|
|
|
RFC2324 posted:Does knowing exactly which of the thousands of RFCs describes something somehow matter more than the actually content of the RFC for some reason? Back in college, the prof who taught modern physics intro (250-something; all the stuff since Einstein basically) thought it would be a good idea for the midterm to consist of 70%questions formulated: ___ author wrote a paper in ___ year titled <actual title> that was principally about : <checkboxes that heavily overlap and contradict>. He was literally the worst-rated instructor on the entire university of some 1700 academic staff. If you're asking history questions that can be answered by machine learning tools in a tech interview, you're doing it wrong. If you're asking how to apply those technologies to deal with problems and especially around the boundaries where those techs stop working well, you're doing it right. Instead of asking about RFC1918, ask why IPv6 abhors private addressing (but be prepared for their opinion to differ from yours).
|
|
#
?
Oct 22, 2015 03:39
|
|
|
keseph posted:ask why IPv6 abhors private addressing (but be prepared for their opinion to differ from yours). I don't know much at all about IPv6, can you actually answer this one? Or even better, can we get multiple answers?
|
|
#
?
Oct 22, 2015 03:55
|
|
|
RFC2324 posted:I don't know much at all about IPv6, can you actually answer this one? Or even better, can we get multiple answers? Bit of history involved. NAT sucks and was a stop gap measure to prevent the exhaustion of ipv4. It breaks the original intended philosophy of IP connectivity being end-to-end. When you've got NAT between you and a destination, the TCP session or whatever is actually going on between the public server and your NAT device, usually the firewall. The public server can't address the end user so it speaks to the NAT device on the end user's behalf and the NAT says "by the way this is for you" to pass it along. Ipv6 has enough unique addresses that everyone on earth could have a /8 no problem so that solves the original issue that prompted NAT's adoption. There has been a bit of back and forth on whether or not ipv6 actually will use NAT. Originally it was no and then it was yes and it was backpedalled to no. I'm not sure where it ended up or really what the argument was for keeping it other than people got comfortable with the idea of private addressing. There is a bit about converting ipv6 addresses to ipv4 addresses with NAT64 for when an IPv6 packet needs to traverse over a legacy network that doesn't support ipv6, too. I'm not really sure how this works or what the routing implications of it are but it's out there. You could maybe argue that NAT is useful for concealing whats inside your network but it's really not. Just because an IP is theoretically routable doesn't mean you can get to it, that's what firewalls and routers are for. This applies to ipv4 and ipv6, MIT likely has a ton of mundane stuff in their /8. That doesn't mean you can start doing whatever you want to anything that may be in that range. Methanar fucked around with this message at 04:40 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 04:16
|
|
|
Methanar posted:Bit of history involved. NAT sucks and was a stop gap measure to prevent the exhaustion of ipv4. It breaks the original intended philosophy of IP connectivity being end-to-end. So its not actually a technical question, but rather one of design philosophy.
|
|
#
?
Oct 22, 2015 04:56
|
|
|
RFC2324 posted:So its not actually a technical question, but rather one of design philosophy. Having EVERYTHING be publicly routable is going to be important when the internet of things kicks in. Your toilet or whatever is going to be communicating with apple's iShit servers regarding your fiber intake which is going to communicate with your wifi enabled slippers, tea kettle etc.
|
|
#
?
Oct 22, 2015 05:17
|
|
|
NAT is an excellent example of security by obscurity and it does help, regardless of whether you should rely on that or not.
|
|
#
?
Oct 22, 2015 05:21
|
|
|
Work gave us a /64 to play with for our datacenter and I'm going to see if I can get a /48 so that I can get SLAAC going. Even if I don't get it, whatever, okay, I still have a /64 for our datacenter. One of the guys in the team I supported was worried that I should make sure I split this out to have enough networks for our datacenter. If I divide it out into multiple /80 subnets, I'll end up with 65,536 networks with 281 trillion hosts per network. I told him that and yeah, I think we'd be okay.
|
|
#
?
Oct 22, 2015 05:23
|
|
|
Methanar posted:Having EVERYTHING be publicly routable is going to be important when the internet of things kicks in. Your toilet or whatever is going to be communicating with apple's iShit servers regarding your fiber intake which is going to communicate with your wifi enabled slippers, tea kettle etc. Conversely, I don't really want anyone that isn't directly attached to my network talking to my toilet because I can't trust the toilet vendor to not leave 120 ports, including telnet and an SSHv1 server, open. NAT is pretty convenient poor man's firewall. adorai posted:NAT is an excellent example of security by obscurity and it does help, regardless of whether you should rely on that or not. This.
|
|
#
?
Oct 22, 2015 05:25
|
|
|
NeuralSpark posted:Conversely, I don't really want anyone that isn't directly attached to my network talking to my toilet because I can't trust the toilet vendor to not leave 120 sharts, including stoolnet and an SSH1T server, open. SHAT is pretty convenient poop man's fartwall. It's the scotch talking. Yes, that's it.
|
|
#
?
Oct 22, 2015 05:46
|
|
|
adorai posted:NAT is an excellent example of security by obscurity and it does help, regardless of whether you should rely on that or not. I'm going to miss making obscure personal jokes out of my subnets. For a long time every network I made was named after one of the old 'cheap long distance!' codes, like 10.10.220.x e: original subnet name was not actually valid, fixed to one I used that was valid.
|
|
#
?
Oct 22, 2015 06:02
|
|
|
Sometimes I flat-out don't want a stranger on the Internet knowing how many of my systems behind the same IP are not, in fact, the same system.
|
|
#
?
Oct 22, 2015 06:07
|
|
|
Let me know if there is a "dumb IT questions" thread I should be asking this in instead. How does the routing device performing NAT know which device on the internal network traffic is for? I know it keeps track of connections but suppose there are two goons on the same network. How does the router know which one should get the FYAD page and which the YOSPOS? Especially since presumably there is a router performing NAT on the other side as well. Or am I over thinking it for my level of knowledge?
|
|
#
?
Oct 22, 2015 06:43
|
|
|
22 Eargesplitten posted:Let me know if there is a "dumb IT questions" thread I should be asking this in instead. How does the routing device performing NAT know which device on the internal network traffic is for? I know it keeps track of connections but suppose there are two goons on the same network. How does the router know which one should get the FYAD page and which the YOSPOS? Especially since presumably there is a router performing NAT on the other side as well. Or am I over thinking it for my level of knowledge? It maintains session information, as I understand. When you request your FYAD page, the connection stays open until the page is loaded, and so that is a separate connection than your buddy loading up YOSPOS.
|
|
#
?
Oct 22, 2015 06:46
|
|
|
22 Eargesplitten posted:Let me know if there is a "dumb IT questions" thread I should be asking this in instead. How does the routing device performing NAT know which device on the internal network traffic is for? I know it keeps track of connections but suppose there are two goons on the same network. How does the router know which one should get the FYAD page and which the YOSPOS? Especially since presumably there is a router performing NAT on the other side as well. Or am I over thinking it for my level of knowledge? http://blog.boson.com/bid/53313/NAT-and-PAT-What-s-the-Difference Port numbers are used by the NAT device to uniquely identify each user behind NAT. This keeps track of what belongs to who.
|
|
#
?
Oct 22, 2015 06:54
|
|
|
RFC2324 posted:When you request your FYAD page, the connection stays open until the page is loaded, and so that is a separate connection than your buddy loading up YOSPOS. The session information stored is port mapping information on the external interface. EDIT: Link explains it better
|
|
#
?
Oct 22, 2015 06:57
|
|
|
That is so much simpler than I was thinking, but it makes sense. E: from that link, is NAT with IP masquerading the same thing as PAT? Because what I'm reading about NAT is that it's used in conjunction with masquerading to get more devices on the IPV4 network. 22 Eargesplitten fucked around with this message at 07:04 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 06:58
|
|
|
22 Eargesplitten posted:Let me know if there is a "dumb IT questions" thread I should be asking this in instead. How does the routing device performing NAT know which device on the internal network traffic is for? I know it keeps track of connections but suppose there are two goons on the same network. How does the router know which one should get the FYAD page and which the YOSPOS? Especially since presumably there is a router performing NAT on the other side as well. Or am I over thinking it for my level of knowledge? RFC2324 posted:It maintains session information, as I understand. When you request your FYAD page, the connection stays open until the page is loaded, and so that is a separate connection than your buddy loading up YOSPOS. Yep, the device inside the NAT initiates the IP connection to the server in the butt and that connection state is tracked on the NAT device. The NAT device, having visibility to the internal network, knows which machine made the connection requesting a FYAD page and which machine YOSPOS despite the fact that they are both hitting the same server on the outside. On the SA server side, both connections are coming from the same IP but there is different cookie and session information, so it can differentiate users (above and beyond the fact that the connections are requesting different pages).
|
|
#
?
Oct 22, 2015 07:00
|
|
|
Do people actually read RFCs and glean information from them? I've never really looked into RFCs - I understand they form the basis of the technology but I don't really read them to learn. Should I be? MC Fruit Stripe fucked around with this message at 07:07 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 07:03
|
|
|
Methanar posted:http://blog.boson.com/bid/53313/NAT-and-PAT-What-s-the-Difference 22 Eargesplitten posted:That is so much simpler than I was thinking, but it makes sense. So what we call NAT in most use cases is actually PAT, if I am reading this correctly? MC Fruit Stripe posted:Do people actually read RFCs and glean information from them? I usually think of the RFCs as the things I read if I want to learn how a thing works from an engineering perspective, but for actual implementation and troubleshooting I usually try to find something that approaches the issue from an implementation point of view. ie: RFC tells you how a thing works, but usually doesn't seem to tell you anything about how it breaks, or how to get it to a working state.
|
|
#
?
Oct 22, 2015 07:17
|
|
|
MC Fruit Stripe posted:Do people actually read RFCs and glean information from them? I suppose the most common use case, or at least the reason why I read RFCs, is I am doing packet-capture analysis and I want to verify that the network equipment is in fact conforming to RFC standards. I think every network engineer should understand the "common" RFCs - DHCP, ARP, IPv6, Multicast, STP (Shielded Twisted Pair, that is) etc. RFC2324 posted:So what we call NAT in most use cases is actually PAT, if I am reading this correctly? Essentially. It's referred to as NAT overload as well which is probably where the terms get mixed up. I'm probably the only network dude who loves NAT/PAT. Personally I think it's some pretty cool poo poo and has definitely helped me create some network wizardry/fuckery in the past with some pretty limited resources. skooky fucked around with this message at 07:48 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 07:42
|
|
|
skooky posted:Essentially. It's referred to as NAT overload as well which is probably where the terms get mixed up. I'm probably the only network dude who loves NAT/PAT. Personally I think it's some pretty cool poo poo and has definitely helped me create some network wizardry/fuckery in the past with some pretty limited resources. Any examples? PAT has some very obvious use cases but I'm curious what kinds of things NAT (the actual NAT) can be used for. fake e: Actually I think I'll just read through this article here.
|
|
#
?
Oct 22, 2015 08:06
|
|
|
Reiz posted:If you can handle the whole immigration thing, I know a couple of people chomping at the bit to do that Exact Job for like $40k usd. Pretty strange that there aren't people like that in the UK. Yeah if you can deal with immigration I'd pick this job up. In the middle of making a career switch so I dont mind getting stuck with a poo poo role for now, but I'm not dumb and I'm actively teaching myself everything I come accross and picking up certs as I go.
|
|
#
?
Oct 22, 2015 11:33
|
|
|
MC Fruit Stripe posted:Do people actually read RFCs and glean information from them? Yeah. I've read the RFC for MPLS and MP BGP. They're actually full of useful information.
|
|
#
?
Oct 22, 2015 12:00
|
|
|
NAT and PAT isn't really difficult. The router stores the original packet information in a lookup table in memory and rewrites the packets with another source/destination adress and/or source/destination port. When the reply packets come in it checks the lookup table and rewrites the packets again so they reach the original sender.
|
|
#
?
Oct 22, 2015 12:32
|
|
|
Gothmog1065 posted:I know there's a bunch of goons who work on Epic, and our hospital is in the preliminary phases of moving to Epic. I want to kind of be ahead of the game, is there anywhere to talk to goons about it? Their certifications standards and whatnot? Ask in the Madison, WI thread. http://forums.somethingawful.com/showthread.php?threadid=2339359
|
|
#
?
Oct 22, 2015 13:17
|
|
|
Garrand posted:Any examples? PAT has some very obvious use cases but I'm curious what kinds of things NAT (the actual NAT) can be used for. Two of the most common uses of NAT that I run in into are: A: Port forwarding, where you say "hey! router! if any traffic comes to our public IP 5.5.5.5 on port 80, leave the source IP and source/dest ports alone, but translate the destination IP to $WEBSERVER's IP 192.168.200.52" After it's translated, your router (hopefully) says "hey! I have a route to 192.168.200.52" and so the web traffic is sent there. The return packets sent back out your outif are translated back to the source IP of 5.5.5.5 and everything is groovy. B: Transparent web proxies, where port 80 traffic on your network is translated to port 8080 which your proxy service is listening on. It does its proxy magic, then sends the traffic on out to the internet. There are variations on the port forwarding like, let's say you want to have multiple hosts behind your one public IP accessible via RDP from the internet for some reason. You can tell the router to watch for inbound traffic to 5.5.5.5 on port 9380 and translate that to have a destination IP of 192.168.234.21 and destination port 3389. Then you can say inbound traffic on 9381 is translated to .22 on port 3389, etc.
|
|
#
?
Oct 22, 2015 13:32
|
|
|
NeuralSpark posted:Conversely, I don't really want anyone that isn't directly attached to my network talking to my toilet because I can't trust the toilet vendor to not leave 120 ports, including telnet and an SSHv1 server, open. NAT is pretty convenient poor man's firewall. This is what scares me "about the Internet of things". What if my toilet vendor does a poor job of securing it and leaves a bunch of ports open. I'm assuming in this future the toilet will have advanced bidet and comfort controls. Hackers could be monitoring my poo poo for information to blackmail me with or know when I'm about to drop trow and am at my most vulnerable. Or they could spray me with water thats to fast and hot and I could injure my turd cutter. This isnt the future I signed up for! BaseballPCHiker fucked around with this message at 15:29 on Oct 22, 2015 |
|
#
?
Oct 22, 2015 13:41
|
|
|
IPv6 eliminates the need for NAT, but not firewalls. Just make sure your cybertoilet is behind a quality home firewall. Hopefully one will exist by then. I'm more worried about not being able to flush until I install updates 
|
|
#
?
Oct 22, 2015 14:08
|
|
|
|
| # ? May 13, 2024 09:56 |
|
|
Security is defense in depth. Removing layers will always make it weaker. It's pretty much that simple. Firewalls are good. "I have a firewall so NAT doesn't offer anything" is tough, though. Better to have both sometimes. I like having publicly routable stuff, but it's a huge annoyance to worry about edge firewalls along with client firewalls, and whether whatever API I'm hitting actually talks ipv6 and sees some address that isn't in a security group. That'll probably get better as adoption slowly picks up.
|
|
#
?
Oct 22, 2015 14:47
|
|