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