Archive

Archive for the ‘Lab preparation’ Category

Saving time on lab tasks

March 11, 2011 1 comment

This post will show how you can save time on the lab tasks. Assume you need to complete this OSPF task.

  • Advertise the Loopback0 interfaces of R1, R2, R3 and R4 into OSPF area 0
  • Advertise the Loopback0 interface of R6 into OSPF area 1
  • Advertise the Loopback 0 interfaces of SW1 and SW3 into OSPF area 2
  • Advertise the Loopback 0 interfaces of R5, SW2 and SW4 into OSPF area 3

Our task is to advertise the loopbacks of all routers and switches in the topology into OSPF in
different areas. The topology is the regular INE topology but it doesn’t really matter here.
The major network is 155.21.0.0/16 where R1 has the loopback 155.21.1.1, R2 has
155.21.2.2 and up to SW4 that has 155.21.10.10.

We will be using the notepad technique, this can save you a lot of time when the lab comes.
What we do is write everything into notepad instead of typing in the CLI and we try to
reuse as much config as we can and only change a few parameters and then we copy
and paste to all the devices. This will save you from typing, save time and be more
accurate than typing to the CLI.

We have two options here, either we advertise the loopbacks the regular way by
entering router ospf 1 and then using the network statement or we can use the
new method of configuring OSPF under the interface instead.

Lets look at the first approach. Every loopback is in it’s own class C subnet. Assume
that we have entered OSPF config mode and we now need to put the network
statement, what should we use? We only want to advertise the loopback and not
other interfaces. So we start typing in notepad.

end
conf t
router ospf 1
network 155.21.1.1 0.0.0.0 area 0

This is as specific as we can get, this will only advertise the loopback. Now we need to copy
this and lets look at R2. The reason why I put an end at the start is to make sure that we
will end up in config mode and not some other submode. Router ospf command should work
from most modes like interface config but its better to make sure.

end
conf t
router ospf 1
network 155.21.2.2 0.0.0.0 area 0

So we need to change two digits for every device. Can we be more effective? If we change
the network statement to 155.21.1.0 0.0.0.255 we would only need to change one digit in
notepad for every device, that is actually better!

There is an even more effective way of doing this, which will mean that we won’t have to
change a single digit for the first four devices! Every minute saved will give us more time
to troubleshoot and verify config. This is how we do it, type into notepad.

end
conf t
int lo0
ip ospf 1 area 0

This config will be exactly the same for the first four devices and for the others
we only need to change the area, that is one digit at most! So now we have done
this in the most effecient manner possible. Now we want to test the reachability
of all the loopbacks. We could ping manually from the CLI and type ping 155.21.1.1
and so on but that would take a lot of time for 9 loopbacks in every device.
We could enter all IP’s in notepad with ping statements and then paste this into all
the routers which would be way more effective but the most effective way of doing
this is by using the TCL shell in IOS. If we don’t have support for TCL (switches)
we can also use a macro. This is how we do it in TCL.

tclsh
foreach ip{
155.21.1.1
155.21.2.2
155.21.3.3
155.21.4.4
155.21.5.5
155.21.6.6
155.21.7.7
155.21.8.8
155.21.9.9
155.21.10.10
}{ping $ip re 1}

We could leave out the loopback from the device that we are currently on
but then we would have to edit more in notepad. We should get a reply from
ourselves and if not we know why the ping failed. So this code in TCL will ping
every loopback repeated only one time and show us the output. We have now
configured the loopbacks and verified reachability in a matter of minutes.
I hope this post will help you in saving time and as I progress in my studies I will
post more of these tips.

Categories: CCIE, Lab preparation Tags: , ,

INE workbool vol1 labs 2.1 – 2.8

January 21, 2011 Leave a comment

Went through the frame-relay labs today. I have never used frame-relay in real life so although it wasn’t very difficult to configure I think I need to go through some videos and documentation to understand the details of inverse ARP and LMI. I know that LMI tells the DTE about the PVC’s available (DLCI’s) and that inverse ARP or static mappings is needed for the layer 3 to layer 2 resolution. I just need to work out which combos are available and how the DTE knows when using inverse ARP which DLCI to use when sending traffic out.

Started labbing

January 20, 2011 2 comments

I have now oficially started to prepare for the lab. Yesterday I did my first rack rental via Graded labs. This worked flawlessly even though I am located in Sweden. Getting access to the equipment was easy and the command prompt was responsive. The only thing that’s a drag is that it takes so long to load the configurations via the control panel.

I am following this program from INE. I was able to finish 1.1 – 1.12 yesterday. I was a bit shocked first even at the first lab since you need to get the right feel for the diagrams and how to get the information from them that you want. I had to draw a new diagram to get the information I wanted. To do this “show cdp neighbor” and “show interface trunk” is very usable.

Feels very good to have started. I had a pretty good grasp of the labs during this session, it still is easy to forget easy things like creating a VLAN or so. One time I didn’t know the command to do a task and I then looked it up inĀ  the DOC-CD. I will try to only use this as my source for configuring and not rely on google to search.

Follow

Get every new post delivered to your Inbox.

Join 615 other followers