GNS3
http://forum.gns3.net/

RedNectar's GN3v1.x Suggestions
http://forum.gns3.net/topic7581.html		 Page 1 of 1
Author:  rednectar [ Wed Nov 06, 2013 10:49 pm ]
Post subject:  RedNectar's GN3v1.x Suggestions
Here are some of my suggestions for improving GNS3 - some I've mentioned before, perhaps not as coherently as here.

  1. Virtual PC Simulator Integration

    VPCS Integration has come a long way in GNS3, but having soooooo many ports to choose from when I add a "Host" cloud makes it too difficult for users that are not "in the know" of how NIO-UPD ports work.

    My suggestion make this much easier for users, and also makes use of the new VPCS hypervisor function to allow you have more than nine VPCs.

    This suggestion has two parts to it; a new VPCS Icon, and VPCS Hypervisor support

    This is how I see it working.

    Under the End Devices list there would be an additional icon for VPCS host.
    When you added the first VPCS host, GNS3 would start the VPCS hypervisor - just as GNS3 starts the Dynamips hypervisor when you drag a router onto the workspace. (with a vpcs -H 20000 command - assuming 20000 TCP is the VPCS Hypervisor Port given in settings - discussed later)
    This first VPC would be automatically named VPC1, and have one interface available: nio_udp:30000:127.0.0.1:20000
    Similarly, the second VPC device would be automatically named VPC2, and have one interface available: nio_udp:30001:127.0.0.1:20001 etc
    Note that the port numbers used will be derived from base ports defined in settings (discussed later)

    At some point, there will need to be commands sent to the hypervisor to tell it to start as many VPCS instances as required (one for every 9 PCs - or more correctly, one for every 9 UDP ports used by VPCS devices - I may have a VPC1 and a VPC10 and have deleted VPCs 2-9 - this would require 2 instances because VPC10 would be bound to nio_udp:30009:127.0.0.1:20009). Keeping track of how many instances of VPCS are running will be crucial to the smooth implementation of this feature.

    To start the first VPC instance, send the command vpcs -p 20001 -s 20000 -c 30000 to the VPCS hypervisor. Note, the -p parameter is the Base VPCS Terminal Port defined in VPCS settings. The -s and -c are derived from the base ports defined in settings (with local and remote values swapped). VPCS Settings are discussed later. If a second instance is required, it would use the command vpcs -p 20002 -s 20009 -c 30009

    The question is, when do these instances of VPCS get started. I suggest these possibilities
    1. When the user clicks on the Start/resume all devices icon
    2. When the user selects Tools | VPCS
    3. When the user right-clicks on a VPCS device, there is an option to Start VPCS
    4. A Start VPCS option on the Device menu
    5. When the user double-clicks on a VPC icon
    Now, of course starting these instances of VPCS through the VPCS hypervisor does not open a terminal session. But (apart from a. above) users will expect that not only will the required instances of VPCS start, but that a console window should also open (as it does now with Tools | VPCS )

    And note that if more than one instance of VPCS is running (ie, more than 9 VPCs), there will need to be more than one terminal window open, at least when I click Tools | VPCS - the other options might just open a terminal window appropriate to the instance.

    And for there to be a console window, there needs to be a way of defining the terminal application, which brings me to the topic of settings:

    VPCS Settings

    There would need to be a VPCS configuration page added to Preferences. It would have settings for:
    Code:
    Executable path to VPCS:
    [e.g/ /usr/bin/vpcs      ]
    VPCS Hypervisor Port:    Base VPCS Terminal Port:    Base Local Port:    Base Remote Port:
    [         20000 TCP]     [            20001 TCP]     [    30000 UDP]     [     20000 UDP]
               
    Terminal Command:
    [e.g. konsole --new-tab -p tabtitle=VPCS -e telnet 127.0.0.1 %p >/dev/null 2>&1 &   ]

    • Note for the Terminal Command the %p parameter will determined by the Base VPCS Terminal Port. If the VPCS instance being started is bound to a port number more than 8 greater than the Base Local and Remote Ports, then the port number for %p will be determined by doing some modulus 9 arithmetic!
    • Note: The Terminal Command: option may be better put under GNS3 Preferences | General | Terminal Settings and may also be given the luxury of having a set of Preconfigured VPCS terminal commands

    VPCS Configurator

    Currently, when I double-click on a cloud icon, or navigate to Device | Configure the Node Configurator opens. The Node Configurator has sections for Routers, Ethernet Switches, etc, and Clouds.

    Clouds are always numbered (by default) C1, C2 etc.

    I would like to see the the VPCS objects be given a separate category to Clouds
    The configuration options for VPC1, VPC2 etc would simply be:
    Local Port: [ xxxxxxxx]
    Remote Port:[ xxxxxxxx]

    There is no need for NIO Ethernet, NIO TAP or NIO anything tabs, nor is there a need to specify a Remote host

    Kill VPCS Instances when quitting GNS3

    Currently if I quit GNS3, dynamips is killed and all instances of any console sessions I had get killed too.

    Similarly, in the hypervisor driven model, I'd expect when I quit GNS3, all the child VPCS and VPCS Hypervisor sessions would get killed too.
  2. Use relative path for images

    One of the things that make it hard for people to swap topologies and projects is the fact that whenever you open someone else's topology, you have to choose new images, EVEN IF YOU HAVE A LOCAL IMAGE OF THE SAME NAME!

    This is because the full pathname is saved in topology.net - eg:
    image = /home/user/GNS3/Images/c3640-ik9o3s-mz.124-25a.image

    We added the ability to remove path names from configuration files years ago. It is time to do the same with Images. I want my topology files to read:
    Code:
    [127.0.0.1:7200]
        [[3640]]
            image = c3640-ik9o3s-mz.124-25a.image

    and if the image is nested deeper in the same path - even Qemu images:
    Code:
    [qemu 127.0.0.1:10525]
        [[5520]]
            initrd = ASA/asa842-initrd.gz
            kernel = ASA/asa842-vmlinuz

    instead of
    Code:
    [127.0.0.1:7200]
        [[3640]]
            image = /home/user/GNS3/Images/c3640-ik9o3s-mz.124-25a.image

    and
    Code:
    [qemu 127.0.0.1:10525]
        [[5520]]
            initrd = /home/user/GNS3/Images/ASA/asa842-initrd.gz
            kernel = /home/user/GNS3/Images/ASA/asa842-vmlinuz


    To do this, I see we need another option under GNS3 Preferences | General | General Settings that says:
    [x] Use relative paths for OS images

    When checked, topology.net files would be saved with the OS Images directory portion removed from the configuration as indicated above, and when loading a topology file, the OS Images directory portion would automatically be added to images where the location did not start with a / or \ or a Windows Drive letter:
  3. Spelling of Idle-PC

    In various places throughout GNS3, the Idle-PC setting is referred to as:
    Idle-PC
    Idle PC
    Idle Pc
    IDLE-PC
    idlepc

    How about we choose one - say Idle-PC and stick with it!
  4. Hypervisor selection bug

    Before I write this one up, can someone tell me if the IOS images and hypervisors option is going to be integrated into the normal GNS3 Preferences?
  5. More when I get time to write them up!
    [Edit: see topic7685.html]
