Archive for September, 2010

…and I feel like I understand a bit more about networking already. Most useful was revision of such basic principles a subnetting and logical-to-physical addressing.

There’s still a balance to be made between remote and on-site working. The remote Cisco Netlab system is very useful but you can only go so far without getting your hands on real cables, real gear.

I assume that the other students have spent a lot of time in the lab because only two of us have ever booked a remote session. Unfair advantage? I guess we’ll see on Friday. I mean, did anyone actually bother to do any lab work this week, and if they did was it more productive than the 12-or-so hours I’ve put in remotely?

Steve

Advertisements

Aah, that’s more like it!

Posted: September 28, 2010 in Live@Edu

Microsoft’s crappy old Spaces blog system has just been replaced with WordPress. Much more betterer!

In case you missed this when Adrian demoed it last week, here’s how to download a copy of Packet Tracer.

1) Go to http://cisco.netacad.net and log in with the credentials that Adrian emailed to your Anglia Ruskin student email account

2) Click on the Accademy Connection login button to the right. This isn’t the same as the Log In link at the top of the page!

You will have to provide lots of details in a big form. Do this, paying attention to the mandatory fields.

3) Once you’ve set your permanent username and password, log in

4) The Packet Tracer download link is on the left

5) Locate the inexplicably difficult to find link to download the application

6) Choose your flavour and away you go.

Steve

Here’s a poser for my infrastructure-y friends: how do you find the MAC address of a remote server using Wireshark?

I know the following to be true because I have access to these machines directly:
Client—————-Router—————-Server
172.16.0.2              172.16.255.254          192.168.254.254
00:0c:29:dc:f9:d1     00:0c:85:27:44:40       00:0c:29:8a:60:29

If I ping the Server from the client and then interrogate the packets in Wireshark I see the folowing:
Ethernet II (Layer 2): Destination: 00:0c:85:27:44:40
IP: Destination: 192.168.254.254

So I pinged the Server but the Layer 2 destination is Router.

Why? Is this because access to the Server is only through the Router, therefore that is the destination? Is it because the Server is on a different subnet to the Client? I’m a bit lost.
Steve

[UPDATE] A response from a friend of mine clears the whole thing up!

Answer… as te blog won’t let me post a reply of this length.

Q. "how do you find the MAC address of a remote server"
A. You cannot, directly.
Q. "Why? Is this because……?"
A. Yes.

To explain: IP sits at Layer 3 and is based on logical addressing (the IP address), as such this is abstracted from Layer 2 which is based on physical addressing (the MAC address).

You will see in in a packet trace if you ping for anything not in your ARP table, the first packet seen is the local machine sending an ARP request. If the destination machine is on the same IP subnet, it will reply with it’s MAC address so physical communication can happen at Layer 2.

If the machine isn’t on the local subnet, your machine will ARP for the default router IP address. Your machine will then physically send packets to that router, if you look in the trace the IP destination is the actual destination – the Layer 2 & 3 no longer directly correspond.

It’s a bit like you posting a letter, if it’s in your street then you just walk down and post it yourself, you know the physical (MAC) address of the destination. Anything else, you don’t care about the physical location (MAC address) as you address the envelope (IP address) and put it in the postbox (the router for which you have the physical location for), you don’t physically care where the destination is so don’t need to know the MAC address.

I presume they have discussed the OSI 7 layer Model? if not, then http://en.wikipedia.org/wiki/Osi_7_layer_model will sort you out.
Does that help?

Regards
Jeremy

Hi all,

I experienced a couple of gotchas when I tried to use the Netlab remote
lab for the first time. Fairly obvious in hindsight, but I thought if I
posted the resolution here it might save some of you some pain…

Once you have started your remote lab session, open up a couple of the
Clients. The virtual images are scrubbed each time you begin a new
session. In other words, their config is reset to Cisco defaults. This
is great because you have a consistent starting point, but it also means
you have a bit of housekeeping to do before you can start work.

Firstly check that you NIC is configured for DHCP like this:

Now open a Command Prompty (Start/Run/cmd) and type ipconfig /release (enter). Now type ipconfig /renew (enter). This makes the network configuration take effect and makes a fresh request to the DHCP server for an IP address.

Check your network configuration by typing ipconfig /all (enter). Your local IP address should be something like 172.16.0.1. (Or .2 as it is here, because I’d already configured another Client.) Prove that you can see network stuff by typing ping eagle-server.example.com (enter).

For most exercises you’ll need to download and install Wireshark. Remember that these computers don’t have any public internet access, so you’ll have to download Wireshark from the lab server itself. This is called eagle-server.example.com (192.168.254.254). You could use the old DOS-style FTP package, but it’s easier to use use Internet Explorer to browse the Eagle server’s FTP server and install directly from there.

You will need to perform similar steps on all Clients. You need to do this for most lab exercises.

Hope this helps!

Steve

I just completed the first lab workshop and found it to be not nearly as intimidating as I had expected. I’m impressed by the setup the Faculty of Science and Technology has here. Proper CISCO stuff, all works first time and the CISCO documentation is very good.

I’m also looking forward to having a go at remote working via Netlab. If I can get this working from home then my worries about travel and lab time will be unfounded. Later on I guess I’ll need physical exposure to the gear, but for the preliminary tasks it’s mainly packet interrogation, console work etc. All this can be done via VM.

I might add my lab notes here later, if I think it’s appropriate.

Steve

Day one complete.

The Infrastructure Management and Disaster Recovery module is massive. Huge. I easily have 200 hours of reading to do. Probably 250 hours. Maybe more. Add to that all the lab work and the small matter of the assignment and I predict that I’ll see sunlight again perhaps in January.

I’ve spent two hours reading the first chapter of 11 essential chapters for this week. Did the CISCO lab exercises too (perfunctorily, I might add, as they were a little Mickey Mouse – CISCO ‘Introduction To’ exercises are notoriously woolly) and took the test at the end. Brain is now fried.

I think I’m going to actually start taking my lunchbreaks from now on, and my time will be spent reading.

I’m a little concerned by the need to be on-site for the module’s official lab exercises. If these can be completed within each week’s 3-hour workshop then I’ll be fine, but I can’t afford any more time out of the office, nor can I travel from Chelmsford to Cambridge another day in the week. I’ll see how it goes tomorrow before I start panicing.

Sorry, I’m sounding a little overwhelmed. That’s because I am.

Steve