[c-nsp] is RPF strict mode common?

Eric Van Tol eric at atlantech.net
Fri May 9 06:16:03 EDT 2008


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Mark Tinka
> Sent: Thursday, May 08, 2008 10:19 AM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] is RPF strict mode common?
>
> On Thursday 08 May 2008, Adam Greene wrote:
>
> > Trying to control bandwidth between my (2) upstream
> > Internet providers, Global Crossing (20Mbps) and Savvis
> > (50Mbps). I currently receive full routes from both, and
> > the smaller Global Crossing link is maxed out, inbound.
> >
> > The obvious solution to me will be to prepend my route
> > announcements to Global Crossing. However, one question:
> > there is a good chance that some of my traffic will flow
> > out through Savvis and in through Global Crossing (in
> > fact, that's almost certainly happening right now). Will
> > this kind of asymmetrical traffic run into issues with
> > other ISPs that deploy RPF in strict mode? Are there many
> > ISPs out there that do this? It seems that so much
> > traffic on the Internet must be asymmetrical, any ISPs
> > running RPF in strict mode must be doing so in a way that
> > will not break traffic that's asymmetrical because of
> > other ISPs' standard routing policies. IF they do, then
> > they would be causing dead spots for their own customers
> > ... do you think that's a valid assumption?

I would suggest that either instead of or in addition to prepending, you utilize the GBLX community string definitions to better control how your traffic flows:

http://www.onesc.net/communities/as3549/

Try setting the community to lower the localpref in their network so your route is less preferred.  You can also prepend to specific networks using their communities.

We use uRPF on non-multihomed customer connections.  The only "large" provider we've ever worked with that uses uRPF on multihomed customer connections is Qwest, which is not a wise idea IMO.

-evt


More information about the cisco-nsp mailing list