INE Workbook Vol 2 Lab 8

You can use bandwidth to adjust STP costs as opposed to using the 'spanning-tree vlan x' command.

When you are doing PPP authentication over MLPPP, you need to enable the authentication parameters on the virtual-template interface and NOT the multilink group interface.

Always be on the lookout for split-horizon issues!! ALWAYS!

I found a big problem with doing the following:

R5
router eigrp 1024
redistribute rip metric 1 1 1 1 1

If, you need to adjust the metrics on neighboring EIGRP routers (variance, traffic share), your metric values will be too small to manipulate. EIGRP will take the smallest bandwidth in the path (1 as configured with the redistribute command) leaving you will only DELAY to manipulate. Usually this is a good thing, but even setting delay to the highest on one interface, and the lowest on the other interface, you will never get a traffic share of roughly 1:2. So - if you need to traffic share 1:4, you are screwed. Now - is it best to do 1 1 1 1 1 or something more like 1544 1 255 1 1500 for metric values? That I cannot say for sure. If you read through your lab and you see you will need to traffic share/load balance, I would set the metrics to more normal values.

You can fix BGP next-hop reachability by using a route-map and using 'set ip next-hop peer-address'. Just make sure that your peer address is reachable throughout your bgp domain.

By default BGP routers will only compare MED between prefixes learned from the same autonomous system. So if you need to influence the backbone routers for inbound traffic, you COULD use MED provided all your BGP routers are in the same AS, but you could also use AS-path prepending.

I always forget that you can attach a route-map to a network statement. So if you get a task for filtering a bgp originated route, and you cannot use prefix-lists or access-lists, a route-map attached to the network statement will be the way to go.

You can attach a group access-list to the 'ip pim send-rp-annouce' command to set a router to only advertise itself as the auto-rp candidate for a certain subset of multicast groups. This configuration is done at the Auto-RP candidate. You also set the rp-announce-filter on the auto-rp mapping agent.


ip pim send-rp-discovery Loopback0 scope 10
ip pim rp-announce-filter rp-list R1_RP group-list R1_Groups
ip pim rp-announce-filter rp-list R2_RP group-list R2_Groups
ip access-list standard R1_Groups
 permit 224.0.0.0 0.255.255.255
 permit 226.0.0.0 0.255.255.255
 permit 228.0.0.0 0.255.255.255
 permit 230.0.0.0 0.255.255.255
 permit 232.0.0.0 0.255.255.255
 permit 234.0.0.0 0.255.255.255
 permit 236.0.0.0 0.255.255.255
 permit 238.0.0.0 0.255.255.255
ip access-list standard R1_RP
 permit 150.1.1.1
ip access-list standard R2_Groups
 permit 225.0.0.0 0.255.255.255
 permit 227.0.0.0 0.255.255.255
 permit 229.0.0.0 0.255.255.255
 permit 231.0.0.0 0.255.255.255
 permit 233.0.0.0 0.255.255.255
 permit 235.0.0.0 0.255.255.255
 permit 237.0.0.0 0.255.255.255
 permit 239.0.0.0 0.255.255.255
ip access-list standard R2_RP
 permit 150.1.2.2


What I am not sure about is if you are required to do both. I suppose this would depend on your multicast topology but it's probably safer to do both.

I wasn't getting my RP mappings across my frame-relay interfaces. There was two solutions to this problem - one that wasn't solved by INE. R1 (the hub F/R router) had the wrong RPF interface for R2 and R3. A simple mroute fixed this issue. The other issue is PIM NBMA. Multicast traffic coming in from a spoke to another spoke will not work without PIM NBMA mode. Think of this like a split-horizon type issue. The pim nbma-mode takes the multicast traffic and treats each PIM neighbor like a point-to-point interface. Why listen to me drabble on about it - get it right from the horse's mouth..... Using IP Multicast over Frame-Relay Networks

Multicast helper is used to transfer broadcast traffic between two end points across a multicast network. There are several caveats such as using 'ip forward-protocol' to process-switch the traffic instead of fast-switching. You also need to apply the multicast helper map on the INCOMING interface of the last hop router (facing the multicast network) and not on the OUTGOING interface of the last hop router (facing the client). DocCD is your friend. If you see this in the lab, you should know exactly where to go....http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6441_TSD_Products_Configuration_Guide_Chapter.html

INE presents an interesting way to prevent transit traffic between two end nodes. R5 interface Fa0/1 has two subinterfaces - one to BB2 and one to BB3. By matching the input interface and dropping that traffic, R5 can no longer be used as a transit between the two nodes.


class-map match-all FROM_BB3
 match input-interface FastEthernet0/1
class-map match-all FROM_BB2
 match input-interface FastEthernet0/1
policy-map TO_BB2
 class FROM_BB3
   drop
policy-map TO_BB3
 class FROM_BB2
   drop
interface FastEthernet0/1.52
 ip address 192.10.1.5 255.255.255.0
 service-policy output TO_BB2
interface FastEthernet0/1.53
 ip address 204.12.1.5 255.255.255.0
 service-policy output TO_BB3


A little out there, but still feasible.

In order to tune a shapers queue, you need to apply a nested service-policy.


policy-map CBWFQ
 class class-default
  bandwidth percent 100
  queue-limit 10
policy-map FRTS
 class class-default
  shape average 128000
  service-policy CBWFQ



And with that, lab 8 is done. Again, not difficult at all and at points can be very tricky. I am getting much better at paying very close attention and doing exactly what is asked in the scenario. Going forward, I need to work on getting much faster as well. Tomorrow I plan to hit Narbik's troubleshooting scenario and then next Monday and Tuesday I've rented some rack time from INE and I plan to complete a few of their troubleshooting labs.