Предлагаю поделиться каверзными вопросами, которые Вы или Вам когда-либо задавались на собеседованиях.
Уверен, что все все знают, но кому-то будет интересно, что:
Сокращать 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.