![]() And I thinkĭocker work on stuff for multi architecture support. If the container still use an old distribution no issue. On a linux box you can use IOU without the VM or ugly 32 bits dependencies just docker. I think we could find a way for mounting the IOU images directory and with a env variable choose the correct image.īut your technique work with today GNS3 and that's cool. When you import the GNS3A the appliance file say this variable can be configured and this will be reflect to the container env.Īlso I'm not a big fan of embedding the IOU image in the container because it's break the project portability. Perhaps we need a settings system for containers. I will start some work on port naming architecture GNS3/gns3-server#676 We can probably add a support for docker in a futur release. Question is it specific to IOU or could we use that in other container. We can probably modify the docker support to inject ethernet adapter with a different name in the container to symbolize that this adapter are serial link. Under the hood the network communication is the same. ![]() We don't know how IOL in VIRL will work it can change the strategy. And we improve a lot docker support to allow container to have custom settings You create them using gns3a, no more dedicated IOU settings / wizard. IOU is a container like other in the interface.Your alpine image is very interesting due to the small size. We know that one day the 32 bit support on most linux will be dropped and we will need to have an alternative. I think it's how we will support IOU in the future. ![]() For me the main issue is the loss of the serial What do you think about IOU within docker? While IOU in docker basically works, a nice support needs some (small) changes. I'm using environment variables for the (few) situations, where the defaults needs to be changed. There is no GUI field in docker to modify the NVRAM and MEM size.Maybe that can be also added to the docker container. The other VM types have a flexible way naming the interfaces in the GUI. The interface names differ between IOU and the GNS3 GUI.Maybe even Mac address collision when runing IOU on multiple GNS3 server gns3-server#557 can be solved that way. If those IDs can be sent to the docker VMs, this issue should be solved. Currently I'm using the device name to create an ID between 1.997, but that's not safe. Currently the docker image has no way choosing one. That means, that every IOU device in a project needs a unique ID. ![]() The base MAC address of an IOU device is based on the device ID, see Mac address collision when runing IOU on multiple GNS3 server gns3-server#557.Of course the use of create-iou-image is just a temporary solution, a much better way would be a dialog integrated into GNS3.ĭuring the development I encountered the following issues:Įspecially for training this is a mayor drawback. As the base image is quite small (based on alpine, about 15 MB), this is a quite efficient way using IOU. With the help of the create-iou-image script the user creates a new docker IOU image for each IOU binary, adding the missing stuff (binary license, config) to the base. It consists of a base image, that contains everything except the IOU binary, the license and the initial config. I've created a more advanced version, see. Julien made an early test with IOU within docker, see. Using docker images for IOU would encapsulate all this special stuff. Cisco IOU is quite complicate to integrate, it needs 32-bit shared libraries, a special NETMAP configuration and iouyap.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |