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

cros_m@tsm.es cros_m@tsm.es
Mon, 19 Aug 2002 18:36:40 +0200


Why wouldn't you give a better local-preference to those routes you want
to prefer?

The other solution used:
* Local Preference.
* Route Maps which modify metrics based on community values.

What we wanted is an alternative that didn't needed so much configuration
work. This proposal would give
us maximum flexibility with no extra work.

The packet flow would be aproximately
* The IP packet exit the VPNorig through the nearest PE router with FW
(they injected 0.0.0.0 default route for each VRF).
* The IP packet enters the auxiliary VPN (VPNfw).
* The VPNfw should have path to the prefixes of all the normal VPN.
* The IP packet would leave the VPNfw to entre the VPNdest by the "nearest"
PE to the destination address.
* The return IP packet (TCP sessions) would follow the same path in the
reverse direction and then the FW that are between VPN wouldn't have
problems dealing with the State of IP connections.


According to "BGP Best Path Selection Algorithm" ("http://www.cisco.com=
/warp/public/459/25.shtml")
(A) Leaving the VPNorig is based in 0.0.0.0 best path which is decided by
the point number 8
       Prefer the path with the lowest IGP metric to the BGP next hop.
(B) Entering the VPNdest from the VPNfw is decided by the point number 6.
       Prefer the path with the lowest multi-exit discriminator (MED).
       But when they are equal, "eBGP is preferred over iBGP path"



  The prefixes are the same but the logical view in the auxiliary VPN
  (VPNfw) has nothing to do with the normal VPN.
  The VPNfw sees them as coming from the CE site ( they come from the PE
  side of other VRF).

  VPNx  /  VPN x
  ===============
  CEx1--PE1 ->|=============|<- PEfw2 (vrf X)   ip route vrf x 0.0.0.0 . .
  .
  CEy1---^    |             |
              |             |
  CEx2--PE2 ->|  MPLS CORE  |<- PEfw1 (vrf X)   ip route vrf x 0.0.0.0 . .
  .
  CEy2---^    |             |
              |             |
  CEx3--PE3 ->|=============|
  CEy3---^


  VPNfw /VRF fw
  ==============
  |=============|<- PEfw2 (vrfFW)   Prefixes CEx1, CEy1, CEx2, CEy2, CEx3 ,
  CEy3
  |             |                         MED  1     1      2     2    3
  3
  |             |
  |  MPLS CORE  |<- PEfw1 (vrfFW)  Prefixes CEx1, CEy1, CEx2, CEy2, CEx3 ,
  CEy3.
  |             |                       MED   3     3      2     2    1
  1
  |             |
  |=============|

     Peers relationship
     ================
     Apart  from the MP-iBGP ones in the MPLS core.

     PEfw1 (vrfX)    ------ PEfw1 (vrfFW)                  vrfFW learns all
prefixes from vrf X  in PEfw1 (MED value from set metric type internal)
     PEfw1 (vrfY)    ------ PEfw1 (vrfFW)                  vrfFW learns all
prefixes from vrf Y in PEfw1 (MED value from set metric type internal)
     ......
     PEfw1 (vrfZ)    ------ PEfw1 (vrfFW)                  vrfFW learns all
prefixes from vrf Z in PEfw1 (MED value from set metric type internal)

     PEfw2 (vrfX)    ------ PEfw2 (vrfFW)                  vrfFW learns all
prefixes from vrf X in PEfw2 (MED value from set metric type internal)
     PEfw2 (vrfY)    ------ PEfw2 (vrfFW)                  vrfFW learns all
prefixes from vrf Y in PEfw2 (MED value from set metric type internal)
     ......
     PEfw2 (vrfZ)    ------ PEfw2 (vrfFW)                  vrfFW learns all
prefixes from vrf Z in PEfw2 (MED value from set metric type internal)

     This is a simplification, because in Cisco an additional PE router  is
needed.
     In Juniper this is possible, but in Cisco you can not establish eBGP
sessions among VRF instances of the same PE router because
    the "BGP Router ID" is a global parameter that can not be changed "per
VRF".





19/08/2002 17:17
Pekka Savola <pekkas@netcore.fi>


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:
>
============================================================================================

> 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)   <====
===

Why wouldn't you give a better local-preference to those routes you want
to prefer?


> 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
instance
> 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 multip=
le
> 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. T=
he
BGP
> selection criteria works well and the decision of the
>       BGP best path is always based in the MED value. The problem app=
ears
> when the paths for a specific prefix have the same MED value.
>       We were expecting that the "Router ID" would decide, but the
problem
> 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  "=
eBGP
> 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 list  real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords