Friday, December 2, 2011

Lab 5.6.1 Reflection

For Lab 5.6.1 by reading the information on the lab i was able to learn that the config isn't the only way of solving IP routing problems. You can also use the Cisco Internetwork Operating system command line interface to solve problems on the local area network(which will be showed in later packet tracer labs). I also learned that the inspecting tool can be used to examine the routing table in packet tracer. I was also able to learn how to configure a route using a GUI(Graphic User Interface). I would have to configure the router with address and subnet mask as 0.0.0.0, and also the next hop as 10.10.6. This configuration  would make any packet that came from the LAN would be directed towards the R1-ISP Router. The most important thing that i learned from this lab which was a on going problem through the other labs was the reason why a added PDU would always fail the first time to the extent where you would have to press the "fire" button to resend it. The problem was that the ARP table were not yet populated.

Reflection questions:
The data that a IP packet can contain is things from the destination IP address, source address, Protocols etc.
What is meant by the phrase the "IP packet has been routed" means that it has traveled through the network and reached the destination. A route is a pathway in which packets travel through. These routes can be configured based on the best possible way to send the packets to the user's wishes. The places where things go wrong could be from the routes to even the devices. If devices or routes aren't configured correctly than packets would either never be sent or on the most likely be lost or dropped.

Lab 4.6.1 Reflection

This lab I wasn't able to get up to but by reading all the tasks i understood what information i would have gotten out of it. This lab has the same addressing table as the previous labs before. So in terms of ip address, interface, subnet mask, and gateway all the configurations have remained the same. the only thing that did change was the server. There is a new IP address, and default gateway. Just like the previous lab task 1's main focus is on repairing and testing the topology. It tells me that adding a simple PDU would appear in the PDU list window as part of  "scenario 0". By than pressing  the "Fire" button in the PDU list window would send the test ping a second time to the point where it will this time be successful. One thing that i learned from this lab is that by event  filter being set to display DNS, UDP, HTTP, TCP, and IMCP and than opening a web browser from the desktop of computer 1A and finally typing the URL eagle-server.example.com in combination with the use of capture/foward button will show me the interaction between the DNS, UDP, HTTP, and TCP.

Reflection Question: comparing and contrasting DNS, HTTP, UDP, TCP
DNS: Domain Name System which is a naming system for computers, services etc.
HTTP: Hyper Text Transfer Protocol which is a networking protocol for web pages.
UDP: User Datagram Protocol is a transport layer protocol that runs on top of ip networks.
TCP: Transmission Control  Protocol similar like the UDP which is one of the main protocols used for the internet protocol suite(Also a transport layer protocol).

Lab 3.5.1 Reflection

In lab 3.5.1 i was able to easily set up the topology given since the addressing table's have been the same for three consecutive labs so far. For task 1 i was able to configure the necessary devices with IP, subnet mask. default gateway, etc. I connected eagle server to the  R1-ISP from the Fa0/0 port .I added a simple PDU but just like the previous lab the packet had problems going to the routers. It eventually went to the eagle server but failed there as well. Based on the lab what should of happened was that the simple PDU should of appeared in the PDU list window as part of "Scenario 0".  I understand that the first time i were to send the the one shot ping message that it would fail because of the ARP(Address Resolution Protocol). By clicking on the fire button(which is in the PDU list window) will send the packet a second time which will be successful .  Base on the question on the reflection what happens when you type a Url into a browser and a webpage comes back is that the client requests information from the server in whcih the server accepts and sends information back in the form of a webpage based on the requested URL .The type of client/server interaction that is present is that the client Pc-PT 1b is requesting information from the Server in which the server will accept the the request and act accordingly.

Lab 2.7.1 Reflection

In this this lab we used packet tracer to set up another network. The topology diagram showed us a basic set up of how it is suppose to turn out.  I was able the set up the network and configure all the devices correctly as the lab suggested me to. But for some reason there was still problems with the pack simulation. As the packets traveled to the other devices once it got to the router it would show an "X" on the packet meaning most likely that there was a problem with the packet being sent to the router. This occurred when i added the simple PDU as a test message from computer 1b to the eagle server. It failed to even go past the router for some unknown reason. What would happen if it was successful the packet would have appeared in the event list as a packet that was "detected" or "sniffed". Task 3 told me to switch to simulation mode in  which i would able to examine the packet in each step as it went through each device. In task 4 it told me to experiment a little with topology given. I was able to progress more than the previous set up and as a result was able to get a better understanding of what this lab wanted to teach me.

Thursday, December 1, 2011

hand out #1

1.) The way in which the video relates to me and the class is that it has to do with computing. TO be more specific programming. I found the video to be very interesting since the kid was so young and yet was still able to come up with an idea and follow through with it.

2.) This is a good reflection of self discipline because the kid in the video is so young but is smart and disciplined enough to go through with making an app. Many teenagers can learn from this adolescent because not many teens and kids are as disciplined as him to be this professional and such a young age. It also takes commitment and dedication and goes for show that anything is possible.

3.) I personally think that both this subject and creating an app are difficult in their own way. Like the kid said in the video creating a program could be hard. The reason why is because you have limited resources. You can't really ask your parents because the odds of them knowing is very slim. You can always go on the internet, but you could be either charged, but if you find the information needed you wouldn't really have someone to ask for help with if you got a problem with how you're writing your program. Cisco is also difficult because you don't just have to know things through software but also on a hardware level. Especially when  your troubleshooting problems in a network. You would have to go up the layers troubleshooting to see in which layer the problem originated from, and when finally finding it fixing it. I think that Cisco is most likely a little harder than creating an app. With an app you are writing endless lines of code. You can most likely fix something easily if you make a mistake in making a app. But for Cisco for troubleshooting you need to look through on a software and hardware level in order to mediate a problem.