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
Wednesday, February 18, 2009
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.
Saturday, January 24, 2009
Conditional Debug
I came across this useful nugget the other day, wishing I knew about it years ago.
One of the first considerations when turning on a debug is that you can potentially bring a router to its knees. In theory, you should only log to the buffer, assign an access list to the debug, and adjust the scheduler to ensure that a certain amount of time is dedicated to essential process, blah, blah, blah.
Even when following these precautions, it can be gut-wrenching to even consider running a debug that you know is going to generate A LOT of output.
Take for example, debug ppp packet. What if you have a router that has tens, or even hundreds, of interfaces running ppp? Yet you need something beyond debug ppp authentication and debug ppp negotiation. There is not an option to specify an ip address on debug ppp packet, like there is for debug ip packet. No wonder, since ppp is layer 2.
There is still a safe way to do this (disclaimer: test this in the lab first, don't blame me if you muck up your production network!)
debug condition interface [interface] allows you to only perform the debug on a specified interface.
For example, say you have a native 6500 with 336 interfaces, and you want to debug ip packet on interface f2/41. You don't really want to use an access list because you're more interested in all traffic on the interface, rather than a specific set of IPs.
You can do the following:
debug condition interface f2/41
debug ip packet
And the result is you'll only see ip packets associated with f2/41, instead of all 336 interfaces.
Further details can be found here.
One of the first considerations when turning on a debug is that you can potentially bring a router to its knees. In theory, you should only log to the buffer, assign an access list to the debug, and adjust the scheduler to ensure that a certain amount of time is dedicated to essential process, blah, blah, blah.
Even when following these precautions, it can be gut-wrenching to even consider running a debug that you know is going to generate A LOT of output.
Take for example, debug ppp packet. What if you have a router that has tens, or even hundreds, of interfaces running ppp? Yet you need something beyond debug ppp authentication and debug ppp negotiation. There is not an option to specify an ip address on debug ppp packet, like there is for debug ip packet. No wonder, since ppp is layer 2.
There is still a safe way to do this (disclaimer: test this in the lab first, don't blame me if you muck up your production network!)
debug condition interface [interface] allows you to only perform the debug on a specified interface.
For example, say you have a native 6500 with 336 interfaces, and you want to debug ip packet on interface f2/41. You don't really want to use an access list because you're more interested in all traffic on the interface, rather than a specific set of IPs.
You can do the following:
debug condition interface f2/41
debug ip packet
And the result is you'll only see ip packets associated with f2/41, instead of all 336 interfaces.
Further details can be found here.
Sunday, January 18, 2009
IE Vol 1 Auto-RP Filtering Candidate RPs Complete
Ok, it's obvious whoever wrote this part of the workbook wasn't paying close attention to subnet masks. There are several mistakes here.
To filter, from the mapping agent side, which RPs will be announced for a particular group, use the ip pim rp-announce-filter. The tricky part here is that, the only part is not that an entry required for each RP and its associated groups that should be allowed. An extra entry explicitly denying remaining RPs and groups must be added as well, to prevent rouge RPs.
To filter, from the mapping agent side, which RPs will be announced for a particular group, use the ip pim rp-announce-filter. The tricky part here is that, the only part is not that an entry required for each RP and its associated groups that should be allowed. An extra entry explicitly denying remaining RPs and groups must be added as well, to prevent rouge RPs.
IE Vol 1 Multiple Candidate RPs Complete
In this lab, two candidate RPs are created, which only advertise a portion of the multicast addresses. This requires the group-list option of the ip pim send-rp-announce command. Not much to it, just configure the access list to only allow the multicast groups that the router wants to be an RP for.
There is one thing to keep in mind on this command. Typically, whenever creating a multicast access-list, you want to use the destination address, since a multicast group can only be a destination, and not a source. But we are not filtering here, we are telling the RP which groups to advertise. Therefore, the groups to be advertised are configred as the source of the access-list. Perhaps more easily, a standard ip access-list can be used.
On a minor irritating note, the lab specifies a /4 address, when it should have used a /5. /1 is a class A, /2 is a class B, /3 is a class C, therefore /4 would be the entire class D. To split a class D down the middle, a /5 is required.
There is one thing to keep in mind on this command. Typically, whenever creating a multicast access-list, you want to use the destination address, since a multicast group can only be a destination, and not a source. But we are not filtering here, we are telling the RP which groups to advertise. Therefore, the groups to be advertised are configred as the source of the access-list. Perhaps more easily, a standard ip access-list can be used.
On a minor irritating note, the lab specifies a /4 address, when it should have used a /5. /1 is a class A, /2 is a class B, /3 is a class C, therefore /4 would be the entire class D. To split a class D down the middle, a /5 is required.
IE Vol 1 Auto-RP Complete
Again, nothing fancy here. First the interfaces are configured for sparse-dense mode. Once configured this way, the multicast flow works, since it falls back to dense mode when an RP is not known for a flow.
So the trick is to get that RP learned dynamically. There are two dynamic RP protocols: Auto-RP and bootstrap RP. This exercise uses auto-rp, but they are both very similar.
Two things are required for the dynamic registration to happen. First, at least one router must advertise one of its interfaces as a candidate rp, using ip pim send-rp-announce. This advertisement happens via multicast group 224.0.1.39. Since there is no rp for this group, it uses dense mode and will get flooded/pruned.
Next, a router must be configured to listen for 224.0.1.39 messages. This is done via the ip pim send-rp-discovery command, and this router is called a mapping agent. It can be on the same or a different router. Once added, the mapping agent acts as a receiver on 224.0.1.39. Therefore, the routers must graft this receiver on to be a listener for this group. This means any RPF checks must be successful on the 224.0.1.39 group to ensure messages from the candidate rp(s) are being received by the mapping agent.
The mapping agent decides on a candidate rp and advertises its selection out via dense mode to group 224.0.1.40. Through this group, all routers learn the RP for the group, and can the flow can use sparse mode.
So the trick is to get that RP learned dynamically. There are two dynamic RP protocols: Auto-RP and bootstrap RP. This exercise uses auto-rp, but they are both very similar.
Two things are required for the dynamic registration to happen. First, at least one router must advertise one of its interfaces as a candidate rp, using ip pim send-rp-announce. This advertisement happens via multicast group 224.0.1.39. Since there is no rp for this group, it uses dense mode and will get flooded/pruned.
Next, a router must be configured to listen for 224.0.1.39 messages. This is done via the ip pim send-rp-discovery command, and this router is called a mapping agent. It can be on the same or a different router. Once added, the mapping agent acts as a receiver on 224.0.1.39. Therefore, the routers must graft this receiver on to be a listener for this group. This means any RPF checks must be successful on the 224.0.1.39 group to ensure messages from the candidate rp(s) are being received by the mapping agent.
The mapping agent decides on a candidate rp and advertises its selection out via dense mode to group 224.0.1.40. Through this group, all routers learn the RP for the group, and can the flow can use sparse mode.
Subscribe to:
Posts (Atom)
Posts
