«

Hi All,

I am searching for a way to make source routing of Ips of my network to
my bgp neighbors.
Currently, i force the traffic to a specific neighbor.

Configuration :

access-list 150 permit ip host 11.12.13.15 any

route-map test permit 10
match ip address 150
set ip next-hop 1.2.3.4 #( Transit 1 )

interface Vlan55
ip policy route-map test


I want to have a more flexible solution for that.


Example :

11.12.13.14 | |
-------------> | | ---------> Transit 1 ( local-pref 90)
| BGP |
| Router | ---------> Transit 2 ( local-pref 100)
11.12.13.15 | |
-------------> | | ---------> Peer with A ( local-pref 105 )
| | ---------> Peer with B ( local-pref 110 )

I want the outbound traffic which ip source address is 11.12.13.14 to be
able to reach all networks depending on the neighbor local-pref
parameters. ( This solution currently work )

I want the outbound traffic which ip source address is 11.12.13.15 to
not be able to go through "Transit 2" and "Peer with A".


Any help or pointers towards a solution will also be greatly appreciated.

Thanks.

Regards,

Nicolas.

"Nicolas" <> wrote in message
news:43fc633b$0$12129$...
> I want the outbound traffic which ip source address is 11.12.13.14 to be
> able to reach all networks depending on the neighbor local-pref
> parameters. ( This solution currently work )
>
don't need a policy map for this, just let it fall through to the
routing-based forwarding (= don't do anything specific about this address).

> I want the outbound traffic which ip source address is 11.12.13.15 to not
> be able to go through "Transit 2" and "Peer with A".
>
you can use 'verify-availability' as described in "Policy Based Routing with
the Multiple Tracking Options Feature Configuration Example"
(http://www.cisco.com/en/US/customer/...0211f5c.shtml),
however this will not take into consideration individual networks reachable
via particular peer (that is you can't switch traffic based also on
destinations unless it's small set of arbitrary destinations).

Kind regards,
iLya

Hi ILya,

Thanks for your reponse.

Charlie Root wrote:
>>I want the outbound traffic which ip source address is 11.12.13.14 to be
>>able to reach all networks depending on the neighbor local-pref
>>parameters. ( This solution currently work )
>>
>
> don't need a policy map for this, just let it fall through to the
> routing-based forwarding (= don't do anything specific about this address).
>
>
>>I want the outbound traffic which ip source address is 11.12.13.15 to not
>>be able to go through "Transit 2" and "Peer with A".
>>
>
> you can use 'verify-availability' as described in "Policy Based Routing with
> the Multiple Tracking Options Feature Configuration Example"

I dont want to verify the availability of a particular link.
I just want to create some specific routing policy for some address of
my network through my ebgp routes.

Best Regards,

Nicolas

"Nicolas" <> wrote in message
news:43fc7a2a$0$17070$...
> Hi ILya,
>
> Thanks for your reponse.
>
> Charlie Root wrote:
>>>I want the outbound traffic which ip source address is 11.12.13.14 to be
>>>able to reach all networks depending on the neighbor local-pref
>>>parameters. ( This solution currently work )
>>>
>>
>> don't need a policy map for this, just let it fall through to the
>> routing-based forwarding (= don't do anything specific about this
>> address).
>>
>>
>>>I want the outbound traffic which ip source address is 11.12.13.15 to not
>>>be able to go through "Transit 2" and "Peer with A".
>>>
>>
>> you can use 'verify-availability' as described in "Policy Based Routing
>> with the Multiple Tracking Options Feature Configuration Example"
>
> I dont want to verify the availability of a particular link.
> I just want to create some specific routing policy for some address of my
> network through my ebgp routes.
>
the problem with this is that only route with best metric (local-pref) will
make it into the routing table (bgp table itself is not used for forwarding
decisions, it only installs best path into the routing table).

the only solution comes to my mind is to use VRF for each of this addresses
and for each of your peer links, then define policy which routes are
exchanged between VRFs. But I wouldn't do it - you surely will end up with
at least double increase in memory requirements (to keep at least two copies
of the routing table). I haven't tried this yet (but actually curious to try
it in the lab when I have time), so can't be sure what other caveats are
there and if it going to work at all.

Kind regards,
iLya