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 <[email protected]> > 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 [email protected] > 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 [email protected] ……………………………………………………………………………….....www.720.fr _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
