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: (
******************************************************************
********
From: Question 45

Subject: Where can I get mzmaker to compress my IOS?

******************************************************************
********
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

/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