Saturday, February 28, 2009

IE Vol 2 Section 6

6.1 Complete. No issues, just a tunnel.
6.2 Complete, just need to make sure the tunnel passes the rpf check.
6.3 Complete, ip multicast-boundary does the trick.

Thursday, February 26, 2009

IE Vol 2 Section 5

5.1 Complete, no issues although it did take me a bit to figure out exactly what they were asking for. I'd definitely get some proctor clarification on this in the lab.

5.2 Complete, although the solutions guide also had an "assumed tasks" that weren't specifically mentioned in the task itself.

Getting the pe-ce ospf and ospf-bgp redistribution running wasn't an issue at all. However my AS100 pe and ce could not reach site 2. It turned out this was because vpnv4 next-hop-self wasn't turned on for the as100 P router. Because of this, the PE saw the AS200 link as the next hop, rather than the P router's loopback. The AS200 link was not in the mpls forwarding table, so the PE router sent this packet out without a label. The P router would then receive an mpls vpn labeled packet with no forwarding label, and have to drop the packet. Adding the vpnv4 next-hop-self instead showed the P router loopback as the next hop, which the PE router did have in its mpls forwarding table, therefore the mpls path was intact.

The solutions guide also had R4 advertise ospf external routes. I see why this was done, since it's necessary so that site 1 can reach site 2's external ospf networks. But the task does not call for this. It should have stated that this reachability is required.

5.3 I ALMOST had this completed. The nat took me awhile but I finally got it running. I was hung up on the static route for leaking routes into the vrf. The issue I couldn't fix was in having R4 use redundant paths for the static route to R3. I was missing the global keyword on the static route. This allows a recursive lookup to the global routing table for the vrf static route. Once that was added, I had to put another next-hop-self on R5->R4 to allow reacability to external prefixes.

5.4 Ok, I was completely lost on this one. I knew I needed to filter routes going to the CE without adding vfr's to the CE routers. I just wasn't sure of the mechanism to do this. So now I know a new trick, which I'm sure will be invaluable on the real lab. ip vrf export maps, which use route-maps to selectively assign route-targets to specific routes. I definitely need to write that to my own memory.

IE Vol 2 Section 4

4.1 Complete, no issues
4.2 Complete, this one took me a bit. After searching the docs and ? there didn't seem to be another way to filter neighbors. Then it dawned on me that we're using port 646. So an access list preventing tcp port 646 from anywhere but the desired neighbor would take care of this.

The solutions guide went a little further and blocked udp 646 and forced the transport mpls address as well. I don't see why udp 646 needs to be blocked. Even if hellos get through, the session would never be brought up unless tcp 646 was reachable. I guess it may be a little cleaner that way, but shouldn't be necessary.

4.3 Complete, no issues

Wednesday, February 25, 2009

IE Vol 2 Section 3

3.1 Complete, no issues--just had to ensure next-hop-self was set appropriately, since remote AS does not have reachability to local AS link IPs.

3.2 Complete, no issues.

3.3 Complete, no issues. The lab didn't specify to filter the summary internally, so I left it in. I'd probably ask a proctor.

3.4 Complete, strange wording but no issues.

3.5 Complete, no issues. If you don't want downstream ASs to see you changes, use MED instead of as path prepend.

Tuesday, February 24, 2009

IE Vol 2 Section 2

2.1 Basic IS-IS config. It did take me a while to figure out how to configure IS-IS on the ATM interface.

debug isis adjacency-events spelled out the issue right away:
ISIS-Adj: Encapsulation failed for L2 LAN IIH on ATM4/0

To resolve this, the neighbor clns net address, along with clns broadcasts, needed to be mapped to the pvc. According to the solutions guide, it looks like I could have just mapped address 00, along with broadcasts, instead of the full net address, to save a little bit of time.

2.2 No problems, if I can't assign the interface, then redistribution does the trick. The solutions guide says to use the passive-interface isis, which is good to know. But my solution works fine as well.

