Почему работает "Ping 127.227.327" или каверзные вопросы для собеседования

Предлагаю поделиться каверзными вопросами, которые Вы или Вам когда-либо задавались на собеседованиях.
Уверен, что все все знают, но кому-то будет интересно, что:
Сокращать IP адреса при записи придумали не в IPv6 и ping 127.127 спокойно будет присылать ответ.
Так же будет отвечать и ping 127.227.327 (да именно 327, я не опечатался).
Что произойдет, если запустить ping числа 2133333333? а 2139999999?
Зачем нужен wildcard? ведь уже и так есть netmask.
Тэги темы:
«1

Комментарии

  • У меня вот была подборочка.

    http://linkmeup.ru/blog/84.html
  • eucariot написал:

    У меня вот была подборочка.

    http://linkmeup.ru/blog/84.html

    Прикольные вопросы, помню, доставили много удовольствия.:) Даже что-то новое тогда узнал.

    Меня спрашивали, как работает утилита traceroute.
    И спрашивали, как в Port-Channel узнать, что один из линков не работает (я тогда не знал про Port-Channel, но догадался, что можно посылать по линкам пакеты и смотреть, придут ли).

    И ещё спрашивали алгоритм BGP Best path selection (на другом собеседовании).
  • Сколько аксес-листов можно навесить на один интерфейс в IOS-e?
    Какой номер порта надо закрыть чтоб перестал ходить пинг?
    Каким образом в трейсе задержка на более поздних хопах может быть меньше, чем на ранних?
  • Neolexus написал:


    Сокращать IP адреса при записи придумали не в IPv6 и ping 127.127 спокойно будет присылать ответ.

    Эм.. это не сокращение адреса а реализация команды ping. В rfc для v4 никаких сокращений.
    А так и ping 127.0000000000000000001.000000000127 будет работать, по крайней мере в nix.
  • MetallicAt написал:


    Какой номер порта надо закрыть чтоб перестал ходить пинг?

    Я так тролил с другой стороны - на какой порт приходит пинг ))

  • отредактировано марта 2016
    Neolexus написал:

    Предлагаю поделиться каверзными вопросами, которые Вы или Вам когда-либо задавались на собеседованиях.
    Уверен, что все все знают, но кому-то будет интересно, что:
    Сокращать IP адреса при записи придумали не в IPv6 и ping 127.127 спокойно будет присылать ответ.
    Так же будет отвечать и ping 127.227.327 (да именно 327, я не опечатался).
    Что произойдет, если запустить ping числа 2133333333? а 2139999999?
    Зачем нужен wildcard? ведь уже и так есть netmask.

    Прямо смутился при прочтении об адресе 127.227.327. Но таки чтение в RFC решает).
    Следующий на сколько я понял число в другой системе исчисления.
  • отредактировано марта 2016
    Всегда была интересна цель некоторых таких вопросов, особенно про пинг. :)
  • Archee написал:

    Всегда была интересна цель некоторых таких вопросов, особенно про пинг. :)

    Конкретно про пинг позволяет перестать тратить время на собеседование с неграмотными людьми.

    Неконкретно, все вопросы на подумать показывают как это самое подумать происходит и, всё же, иногда лучше жевать...
  • отредактировано марта 2016
    jedi написал:

    Archee написал:

    Всегда была интересна цель некоторых таких вопросов, особенно про пинг. :)

    jedi написал:

    MetallicAt написал:


    Какой номер порта надо закрыть чтоб перестал ходить пинг?

    Я так тролил с другой стороны - на какой порт приходит пинг ))

    Конкретно про пинг позволяет перестать тратить время на собеседование с неграмотными людьми.

    Неконкретно, все вопросы на подумать показывают как это самое подумать происходит и, всё же, иногда лучше жевать...
    А какой должен быть ответ?
    просто тут такое дело:







  • Любопытно про RFC 862.
    Насколько я понял это как раз про Echo Protocol что используется транспортный уровень UDP/TCP причем, я видел множество раз реализацию через UDP, а через TCP не встречал.
    Но, чаще под пингом понимают реализацию ICMP-echo
    В таком случае используется строго ICMP-протокол с type 0 и с type 8.
    Так действительно, о каком пинге идет речь?
  • отредактировано марта 2016
    Так в том-то и дело, что пингом всё подряд называют :) Уверен где-то есть пинг через HTTP. IRC тоже имеет Ping сообщение - см rfc2812
  • Про пинг опять: как работает пинг через PAT, если в ICMP нет портов?
  • EvgeniyHeine написал:

    Про пинг опять: как работает пинг через PAT, если в ICMP нет портов?

    О я даже не знаю точного ответа, поле Identifier?
  • EvgeniyHeine написал:

    Про пинг опять: как работает пинг через PAT, если в ICMP нет портов?

    Только что, опытным путем выяснил, что в заголовке ICMP протокола есть поле Identificator, которое используется в роли порта при осуществлении PAT трансляций.
  • Считаю подход с задаванием таких вопросов ошибочным. Это по сути не проверяет реальных навыков человека. Сможет ли инженер, который умеет отвечать на вопросы, обслуживать инфраструктуру для которой его берут? Помогут ли ему знания ответов на эти вопросы в этом? Мне кажется нет.

    Я считаю есть 2 хороших подхода к техническому собеседованию сетевого инженера:

    1) Человеку дается компьютер с лабой и ставится задача настроить какую-то топологию. Сложность топологии в зависимости от реальных задач конечноже, которые будут нужны инженеру. Если инженер будет работать с сетью предприятия то это могут быть всякие opsf, bgp, dmvpn и прочее. Сразу понятно сможет ли человек работать с имеющейся инфраструктурой или нет.

    2) Второй подход описан по ссылке: networkcomputing.com/cloud-infrastructure/4-must-ask-interview-questions-network-engineers/1812353780

    В кратце: инженеру нужно нарисовать часть сети, которой он занимался и рассказать как, что и зачем в ней работает. Так же можно задать пару вопросов по технологиям из резюме. Человек пишет, что знает BGP? Замечательно, пусть расскажет что это за протокол и какие задачи с помощью него можно решить.

    Пишу не ради холивара, просто считаю, что когда человек приходит в компанию рога и копыта работать за небольшие деньги с простенькой топологией, а его начинают грузить вопросами с собеседования в гугл "почему люки круглые" - это как-то немного неправильно и не честно по отношению к человеку получается. И велик шанс упустить хорошего инженера, который хочет развиваться и принесет много пользы предприятию.
  • mxssl написал:

    Считаю подход с задаванием таких вопросов ошибочным. Это по сути не проверяет реальных навыков человека. Сможет ли инженер, который умеет отвечать на вопросы, обслуживать инфраструктуру для которой его берут? Помогут ли ему знания ответов на эти вопросы в этом? Мне кажется нет.

    Полагаю, что каверзные вопросы не исключают основных. Разумеется, в первую очередь нужно понять, что кандидат готов к реальному миру и сети и справится с задачей сделать, как сказали.

    Вопросы же такого плана позволяют выявить глубину изучения темы и мышление.
    Понимаете, BGP и OSPF можно научиться настраивать, не прочитав ни одной книги. И даже разобраться в порядке установления соседства и прочего. Понять не стоит строить локальные сети на IBGP требует и почитать, и подумать, и лабу собрать.
    И если нужен сотрудник с перспективой или на позицию архитектора/дизайнера/в отдел развития, то лучше, чтобы необычные вопросы он или сам изучал или был готов их обработать.

    Но в целом да, пункт совсем не обязательный.

  • Очень зависит какого уровня ищется человек, и на какую позицию.
    Мне вот на позицию network QA задавали вопрос типа "в чем приемущества и недостатки радачи MPLSVPN-меток per-vrf перед per-prefix?". Человеку, который занимается продакшном такие вещи знать, по-моему, не обязательно. Хоть и совсем не помешает :)
    Каверзные вопросы выполняют еще одну "немаловажную" роль - они дают работодателю возможность повыпендриваться своими одноразово встреченными поломками, в которых виновата скорей фаза луны, чем что-то жестко техническое.
    По моему опыту, лучше всего работают вопросы, ответы на которые интервьюируемый заранее не знает, но понять в какую сторону стоит думать вполне может. Практически любая работа сетевого (да и не только) инженера состоит из попыток совладать с ситуациями, в которых он никогда не бывал. И этот скилл, к сожалению, проверяют далеко не так часто, как хотелось бы.
  • отредактировано марта 2016
    >> Мне вот на позицию network QA задавали вопрос типа "в чем приемущества и недостатки радачи MPLSVPN-меток per-vrf перед per-prefix?".

    С преимуществами всё понятно, а вот недостатков в решении раздавать метки per-vrf что-то не вижу. Не ясно - зачем раздавать per-prefix. VPN-метка нужна, чтобы легко решить, на какой интерфейс пробрасывать пакет в data-plane. Если в VRF пришло, допустим 3 префикса, зачем для каждого из них внутренняя метка, если все равно, все они будут сниматься, а пакет выбрасываться в один и тот же интерфейс? Если только для работы очередей в QoS? Но вроде бы возможностей EXP для этого должно хватить...
    Расскажите правильный ответ )).
  • отредактировано марта 2016
    Larchen написал:

    >> Мне вот на позицию network QA задавали вопрос типа "в чем приемущества и недостатки радачи MPLSVPN-меток per-vrf перед per-prefix?".

    С преимуществами всё понятно, а вот недостатков в решении раздавать метки per-vrf что-то не вижу. Не ясно - зачем раздавать per-prefix. VPN-метка нужна, чтобы легко решить, на какой интерфейс пробрасывать пакет в data-plane. Если в VRF пришло, допустим 3 префикса, зачем для каждого из них внутренняя метка, если все равно, все они будут сниматься, а пакет выбрасываться в один и тот же интерфейс? Если только для работы очередей в QoS? Но вроде бы возможностей EXP для этого должно хватить...
    Расскажите правильный ответ )).

    Реальный ответ только автор даст, он же вопрос задавал :)
    Вот без гугла сходу пришли в голову две ассоциации: BGP PIC и Load-balancing на P-уровне.
    Балансировка на основе MPLS "в коре" чаще всего делается только для non-ip трафика( обычно L3/L4), но бывает и так, что железка не может смотреть сильно глубоко и берёт нижний лейбл, чтобы не балансить по глубоко лежащему IP.
    Вы клёвые вопросы задаёте форуме, но я попросил бы выражаться яснее. К другим участникам это тоже относится, особенно если на собеседовании вам таки дали картинку.
  • >> Вы клёвые вопросы задаёте форуме, но я попросил бы выражаться яснее.

    Думал об этом, но это на самом деле трудно. Когда погружен в какой-то вопрос, находишься в его контексте, возникает иллюзия, что остальным тоже ясен этот контекст, хотя на самом деле это далеко не так.
  • отредактировано марта 2016
    >> Балансировка на основе MPLS "в коре"
    А разве "в коре" коммутация не по транспортной (внешней) метке?
    В смысле, для задач Load Balancing почему-бы не использовать RSVP-TE, не построить нужное количество TE-LSP по желаемым путям, и не балансить между ними на head-end'e? Зачем всем маршрутизаторам "в коре" спускаться от транспортной к VPN-метке?

    UPD: Есть что-нибудь хорошее, что можно почитать про эти вещи (балансировка по VPN-метке в коре)?
  • Larchen написал:

    >> Балансировка на основе MPLS "в коре"
    А разве "в коре" коммутация не по транспортной (внешней) метке?
    В смысле, для задач Load Balancing почему-бы не использовать RSVP-TE, не построить нужное количество TE-LSP по желаемым путям, и не балансить между ними на head-end'e? Зачем всем маршрутизаторам "в коре" спускаться от транспортной к VPN-метке?

    UPD: Есть что-нибудь хорошее, что можно почитать про эти вещи (балансировка по VPN-метке в коре)?

    Я имел в виду ECMP и баланс внутри LAG. Там берётся нижняя метка, так как она чаще всего уникальнее, чем транспортные.
    Например, vc-label будет у каждого l2vpn-клиента разный. Но если хочется ещё больше балансить, то есть fat-pw, который генерит фейковые метки на основе MAC или L3/L4, и ставит их в самый низ для балансировки в коре.
    Боюсь по балансировке только платформенное могу посоветовать, и только cisco.
  • Идею понял.
  • Если метка дана per-vrf то egress PE должен сделать 3 lookup-а - один по внешней метке, один по внутренней, и один по dest-ip. А если per-prefix, то последний lookup можно сэкономить, он уже не нужен (при условии, что forwarding table посотроен верно и может привязать egress interface прямиком к внутренней метке). Минус такого подхода - меньшая масштабируемость. Меток-то не бесконечное количество.
  • >> один по внешней метке,

    Обычно же включен режим PHP, внешняя удаляется на PHP-маршрутизаторе.

    >> один по внутренней,

    Рзаве LFIB на основе VPN-метки (которая после PHP стала внешней) не определяет все дальнейшие действия (POP, заголовок для формирования L2-фрейма и выходной интерфейс?
    Зачем делать lookup ещё и по IP? В случае, если в VRF множество интерфейсов? Не лучше ли тогда сделать несколько VRF, каждый со своим интерфейсом, внутренней меткой, идентификатором RD и политиками экспорта/импорта?
  • Larchen написал:

    >> один по внешней метке,

    Обычно же включен режим PHP, внешняя удаляется на PHP-маршрутизаторе.

    >> один по внутренней,

    Рзаве LFIB на основе VPN-метки (которая после PHP стала внешней) не определяет все дальнейшие действия (POP, заголовок для формирования L2-фрейма и выходной интерфейс?
    Зачем делать lookup ещё и по IP? В случае, если в VRF множество интерфейсов? Не лучше ли тогда сделать несколько VRF, каждый со своим интерфейсом, внутренней меткой, идентификатором RD и политиками экспорта/импорта?

    Что значит легче? При использовании per-VRF label allocation, LFIB всё-равно не будет включать в себя всю информацию относительно egress interface, L2 и иже с ними. Он же не может полагаться на то, что действительно в каждом VRFe будет только один внешний интерфейс, а на нём только один next-hop. А вот если label выдается per-prefix, то такой проблемы нет.
  • Понял, спасибо.
  • Раз беседа немного ушла из начальной темы, хочу кратко пояснить о полезности вопросов технического характера.
    Я не так много собеседований успел протий за свою короткую жизнь, но однозначно уважения у меня заслужили конторы, которые придерживались следующих правил на технической части:
    1) Не задают вопросы, с которыми сами столкнулись вчера, и решали всем отделом.
    2) Вместо вопросов из п.1, проверка соображалки может быть решена игрой: Примените базовую фичу согласно нашим абсурдным правилам и расскажите как вы рассуждали.
    3) Если вопрос по дизайну, дают возможность кандидату кратко поведать о похожих задачах, решаемых им в реальной жизни.
    4) Избегают неоднозначности и неполноты вопроса насколько это возможно. кэп
    5) Когда задаётся вопрос, помнят, что кандидат может знать больше них. Не исключено, что кандидат вас будет тролить и расскажет всем знакомым, что это он вас собеседовал.
    6) Избегают редких фич в вопросах. Лучше спросить глубоко про OSPF, чем про программирование конкретного asic, за редким исключением в рассматриваемых позициях. Не знать архитектуру конкретного маршрутизатора не стыдно, а вот спалиться перед будущим заказчиком в незнании полей ethernet это беда.

    Критерии эти субъективные. Конечно вопросы должны быть приближены к будущей роли, но одним из козырей инженера является обучаемость, что намного полезнее, чем знать наизусть 3-4 команды в CLI.
Войдите или Зарегистрируйтесь чтобы комментировать.