From: Chua, Parry (Parry.Chua@xxxxxxxxxx)
Date: Tue Jan 01 2002 - 22:46:12 GMT-3
Hi,
I think that the topic is focusing on BUILDING PEERING SESSIONS, it main
purpose is to show different way of EBGP session as well as IBGP session
is build using loopback interface on one router.
Parry Chua
-----Original Message-----
From: Adam Quiggle [mailto:aquiggle@nc.rr.com]
Sent: Wednesday, January 02, 2002 9:11 AM
To: EA Louie; ccielab@groupstudy.com
Subject: Re: eBGP multihop & Halabi page 300 (anyone have any better
ideas?)
Louie,
I don't think there is anything misstated in Halabi's book, just a lack
of clarification. As a theoretical example I understand how running
OSPF between RTD, RTE and RTF resolves a local reachability problem.
However, I should have stated that I was looking at this from a global
reachability perspective.
For example, what if the network 172.31.10.0/24 was hanging off of RTC
and we advertised it into BGP. Without injecting the BGP routes into
OSPF
RTE will never know how to get to 172.31.10.0/24 and subsequently AS2
will not be able to reach that network even though RTD has it in his
BGP table.
Maybe this is an obscure point, but given the configs, I think you could
be mislead to think that you can run eBGP between RTF and RTD without
having to address RTE and the global reachability problem.
Looks like I was just over-analyzing what was supposed to be a very
simple configuration.
Thanks,
AQ
At 04:04 AM 12/31/01, EA Louie wrote:
>dude, you missed the obvious in this scenario - ospf is running on the
>192.68 network. read those configs again, and look at the sh ip bgp
nei on
>p 307 (2nd edition). obviously RTF found the nexthop to RTD.
>
>of course, i'm reading from 2ed of Halabi - check the errata for 1ed of
>Halabi if that's what you're using.
>
>-e-
>
>----- Original Message -----
>From: "Adam Quiggle" <aquiggle@nc.rr.com>
>To: <ccielab@groupstudy.com>
>Sent: Sunday, December 30, 2001 11:49 PM
>Subject: eBGP multihop & Halabi page 300 (anyone have any better
ideas?)
>
>
> > 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:56:13 GMT-3