2.3 The instructions ommited a few links that were on the diagram, but aside from that no issues. I LOVE the simplified routing in SP. As usual, a loopback needs to be changed to point-to-point to report its subnet mask appropriately.

2.4 OSPF fast hello timers report links down in less than a second.

Monday, February 23, 2009

IE Vol 2 Lab 2 Section 1

Again, I'm going to be taking my time and going through everything with a fine tooth comb.

1.1. No problem--I love the simplified switching tasks.
1.2 The default config had the wrong lmi type specified. Not sure if IE did this intentionally, but it ended up being a good troubleshooting exercise anyway.
1.3 No problem
1.4 EEK
1.5 Doccd to the rescue. Pretty much like frame-relay. Just assign the ip address, create the pvc, and assign the ip mapping to the pvc, including broadcasts.

1.6 PPPoE. Ugh, I was thrilled when they removed isdn from the R&S lab. I have never been a big fan of dialer interfaces. Well, here they are again in PPPoE. The docs are also in a bit of a different place: the broadband access guide.

Sunday, February 22, 2009

Updated Study Plan

I'm not quite as far along as I'd like to be. A lot of the reason behind this has been due to an increased work-load, a lack of equipment, and just plain procrastination.

There isn't much I can do about the increased work-load, other than hoping things slow down some.

Now that I have Dynamips running the full VolII lab, a lack of equipment isn't an issue any more.

And as far as procrastination, as the lab date nears this should be less of an issue.

Here is my updated agenda:

Week of 2/22: Vol II Lab 2
Week of 3/1: Vol II Lab 3
Week of 3/9: Vol II Lab 4
3/14: Vol II Lab 5
3/15: Vol II lab 6
3/21: Vol II lab 7
3/22: Vol II lab 8
3/28: Vol II lab 9
3/29: Vol II lab 10

The main issue here is I'm going to be working my butt off the 2 days before the lab, so I might burn myself out. So ideally work will be kind and I'll be able to get labs 2, 3, and 4 done ahead of schedule.

IE Vol2 Final Thoughts

I'm glad I took the time to go through this lab at a slower pace. More than anything, I got a LOT more comfortable with TE and Multicast, but I know I still have some work to do on QoS. I also listened to one of the QoS CoD's. I also found the MPLS QoS link, so I'll try lab 2 following the link to see if it goes any better.

The key here is, if the SP lab is similar to the R&S lab, this is as complicated as HALF of the lab will be. It would be impracticle for expect anyone to be able to pass an 8 hour lab if every single topic was covered to the nth degree. Instead, about half the lab is just going to be the basics.

So I know I'll be able to get something basic up and running. Over the next 9 labs, I just need to prepare for the curve balls that will be thrown at me. Aside from that, I think about the only completely new topic I haven't covered yet will be PPPoE, which on the downside, I hear can be a major pain.

IE Vol 2 Lab 1 Repeat Continued

Section 8: Security. Nothing new here--same type of stuff from R&S.

Section 9: Looks like I'll need to commit the mpls traffic-eng logging command to memory.

Section 10: Turning off ttl propagation stops the routers from reporting next hops in telnet.

MPLS QoS in a nutshell

Well this link pretty much explains everything regarding MPLS QoS. It's another feature guide, so I definitely need to commit the 12.2T.13 feature guide index to memory.

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftdtmode.html

IE Vol 2 Lab 1 Repeat Continued

Section 7 - QoS

Wow, as if QoS wasn't hard enough to begin with, matters sure get even more complex when MPLS is involved.

I actually had to go back and watch the CoD on this to get an idea on what's going on.

The bottom line is there are two key points to keep in mind:
1. There are multiple labels on the stack and the router can only look at the topmost layer on ingress.
2. Labels are swapped and/or popped so extra steps may need to be taken to ensure the packet is classified correctly on egress.

In a full lab scenario, the label stack is likely to consist of:
Bottom: VPN label imposed by the PE router
Middle: TE label imposed in the P network
Top: Link label imposed on a hop-by-hop basis

