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

Fri Dec 15 15:54:14 EST 2006

Looks like next-hop recursive isn't available to me, but next-hop by
itself should be fine.  For some reason I'm not getting any policy hits on
a GigE VLAN on a 7500 (speaking of 7500's :)) running 12.1(22)E1 but it's
working fine on a 7206/G1 with the same IOS.

More digging...

Thanks, everybody.

On Thu, December 14, 2006 21:03, Rolf Mendelsohn wrote:
> Hi Rick,
>
> On Friday 15 December 2006 01:23, Rick Ernst wrote:
>> 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.
>
> Use a Next-hop which is a bit further away then the router you are
> connected
> to, ask your upstream for detail about a core router of his and make that
> the
> target of your PBR.
>
> In that case it get's looked via BGP and if for some reason that core goes
> down traffic isn't blackholed (given an ethernet link).
>
> route-map fast-out-is permit 10
>  description Match Traffic supposed to go via XYZ and send via ABC
>  match ip address 180
>  set ip next-hop recursive X.Y.Z.A
>
> I have a very similar scenario in terms of high cost/low latency & high
> latency/low cost (Satellite) links, so I route not only with PBR based on
> address blocks, but also on App.
>
> e.g.
>
> access-list 180 remark Deny local
> access-list 180 deny   ip X.Y.48.0 0.0.15.255 X.Y.48.0 0.0.15.255
> access-list 180 deny   ip X.Y.48.0 0.0.15.255 A.B.69.56 0.0.0.7
> access-list 180 deny   ip X.Y.48.0 0.0.15.255 A.B.127.80 0.0.0.3
> access-list 180 deny   ip X.Y.48.0 0.0.15.255 C.D.201.12 0.0.0.1
> access-list 180 remark Deny Junk
> access-list 180 deny   tcp X.Y.48.0 0.0.15.255 any eq smtp
> access-list 180 deny   tcp X.Y.48.0 0.0.15.255 eq smtp any
> access-list 180 deny   tcp X.Y.48.0 0.0.15.255 any eq pop3
> access-list 180 deny   tcp X.Y.48.0 0.0.15.255 eq pop3 any
> access-list 180 remark Permit latency-sensitive apps
> access-list 180 permit tcp any any eq www
> access-list 180 permit tcp any eq www any
> access-list 180 permit tcp any any eq 443
> access-list 180 permit tcp any eq 443 any
> access-list 180 permit tcp any any range 22 telnet
> access-list 180 permit tcp any range 22 telnet any
> access-list 180 permit tcp any any eq 3389
> access-list 180 permit tcp any eq 3389 any
> access-list 180 permit ip X.Y.54.0 0.0.1.255 any
> access-list 180 permit tcp X.Y.48.0 0.0.15.255 any eq 22
> access-list 180 permit tcp X.Y.48.0 0.0.15.255 any eq telnet
> access-list 180 permit tcp X.Y.48.0 0.0.15.255 any eq 3389
> access-list 180 permit ip X.Y.56.0 0.0.0.255 any
>
>
> Lastly make sure that you have a QoS Policy-map restricting the amount
> of "Silver Customer" / "Gold Customer traffic coming in or going out the
> other link - i.e. when one of your upstreams goes down, make sure that the
> customer with an SLA still has sufficient Bandwidth.
>
> HTH
> cheers
> /rolf
>
>>
>> 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-----
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>