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 "BGP
> best path selection algorithm".
> My doubt is if there is any option, so we can decide first by RouterID
> 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 among
> MPLS VPN. (RFC2547)
> There can be multiple FW asociated to each VPN.
> We use an auxiliary transit VPN ("VPNfw") , so that we avoid asymmetric
> 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 BGP.
> ===================================================================
> 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 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 appears
> 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 longer.
>
>
>
============================================================================================
> 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
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 "BGP
> best path selection algorithm".
> My doubt is if there is any option, so we can decide first by RouterID
> 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 among
> MPLS VPN. (RFC2547)
> There can be multiple FW asociated to each VPN.
> We use an auxiliary transit VPN ("VPNfw") , so that we avoid asymmetric
> 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 BGP.
> ===================================================================
> 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 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 appears
> 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 longer.
>
>
>
============================================================================================
> 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