less than a /24 & BGP tricks

Stephen Kratzer kratzers at pa.net
Tue Jun 30 17:08:53 UTC 2009


Neal,

If your providers are doing uRPF, and it is always the case that hosts using 
provider A's IPs must route through provider A, and hosts using provider B's 
IPs must route through provider B, then why not enforce this behavior in your 
routing tables rather than doing PBR?

From your description, it doesn't sound like you're distributing subnets 
across datacenters, and it's difficult to tell how, why, or if you're sharing 
provider routes between your routers.

Stephen Kratzer
Network Engineer
CTI Networks, Inc.

On Tuesday 30 June 2009 09:54:29 neal rauhauser wrote:
>    I have a network with two upstreams that land in datacenters many miles
> apart. The hardware involved is Cisco 7507s with RSP4s and VIP4-80. I've
> got a curious problem which I hope others here have faced.
>
>    A while ago we got a /28 from each provider and attached it to a
> dedicated fast ethernet interface at each location. Inbound traffic arrives
> normally and anything arriving on that port is policy routed to the
> upstream that provided the prefix.
>
>    This was all well and good when it was a little firewall with a Linux
> machine  behind it being used to check latency and do other diagnostics,
> but the sales people noticed it and have lined up a couple of opportunities
> to sell a service that would depend on our being able to receive and send
> traffic from blocks less than a /24.
>
>    The policy routing works fine at low volume, but the RSP4 is rated to
> only do four megabits and I know they're going to exceed that.
>
>    I can terminate this subnet on another router, wire that device into the
> 7507 with a crossover, and establish a BGP session. I'm wondering if there
> is a tidy way to set next hop in some fashion using route-maps such that
> all the marking would be done on the auxillary machine and the traffic
> passing through the 7507 would be CEF switched rather than process
> switched.






More information about the NANOG mailing list