Time once again to change things up for a timed lab. This is the second to last of the Vol 2 labs. It also has a difficulty of 7, which generally means its difficulty closely mirrors that of the real thing. So I need to pay close attention to my performance on this one.
12:15am lab started
Layer 2
12:26am 1.1 complete
12:28am 1.2 complete
12:45am 1.3 complete, fun with inverse-arp. Will probably need point-to-multipoint for ospf.
12:48am 1.4 complete
12:53am 1.5 complete
Layer 2 complete, 10/10, 0:38
IGP
12:58am 2.1 complete
1:00am 2.2 complete
1:02am 2.3 complete
1:08am 2.4 complete
1:10am 2.5 complete
1:19am 2.6 complete
1:22am 2.7 complete, had to manually redis loopback on r1
IGP complete, 15/15, 0:29
EGP
1:24am 3.1 complete
1:28am 3.2 complete
1:30am 3.3 complete
EGP complete, 7/7, 0:08
MPLS
1:33am 4.1 complete
1:36am 4.2 complete
2:05am 4.3 complete
MPLS complete, 8/8, 0:35
VPN
2:33am forced break
3:59am back from break
4:05am 5.1 complete
4:11am 5.2 complete
4:30am 5.3 complete
4:55am 5.4 complete
5:05am 5.5 complete, as-override
5:26am 5.6 complete, domain-id
5:32am 5.7 complete, export map
5:38am 5.8 complete, one label still shows, but it's in vrf 100, so should be ok
5:47am 5.9 complete
VPN complete, 25/25, 2:16
Time so far: 4:06
Multicast
6:36am skipping multicast, having issues with p2mp network
taking break
10:25am back from break
QoS
10:30am 7.1 complete, assuming it's ok to do this from the router side instead of the switch side
10:35am 7.2 complete
10:40am 7.3 complete
Qos complete, 8/8, 0:15
Security
10:46am 8.1 complete, permit means don't do uRPF check
11:13am 8.2 complete, got pppoe going!!!
11:30am time's up, almost had it
Security incomplete 6/11, 0:44
System Management, no time, 0/3
IP Services, no time, 0/5
Total possible, 79/100.
Time spent: 5:03 :(. I had too many distractions during the night and by time 6:30am got here I was just too tired to go on. I KNOW I could have completed 8.3, 9.1, 10.1, and 10.2. So all that really leaves is multicast. If this were my actual lab, I'm about 99% sure I would have passed it.
Reviewing the solutions to see if I missed anything:
Task 5.8 added the keyword forwarded
For 6.1, it looks like I did what I needed to . I remembered autorp listener and nbma mode, so I'm not sure why I couldn't get it to work.
Realistically, if I had 8 hours, I would have definitely got 8.3, 8.4, and 9.1. Most likely 10.1 and 10.2 as well, but even if I don't include those I'm still looking at 87%, which is passing.
Friday, March 20, 2009
Tuesday, March 17, 2009
IE SP Vol 2 Lab 8
Layer 2
1.1 no issues
1.2 no issues
1.3 no issues
1.4 unfortunately I had to look this one up. All I needed to do was to create an mpls subinterface and configure mpls ip on it. I'm not sure why I couldn't figure that out. Been dealing with pvc's so much lately, and didn't even need one this time.
IGP
2.1 no issues
2.2 no issues
2.3 no issues
2.4 no issues
EGP
3.1 well I mapped the peer group, but I didn't actually use it. The task could have been a little more restrictive to actually for me to use it.
MPLS
4.1 no issues
4.2 no issues
VPN
5.1 no issues
5.2 no issues, allowas-in
5.3 I used an export map, but the solutions guide wanted soo. Either way works fine.
5.4 I had to get creative on this one. A couple of TE tunnels with MED thrown in seemed to do the trick.
5.5 ok, the TE tunnel killed my redundancy. Now I could have probably done something really fancy with the tunnels to work around this, but it made more sense to get rid of them altogether and follow the solution guide. So I went with local preference, which for this task worked much better. Aside from that, some rip redistribution did the trick.
5.6 finally, an easy one
1.1 no issues
1.2 no issues
1.3 no issues
1.4 unfortunately I had to look this one up. All I needed to do was to create an mpls subinterface and configure mpls ip on it. I'm not sure why I couldn't figure that out. Been dealing with pvc's so much lately, and didn't even need one this time.
IGP
2.1 no issues
2.2 no issues
2.3 no issues
2.4 no issues
EGP
3.1 well I mapped the peer group, but I didn't actually use it. The task could have been a little more restrictive to actually for me to use it.
MPLS
4.1 no issues
4.2 no issues
VPN
5.1 no issues
5.2 no issues, allowas-in
5.3 I used an export map, but the solutions guide wanted soo. Either way works fine.
5.4 I had to get creative on this one. A couple of TE tunnels with MED thrown in seemed to do the trick.
5.5 ok, the TE tunnel killed my redundancy. Now I could have probably done something really fancy with the tunnels to work around this, but it made more sense to get rid of them altogether and follow the solution guide. So I went with local preference, which for this task worked much better. Aside from that, some rip redistribution did the trick.
5.6 finally, an easy one
Monday, March 16, 2009
2 weeks out
I sit for the lab on March 30th, 2 weeks from today.
Thus far, I have completed the following:
IE Vol 1, all labs
IE Vol 2, labs 1-7 (4 and 7 were only partially completed)
At this point I feel pretty comfortable with most of the topics. I'm still a little concerned with the following:
MSDP - I just don't have the big picture on this yet
TE - I can get the tunnels up just fine now, but routing vpn traffic across the tunnel gives me problems
PPPoE - I just plain need more practice
AToM - Haven't touched it
My game plan is as follows:
Squeeze in labs 8, 9, and 10 during the week
Study SP scenarios during the week
3/21 - Repeat Lab 4
3/23 - Repeat Lab 7
3/28 - Whatever I need the most
The big thing I'm doing differently in studying for the SP lab vs R&S is I'm going slowly and banging away until I figure out the issues. I definitely like this approach better. But on these last 3 timed attempts, I'll need to do it like it's for real to help me decide which tasks to skip, etc.
Thus far, I have completed the following:
IE Vol 1, all labs
IE Vol 2, labs 1-7 (4 and 7 were only partially completed)
At this point I feel pretty comfortable with most of the topics. I'm still a little concerned with the following:
MSDP - I just don't have the big picture on this yet
TE - I can get the tunnels up just fine now, but routing vpn traffic across the tunnel gives me problems
PPPoE - I just plain need more practice
AToM - Haven't touched it
My game plan is as follows:
Squeeze in labs 8, 9, and 10 during the week
Study SP scenarios during the week
3/21 - Repeat Lab 4
3/23 - Repeat Lab 7
3/28 - Whatever I need the most
The big thing I'm doing differently in studying for the SP lab vs R&S is I'm going slowly and banging away until I figure out the issues. I definitely like this approach better. But on these last 3 timed attempts, I'll need to do it like it's for real to help me decide which tasks to skip, etc.
Lab 6 Task 6 - 9
Ok, back to finish off lab 6.
6.1 no issues
6.2 accept-rp to only use certain rp's. Also, need to configure sparse-mode on links between domains.
6.3 advertise the remote router loopback into bgp ipv4 multicast.
7.1 I wasn't paying attention to scale. And yet another lab anomaly.
8.1 Almost, missed the discovery transport address. I don't understand why this is required at all. If I get a question like this on the lab I may add it just to be on the safe side, but it seems irrelevant, unless it is somehow locking down the address.
9.1 no issues
10.1 took me a bit of hunting but I finally found it. ip access-list logging
6.1 no issues
6.2 accept-rp to only use certain rp's. Also, need to configure sparse-mode on links between domains.
6.3 advertise the remote router loopback into bgp ipv4 multicast.
7.1 I wasn't paying attention to scale. And yet another lab anomaly.
8.1 Almost, missed the discovery transport address. I don't understand why this is required at all. If I get a question like this on the lab I may add it just to be on the safe side, but it seems irrelevant, unless it is somehow locking down the address.
9.1 no issues
10.1 took me a bit of hunting but I finally found it. ip access-list logging
Duh!
Even though on the last couple of labs I've been able to get the TE tunnels up, I haven't been successful in actually routing traffic across them
During troubleshooting, I'd see the TE tunnel in the forwarding table, and verified mpls packets flowing through the tunnel. But the packets always seemed to get dropped at the endpoint. I thought this could have been something to do with the implicit-null issue, but forcing explicit nulls never helped.
I also noticed the mpls forwarding table showed no label for the TE tunnel. I thought maybe this was just a quirk of TE tunnels.
As it turns out, I need to enable mpls ip on the tunnel interface.
During troubleshooting, I'd see the TE tunnel in the forwarding table, and verified mpls packets flowing through the tunnel. But the packets always seemed to get dropped at the endpoint. I thought this could have been something to do with the implicit-null issue, but forcing explicit nulls never helped.
I also noticed the mpls forwarding table showed no label for the TE tunnel. I thought maybe this was just a quirk of TE tunnels.
As it turns out, I need to enable mpls ip on the tunnel interface.
IE SP Vol 2 Lab 7
I'll have to take a break from lab 6 so I can do my scheduled timed lab 7.
3:00am began
3:08am 1.1 complete
3:11am 1.2 complete
3:18am 1.3 complete, verified using debug ppp authen and shut/no shut int
3:21am 1.4 complete, ppp peer neighbor (default) route allows connectivity
...55 minute break...
4:24am 1.5 complete
Layer 2 complete, 14/14
..50 minute break...
5:05am 2.1 complete
5:07am 2.2 complete
5:32am 2.3 complete, redistribute ip level-2 into level-1 route-map
5:35am 2.4 complete
IGP complete, 10/10
5:47am 3.1 complete
5:58am 3.2 complete
6:02am 3.3 complete
6:07am 3.4 complete
6:15am 3.5 complete, route-maps can set next hops too
6:31am 3.6 complete
BGP complete, 16/16
6:37am 4.1 complete, looks like ldp uses 224.0.0.2
MPLS complete, 3/3
6:46am 5.1 complete
7:04am 5.2 complete, as override
8:24am 5.3 complete, export maps and playing with the next-hop route-maps
9:54am 5.4 skipped. Ugh, I had all sorts of unrealized issues here. I didn't have an isis adjacency on the atm link. For some reason, I needed to change the atm subinterface type to p2m so it matched with r2's interface only config. After this, I had to ensure all broadcasts were permitted on the pvc's so that mpls would come up. And after all that, once the TE tunnels were up, yet again traffic going across them would drop, so I had to shut the tunnel and move on.
10:10am 5.5 complete
Unfortunately a large number of distractions only let me get about 5 hours toward this lab before I ran out of time.
The final tally is:
projected: 55/100
Task notes:
1.5: Ha, I was right to change a3/0.12 to multipoint. I'd give myself extra credit for that if I could!
After reviewing most of the tasks, I caught on to most of the tricks. Even though I didn't get very far into the lab, I'm very excited with my progress!
3:00am began
3:08am 1.1 complete
3:11am 1.2 complete
3:18am 1.3 complete, verified using debug ppp authen and shut/no shut int
3:21am 1.4 complete, ppp peer neighbor (default) route allows connectivity
...55 minute break...
4:24am 1.5 complete
Layer 2 complete, 14/14
..50 minute break...
5:05am 2.1 complete
5:07am 2.2 complete
5:32am 2.3 complete, redistribute ip level-2 into level-1 route-map
5:35am 2.4 complete
IGP complete, 10/10
5:47am 3.1 complete
5:58am 3.2 complete
6:02am 3.3 complete
6:07am 3.4 complete
6:15am 3.5 complete, route-maps can set next hops too
6:31am 3.6 complete
BGP complete, 16/16
6:37am 4.1 complete, looks like ldp uses 224.0.0.2
MPLS complete, 3/3
6:46am 5.1 complete
7:04am 5.2 complete, as override
8:24am 5.3 complete, export maps and playing with the next-hop route-maps
9:54am 5.4 skipped. Ugh, I had all sorts of unrealized issues here. I didn't have an isis adjacency on the atm link. For some reason, I needed to change the atm subinterface type to p2m so it matched with r2's interface only config. After this, I had to ensure all broadcasts were permitted on the pvc's so that mpls would come up. And after all that, once the TE tunnels were up, yet again traffic going across them would drop, so I had to shut the tunnel and move on.
10:10am 5.5 complete
Unfortunately a large number of distractions only let me get about 5 hours toward this lab before I ran out of time.
The final tally is:
projected: 55/100
Task notes:
1.5: Ha, I was right to change a3/0.12 to multipoint. I'd give myself extra credit for that if I could!
After reviewing most of the tasks, I caught on to most of the tricks. Even though I didn't get very far into the lab, I'm very excited with my progress!
Saturday, March 14, 2009
IE SP Vol 2 Lab 6 Continued
VPN
5.1 no issues
5.2 something in Dynamips crashed and I had to reload a couple of routers to get the 5-8 adjacency up.
5.3 no issues. Sham links are covered nicely on the doccd.
5.4 no issues.
5.5 no issues
5.6 no issues. I'm getting MUCH better with TE, this one only took me a few minutes.
5.7 this task was a major pain. I went ahead and made an assumption that only vlan78 was required. The first step was obvious, adjust bgp weights so the correct link was preferred. But it wasn't quite so simple. One of the PE routers refused to advertise the required routes. After way too much time troubleshooting, it turned out that this was due to sham-link costs. Adjusting these ensured the path through R5 was used.
The solutions guide just ignored the sham link altogether saying there was a conflict. It then went ahead and used an export map, which basically took the place of my weight adjustment. 6 one way a half dozen the other...
5.8 no issues
5.9 Yet another task that took a heck of a long time. The pings between ASs failed at first, naturally. It didn't take much time in debugging to determine that send-labels was required on the P-P bgp peers, since they were not running mpls with each other and did not split the vrf's out via subinterfaces. Next, I made sure the route-reflector left the next-hop-unchanged to allow the vpn traffic to flow PE-PE to ensure the vpn tag remained entact.
But no matter what I did, the upstream PE router was still seeing the bgp network as sending no label. I spent multiple hours troubleshooting this. Debug mpls packet is becoming my best friend.
So as it turns out, with a little help from the solutions guide, that the route-map is to blame. If a route map is used, set mpls-label must be configured in the route-map, otherwise this will override the send-label portion of the bgp neighbor config.
But even after I configured this, the CE router still couldn't ping AS54. After another hour or two troubleshooting, the problem seemed to be that the upstream P router was trying to send the traffic back via mpls instead of ip. I have no idea why this was happening, but a mpls encapulation failed message was occurring. Guessing that something may have just gotten hosed on the router in all my previous messing around, I gave up and just reloaded the upstream PE routers. Sure enough, everything came up upon the reload. Annoying, but it's working.
Too much time spent, but I think I got a lot of good troubleshooting experience.
5.10 Yet again more nastiness. The basic task was simple--summarize using an aggrigate address to ensure the longer-match prefix is preferred. An interesting trick. But for some reason, the path to R8 breaks once I set this. Tearing down the TE tunnel fixes it. So yet again i put a ton of time into troubleshooting this. It turns out that for some reason R1 is ignoring the sham-link when TE is operational.
A reboot of R1 seemed to take care of the sham-link issue, but my traffic is still not making it back to R8.
After another hour spent of troubleshooting, I'm giving up on this one. I'm going to write it off as some kind of weird incompatibility with sham-links and TE or something like that. Either that or something is still not clicking with TE that's not mentioned in the solutions guide either.
5.11 wow, no issues
5.12 of course, once again issues. This again deals with the sham link and R7 cannot be made to take the backdoor route to R8 to come into nat on R5 in the appropriate interface.
5.1 no issues
5.2 something in Dynamips crashed and I had to reload a couple of routers to get the 5-8 adjacency up.
5.3 no issues. Sham links are covered nicely on the doccd.
5.4 no issues.
5.5 no issues
5.6 no issues. I'm getting MUCH better with TE, this one only took me a few minutes.
5.7 this task was a major pain. I went ahead and made an assumption that only vlan78 was required. The first step was obvious, adjust bgp weights so the correct link was preferred. But it wasn't quite so simple. One of the PE routers refused to advertise the required routes. After way too much time troubleshooting, it turned out that this was due to sham-link costs. Adjusting these ensured the path through R5 was used.
The solutions guide just ignored the sham link altogether saying there was a conflict. It then went ahead and used an export map, which basically took the place of my weight adjustment. 6 one way a half dozen the other...
5.8 no issues
5.9 Yet another task that took a heck of a long time. The pings between ASs failed at first, naturally. It didn't take much time in debugging to determine that send-labels was required on the P-P bgp peers, since they were not running mpls with each other and did not split the vrf's out via subinterfaces. Next, I made sure the route-reflector left the next-hop-unchanged to allow the vpn traffic to flow PE-PE to ensure the vpn tag remained entact.
But no matter what I did, the upstream PE router was still seeing the bgp network as sending no label. I spent multiple hours troubleshooting this. Debug mpls packet is becoming my best friend.
So as it turns out, with a little help from the solutions guide, that the route-map is to blame. If a route map is used, set mpls-label must be configured in the route-map, otherwise this will override the send-label portion of the bgp neighbor config.
But even after I configured this, the CE router still couldn't ping AS54. After another hour or two troubleshooting, the problem seemed to be that the upstream P router was trying to send the traffic back via mpls instead of ip. I have no idea why this was happening, but a mpls encapulation failed message was occurring. Guessing that something may have just gotten hosed on the router in all my previous messing around, I gave up and just reloaded the upstream PE routers. Sure enough, everything came up upon the reload. Annoying, but it's working.
Too much time spent, but I think I got a lot of good troubleshooting experience.
5.10 Yet again more nastiness. The basic task was simple--summarize using an aggrigate address to ensure the longer-match prefix is preferred. An interesting trick. But for some reason, the path to R8 breaks once I set this. Tearing down the TE tunnel fixes it. So yet again i put a ton of time into troubleshooting this. It turns out that for some reason R1 is ignoring the sham-link when TE is operational.
A reboot of R1 seemed to take care of the sham-link issue, but my traffic is still not making it back to R8.
After another hour spent of troubleshooting, I'm giving up on this one. I'm going to write it off as some kind of weird incompatibility with sham-links and TE or something like that. Either that or something is still not clicking with TE that's not mentioned in the solutions guide either.
5.11 wow, no issues
5.12 of course, once again issues. This again deals with the sham link and R7 cannot be made to take the backdoor route to R8 to come into nat on R5 in the appropriate interface.
Subscribe to:
Posts (Atom)
Posts
