[c-nsp] Unicast Reverse Path Forwarding - Loose Mode

[Youssef Bengelloun-Zahr]

Hello List,

Let me bounce on this thread again as I am seriously thinking
about implementing uRPF loose mode / RTBH on our backbone. We have been
taking on some DDoS recently, Internet is a bitch ;-)

I was thinking enabling it on the interfaces towards my :

- Upstream Providers,

- Peerings,

- Virtual-template Interfaces (my clients connect on a bunch of LNS using
PPPoATM).


We have a bunch 6509s acting as core routers and a bunch of 7204VXRs
(NPE-400 / NPE-G1) acting as LNS border routers.

Problem Is : I am concerned about performance issues. Is uRPF a big consumer
of CPU / Memory ?


Do you guys have ever experienced any particulars problems ?

Does activating this feature cause BGP or PPP sessions to flap ?

Thanks for the feedback.

Best regards.

Y.



2010/4/18 Mark Tinka <mtinka at globaltransit.net>

> On Thursday 08 April 2010 08:48:39 pm Steve Bertrand wrote:
>
> > I guess what I'm trying to say is that enabling it is
> >  good,...
>
> Agree.
>
> >  and I've never run into any situation where
> >  enabling loose mode has caused problems.
>
> The only problem we've had is when peering privately with
> other networks and you ask them to ensure they don't
> announce your prefixes to the general Internet (they should
> be kept only within their AS + their [BGP] customers).
>
> Well, what happens is that when they (mistakenly, I hope)
> announce your prefixes to the Internet, they become a
> transit path back to you. But because your private peering
> router does not hold a full table, inbound traffic from some
> soul on the Internet (who is not a customer of your peering
> partner) gets dropped because a route back to said soul
> doesn't exist in your peering router.
>
> There have been many a situation like this for us, and it's
> not pretty. Be watchful of your private (and public) peers
> when running uRPF.
>
> One could announce prefixes with a NO_EXPORT community to
> the peers, but this assumes they support BGP communities.
> Also, it could potentially mean your routes won't get into
> their BGP customers' networks (which is likely not what you
> want).
>
> Alternatively, one's peering router could hold a full table,
> but there's probably more to it than just simply that.
>
> Cheers,
>
> Mark.
>
> _______________________________________________
> 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/
>



-- 
Youssef BENGELLOUN-ZAHR ………………………………………………
Ingénieur Réseaux et Télécoms


Technopole de l'Aube  en Champagne - BP 601 - 10901 TROYES  Cedex 9
Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE
Tel                 +33 (0) 825 000 720
Tel. direct      +33 (0) 1 77 35 59 14
Tel. portable  +33 (0) 6 22 42 63 80
Email            ybz at 720.fr
……………………………………………………………………………….....www.720.fr