[nsp] Re: [nsp] ¿ Is it possible to change the order "BGP best path selection algorithm" ?

cros_m@tsm.es cros_m@tsm.es
Tue, 20 Aug 2002 09:16:53 +0200


Hello:


* bgp bestpath as-path ignore (In the proposed scenario the as_path is the
same for all the prefixes, so this is not necessary).
* bgp bestpath compare-routerid.( This is really needed, and it is active
by default in some IOS versions).

About the URL you have given ( http://www.elemental.net/~lf/undoc/#d0e1=
295
) . This was the kind of information that I was hoping would give an
undocumented command  , but the entries about BGP don't help in this case.



Thanks

      Miguel.





19/08/2002 20:54
Hank Nussbacher  <hank@att.net.il>


Destinatarios:    cros_m@tsm.es
CC:         cisco-nsp@puck.nether.net
Asunto:     Re: [nsp] ¿ Is it possible to change the order "BGP best path
            selection algorithm" ?


On Mon, 19 Aug 2002 cros_m@tsm.es wrote:

Not going to fully check this but you might want to try 'bgp bestpath
as-path ignore' or 'bgp bestpath compare-routerid'.  Both of these
(and others on that page) change the "BGP best path selection
algorithm" but perhaps not as much as you would like.

See:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr=
/ip_r/iprprt2/1rdbgp.htm#xtocid4

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr=
/ip_r/iprprt2/1rdbgp.htm#xtocid5


Let me know if this helps.

-Hank

>
>
>
============================================================================================

> The Question: There are many options to change the behavior of the "B=
GP
> best path selection algorithm".
> My doubt is if there is any option, so we can decide first by RouterI=
D
> instead of"eBGP is preferred over iBGP path".
>
============================================================================================

>
> The scenario is a very controlled one ( is for internal use in a
> company).
>
> Standard Behavior
> =================
>
>        Prefix      MED   e/iBGP(1) Dist_NH(2)    RouterID(3)
>      =======================
====================================
>     (*)prefix_a     5    (eBGP)      1            5.5.5.5    <====
==
>        prefix_a   5     iBGP       5            2.2.2.2
>
>
> Desired Behavior
> =================
>
>       Prefix      MED   e/iBGP(-) Dist_NH(-)    RouterID(1)
>      =======================
====================================
>      prefix_a     5     eBGP     1            5.5.5.5
>   (*)prefix_a     5     iBGP       5           (2.2.2.2)   <====
===
>
>
>
>
>
>
> More Information
> ===============
>
> We are working in a distributed FW solution to the interconnection am=
ong
> MPLS VPN. (RFC2547)
> There can be multiple FW asociated to each VPN.
> We use an auxiliary transit VPN ("VPNfw") , so that we avoid asymmetr=
ic
> routing.
> Travelling from VPNorig to VPNdest would be as indicated below.
>
>     VPNorig ===> FW_exit_orig ===>  VPNfw   ===> FW=
_enter_dest ===>
> VPNdest
>
>
> We have several options and in one of them we use the MED field of BG=
P.
> ========================
============================================
>     We don't play with Route Targets (Each VPN has its RD and they
> import/export its Route Target).
>     VPNorig (VRF) have default routes pointing to their FW sites.
>     VPNfw learns the prefixes of all the final VPN trough eBGP.
>     We are "cheating" as we declare as CE BGP neighbours the VRF inst=
ance
> associated to the auxiliary VPNfw.
>
> |------------|                       |-------------|
> |    * VRF1  |----- eBGP neighbour --|-* VRFfw     |
> |PE  * VRF2  |----- eBGP neighbour -// /       PE  |
> |    . . .   |                      /|/            |
> |    *VRFn-1 |----- eBGP neighbour / /           |
> |    *VRFn   |----- eBGP neighbour  /|             |
> |------------|                       |-------------|
>
>     The prefixes carry in the MED, the IGP metric ( set metric type
> internal).
>     We have multiple sites with "VPN/VRF fw" so that we have multiple=

> paths for the same prefix, differing only in the MED value.
>     In Cisco, the BGP Router ID can not be specified per VRF, so we
> needed 2 PE instead of one.
>     We had to play with Local AS, Allow AS IN,  AS Path Prepend.
>
>     Everything works OK but we have a small (really big) problem. The=
 BGP
> selection criteria works well and the decision of the
>     BGP best path is always based in the MED value. The problem appea=
rs
> when the paths for a specific prefix have the same MED value.
>     We were expecting that the "Router ID" would decide, but the prob=
lem
> is that the we forgot the intermmediate step in which
>     "eBGP is preferred over iBGP path".
>
>
> I have omitted many details, but I didn't want to make the Email long=
er.
>
>
>
============================================================================================

> The Question: As there are many options to change the behavior of the=

"BGP
> best path selection algorithm".
> Is there any option, so we can decide first by RouterID instead of"eB=
GP
> is preferred over iBGP path" ?
>
============================================================================================

>
> Standard Behavior
> =================
>
>        Prefix      MED   e/iBGP(1) Dist_NH(2)  RouterID(3)
>      =======================
====================================
>     (*)prefix_a     5    (eBGP)      1            5.5.5.5    <====
==
>        prefix_a     5     iBGP       5            2.2.2.2
>
>
> Desired Behavior
> =================
>
>       Prefix      MED   e/iBGP(-) Dist_NH(-)    RouterID(1)
>      =======================
====================================
>      prefix_a     5     eBGP       1            5.5.5.5
>   (*)prefix_a     5     iBGP       5         (2.2.2.2)   <=====
==
>     The scenario is a very controlled one ( is for internal use in a
> company).
>
>
> Thanks
>
>
>     Miguel
>
> _______________________________________________
> cisco-nsp mailing listreal_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

Hank Nussbacher