Author:  fbifido [ Thu Nov 07, 2013 2:00 am ]
Post subject:  Re: RedNectar's GN3v1.x Suggestions
I second #2,

i was just about to write a post on the new GNS3 v1.0 new format. but saw this post.
but in GNS3, you can only add 1 IOS image to a platform->model, its best to just have:

Code:
[[2691]]                               <--------|
        image = [c2691]                          |
        idlepc = [c2691]                          |--- This section can be remove or made optional
        idlemax = [c2691]                        |      because every gns3 install is different, but once it is installed
        sparsemem = True                       |       and setup up, all the IOS are the same, not the file name, but how
        ghostios = True             <---------|       you call them in the GUI, all other values can be stored with the image
[[ROUTER R1]]
        model = [c2691]  <---- you can get all the info for the router from gns3 ios store, image/idlepc/idlemax
        console = 2001
        aux = 2501
        cnfg = configs\R1.cfg
        wic0/0 = WIC-2T
        s0/0 = R2 s0/0
        s0/1 = R3 s0/0
        x = -393.0
        y = -146.0
        z = 1.0


not every one have access to the same images, but i am sure they have access to one of the IOS from that same model.

while writing this i realize that these settings has little to do with GNS3 but more to do about Dynamips, so if the above info does not make sense, will MiBAD.

Quote:


Use relative path for images

