This lab has been a bit of fun, with a lot of odd little challenges thrown in there to keep it interesting. I am having problems with my rack not always functioning properly with the solutions provided though, a bit of a bummer. All good stuff, nonetheless.
- The frame cloud was to be 3 routers (R1-R5-R2) in a hub-n-spoke topology, all with multipoint subinterfaces. Inverse-ARP was not allowed. More than one map statement was also forbidden. The solution was to use PPPoFR for the links. Okay, fair enough. Later on, the lab instructs you to run OSPF area 125 on the PPPoFR links. That part didn’t work for me. I configured the virtual-template interfaces as OSPF network type point-to-multipoint. The adjacencies formed correctly. The routing table loaded. All routes pointed out the expected interfaces. Even the CEF table looked correct. But try though I might, R5 kept sending all traffic to R2, no matter what, causing my traffic to exceed TTL. No idea why. Reload didn’t help. If I tore down the PPPoFR link to R2, R5 would forward to R1 fine. The set up is simple (not a lot of code), and my tables and the answer key’s tables matched 100%. I ended up tearing down the PPPoFR links, and rebuilding the FR cloud as simple point-to-multipoint with map statements. I brought OSPF back up, and R5 forwarded normally. I’m blaming the router and/or IOS (12.4.16 Advanced Enterprise) in this case. Might be a known issue, but I didn’t take the time to hit BugTool.
- The PPP link was to be brought up via Dialer interfaces. That’s not something I’ve practiced at all, and I didn’t know the code. So I did a straight copy off of the answer key, but the link still didn’t come up. Again, I’m not sure why. R5 was involved in the issue again – so maybe R5 needs a session in the woodshed. ;) Bringing the link up as traditional PPP was no problem.
- The RIP task was to advertise a default route from R4 to SW2, but R4 was not to send the default to R5. Use of a distribute list was forbidden. I reflexively put an “ip summary rip 0.0.0.0 0.0.0.0” onto the R4 interface facing SW2. Nope. That ended up suppressing all RIP advertisements to SW2, but not sending a default route. Okay, I reviewed the command, and it only summarizes on classful boundaries. Fair enough. I decided I could write an offset-list so that I could send all the routes to R5, but poison the default with a metric of 16. Technically, the 0.0.0.0 route would still be sent to R5, but R5 would not do anything with it. That answer just didn’t feel right, but I was out of ideas. IE’s solution was to apply a route-map to the “default-information originate” command that did a “set interface fa0/1”. That was a heck of a plan, and something that hadn’t popped into my head. I tried it…didn’t work. When I created the route-map, I got the following error:
Rack1R4(config-route-map)#set interface fa0/1
% route-map:can not set interface.
% Use P2P interfaces for set interface clause
Okay, okay – I’m strong. I can handle this. Since the interface facing R5 was a serial P2P link, I re-wrote the route-map like this:
Rack1R4(config-route-map)#no route-map DEFAULT-TO-SW2
Rack1R4(config)#route-map DEFAULT-TO-SW2 deny 10
Rack1R4(config-route-map)#set interface s0/1/0
Rack1R4(config-route-map)#route-map DEFAULT-TO-SW2 permit 999
He lines up the shot…a smooth release, lovely arc…but the crowd is crushed as they witness a hard clang off the back of the rim. Surprisingly, that ended up still sending the default route across the serial link to R5, but NOT across the ethernet to SW2. Go figure.
I couldn’t make the IE solution work. I went back to my offset list idea, which worked okay, except that technically the task said R4 wasn’t supposed to send the 0.0.0.0 route, which it does if you look at the debug, just with a 16 metric.
Rack1R4(config)#access-l 99 deny 188.8.131.52 0.0.0.255
Rack1R4(config)#access-l 99 deny 184.108.40.206 0.0.0.255
Rack1R4(config)#access-l 99 permit 0.0.0.0 0.0.0.0
Rack1R4(config-router)#offset-list 99 out 16 serial 0/1/0
Rack1R4#debug ip rip
RIP protocol debugging is on
*Apr 11 21:03:12.253: RIP: sending v2 update to 220.127.116.11 via Serial0/1/0 (18.104.22.168)
*Apr 11 21:03:12.253: RIP: build update entries
*Apr 11 21:03:12.253: 0.0.0.0/0 via 0.0.0.0, metric 16, tag 0
*Apr 11 21:03:12.253: 22.214.171.124/24 via 0.0.0.0, metric 1, tag 0
*Apr 11 21:03:12.253: 126.96.36.199/24 via 0.0.0.0, metric 1, tag 0
*Apr 11 21:03:12.253: 188.8.131.52/24 via 0.0.0.0, metric 1, tag 0
- I ran into a task to redistribute a specific iBGP route into EIGRP. I haven’t done much redistribution to or from BGP, but no big deal, right? So, I dutifully built my route-map, and redistributed…and…nothing. The route was not showing up in the EIGRP topology. Huh. Turns out that the router won’t let you redistribute an iBGP-learned route into an IGP by default, because typically that’s a stupid thing to do. So to allow this behavior, you have to tell BGP “bgp redistribute-internal“. Soon as I did that, followed by a “clear ip bgp *“, my redistributed route showed up when doing a “show ip eigrp topology“.