From: James (james@towardex.com)
Date: Sun Jul 04 2004 - 19:06:34 GMT-3
Ah.. I didn't know this was a (multihop|nexthop-modified) session :P
I can see a few ways of working on this:
a) Adjust IGP cost to the next-hop like you suggested.
b) Change to plain single-hop eBGP session between AS1 and AS2 if possible.
c) Set route-map between eBGP peers to manually set next-hop per prefix or use
next-hop-self.
I am sure people can suggest other ways as well.. But above 3 seems easiest
to me..
-J
On Sun, Jul 04, 2004 at 10:57:44PM +0100, Richard Dumoulin wrote:
> Hi James, what I mean is that although Ra will prefer Rb to go to AS2 thanks
> to the local pref, actually because of the next hop of the routes the
> traffic will go directly to AS2,
>
> --Richard
>
> -----Original Message-----
> From: James [mailto:james@towardex.com]
> Sent: domingo, 04 de julio de 2004 23:46
> To: Richard Dumoulin
> Cc: ccielab@groupstudy.com
> Subject: Re: BGP indecision !?!?
>
>
> I belive local-pref overrides everything with exception of weight. Hot
> potato
> behaviour can be cancelled with higher LP on bgp route received from
> non-direct connected peer. So... local-pref adjustment of rB should work
> well for you I think..
>
> -J
>
> On Sun, Jul 04, 2004 at 10:32:23PM +0100, Richard Dumoulin wrote:
> > Hi group,
> >
> > Suppose the following scenario: Ra and Rb are in the same BGP AS 1.
> > Both are connected to another AS 2. AS 2 sends routes to AS1. And we
> > are asked to configure in such a way that Ra will prefer to exit to
> > AS2 via Rb instead of directly. One way is to increase the local
> > preference on Rb. But what happens if the next hop of those routes has
> > a lower igp metric through AS 2 ? Should the metrics be manipulated so
> > that Ra traffic is actually sent through Rb ?
> >
> > Thank you
> >
> > --Richard
> >
> >
> >
> >
> > **********************************************************************
> > Any opinions expressed in the email are those of the individual and
> > not necessarily the company. This email and any files transmitted with
> > it are confidential and solely for the use of the intended recipient.
> > If you are not the intended recipient or the person responsible for
> > delivering it to the intended recipient, be advised that you have
> > received this email in error and that any dissemination, distribution,
> > copying or use is strictly prohibited.
> >
> > If you have received this email in error, or if you are concerned with
> > the content of this email please e-mail to:
> > e-security.support@vanco.info
> >
> > The contents of an attachment to this e-mail may contain software
> > viruses which could damage your own computer system. While the sender has
> taken every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry out your own virus checks before opening any attachments to
> this e-mail.
> > **********************************************************************
> >
> > ______________________________________________________________________
> > _
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> --
> James Jun TowardEX Technologies,
> Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@towardex.com Boston-based Colocation & Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> www.twdx.net
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:46 GMT-3