One of the things that make it hard for people to swap topologies and projects is the fact that whenever you open someone else's topology, you have to choose new images, EVEN IF YOU HAVE A LOCAL IMAGE OF THE SAME NAME!

This is because the full pathname is saved in topology.net - eg:
image = /home/user/GNS3/Images/c3640-ik9o3s-mz.124-25a.image

We added the ability to remove path names from configuration files years ago. It is time to do the same with Images. I want my topology files to read:
Code:
[127.0.0.1:7200]
[[3640]]
image = c3640-ik9o3s-mz.124-25a.image
Author:  grossmj [ Thu Nov 07, 2013 8:34 pm ]
Post subject:  Re: RedNectar's GN3v1.x Suggestions
@rednectar

Quote:
Virtual PC Simulator Integration


I pretty much agree with everything you said. Excellent write up :) I will come back to it when I start the integration.

Quote:
Use relative path for images


This is a real problem and managing it is not so easy because we can't distribute IOS images (see reply to fbifido below). However, I am pretty sure that relative paths for images should already work if your image is inside your project folder (haven't tested recently).

Quote:
Spelling of Idle-PC


Yep, good one :D I agree, we should stick with Idle-PC only.

Quote:
Hypervisor selection bug


Do not waste too much time with this because the IOS images and hypervisors is gonna change a lot and move to Preferences.

@fbifido

Quote:
i was just about to write a post on the new GNS3 v1.0 new format. but saw this post.
but in GNS3, you can only add 1 IOS image to a platform->model, its best to just have:


That's pretty much what I intend to do using a different file format. The main problem which seems unsolvable is that different IOS images for the same platform have different features, which means that a project that works for someone may not work for someone else... (on the IOS side).
Author:  rednectar [ Thu Nov 07, 2013 9:23 pm ]
Post subject:  Re: RedNectar's GN3v1.x Suggestions
@Jeremy
Quote:
This is a real problem and managing it is not so easy because we can't distribute IOS images (see reply to fbifido below). However, I am pretty sure that relative paths for images should already work if your image is inside your project folder (haven't tested recently).


Relative paths for images doesn't work. If you take a peek in a recently saved/created topology.net, you will see:
Code:
[127.0.0.1:7200]
    [[3640]]
        image = /home/user/GNS3/Images/c3640-ik9o3s-mz.124-25a.image
....
[qemu 127.0.0.1:10525]
    [[5520]]
        initrd = /home/user/GNS3/Images/ASA/asa842-initrd.gz
        kernel = /home/user/GNS3/Images/ASA/asa842-vmlinuz


I am trying to put together a GNS3 WorkBench package for Windows - and trying to copy topology.net files form Linux to Windows is a real pain because of this - there is no way I can copy a topology.net from Linux to Windows without bypassing the message that says:

Quote:
Local IOS image /home/user/GNS3/Images/c3640-ik9o3s-mz.124-25a.image
cannot be found on the hypervisor 127.0.0.1:7200

Please choose an alternative image:
[127.0.0.1:C:\Users\user\GNS3\Images\c3640-ik9o3s-mz.124-25a.image]


This is stupid. The image c3640-ik9o3s-mz.124-25a.image is in the default location on both the Linux install and the Windows install. GNS3 should just "do it" without the question.

It is no better even if I edit the topology.net file to say
Code:
[127.0.0.1:7200]
    [[3640]]
        image = c3640-ik9o3s-mz.124-25a.image

I still get the annoying dialogue when I open the topology in Windows - so the fix has to involve not only how the topology.net is saved, but how it is loaded as well.

HTH

PS Has anyone done any design work on this?
Quote:
IOS images and hypervisors is gonna change a lot and move to Preferences.
I've got a lot of ideas - including some ideas about the bindings to 0.0.0.0 vs 127.0.0.1
Author:  grossmj [ Thu Nov 07, 2013 9:29 pm ]
Post subject:  Re: RedNectar's GN3v1.x Suggestions
@Chris

Quote:
I still get the annoying dialogue when I open the topology in Windows - so the fix has to involve not only how the topology.net is saved, but how it is loaded as well.


Ok, I am gonna take this into account for the new GNS3.

Quote:
PS Has anyone done any design work on this?

I've got a lot of ideas - including some ideas about the bindings to 0.0.0.0 vs 127.0.0.1


Nope, I just want to consolidate the way and from where your configure settings. No design has been done yet. So please feel free to throw your ideas in :)

Thanks!
Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/