CCIE Pursuit Blog

November 8, 2007

LFU 7: RTFM

Last night (actually early this morning due to my inability to translate time zones) I rented some time on Internetwork Expert’s racks.  I was assigned to rack 6.  I logged on and after doing some of the technology labs, I decided to do as much of Lab 1 from the Volume III workbook as time allowed.  I had already done the layer 2 part of this lab on my rack and figured that it was good practice to do it again and see how far I could get through the IGP configuration before I fell asleep.

One of the great things about renting a vendor’s rack is that they are set up precisely for their workbooks, right down to the interface.  On my rack I need to constantly tweak vendor provided initial configurations to match my actual interfaces.  It’s not a huge deal, but it does burn up some time when setting up for a lab.  On IE’s rack I was able to quickly load the initial configurations and start on the lab.

I tore through the layer 2 stuff.  A lot of that had to do with this being the second time that I’ve done this lab, but also because the tasks are pretty basic and unambiguous. 

I was zipping along until I hit task 3.2  In this task you’re asked to create a point-to-point Frame Relay connection from r6 to bb1 (backbone router).  Pop on an IP address and configure Frame Relay.  Piece of cake.   That’s when the fun began:

I could not ping bb1 from r6.  I configured it correctly and I was getting a good frame map:

r6#p 54.1.2.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.2.254, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5) 

r6#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
interface Serial0/0.1 point-to-point
 ip address 54.1.2.6 255.255.255.0
 frame-relay interface-dlci 100

r6#sh frame map
Serial0/0.1 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast
          status defined, active

Weird.  I did a shut/no shut on the physical interface and was still unable to ping the bb1.  I jumped on the access server and tried to reverse telnet to bb1 but was not allowed to access it.  At this point I grabbed the answer key to verify my configuration.  I felt stupid doing this because the task was so simple and I had successfully completed it before on my own rack.  My configuration matched the answer key.  So what the hell was going on?

I verified that Frame Relay was working.  LMI, Frame Maps, Frame PVCs, interfaces were up and up…everything looked good.  Routing protocols had not been configured at this point, so it HAD to be something with the layer 2 configuration.  But what?

I had a couple of troubleshooting routes that I could take a this point.  I was leaning towards something being configured wrong on the bb1, so I decided to default r6’s s0/0 interface and then use Frame Relay Inverse-ARP on the physical interface to create a dynamic mapping.  If successful, that should allow me to verify the DLCI and IP address of bb1:

This is after I defaulted and rebuilt the s0/0 interface:
r6#sh run int s0/0
Building configuration…

Current configuration : 89 bytes
!
interface Serial0/0
 ip address 54.1.2.6 255.255.255.0
 encapsulation frame-relay
end

r6#sh ip int br | i Serial0/0
Serial0/0                  54.1.2.6        YES manual up                    up

Serial0/0.1                unassigned      YES manual deleted               down

r6#sh frame map
Serial0/0 (up): ip 54.6.1.254 dlci 101(0x65,0x1850), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 54.6.2.254 dlci 100(0x64,0x1840), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 54.6.3.254 dlci 51(0x33,0xC30), dynamic,
              broadcast,, status defined, active

Fuck me running!  The IP address on bb1 was wrong.  The second octet is 6 and should be 1:

Serial0/0 (up): ip 54.6.2.254 dlci 100(0x64,0x1840), dynamic,
              broadcast,, status defined, active

r6#sh ip int br | i Serial0/0
Serial0/0                  54.1.2.6        YES manual up                    up

My configuration matched the topology and the answer key.  I opened the initial configuration for the bb1 from Internetwork Expert’s own documentation (remember that I could not access the bb1):

interface Serial0.100 point-to-point
 description PVC 100 to Rack8
 ip address 54.1.2.254 255.255.255.0 
 ipv6 address 2001:54:1:2::254/64
 ipv6 address FE80::254 link-local
 frame-relay interface-dlci 100

Why hath thou forsaken me Internetwork Expert?  I was crushed.  I was up way past my bedtime and looking at only a couple hours of sleep before the roar of my alarm woke me to face a day at work with minimal sleep.  I would spend my few hours of sleep plotting the slow and painful demise of the Brians.  🙂

I went ahead and altered R6’s s0/0 interface IP and everything worked just fine.

I have learned a couple of things about myself over the years:

  1. I am often wrong.
  2. If I wait a bit and keep my big mouth shut, I’ll usually see the error of my ways.

Unfortunately, I usually skip step two and end up with my foot in my mouth.  In this case I thankfully saw the error of my ways before emailing IE complaining about the incorrect configuration of the bb1.

If you’ve used IE’s labs before, you’ll know that the IP address on the topology are written in the form of “10.x.1.0/24” where x = your rack number.  I have always used x = 1.  This has never been a problem because I use my own rack most of the time.  When I have rented racks before, it’s never been an issue either because I’ve never used the bb routers before. 

In this case I was on rack 6 and had pasted in the initial configurations which used x=1 (this negates my “initial configs need no editing” statement from earlier).  This meant that IE had the bbs configured correctly (x = 6) but that ALL of my interfaces were configured incorrectly (x = 1).

ARRGHH!!!!!!!

I went ahead and changed the octet only on the connections to the bb routers.  I was getting pretty tired and it was obvious that I was not going to complete the entire lab before passing out, so I did not worry about any issues caused by the bb-injected routes using x=6.

In the end I was disappointed that I spent so much time troubleshooting this issue, but I am happy that I was able to troubleshoot the issue and eventually find the underlying problem (my idiocy).

The lesson: Read the instructions and don’t get so comfortable with a topology or routine that you don’t think/question why you’re doing something a certain way.  If this had happened to me on the actual lab, it would have sunk me.

Advertisements

1 Comment »

  1. I have experienced situations like this with a few of the IE labs, and more often then not it is an issue with R6 to the backbone. Authentication, addressing, incomplete task requirements. The great thing about IE though, is that if you just email one of the Brian’s they will address the issue, and I would imagine they document it in their forum.

    I would say, for as good as the products IE puts out, they have fewer errors than the likes of IPExpert (Scott Morris plagiarized his R&S audio bookcamp, by the way) and others I have seen. For the costs of these products we’d hope not to see errors, but even Quad CCIE’s are human.

    Comment by Brent — November 10, 2007 @ 10:39 am | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: