“encaps failed on broadcast for link 38” =’s No IP Routing I come to find out.

IP Routing was shut off on R1 which killed me lol. I couldn’t find anything on this error when setting up the frame-relay connection between R1 and R2 Friday night. The worst part is I thought it was a hardware issue on my test lab at work so I waited until today to try to fix it. I even was doing frame relay switching debugs on the frame relay switch trying to find out what was going on. My question is how did IE shut off ip routing in the config? I don’t see it anywhere in there. Oh well big lesson learned there and moving on now through the rest of the lab.


I found the “no ip routing” command. It was sitting under the “line aux” configuration. Sneaky…

After getting completely drilled on the redistribution portion I finally made it through the lab. I did hit the answer book a lot though after BGP :(. Oh well it is the first full lab I have completed in a while so I will take it as a win. I have the lab breakdown class on demand material from Internetwork Expert as well. I am hoping to complete that by this weekend while taking notes during it.

I do get to see HSRP in action this weekend when our main provider knocks out my multiple bonded T1’s at one of my facilities for maintenance. If our provider still has their end up our multipoint link will still show up/up and never let the backup router take over. So I may have some babysitting to do at midnight on Saturday. If the link doesn’t go down completely I will just have to change administrative distance of the route to our corporate office so the main router just routes the traffic over to the backup network till the morning.

HAHAHAHAHAHA is all I am going to say here… 🙁

del flash:vlan.dat

frame-relay route 513 interface serial0/3 315

Well I got through the last workbook I wanted to get through sometime last week before moving back to the Internetwork Experts workbook 2. I started lab 2 today with a few dumb issues. First off I forgot to delete the vlan.dat file from flash before configuring the switching section. This didn’t play nice when it came time to prune vlans. It is always a real pain in the rear when you spend countless minutes troubleshooting only to remember you forgot to delete the file. Those are the mistakes that I can’t stand making, such a complete waste of time.

The other command was missing from my frame-relay switch when it came time to enable EIGRP. I spent another hour trying to figure out why the interfaces were not coming up and why EIGRP was not forming a neighbor relationship. I must have forgotten to check the up state of the serial interfaces on both R3 and R5 before moving passed frame relay. I must have just been overly excited to move and configure HDLC! I found the missing route when I was out of ideas on why the interfaces were not coming up. Sure enough it is always one of the first items I should be checking.

At this rate I will be buying a cold Cisco lunch for $1400 and the cost of the trip to eat that lunch :). At least I am learning as I continue to torture myself. I am coming to the realization that I am going to just need to break my labs up between two to three days. Too much to do at night when I get home.

Either way I am not feeling all that comfortable about my mock lab on April 14th, or the real lab for that matter.

I think I have all IPs covered here. You can copy and paste this to each router under tclsh and off you go. Internetwork Expert’s solution guide has the full script if you want to type it up and run it each time from the process name.

foreach i {
} {ping $i}

Well I got through half of the first lab this weekend. I ran into a cabling issue Saturday morning that took me a little bit to figure out. The tough part of using Dynamips bridged out to real switches is troubleshooting hardware and software issues. Turned out to be a mix up of the usb ethernet controller on the mac mini and my dynamips internetwork expert file. This mix up was causing R4 and R5 not to be able to talk between Vlan 45. My first attempt at lab one was stopped by this same problem. The issue was the same, but I was so far into the lab that it was hard to find where the issue was. This time I made sure to test out all connectivity after each section and caught this early. It did encourage me that the problem was not something I configured incorrectly a few weeks ago.

The second issue I had was forming the bgp peer session with switch four and BB2. A simple password was needed for the session, neighbor remote-as 254 password CISCO. For some reason though, the peer session would not come up between the two. So I turned on debug and saw the authentication error. I checked the solution guide and I had it exactly right. I decided to console onto BB2 and saw the peer group configuration on there. The password still wouldn’t go through though. I tossed on the bgp peering configuration manually to switch four and everything came up. I’m wondering if I have an old BB2 configuration on my hands. I will have to make sure I get the latest configurations tomorrow before continuing on.

Lesson learned: Always check connectivity after each section, especially in practice labs.

I stopped at that point tonight and will continue on tomorrow.

Well I am looking to get back into workbook II lab 1 by next week. If I don’t start soon, it feels like I will never start back up again. I am going to have to break the first few labs up by their topics. I won’t have eight hours to spend on each lab for a while. I would like to get the labs done in two 4 hours sessions on the weekends to start so I have the next five days to read over things that I am not clear on, or having trouble with.

Up until now I have been too concerned with multicast and QOS instead of concentrating on the core items. I need to get those down one hundred percent or else there is no way to pass the lab anyhow. So I decided it is better to get the core down cold and start to worry about the other topics later down the stretch.

I finished multicast this week with the workbook I labs. I still need to work out some more labs with it though. Hopefully I will get it all down after a few workbook II labs. I am hoping to finish up the QOS class on demands this week and move through the labs through the weekend. Then I want to quickly review some OSPF and EIGRP once more and back to the workbook II labs.

I am still looking at July 14th at RTP for my lab attempt. I have four mock labs scheduled starting in April that will hopefully give me a good indication before I pay the lab fee :).

I finished up the BGP labs from workbook I today and will continue on with Multicast tomorrow. I have to say I feel better about things after revisiting them again. Even if it slows my pace, what does it matter? I would rather go over the labs again from workbook I then move forward unprepared.

I did use the Doc DVD along with the IOS Cookbook. I read the BGO chapter before I started the labs and was pleasantly surprised how well it broke everything down. There were good examples and excellent breakdown of the examples as well. This book is an excellent reference.

There are a few labs in workbook one that I will be going over again this week. The first will be BGP and then Multicast. I am hoping to have the BGP labs done along with the multicast done by the end of the week. That will leave me with QOS for the weekend, but I want to go over the COD’s again before hammering out QOS. One thing that was suggested to me by a reader was to look over the lab as I go over the topic through the COD. The labs for workbook one seem to follow the lectures closely and help give you a better idea. Hopefully this all helps. I also had another reader tell me not to worry about my work done on Lab one from workbook two. That I will always have gaps going between workbook one and workbook two. Hopefully though I can close a lot of the easy gaps.


← Previous PageNext Page →