IE SP Vol2 Lab 4

Here we go, 3 days ahead of schedule, woohoo!

1.1 Complete, no issues
1.2 Complete, no issues
1.3 Complete, no issues
1.4 Complete, surprisingly. Even without inverse-arp or mappings, we can configure a p2p subinterface with a broadcast pvc. Per the solutions guide, the broadcast keyword isn't even required. I guess if you have a p2p subinterface with a single pvc, it assumes to send all traffic out that single pvc.

2.1 Complete, no issues
2.2 Complete, no issues. Minimum amount of commands means specify is-type under router isis instead of on each interface.
2.3 Complete, pretty poorly worded task, but adjusting the hello timers took care of it.
2.4 Complete, no issues, for md5 isis authen we need key-chains.
2.5 Complete, no issues

3.1 Complete, no issues
3.2 Complete, wow, the instructions sure could have been more specific here. Nowhere is it mentioned that redistribution should be done. Nowhere is it mentioned that the peering should come up here, just that it should be configured. I guess in theory I should have read the rest of the lab and figured out the design to know what must have to happen here.

Also, the neighbor next-hop-unchanged command stops an eBGP router from updating next-hop advertised from an iBGP peer.

IE SP Vol 2 Lab 3 Complete

I actually feel pretty good about this lab.

Sections 1 - 4 were pretty easy for the most part.
Section 5 was a tough vpn with two P ASs joined by vrf-lite. It turned out to be a great exercise which really boosted my confidence.
Section 6 was a bit over my head when I started, but I feel much better about mdt now. I think I have a pretty good idea what's going on and how to troubleshoot issues.

I'm feeling really good about QoS right now. Funny, I always seem to feel good about QoS yet I tend to get my butt kicked on the lab on this topic.

Security was something completely different. I think I understand how remotely triggered black holes work now.

System management was silly, and IP Services involved ORF, which while a new topic for me, was pretty easy to configure.

So, keeping in mind that I didn't enforce a time limit, I'd score myself about a 79 on this one, since I blew half the multicast and the whole QoS section. Still, not bad for a difficulty 8 lab.

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.