Many people are not aware of how to make the best use of the features the the Virtual PCs (VPCs) program, so I thought I’d run a small tutorial.
Technical note: This tutorial was written using VPCs version 0.21 – and some of the functions described here will not work exactly the same on 0.20a, and for version 0.16 – you will have to use echo instead of TCP and UDP ping options.
To get started, I’ll assume you are working with the GNS3 Workbench, and have access to some working configurations. To keep things simple, I’m going to start with the nice triangular network that is found in Wendell Odom’s CCNA books. (If you are not working with the GNS3 Workbench, then download the topology, config and startup.vpc files here). Or of course, you could just build your own network based on the diagram below.
To get to the working example, start by double-clicking the GNS3 Files-More exercises here icon. This will open up a folder of exercises, and from there open the exercise 3Router-ICND_Book_Example. In this folder you will see several files whose name begin with startup… Find the file called startup.2 (eigrp configured) and double click on it. You will be prompted with:
Do you want to run “startup.2 (eigrp configured)”, or display its contents?”
Click on Run and the lab will load.
In the GNS3 application, from the menu 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 VPCs.
Start by activating the VPCs Konsole window. You should see:
To access one of the other VPCs, 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.
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)
Now test the loop condition you set up.
From PC1Bugs
And as you can see from the output above, all predictions were correct. That is:
So here’s the plan:
From PC1Bugs
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.
Note I had to stop the trace by hitting CTRL+c, but I could have limited the number of replies by specifying the maxhops option.
Now that you have changed the hostnames and one of the IP addresses, it is a good time to save your configuration, and quit VPCs, which will force VPCs to save the history file, which you will need in the next step.
So now reload your configuration, and check it with the show command. You should see all your pcnames restored, and the ip address for Sam has changed.
Create a blank file called script2 in this folder – you can do this by clicking File->Create Document -> Empty file, and giving it the name script2.
Double click on this file to open it in gedit. Put a comment right at the top something like this:
Now locate the file called script1 in the same directory and double-click on it to open it also in gedit. It should look like this:
Back in the script2 file, go to the end of the file and add these commands:
And now let’s see this script run! Back in VPCs, load this updated script.
But if you look closely, you will see there is a problem – you can’t see exactly which commands are producing which output. Never fear there is an answer for that.
Go back to your script2 file in the editor, and add the single command at the top of the file (after your comment)
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. However, there is a catch.
Enter a command like ping 10.1.1.251
Footnote: What VPCs DOESN’T do
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:
Thanks to http://rednectar.net
Technical note: This tutorial was written using VPCs version 0.21 – and some of the functions described here will not work exactly the same on 0.20a, and for version 0.16 – you will have to use echo instead of TCP and UDP ping options.
To get started, I’ll assume you are working with the GNS3 Workbench, and have access to some working configurations. To keep things simple, I’m going to start with the nice triangular network that is found in Wendell Odom’s CCNA books. (If you are not working with the GNS3 Workbench, then download the topology, config and startup.vpc files here). Or of course, you could just build your own network based on the diagram below.
To get to the working example, start by double-clicking the GNS3 Files-More exercises here icon. This will open up a folder of exercises, and from there open the exercise 3Router-ICND_Book_Example. In this folder you will see several files whose name begin with startup… Find the file called startup.2 (eigrp configured) and double click on it. You will be prompted with:
Do you want to run “startup.2 (eigrp configured)”, or display its contents?”
Click on Run and the lab will load.
In the GNS3 application, from the menu 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 VPCs.
Start by activating the VPCs Konsole window. You should see:
Executing the startup file PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251 PC2 : 10.1.2.1 255.255.255.0 gateway 10.1.2.252 PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253 NAME IP/CIDR GATEWAY MAC LPORT RPORT VPCS1 10.1.1.1/24 10.1.1.251 00:50:79:66:68:00 20000 30000 fe80::2050:79ff:fe66:6800/64 VPCS2 10.1.2.1/24 10.1.2.252 00:50:79:66:68:01 20001 30001 fe80::2050:79ff:fe66:6801/64 VPCS3 10.1.3.1/24 10.1.3.253 00:50:79:66:68:02 20002 30002 fe80::2050:79ff:fe66:6802/64 VPCS4 0.0.0.0/0 0.0.0.0 00:50:79:66:68:03 20003 30003 fe80::2050:79ff:fe66:6803/64 VPCS5 0.0.0.0/0 0.0.0.0 00:50:79:66:68:04 20004 30004 fe80::2050:79ff:fe66:6804/64 VPCS6 0.0.0.0/0 0.0.0.0 00:50:79:66:68:05 20005 30005 fe80::2050:79ff:fe66:6805/64 VPCS7 0.0.0.0/0 0.0.0.0 00:50:79:66:68:06 20006 30006 fe80::2050:79ff:fe66:6806/64 VPCS8 0.0.0.0/0 0.0.0.0 00:50:79:66:68:07 20007 30007 fe80::2050:79ff:fe66:6807/64 VPCS9 0.0.0.0/0 0.0.0.0 00:50:79:66:68:08 20008 30008 fe80::2050:79ff:fe66:6808/64 VPCS[1]>The [1] shows that your focus is Virtual PC #1. From the output above, you can see that VPCS1‘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 arp command
- a successful ping to a remote address (PC2Sam – 10.1.2.1)
- command abbreviation
VPCS[1]> show
NAME IP/CIDR GATEWAY MAC LPORT RPORT
VPCS1 10.1.1.1/24 10.1.1.251 00:50:79:66:68:00 20000 30000
fe80::2050:79ff:fe66:6800/64
VPCS2 10.1.2.1/24 10.1.2.252 00:50:79:66:68:01 20001 30001
fe80::2050:79ff:fe66:6801/64
VPCS3 10.1.3.1/24 10.1.3.253 00:50:79:66:68:02 20002 30002
fe80::2050:79ff:fe66:6802/64
VPCS4 0.0.0.0/0 0.0.0.0 00:50:79:66:68:03 20003 30003
fe80::2050:79ff:fe66:6803/64
VPCS5 0.0.0.0/0 0.0.0.0 00:50:79:66:68:04 20004 30004
fe80::2050:79ff:fe66:6804/64
VPCS6 0.0.0.0/0 0.0.0.0 00:50:79:66:68:05 20005 30005
fe80::2050:79ff:fe66:6805/64
VPCS7 0.0.0.0/0 0.0.0.0 00:50:79:66:68:06 20006 30006
fe80::2050:79ff:fe66:6806/64
VPCS8 0.0.0.0/0 0.0.0.0 00:50:79:66:68:07 20007 30007
fe80::2050:79ff:fe66:6807/64
VPCS9 0.0.0.0/0 0.0.0.0 00:50:79:66:68:08 20008 30008
fe80::2050:79ff:fe66:6808/64
Now continue by pinging the default gateway (10.1.1.251), check the arp cache using the arp command, then pinging PC2Sam, (VPCS2) whose IP address you can see from above is 10.1.2.1VPCS[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 msThat worked, so there should be an arp entry for 10.1.1.251.
VPCS[1]> arp c2:00:10:03:00:00 10.1.1.251The 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
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 & right arrow keys
- The help key (?)
- The hist (history) command
- Changing from one VPC to another
- Aborting output by pressing CTRL+c
VPCS[1]> ? show Print the net configuration of PCs d Switch to the PC[d], d is digit, range 1 to 9 history List the command history ip [arguments] Configure PC's IP settings dhcp Configure host/gateway address using DHCP arp Show arp table ping address [options] Ping the network host tracert address [maxhops] Print the route packets take to network host echo [text] Display text in output clear [arguments] Clear ip/ipv6, arp/neighbor cache set [arguments] Set hostname, connection port and echo on or off load filename Load the configuration/script from the file 'filename' save filename Save the configuration to the file 'filename' ver Show version ? Print help quit Quit program VPCS[1]> h 1 show 2 ping 10.1.1.251 3 arp 4 p 10.1.2.1 5 ? 6 h
Tip
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 VPCs, 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
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 interruptedLesson #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
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, 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
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 endAnd 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
- 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.
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.
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 address [options], Ping the network host, Ctrl+C to stop the command -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 -l size data size -T ttl set TTL, default 64 -p port source and 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 responseNotice 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) ^CNote that this time, the TTL Expired (Type=11) message came from Albuquerque (10.1.130.252), 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)
- 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.
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 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.
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 msA VPCs TCP ping works like this:
- 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.
- A data packet (containing a few CR characters) is sent, and if TCP ACK is received, SendData is displayed, along with the time taken.
- 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
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!!
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 msThat proves that Seville is indeed listening on port 80!
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 returnedAs expected, Albuquerque is NOT listening on port 80, and says so!
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 msNote 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
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.
So here’s the plan:
From PC1Bugs
- Ping PC3Elmer’s UDP port 99 – that should work – VPCs respond to all UDP packets from other VPCs
- 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)
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 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 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) ^CAnd 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
- 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, 64 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 9 10.1.130.251 55.977 ms 60.101 ms^C *As expected, the trace ran back and forth between Albuquerque and Seville.
Note I had to stop the trace by hitting CTRL+c, but I could have limited the number of replies 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 msBy specifying the number 4 at the end of the tracert command, I didn’t need to hit CTRL+c to stop the trace this time.
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 VPCs display name
- Changing a VPCs 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
- Change VPCs 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 script1 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 (script1) to create a test script called script2
- Document your script with comments and echo commands
- load the text script2 into VPCs using the load command
- change the behaviour of your script by using the set echo on and set eco off commands
VPCS[1]> set set [lport|rport|pcname|echo], 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 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 [dhcp|auto|address], Configure PC's IP settings dhcp Configure host/gateway address using DHCP, only ipv4 auto Stateless address autoconfiguration, only ipv6 PC will try to get the ipv6 address from the router at startup address [gateway] [CIDR] set the PC's ip, gateway's ip and network mask Default IPv4 CIDR 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 10.1.1.65 26', set the host ip to 10.1.1.70, the gateway ip to 10.1.1.65, the netmask to 255.255.255.192, the tapx ip to 10.1.1.126 in the ether mode. Sam[2]> ip 10.1.2.2 10.1.2.252 24 PC2 : 10.1.2.2 255.255.255.0 gateway 10.1.2.252Note 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 VPCs, which will force VPCs to save the history file, which you will need in the next step.
Sam[2]> save script1 ......... done Sam[2]> quitOf course, if you are running VPCs from within the GNS3 Workbench environment, VPCs will actually automatically restart, because I have run this instance of VPCs from within a script which saves people from accidentally quitting. However that doesn’t matter, because you saved your configuration remember?
So now reload your configuration, and check it with the show command. You should see all your pcnames restored, and the ip address for Sam has changed.
VPCS[1]> load script1 Executing the startup file PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251 PC2 : 10.1.2.2 255.255.255.0 gateway 10.1.2.252 PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253 VPCS[9]> showNAME IP/CIDR GATEWAY MAC LPORT RPORT Bugs 10.1.1.1/24 10.1.1.251 00:50:79:66:68:00 20000 30000 fe80::2050:79ff:fe66:6800/64 Sam 10.1.2.2/24 10.1.2.252 00:50:79:66:68:01 20001 30001 fe80::2050:79ff:fe66:6801/64 Elmer 10.1.3.1/24 10.1.3.253 00:50:79:66:68:02 20002 30002 fe80::2050:79ff:fe66:6802/64 VPCS4 0.0.0.0/0 0.0.0.0 00:50:79:66:68:03 20003 30003 fe80::2050:79ff:fe66:6803/64 VPCS5 0.0.0.0/0 0.0.0.0 00:50:79:66:68:04 20004 30004 fe80::2050:79ff:fe66:6804/64 VPCS6 0.0.0.0/0 0.0.0.0 00:50:79:66:68:05 20005 30005 fe80::2050:79ff:fe66:6805/64 VPCS7 0.0.0.0/0 0.0.0.0 00:50:79:66:68:06 20006 30006 fe80::2050:79ff:fe66:6806/64 VPCS8 0.0.0.0/0 0.0.0.0 00:50:79:66:68:07 20007 30007 fe80::2050:79ff:fe66:6807/64 VPCS9 0.0.0.0/0 0.0.0.0 00:50:79:66:68:08 20008 30008 fe80::2050:79ff:fe66:6808/64 VPCS[9]> 2 Sam[2]>The next task is to create a new file which will become our second script file, and you will use the contents of the script1 you saved in VPCs and the contents of vpcs.hist to create this script. In a file browser, navigate to the folder /opt/GNS3/Project/3Router_ICND_Book_Example – it is the same folder where you fond the startup.2 (eigrp configured) file when you started in Lesson #1.
Create a blank file called script2 in this folder – you can do this by clicking File->Create Document -> Empty file, and giving it the name script2.
Double click on this file to open it in gedit. Put a comment right at the top something like this:
#Script file created for testing vpcs
Tip
Comments can be placed in script files by starting the comment with the # character.Now locate the file called script1 in the same directory and double-click on it to open it also in gedit. 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 set pcname VPCS 5 set pcname VPCS 6 set pcname VPCS 7 set pcname VPCS 8 set pcname VPCS 9 set pcname VPCSCopy and paste the first 9 lines into your script2 file. 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 24Now 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 ping 10.1.1.251 arp p 10.1.2.1 ? h 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 10.1.2.252 24 save script1 quitNow I want you to copy all of the lines from vpcs.hist EXCEPT the last 2 lines – the save command and the quit command at the end. You are about to paste them in script2, but there is one more task before we do that!
Back in the script2 file, go to the end of the file and add these commands:
1 echo Here is the beginning of the history fileThe 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. Now, immediately after these lines, paste the contents of vpcs.hist that you just copied, and save the file. 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.
load script2And watch all those commands being executed – did you see the message “Here is the beginning of the history file” appear?
But if you look closely, you will see there is a problem – you can’t see exactly which commands are producing which output. Never fear there is an answer for that.
Go back to your script2 file in the editor, and add the single command at the top of the file (after your comment)
set echo onSave the file again, and load it one more time. If you get sick of waiting for it to complete, hit CTRL+c
Tip
Script files can be aborted by hitting CTRL+cNow 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. However, there is a catch.
Enter a command like ping 10.1.1.251
Bugs[1]> ping 10.1.1.251 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 msSee how the command is echoed on the output after you type it? This can be corrected by reversing the set echo on command we put at the beginning of the file by putting a set echo off at the end of the file – but of course you will have to let the whole script run without interruption for it to take effect. Of course you could just type: set echo off at the vpcs command line to turn it off yourself.
Footnote: What VPCs DOESN’T do
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:
- VPCs 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.
- Still on the fragmentation, if you send a VPCs host a ping that arrives in fragments, it can’t put the fragments back together, so the pings will fail.
- 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.
- Similarly, other fancy IP options, like record route can’t be set either.
- VPCs don’t have any layer 3 routing capability beyond a default gateway. Therefore VPCs can’t act upon ICMP re-directs if it ever receives one.
Thanks to http://rednectar.net
No comments:
Post a Comment