1,272 Words. Plan about 8 minute(s) to read this.
I ran through NetMasterClass.com DOiT Vol.2 scenario 23 on Saturday. It took me about 7.5 leisurely-paced hours. I took my time, working through each task I knew as quickly and efficiently as I could, but still not rushing. The tasks I didn’t know, I was mostly able to find on the Doc CD with little trouble. And the odds and ends that had me scratching my head, I worked through with the NMC answer key.
My highlights from this practice lab follow. As always, please register on the blog and add your comments if you have something to say. I especially appreciate the comments from folks who did the scenario, but were struck by something I didn’t comment on.
- You can turn off frame relay inverse-arp selectively by DLCI, using “no frame-relay inverse-arp IP DLCI-number“. This allows you to use inverse-arp on the DLCIs you want to utilize, but still ignore other DLCIs you don’t want to use. This is particularly handy with physical interfaces, where DLCIs are automatically assigned if you haven’t assigned them to a subinterface.
- I faced an interesting OSPF problem where I was oh-so-close to the right answer, but was missing an important detail. The scenario was where you’ve got 2 ABRs R3 & R4) sitting in between area 0 & and NSSA area 30. In area 30, you’ve got CAT1 redistributing a connected route. R1 is in area 0. R1 neighbors with R3 & R4 in area 0. CAT1 neighbors with R3 & R4 in area 30. The task was so make sure that R1 used R3 as the next-hop for the redistributed route coming from CAT1, and that R4 saw the redistributed route as an N1.I was thinking (correctly) that this was the deal where one ABR is going to become the type-7 to type-5 translator. If I left defaults alone, R4 would be elected to have the 7-to-5 role, since he had the highest RID. So, I bumped up R3’s RID to be higher than R4’s, figuring that R4 would get the job of 7-to-5 translation, and be seen by R1 as the source of the redistributed route coming off of CAT1. I was correct, as far as that went. But, I didn’t have quite all the information I needed to know what was going to happen next.
Image is � NetMasterClass.com…
The issue that I didn’t see coming was that R4 ended up seeing the redistributed route as an E1 instead of an N1. So, R1 ended up seeing the redistributed route sourced from both R3 and R4, instead of just R3. So why did R4 see that redistributed route as an E1? You’d think, since R4 was attached to area 30, and CAT1 was redistributing the route into the NSSA area, that R4 would see an N1…but no. So what happened? What happened was that R3, as the 7-to-5 translator, sent out the N1 into area 0 as an E1…which is what’s supposed to happen. R1 received that type-5 LSA, and then advertised it to R4 via area 0…which is also supposed to happen. Here’s the problem: now you’ve got R4 knowing this LSA from 2 different sources. He knows it from CAT1 as a type-7/N1. He knows it from R1 as an type-5/E1. The destination subnet, the cost, and forwarding address were all the same for the E1 and N1 advertisements, so how would R4 break the tie? R4 broke the tie by preferring the E1 advertisement.
To fix this issue, you go to your 7-to-5 translator, and add the “area nssa translate type7 suppress-fa” command. This will strip out the forwarding address from the LSA, meaning that the router doing the advertising is assumed to be the next-hop. When I inserted that command on R3, R4 then preferred the N1 route, and R1 saw R3 as the only way to get to CAT1’s redistributed route.
- In IPv6 redistribution, “include-connected” doesn’t mean what I thought it meant. I thought it meant it would include all the, you know, connected networks…like maybe you could use that instead of “redistribute connected”.What it means is this, taken from the Doc CD: “include-connected (Optional) Allows the target protocol to redistribute routes learned by the source protocol and connected prefixes on those interfaces over which the source protocol is running.”
So, you still have to “redistribute connected” in IPv6. That’s one of those things that’s good to know before you burn 30 minutes in the lab wondering why some of your IPv6 prefixes aren’t pingable.
- I admit to being overly creative when I tackled the redistribution. I was trying to handle multiple points of mutual redistribution without using access lists to filter what was allowed where. There wasn’t any need to do anything other than simple ACLs to control the redistribution. I ended up screwing with OSPF & EIGRP redistribution metrics.I almost never see an NMC redistribution solution that involves metric tweaking. All the NMC redistribution scenarios involve tweaking administrative distance and using ACLs to prevent route feedback. Did I end up with a stable topology that met all of the scenario requirements? Yes, I did. Did I do it like the NMC answer key? In parts, but not everywhere. I say all that to make this point: I had a problem with one prefix because of the way I decided to do redistribution. If I had done it the NMC “cookbook” way, I would not have had that problem. I think I’ll be better served to get to a standard way of tackling redistribution, and do it the same way every time, as much as possible. That way, I know what works, and I know how to execute it quickly. As I’ve discovered, a lack of time is as big an enemy as a lack of knowledge when it comes to passing the lab.
- This scenario covered stateful NAT, which I never quite got working due to what I believe were IOS bugs. As it worked out, I needed to configure stateful NAT on my 2600s, which have a 12.3 build, instead of 12.4. The commands were there, but I had trouble with tracebacks and generally flaky behavior. The idea behind stateful NAT is that one router keeps another’s NAT table synchronized. That way, if the primary NAT routers falls off the network, existing NAT translations will continue to flow unimpeded through the backup NAT router because of the mirrored NAT translation tables.
- In QoS, I ran into a painfully simple command that I had not run into before. When in a policy-map, you can apply the command “drop” to a class of traffic. For any traffic in that class, the QoS policy will drop it.
- I was given a task to configure system logging for successful and failed login attempts. The task further instructed to slow down dictionary attacks by introducing a 3 second delay between login attempts. And finally, if 2 login attempts to R5 failed within a 15 second period, R5 shouldn’t allow any logins for 10 seconds, unless the attempt comes from 18.104.22.168. These features all refer to Cisco IOS Login Enhancements (Login Block). Here’s the code.
login block-for 10 attempts 2 within 15
login delay 3
login quiet-mode access-class OVERRIDEQUIET
login on-failure log
login on-success log
ip access-list standard OVERRIDEQUIET
Okay, not my most scintillating post ever, but I needed to get this one done. I’m working on my reading list this week, and very possibly going to register for a bootcamp this week. I’ll end up updating my Lab Roadmap to reflect whatever I settle on for bootcamp. Because I’m planning on a bootcamp, I think, I’m skipping out on the week o’ labs I had originally scheduled for this week.