eBGP multihop & Halabi page 300 (anyone have any better ideas?)

From: Adam Quiggle (aquiggle@xxxxxxxxx)
Date: Mon Dec 31 2001 - 04:49:27 GMT-3


   
Hey gang,

Just fooling around with eBGP multihop on page 300 of Halabi's book. While
looking at Figure 10-1 on page 300 I thought about an interesting situation
that doesn't seem to be discussed in this section (maybe it does and I just
haven't gotten to it).

If you look at the configurations provided on pages 301-305 you will notice
that the configuration of RTE is conspicuously missing. I assume that this
was intentional to let the reader stumble across and think through this
problem. The most obvious problem is that using the configurations
provided RTD and RTF will not be able to form an eBGP multihop session
since neither router has a path to the ip address used to form the BGP
session. This can be easily solved by one of two methods:

(a) static routes on RTF and RTD
(b) configure an IGP between RTF, RTE and RTD, thus providing the
connectivity needed to form the BGP session.

This all seems simple enough and I'm sure everyone can see that solution
(a) would not be allowed on the CCIE lab...anyway.

Everything seems merry until you start thinking about routing packets
between AS1, AS2 and AS3. It seems that RTE would cause a lot of problems
very quickly since it does not have a path to any of the networks in AS3 or
AS1 (assuming that AS2 would have its own IGP that would inform it of
routes within its own AS). In addition we can not redistribute BGP routes
from AS1 and AS3 into the IGP of AS2 from RTD since that will just cause a
routing loop between RTE and RTD.

It seems to me that in order to solve this problem the routes for AS3 and
AS1 must come from RTF. To solve this problem I see one of two solutions:

(a) configure a default route on RTE pointed at RTF and rely on the IGP to
inform router RTE about routes within AS2 (this means AS2 could not be a
transit AS)
(b) Redistribute BGP on RTF into the IGP running between RTF, RTE and RTD.

Does anyone see another solution to this problem?

Thanks,
AQ



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:50 GMT-3