Несмотря на кажущуюся простоту добавления узлов в проект GNS3, все оказалось не так уж просто. Описанные ранее узлы из Virtual PC Simulator у меня иногда "завешивают" намертво мой ноутбук. У меня нет никакого желания прерывать свой курс самостоятельной подготовки к экзамену CCNA, и выяснять с чем бы это могло быть связано. Из этой ситуации остается один выход - QEMU. В принципе решение не новое и, по идее, вполне рабочее. Но есть одно но... Как я ни пытался - больше одного узла добавить в проект GNS3 я не мог. Точнее сказать, добавить получается, но больше одного виртуального qemu-хоста не стартует.
Как оказалось, с этой проблемой столкнулся не я один. Это уже известный баг QEMU. Оказывается с одного образа операционной системы можно запустить только один виртуальный хост. Т.е. если для любого количества маршрутизаторов достаточно одного образа Cisco IOS, и все ограничение только в количестве мегабайт оперативной памяти и ресурса процессора, то для виртуальных QEMU-хостов для каждого экземпляра нужен свой отдельный образ. Т.е. нужно скопировать один и тот же образ с разными именами столько раз, сколько нужно виртуальных хостов. После этого, при добавлении Qemu host в топологию проекта GNS3, нужно для каждого из них указывать свой файл образа в меню "Configure". После этого, при нажатии кнопки "Start" автоматически запускается окно консоли где видна загрузка Linux. В моем случае это linux-microcore 2.10.
Само по себе поведение qemu отличается от поведения любого другого эмулироемого объекта. В частности, если закрыть консоль qemu host, то она уже не откроется и этот виртуальный хост больше не отреагирует на "Stop" или "Start". Это очень неудобно, так как в процессе выполнения лабораторной работы, время от времени приходится закрывать консоли. Если ошибиться и закрыть консоль qemu host, то его придется удалять, а на его место добавлять новый. Эта проблема решается одной опцией запуска qemu. Точнее не решается, а запрещается закрытие консоли. Для того, чтобы консоль к qemu-узлу не закрывалась по кнопке закрытия окна, необходимо в "Edit" -> "Preferences..." -> "Qemu" в закладке "Qemu Host" вызвать на редактирование предварительно настроенный образ, и в "Qemu Options" добавить к -no-acpi еще -no-quit . Последняя опция отключает закрытие окна консоли. Теперь окно невозможно случайно закрыть. Окно консоли будет автоматически закрываться после нажатия "Stop".
Теперь вопрос с виртуальными хостами для проектов GNS3 окончательно решен, и можно строить топологии на подобие тех которые используются в Cisco Packet Tracer.
6 комментариев:
Добрый день. Сталкивались ли Вы с такой проблемой. Имеется 2 маршрутизатора подключенных друг за другом. Первый маршрутизатор через облако подключен к реальной сети. На нем я прописал ip route 0.0.0.0 0.0.0.0 192.168.1.1. И задал IP FA0/0 192.168.1.70 255.255.255.0. С него я могу пингануть 192.168.1.1 и с ПК пингуется 192.168.1.70. Далее, на втором интерфейсе я прописал сеть 10.2.1.1 255.255.255.0. IP второго маршрутизатора 10.2.1.2. С него я пигую 192.168.1.70 и 10.2.1.1. А вот 192.168.1.1 не пингуется. М.б. я что-то не правильно настроил... Можете подсказать, если не сложно или поделиться рабочей схемой. Буду очень благодарен. Спасибо.
А 192.168.1.1 знает что маршрут на 10.2.1.0/24 находиться за 192.168.1.70? Похоже что нет. Думаю прописывание маршрута на компьютере решит проблему.
Наверное не на ПК, а на роутере 192.168.1.1. Получается, 192.168.1.1 не знает про адрес 10.2.1.2 и соответственно сеть 10.2.1.0. Либо я должен прописать маршрут на ПК, адрес которого 192.168.1.35. Т.е. 10.2.1.0 255.255.255.0 192.168.1.1 прописываю на роутере или ПК.
Возможно что я не до конца понял всю топологию. Картинка бы значительно упростила ситуацию. В любом случае, оба участника должны знать о маршрутах. Т.е. если мы пингуем с 10.2.1.2 -> 192.168.1.1, то 10.2.1.2 должен знать маршрут в сеть 192.168.1.0/24, а 192.168.1.1 должен знать маршрут в сеть 10.2.1.0/24. Как-то так.
Добрый вечер. Спасибо за подсказку, все заработало. Действительно, проблема была в маршрутизации. Роутер не знал о сети 10.2.1.0. Я прописал маршрут до этой сети на роутере и указал в качестве GW 192.168.1.70, т.е. 10.2.1.0 255.255.255.0 192.168.1.70 и все заработало. Еще раз, большое спасибо за подсказку. Только начинаю постигать основы маршрутизации, надеюсь рано или поздно начну в этом разбираться.
Пожалуйста. В первой книге двухтомника "Официальное руководство по подготовке к сертификационным экзаменам CCNA" есть раздел который так и называется "Маршрутизация". Там все очень хорошо описано по шагам. Рекомендую прочесть этот раздел для понимания процесса маршрутизации.
Отправить комментарий