[c-nsp] Selecting an eBGP destination based on the source network.

[Rick Ernst]

To bring together the three suggestions I've seen so far:

1) PBR - I need to look closer at multple next-hops and CPU utilization
   on the router with the input interface.  It looks like CEF/dCEF should
   mitigate it, but nothing like trying in a real environment.  The third
   issue I need to check is making sure that next-hop to a router that
   has it's eBGP session down will use iBGP to use another available
   upstream.

2) VRF - I haven't messed with this at all. I need to look at it.

3) OER - Looks like it's geared toward handling dynamic performance changes
   and is applied to all outbound traffic; not selected source networks
   and pre-determined quality of links.

For a high-level description of our network; we have dedicated/individual
7206/G1s for each upstream running an eBGP session.  Each is
dual-connected on different networks via OSPF to redundant 7500 core
routers acting as RR servers.  They, in-turn, are connected to multiple
aggregation devices with the same dual-network/OSPF connectivity.

Thanks for the suggestions, and keep them coming.  I got my brain locked
into thinking of a BGP solution and forgot about PBR.

Rick




On Thu, December 14, 2006 15:25, Bruce Pinsky wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rick Ernst wrote:
>> It's a forwarding decision.
>>
>> "Customer class A" would prefer high-speed/high-quality outbound links
>> and
>> fall back to low-speed/low-cost links in case of failure, while
>> "Customer
>> class B" would prefer the low-speed/low-cost links and fall back to the
>> high-speed/high-quality links.
>>
>> The key would be determining the destination based on source network,
>> and
>> my initial thought was doing something with next-hop, but that raises a
>> possible reachability problem if the next-hop isn't available.
>>
>
> You can specify multiple next-hops that will be tried, in order, if not
> available.
>
>
> Depending on your design/topology, there may be some ways to use VRF-Lite
> to segregate the different customer classes and create different routing
> policies for each of those classes.
>
> If you can share some more info about your network (privately if
> necessary), I might be able to offer up a couple of different options.
>
> - --
> =========
> bep
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.4 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFgd2EE1XcgMgrtyYRAuJcAKCGKqcV2Jndgni1e+4ZV15idVI8FwCghwIu
> VJvXslUM7OROUfe9HOJ/OBQ=
> =5x9M
> -----END PGP SIGNATURE-----
>