HOW TO install GNS3 v1.0 beta on Ubuntu/Linux Mint/Debian

I wrote a script to keep my Linux Mint 17.0 GNS3 v1.0 beta install updated.

This script has been tested on 32 bit Linux Mint 17 and 32 bit Ubuntu 14.04, and is an updated version of my earlier alpha installer.

Download the script from this post on the GNS3 Forum, and decompress the file in your home directory (or wherever you choose) and make sure you run the script as sudo (it will remind you to do so if you forget)

The script attempts to setup the GNS3v1 beta on your existing Linux system.

It is based on instructions at http://forum.gns3.net/post27906.html

http://forum.gns3.net/topic8988.html and https://github.com/GNS3/gns3-server

http://forum.gns3.net/post28922.html and http://forum.gns3.net/topic11444.html

If you have problems, please refer to the forum posts. Good Luck

It will, depending on the type of install you choose:

* Create my recommended directory structure for you

* Install git (developer install)

* Install subversion (developer install)

* Install bison parser generator (developer install)

* Install flex lexical analyzer (developer install)

* Install all the python stuff you need

* Install dynamips

* Install pip

* Install Dan Lintott’s gns3-converter http://forum.gns3.net/post35824.html

* Install vboxwrapper and VirtualBox

* Install iouyap -Ref: http://forum.gns3.net/topic8966.html

* Fix link to libssl1.0.0 -Ref: http://forum.gns3.net/topic8988.html

* Install SSH

* Install Wireshark

* Install VPCS

* Install BBE

* Install ROXTerm

* Create a iourc file for you (you’ll have to add your own licence)

* Add an entry to your hosts file for xml.cisco.com

* Install gns3-server (beta)

* Install gns3-gui (beta)

When run (must be run as sudo) it will give you 6 options:

An archive install installs dynamips from the deb repository, and gns3 
components from the latest release version using wget (Safest option)

A developer install pulls latest development sourcecode for dynamips, 
iouyap, vpcs, gns3-server and gns3-gui using git clone or git pull 
(or svn for vpcs)
This is the bleeding edge code.

Full install options re-installs everything - no questions asked
Note: Will not overwrite iourc if it exists
Normally, supplemtary apps like pip and ssh are skipped if already installed.
The full archive install can also be invoked using the -full command line 
option.

Would you like:
a. an interactive archive (release version) install?
A. an archive (release version) install? - no questions asked.
f. a full archive install (re-installs everything)? - no questions asked.

d. an interactive developer (bleeding edge) install?
D. a developer (bleeding edge) install? - no questions asked.
F. a full developer install (re-installs everything)? - no questions asked.

q. quit. Get me out of here!

a/A/d/D/f/F/q [a]
About these ads
Posted in GNS3 | Tagged , , | Leave a comment

WordPress Changed their editor – and it sucks

Welcome to the keyhole. Trying to edit/create a blog post using WordPress just got harder (as if it wasn’t hard enough already!)

When I go to create a page, the first thing you notice is that you have to edit in a keyhole. The new edit page looks like this:

Screen Shot 2014-08-17 at 08.43.39  (2)

It used to look like this:Screen Shot 2014-08-17 at 08.41.48  (2)

Notice that there is a lot more editing room in the old page.  And if I’m in “Visual” mode, the editing screen gets even bigger!

And that’s not all. I used to have a [Save Draft] option. That’s gone – so when I went looking for it and clicked on something that took me somewhere else, when I cam back I’d lost some of my work. Not happy.

And Preview page doesn’t work (although it DOES force a “save draft”)

So WordPress, so far your new editor scores about 3/10 from me. Mind you, the “Classic Editor” is only worth about 6/10.

Posted in rant, wordpress | Tagged , | Leave a comment

VPCS Tutorial-updated

Many people are not aware of how to make the best use of the features the the Virtual PC Simulators (VPCS) application, so I thought I’d run a tutorial. This is re-work of the original tutorial I wrote, updated for GNS3 version 0.8.7 and VPCS version 0.5b2, and doesn’t require GNS3 WorkBench, although you could easily add this exercise by following these instructions.

