[31183] in North American Network Operators' Group
RE: Confussion over multi-homing
daemon@ATHENA.MIT.EDU (Dmitri Krioukov)
Fri Sep 15 11:58:37 2000
From: "Dmitri Krioukov" <dima@krioukov.net>
To: <nanog@merit.edu>
Date: Fri, 15 Sep 2000 12:11:12 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFGEAGEPAA.dima@krioukov.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1148622BC878D411971F0060082B042C36C8@hawk.lvrmr.mhsc.com>
Errors-To: owner-nanog-outgoing@merit.edu
has *ANYBODY* done this?
--
Network Working Group T. Bates
Request for Comments: 2260 Cisco Systems
Category: Informational Y. Rekhter
Cisco Systems
January 1998
Scalable Support for Multi-homed Multi-provider Connectivity
<...>
5.2. Further improvements
<...>
An enterprise border router would maintain EBGP peering not just with
the directly connected border router of an ISP, but with the border
router(s) in one or more ISPs that have their border routers directly
connected to the other border routers within the enterprise. We
refer to such peering as "non-direct" EBGP.
An ISP that maintains both direct and non-direct EBGP peering with a
particular enterprise would advertise the same set of routes over
both of these peerings. An enterprise border router that maintains
either direct or non-direct peering with an ISP advertises to that
ISP reachability to the address prefix that was allocated by that ISP
to the enterprise. Within the ISP routes received over direct
peering should be preferred over routes received over non-direct
peering. Likewise, within the enterprise routes received over direct
peering should be preferred over routes received over non-direct
peering.
Forwarding along a route received over non-direct peering should be
accomplished via encapsulation [RFC1773].
As an illustration consider an enterprise connected to two ISPs,
ISP-A and ISP-B. Denote the enterprise border router that connects
the enterprise to ISP-A as E-BR-A, and the ISP-A border router that
is connected to E-BR-A as ISP-BR-A; denote the enterprise border
router that connects the enterprise to ISP-B as E-BR-B, and the ISP-B
border router that is connected to E-BR-B as ISP-BR-B. Denote the
address prefix that ISP-A allocated to the enterprise as Pref-A;
denote the address prefix that ISP-B allocated to the enterprise as
Pref-B. E-BR-A maintains direct EBGP peering with ISP-BR-A and
advertises reachability to Pref-A over that peering. E-BR-A also
maintain a non-direct EBGP peering with ISP-BR-B and advertises
reachability to Pref-B over that peering. E-BR-B maintains direct
EBGP peering with ISP-BR-B, and advertises reachability to Pref-B
over that peering. E-BR-B also maintains a non-direct EBGP peering
with ISP-BR-A, and advertises reachability to Pref-A over that
peering.
When connectivity between the enterprise and both of its ISPs (ISP-A
and ISP-B is up, traffic destined to hosts whose addresses were
assigned out of Pref-A would flow through ISP-A to ISP-BR-A to E-BR-
A, and then into the enterprise. Likewise, traffic destined to hosts
whose addresses were assigned out of Pref-B would flow through ISP-B
to ISP-BR-B to E-BR-B, and then into the enterprise. Now consider
what would happen when connectivity between ISP-BR-B and E-BR-B goes
down. In this case traffic to hosts whose addresses were assigned
out of Pref-A would be handled as before. But traffic to hosts whose
addresses were assigned out of Pref-B would flow through ISP-B to
ISP-BR-B, ISP-BR-B would encapsulate this traffic and send it to E-
BR-A, where the traffic will get decapsulated and then be sent into
the enterprise. Figure 2 below describes this approach graphically.
+---------+ +---------+
( ) ( )
( ISP-A ) ( ISP-B )
( ) ( )
+---------+ +---------+
| |
+--------+ +--------+
|ISP-BR-A| |ISP-BR-B|
+--------+ +--------+
| /+/ |
/\ | Pref-B /+/ |
|| | /+/ \./
Pref-A| /+/ non- /.\
|| | /+/ direct |
| /+/ EBGP |
+------+ +-------+
|E-BR-A|-----------|E-BR-B |
+------+ IBGP +-------+
Figure 2: Reachability information advertised via non-direct EBGP
Observe that with this scheme there is no additional routing
information due to multi-homed enterprises that has to be carried in
the "default-free" zone of the Internet. In addition this scheme
doesn't degrade in the presence of ISPs that filter out routes based
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
on the length of their address prefixes.
Note that the set of routers within an ISP that maintain non-direct
peering with the border routers within an enterprise doesn't have to
be restricted to the ISP's border routers that have direct peering
with the enterprise's border routers. The non-direct peering could be
maintained with any router within the ISP. Doing this could improve
the overall robustness in the presence of failures within the ISP.
--
thanks,
--
dima.
