Giáo trình Advanced Certificate in Information Technology - Sanlein part 88 potx

alternatives from two T1s between a single router at your site and a single router at the ISP, to two T1's between separate routers at your site to two different ISPs. For how to get the most out of BGP, including load sharing and efficiency considerations (my book only considers availability), read Halabi's book. If none of the above makes sense to you, hire a competent consultant to walk you through the alternatives and their tradeoffs. ***** The O'Reilly article follows: ***** by Vincent Jones 05/11/2001 Many organizations depend upon Internet connectivity to support critical applications. One popular approach for improving Internet connectivity is to connect to more than one Internet service provider (ISP), a technique called multi- homing. Multi-homing can be very effective for ensuring continuous connectivity eliminating the ISP as a single point of failure and it can be cost effective as well. However, your multi-homing strategy must be carefully planned to ensure that you actually improve connectivity for your company, not degrade it. THE CONCEPT OF PHYSICAL DIVERSITY First, I want to discuss the network components that can affect overall connectivity. Because most network failures are due to problems in the WAN links, it does little good to connect to a second ISP if both ISP links are carried over the same communications circuit. Even if independent circuits are used if they are not physically diverse they will still be subject to common failure events such as construction work inside your building or digging in the street outside. Providing complete physical diversity can be difficult and expensive, but the requirement is not limited to ISP connections. All critical network links for internal communications should also be diversified. Assuming an otherwise well- designed internal network, the easiest way to achieve physical diversity in your ISP connections is to connect from two different locations that are already well- connected to each other. But they must be far enough apart that they don't share any common communications facilities to either ISP. REDIRECTING TRAFFIC USING THE BORDER GATEWAY PROTOCOL Once physical connectivity is in place, you need to make it useful. Taking advantage of redundant links requires two conditions to always be present. First, you must be able to detect when a link has failed. Second, you must have a mechanism for redirecting traffic that would normally flow across a failed link to take a different path that is still functional. In a multi-homing environment, both tasks are normally achieved by running Border Gateway Protocol (BGP) between your routers and those of the ISPs. BGP is often assumed to mean complex configurations on expensive, high-end routers to handle the huge routing tables required to fully describe the Internet. However, depending upon the specific application requirements and the degree of load-balancing you want across all available links, it may be practical to implement multi-homing using the smallest routers you have available that are capable of handling the traffic load. In other words, implementing multi-homing doesn't have to be an all-or-nothing choice. There are choices you can make along the way based upon the equipment you have available and the level of connectivity you need to provide. DETERMINING LEVEL OF CONNECTIVITY REQUIRED At one extreme, when your goal is to simply to provide internal users with access to the Internet, you don't need to run BGP at all. As long as the link layer protocol supports the exchange of keep-alive messages from router to router, link failure will be detected by the link layer protocol. Floating static routes can then reliably direct all outbound traffic to a working ISP link. Network Address Translation (NAT) is then used to send outbound packets with a source IP address associated by the ISP with that outbound link. Return traffic will automatically come back via the same working link because that link is the only link servicing that address range. Of course this approach will not work if you are providing services to the outside world, as the addresses associated with the failed link will disappear. Similarly, connections that were established over the link that failed will need to be reconnected. However, for many applications this impact is minor. For example, a typical web surfer would merely need to hit the "page refresh" button. This approach is also sufficient to provide high-availability virtual private networks (VPN) across the Internet if you use a routing protocol such as OSPF to detect and route around failed IPSec tunnels. The other extreme would be when you need to support a common IP address range using both ISPs. Then you need to run BGP. This will normally be the case any time your applications include providing services to Internet users, such as access to a common database. You will need to arrange for both ISPs to accept your BGP advertisements of your IP address prefixes. Then your ISPs need to advertise those address prefixes to the rest of the Internet. Getting your address prefixes advertised is usually not a problem. You do, however, have to use care in your configuration to ensure that you do not inadvertently advertise any other address prefixes. In particular, you must ensure that you do not advertise yourself as a path between the two ISPs. This could cause your links to be consumed by transit traffic of no interest to you. More challenging is setting up your advertisements so that incoming traffic is reasonably balanced between the ISP links. Achieving that can be difficult at best, and nearly impossible at worse. CHOOSE THE RIGHT ROUTE FOR YOU The final decision is determining which routes to accept from each ISP. This can range from merely accepting a default route (used to detect if the link is up or down) to accepting all routes (so called "running defaultless"). The former is usually insufficient, because it does not protect you from an ISP which has an internal failure cutting them off from the rest of the Internet. The latter requires using "carrier-class" routers with lots of memory installed (and therefore more expensive). Fortunately, there are some "in-between" choices. Rather than using a simple default route, you can use a conditional default route to protect against ISP failure behind the ISP's router that serves you. A conditional default route is a default route that is defined by a router only if a specific address is already in that router's routing table. Each ISP is only used for a default route if it is advertising one or more routes that indicate it is receiving advertisements from the rest of the Internet. That way, you will always use a default route which promises to be useful. Another option is to have the ISP send you just its local routes. That way, you can optimize your outbound routing to avoid sending packets that could be locally delivered to the wrong ISP, adding to delivery delays. Care must be taken when using this option, however, because some ISPs have so many local routes that there is no cost benefit in the size of the routers required to handle them compared to running defaultless. Options can also be combined. In many cases, taking local routes and a conditional default route will provide all the availability benefits of running defaultless, while still allowing the use of low-cost routers. As is always the case in networking, a good understanding of the requirements and the available capabilities is essential to maximizing cost-effectiveness. ****************************************************************** ******** From: Question 44 Subject: What kind of memory can I use to upgrade my 2500 series router? The RAM is standard 72-pin parity 70ns FPM w/ tin leads, while the flash is the generic Cisco flash. If you have older boot ROMs, you'll want to make sure you get Intel chips or the ROMs won't recognize them. Or you could upgrade the ROMs - Cisco part number BOOT-2500=, allegedly free. > Any suggestions for a decent memory supplier for this? I used to use Kingston when I had 25xx's. But MemoryX seems to be less expensive these days: (http://www.memoryx.net/routers.html) ****************************************************************** ******** From: Question 45 Subject: Where can I get mzmaker to compress my IOS? http://www.mcseco-op.com/mzmaker.htm ****************************************************************** ******** From: Question 46 Subject: What is the meaning of in/out in reference to an access-list? >Can anyone point me to a good description of the difference between "in" >and "out" in applying an access list to an interface? Even the good >books seem to only devote a sentence to the difference between them. The simplest explanition I've seen is: Crawl into your router and look towards the interface. If the packets are going away from you they're outbound. If they're hitting you in the forehead their inbound. ****************************************************************** ******** From: Question 47 Subject: How do I remove the /32 - host - route when a PPP link comes up? To get rid of this host route, try the following command on both ends of the link: no peer neighbor-route ****************************************************************** ******** From: Question 48 Subject: How do I forward DHCP broadcasts to my DHCP server? > We are a Canadian company with an American office. We have a Cisco router > at each office connected via a T1 line. We have a DHCP server at our > Canadian office, and we would like it to also delgate IPs to our american > office. Is this possible? If so, what must be done? You have some choices. 1) Run DHCP on the remote router. This will prevent the dhcp requests from coming across the WAN. The downside is that only certain IOSes support running dhcp and is a bit more work for the router. 2) You can enable bootp forwarding or dhcp relaying. This can be accomplished by using "ip helper-address DHCP_SERVER_IP_HERE" interface command. But using helper-address turns on a lot of unnecessary UDP forwarding so you need to lock it down first. So: conf t no ip forward-protocol udp tftp no ip forward-protocol udp dns no ip forward-protocol udp time no ip forward-protocol udp netbios-ns no ip forward-protocol udp netbios-dgm no ip forward-protocol udp tacacs ip forward-protocol udp bootpc interface ethernet0/0 ip helper-address YOUR_REMOTE_DHCP_SERVER_IP_HERE ****************************************************************** ******** From: Question 49 Subject: How do I send L2 traffic through a tunnel? > Thanks for answering my post, the current problem I have is I need to send > Layer2 type traffic through a tunnel is this possible ? Sure. See http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/inter_c /icdlogin.htm#xtocid292793 > I enabled bridging on both routers and created a bridge group and that > seems to work fine I can see my netbeui traffic passing > The problem is I have to be able to encapsulate netbeui or any other Layer2 > type protocol and encapsulate within a IP packet. The usual way to do this is using a GRE tunnel between two routers, and configuring an additional loopback interface on each router as the source interface for the tunnel traffic, as below. Here, each router has a bridge group defined which allows certain traffic only as stated in the 200-series ACL onto the loopback interface. In this case it's LAT only - you will need to check the LSAP protocol number(s) for netbios/netbeui as I can't remember these off-hand. Once the traffic is forwarded from the LAN interface onto the loopback, it is encapsulated into IP GRE and forwarded to the far router. / \ Tunnel0| |Tunnel0 | | LAN Router A WAN Cloud Router B LAN Eth0 Ser0 Ser0 Eth0 Router A int e0 ip address 192.168.100.254 255.255.255.0 bridge-group 1 int loop0 . than one Internet service provider (ISP), a technique called multi- homing. Multi-homing can be very effective for ensuring continuous connectivity eliminating the ISP as a single point of failure. available links, it may be practical to implement multi-homing using the smallest routers you have available that are capable of handling the traffic load. In other words, implementing multi-homing. forward-protocol udp tftp no ip forward-protocol udp dns no ip forward-protocol udp time no ip forward-protocol udp netbios-ns no ip forward-protocol udp netbios-dgm no ip forward-protocol