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