Sunday, March 1, 2009
IE Vol2 Lab 2 Complete
Well, I'm on schedule, barely, and ready to do lab 3 next week. There really wasn't anything too substantially scary in this lab. The VPN config was pretty basic and there wasn't any TE. PPPoE was new, but I felt pretty comfortable with it and know how to get to the docs. I'm also getting more comfortable with MPLS QoS. So, aside from a few knobs I think I did ok.
IE Vol 2 Section 10 Complete
10.1 Gotta love those knobs. mpls ldp tcp pak-priority. Now I never would have found this one. Guess I gotta get better at looking over the command-line options.
10.2 Pretty basic netflow setup. I'm not sure if netflow was covered in R&S, but I've worked with it enough where it wasn't an issue.
10.2 Pretty basic netflow setup. I'm not sure if netflow was covered in R&S, but I've worked with it enough where it wasn't an issue.
IE Vol 2 Section 9 Complete
9.1 Complete, no issues--just like R&S
9.2 Complete, no issues--just like R&S
9.3 Complete, no issues--just like R&S
9.2 Complete, no issues--just like R&S
9.3 Complete, no issues--just like R&S
IE Vol 2 Section 8
8.1 Complete. No issues, standard R&S stuff here. The nice part about logging denies, is I find out quickly that ospf has to be permitted in the access list.
8.2 Complete. Maximum routes in the vrf controls the size of the routing table.
8.2 Complete. Maximum routes in the vrf controls the size of the routing table.
IE Vol 2 Section 7
7.1 Complete. No issues, straight R&S stuff.
7.2 Complete. I need to remember not to use the nbar ftp, but to use an access-list of ftp, ftp-data, and gt 1023 to match ftp traffic.
7.3 Complete. I disagree with the solutions guide here. The requirements specify traffic should not be dropped "unless there is congestion in the transit path". To me this means setting DE, but the answers say to use queueing. In the lab a question to the proctor would be in order.
7.4 Complete, Qos-groups again. The key to keep in mind is that when traffic comes in an mpls interface, the only thing to match on is the mpls exp bits. Then on its way out of the router, if the tag is stripped, the exp bits are gone. So it's only possible to match on the packet itself. The other alternative is to use the Qos-group, with which the router associates an incoming packet internally, to remember to apply policies on egress.
7.2 Complete. I need to remember not to use the nbar ftp, but to use an access-list of ftp, ftp-data, and gt 1023 to match ftp traffic.
7.3 Complete. I disagree with the solutions guide here. The requirements specify traffic should not be dropped "unless there is congestion in the transit path". To me this means setting DE, but the answers say to use queueing. In the lab a question to the proctor would be in order.
7.4 Complete, Qos-groups again. The key to keep in mind is that when traffic comes in an mpls interface, the only thing to match on is the mpls exp bits. Then on its way out of the router, if the tag is stripped, the exp bits are gone. So it's only possible to match on the packet itself. The other alternative is to use the Qos-group, with which the router associates an incoming packet internally, to remember to apply policies on egress.
Saturday, February 28, 2009
IE Vol 2 Section 6
6.1 Complete. No issues, just a tunnel.
6.2 Complete, just need to make sure the tunnel passes the rpf check.
6.3 Complete, ip multicast-boundary does the trick.
6.2 Complete, just need to make sure the tunnel passes the rpf check.
6.3 Complete, ip multicast-boundary does the trick.
Thursday, February 26, 2009
IE Vol 2 Section 5
5.1 Complete, no issues although it did take me a bit to figure out exactly what they were asking for. I'd definitely get some proctor clarification on this in the lab.
5.2 Complete, although the solutions guide also had an "assumed tasks" that weren't specifically mentioned in the task itself.
Getting the pe-ce ospf and ospf-bgp redistribution running wasn't an issue at all. However my AS100 pe and ce could not reach site 2. It turned out this was because vpnv4 next-hop-self wasn't turned on for the as100 P router. Because of this, the PE saw the AS200 link as the next hop, rather than the P router's loopback. The AS200 link was not in the mpls forwarding table, so the PE router sent this packet out without a label. The P router would then receive an mpls vpn labeled packet with no forwarding label, and have to drop the packet. Adding the vpnv4 next-hop-self instead showed the P router loopback as the next hop, which the PE router did have in its mpls forwarding table, therefore the mpls path was intact.
The solutions guide also had R4 advertise ospf external routes. I see why this was done, since it's necessary so that site 1 can reach site 2's external ospf networks. But the task does not call for this. It should have stated that this reachability is required.
5.3 I ALMOST had this completed. The nat took me awhile but I finally got it running. I was hung up on the static route for leaking routes into the vrf. The issue I couldn't fix was in having R4 use redundant paths for the static route to R3. I was missing the global keyword on the static route. This allows a recursive lookup to the global routing table for the vrf static route. Once that was added, I had to put another next-hop-self on R5->R4 to allow reacability to external prefixes.
5.4 Ok, I was completely lost on this one. I knew I needed to filter routes going to the CE without adding vfr's to the CE routers. I just wasn't sure of the mechanism to do this. So now I know a new trick, which I'm sure will be invaluable on the real lab. ip vrf export maps, which use route-maps to selectively assign route-targets to specific routes. I definitely need to write that to my own memory.
5.2 Complete, although the solutions guide also had an "assumed tasks" that weren't specifically mentioned in the task itself.
Getting the pe-ce ospf and ospf-bgp redistribution running wasn't an issue at all. However my AS100 pe and ce could not reach site 2. It turned out this was because vpnv4 next-hop-self wasn't turned on for the as100 P router. Because of this, the PE saw the AS200 link as the next hop, rather than the P router's loopback. The AS200 link was not in the mpls forwarding table, so the PE router sent this packet out without a label. The P router would then receive an mpls vpn labeled packet with no forwarding label, and have to drop the packet. Adding the vpnv4 next-hop-self instead showed the P router loopback as the next hop, which the PE router did have in its mpls forwarding table, therefore the mpls path was intact.
The solutions guide also had R4 advertise ospf external routes. I see why this was done, since it's necessary so that site 1 can reach site 2's external ospf networks. But the task does not call for this. It should have stated that this reachability is required.
5.3 I ALMOST had this completed. The nat took me awhile but I finally got it running. I was hung up on the static route for leaking routes into the vrf. The issue I couldn't fix was in having R4 use redundant paths for the static route to R3. I was missing the global keyword on the static route. This allows a recursive lookup to the global routing table for the vrf static route. Once that was added, I had to put another next-hop-self on R5->R4 to allow reacability to external prefixes.
5.4 Ok, I was completely lost on this one. I knew I needed to filter routes going to the CE without adding vfr's to the CE routers. I just wasn't sure of the mechanism to do this. So now I know a new trick, which I'm sure will be invaluable on the real lab. ip vrf export maps, which use route-maps to selectively assign route-targets to specific routes. I definitely need to write that to my own memory.
Subscribe to:
Posts (Atom)
Posts
