IEWB Vol II Ver. 4.1 Lab3

This lab was flyin’ at the beginning, but can to a quick slow-down when I got to BGP. I literally had up to IGP done in about 4 hours. I was elated!

A couple of things…

• I really got skunked on task 5.2. I was racking my brain on how to filter BGP routes at the border of the AS without doing any configuration on the EBGP routers themselves. I tried the neighbor filter command, but that only works on the local router. I peeked at the SG because I was so stumped and just saw one word – communites. The light bulb came on instantly. I then immediately knew that no-export was it. Man, I felt challenged.
• Task 5.5 grabbed me and gave me a shake, too. I was thinking to myself, how do I advertise a BGP prefix down a “backup” link? Again, my brain was challenged. OK – define an advertise-map non-exist list. Go figure. I need more practice with those for sure. Arrrrgggg…

Well, onward to MC. I assume it will go a bit better. I am also trying to grasp QoS, too. It does help that I am developing a QoS course at work as well. The devices that I work with at work are a bit different than Cisco, so hopefully it will all work out in my brain.

It has been a tough week and weekend. Me and my whole family have been sick and it has slowed things down a bit. Onward and upward, though…

Final Update… IEWB Vol II Ver 4.1 Lab 2

Well, after tallying up all the points and himming and hawwing as to whether I would have gotten some points for a few of them, I got a blazing score of… ready?… 50! I have way more work to do.

Overall, I’m not too sad. There were a few little stupid mistakes, but it really showed me where I sit right now. Trouble areas include redistribution (of course), QoS, Multicast. The IP Services ans Security I did what I knew how to do and winged the rest. I should have used the DocCD more (don’t get me started on the UniverCD). More on that later…

No… I’ll address it now. The DocCD has spiraled downhill. The Master Index for 12.4 is gone. Several of the Cat3550/60 docs are redirected to general cisco.com pages. BGP for 12.4 just doesn’t exist at this time. OK, so what will it be like in the lab? I’ve heard everything from it was the “old” format to they are letting access to links that go outside of the DocCD. So, what if the topic is completely gone? I don’t imagine that they are trying to fix that. The only resource in the lab is jacked up. From the posts on Groupstudy, people are passing, so it must not be that bad. I just needed to seriously gripe.

It’s on to Lab 3 this week. It looks a little tougher, but I will put all I have into it. I will pass this beast in July!

Update… IEWB Vol II Ver 4.1 Labs 1 & 2

OK, It’s been over a month since I last logged my progress. I did have a burn-out for about half a week about two weeks back. So, now back on track.

I have accomplished the first two Vol II IE labs. I am doing OK, but making silly mistakes. I am going through the corrections of Lab 2 and I am finding that I didn’t read the question all the way or missed an item, so I got no points for the task. For example, I missed setting the “primary” talker for LACP; all the other items were right, but just forgot this simple one.

These labs are a level 6 and I seem to be comfortable with this level (not counting the little slips). I will be attempting Lab 3 next, a Level 6 as well. I contemplated moving on to a Level 7, but figured with the small mistakes I’ve been making, I’ll try to work the Level 6 a bit more.

At times when I haven’t been able to connect to the home lab, I have been using dynamips on my laptop to do the BGP Labs of IEWB Vol I. This way I can continue to work on problem areas and still get time with the IOS. This helped a lot with OSPF filtering in all the different scenarios.

The topics that I need to buckle down on learning well are QoS and Multicast (more specifically Anycast and Source-Specific Multicast) and good old Redistribution. CoDs for these, here I come… again.

IEWB Vol III Ver. 4.1 Lab 6

Well, it has been interesting two weeks. I had a close friend pass away and I assisted the family with funeral arrangements and logistics. Plus all the emotional stress had me really down, so it took me half a week to do all the arrangements and a week to recover from it.

I am resuming working on my goal tommorrow. I will keep working on Lab 6 and work on the nightmarish redistribution in this lab. I need to get good at redist. I just have a funny feeling that this may be one of my challenges.

I read on Groupstudy of Kieth Tokash who spoke of his frustration and burnout, looking for an idea of everyone’s study schedule. It is good to know that I’m not the only one who goes through this. I think that as I go through my study sessions, I need to really focus when I study and when I don’t, allow my mind to digest the stuff I’ve learned. Maybe just go over my notes, but not do too strenuous learning. It’s hard not to just go “b***s to the wall” with the deadline coming faster than a freight train on the loose. I do know that I need to resume exercising and eating well. We’re trying to get our 19 mo. old son to sleep in his own bed; that will help with the semi-effective sleep.

So… Lab 6 tommorrow. I am supposed to be on the full 8 hr labs (vol II), but I’ll ponder what I am going to do now due to the lost 2 weeks.

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?

IEWB Vol III Ver. 4.1 Lab3

Some things for this lab -

• I noticed that there wasn’t particular VTP modes mentioned to set the switches to at the very beginning, but I did notice a VLAN 2569 on the segment between R5, R6, R2 and SW3. I remember that VTP can only handle VLAN numbers up to about a 1000, so that immediately told me transparent mode. There wasn’t a switch that didn’t touch the 190.1.0.0 subnet, so all had to be transparent.
• For the Switching section, I did my trunking and then my port-channeling before VTP configuration. This way all the VLANs were propagated; I just had to assign them to interfaces. Then I changed the switches to transparent mode. This “locked” the VLANs in.
• I also had to remember that the trunking needed to be configured on the switch ports first before the port-channeling, then trunking configured again on the port-channel.

All in all, I am thinking clearer and looking at the sections before tackling them to get an idea what will be needed. I am starting to be able to see issues before doing the tasks by looking at the diagram and each section at a time. Pretty soon, I’ll be able to look at the whole lab paper and see the issues as well.

One thing I have considered is doing the FR section first, reboot and then work on the Switching while they reboot. I’ll have to try and see how that will work.

IEWB Vol III Ver. 4.1 Lab2 continued…

A couple of things for this week. I have been hammered with redistribution tasks with this one. Well, I think I went about it all wrong. I configured mutual redistribution on R2 and just moved on without checking anything, assuming that redistribution at one spot shouldn’t have any issues. I then went to do the same on R4 and R5 and created a mess.

A couple of things to learn.

• Verify connectivity within each routing domain first. This way you know everything was good to go before releasing the floodgates.
• Take it step by step and test after each step. Redist one way, test. Redist the other way, test. Make sure that what you think should happen, does happen.
• Remember AD. The higher protocol will take precedence in contention for the routing table.
• When redist, the routing protocol that is being redist into will take all the routes of the source protocol that are active in the routing table for that protocol. Next, it will grab the routes advrtised by the network command of the source protocol. 

On that last point, let’s say a connected loopback is advertised into a protocol and then that protocol is redist into another routing protocol. The loopback network isn’t redist, because it doesn’t meet any of the requirements of the last bullet. Also, it is seen by the router as directly connected (which it is),with an AD of 1, so the protocol won’t even place it in the routing table, so it won’t get pivked up by that criteria either.   It may be in to protocol database, but redist doesn’t even look there to grab routes. Hmmm… Any ideas? The only solution I could think of is to redist the connected loopback the destination protocol directly. Go figure… If there is a requirement that prohibits this, what do you do?