[c-nsp] BGP transit selection from source customer network
P C
pc50000 at gmail.com
Wed Aug 3 13:37:26 EDT 2011
Only PBR is really required to make a certain "netblock/source"
address go to a particular egress interface. It should work as
desired
But be warned... PBR/"source based routing" is process switched on
some platforms and results in a large performance hit. It can also
suffer from some redundancy problems if not properly implemented (if
ISPB goes down, how will PBR know to re-route?)
It's also way too "static/inflexible" for my liking since it's not
destination based -- when equipment is changed/upgraded down the road
-- or even an interface moved -- it's easy to "miss" that one
source-based routing entry and cause an outage for that customer
On Wed, Aug 3, 2011 at 6:40 AM, Alexandre Durand
<alexandre.durand at tasfrance.com> wrote:
> Well I don t agree, It is easy enought on route A to overweight ISPA so path
> is preffered over ISPA for any source, so I just use PBR to send my customer
> traffic via ISPA and the other source traffic to the Router B with ISPB. As
> this is said, I might change my route-map as follow:
>
> ip prefix-list cust1 deny x.x.x.x/24
> ip prefix-list cust1 permit 0.0.0.0/0 le 32
>
> route-map cust1, permit, sequence 10
> Match clauses:
> ip address prefix-list cust1
> Set clauses:
> ip next-hop ISPB
> Policy routing matches: 15 packets, 1710 bytes
>
> Any traffic except my customer traffic will be forwarded to ISPB
>
>
>
>
> On 03/08/11 09:54, Andrii Morozov wrote:
>>
>> According to the scheme drawn above, you have an iBGP between your border
>> routers. Thus, they will send the best routes to each other. This means, no
>> matter whether you set PBR or not, if the best path is selected over ISB B,
>> the traffic will traverse that link, but not ISP A.
>>
>> 2011/8/2 Alexandre Durand <alexandre.durand at tasfrance.com
>> <mailto:alexandre.durand at tasfrance.com>>
>>
>> weird I used only PBR and it seems to be working. I created a
>> route-map that send cust1 traffic out to ISPA (RIB internet
>> routes) and any other customer source traffic out to ISPB. the
>> weird thing is that ISPB routes are NLRI routes and not RIB routes
>> ... how can this be working ...
>>
>> regards
>>
>> alexandre
>>
>> route-map cust1, permit, sequence 10
>> Match clauses:
>> ip address (access-lists): cust1
>> Set clauses:
>> ip next-hop ISPA
>> Policy routing matches: 122 packets, 13908 bytes
>> route-map cust1, permit, sequence 20
>> Match clauses: (ANY)
>> Set clauses:
>> ip next-hop ISPB
>> Policy routing matches: 15 packets, 1710 bytes
>>
>>
>> On 02/08/11 11:04, Alexandre Durand wrote:
>>
>> Hi,
>>
>> You are right, however on router A is connected to ISPA, bgp
>> will add only preferred ISPA routes and not the others routes
>> from router B ISPB with IBGP, but only ISPA routes will be
>> preferred on this router A (attribute weight), router A will
>> be not aware about ISPB rouites unless ISPA goes down.
>>
>> I may use a dedicated vrf for ISPA so global routing table and
>> vrf table are not bound each other. And then use PBR over
>> route-map to redirect first via ISPA VRF and secondly via
>> global routing table where ISPB routes will be present in RIB.
>> What do you think about it?
>>
>> The only issue witch such solution is that I will need to
>> upgrade the ios because vrf under route-map is not supported
>> on my IOS(12.2(18)SXD3).
>>
>> regards
>>
>> Alexandre
>>
>> On 01/08/11 17:56, David Freedman wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/08/11 15:35, Alexandre Durand wrote:
>>
>> Hi Andrew,
>>
>> Tnhan you for you answer. Actually youa re right about
>> the inbound
>> traffic in which I can easily advetise this network
>> with a preference to
>> my "ISPA", this is fine and already done.
>>
>> The issue here is about the oubound traffic, when my
>> customer traffic is
>> going back out to ISP, I can also you weight on the
>> router where I host
>> this "ISPA" and use no-advertise attribute so I don t
>> advertise
>> prefixes to others iBGP routers, fine but others
>> customer traffic will
>> also be routed via ISPA because the shortest ISP path
>> is going throught
>> this router too...
>>
>> I think what you are saying sounds like this:
>>
>> |Your Network---Internet---------|
>>
>> [Cust1]--( N )
>> ( E )--[ISPA]-(N)-[Cust4]
>> [Cust2]--( T ) (E)
>> ( W )--[ISPB]-(T)-[Cust5]
>> [Cust3]--( K )
>>
>>
>>
>> I take it you want to do :
>>
>> - - Predetermined outbound path Cust1->Cust4 via ISPA
>> - - Predetermined outbound path Cust2->Cust5 via ISPB
>> - - Cust3 -> Cust4/5 via any/best path
>>
>> What you are talking about is essentially policy routing
>> at your edge
>> (i.e using your own criteria, like customer ID to
>> influence outbound
>> routing, not metrics)
>>
>> you can do this simply with PBR at the edge but it won't
>> be very
>> reliable, but you might want to look at OER/PFR
>>
>>
>> (http://www.cisco.com/en/US/products/ps8787/products_ios_protocol_option_home.html)
>>
>>
>> Dave.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla -
>> http://enigmail.mozdev.org/
>>
>>
>> iEYEARECAAYFAk42zL4ACgkQtFWeqpgEZrK2BgCgwGU7nRzRPklKNII9L69uA00I
>> w5YAoKkhzi8L8Roo5oONsg/6z1aNW0ka
>> =lLQt
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>>
>>
>> -- Alexandre DURAND
>> TAS FRANCE
>> WTC 1-K, 1300 route des Crêtes
>> 06560 Valbonne Sophia Antipolis
>> Phone : +33 (0)4 92 94 56 93
>> Fax : +33 (0)4 92 94 33 99
>> Web: http://www.tasfrance.com
>> Email : alexandre.durand at tasfrance.com
>> <mailto:alexandre.durand at tasfrance.com>
>> peering: http://as8554.peeringdb.com
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>
>
> --
> Alexandre DURAND
> TAS FRANCE
> WTC 1-K, 1300 route des Crêtes
> 06560 Valbonne Sophia Antipolis
> Phone : +33 (0)4 92 94 56 93
> Fax : +33 (0)4 92 94 33 99
> Web: http://www.tasfrance.com
> Email : alexandre.durand at tasfrance.com
> peering: http://as8554.peeringdb.com
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list