Re: job screening question
Isn't MTU discovery on IP and not TCP? On Thu, Jul 5, 2012 at 11:11 AM, Oliver Garraux <oliver@g.garraux.net>wrote:
Seems fairly straightforward to me. It'll break path MTU discovery.
I would hope someone applying for an "IP expert" position would know that.
Could HR be mangling the question or something?
Oliver
-------------------------------------
Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux
On Thu, Jul 5, 2012 at 1:02 PM, William Herrin <bill@herrin.us> wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. *What* *part of the TCP protocol (not IP in general, TCP specifically)* *malfunctions as a result?*
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- Copyright 2012 Derek Andrew (excluding quotations) +1 306 966 4808 ICT University of Saskatchewan Peterson 120; 105 North Road Saskatoon,Saskatchewan,Canada. S7N 4L5 Timezone GMT-6 Typed but not read. [image: Description: Description: Description: Description: Description: cid:image002.png@01CCD52C.EA7400D0] <http://www.usask.ca/> --
On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
Isn't MTU discovery on IP and not TCP?
If you want to overthink the question, the failure in the TCP protocol is that it doesn't adjust the MSS to match the path MTU. It continues to rely on the incorrect path MTU estimate, sending too-large packets which will never arrive. This happens because TCP doesn't receive a notification that the path MTU estimate has changed from the default because the lower layer PMTUD algorithm never receives the expected ICMP packet. This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821. The less precise answer, path MTU discovery breaks, is just fine. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
From: William Herrin <bill@herrin.us> Subject: Re: job screening question To: "Derek Andrew" <Derek.Andrew@usask.ca> Cc: "nanog@nanog.org" <nanog@nanog.org> Date: Thursday, July 5, 2012, 3:18 PM On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
Isn't MTU discovery on IP and not TCP?
If you want to overthink the question, the failure in the TCP protocol is that it doesn't adjust the MSS to match the path MTU. It continues to rely on the incorrect path MTU estimate, sending too-large packets which will never arrive. This happens because TCP doesn't receive a notification that the path MTU estimate has changed from the default because the lower layer PMTUD algorithm never receives the expected ICMP packet.
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine.
Regards, Bill Herrin
Precisely! and if I understand correctly, a non-techinical person within HR is expected to hear this answer and relay it to you? That is more than a long shot. Unless of course they have photographic memories, are great typists or perhaps do "short hand". ./Randy
On Thu, Jul 5, 2012 at 7:01 PM, Randy <randy_94108@yahoo.com> wrote:
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
The less precise answer, path MTU discovery breaks, is just fine.
Precisely! and if I understand correctly, a non-techinical person within HR is expected to hear this answer and relay it to you? That is more than a long shot. Unless of course they have photographic memories, are great typists or perhaps do "short hand".
So I get a garbled answer about disk fragmentation. I can't tell the difference between an answer garbled in transit and an answer that was flat wrong to begin with? The point of the question is to help me decide which people I want to spend half an hour on the phone with and which ones get a polite thank-you-not-it from HR while I do the parts of my job that don't involve interviewing folks. If there's any doubt about whether they belong in the not-it category, they proceed to the phone interview. Regards, Bill Herrin P.S. Yes, I got an answer about "degrading DNS port unreachables and MTU disk fragmenting as well." I asked HR to set up a phone interview. If that wasn't an HR garble, I *really* want to hear the explanation. :D -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jul 5, 2012, at 6:09 PM, William Herrin wrote:
On Thu, Jul 5, 2012 at 7:01 PM, Randy <randy_94108@yahoo.com> wrote:
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
The less precise answer, path MTU discovery breaks, is just fine.
Precisely! and if I understand correctly, a non-techinical person within HR is expected to hear this answer and relay it to you? That is more than a long shot. Unless of course they have photographic memories, are great typists or perhaps do "short hand".
So I get a garbled answer about disk fragmentation. I can't tell the difference between an answer garbled in transit and an answer that was flat wrong to begin with?
I suspect this was a candidate answer about "Packet Fragmentation" (e.g. the answer you were looking for) and that your HR might have translated "packet" into "disk" because that's the only place they've heard of fragmentation.
The point of the question is to help me decide which people I want to spend half an hour on the phone with and which ones get a polite thank-you-not-it from HR while I do the parts of my job that don't involve interviewing folks. If there's any doubt about whether they belong in the not-it category, they proceed to the phone interview.
Makes sense, but, the example garbled answer you provided seems entirely legitimate to me.
Regards, Bill Herrin
P.S. Yes, I got an answer about "degrading DNS port unreachables and MTU disk fragmenting as well." I asked HR to set up a phone interview. If that wasn't an HR garble, I *really* want to hear the explanation. :D
Yep... Pretty sure that everything you listed here so far would be an HR garble of a legitimately correct (within your parameters) answer. Owen
Geez, I'd be happy to find someone with a good attitude, a solid work ethic, and the desire and aptitude to learn. :) Jason On 7/5/2012 5:18 PM, William Herrin wrote:
On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result? Isn't MTU discovery on IP and not TCP? If you want to overthink the question, the failure in the TCP protocol is that it doesn't adjust the MSS to match the path MTU. It continues to rely on the incorrect path MTU estimate, sending too-large packets which will never arrive. This happens because TCP doesn't receive a notification that the path MTU estimate has changed from the default because the lower layer PMTUD algorithm never receives the expected ICMP packet.
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Something tells me you're suddenly going to find yourself with an influx of correct answers... On Thu, Jul 5, 2012 at 3:18 PM, William Herrin <bill@herrin.us> wrote:
On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
Isn't MTU discovery on IP and not TCP?
If you want to overthink the question, the failure in the TCP protocol is that it doesn't adjust the MSS to match the path MTU. It continues to rely on the incorrect path MTU estimate, sending too-large packets which will never arrive. This happens because TCP doesn't receive a notification that the path MTU estimate has changed from the default because the lower layer PMTUD algorithm never receives the expected ICMP packet.
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
He'll have to come up with another weedout question, like "what's a /27?" I'm constantly amazed/disappointed when we interview candidates for a senior Linux admin job and they just don't know modern networking at all. Even better question, with multiple right answers, "how many IPs are in a /32?" You could probably have some fun with most applicants[1] when they answer 1, and then you ask "would you like to expand on that answer?" The small (sub /24) subnets are dealt with so frequently in an ISP/hosting provider environment, that IMO, anyone claiming to have experience in such an environment should just flat out know how many IPs and the subnet masks for /32 - /24 in IPv4, or be sufficiently comfortable with subnetting that they can figure these things out quickly enough to avoid awkward pauses during the interview if asked about them. 1) At least the few who get it right. On Thu, 5 Jul 2012, Mike Hale wrote:
Something tells me you're suddenly going to find yourself with an influx of correct answers...
On Thu, Jul 5, 2012 at 3:18 PM, William Herrin <bill@herrin.us> wrote:
On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
Isn't MTU discovery on IP and not TCP?
If you want to overthink the question, the failure in the TCP protocol is that it doesn't adjust the MSS to match the path MTU. It continues to rely on the incorrect path MTU estimate, sending too-large packets which will never arrive. This happens because TCP doesn't receive a notification that the path MTU estimate has changed from the default because the lower layer PMTUD algorithm never receives the expected ICMP packet.
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
I would use questions such as the following: 1. How many end-sites can be numbered from a single /32. (Correct answers: IPv4 - 1, IPv6 - 65,536) 2. In what circumstance might you need to use IPSEC to secure OSPF instead of MD5 authentication? 3. How many /32s can be created from a single /24? (Hint, this answer is the same for IPv4 and IPv6) 4. What is the purpose of an IP address such as ::ffff:192.0.2.123? 5. What is the reason for the 100m distance limit within an ethernet collision domain? The essay questions can wait for the interview if they get past these basics. Owen On Jul 5, 2012, at 5:14 PM, Jon Lewis wrote:
He'll have to come up with another weedout question, like "what's a /27?" I'm constantly amazed/disappointed when we interview candidates for a senior Linux admin job and they just don't know modern networking at all.
Even better question, with multiple right answers, "how many IPs are in a /32?" You could probably have some fun with most applicants[1] when they answer 1, and then you ask "would you like to expand on that answer?"
The small (sub /24) subnets are dealt with so frequently in an ISP/hosting provider environment, that IMO, anyone claiming to have experience in such an environment should just flat out know how many IPs and the subnet masks for /32 - /24 in IPv4, or be sufficiently comfortable with subnetting that they can figure these things out quickly enough to avoid awkward pauses during the interview if asked about them.
1) At least the few who get it right.
On Thu, 5 Jul 2012, Mike Hale wrote:
Something tells me you're suddenly going to find yourself with an influx of correct answers...
On Thu, Jul 5, 2012 at 3:18 PM, William Herrin <bill@herrin.us> wrote:
On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
Isn't MTU discovery on IP and not TCP?
If you want to overthink the question, the failure in the TCP protocol is that it doesn't adjust the MSS to match the path MTU. It continues to rely on the incorrect path MTU estimate, sending too-large packets which will never arrive. This happens because TCP doesn't receive a notification that the path MTU estimate has changed from the default because the lower layer PMTUD algorithm never receives the expected ICMP packet.
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, Jul 5, 2012 at 8:22 PM, Owen DeLong <owen@delong.com> wrote:
I would use questions such as the following:
1. How many end-sites can be numbered from a single /32. (Correct answers: IPv4 - 1, IPv6 - 65,536)
IPv6 - 16,777,216 to 268,435,456 :p
5. What is the reason for the 100m distance limit within an ethernet collision domain?
What's an ethernet collision domain? Seriously, when was the last time you dealt with a half duplex ethernet? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jul 5, 2012, at 5:32 PM, William Herrin <bill@herrin.us> wrote:
5. What is the reason for the 100m distance limit within an ethernet collision domain?
What's an ethernet collision domain? Seriously, when was the last time you dealt with a half duplex ethernet?
Last time I built a cluster; admin and some redundant ingress/egress methods do better with hubs than switches. Also last time I had to build a cheap redundant firewall. This is a corner case, but if you just know ether as a point to point it will eventually bite you. Having some spanning tree clue is much more relevant now, though. George William Herbert Sent from my iPhone
On Thu, 5 Jul 2012, William Herrin wrote:
On Thu, Jul 5, 2012 at 8:22 PM, Owen DeLong <owen@delong.com> wrote:
I would use questions such as the following:
1. How many end-sites can be numbered from a single /32. (Correct answers: IPv4 - 1, IPv6 - 65,536)
IPv6 - 16,777,216 to 268,435,456 :p
5. What is the reason for the 100m distance limit within an ethernet collision domain?
What's an ethernet collision domain? Seriously, when was the last time you dealt with a half duplex ethernet?
You've never (much less recently) seen a customer misconfigure their end of an ethernet handoff such that you end up with duplex mismatch? Granted, in that case, distance is irrelevant...but it is half half-duplex ethernet :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, Jul 5, 2012 at 9:28 PM, Jon Lewis <jlewis@lewis.org> wrote:
You've never (much less recently) seen a customer misconfigure their end of an ethernet handoff such that you end up with duplex mismatch? Granted, in that case, distance is irrelevant...but it is half half-duplex ethernet :)
If I was asking an ethernet question, I'd rather ask: 1. How do you make a crossover ethernet cable to connect two switches? (cross the green and orange pairs) 2. What happens if you plug that cable into a pair of gigabit ethernet switches? (mdix malfunctions, ports negotiate to 100 full, on some poorly implemented switches the mix of straight and crossed wires eventually damage the ports so they can no longer do gige) Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
From: William Herrin <bill@herrin.us> Subject: Re: job screening question To: "Jon Lewis" <jlewis@lewis.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Date: Thursday, July 5, 2012, 6:43 PM On Thu, Jul 5, 2012 at 9:28 PM, Jon Lewis <jlewis@lewis.org> wrote:
You've never (much less recently) seen a customer misconfigure their end of an ethernet handoff such that you end up with duplex mismatch? Granted, in that case, distance is irrelevant...but it is half half-duplex ethernet :)
If I was asking an ethernet question, I'd rather ask:
1. How do you make a crossover ethernet cable to connect two switches? (cross the green and orange pairs)
2. What happens if you plug that cable into a pair of gigabit ethernet switches? (mdix malfunctions, ports negotiate to 100 full, on some poorly implemented switches the mix of straight and crossed wires eventually damage the ports so they can no longer do gige)
Regards, Bill Herrin
Or for that matter, in the absence of auto-MDI/MDIX: 1) when is a straight-through cable *required*? 2) when is a cross-over cable *required*? How about another HR-Question: what do 0.0.0.0/1 and 128.0.0.0.0/1 as static-routes accomplish? ./Randy
On 7/6/12 2:10 AM, "Randy" <randy_94108@yahoo.com> wrote:
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
From: William Herrin <bill@herrin.us> Subject: Re: job screening question To: "Jon Lewis" <jlewis@lewis.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Date: Thursday, July 5, 2012, 6:43 PM On Thu, Jul 5, 2012 at 9:28 PM, Jon Lewis <jlewis@lewis.org> wrote:
You've never (much less recently) seen a customer misconfigure their end of an ethernet handoff such that you end up with duplex mismatch? Granted, in that case, distance is irrelevant...but it is half half-duplex ethernet :)
If I was asking an ethernet question, I'd rather ask:
1. How do you make a crossover ethernet cable to connect two switches? (cross the green and orange pairs)
2. What happens if you plug that cable into a pair of gigabit ethernet switches? (mdix malfunctions, ports negotiate to 100 full, on some poorly implemented switches the mix of straight and crossed wires eventually damage the ports so they can no longer do gige)
Regards, Bill Herrin
Or for that matter, in the absence of auto-MDI/MDIX:
1) when is a straight-through cable *required*? 2) when is a cross-over cable *required*?
How about another HR-Question:
what do 0.0.0.0/1 and 128.0.0.0.0/1 as static-routes accomplish?
./Randy
My favorite screening question at the moment is: What does a NULL-Route for 169.254.0.0/16 not fix on a Cisco router? Answer - Compliance with RFC 3927 because it doesn't fix the problem of a link-local source address. Answers that also mention proxy-ARP result in immediate interviews. --Dave
On Thu, Jul 5, 2012 at 10:10 PM, Randy <randy_94108@yahoo.com> wrote:
How about another HR-Question:
what do 0.0.0.0/1 and 128.0.0.0.0/1 as static-routes accomplish?
Override the dynamic (e.g. DHCP) default route. Often so you can implement a workaround that central Network Security wouldn't approve of. :-) Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
From: William Herrin <bill@herrin.us> Subject: Re: job screening question To: "Randy" <randy_94108@yahoo.com> Cc: "nanog@nanog.org" <nanog@nanog.org> Date: Thursday, July 5, 2012, 7:36 PM On Thu, Jul 5, 2012 at 10:10 PM, Randy <randy_94108@yahoo.com> wrote:
How about another HR-Question:
what do 0.0.0.0/1 and 128.0.0.0.0/1 as static-routes accomplish?
Override the dynamic (e.g. DHCP) default route. Often so you can implement a workaround that central Network Security wouldn't approve of. :-)
<smile> Yes of course! But NOT the "answer" I am looking for(..and want to hear..) because - 1) having such default-routes "internally" is a terribly-bad/broken idea. I am looking for a "candidate" who can actually say the same and go on to say: "it is a kludge that can be put in place to load-share between two links to upstreams when "budgetary-constraints" prevent us from anything but static-routing - two upstreams terminating on the same router. There You go: So, There are some questions (includes Your original-question) that HR should not be asking. There is a big difference between Engineering-Management and Management-Engineering.....(Morton Thiokol/Challenger is a classic case in point.) Regards, ./Randy
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Jul 5, 2012 at 10:10 PM, Randy <randy_94108@yahoo.com> wrote:
How about another HR-Question:
what do 0.0.0.0/1 and 128.0.0.0.0/1 as static-routes accomplish?
Nothing much. The first is half-assed and the second's a typo. El "do I get the job?" mar...
Aaawwe On Jul 5, 2012 7:10 PM, "Randy" <randy_94108@yahoo.com> wrote:
--- On Thu, 7/5/12, William Herrin <bill@herrin.us> wrote:
From: William Herrin <bill@herrin.us> Subject: Re: job screening question To: "Jon Lewis" <jlewis@lewis.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Date: Thursday, July 5, 2012, 6:43 PM On Thu, Jul 5, 2012 at 9:28 PM, Jon Lewis <jlewis@lewis.org> wrote:
You've never (much less recently) seen a customer misconfigure their end of an ethernet handoff such that you end up with duplex mismatch? Granted, in that case, distance is irrelevant...but it is half half-duplex ethernet :)
If I was asking an ethernet question, I'd rather ask:
1. How do you make a crossover ethernet cable to connect two switches? (cross the green and orange pairs)
2. What happens if you plug that cable into a pair of gigabit ethernet switches? (mdix malfunctions, ports negotiate to 100 full, on some poorly implemented switches the mix of straight and crossed wires eventually damage the ports so they can no longer do gige)
Regards, Bill Herrin
Or for that matter, in the absence of auto-MDI/MDIX:
1) when is a straight-through cable *required*? 2) when is a cross-over cable *required*?
How about another HR-Question:
what do 0.0.0.0/1 and 128.0.0.0.0/1 as static-routes accomplish?
./Randy
On Jul 5, 2012, at 6:28 PM, Jon Lewis wrote:
On Thu, 5 Jul 2012, William Herrin wrote:
On Thu, Jul 5, 2012 at 8:22 PM, Owen DeLong <owen@delong.com> wrote:
I would use questions such as the following:
1. How many end-sites can be numbered from a single /32. (Correct answers: IPv4 - 1, IPv6 - 65,536)
IPv6 - 16,777,216 to 268,435,456 :p
I'd accept those if I was willing to send the candidate to rational IPv6 networking re-education camp. If I expected the candidate to be able to do real work immediately, I would require the correct answer as specified above. Assigning a /56 to an end-site is bad juju. Assigning a /60 is pure useless evil.
5. What is the reason for the 100m distance limit within an ethernet collision domain?
What's an ethernet collision domain? Seriously, when was the last time you dealt with a half duplex ethernet?
You've never (much less recently) seen a customer misconfigure their end of an ethernet handoff such that you end up with duplex mismatch? Granted, in that case, distance is irrelevant...but it is half half-duplex ethernet :)
Either way, the collision domain itself is irrelevant to the question at hand... The important thing is to find out that the candidate understands what an ethernet pre-amble is and why it is important. Owen
In a message written on Thu, Jul 05, 2012 at 08:32:46PM -0400, William Herrin wrote:
What's an ethernet collision domain? Seriously, when was the last time you dealt with a half duplex ethernet?
5 segments 4 repeaters 3 segments with transmitting hosts 2 transit segments 1 collision domain If any employer thought that was useful knowledge for a job today I would probably run away, as fast as possible! -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thu, 05 Jul 2012 18:36:34 -0700, Leo Bicknell said:
If any employer thought that was useful knowledge for a job today I would probably run away, as fast as possible!
Only way I'd take that job is with both budget and authority to clean up the mess. However, those kind of things are usually politically messy enough that you don't want to be the FTE who does it - that's what consultants are for. :)
On Jul 5, 2012, at 18:32, William Herrin <bill@herrin.us> wrote:
On Thu, Jul 5, 2012 at 8:22 PM, Owen DeLong <owen@delong.com> wrote:
I would use questions such as the following:
1. How many end-sites can be numbered from a single /32. (Correct answers: IPv4 - 1, IPv6 - 65,536)
IPv6 - 16,777,216 to 268,435,456 :p
5. What is the reason for the 100m distance limit within an ethernet collision domain?
What's an ethernet collision domain? Seriously, when was the last time you dealt with a half duplex ethernet?
Today. Legacy devices still require half-duplex sometimes. Dave
William Herrin wrote:
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine.
I would say that the ability to quickly understand, troubleshoot and find a solution to a problem (and document it) is a far better skill to have than having ready made answers to interview questions learned by heart. It should take a skilled person less than 30 minutes to find the answer to that question and understand it too. The importance of knowing many things by heart has become incredibly moot. Greetings, Jeroen -- Earthquake Magnitude: 4.4 Date: Tuesday, July 10, 2012 04:06:53 UTC Location: Central Alaska Latitude: 63.4533; Longitude: -149.4308 Depth: 110.60 km
On Mon, 9 Jul 2012, Jeroen van Aart wrote:
William Herrin wrote:
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine. I would say that the ability to quickly understand, troubleshoot and find a solution to a problem (and document it) is a far better skill to have than having ready made answers to interview questions learned by heart.
It should take a skilled person less than 30 minutes to find the answer to that question and understand it too. The importance of knowing many things by heart has become incredibly moot.
If you are applying for a network position, you better know the *basics*. Having to look up the basics is not a good sign. Do you really want to hire someone who is going to have to look up basic networking concepts for 30 minutes every time they are in a meeting and asked a question? -Dan
On 07/10/2012 03:32 AM, goemon@anime.net wrote:
On Mon, 9 Jul 2012, Jeroen van Aart wrote:
William Herrin wrote:
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine. I would say that the ability to quickly understand, troubleshoot and find a solution to a problem (and document it) is a far better skill to have than having ready made answers to interview questions learned by heart.
It should take a skilled person less than 30 minutes to find the answer to that question and understand it too. The importance of knowing many things by heart has become incredibly moot. If you are applying for a network position, you better know the *basics*. Having to look up the basics is not a good sign.
Do you really want to hire someone who is going to have to look up basic networking concepts for 30 minutes every time they are in a meeting and asked a question?
-Dan
Hence the reason he mentioned "skilled" person...
On 7/10/12 6:56 AM, Bret Clark wrote:
Hence the reason he mentioned "skilled" person...
Right. A skilled person knows not to commit to anything in a meeting, or to at least validate what they think before they open their mouth. Depends on the audience, of course. At least in my environment, there is not an expectation for someone to be able to rattle off technical specifics from memory on demand - I've got an iPad and Google for that. General concepts and functionality/limitations/whatever are great in that setting, but no one asks for the level of detail that takes 30 minutes to research and digest in a meeting. The ability to remember obscure command line arguments, or parts of a protocol header don't have much value, when you can look it about 10 seconds. Anyone else noticed their memory has gotten worse since Google came along? :) David
I think Ivan covered that http://blog.ioshints.info/2012/03/knowledge-and-complexity.html And also about hiring in general http://blog.ioshints.info/2009/12/certifications-and-hiring-process.html Many says that everything happens in the first 5 minutes of interview, right chemistry if you like - the rest of the hiring process you're looking for reasons to hire the person you like or for the reasons to reject someone you don't like. On Tue, Jul 10, 2012 at 1:05 PM, David Coulson <david@davidcoulson.net> wrote:
On 7/10/12 6:56 AM, Bret Clark wrote:
Hence the reason he mentioned "skilled" person...
Right. A skilled person knows not to commit to anything in a meeting, or to at least validate what they think before they open their mouth. Depends on the audience, of course.
At least in my environment, there is not an expectation for someone to be able to rattle off technical specifics from memory on demand - I've got an iPad and Google for that. General concepts and functionality/limitations/whatever are great in that setting, but no one asks for the level of detail that takes 30 minutes to research and digest in a meeting. The ability to remember obscure command line arguments, or parts of a protocol header don't have much value, when you can look it about 10 seconds.
Anyone else noticed their memory has gotten worse since Google came along? :)
David
On 07/10/2012 03:56 AM, Bret Clark wrote:
On 07/10/2012 03:32 AM, goemon@anime.net wrote:
On Mon, 9 Jul 2012, Jeroen van Aart wrote:
William Herrin wrote:
This is, incidentally, is a detail I'd love for one of the candidates to offer in response to that question. Bonus points if you discuss MSS clamping and RFC 4821.
The less precise answer, path MTU discovery breaks, is just fine. I would say that the ability to quickly understand, troubleshoot and find a solution to a problem (and document it) is a far better skill to have than having ready made answers to interview questions learned by heart.
It should take a skilled person less than 30 minutes to find the answer to that question and understand it too. The importance of knowing many things by heart has become incredibly moot. If you are applying for a network position, you better know the *basics*. Having to look up the basics is not a good sign.
Do you really want to hire someone who is going to have to look up basic networking concepts for 30 minutes every time they are in a meeting and asked a question?
-Dan
Hence the reason he mentioned "skilled" person...
This all has to be tempered with the zeitgeist as what is "basic knowledge" now, will be "charming history" at some point. All of it. No, a vampire tap has nothing to do with Twilight. No, the difference between 74 and 54 series logic is not 20. All of us oldsters would do well to try to keep up with what's new and hip coming out of schools and grill them in an intelligent fashion. Better yet, let them teach you something which shows if they understand or whether they're just parroting stuff back. MIke
On Thu, 05 Jul 2012 15:05:01 -0600, Derek Andrew said:
Isn't MTU discovery on IP and not TCP?
AIX actually supported PMTUD for UDP. Not sure if it still does. Yes, it was bizarro even for AIX. No, I'm not aware of any actual UDP applications that were able to do anything useful with this info. ;)
On Jul 5, 2012, at 6:17 PM, valdis.kletnieks@vt.edu wrote:
On Thu, 05 Jul 2012 15:05:01 -0600, Derek Andrew said:
Isn't MTU discovery on IP and not TCP?
AIX actually supported PMTUD for UDP. Not sure if it still does. Yes, it was bizarro even for AIX. No, I'm not aware of any actual UDP applications that were able to do anything useful with this info. ;)
Think IPSEC NAT Traversal over UDP and/or Teredo. (Yes, Teredo is ugly and should be banned from any legitimate network, but...) Owen
participants (21)
-
Andriy Bilous -
Bjørn Mork -
Bret Clark -
David Casey -
David Coulson -
David Edelman -
Derek Andrew -
Elmar K. Bins -
George Herbert -
goemon＠anime.net -
Jason Baugher -
Jeroen van Aart -
Jon Lewis -
Leo Bicknell -
Michael Thomas -
Mike Hale -
Owen DeLong -
Ramanpreet Singh -
Randy -
valdis.kletnieks＠vt.edu -
William Herrin