[BTW - if you find this tutorial a little heavy going, this link will take you to Alim H Ali's  excellent getting started tutorial on youtube]

To get started, I’ll assume you have GNS3 running on your system and have a suitable image for a c3725 router.  Start by downloading files the zip file found here.  Expand the zip file into your GNS3 Projects folder, then in GNS3, open the topology.net file found in the VPCS_Tutorial folder.  As you open the file, you will be asked to select your c3725 router image.   You should then see the topology below: [Oh, and by the way, the instructions page points to this blogpost, so if you suddenly have two copies of this page open, that's the reason]

In the GNS3 application, from the menu open the VPCS window by selecting Tools|VPCS.  Next, select Control|Start/Resume all devices to start your routers, and once the routers have started, from the menu select Control|Console to all devices icon. After all the routers have started, and the routing protocol converged, you are ready to start learning about the VPCS.

Start by activating the VPCS window. You should see:

Executing the startup file

Checking for duplicate address...
PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251

Checking for duplicate address...
PC2 : 10.1.2.1 255.255.255.0 gateway 10.1.2.252

Checking for duplicate address...
PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253


NAME   IP/MASK              GATEWAY           MAC                DNS
VPCS1  10.1.1.1/24          10.1.1.251        00:50:79:66:68:00  
VPCS2  10.1.2.1/24          10.1.2.252        00:50:79:66:68:01  
VPCS3  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02  
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03  
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04  
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05  
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06  
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07  
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08  

VPCS[1]>

The [1] shows that your focus is Virtual PC #1. From the output above, you can see that Virtual PCS1‘s IP address is 10.1.1.1 and its default gateway is 10.1.1.251. In the GNS3 topology, it is marked as PC1Bugs.

Lesson #1 – Successful pings

In this lesson, you will see:

  • the purpose of the startup.vpc file
  • how to check your configuration
  • a successful ping to a local address (PC1Bugs’ default gateway – 10.1.1.251)
  • how to check the arp cache using the show arp command
  • a successful ping to a remote address (PC2Sam – 10.1.2.1)
  • command abbreviation

It helps if you understand that the reason that your Virtual PCs have any configuration is because there is a startup file that serves as a script file when you run VPCS.  You will learn more about script files in Lesson #7 and Lesson #8, but for now, I want you to understand that your startup.vpc script ended with the show ip all command, and that you can use this command any time you want to check your configuration, so begin by practicing that command.

VPCS[1]> show ip all

NAME   IP/MASK              GATEWAY           MAC                DNS
VPCS1  10.1.1.1/24          10.1.1.251        00:50:79:66:68:00  
VPCS2  10.1.2.1/24          10.1.2.252        00:50:79:66:68:01  
VPCS3  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02  
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03  
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04  
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05  
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06  
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07  
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08  

Now continue by pinging the default gateway (10.1.1.251), check the arp cache using the show arp command, then pinging PC2Sam, (VPCS2) whose IP address you can see from above is 10.1.2.1

VPCS[1]> ping 10.1.1.251
10.1.1.251 icmp_seq=1 ttl=255 time=8.741 ms
10.1.1.251 icmp_seq=2 ttl=255 time=3.502 ms
10.1.1.251 icmp_seq=3 ttl=255 time=1.943 ms
10.1.1.251 icmp_seq=4 ttl=255 time=3.289 ms
10.1.1.251 icmp_seq=5 ttl=255 time=2.909 ms

That worked, so there should be an arp entry for 10.1.1.251.

VPCS[1]> show arp
c2:00:10:ab:00:00  10.1.1.251

The arp entry is OK. When you ping a remote device, often the first ping times out if a router along the way has go through an arp request.

VPCS[1]> p 10.1.2.1
10.1.2.1 icmp_seq=1 timeout
10.1.2.1 icmp_seq=2 ttl=62 time=8.220 ms
10.1.2.1 icmp_seq=3 ttl=62 time=5.116 ms
10.1.2.1 icmp_seq=4 ttl=62 time=5.171 ms
10.1.2.1 icmp_seq=5 ttl=62 time=6.130 ms

Tip

RedPoint2

Notice that in the second ping, I didn’t type the whole word ping, I abbreviated “ping” to “p“. This can be done with any command, so long as you type enough to identify the command.

 

Lesson #2 – Command history, basic navigation and help

This lesson takes you through:

  • The use of the <up>, <down>, <left>, and <right> arrow keys
  • The help key (?)
  • The show history command
  • Changing from one VPC to another
  • Aborting output by pressing <Ctrl+c>

If you press the <up-arrow> then <down-arrow> keys, you will see that you can recall your previous commands. You can further edit these commands using the <left-arrow> and <right-arrow keys>. The command ? will give you a page of help, and from that help you can see there is a command show history which shows a list of the last 50 commands you have used – and hist can be abbreviated to as little as sh hi.

VPCS[1]> ?

?                        Print help
! [command [args]]       Invoke an OS command with the 'args' as its arguments
                  Switch to the VPC.  range 1 to 9
arp                      Shortcut for: show arp. Show arp table
clear [arguments]        Clear IPv4/IPv6, arp/neighbor cache, command history
dhcp [-options]          Shortcut for: ip dhcp. Get IPv4 address via DHCP
disconnect               Exit the telnet session (daemon mode)
echo               Display  in output
help                     Print help
history                  Shortcut for: show history. List the command history
ip [arguments]           Configure VPC's IP settings
load [filename]          Load the configuration/script from the file [filename] (startup.vpc is the default filename).
ping  [-options]   Ping the network  with ICMP (default) or TCP/UDP
quit                     Quit program
relay [arguments]        Relay packets between two UDP ports
rlogin []      Telnet to host relative to HOST PC
save [filename]          Save the configuration to the file [filename] (startup.vpc is the default filename).
set [arguments]          Set VPC name, peer ports, dump options, echo on or off
show [arguments]         Print the information of VPCs (default). Try show ?
sleep  [text]   Print  and pause the running script for 
trace  [-options]  Print the path packets take to network 
version                  Shortcut for: show version

To get command syntax help, please enter '?' as an argument of the command.

Tip

RedPoint2

Your history is kept from session to session. If you quit a VPCS session, it saves the current command history in a file called vpcs.hist, so even when you run this lab next time, your command history will be preserved from last time!

 

To access one of the other Virtual PCs, type a digit on a line by itself. In the example below, notice how I enter 2 to move to PC2, and then use the <up-arrow> to retrieve the ping command.

VPCS[1]> 2
VPCS[2]> ping 10.1.1.251

10.1.1.251 icmp_seq=1 ttl=254 time=4.113 ms
10.1.1.251 icmp_seq=2 ttl=254 time=7.437 ms
^C

Tip

RedPoint2

You can stop a ping (or tracert) command by pressing CTRL+c. Notice how the last ping shows only two ping replies, then ^C on the last line, indicating that the ping was interrupted

Lesson #3 – Unsuccessful pings

This lesson will illustrate:

  • An arp request failure trying to reach a non-existant local address
  • A ping timeout trying to reach a non-existant remote address
  • An ICMP type:3, code:1 (Destination Host Unreachable) reply

This time you will ping three non-existant addresses, one on PC1Bugs‘ local subnet, one to another subnet off the Yosemite router in the scenario, and the other to an address that is not part of this network at all.

VPCS[2]> 1
VPCS[1]> ping 10.1.1.2
host (10.1.1.2) not reachable

VPCS[1]> ping 10.1.2.2
10.1.2.2 icmp_seq=1 timeout
10.1.2.2 icmp_seq=2 timeout
10.1.2.2 icmp_seq=3 timeout
10.1.2.2 icmp_seq=4 timeout
10.1.2.2 icmp_seq=5 timeout

VPCS[1]> ping 4.4.4.4
*10.1.1.251 icmp_seq=1 ttl=255 time=4.660 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=2 ttl=255 time=2.389 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=3 ttl=255 time=2.793 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=4 ttl=255 time=3.353 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=5 ttl=255 time=3.166 ms (ICMP type:3, code:1, Destination host unreachable)

Notice that the first ping says that the local IP (10.1.1.2) was not reachable – in other words, the VPCS sent an ARP request, but did not receive a reply. See how this is different to the second ping, which would have been sent all the way to Yosemite router, and of course Yosemite would not have been able to reach the non-existant 10.1.2.2, so the pings timeout.

For the third ping to 4.4.4.4, the ICMP packet was sent to the default gateway as well, but this time the gateway did not have a path to 4.4.4.4, so the gateway sent back an ICMP message, type:3, code:1, which equates to Destination Unreachable (type=3), Host Unreachable (code=1). (See http://www.iana.org/assignments/icmp-parameters

for a list of ICMP code/type numbers)

Configuration Update

To explore the many other ICMP replies you might get, you will first have to change some of the routing tables on these routers to make them think the network is different to what it physically is. In summary, you will:

  • Tell router Albuquerque that the 2.0.0.0/8 network is reachable via the Seville router (so the Seville router will send back Destination Unreachable messages)
  • Tell router Albuquerque that the 3.0.0.0/8 network is reachable via the Seville router, AND tell the Seville router that 3.0.0.0/8 is reachable via Albuquerque (setting up a routing loop, so packets sent to a 3.x.x.x address will loop until the TTL expires)
  • Apply an access list on Seville to stop any TCP/UDP packets on port 80 reaching PC3Elmer (so the Seville router will send ICMP Destination Administratively Prohibited messages back to the sender)
  • Make sure Albuquerque is NOT an http server, so when you send a TCP ping to its port 80, it will reply with a TCP RST
  • Make sure Albuquerque is both a tcp small server, so when you send a TCP ping to the TCP echo port (port 7) it will reply
  • Make sure Seville is an http server, so when you send a TCP ping to its port 80, it will reply

To do this, cut and paste the following lines into the configuration of Albuquerque router:

enable
configure terminal
ip route 2.0.0.0 255.0.0.0 10.1.130.253
ip route 3.0.0.0 255.0.0.0 10.1.130.253
no ip http server
service tcp-small-servers
end

And cut and paste the following lines into the configuration of Seville router:

enable
configure terminal
ip route 3.0.0.0 255.0.0.0 10.1.130.251
access-list 101 deny tcp any host 10.1.3.1 eq 80
access-list 101 deny udp any host 10.1.3.1 eq 80
access-list 101 permit ip any any
interface fa0/0
ip access-group 101 out
exit
ip http server
end

Lesson #4 – Explore ICMP replies and options

This lesson shows you how to interpret a variety of ICMP replies and options.  In particular you will explore:

  • an ICMP type:3, code:1 (Destination Host Unreachable) reply from a remote router
  • an ICMP type:11, code:0 (TTL expired) reply
  • viewing the options of the ping command
  • controlling the TTL of the ping packets you send

To achieve this you will need to:

  • send a ping from PC1Bugs to something on the 2.0.0.0 network.  Albuquerque should now send it on to Seville, and Seville reply with an ICMP Destination Unreachable.
  • send a ping from PC1Bugs to something on the 3.0.0.0 network.  Albuquerque should now send it on to Seville, and Seville return it to Albuquerque and so on.
  • issue the ping command without an ip address to see the help about the ping options.
  • issue the ping command with the -T option to control the TTL values.

Start with a ping to something on the 2.0.0.0 network.  Recall you just configured Albuquerque (PC1Bugs’ default gateway) to think the 2.0.0.0 network was reachable via Seville.

VPCS[1]> ping 2.2.2.2
**10.1.130.253 icmp_seq=1 ttl=254 time=5.326 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.130.253 icmp_seq=2 ttl=254 time=9.323 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.130.253 icmp_seq=3 ttl=254 time=6.267 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.130.253 icmp_seq=4 ttl=254 time=5.789 ms (ICMP type:3, code:1, Destination host unreachable)

Note how the pings went to Seville, and Seville (10.1.130.253) replied with the ICMP Destination Unreachable messages (type:3, code:1) as expected.

Now test the loop condition you set up.  Recall you just configured Albuquerque (PC1Bugs’ default gateway) to think the 3.0.0.0 network was reachable via Seville, and you configured Seville to think the 3.0.0.0 network was reachable via Albuquerque.

VPCS[1]> ping 3.3.3.3
*10.1.130.253 icmp_seq=1 ttl=254 time=83.237 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=2 ttl=254 time=60.351 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=3 ttl=254 time=54.258 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=4 ttl=254 time=72.232 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=5 ttl=254 time=74.451 ms (ICMP type:11, code:0, TTL expired in transit)

Note how the pings looped until the TTL expired at Seville, which sent back ICMP TTL Expired messages (type:11).  Try that again, but this time change the TTL of the packets sent so that they start with an odd number rather than the default even number (64).   Issue a ping command by itself to see the ping options.

VPCS[1]> ping

ping <host> [options]
   Ping the network <host>. <host> can be an ip address or name
 options:
  -1             ICMP mode, default
  -2             UDP mode
  -3             TCP mode
  -P <protocol>  Same as above, setting ip protocol
                 1 - icmp, 17 - udp, 6 - tcp
  -c <count>     packet count, default 5
  -l <size>      data size
  -T <ttl>       set TTL, default 64
  -s <port>      source port
  -p <port>      destination port
  -f <flag>      tcp head flag, |C|E|U|A|P|R|S|F|
                           bits |7 6 5 4 3 2 1 0|
  -t             send packet until interrupt by Ctrl+C
  -i <ms>        wait <ms> milliseconds between sending each packet
  -w <ms>        wait <ms> milliseconds to receive the response

 Note: 1. Using names requires DNS to be set.
       2. Use Ctrl+C to stop the command.

Notice that the option to control the starting TTL value is -T. Use it in the following command.

VPCS[1]> ping 3.3.3.3 -T 3
*10.1.130.251 icmp_seq=1 ttl=255 time=6.718 ms (ICMP type:11, code:0)
*10.1.130.251 icmp_seq=2 ttl=255 time=4.172 ms (ICMP type:11, code:0)
^C

Note that this time, the TTL Expired (Type=11) message came from Albuquerque (10.1.130.251), because the TTL expired after 3 hops.

Lesson #5 – TCP & UDP pinging

This lesson shows you how to send packets to TCP and UDP ports, and interpret the results. You will:

  • use the -P and -p options with the ping command
  • see a successful VPCS TCP ping connection
  • learn how VPCS TCP ping works
  • observe an ICMP Administratively Denied (type:3, code:13) reply to a TCP ping
  • observe a TCP RST reply
  • see a successful VPCS UDP ping
  • observe that an unsuccessful UDP ping draws a ICMP Destination Port Unreachable (type:3, code:3)

To test the Access Control List (ACL), you will use one of the VPCS most powerful features – the ability to send packets to TCP and UDP ports.  To do this you will:

  • add a -P 6 (protocol=6, TCP) and a -p 23 (TCP port 23, telnet) and a -p 80 (TCP port 80, HTTP) to your “TCP” pings to see what happens when a TCP “ping” gets through, and when a TCP is denied by an ACL.
  • test a TCP “ping” to the Seville router as well, because you made it a HTTP server when you pasted the ip http server command.
  • see what happens when you try to send a “TCP ping” to Albuquerque TCP port 80 (Albuquerque is NOT an HTTP server – you made sure by pasting a no ip http server command)
  • observe the result when you send a TCP ping to the default TCP port (which happens to be port 7) on Albuquerque – that should work because you issued a service tcp-small-servers command on Albuquerque.

So here’s the plan:

From PC1Bugs

  • Ping PC3Elmer’s TCP port 23 – that should work
  • Ping PC3Elmer’s TCP port 80 – that should be denied by the ACL
  • Ping Seville router’s TCP port 80 – that should work, because you issued an ip http server command.
  • Ping Albuquerque router’s TCP port 80 – that should draw a TCP reset, because you issued a no ip http server command. It is NOT an http server.
  • Ping Albuquerque router’s default TCP port (TCP port 7 is the TCP echo port) – that should work, because you issued a service tcp-small-servers command.

Start by pinging Pc3Elmer’s TCP port 23

VPCS[1]> ping 10.1.3.1 -P 6 -p 23
Connect   23@10.1.3.1 seq=1 ttl=62 time=1311.560 ms
SendData  23@10.1.3.1 seq=1 ttl=62 time=12.115 ms
Close     23@10.1.3.1 seq=1 ttl=62 time=10.617 ms
Connect   23@10.1.3.1 seq=2 ttl=62 time=9.944 ms
SendData  23@10.1.3.1 seq=2 ttl=62 time=10.744 ms
Close     23@10.1.3.1 seq=2 ttl=62 time=17.752 ms
Connect   23@10.1.3.1 seq=3 ttl=62 time=8.096 ms
SendData  23@10.1.3.1 seq=3 ttl=62 time=12.436 ms
Close     23@10.1.3.1 seq=3 ttl=62 time=15.322 ms
Connect   23@10.1.3.1 seq=4 ttl=62 time=12.134 ms
SendData  23@10.1.3.1 seq=4 ttl=62 time=20.260 ms
Close     23@10.1.3.1 seq=4 ttl=62 time=17.187 ms
Connect   23@10.1.3.1 seq=5 ttl=62 time=13.777 ms
SendData  23@10.1.3.1 seq=5 ttl=62 time=11.590 ms
Close     23@10.1.3.1 seq=5 ttl=62 time=14.084 ms

A VPCs TCP ping works like this:

  1. A TCP SYN is sent, and if a TCP SYN/ACK is received, the VPC finishes the connection with an ACK and displays Connect, along with the time taken.
  2. A data packet (containing a few CR characters) is sent, and if TCP ACK is received, SendData is displayed, along with the time taken.
  3. A TCP FIN/ACK is sent, and if both an ACK and FIN/ACK are returned, the VPC finishes the termination handshake with an ACK and displays Close, along with the time taken.Sometimes the remote system, if it is not another VPC, may respond with a RST rather than a FIN/ACK, in which case VPC will display Close xx@x.x.x.x timeout

Now try pinging PC3Elmer’s TCP port 80 – that should be denied by the ACL

VPCS[1]> ping 10.1.3.1 -P 6 -p 80
*10.1.130.253 tcp_seq=1 ttl=254 time=9.455 ms (ICMP type:3, code:13, Communication administratively prohibited)
*10.1.130.253 tcp_seq=3 ttl=254 time=3.924 ms (ICMP type:3, code:13, Communication administratively prohibited)
*10.1.130.253 tcp_seq=5 ttl=254 time=6.600 ms (ICMP type:3, code:13, Communication administratively prohibited)

Note how the Seville router sent an ICMP Destination Unreachable (type:3) Administratively Prohibited (code:13) message for the TCP ping to PC3Elmer’s port 80. What a great tool to test ACLs!!

Next, try pinging Seville router’s TCP port 80 – that should work, because you issued the ip http server command on Seville.

VPCS[1]> ping 10.1.3.253 -P 6 -p 80
Connect   80@10.1.3.253 seq=1 ttl=254 time=12.448 ms
SendData  80@10.1.3.253 seq=1 ttl=254 time=215.492 ms
Close     80@10.1.3.253 seq=1 ttl=254 time=16.636 ms
Connect   80@10.1.3.253 seq=2 ttl=254 time=5.434 ms
SendData  80@10.1.3.253 seq=2 ttl=254 time=234.653 ms
Close     80@10.1.3.253 seq=2 ttl=254 time=13.759 ms
Connect   80@10.1.3.253 seq=3 ttl=254 time=6.927 ms
SendData  80@10.1.3.253 seq=3 ttl=254 time=232.419 ms
Close     80@10.1.3.253 seq=3 ttl=254 time=10.550 ms
Connect   80@10.1.3.253 seq=4 ttl=254 time=6.130 ms
SendData  80@10.1.3.253 seq=4 ttl=254 time=235.334 ms
Close     80@10.1.3.253 seq=4 ttl=254 time=11.846 ms
Connect   80@10.1.3.253 seq=5 ttl=254 time=5.188 ms
SendData  80@10.1.3.253 seq=5 ttl=254 time=202.523 ms
Close     80@10.1.3.253 seq=5 ttl=254 time=12.864 ms

That proves that Seville is indeed listening on port 80!

Time to ping Albuquerque router’s TCP port 80 – that should draw a TCP reset, because you issued a no ip http server command. It is NOT an http server.

VPCS[1]> ping 10.1.1.251 -P 6 -p 80
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned

As expected, Albuquerque is NOT listening on port 80, and says so!

Finally, test the effect of issuing the service tcp-small-servers command on Albuquerque by pinging Albuquerque router’s default TCP port (TCP port 7 is the TCP echo port).

VPCS[1]> ping 10.1.1.251 -P 6 
Connect   7@10.1.1.251 seq=1 ttl=255 time=8.001 ms
SendData  7@10.1.1.251 seq=1 ttl=255 time=6.384 ms
Close     7@10.1.1.251 seq=1 ttl=255 time=9.536 ms
Connect   7@10.1.1.251 seq=2 ttl=255 time=4.909 ms
SendData  7@10.1.1.251 seq=2 ttl=255 time=4.741 ms
Close     7@10.1.1.251 seq=2 ttl=255 time=6.241 ms
Connect   7@10.1.1.251 seq=3 ttl=255 time=3.352 ms
SendData  7@10.1.1.251 seq=3 ttl=255 time=4.962 ms
Close     7@10.1.1.251 seq=3 ttl=255 time=9.370 ms
Connect   7@10.1.1.251 seq=4 ttl=255 time=4.476 ms
SendData  7@10.1.1.251 seq=4 ttl=255 time=5.269 ms
Close     7@10.1.1.251 seq=4 ttl=255 time=7.219 ms
Connect   7@10.1.1.251 seq=5 ttl=255 time=4.735 ms
SendData  7@10.1.1.251 seq=5 ttl=255 time=7.637 ms
Close     7@10.1.1.251 seq=5 ttl=255 time=7.043 ms

Note that the last ping didn’t specify a port number – I just specified the protocol,  (-P 6) and the VPC sent it to TCP port 7, which is the well-known TCP echo port.

Tip

RedPoint2

The VPCS has some shortcuts for IP protocols 1, 6, & 17 – see the output of the ping help above. I could have said ping 10.1.1.251 -3 instead of ping 10.1.1.251 -P 6. Personally I prefer -P 6, because it makes me remember that TCP is IP protocol #6, which may be handy information in an exam one day!

And as you can see from the output above, all predictions were correct. That is:

  • The Ping to PC3Elmer’s TCP port 23 worked
  • The Ping to PC3Elmer’s TCP port 80 was denied by the ACL
  • The Ping to Seville router’s TCP port 80 worked.
  • The Ping to Albuquerque router’s TCP port 80 returned a TCP reset, because it is NOT an http server.
  • The Ping to Albuquerque router’s default TCP port worked, because you issued a service tcp-small-servers command.

Now let’s try some UDP pings. This time you will see some new ICMP replies – specifically ICMP Destination Port unreachable. When you send a TCP SYN packet to a device that is not listening on a particular port, the target device sends back a TCP RST (reset) segment. However, if you send a UDP packet to a device that is not listening on a particular port, the target device sends back am ICMP type:3, code:3 – Destination Port unreachable.

So here’s the plan:

From PC1Bugs

  • Ping PC3Elmer’s UDP port 99 – that should work – Virtual PCs respond to all UDP packets from other Virtual PCs
  • Ping PC3Elmer’s UDP port 80 – that should be denied by the ACL
  • Ping Seville router’s UDP port 99 – that should see an ICMP Destination Port Unreachable reply (type:3, code:3)

Starting with the ping to PC3Elmer’s UDP port 99

VPCS[1]> ping 10.1.3.1 -P 17 -p 99
10.1.3.1 udp_seq=1 ttl=62 time=7.920 ms
10.1.3.1 udp_seq=2 ttl=62 time=5.623 ms
10.1.3.1 udp_seq=3 ttl=62 time=4.979 ms
10.1.3.1 udp_seq=4 ttl=62 time=8.003 ms
10.1.3.1 udp_seq=5 ttl=62 time=6.732 ms

Now ping PC3Elmer’s UDP port 80 – that should be denied by the ACL

VPCS[1]> ping 10.1.3.1 -P 17 -p 80
**10.1.130.253 udp_seq=1 ttl=254 time=6.053 ms (ICMP type:3, code:13, Communication administratively prohibited)
*10.1.130.253 udp_seq=2 ttl=254 time=4.337 ms (ICMP type:3, code:13, Communication administratively prohibited)
^C

Finally, ping Seville router’s UDP port 99 – that should see an ICMP Destination Port Unreachable reply (type:3, code:3)

VPCS[1]> ping 10.1.3.253 -P 17 -p 99
*10.1.3.253 udp_seq=1 ttl=254 time=12.187 ms (ICMP type:3, code:3, Destination port unreachable)
*10.1.3.253 udp_seq=2 ttl=254 time=6.813 ms (ICMP type:3, code:3, Destination port unreachable)
^C

And as you can see from the output, all predictions were correct. That is:

  • The Ping to PC3Elmer’s UDP port 99 worked
  • The Ping to PC3Elmer’s UDP port 80 was denied by the ACL
  • The Ping to Seville router’s TCP port 99 caused an ICMP Destination Port Unreachable reply (type:3, code:3) reply.

Lesson #6 – Trying Tracert (traceroute)

Tracert actually uses the fact that routers send ICMP destination unreachable messages to trace the path through a network.  In this lesson, you will:

  • watch a tracert succeed
  • watch a tracert strike a ICMP Destination Unreachable reply along the path
  • watch a tracert detect a loop
  • control the number of hops that tracert will trace for

Using the existing topology, trace the path from PC1Bugs to

  • PC2Sam (10.1.2.1) – this should succeed
  • unknown remote address, 4.4.4.4 and 2.2.2.2 – you can expect that PC1Bugs’ default gateway (Albuquerque) will reply with a Destination Unreachable for the 4.4.4.4 address, and since you added a route to Albuquerque directing traffic to the 2.0.0.0 network to Seville, you can expect that Seville will reply with a Destination Unreachable for the trace to 2.2.2.2
  • unknown remote address, 3.3.3.3 – you can expect that Albuquerque will forward this to Seville, and Seville pass it back to Albuquerque and so on because I have engineered the loop with the route statements you added earlier.
VPCS[1]> trace 4.4.4.4
traceroute to 4.4.4.4, 64 hops max, press Ctrl+C to stop
 1   10.1.1.251   3.669 ms  1.977 ms  3.064 ms
 2   *10.1.1.251   2.238 ms (ICMP type:3, code:1, Destination host unreachable)

The ICMP type:3, code:1 is an ICMP Destination Host Unreachable, as was predicted.

Note that the default gateway router (Albuquerque) did actually reply to the first round of packets sent with a TTL of 1, proving that routers actually make the routing decision before they decrement the TTL.

Note that reply 2 has a * character at the beginning of the line to indicate that this reply indicates a failure of some kind.

VPCS[1]> trace 2.2.2.2
traceroute to 2.2.2.2, 64 hops max, press Ctrl+C to stop
 1   10.1.1.251   2.579 ms  3.204 ms  3.462 ms
 2   10.1.130.253   7.917 ms  4.209 ms  4.673 ms
 3   *10.1.130.253   12.890 ms (ICMP type:3, code:1, Destination host unreachable)

This time the trace got to Seville, but Seville has no route to the 2.0.0.0 network, so replied with the ICMP Destination Host Unreachable (type:3, code:1)

VPCS[1]> trace 3.3.3.3
traceroute to 3.3.3.3, 8 hops max, press Ctrl+C to stop
 1   10.1.1.251   2.979 ms  1.700 ms  2.143 ms
 2   10.1.130.253   6.280 ms  4.980 ms  5.108 ms
 3   10.1.130.251   9.438 ms  9.512 ms  4.398 ms
 4   10.1.130.253   4.758 ms  6.241 ms  6.453 ms
 5   10.1.130.251   6.460 ms  10.098 ms  7.811 ms
 6   10.1.130.253   8.771 ms  9.053 ms  8.533 ms
 7   10.1.130.251   11.545 ms  13.584 ms  9.932 ms
 8   10.1.130.253   10.501 ms  11.806 ms  12.095 ms

As expected, the trace ran back and forth between Albuquerque and Seville.

Note I could have stopped the trace earlier by hitting CTRL+c, or I could have limited the number of replies to say 4 by specifying the maxhops option.

VPCS[1]> trace 3.3.3.3 4
traceroute to 3.3.3.3, 4 hops max, press Ctrl+C to stop
 1   10.1.1.251   3.577 ms  2.185 ms  1.404 ms
 2   10.1.130.253   5.021 ms  3.862 ms  5.262 ms
 3   10.1.130.251   4.358 ms  4.557 ms  4.890 ms
 4   10.1.130.253   9.543 ms  9.636 ms  5.829 ms

By specifying the number 4 at the end of the trace command, the output was reduced. Normally, the default 8 hops is sufficient, but if you had a large network with more than 8 hops end-to-end, you might need to increase the maxhops

Lesson #7 – Fun Stuff

There are a few other features that haven’t been explored yet, but can be very useful especially for documentation and test scripts.  You are about to explore:

  • Changing the Virtual PCs display name
  • Changing a Virtual PCs IP address
  • Creating a VPCS script file
  • Running a VPCS script file
  • Editing a VPCS script
  • How to use the echo command
  • How to control the output of scripts the set echo on and set echo off commands

In this lesson you will:

  • Change Virtual PCs 1 -3 to names to match the diagram – ie PC1=Bugs, PC2=Sam and PC3=Elmer using the set pcname command.
  • Change the IP address of PC2Sam to 10.1.2.2/24
  • Save your configuration to a file called config1 using the save command
  • Execute a series of commands to load them into your history buffer
  • Quit VPCS to save your history buffer
  • Use a text editor to combine parts of your history buffer (vpcs.hist) with your script file (config1) to create a test script called script1.vpc
  • Document your script with comments and echo commands
  • load the text script1.vpc into VPCS using the load command
  • change the behaviour of your script by using the set echo on and set echo off commands

Start with the name changing as shown below.  Note that you can get help about the set command by typing set, and that the first attempt to set the pcname to PC1Bugs shows you that the maximum length of a pcname is 6 characters

VPCS[1]> set   

set [lport|rport|pcname|echo|dump], Set connection port, hostname or echo setting
    lport port      local port, listen by VPCS
    rport port      remote port, listen by dynamips
    pcname name     rename the current pc
    echo [on|off]   set echoing on or off
    dump [options]  set the packet dump flag for this VPC. 
                    Options:
                      detail  print protocol
                      mac     print ether address
                      raw     print the first 40 bytes
                      all     all the packets including incoming.
                              must use [detail|mac|raw] as well as 'all'
                      off     clear all the flag
VPCS[1]> set pcname PC1Bugs
Hostname is too long. (should be less than 6)

VPCS[1]> set pcname Bugs   

Bugs[1]> 2
VPCS[2]> set pcname Sam 

Sam[2]> 3
VPCS[3]> set pcname Elmer

Elmer[3]>

So far, the PC IP addresses have stayed constant, so for practice, change Sam’s IP address to 10.1.2.2, leave the gateway as 10.1.2.252 and set the mask to 24 bits

Elmer[3]> 2
Sam[2]> ip          

ip [arguments],
  Configure current VPC's IP settings
  arguments:
    <address> [/<mask>] [<gateway>]
    <address> [<gateway>] [/<mask>]
                   Set the VPC's ip, default gateway ip and network mask
                   Default IPv4 mask is /24, IPv6 is /64. In the ether mode, 
                   the ip of the tapx is the maximum host ID of the subnet. 
                   ip 10.1.1.70 /26 10.1.1.65 set the VPC's ip to 10.1.1.70, 
                   the gateway to 10.1.1.65, the netmask to 255.255.255.192, 
                   the tapx ip to 10.1.1.126 in the ether mode.
                   </mask> may be written as /26, 26 or 255.255.255.192
    auto           Attempt to obtain IPv6 address, mask and gateway using SLAAC
    dhcp -[d|r|x]  Attempt to obtain IPv4 address, mask, gateway, DNS via DHCP
          -d         Show DHCP packet decode
          -r         Renew DHCP lease
          -x         Release DHCP lease
    dns <ip> Set DNS server <ip>, delete if <ip> is '0'
    domain <name> set local domain name
    mtu <value> Set IPv4 MTU to <value>, at least 576. 

Sam[2]> ip 10.1.2.2/24 10.1.2.252
Checking for duplicate address...
PC2 : 10.1.2.2 255.255.255.0 gateway 10.1.2.252

Note how VPCS checks for duplicate addresses (by sending gratuitous arp requests) before allocating the IP address.

Note also, that since the default mask is 24 bits, I could have just issued the command, ip 10.1.2.2 10.1.2.152

Now that you have changed the hostnames and one of the IP addresses, it is a good time to save your configuration, and quit VPCSs, which will force VPCS to save the history file, which you will need in the next step.

Sam[2]> save config1
.........  done
Sam[2]> quit

Tip

RedPoint2

When VPCS saves files, it checks to see if your filename has an extension. If it doesn’t, VPCS automatically adds a .vpc extension, so the file you just saved will appear as config1.vpc on your disk

Start VPCS again by selecting Tools|VPCS from GNS3.  This will automatically load the original configuration (before you changed Sam’s IP address and the PC names) again.

So now load your config1 configuration configuration, and check it with the show ip all command.  You should see all your pcnames restored, and see the new ip address for Sam.

VPCS[1]> load config1

Executing the file "config1"


Checking for duplicate address...
PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251


Checking for duplicate address...
PC2 : 10.1.2.2 255.255.255.0 gateway 10.1.2.252


Checking for duplicate address...
PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253

Bugs[1]> show ip all

NAME   IP/MASK              GATEWAY           MAC                DNS
Bugs   10.1.1.1/24          10.1.1.251        00:50:79:66:68:00  
Sam    10.1.2.2/24          10.1.2.252        00:50:79:66:68:01  
Elmer  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02  
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03  
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04  
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05  
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06  
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07  
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08  

The next task is to create a new file which will become our second script file, and you will use the contents of the config1.vpc you saved in VPCS and the contents of vpcs.hist to create this script. In a file browser, navigate to the folder where you expanded these tutorial files (VPCS_Tutorial).  In that folder, you will find a configs folder. Open this folder and you will see the router configurations, the startup.vpc file, the config1.vpc file you just saved and your vpcs.hist file.

configsFolder

Create a blank file called script1.vpc in this folder.  In Windows  you can do this by right-clicking in the folder and choosing New|Text Document. Linux usually has something similar, and so to does Path Finder on OS X (but not Apple’s Finder program – you’re on your own).  Give this file the name script1.vpc.

Open this file with your favourite text editor.  In Windows. my favourite editor is Notepad++.  Put a comment right at the top something like this:

#Script file created for testing vpcs

Tip

RedPoint2

Comments can be placed in script files by starting the comment with the # character.

Now locate the file called config1.vpc in the same directory and open it also in your text editor. It should look like this:

1
set pcname Bugs
ip 10.1.1.1 10.1.1.251 24
2
set pcname Sam
ip 10.1.2.2 10.1.2.252 24
3
set pcname Elmer
ip 10.1.3.1 10.1.3.253 24
4
5
6
7
8
9
1

Copy and paste the first 9 lines into your script1.vpc file, and add four more lines saying:

1
echo Here is the beginning of the history file
echo Press <Enter> to continue
sleep 0

The command 1 on a line by itself is to ensure that we start at the correct PC. The echo command will display a message as our script is executing – you’ll what it means in a moment.

It should now look like:

#Script file created for testing vpcs
1
set pcname Bugs
ip 10.1.1.1 10.1.1.251 24
2
set pcname Sam
ip 10.1.2.2 10.1.2.252 24
3
set pcname Elmer
ip 10.1.3.1 10.1.3.253 24
1
echo Here is the beginning of the history file
echo Press <Enter> to continue
sleep 0

Now open (in the same directory) the file called vpcs.hist. In it you will find all the commands you have entered so far. If you have followed this tutorial to the letter, it should look like this:

show ip all
ping 10.1.1.251
show arp
p 10.1.2.1
?
sh hi
2
p 10.1.2.1
1
ping 10.1.1.2
ping 10.1.2.2
ping 4.4.4.4
ping 2.2.2.2
ping 3.3.3.3
ping
ping 3.3.3.3 -T 3
ping 10.1.3.1 -P 6 -p 23
ping 10.1.3.1 -P 6 -p 80
ping 10.1.3.253 -P 6 -p 80
ping 10.1.1.251 -P 6 -p 80
ping 10.1.3.1 -P 17 -p 99
ping 10.1.3.1 -P 17 -p 80
ping 10.1.3.253 -P 17 -p 99
trace 4.4.4.4
trace 2.2.2.2
trace 3.3.3.3
trace 3.3.3.3 4
set
set pcname Bugs
2
set pcname Sam
3
set pcname Elmer
2
ip
ip 10.1.2.2/24 10.1.2.252
save config1
quit

Now I want you to copy all of the command lines up to the last trace command from vpcs.hist, and then paste them after the echo command in script1.vpc.

Save the file in your text editor. Don’t close it, you have more to do yet.

And now let’s see this script run! Back in VPCs, load this updated script.

Bugs[1]> load script1

And watch all those commands being executed – did you see the message “Here is the beginning of the history file” appear?  Did you have to press the <Enter> key to continue when the sleep 0 command was executed?

Bugs[1]> load script1

Executing the file "script1"


Checking for duplicate address...
PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251


Checking for duplicate address...
PC2 : 10.1.2.2 255.255.255.0


Checking for duplicate address...
PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253

Here is the beginning of the history file
Press <Enter> to continue

NAME   IP/MASK              GATEWAY           MAC                DNS
Bugs   10.1.1.1/24          10.1.1.251        00:50:79:66:68:00
Sam    10.1.2.2/24          0.0.0.0           00:50:79:66:68:01
Elmer  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08

10.1.1.251 icmp_seq=1 ttl=255 time=401.632 ms
10.1.1.251 icmp_seq=2 ttl=255 time=316.965 ms
10.1.1.251 icmp_seq=3 ttl=255 time=270.417 ms
10.1.1.251 icmp_seq=4 ttl=255 time=402.962 ms
10.1.1.251 icmp_seq=5 ttl=255 time=460.386 ms

But if you look closely, you will see there is a problem – you can’t see exactly which commands are producing which output.   For instance – which PC issued the ping to 10.1.1.251? From this output, you can’t tell that. Never fear.  There is an answer for that.

Go back to your script1.vpc file in the editor, and add the single command at the top of the file (after your comment)

set echo on

Save the file again, and load it one more time. If you get sick of waiting for it to complete, hit <Ctrl+c>

Tip

RedPoint2

Script files can be aborted by hitting <Ctrl+c>

 

Now notice that while the script is executing, the command that produces the output is displayed before the command. This is the effect of the set echo on command. For instance, you can now that it was PC1 (Bugs) that issued the first ping command:

Bugs[1]> ping 10.1.1.251
10.1.1.251 icmp_seq=1 ttl=255 time=2.756 ms
10.1.1.251 icmp_seq=2 ttl=255 time=2.895 ms
10.1.1.251 icmp_seq=3 ttl=255 time=3.437 ms
10.1.1.251 icmp_seq=4 ttl=255 time=3.104 ms
10.1.1.251 icmp_seq=5 ttl=255 time=4.335 ms

Note that echo commands themselves do not get “echoed” even if “echo” is set to on.  You can check the status of the echo flag using the show echo command, and of course if you want to hide commands, you can turn the echo function off with the set echo off command.

Tips

RedPoint2

  1. You will generally want a set echo on command at the start of each script file you write.
  2. The state of the echo flag is only relevant in script files.  Commands entered at the command prompt never get echoed (this was not always the case in earlier versions!)

Lesson #8 – Saving you work.

I’ve kept this one for last, because I wanted to make sure that the script files worked as expected.  However, recall that I mentioned back in Lesson #1 that there was a file called startup.vpc.  If this file exists in the directory where vpcs is launched from, it will get executed.  This is what the file looks like now:

# The startup file for RedNectar's VPCS Tutorial
# 
1
ip 10.1.1.1/24 10.1.1.251
2
ip 10.1.2.1/24 10.1.2.252
3
ip 10.1.3.1/24 10.1.3.253

# Start at PC1
1
#Display the IPs
show ip all

However, you can easily update/overwrite this file using the save command. In fact, all you need to do to save your startup configuration file (startup.vpc) all you need to do is type the save command save and hit Enter.

Bugs[1] save
.........  done

However, you will loose any comments or additional commands that you may have placed there – in fact all that is really saved is names and IP addresses.  If you take a look at your saved startup.vpc now, it will look like this:

Bugs[1]> !type startup.vpc

1
set pcname Bugs
ip 10.1.1.1 10.1.1.251 24
2
set pcname Sam
ip 10.1.2.2 24
3
set pcname Elmer
ip 10.1.3.1 10.1.3.253 24
4
5
6
7
8
9
1

Tip

RedPoint2

Note how I used the ! character above to execute a Windows command from within VPCS. On Linux or OS X, I would have entered !cat startup.vpcs rather than !type startup.vpcs

That completes this lesson and the tutorial.  I hope you can now use this powerful tool more effectively.

Chris Welsh

http://rednectar.net

@rednectarchris

Footnote: What the VPCS DOESN’T do

The VPCS is a VERY useful troubleshooting tool when used in your GNS3 environment, and does everything you’d want it to do almost 100% of the time. There are some minor features not implemented that you might want to be aware of:

  1. VPCSs has no concept of MTU or IP fragmentation.  If you ask it to send a ping of 2000 bytes, it will.  All in one packet!  This makes it impossible to use to test IP fragmentation.
  2. Still on the fragmentation, if you send a Virtual PCs host a ping that arrives in fragments, it can’t put the fragments back together, so the pings will fail.
  3. The DF (Don’t Fragment) bit on your pings is set by default, so you can test links with MTUs less than 1500 OK – however, if you want to set fragmentation across that link, you can’t turn the DF bit off.
  4. Similarly, other fancy IP options, like record route can’t be set either.
  5. Virtual PCs don’t have any layer 3 routing capability beyond a default gateway.  Therefore Virtual PCs can’t act upon ICMP re-directs if it ever receives one.
  6. IPv6 implementation is basic.  It doesn’t do many of the things expected by an IPv6 client, but you can assign it a static IPv6 address, and it will learn it IPv6 address via SLAAC.

 

 

Posted in GNS3, Cisco, GNS3 WorkBench, vpcs | Tagged , , , , | Leave a comment

GNS3 WorkBench v8.7 is ready for download

It has taken a while, but I’ve finally got all the files for GNS3 WorkBench v8.7 uploaded to sourceforge.

ICND1ReadinessTestTopologyAnd the Windows version (and OS X version) is better than ever. You can now enjoy all the exercises and labs of GNS3 WorkBench without having to download a whole Virtual Machine!   Just use the link to the v8.7_Windows_OSX version to download a zip file that you can add to your existing GNS3 install – including the new awesome ICND1 Readiness Test

Like v8.6, there are three versions to choose from:

v8.7_Windows_OSX: just the Labs and Exercises that make up GNS3 WorkBench in OS independent format
v8.7_Appliance: a “ready made” Virtual Machine split into two files (~2G) or twenty-three smaller files (all < 1G)
v8.7: a collection of script files and compressed images to do a “do it yourself” install on your existing Linux Mint 17.0 or Ubuntu 14.04 machine

The major difference between v8.6 and v8.7 is the addition of the challenging ICND1 Readiness Test, as well as updating the instructions for all labs to relate more closely to the “snapshot” idea. The script file that updates your topology files if you have a different IOS image to the recommended version has also been updated.

Yours to enjoy

RedNectar

Posted in Cisco, dynamips, GNS3, GNS3 WorkBench, Labs, Router Configuration | Tagged , , , , , , , , | 3 Comments

ICND1 Readiness Test

Recently I had a student (let’s call him David) ask me “Do you think I am ready to sit the ICND1 exam?”

Although David had studied the ICND1 text book, his skills were lacking when it came to configuring routers.  He had a copy of GNS3 WorkBench, and a copy of the GNS3 Network Simulation Guide, but had not completed all the GNS3 WorkBench exercises, so I sent him off telling him that he should at least complete ALL the ICND1 GNS3 exercises that he had at his disposal.  But It occurred to me that I didn’t have a monster exercise that I could give to David to test as many of the ICND1 Exam objectives as possible.

So David, I created that monster exercise. I called it the ICND1 Readiness Test. Be challenged!

 

 

RedPoint2.           .

The ICND1 Readiness Test is part of the new v8.7 GNS3 WorkBench distribution.  You can download the GNS3 WorkBench exercises (including the ICND1 Readiness Test) to run on your existing installation of GNS3 on your Windows or Macintosh PC here.  Or if you want the full bells-and-whistles install, go to this download and follow the instructions to install GNS3 WorkBench on your Linux Mint 17.0 32bit (or Ubuntu 14.04 32 bit system).  If you don’t have a Linux system but still want the whole integrated GNS3 WorkBench environment, you can download the GNS3 WorkBench VMware appliance here.

The exercise looks like this (Click on the image for a closer look):

ICND1 Readiness Test

Your job is to design and implement IPv4 and IPv6 addressing schemes for your company rednectar.net.

The instructions go on to tell you

Rednectar.net’s internal devices are arranged on two VLANs – a Users VLAN and a Servers VLAN, with a third Guest VLAN providing web browsing access for guests. Rednectar.net’s Service Provider has allocated the public IP address range of 192.0.2.184/29 and informed you that it will provide Internet services for you via the public IPv4 address 192.0.2.185 and DNS services via their DNS Server at 192.0.2.192. The address range 2001:db8:beef::/48 has been allocated for IPv6 addresses.

To complete this activity successfully, you design and implementation must meet the following criteria:

And so on to describe the criteria in relation to the ICND1 exam topics.  You can see the full description later in this post.

 

RedPoint2

.           .

If you can complete this exercise within an hour, I’d suspect there’s a good chance that you are ready for the ICND1 exam – although there are other objectives that are not covered here, so you’d need to be sure you have those under control as well.

But don’t expect that you’ll do this exercise in an hour the first time you
try.  In fact, you should probably take a good day or two to go through
it slowly the first time you try.  But because you have to start by
designing your own IP addressing scheme, you can do this exercise over and
over again using different IP addresses.  Or use this layout as a
template to create your own exercise.

As well as the full configuration exercise, you also get three troubleshooting exercises, each with three items you have to solve.  And of course, there is a set of sample completed configurations and a ICND1 Readiness Test Testing Walk Through as well, that describes all the tests you need to do to verify that you have completed the task.

Here is the full description of the exercise.  If you think you are ready for ICND1, give it a shot! Continue reading

Posted in Cisco, dynamips, GNS3, GNS3 WorkBench | Tagged , , , , , , , , , , , , | 3 Comments

How to find the zero subnet and broadcast address of a given IP address

I’ve just received an email asking for help.

Would you please clarify this concept for me on how to find the zero subnet and broadcast address of a given IP address.

For Example: The given IP address was 200.1.2.0/28

My Working:

255.255.255.240
200.  1.  2.  0
200.  1.  2.  0 Zero Subnet
200.  1.  2. 16
200.  1.  2. 32
200.  1.  2. 48
...
...
200.  1.  2.240

Is 200.1.2.240 the Subnet Broadcast? Or 200.255.255.240?

My reply:

Alfred,

You have exactly the correct answer (200.1.2.240)… but you have asked the wrong question! And your confusion is understandable.

Firstly there are two concepts

The subnet broadcast is the address that can be used to send information to all hosts on that subnet.

The broadcast subnet is the last subnet that can be assigned for a given subnet mask, just as the zero subnet is the first subnet that can be assigned for a given mask.

Given the context of your question, I think you meant to ask

Is 200.1.2.240 the Broadcast Subnet? Or 200.255.255.240?

To answer this question, you have to ask yourself “Am I dealing with a class A, class B or class C address?

Since you are dealing with a class C address, the first three octets are never going to change, so the 200.1.2.240 answer is correct.

If however, you were dealing with a class B address, like 150.1.2.0, only the first two octets would stay fixed, so the working (using the 255.255.255.240 mask again) would be:

255.255.255.240
150.  1.  2.  0 (Zero subnet)
150.  1.  2. 16
150.  1.  2. 32
...
150.  1.  2.240
150.  1.  3.  0
150.  1.  3. 16
...
150.  1.255.240 (Broadcast subnet)

Which would make 150.1.255.240 the broadcast Subnet.

The alternate answer you gave (200.255.255.240) is more like what you would see for a class A address, like 100.1.2.0, because with class A addresses, only the first octet is fixed.

255.255.255.240
100.  1.  2.  0 (Zero subnet)
100.  1.  2. 16
100.  1.  2. 32
...
100.  1.  2.240
100.  1.  3.  0
100.  1.  3. 16
...
100.255.255.240 (Broadcast subnet)

 

Posted in GNS3 WorkBench | 1 Comment

Building a new GNS3 WorkBench lab

Building a new GNS3 WorkBench lab

[Note: The procedures described in this post are dependant on the reader
having a copy of GNS3 WorkBench Virtual Machine v8.7 or later]

GNS3 WorkBench comes with lots of labs, but building a new lab – with
instructions snapshots and prepared configurations is not a trivial
task.  However, I’ve added some scripts that help me create a new
lab.  If you think you’d like to build your own labs, then follow me
as I build a new lab.

Step 1: Build the topology and final configuration

I’ll start by creating a new project in GNS3 (in the GNS3 WorkBench Linux
Virtual Machine – the scripts I use are not going to run on
Windows).  The project I’m creating is called ‘ICND1
Readiness Test
‘. This will be an
ICND1 level exercise, so I want to create this project in the /home/user/GNS3/WorkBench/Projects/ICND1
Exercises
directory, therefore I change the Project
Directory
too.  And this project will have an Etherswitch
router and crypto keys, so I’ll check the Save nvrams including
EtherSwitch VLANs and crypto keys
option.

NewProject

Next I’ll build the topology that I want, and configure the routers as I
want them in the final configuration.  During this process, I keep a
copy of BlueGriffon
opened where I create the page which will later become the snapshot0.html
instructions page for the project.  When I’ve got the topology
finished, I’ll also create a script file called check-answer.vpc
for the Virtual PC Simulator (VPCS) which can be used to test most of the
configurations, but I’ll discuss that in a separate section – but if you
see references to check-answer.vpc then keep in mind the purpose
of this file.

ICND1 Readiness Test Topology

Step 2: Put the WorkBench template files in place

Once I am happy with the project, I save the project making sure that I
have the GNS3 option to [x] Include a screenshot when saving a
project
checked in Edit | Preferences <-General -
[General Settings]
– this makes sure I get a topology.png
file created which is used in several places.  IN fact, it is worth
spending some time to get the topology looking just right on the screen
before you save.

I then quit GNS3 and start using a set of scripts that are found in the /home/user/GNS3/WorkBench/Scripts/WBDev
directory.  They are:

addPWDToPATH.sh
changeIcon.py
labPreparer.sh
labRenamer.sh
replacer.sh

 

Tip:072011_0413_VMWareInter6.png The main scripts are labPreparer.sh  and 
labRenamer.sh
, but I’ll want to run these
scripts from a command window, and I don’t want to have to be
writing commands like  /GNS3/WorkBench/Scripts/WBDev/labPreparer.sh
all the time, so I run the addPWDToPATH.sh script from
this directory to begin with.  That puts the /GNS3/WorkBench/Scripts/WBDev
directory in my path, but I do have to log out and log in again
after running it.  Note, that I only ever have to do this one
on any one VM, and then you are good forever after that.

From the /home/user/GNS3/WorkBench/Projects/ICND1 Exercises/ICND1
Readiness Test
directory, I run the labPreparer.sh script.
This Script that takes a GNS3 project (in this case the ICND1 Readiness
Test
), and copies a bunch of skeletal files to the project – basic
help files (instructions), some snapshot directories and an openMeFirst.net
topology file which will replace topology.net later.  It also
copies the current configs and working directories to
the new snapshot directories.  After running this script, my
project directory looked like this (The selected files/folders are the
original files/directories):
afterRunning labPreparer.sh

The problem is, all of these template files use the word WBProjectName
both in the naming of the files, and in the files within the help
system.  Ideally, we would rather have WBProjectName
replaced by the name of the project.  That is where the next script
comes in.

Step 3: Rename files and replace text

To tidy up the copied template files, I next run the labRenamer.sh
script.  If I run the labRenamer.sh script,  all
occurrences of WBProjectName in any file or filename, will
be replaced by the name of the GNS3 project as indicated by the current
directory name – in this case ICND1 Readiness Test.

Tip:072011_0413_VMWareInter6.png The labRenamer.sh script can also be run with a
parameter if you need to rename a project.A command like  labRenamer.sh “ICND1 Challenge”
would take all occurrences of the current directory name (in this
case ICND1 Readiness Test) found in any instructions files
associated with this project, and change them to ICND1
Challenge
– including any filenames, directory names and even
the current directory. Which, by the way, will leave the script in a
state of limbo when it exits because the current directory has been
renamed.  You will be prompted to issue a cd .
command in this case to get your bash shell to workout what the
current directory is.

The labRenamer.sh script exits with a message:

Done - ready to edit instructions.

which takes me to the next step, with the project folder now looking like:

afterRunning labRenamer.sh

Step 4: Edit instructions

Looking now inside the instructions folder off my project I will
find the .html skeleton files for my project. In this example, off
the /home/user/GNS3/WorkBench/Projects/ICND1 Exercises/ICND1 Readiness
Test/instructions/
directory.  They are:

console.png
instructions.html
navigation.html
snapshot0.html
snapshot1.html
snapshot2.html
snapshot3.html
snapshot9.html
snapshotHelp.html
start.png
topology.html
topologyicon.png
topology.png

Opening the instructions.html file in my browser shows
me the general layout of these files in the system:

instruntions.htmlRoadmap

What I will have to do now is edit these html files in the instructions
directory to suit your project.  I could do this by hand using a text
editor, but I’m going to use the BlueGriffon
html editor.  The files I’ll have to edit are:

File Purpose
snapshot0.html This is the default content that is shown
when the project is opened or the user chooses Help |
Instructions
.  It describes the main scenario, and
should always include a link to the topology.html file
that will display the topology. It should describe the exercise.
snapshot1.html Once the final configurations are worked out, it is a relatively
simple task to create a troubleshooting
exercise based on the same configurations.  I typically use snapshot1
as the troubleshooting exercise, but it could be set up as another
exercise based on the same configuration.
snapshot2.html snapshot3.html

…etc

It is possible of course keep adding as many variations and
exercises as needed.  If the original exercise had some routers
already configured, I often make a challenge exercise where the user
has to configure all the routers from scratch.By default, you get templates for snapshot2.html and
snapshot3.html
.  If you want to use a 4th or more
snapshots, you will have to create them yourself by copying one of
these, as well as edit navigation.html (see below)
snapshot9.html If I make a set of solution configurations, I’ll make them
available as snapshot 9 (Completed WBProjectName exercise).
If there are two different solutions, I’ll make the second solution
available as snapshot 8 (Completed Alternate WBProjectName
exercise)
etc.  snapshot9.html will
probably only need minimal editing – I usually find that the default
setup is just fine.
navigation.html If I plan on having any more or less than four snapshots plus a
solution, then I will have to edit the navigation.html
file to add/remove links to the other snapshot instructions.Also, if my project requires special pages, I can add links to them
here.
topology.html I probably won’t need to edit this file, because it is
automatically set up to display your saved topology.png,
but if I needed to add more topology detail, I could add it here.

I’ll start by opening snapshot.0.html as an individual file in
BlueGriffon.
Pretty soon, it begins to look like:

snapshot0.htmlInBlueGriffonText

or in Wyswyg view:

snapshot0.htmlInBlueGriffonWysiwyg

I make sure I get the instructions for snapshot0 quite polished
before I try any of the other variations.  But by this stage I have
to be careful, because I’ve already created my base snapshots (not by
using the File | Manage snapshots option in GNS3, but by
copying files in the GNS3 snapshot format).  My final configurations
are actually living in the snapshot folder called topology_9
(Completed ICND1 Readiness Test)_snapshot_191013_000000
, so it is
the topology.net file in this directory that I’ll have to work
with from now on if I need to make any further changes to the final
configurations!

finding topology.net

Step 5: Create the snapshot scenarios

Recall back in Step 2, there were three snapshot scenarios copied
created, based on the current configuration at the time you ran the labPreparer.sh
script.  This gave your project five snapshots/scenarios which are
virtually identical. It is time to sort them out.

For this exercise, I’ll only want the basic topology_0, topology_1
(Troubleshooting)
and topology_9 (Completed) snapshots,
so I’ll delete the other snapshot folders (topology_2* and topology_3*).

I leave topology_9 as the “solution” to the exercise, so it is
almost already prepared.  The configs directory with the
prepared router configurations and startup.vpc file is
ready.  The only other change I make is that I open the topology in
GNS3 and add a textual comment to remind me that this is the final
configuration.  Now, if I ever forget which snapshot I have restored,
I have my message to remind me:

annotaed topology_9.net
Next, I will re-visit the base snapshot topology – topology_0.
Again, I’ll do this by directly working with the files within the snapshots
directory, rather than via GNS3’s File | Mange snapshots.
Since topology_0 (ICND1 Readiness Test) is the initial
configuration, all I need to do is to delete the configs for the routers
that need to be configured for the exercise – but one of these routers is
actually a EhterSwitch router, so I’ll need to do
something special about the working directory.

Firstly, I’ll look inside the topology_0 snapshot:

insideThe topology_0 Snapshot

I have four tasks I need to do here.

    1. Firstly, I need to open the topology.net file and add my
      comment to identify this as topology_0 as I did with topology_9
      above.

annotaed topology_0.net

    1. Next, I need to edit R1.cfg, R2.cfg and SW1.cfg
      files.  The ServiceProvider.cfg file needs to be kept
      intact, so no changes there.  One option would be to actually
      delete these files, but that would mean that users would then start with
      partially configured routers (based on the baseconfig.txt file
      for the IOS being used).  So instead, I edit the router configs to
      say simply:
do setup

but the SW1.cfg file is a bit more tricky, because it need to
keep some of the basic config (in particular, the duplex and speed
settings for the interface range fa1/0 – 15) so for this file I change the
config to:

interface FastEthernet0/0
 description *** Unused for Layer2 SW ***
!
interface FastEthernet0/1
 description *** Unused for Layer2 SW ***
!
interface range FastEthernet1/0 - 15
 duplex full
 speed 100
!
do setup
    1. However, that is not quite enough to completely erase the config on
      the switch – because there were VLANs and crypto keys created.  To
      deal with them, I have to remove all the files in the working
      directory, or at least the three files that have SW1
      in their names:
c3725_SW1_rom
c3725_SW1_slot0
c3725_SW1_slot1

In actual fact, I remove all the files in the snapshot’s working
directory, because I also want to remove the crypto keys for the other
routers too.

    1. The final task is to edit the startup.vpc file.
      Configuring the VPCS is one of the tasks that will be required in this
      exercise, but the Virtual PC representing http://www.example.com
      will need to have its configuration preserved.  Also, I like to add
      a few extra messages to the startup.vpc file, so that it will
      look like this:
# The startup file of VPCS
# 
9
set pcname www
ip 93.184.216.119 93.184.216.1 24
ip 2001:db8:dead::2/64
1
show ip all
echo
echo When you have completed the exercise, check your answer by issuing the following command:
echo load check-answer.vpc
echo

I will now repeat this process more or less as appropriate for topology_1,
except that if I’m doing a troubleshooting exercise I will leave the
configs intact apart from one or two changes, and probably leave the working
directory alone.  And if I wanted a second troubleshooting exercise,
I’d just make a copy of topology_1 snapshot, rename it and
adjust.

Of course there is one more thing that I need to do to complete the
troubleshooting snapshot – I will have to edit the snapshot1.html
file in the instructions directory to describe the nature of the
troubleshooting exercise that I want.  And of course repeat for as
many snapshots that I want to appear in the list.

I will also have to edit the navigaion.html file in the instructions
directory to add new links or remove unwanted links to snapshots.

editing navigation.html

Step 6: Create the check-answer.vpc script (optional)

In actual fact, I normally do this step as part of Step 1, but since it
is optional, I didn’t want to get too deep too early.  The whole idea
of a check-answer.vpc is to give the user a way of checking the
connectivity aspects of the exercise.  VPCS is especially good at
checking access control lists (ACLs), so in the exercise I’m building
here, it is essential that I have a good script.

Note: Since I’m creating the script after setting up
the skeleton snapshots, I’ll have to copy the completed check-answer.vpc
to the configs directory within each snapshot when I’m
finished.

This script has to created by hand in a text editor, and the way I start
is actually with the text of the snapshot0.html file – because
that is where I will find descriptions of the tasks that have to be
carried out.  I want to be sure that I echo messages to the console
as the tests are taken. I won’t be able to check every detail, but I’ll
check the ones that I can.  Here is the first section of check-answer.vpc
that I created for the ICND1 Readiness Test project:

set echo off
echo ***************************************************************************
echo This is the check-answer.vpc script for the ICND1 Readiness Test.
echo It will NOT test all completion criteria, you will have to assess some
echo items by yourself.
echo
echo ***************************************************************************
echo Press <ctrl+c> (multiple times) to stop, <enter> to continue.
sleep 0
echo ***************************************************************************
echo Checking dhcp address assignment for VPCS 1. You should see output similar to:
echo DDORA IP x.x.x.x/xx GW x.x.x.x
1
ip dhcp
echo Checking DNS and DOMAIN NAME assignments:  You should see the lines:
echo DNS         : 192.0.2.192
echo DOMAIN NAME : rednectar.net 
echo in the output of the following 'show ip' command
set echo on
show ip
set echo off
echo ***************************************************************************
echo Press <Ctrl+c> (multiple times) to stop, <enter> to continue to obtain the
echo dhcp addresses for VPCS 2-5
sleep 0
set echo on
echo Checking dhcp address assignment for VPCS 2.
echo
2
ip dhcp
echo ***************************************************************************
echo Checking dhcp address assignment for VPCS 3.
echo
3
ip dhcp
echo Checking dhcp address assignment for VPCS 4.
echo
4
ip dhcp
echo ***************************************************************************
echo Checking dhcp address assignment for VPCS 5.
echo
5
ip dhcp
echo Checking DNS and DOMAIN NAME assignments:  You should see the lines:
echo DNS         : 192.0.2.192
echo DOMAIN NAME : rednectar.net 
echo in the output of the following 'show ip' command
show ip
set echo off
echo ***************************************************************************
echo Now would be a really great time to check your DHCP server and issue a
echo 'show ip dhcp bindings' command on R2
echo Press Press <Ctrl+c> (multiple times) to stop, <enter> to continue testing NAT
sleep 0

As you can see, creating a thorough VPCS script can take some time.
To give your VPCS devices access to the script, it must be saved in the configs
directory of the appropriate snapshot(s).

Step 7: Tidy up

There are four things remaining before the project becomes a
fully-fledged GNS3 WorkBench Project.  I have to:

  1. Setup the folder icon for the ~/GNS3/WorkBench/Projects/ICND1
    Exercises/ICND1 Readiness Test
    directory
  2. Create script files in the ~/GNS3/WorkBench/Projects/ICND1
    Exercises/ICND1 Readiness Test
    directory to run each of the
    snapshots.  These scripts are used by the shortcuts on the GNS3
    WorkBench desktop
  3. Create the above mentioned desktop shortcut for the new project
  4. Clear the development configuration so the first-time user is forced
    to load a snapshot if they open the project from within GNS3 or by
    double-clicking the topology.net file.

And of course, there are scripts to do all of the above:

Task 1: Setup the folder icon for the project’s base directory

I’ll start by opening a command prompt in the project’s base directory ~/GNS3/WorkBench/Projects/ICND1
Exercises/ICND1 Readiness Test
.  From here I run the command:

changeIcon.py . instructions/topologyicon.png

Note carefully the period (.) character in the middle of that command -
it tells the script to update the icon of the current directory.
I could have of course typed the command as:

~/GNS3/WorkBench/Scripts/WBDev/changeIcon.py ~/GNS3/WorkBench/Projects/ICND1\ Exercises/ICND1\ Readiness\ Test ~/GNS3/WorkBench/Projects/ICND1\ Exercises/ICND1\ Readiness\ Test/instructions/topologyicon.png

 

Tip:072011_0413_VMWareInter6.png Alternatively I could have run the updateIcons.sh script
found in the ~/GNS3/WorkBench/Scripts/Administrative directory
– which would have done the same job – but would have also updated
EVERY other icon in the GNS3 WorkBench system.

This script changes the folder icon from looking like this:

folderIconPreScript

to this:

folderIconAfterScript

Task 2: Create script files in the project’s base directory

Each project gets a series of script files created in the project’s base
directory that, when run, copy the contents of one of the snapshots into
the base directory, including the configs and working
directories and then runs GNS3. The purpose of these scripts is
twofold.  One is to make it easy for users to load a snapshot from
the command line or the file browser, the other is to make it possible to
create shortcuts on the desktop that achieve the same purpose.

From the command prompt in the project’s base directory ~/GNS3/WorkBench/Projects/ICND1
Exercises/ICND1 Readiness Test
I run the command:

createRunSnapshotLaunchers.sh

This script actually copies a template script once for every snapshot, so
if I have three snapshots called:

0 (ICND1 Readiness Test)
1 (ICND1 Readiness Test Troubleshooting)
9 (Completed ICND1 Readiness Test)

then the script will create launchers called:

runSnapshot.0 (ICND1 Readiness Test)
runSnapshot.1 (ICND1 Readiness Test Troubleshooting)
runSnapshot.9 (Completed ICND1 Readiness Test)

 

Tip: The createRunSnapshotLaunchers.sh script can be run with
a -all option, which will create ‘runSnapshot.x….
scripts for the entire GNS3 WorkBench and GNS3 Vault structure.

Task 3: Create a shortcut on the Desktop

Now that I have created a new IDND1 WorkBench Project, I’ll want it to
appear in the ICND1 Exercises (Shorcuts) folder on the Desktop.
The script to create the Desktop shortcuts will actually re-create all
the Desktop shortcuts, and must be run from the ~/GNS3/WorkBench/Scripts/Administrative
directory like this:

cd ~/GNS3/WorkBench/Scripts/Administrative
updateIcons.sh

This script examines all of the project directories under the base GNS3
WorkBench directory (~/GNS3/WorkBench/Projects) and searches
first for a directory on the Desktop with a similar name to one
of the directories under ~/GNS3/WorkBench/Projects. If it
finds a folder that hasn’t got the equivalent shortcut folder on the
desktop, it offers to create it.  Next, is searches for a ‘runSnapshot.0...’
script in each project directory, which would have been created by the ‘createRunSnapshotLaunchers.sh
script I ran earlier.  Each time it finds a ‘runSnapshot.0…
script, it creates a desktop shortcut to run that script, or if there is
none, it will offer to create a shortcut to a ‘runSnapshot.continue
script. It also updates the icons for the folders on the Desktop.

Having run the script, I now see the shortcut when I open the Desktop
folder called ICND1 Exercises (Shortcuts)

desktopShortcutIcon

Task 4: Clear the development configuration

The final step is to save confusion if the exercise is loaded the first time
from within GNS3 or by opening topology.net from the file
browser.  I want to force the user to load one of the snapshots, so I
have a special copy of topology.net that I use for that purpose.  It
was copied to the project directory back in Step 2 and is called openMeFirst.net.
To make sure this topology is indeed opened first, I copy it over the
original topology.net like so:

cd ~/GNS3/WorkBench/Projects/ICND1 Exercises/ICND1\ Readiness\ Test
cp openMeFirst.net topology.net

Now if anyone opens the topology.net file before a
snapshot has been restored will see:

openMeFirst

And like most of the other tasks, I have a script that will repeat this
job for all projects if I want to refresh the system ready for a new
user.  The script file is found in the ~/GNS3/WorkBench/Scripts
directory and is called prepForNewuser.sh.  When you run
this script, it will not only copy over all the primary topology.net
files in every project’s base directory, but will also wipe out any files
in any configs directory working directory
or qemu-flash-drives directory ready for fresh files to be
copied into these directories whenever a snapshot is restored.  Here
is a sample of the output of prepForNewuser.sh

user@GNS3WB86 ~/GNS3/WorkBench/Scripts $ ./prepForNewUser.sh 
********************************************************************************
              Copying base topologies to GNS3 WorkBench Projects.               
This script prepares a GNS3 WorkBench environment for a new user by:
a) deleting any configurations saved by the current user, and 
b) copying /home/user/GNS3/WorkBench/Scripts/Templates/openMeFirst.net 
to be the base topology.net for all GNS3 WorkBench projects, and by copying
/home/user/GNS3/WorkBench/Scripts/Templates/openMeFirst.vault.net. 
to be the base topology.net for all GNS3 Vault projects so that users know that
they need to load a snapshot before commencing.
It will destroy any topology.net files saved in the GNS3 WorkBench/GNS3 Vault
directory structure as well as deleting any saved configurations
********************************************************************************
 

Do you want to continue? Y/N [y] y
Updating GNS3 WorkBench topology.net files
Updating GNS3 Vault topology.net files

Step 8: Enjoy and distribute

If anyone would like to create their own exercises and distribute them,
complete the step up till the end of Step 6.  Then you can compress
your project file and submit it – either send it to me,
or submit it on the GNS3
Forum
.  Either way, I’m sure there will be some folk who will
appreciate your efforts.

 

RedNectar

Posted in Cisco, dynamips, GNS3, GNS3 WorkBench | Tagged , , , , , , | 3 Comments