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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> >> >> 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 [email protected] >> <mailto:[email protected]> >> 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 : [email protected] >> <mailto:[email protected]> >> peering: http://as8554.peeringdb.com >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> <mailto:[email protected]> >> 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 : [email protected] > peering: http://as8554.peeringdb.com > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
