Designing Cisco Network Service Architectures - Free Books

Case Study 2 Answer Key: CP Hotels Addressing and RoutingDesignStep 1 AddressingBased on the scenario, this section includes a proposed solution. According to the case studyguidelines, there may be some minor variations in your solutions.• The Call Center blocks go up by 12. Going up by 8 would summarize better and stillprovide enough address space.• It would be good to have a plan for address consolidation in the Data Centers, to get serversonto one prefix per Data Center, say over a 5-7 year period as servers are replaced.Step 2 Routing and Summarization• The hotel areas should be made totally stubby. (This was not specified, and should bebrought up with the customer, recommended if not part of the present design.)• The HQ areas should also be totally stubby.• EIGRP would make the design simpler in the following ways:— EIGRP can filter all but corporate prefix summaries or default routes from the routessent to the hotels, greatly reducing the routing traffic to hotels. OSPF has to flood allLSAs to all hotels, plus all prefixes imported from BGP. This is exacerbated by FRinstability.— OSPF does not allow intra-area filtering, so all hotels within an areas see routes toeach other, yet there is no reason for one hotel to have a route to any other hotel.— In conjunction with filtering and corporate summaries, the EIGRP stub featurewould be useful for hotels.— The VLAN links between Data Centers would not be needed for area contiguity andavoiding having OSPF transit traffic going through hotel sites to stay within an area.They still would be needed due to the route summarization, however. (Why?)• EIGRP could be useful in the Server Farm Module, for more flexibility, although OSPFshould work reasonably well there, given the regularity of the topology. OSPF has thevirtue that it can be used with Cisco FWSM or PIX, CSS/CSM Route Health Injection, etc.,whereas EIGRP cannot.• The OSPF aggregation routers could be done away with, but the price would be a muchlarger (and single) area 0, more routes being sent to hotels, and a lot of peers for the corefacingEBGP routers. The present design compartmentalizes the large-scale hotel routingwell.• NAT for partners would avoid the injection of random prefixes into core BGP, also wouldallow partners to use private addresses without concern about overlapping server addressesat CP Hotels that they need to communicate with.• BGP route reflector won’t help with EBGP. It might be used for the IBGP in the HotelsModule, although the same peering would be needed (each aggregation router peered toboth core-facing routers). Not using Route Reflector has the advantage that one hotelaggregation block (Region) doesn’t need to see routes to the others anyway.• The links to twin routers are needed to prevent black-holing packets if a hotel link fails.Otherwise, the summary prefix advertisement may draw in packets to the router with the© 2007 Cisco Systems, Inc. Lab Guide 45