INE Workbook Vol 2 Lab 1

When redistributing between protocols, be careful about connected interfaces. If you have redistributed a connected interface using a route-map, and you redistribute between two protocols - anything not specified in that route-map will not be redistributed. Those interfaces will be treated as connected interfaces. Here is a redistribution example.


router eigrp 10
 redistribute ospf 1 metric 1 1 1 1 1
 network 54.1.1.6 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.6.6
!
router ospf 1
 router-id 150.1.6.6
 log-adjacency-changes
 redistribute connected subnets route-map Redist
 redistribute eigrp 10 subnets tag 10
 network 150.1.6.6 0.0.0.0 area 46
 network 183.1.46.6 0.0.0.0 area 46
router bgp 100
!

route-map Redist permit 10
 match interface FastEthernet0/1

We are redistributing the connected interface f0/1 into OSPF. Now when eigrp is redistributed into OSPF, the eigrp connected interface (54.1.1.6) will not be present in OSPF and those route unreachable. Simple fix is to also redistribute the EIGRP connected interface.


route-map Redist permit 20
 match interface Serial0/0

In the lab, if you need to redistribute between protocols and connected interface, you should immediately investigate this!

Sometimes, you may to use the neighbor x next-hop-self command to work around recursive lookup issues. For instance, from AS 100 we want to prefer the route to 150.1.11.0/24 in AS200 through the connection between R5 and SW4. So off we go and we set the metric out from AS200 to AS100. Poof! The route to R5 is preferred from within R1.


Rack1R3#sh ip bgp
BGP table version is 33, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


   Network          Next Hop            Metric LocPrf Weight Path
.....
*>i150.1.11.0/24    183.1.105.10           100    100      0 200 i
*                   183.1.123.1            200             0 200 i

Using a metric value of 100 over 200, we prefer 150.1.11.0/24 going through SW4 via 183.1.105.10. Let's see where that takes us.


Rack1R3#sh ip route 183.1.105.10
Routing entry for 183.1.105.0/24
  Known via "eigrp 100", distance 90, metric 2689536, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets route-map EIGRP->OSPF
  Last update from 183.1.123.2 on Serial1/0, 03:12:41 ago
  Routing Descriptor Blocks:
  * 183.1.123.2, from 183.1.123.2, 03:12:41 ago, via Serial1/0
      Route metric is 2689536, traffic share count is 1
      Total delay is 40300 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 4

Ugh, no - that's not what we wanted. The route to 150.1.11.0/24 will go out via the Serial1/0 connection based on the next-hop value. So how to get around this? If on AS100 router R5, we set the 'neighbor next-hop-self' command for R3, the next-hop will be the connected interface.


Rack1R3#sh ip bgp
BGP table version is 34, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


   Network          Next Hop            Metric LocPrf Weight Path
......
*>i150.1.11.0/24    183.1.0.5              100    100      0 200 i
*                   183.1.123.1            200             0 200 i
Rack1R3#sh ip route 183.1.0.5
Routing entry for 183.1.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1000 0 255 1 1500 route-map EIGRP-Connected
  Routing Descriptor Blocks:
  * directly connected, via Serial1/1
      Route metric is 0, traffic share count is 1


I need to learn to not make stupid mistakes. In a MPLS VPN environment, I tried to ping across the MPLS VPN but I didn't see the source interface on my ping command. Forgetting something like that could send me on a 'troubleshooting' spree for something that isn't really a problem...sigh...


I've said it before, I'll say it again -  'no ip mroute-cache' and 'debug ip mpacket' can be a lifesaver when troubleshooting multicast.....


INE presents things like you may see in the lab. I got a requirement to rate-limit ICMP packets. My only restriction was to not use 'match protocol'. So I configured the legacy rate-limit command with an access-list. That should be an acceptable solution. Their solution was the CBWFQ policing method (which I prefer) using an access-list to match ICMP packets. In my eyes, both are viable solutions. 


With CBWFQ, you can't use percent and bandwidth commands, but you can use percent with priority commands. Unfortunately INE left out the fact that the voice traffic should be prioritized. They simply said 'allocate 64kbps to VOIP bearer traffic'. Standard practices says to use priority here, but the lab is certainly NOT based on best practices. 


And with that, I've completed Lab 1 with a difficulty level of 8. I really didn't think that it was too hard. There was just way too many scenarios where they weren't real specific about what you should do, or left out important details. I guess this is where you would ask the proctor in the real lab and hope that they are more helpful than the last proctor I had. I just made a few simple mistakes that I need to keep track of because they can KILL YOU in the real lab. I need lots more practice doing redistribution, and these full labs should help me. I could also use some more help with EEM - mostly I need to know what all the variables are for an action....


I was almost regretting doing full labs  because I thought I would get murdered, but really it was not that bad. I think I am going to fire up troubleshooting and work on that tomorrow and Saturday. I'll be leaving town Sunday for a week, but hopefully I'll be able to get a few full labs completed while I am out of town working....