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/
