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.
Monday, March 16, 2009
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.
IE SP Vol 2 Lab 6 Continued
MPLS
4.1 no issues
4.2 no issues
Some good information is contained in the solutions guide for verifying the ldp session is encrypted. I'll all for verifying everything, and fully believe it was the reason I was able to pass R&S the second time.
First, find your ldp/tdp session:
Rack1R4#sh tcp brie
TCB Local Address Foreign Address (state)
651EA2F4 20.1.4.4.29641 20.1.6.6.179 ESTAB
6520C0C4 20.1.4.4.646 20.1.6.6.28294 ESTAB
65185A8C 20.1.14.4.15156 20.1.14.1.179 ESTAB
651EDBFC 20.1.4.4.179 20.1.3.3.53879 ESTAB
Then check out the appropriate tcb (port 711 or 646). Note the flags section.
Rack1R4#sh tcp tcb 6520c0c4
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 20.1.4.4, Local port: 646
Foreign host: 20.1.6.6, Foreign port: 28294
...
Flags: passive open, retransmission timeout, gen tcbs, md5,
...
4.1 no issues
4.2 no issues
Some good information is contained in the solutions guide for verifying the ldp session is encrypted. I'll all for verifying everything, and fully believe it was the reason I was able to pass R&S the second time.
First, find your ldp/tdp session:
Rack1R4#sh tcp brie
TCB Local Address Foreign Address (state)
651EA2F4 20.1.4.4.29641 20.1.6.6.179 ESTAB
6520C0C4 20.1.4.4.646 20.1.6.6.28294 ESTAB
65185A8C 20.1.14.4.15156 20.1.14.1.179 ESTAB
651EDBFC 20.1.4.4.179 20.1.3.3.53879 ESTAB
Then check out the appropriate tcb (port 711 or 646). Note the flags section.
Rack1R4#sh tcp tcb 6520c0c4
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 20.1.4.4, Local port: 646
Foreign host: 20.1.6.6, Foreign port: 28294
...
Flags: passive open, retransmission timeout, gen tcbs, md5,
...
Friday, March 13, 2009
IE SP Vol 2 Lab 6 (Untimed)
I'm gonna see if I can squeeze this lab in on an unscheduled day so I can make it through all of them before the big day. 16 days to go...
Layer 2
1.1 No issues
1.2 No issues
1.3 No issues
1.4 No issues
Layer 2 complete, 12/12.
IGP
2.1 No issues
2.2 No issues
2.3 No issues
IGP complete, 9/9
EGP
3.1 No issues
3.2 No issues
3.3 No issues
3.4 No issues
3.5 I ALMOST had this. Of course almost equals nothing in the lab. I figured out what needed to be redistributed to get the ebgp adjacency up. I also figured out some admin distance changes needed to be made in as 100. But what I didn't get right is getting traffic from R3 to R6 flowing across the R1-R4 link. I knew it needed to be done, I just couldn't figure out how, within the scope of current BGP adjacencies. I ended up looking this one up. The trick was to advertise BOTH loopbacks on each AS100 router. Then I could easily adjust the metric on the AS 200 ABRs during redistribution.
EGP complete, 12/15
Layer 2
1.1 No issues
1.2 No issues
1.3 No issues
1.4 No issues
Layer 2 complete, 12/12.
IGP
2.1 No issues
2.2 No issues
2.3 No issues
IGP complete, 9/9
EGP
3.1 No issues
3.2 No issues
3.3 No issues
3.4 No issues
3.5 I ALMOST had this. Of course almost equals nothing in the lab. I figured out what needed to be redistributed to get the ebgp adjacency up. I also figured out some admin distance changes needed to be made in as 100. But what I didn't get right is getting traffic from R3 to R6 flowing across the R1-R4 link. I knew it needed to be done, I just couldn't figure out how, within the scope of current BGP adjacencies. I ended up looking this one up. The trick was to advertise BOTH loopbacks on each AS100 router. Then I could easily adjust the metric on the AS 200 ABRs during redistribution.
EGP complete, 12/15
Subscribe to:
Posts (Atom)
Posts
