Several key design issues should be considered when connecting to the Internet. These issues impact the reliability, performance and cost of Internet connectivity. I will examine several design alternatives in the following sections, then look at a case study.
There are three alternatives regarding physical connectivity between the client and the ISP(s):
- Singly-homed
A single circuit may be adequate for a small organization generating a trickle of traffic. The client organization must choose an ISP and decide on the speed of the access circuit. However, if that single circuit breaks, the entire organization will be without Internet service. Hence, if the organization’s access to the Internet is critical, multi-homing is warranted (even when the traffic volume is small).
- Multi-homed to the same ISP
An organization may decide to implement multiple circuits between itself and its ISP for reliability. An organization that decides to multi-home has a more complex task at hand. Should the links be of the same speed? What should the link speeds be? How should inbound traffic be distributed over the links? How should outbound traffic be distributed over the links?
- Multi-homed to different ISPs
A multi-homed organization may consider using more than one ISP for additional reliability. This will guard against failures in a single ISP network.
There are several options regarding the routing of traffic between the client organization and the Internet. Note that these options apply only to multi-homed clients; singly-homed clients have only one path for inbound and outbound traffic.
In the following discussion, I will distinguish between inbound and outbound traffic. The traffic flow from the client’s network to the Internet is referred to as outbound. The reverse flow from the Internet to the client’s network is referred to as inbound. Inbound and outbound flows need not be symmetrical.
There are several options regarding outbound traffic:
- Default route
The simplest method of defining routes to external destinations is by configuring a default route (
0.0.0.0). The default route will match any destination for which a more specific route is not known via the client’s IGP. The configuration for the singly-homed client using a default route is identical to TraderMary’s configuration in Section 7.2. The single default route works well in a singly-homed scenario.- Partial routing table along with default routes
When a client is multi-homed -- say, to two different ISPs -- the two outbound paths are not equal. Some networks in the Internet will be closer via one path while others will be closer via the second path. A single default route cannot address this asymmetry. The client has two options here. The first option is for the client routers to import a partial set of routes from each ISP and use a default route for the remaining routes. The second option is to import the full routing table.
- Full routing table
The full routing table may be useful in multi-homed environments to allow the most informed decision to be made. However, at the time that this book is being written, there are around 75,000 prefixes in the Internet. This places high demands on router memory and CPU resources. You should have a very good reason to import the full routing table.
Inbound routing decisions are made in the routing tables in other, external ASs. The client may set one or more BGP attributes in an attempt to influence the flow of inbound traffic. However, ISPs have their own routing policies and may disregard or override these attributes. Hence, the inbound routing policies should be implemented in conjunction with the ISP. The methods described here use the AS-PATH attribute.
- Identical AS-PATH length
The option here is for the client organization to advertise all its routes on all paths with identical AS-PATH information.
- AS-PATH prepend
The client organization may consider the AS-PATH prepend option to influence the path that inbound traffic will take.
The following case study implements the AS-PATH prepend option to load-balance traffic over two links.
BollywoodFilms has offices in Bombay and Madras in India. The corporation desires Internet connectivity. Given the notoriously poor telecommunications infrastructure in the South Asian subcontinent, they decide to establish two connections to the local ISP, ISP-SouthAsia. One connection is out of router Bombay and the other is out of router Madras. BollywoodFilms thus multi-homes to the same ISP. Figure 7-13 shows a topology of BollywoodFilms’s external network.
BollywoodFilms owns networks 192.100.1.0/24 and
192.100.2.0/24. 192.100.1.0/24
connects to Bombay (line 51) and
192.100.2.0/24 connects to
Madras (line 61). The configurations on the
routers are as follows:
hostname Bombay
!
51 interface Ethernet0
ip address 192.100.1.1 255.255.255.0
!
52 interface Serial0
ip address 146.100.100.254 255.255.255.252
!
53 interface Serial1
ip address 10.1.1.4 255.255.255.0
!
router bgp 209
54 network 192.100.1.0
55 network 192.100.2.0
56 neighbor 10.1.1.1 remote-as 209
57 neighbor 192.100.100.253 remote-as 109
58 neighbor 192.100.100.253 route-map metric-adj2 out
!
access-list 1 permit 192.100.2.0 0.0.0.255
access-list 2 permit 192.100.1.0 0.0.0.255
!
59 route-map metric-adj2 permit 10
match ip address 1
set as-path prepend 209 209
!
60 route-map metric-adj2 permit 20
match ip address 2
hostname Madras
!
61 interface Ethernet0
ip address 192.100.2.1 255.255.255.0
!
62 interface Serial0
ip address 146.1.1.254 255.255.255.252
!
63 interface Serial1
ip address 10.1.1.1 255.255.255.0
!
router bgp 209
no synchronization
64 network 192.100.1.0
65 network 192.100.2.0
66 neighbor 10.1.1.4 remote-as 209
67 neighbor 200.1.1.253 remote-as 109
68 neighbor 200.1.1.253 route-map metric-adj out
!
access-list 1 permit 192.100.1.0 0.0.0.255
access-list 2 permit 192.100.2.0 0.0.0.255
!
69 route-map metric-adj permit 10
match ip address 1
set as-path prepend 209 209
!
70 route-map metric-adj permit 20
match ip address 2Note that both routers advertise 192.100.1.0 and
192.100.2.0 to the ISP (lines 54, 55, 64, and 65).
This ensures that inbound traffic has an alternate path if one link
fails. So, if Bombay’s link to
the ISP fails, external users on 192.100.1.0 will
receive inbound traffic via Madras, since
Madras advertises 192.100.1.0
to the ISP. This configuration works because
Bombay and Madras have a
link between each other (lines 53 and 63) over which they have an
I-BGP session (lines 56 and 66).
If you look a little deeper into the above configurations (lines 58,
59, 68, and 69), you’ll see that
Bombay and Madras do not
advertise 192.100.1.0 and
192.100.2.0 equally. Bombay
makes the AS-PATH attribute for 192.100.2.0 look
unattractive to routers in the Internet by lengthening its AS-PATH
attribute using the as-path prepend command.
Madras uses the same technique to make
192.100.1.0 look unattractive to Internet routers.
This ensures that when both ISP links are up, inbound traffic for
192.100.1.0 prefers to come directly into
Bombay and inbound traffic for
192.100.2.0 prefers to come directly into
Madras. Thus, a router in the
ISP’s network would have BGP table entries with two
paths for each prefix:
ISP-SAsia#sh ip bgp
...
Network Next Hop Metric LocPrf Weight Path
71 * 192.100.1.0 146.1.1.254 0 209 209 209 I
*> 146.100.100.254 0 0 209 i
72 *> 192.100.2.0 146.1.1.254 0 0 209 i
* 146.100.100.254 1 0 209 209 209 iHowever, the ISP router would prefer the shorter AS-PATH:
ISP-SAsia#sh ip route
...
73 B 192.100.1.0/24 [20/0] via 192.100.100.254, 00:05:58
74 B 192.100.2.0/24 [20/0] via 200.1.1.254, 00:01:44ISP-SouthAsia thus sees a shorter path for
192.100.1.0 via Bombay (line
71) and a shorter path for 192.100.2.0 via
Madras (line 72). If one of these lines goes
down, all inbound traffic will reroute to the other link, since the
BGP tables store both paths.
However, this completes only half the screenplay. The organization decides that outbound traffic from Bombay should exit via Bombay and outbound traffic from Madras should exit via Madras. To implement this policy, ISP-SouthAsia sends a default route to Bombay and Madras, respectively. So Bombay installs a default route that points out of its serial interface to ISP-SouthAsia (line 75) and Madras installs a default route that points out of its serial interface to ISP-SouthAsia (line 76):
Bombay#sh ip route
...
Gateway of last resort is 192.100.100.253 to network 0.0.0.0
75 B* 0.0.0.0/0 [20/0] via 192.100.100.253, 00:07:21
...
Madras#sh ip route
...
Gateway of last resort is 200.1.1.253 to network 0.0.0.0
76 B* 0.0.0.0/0 [20/0] via 200.1.1.253, 00:04:47
...If Bombay loses its link to ISP-SouthAsia, it will use the default route it receives from Madras via the I-BGP peering relationship:
Bombay#sh ip bgp
BGP table version is 72, local router ID is 192.100.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
77 *> 0.0.0.0 192.100.100.253 0 0 109 ?
* i 200.1.1.253 0 100 0 109 ?And, likewise, Madras will use the default route it receives from Bombay:
Madras#sh ip bgp
BGP table version is 80, local router ID is 192.100.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
78 > 0.0.0.0 200.1.1.253 0 0 109 ?
* i 192.100.100.253 0 100 0 109 ?