From: David Buechner (dbuechn@attglobal.net)
Date: Thu Mar 06 2003 - 12:42:18 GMT-3
At 10:41 am 2/26/2003 +0900, tan wrote:
>David, do your instructions say you must have two routes on the southern
>routers? Maybe load balancing will work. If using load balancing, two routes
>could be best, but I don't know if this means two routes will be sent, but
>sounds likely. Load balancing only works on ebgp, but if you use confed-ebgp
>to those southern routers, and maximum paths command to raise default paths
>from one to 2, maybe you can get both paths sent...
Tan,
Actually, in this case, I didn't have instructions so much as I did a
nightmare of my own creation! :-) Seriously though, this was a scenario I
designed based on some things I've seen on my previous attempts. I've
taken those experiences and worked out some scenarios of my own and have
discovered that the design of my scenarios sometimes reflects areas I don't
understand as well as I thought!
Everyone who responded that my RR cluster was working as designed was 100%
correct! I finally found the paragraph in the Doyle book that I
mis-interpreted (after reading all your responses and RFC 1966!) and
understand what is going on better!
Since that revelation I've been experimenting. A BGP confederation with
the same "peering topology" as my RR cluster gave the same results as you
would expect. I finally came to the conclusion that changing which
router(s) I used as the RRs was the way to go - in my scenario I had
everyone peer with both R1 and R3. R1 and R3 were both configured to treat
Routers 2, 5, and 6 as RR clients (see diagram below).
My experimentation also pointed out another issue to me. While this is
likely a "no duh! (i.e. obvious)" issue for many on the list I'll mention
it in case doing so is helpful to someone else.
The issue is this: I have a new understanding for how BGP routing decisions
are effected by underlying route metrics which are often IGP issues. For
example, my original scenario had a part of the network which was EIGRP and
a part which was OSPF. Of particular note was that the "next hop"
addresses were in parts of the network served by different IGPs. The
difference in metrics had effects on BGP routing decisions which made sense
given the IGPs and metrics involved but which were not what one would want
if this were a real network.
Using EIGRP as the IGP for the whole network solved this issue and gave me
the routes I wanted.
Using OSPF highlighted an OSPF design issue for me. As is sometimes true
in a lab scenario I had an OSPF area design which probably wouldn't show up
in real life. I ended up with a situation in which the best route from R2
to the backbone was R2 - ethernet - R5 - serial - R1 - ethernet -
backbone. BGP on R2 was picking R2 - serial - R6 - serial - R3 - ethernet
- backbone instead because said path traversed OSPF area 0 where as the
previous route traversed OSPF areas 25 and 15.
Anyway, enough rambling. I hope it is helpful to someone. Also, Tan,
Peter, Annu, Adz, Bob, and Thomas (and anyone I've forgotten) - thanks for
your input!! Your help is greatly appreciated.
David
> > >>I have a BGP route reflector issue on the following network:
> > >>
> > >>
> > >>--- (E1) --- R7 (AS 254) --- (E0) ---
> > >>| |
> > >>| |
> > >>R3 (AS 400) R1 (AS 400)
> > >>| |
> > >>| |
> > >>------------ R6 (AS 400) ------------
> > >> | \
> > >> | \-- R5 (AS 400)
> > >> |
> > >> R2 (AS 400)
This archive was generated by hypermail 2.1.4 : Sat Apr 05 2003 - 08:51:34 GMT-3