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

Rolf Mendelsohn rolf-web at cyberops.biz
Fri Dec 15 00:03:28 EST 2006


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/


More information about the cisco-nsp mailing list