I still need to work out all the intricacies involved here. But the bottom line is there are two special cases. First, sometimes an explicit null needs to be included, instead of an implicit null. This is called Ultimate Hop Popping, and ensures QoS information is carried throughout the last hop. Second, sometimes a qos-group is needed. I still need a better understanding of when and why this is required.

Thursday, February 19, 2009

IE Vol 2 Lab 1 Repeat Continued

5.1 Complete, no issues
5.2 Complete, no issues
5.3 Complete, no issues
5.4 Complete, no issues

5.5 Complete. Now this one took me awhile. I'm really not that great with NAT on routers. I've spent a lot more time with it on firewalls, so it always takes me awhile to get the differences under control. Fortunately, the doccd has a great vrf nat section. I just always seem to forget to assign the nat inside and nat outside interfaces. Once that was done, it came right up. debug ip nat vrf came in pretty handy.

5.6 complete, no issues
5.7 complete, no issues

6.1 Complete. I'm actually getting a lot better at multicast now. Things are finally starting to click--it only took me 1.5 CCIEs to get there.

6.2 So much for feeling comfortable with multicast. Now I had no idea what I was doing here. I must confess, I skipped the vol 1 mpls multicast section. There really isn't too much more to this, and there's a great link on the doccd, even it if is a bit hard to find. It's under 12.2, new features, 12.2.T.13, Multicast VPN. The bottom line is a mdt group needs to be created under the vrf, loopback 0 needs to be configured for ip pim sparse-mode, and any RPF issues in the core relating to the mdt group must be resolved.

6.3 No problem after 6.2 is complete.

IE Vol 2 Lab 1 Repeat Continued

All I can say is task 4.4 is awful!

For starters I'll admin TE is far from my strongest subject. That being said, the scenario in the lab just plain does not work.

To begin with, extreme care must be taken to ensure ip rsvp bandwidth and mpls traffic-eng tunnels is added to all interfaces in the path. Missing a single one will kill the tunnel and make troubleshooting very difficult.

Next, there is apparently an incompatibility with using dynamic TE paths if there is an ospf non-broadcast link in the path. Since the lab calls for this, the dynamic tunnel will not come up. One work around is to change that link type to point-to-multipoint non-broadcast.

Finally, even after fixing everything I still couldn't get the tunnel up. I checked with one of my CCIE SP coworkers, and he was going to hop on to take a look. Of course, once I powered everything up the TE tunnel came right up. Apparently something got hung and required a reboot to clear.

On the bright side, I feel I did get a lot of experience troubleshooting TE tunnels. The most useful commands I used were:

sh ip rsvp int
sh mpls traf tun
sh mpls traf link int
sh mpls traf topo
sh ip ospf data (the Opaque Link Area section)

Wednesday, February 18, 2009

IE Vol2 Repeat Continuted

3.1 Complete, no issues
3.2 Complete, no issues
3.3 Complete, no issues
3.4 Complete, no issues. I had a hard time with this task my last attempt. I think it's because I didn't verify my routes were valid. A simple sh ip bgp x.x.x.x would have shown this, which would explain why one of my paths wasn't getting installed into the routing table.

4.1 Complete, no issues
4.2 Complete, no issues
4.3 Complete, no issues

Sunday, February 15, 2009

IE Vol 2 Repeat

Ok, this time I'm going to take my time and go through every single bit of vol 2 lab 1 to make sure I have it all down pat.

1.1 Complete, piece of cake
1.2 Dynamips doesn't seem to support "switchport protected"
1.3 No problem
1.4 No problem
1.5 No problem
1.6 I got hung up here because I don't know how to read. A VPI/VCI control pair is specified for R1. I tried to apply this to R1 and R9 and then the bindings wouldn't come up. Once I removed the mpls atm control-vc from R9, all was good.

2.1 No problem
2.2 No problem
2.3 No problem

Study Update

It took me a little while to get back to studying. First off IE's SP labs were full for pretty much the whole month. Unfortunately my workstation was not powerful enough to run the full SP vol 2 lab in Dynamips (13 routers).

I was finally able to get access to a powerful enough box to run it (dual-core 5140 with 4 GB ram). The routers are flying now.