[c-nsp] BGP transit selection from source customer network
Alexandre Durand
alexandre.durand at tasfrance.com
Wed Aug 3 08:40:29 EDT 2011
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
More information about the cisco-nsp
mailing list