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.
Sunday, February 22, 2009
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.
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.
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
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.
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.
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)
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)
Subscribe to:
Posts (Atom)
Posts
