NetMasterClass.com scenario 11 is the first of the 25 to not include the 3560 Catalyst. I’m assuming therefore that the rest of the practice scenarios won’t have 3560’s either. And frankly, that’s not hurting my feelings. On scenarios 1-10, there were so many technology areas that one scenario could cover, that you always felt spread thin. On this scenario, I felt more focused, and able to stay on track. I think this may have been the “easiest” scenario for me thus far, at least at this point in my preparation. I was able to complete the lab in about 6.5 hours. That’s not to say I was perfect, because I wasn’t. There were a number of things I didn’t know and had to read up on and/or review the answer key to be able to proceed. And as usual, there was at least one brain-buster that I never would have gotten, had I not taken a look at the answer key to see what NMC was trying to teach me. So here we go with another collection of odds and ends I took away from this scenario.
- The IOS global command “ip dhcp relay information option” will populate DHCP option 82 with information about the port that the DHCP request came in on. If the DHCP server can interpret option 82 data, he may be able to serve an IP lease from a different scope.
- OSPF packets have a TTL of 1. So if you are required to maintain all OSPF adjacencies in a full-mesh point-to-multipoint frame even if a PVC goes down, your solution is to use tunnels to form the OSPF adjacencies. The tunnel gets you around the OSPF TTL of 1.
- Some CCIE scenario tasks may have more than one valid answer. This point came up in some reading I’ve been doing this week, and also showed up in this lab. Don’t necessarily lock yourself into the thought process that there must be only one valid way to solve the problem. Case in point on this scenario, I was given an open-ended redistribution task with only one specific requirement. My way was quite a bit different from the NMC way, but they acknowledged right up front that there were several ways to make it work. Since my answer was different, I spent a good bit of time proving that it worked and met the specific requirement.
- I ran into a task that called for “load sharing”. I assumed that meant equal-cost load balancing for all traffic, which was a real bugger since I was trying to make that happen across 2 eBGP links homed to different AS’s. After beating my head on that for a while and finally deciding that I must not understand the task, I went to the answer key to discover that they just wanted traffic split over the 2 eBGP links – not equal cost load-balancing. All that needed to be done was to map a local-pref value to half of the IP address space, and a different local-pref value to the other half. Advertise into the AS from the eBGP neighbors, then let iBGP converge appropriately based on local pref. Simple, actually, but my misunderstanding of the task burned up time.
- The IOS Configuration Fundamentals Command Reference has a long list of commands that do all sorts of interesting and esoteric things. I’m in the habit now, where if I see a task asking me to do some specific IOS function, I’ll hit that command list and start looking for things that seem probable. Today, I ran into “service compress-config” from that list.
- “ip telnet quiet” will suppress telnet connection messages. You’ll find it in the dial technologies section, probably not the first place you’d think to look.
- I discovered that if you are running BGP for IPv4 AND IPv6 at the same time, you need to be careful how you configure your neighbors and neighbor activation. Specifically – when you configure IPv6 neighbors, make sure you do a “no … activate” in the IPv4 address family paragraph for that IPv6 neighbor. Here’s an example of a BGP paragraph I finally got right after experiencing “martian” messages (BGP complaining that he was getting a bogus next-hop IP from a neighbor).
router bgp 100
neighbor 126.96.36.199 remote-as 100
neighbor 188.8.131.52 remote-as 400
neighbor 184.108.40.206 remote-as 100
neighbor 220.127.116.11 remote-as 100
neighbor FEC0::1234:1 remote-as 100
neighbor FEC0::1234:3 remote-as 300
neighbor FEC0::1234:4 remote-as 400
neighbor 18.104.22.168 activate
neighbor 22.214.171.124 activate
neighbor 126.96.36.199 activate
neighbor 188.8.131.52 activate
no neighbor FEC0::1234:1 activate
no neighbor FEC0::1234:3 activate
no neighbor FEC0::1234:4 activate
neighbor FEC0::1234:1 activate
neighbor FEC0::1234:3 activate
neighbor FEC0::1234:4 activate
The martian messages (which went away after I added the “no neighbor … activate” in the address-family ipv4 paragraph) read something like this, I think because an IPv6 address was somehow getting mangled into a funky IPv4 address in the BGP advertisement:
%BGP-3-MARTIAN_IP : [IP_address] Martian prefix [chars] in [chars]
Explanation An invalid IP address has been detected.
Recommended Action Verify the configuration, IP address, and prefix defined on the remote router and make any appropriate corrections.
- If there’s no OSPF area 0 explicitly configured (and you aren’t allowed to use the keywords “area 0” anywhere), you can implicitly create an area 0 using a virtual link.
- There is an IOS security feature called Role-Based CLI Access, which allows you to create a set of commands in the form of “parser views” limit what commands view users have access to. I recommend you read up on it if you’re not familiar with it – I had no idea the feature existed, and it’s quite powerful. You can allow views with specific commands or wildcard commands. You can also nest multiple views into a “super view”.
- Multicast VLAN registration is a Cat3550 feature that allows you to, in essence, bridge multicast traffic from one VLAN to another through the switch with no reliance on multicast routing. In my opinion, it’s a little ugly. Maybe a lot ugly. But it’s one of those things that seems good to be aware of, and I’m sure has its place in the real world.