Привет, незнакомец!
Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!
In this Discussion
Почему работает "Ping 127.227.327" или каверзные вопросы для собеседования
Предлагаю поделиться каверзными вопросами, которые Вы или Вам когда-либо задавались на собеседованиях.
Уверен, что все все знают, но кому-то будет интересно, что:
Сокращать IP адреса при записи придумали не в IPv6 и ping 127.127 спокойно будет присылать ответ.
Так же будет отвечать и ping 127.227.327 (да именно 327, я не опечатался).
Что произойдет, если запустить ping числа 2133333333? а 2139999999?
Зачем нужен wildcard? ведь уже и так есть netmask.
Уверен, что все все знают, но кому-то будет интересно, что:
Сокращать IP адреса при записи придумали не в IPv6 и ping 127.127 спокойно будет присылать ответ.
Так же будет отвечать и ping 127.227.327 (да именно 327, я не опечатался).
Что произойдет, если запустить ping числа 2133333333? а 2139999999?
Зачем нужен wildcard? ведь уже и так есть netmask.
Тэги темы:
Войдите или Зарегистрируйтесь чтобы комментировать.
Комментарии
http://linkmeup.ru/blog/84.html
Меня спрашивали, как работает утилита traceroute.
И спрашивали, как в Port-Channel узнать, что один из линков не работает (я тогда не знал про Port-Channel, но догадался, что можно посылать по линкам пакеты и смотреть, придут ли).
И ещё спрашивали алгоритм BGP Best path selection (на другом собеседовании).
Какой номер порта надо закрыть чтоб перестал ходить пинг?
Каким образом в трейсе задержка на более поздних хопах может быть меньше, чем на ранних?
А так и ping 127.0000000000000000001.000000000127 будет работать, по крайней мере в nix.
Следующий на сколько я понял число в другой системе исчисления.
Неконкретно, все вопросы на подумать показывают как это самое подумать происходит и, всё же, иногда лучше жевать...
просто тут такое дело:
Насколько я понял это как раз про Echo Protocol что используется транспортный уровень UDP/TCP причем, я видел множество раз реализацию через UDP, а через TCP не встречал.
Но, чаще под пингом понимают реализацию ICMP-echo
В таком случае используется строго ICMP-протокол с type 0 и с type 8.
Так действительно, о каком пинге идет речь?
Я считаю есть 2 хороших подхода к техническому собеседованию сетевого инженера:
1) Человеку дается компьютер с лабой и ставится задача настроить какую-то топологию. Сложность топологии в зависимости от реальных задач конечноже, которые будут нужны инженеру. Если инженер будет работать с сетью предприятия то это могут быть всякие opsf, bgp, dmvpn и прочее. Сразу понятно сможет ли человек работать с имеющейся инфраструктурой или нет.
2) Второй подход описан по ссылке: networkcomputing.com/cloud-infrastructure/4-must-ask-interview-questions-network-engineers/1812353780
В кратце: инженеру нужно нарисовать часть сети, которой он занимался и рассказать как, что и зачем в ней работает. Так же можно задать пару вопросов по технологиям из резюме. Человек пишет, что знает BGP? Замечательно, пусть расскажет что это за протокол и какие задачи с помощью него можно решить.
Пишу не ради холивара, просто считаю, что когда человек приходит в компанию рога и копыта работать за небольшие деньги с простенькой топологией, а его начинают грузить вопросами с собеседования в гугл "почему люки круглые" - это как-то немного неправильно и не честно по отношению к человеку получается. И велик шанс упустить хорошего инженера, который хочет развиваться и принесет много пользы предприятию.
Вопросы же такого плана позволяют выявить глубину изучения темы и мышление.
Понимаете, BGP и OSPF можно научиться настраивать, не прочитав ни одной книги. И даже разобраться в порядке установления соседства и прочего. Понять не стоит строить локальные сети на IBGP требует и почитать, и подумать, и лабу собрать.
И если нужен сотрудник с перспективой или на позицию архитектора/дизайнера/в отдел развития, то лучше, чтобы необычные вопросы он или сам изучал или был готов их обработать.
Но в целом да, пункт совсем не обязательный.
Мне вот на позицию 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.
Вы клёвые вопросы задаёте форуме, но я попросил бы выражаться яснее. К другим участникам это тоже относится, особенно если на собеседовании вам таки дали картинку.
Думал об этом, но это на самом деле трудно. Когда погружен в какой-то вопрос, находишься в его контексте, возникает иллюзия, что остальным тоже ясен этот контекст, хотя на самом деле это далеко не так.
А разве "в коре" коммутация не по транспортной (внешней) метке?
В смысле, для задач Load Balancing почему-бы не использовать RSVP-TE, не построить нужное количество TE-LSP по желаемым путям, и не балансить между ними на head-end'e? Зачем всем маршрутизаторам "в коре" спускаться от транспортной к VPN-метке?
UPD: Есть что-нибудь хорошее, что можно почитать про эти вещи (балансировка по VPN-метке в коре)?
Например, vc-label будет у каждого l2vpn-клиента разный. Но если хочется ещё больше балансить, то есть fat-pw, который генерит фейковые метки на основе MAC или L3/L4, и ставит их в самый низ для балансировки в коре.
Боюсь по балансировке только платформенное могу посоветовать, и только cisco.
Обычно же включен режим PHP, внешняя удаляется на PHP-маршрутизаторе.
>> один по внутренней,
Рзаве LFIB на основе VPN-метки (которая после PHP стала внешней) не определяет все дальнейшие действия (POP, заголовок для формирования L2-фрейма и выходной интерфейс?
Зачем делать lookup ещё и по IP? В случае, если в VRF множество интерфейсов? Не лучше ли тогда сделать несколько VRF, каждый со своим интерфейсом, внутренней меткой, идентификатором RD и политиками экспорта/импорта?
https://megamozg.ru/post/25168/?utm_campaign=email_digest&utm_source=email_megamozg&utm_medium=email_week_20160331&utm_content=link2post
Я не так много собеседований успел протий за свою короткую жизнь, но однозначно уважения у меня заслужили конторы, которые придерживались следующих правил на технической части:
1) Не задают вопросы, с которыми сами столкнулись вчера, и решали всем отделом.
2) Вместо вопросов из п.1, проверка соображалки может быть решена игрой: Примените базовую фичу согласно нашим абсурдным правилам и расскажите как вы рассуждали.
3) Если вопрос по дизайну, дают возможность кандидату кратко поведать о похожих задачах, решаемых им в реальной жизни.
4) Избегают неоднозначности и неполноты вопроса насколько это возможно. кэп
5) Когда задаётся вопрос, помнят, что кандидат может знать больше них. Не исключено, что кандидат вас будет тролить и расскажет всем знакомым, что это он вас собеседовал.
6) Избегают редких фич в вопросах. Лучше спросить глубоко про OSPF, чем про программирование конкретного asic, за редким исключением в рассматриваемых позициях. Не знать архитектуру конкретного маршрутизатора не стыдно, а вот спалиться перед будущим заказчиком в незнании полей ethernet это беда.
Критерии эти субъективные. Конечно вопросы должны быть приближены к будущей роли, но одним из козырей инженера является обучаемость, что намного полезнее, чем знать наизусть 3-4 команды в CLI.