IE SP Vol 2 Lab 3 Task 10

10.1 Complete. While I knew the theory from the CCIP, this is the first time I actually configured ORF. The guide on the doccd doesn't really explain much, the key is to keep in mind that it's backwards from what it appears. The CE is the sender and the PE is the receiver. The CE router defines a prefix-list and sends it to the PE router, which then filters the prefixes it sends accordingly.

IE SP Vol 2 Lab 3 Task 9

9.1 Complete, I hate menus...just seems like stupid router tricks
9,.2 Complete, username secret

IE SP Vol 2 Lab 3 Task 8

Source Based Remotely Triggered Black Hole Filtering. Wow, that's a mouthful. I've never heard of this before.

In a nutshell--part of the problem with a DOS attack is that it consumes bandwidth. Even if a customer drops packets on an inbound access list, the circuit would still be congested.

This is a way to allow a customer to have the provider drop traffic inside of the P network, so the PE-CE link does not get saturated.

To do this, the customer simply advertises a route with a prearranged tag to the PE router. The PE router will then ensure that traffic from this source gets dropped instead of clogging the link.

Sounds great in theory minus one important concept. Single host DOS attacks are really not that big of an issue. Heck, you could just as easily get your ISP on the phone and have them shun a single host. The manual effort of adding tagged null0 routes would do little to stop a distributed DOS attack, or one that randomly spoofs source addresses.

Anyway, as far as the task:
8.1 Mostly Complete. I was close--for being unsure of what they were looking for, I was happy I made it as far as I did.
8.2 Again mostly complete.
8.3 I did it a different way, but complete.

IE Vol 2 Lab 3 Task 7

7.1 Complete. No issues, same as R&S. If you can't use MQC, there's always CAR.

7.2 Complete. No issues, if you can't use an access list, use a custom nbar port-map.

7.3 Complete. Surprisingly, no issues. Like the solutions guide, I opted to not use qos-groups since the underlying packet was marked ef as well.

One note on QoS. I usually don't bother to use ip sla to test it. Big mistake!!! I have to get into the habit of setting this up every time. It's just way to easy to watch the counters to ensure everything is setup correctly.

IE SP Vol 2 Lab 3 Task 6

Ok, this multicast task was a bit rediculous too. Now on the bright side I was pretty much able to nail the config. But when I got down to the test, I was not able to get it to work at all. I went through the solutions guide and primarily found one mistake--that I didn't have the mdt router's loopback interfaces running pim. Even upon fixing this, however, the multicast test still did not work.

-----12 hours later-----

I was really starting to get desperate here, but I FINALLY got everything figured out. It basically boiled down to two things:

1. sparse-mode requires autorp listener for the autorp groups to be able to pass through. Without it, autorp will not function across sparse-mode interfaces.

2. On mVPN, rp's are required for both the main routing instance and the vrf. This was my main mistake. I was missing a static rp on a vrf interface.

So, after a long time of being worried I had no idea what I was doing and that this stuff was way over my head, it turned out to be silly mistakes that did me in.

As with other topics I spent so much time on troubleshooting an issue, I really hope all this time put in helps me the next time I come across mVPN. I'm feeling pretty good about it now, but we'll see how it goes next week.

If multicast contines to be this complex, I may need to draw a mVPN diagram in order to keep all the tunnels and vrf's straight.

IE Vol 2 SP Lab 3 Task 5

5.1 Complete, no issues
5.2 Complete, no issues
5.3 Complete, no issues
5.4 Wow, what a task. I now see why this lab gets an 8. For 2 bullet points, there is a heck of a lot of assumptions that have to be made, tons of redistribution, and a bunch of vrfs to keep track of. I actually made my way through this pretty well, but it certainly took some time. An excellent exercise to validate understanding of the big picture.
5.5, piece of cake after making it through the last task.

IE Vol 2 SP Lab 3

Here we go with lab 3, right on schedule. Again, I'll be spending a full week on this one, taking my time to research and experiment with anything I'm not confident on. This lab moves up to a difficulty rating of 8, so I'm assuming there will be some curve balls thrown in this time.

1.1 Complete, no issues
1.2 Complete, even in transparent mode, dynamips doesn't seem to allow extended vlans on the ethernet modules.
1.3 Complete, no issues
1.4 Complete, no issues
1.5 Complete, had to change the label protocol to tdp.

2.1 Complete, no issues--no DR? use p2p or p2mp
2.2 Complete, no issues--no area authen? put it on the interface
2.3 Complete, stupid mistake. I couldn't get the isis adjacency up across the frame-relay interface. I thought there may have been some trick here since the frame-relay map had to support clns. Turns out I missed configuring isis on the interface to begin with. A dumb mistake that would have cost me valuable time in the lab.
2.4 Wrong. I used the isis password command. However, this exchanges the passwords in plain text. To do md5, an authentication key-chain must be used ala rip and eigrp.

3.1 complete, no issues
3.2 complete, no issues
3.3 complete, no issues. I'm probably splitting hairs a bit here, but the maximum prefix drops the connection when the limit is exceeded. Since the requirements specify that if the table "continues to grow to 12,000", to me this means at 12,000 the connection should be reset, meaning maximum-prefixes is 11,999. I'd hope the lab wouldn't be quite this particular, but who knows.

4.1 Complete, no issues. Here's where the tdp requirement from earlier gets specified.
4.2 Complete, no issues.

Well so far this lab is laughable. I'm assuming it's gonna it rough here shortly, because the difficulty is nowhere near an 8 so far.