С реализацией option-82 у циски всё не так гладко на самом деле. Реализация проприетарная, и несколько не по RFC сделанная. в связи с чем не вполне интеропается с другими вендорами.
В RFC сказано, что заголовок состоит из двух полей — Suboption Type и Length. Пацаны из циски что-то покурили, и зачем-то добавили ещё два поля — ещё один Length (содержимым которого является Lengh+2) и Remote ID Type (в случае с Circuit ID — Circuit ID Type). В итоге когда такое сообщение ловит устройство, DHCP-часть которого написана по RFC, оно считает два дополнительных поля значимой частью строки, которой они не являются, и тут начинается полная каша, option-82 не работает. Циска признавать этот фэйл не хочет, но и пояснить значение дополнительных полей также не желает.
Edgecore, которые слизали с циски всё что только можно, вначале имели такой же косяк. Но затем опомнились, и переписали этот функционал по RFC.
Так что решение-то гибкое, но в случае с циской возможны нюансы в части interop.
Это я просто к тому, что стоило вначале сделать ремарку, что мол 2950 — чисто L2 коробка, и поэтому на ней interVLAN никакого нет. Просто вначале статьи есть пояснение sw(config)#ip routing, из которого не очевидно, что эту команду надо говорить только на Core. Просто раз уж статья рассчитана на самый начальный уровень, такие базовые вещи можно было бы пояснять.
Я не для того это пишу, чтоб придраться, а чтоб начинающим понятней было:)
Да, а ещё автор запутался вот здесь: Добавлю лишь то, что перед тем как конфигурировать на коммутаторах DHCP необходимого включить ip routing, что бы поднять его на уровень 3 и осуществлять межвлановую коммутацию
Что значит поднять DHCP на 3 уровень? Сие есть совершенно некорректная формулировка. DHCP занимается исключительно выдачей адресов, это не протокол маршрутизации. ip routing же говорится для того, чтобы запустить межвлановую маршрутизацию, а не коммутацию, это очевидно из синтаксиса команды. Коммутация возможна лишь в пределах одного конкретного VLAN. Всё что шире — есть маршрутизация.
Из статьи не очевидно, что ip routing надо говорить только на той коробке, которая занимается DHCP-машинерией. Начинающий кошковод не поймёт, почему на 2950 не работает interVLAN routing. В целом — более чем тривиальная схема, я-то думал будет кунг-фу:)
Гранд пардон. При заказе OADM модулей, была сделана ошибка, OADM модули были заказаны с LC разъемами. При внедрении CWDM приходилось использовать кучу патчкордов, LC и SC розеток
Я вот тут что-то не понял, какая зависимость между типами разъёмов и количеством патчкордов/розеток? С каких пор запретили патчкорды LC-SC?
б) самое простое — использовать патченный QEMU.
если очень хочется использовать VMWare, то я в своё время нашёл в инете скрипт для SecureCRT, который патчит малтикаст. я его немного адаптировал под себя. скрипт лежит тут. предварительно надо сохранить syscall в соответствующую папку.
при каком значении RAM, выделенном под QEMU удалось добиться стабильной работы?
HW Virtual Serial Port у меня так и не удалось заставить нормально работать, пришлось ставить VSPD XP. проблема в том, что вылеченная версия есть только на XP, для висты и семёрки нет. тем самым появился ещё один поинт в пользу QEMU, который нативными средствами делает туннелирование serial-over-IP.
Смотря что называть поддержкой…
Если в части native-IPv6, то можно сказать, что многие CPE уже поддерживают это. А вот если речь идёт про dual-stack, то здесь всё очень неочевидно. Многие вендоры заявляют поддержку, но когда дело доходит до тестов по вполне жизнеспособному сценарию, то оказывается, что то одного нет, то другого.
Вендорам пока что это неинтересно, т.к. денег на этом срубить они ещё не могут. Как только появится серьёзный бизнес-кейс — тогда будет счастье. А наступит он, думаю, не раньше чем года через полтора, когда нормальная поддержка шестёрки станет необходимым условием для выживания производителя CPE на рынке.
0)про смену трека я естественно знаю. по состоянию на текущий момент джей не зарелизил, что будет представлять собой JNCIP-SP. есть мнение, что это уже будет не лаба, а всего лишь риттен. лаба же была забукана не вчера, и не позавчера, так что дропать её смысла нет. вдобавок к этому, при выполнении ряда условий (пока ещё не понятно, каких именно) JNCIP-M бодро трансформируется в JNCIP-SP. в любом случае, сдать лабу хочу чисто из спортивного интереса.
1) естественно, можно всё закрутить на логических роутерах, но для чистоты эксперимента, а также для размазывания оливок по нескольким ядрам, был выбран вариант с запуском отдельного процесса под каждый роутер, благо ресурсы позволяют.
мечтаю о такой штуке, да жаль времени нет:(
на один из ДР любимая подарила мне вот такую штуку shop.lego.com/Product/Default.aspx?p=8275
Радовался как ребёнок. В итоге оно стоит на работе на полке и радует всех, кто проходит мимо.
я сейчас как раз вовсю готовлюсь к JNCIP-M и вопросом эмуляции жунипера для лабы занимался в середине декабря. были опробованы как VMware, так и qemu. окончательный выбор пал на второй, т.к. под VMware при каждой загрузке инстанса необходимо выполнять определённое кунг-фу для нормального функционирования малтикаста. сей процесс был максимально оптимизирован при помощи скриптов для SecureCRT, но кривизна решения резала глаз. так что сейчас это добро работает в qemu с обвязкой в виде GNS3 для удобства. придумывать трёхстрочные параметры для запуска инстанса, конечно, увлекательно, но несколько отвлекает от основной цели запуска лабы:)
из глюков был замечен только один, под виндой. в случае первичной конфигурации em-интерфейса обязательна перезагрузка коробки после его конфигурирования. в противном случае интерфейс не реагирует на пинги, и ни в inet.0, ни в inet.6 он не значится, несмотря на то, что система говорит, что он в апе. глюк существует как в XP, так и в висте. на убунте всё работает как часы. из неприятного — на то время, когда выполняется commit, загрузка CPU, на котором запущен процесс qemu, взлетает до 100%, что теоретически может вызвать потери сигнального трафика и, как следствие, обвал некоторых протоколов.
из дополнений к статье — я бы добавил рекомендацию про kqemu, который используется для акселерации qemu. чем слабее компьютер, тем виднее вклад акселератора. и написал бы про корректное завершение работы оливок (request system halt), т.к. в противном случае возможны спецэффекты при последующих запусках.
и по поводу упоминание VPLS в конце статьи. если я не ошибаюсь, то VPLS оливками не поддерживается.
P.S. к лабе я готовлюсь на 8.3 (требует 96Мб RAM на каждый инстанс). Пробовал накатить 10.3 — очень прожорливый (минимум 384Мб).
В RFC сказано, что заголовок состоит из двух полей — Suboption Type и Length. Пацаны из циски что-то покурили, и зачем-то добавили ещё два поля — ещё один Length (содержимым которого является Lengh+2) и Remote ID Type (в случае с Circuit ID — Circuit ID Type). В итоге когда такое сообщение ловит устройство, DHCP-часть которого написана по RFC, оно считает два дополнительных поля значимой частью строки, которой они не являются, и тут начинается полная каша, option-82 не работает. Циска признавать этот фэйл не хочет, но и пояснить значение дополнительных полей также не желает.
Edgecore, которые слизали с циски всё что только можно, вначале имели такой же косяк. Но затем опомнились, и переписали этот функционал по RFC.
Так что решение-то гибкое, но в случае с циской возможны нюансы в части interop.
Я не для того это пишу, чтоб придраться, а чтоб начинающим понятней было:)
Добавлю лишь то, что перед тем как конфигурировать на коммутаторах DHCP необходимого включить ip routing, что бы поднять его на уровень 3 и осуществлять межвлановую коммутацию
Что значит поднять DHCP на 3 уровень? Сие есть совершенно некорректная формулировка. DHCP занимается исключительно выдачей адресов, это не протокол маршрутизации. ip routing же говорится для того, чтобы запустить межвлановую маршрутизацию, а не коммутацию, это очевидно из синтаксиса команды. Коммутация возможна лишь в пределах одного конкретного VLAN. Всё что шире — есть маршрутизация.
Ну в общем да, процедура переклейки коннектора с SC на LC занимает от силы 15 минут, что вы и сделали.
При заказе OADM модулей, была сделана ошибка, OADM модули были заказаны с LC разъемами. При внедрении CWDM приходилось использовать кучу патчкордов, LC и SC розеток
Я вот тут что-то не понял, какая зависимость между типами разъёмов и количеством патчкордов/розеток? С каких пор запретили патчкорды LC-SC?
interface Group-Async0
no ip address
encapsulation slip
group-range 0/1/0 0/1/15
!
line 0/1/0 0/1/15
session-timeout 120
exec-timeout 0 0
login authentication NoAuth
no exec
transport input telnet
transport output telnet
stopbits 1
Для других железок может потребоваться покрутить параметры line.
если очень хочется использовать VMWare, то я в своё время нашёл в инете скрипт для SecureCRT, который патчит малтикаст. я его немного адаптировал под себя. скрипт лежит тут. предварительно надо сохранить syscall в соответствующую папку.
HW Virtual Serial Port у меня так и не удалось заставить нормально работать, пришлось ставить VSPD XP. проблема в том, что вылеченная версия есть только на XP, для висты и семёрки нет. тем самым появился ещё один поинт в пользу QEMU, который нативными средствами делает туннелирование serial-over-IP.
Если в части native-IPv6, то можно сказать, что многие CPE уже поддерживают это. А вот если речь идёт про dual-stack, то здесь всё очень неочевидно. Многие вендоры заявляют поддержку, но когда дело доходит до тестов по вполне жизнеспособному сценарию, то оказывается, что то одного нет, то другого.
Вендорам пока что это неинтересно, т.к. денег на этом срубить они ещё не могут. Как только появится серьёзный бизнес-кейс — тогда будет счастье. А наступит он, думаю, не раньше чем года через полтора, когда нормальная поддержка шестёрки станет необходимым условием для выживания производителя CPE на рынке.
тем не менее, почитать будет интересно
1) естественно, можно всё закрутить на логических роутерах, но для чистоты эксперимента, а также для размазывания оливок по нескольким ядрам, был выбран вариант с запуском отдельного процесса под каждый роутер, благо ресурсы позволяют.
на один из ДР любимая подарила мне вот такую штуку shop.lego.com/Product/Default.aspx?p=8275
Радовался как ребёнок. В итоге оно стоит на работе на полке и радует всех, кто проходит мимо.
из глюков был замечен только один, под виндой. в случае первичной конфигурации em-интерфейса обязательна перезагрузка коробки после его конфигурирования. в противном случае интерфейс не реагирует на пинги, и ни в inet.0, ни в inet.6 он не значится, несмотря на то, что система говорит, что он в апе. глюк существует как в XP, так и в висте. на убунте всё работает как часы. из неприятного — на то время, когда выполняется commit, загрузка CPU, на котором запущен процесс qemu, взлетает до 100%, что теоретически может вызвать потери сигнального трафика и, как следствие, обвал некоторых протоколов.
из дополнений к статье — я бы добавил рекомендацию про kqemu, который используется для акселерации qemu. чем слабее компьютер, тем виднее вклад акселератора. и написал бы про корректное завершение работы оливок (request system halt), т.к. в противном случае возможны спецэффекты при последующих запусках.
и по поводу упоминание VPLS в конце статьи. если я не ошибаюсь, то VPLS оливками не поддерживается.
P.S. к лабе я готовлюсь на 8.3 (требует 96Мб RAM на каждый инстанс). Пробовал накатить 10.3 — очень прожорливый (минимум 384Мб).