IEWB Vol III Ver. 4.1 Lab5

Almost finished this lab tonight – just two BGP tasks to go. Overall, this lab was challenging. I remember doing this lab last summer and it seemed to overwhelmingly difficult. This time, it doesn’t seem as bad. I am doing better on my time as well.

• Tunneling – This lab is full tunnels and virtual-links. It does take some calculating to know where to place the tunnel and VL ends. When I first found out about tunnelling, I thought it was the coolest thing since sliced bread.
• PPP with Dialer Pool - I’ve pretty much got the PPPoFR down, but dialer maps? I got them built (with help from the SG), but I stripped the link from R4 to R5 down to just HDLC, because I was having so many issues with it. I’ll have to look this one up later.
• Redistribution (surprise, surprise…) – This was tough for me. I thought I had found a bug in the IOS, but it was just redistribution woes. The routes for SW3 and SW4 kept flapping on R5 and I was getting frustrated. I thought it was a RIP issue, since I only redist on R4 and R1 at that time. I stopped redist on R1 and opened it on R5 and the Rip routes for those switches stayed in the routing table. Hmmm… I said to myself “Self… it must be a redistribution issue.” When I filtered to routes from R1 via tags, all was well. I love tagging by the way. It just makes sense.
• Default route in RIP – I had always thought that a 0.0.0.0 route had to be in the routing table before it could be advertised with default-information originate command, but no so. R4 received the default route like a happy clam,

I will finish up BGP and go through the SG and check my work. I guess I should check mu work section by section. I think I will try to remember to do that from now on.

Tomorrow there is a 100% chance of thunderstorms and possibly tornadoes, a great day for router time. It’s too early for storm season in Texas, go figure…

IEWB Vol III Ver. 4.1 Lab4 finished…

Well, when I went back through the SG for this lab, a few areas kicked my butt. I think I did ok, except for the wr erase on all devices fiasco.

• redistribution (again…) – This one I thought I had, but after going through the SG, the answer was much simpler. I had used the distance command to assign an AD of 200 to routes sourced from R3 originating from EIGRP on R2. I thought this would work, but for some reason, it was flaky. The routes from EIGRP through OSPF would not appear and then as it settled down, the EIGRP routes from R5 would slowly take over. Weird… The simple solution was to set all OSPF external routes to AD 200; this created issues on R3 for the RIP routes from BB2 – to get to the BB2 routes, go to R2 on SW1. The answer for this was to set the RIP AD to 109.
• Filtering VLANs on trunks – This was in the VTP section, so I figured that VTP pruning would be the answer. However, manually specifying the needed VLANs on the trunks was what was needed for this requirement. Hmmm… the wording wasn’t too clear. This one would be a question for the proctor.

I used TCL ping scripts on this lab, too. They sure saved a lot of time for reachability verification. I could instantly see problem areas from each end of the network. When I got a no response form a ping request, I just had to figure out if the address represented a down backup interface, a local FR interface or no route by design.

I’m on to Lab5. My goal is to get to Lab 9 by the end of the month. I figure that this sould give me a good base for the IGPs and BGP, ready to go on to Vol II Labs. I will need to bone up on Multicast, QoS and more BGP.

I was reading of Groupstudy the other day about someone who was going to have his CCIE, but had no experience. Man, I was in his shoes. The replies were from others that he will probably be low-balled geting hired, but will quickly go up the ladder.  If a CCIE with experience vs. a CCIE with no experience, most employers will take the experience. One of the posters stated that the right position will come along after all the “experience required” jobs and it will be then right one. It gave me hope…

IEWB Vol III Ver. 4.1 Lab4

My time thus far is shot with this lab. Don’t wr erase on entire stack with the send command on the terminal server! The backbone and frame switch configs got wiped out! I thought that only the active terminals were affected, but NO… all terminals got the clear treatment. I wasted time reloading the config on the backbone routers and the frame relay switch. Doesn’t sound too bad you say? Well, how about wasting time troubleshooting an issue in the network, come to find out that the FR or the BB router interfaces were shutdown. I went through the BB and FR switch configs to verify that they were tweaked appropriately. What a mess… This was a valuable lesson learned, even if it doesn’t apply to the IE Lab.

Even with these issues, it has been a good lab thus far.

• Bridging using virtual templates – it’s been awhile since I’ve done this and it was a good refresher. I viewed the Bridging CoD to bet the understanding back again and it didn’t seem to big of a deal. I’ve never understood why the virtual-template spawns another pointless virtual-access interface that is always down. I can understand why the template itself is down, but why the extra access interface? Also, it would sure be nice in the show ip interface brief output, maybe in the IP address column, they put VA-1 or something like that on the physical interface to know what virtual-access interface is bound to it. If you have multiple VA interfaces running, you want to know what is bound to what. Yes, the show ip interface shows it, but it would be nice to have it in the brief command as well. Cisco are you listening?
• Backup interfaces – OK, administratively shutting down the interface doesn’t work to test it. It needs to be tested with a frame LMI change or shut down the remote interface on the FR switch. Since you don’t have access to the FR switch during the lab, an LMI change will have to be it. This sucks – isn’t the line protocol brought down when you admin shut it down as well? Go figure… this is why Cisco guys get paid the big bucks, I guess.

Redistribution wasn’t too bad this time and I’ll be on to the BGP stuff next.

IEWB Vol III Ver. 4.1 Lab3 finished…

A couple of new things that I learned doing Lab3 this week.

• RIP off-set list number 0 – I learned in task 4.3 that if you need to specify an offset-list to change the RIP metric, it requires an ACL. Well, if a 0 is used instead of and ACL name or number, it will be applied to all routes coming in or going out overall or on a specific interface. Cool…
• “All devices running BGP should have reachability to all BGP learned prefixes.” – I assumed this meant all the BGP devices that I had control over. Well, it includesbackbone routers as well. I didn’t think about that until I went through and did my check with the SG. “All devices” means all devices.
• Always use route tags when redistributing – This has become second nature when i configure redistribution. I am going with the router number/protocol AD naming that IE uses; it makes sense. I can easily see where the routes came from in the show commands for the protocol. If I do this and they aren’t used, no big deal. But if I need them later, it’s a time saver.

The big thing with this week was figuring out the different ways of accomplishing tasks. I need to look at my options and see what works the best, even if I have to do an in-depth read-ahead of a few tasks to see what will work the best.

Overall, good lab. I am a bit slow at this time. I will be working in small ways to get faster. some of this will come with time as i figure out speed techniques. Is it worth learning to type correctly at this point?