[c-nsp] Peering + Transit Circuits

Mark Tinka mark.tinka at seacom.mu
Tue Aug 25 08:55:13 EDT 2015

On 25/Aug/15 14:49, Brian Turnbow wrote:

> You actually need to have an aggregated acl that permits all potentially good traffic, and drops the bad, think of it  like a bogons list.
> Don't just add the routes you receive, otherwise when your friendly ixp peer starts announcing you by accident you don't create a black hole.
> It's a compromise but  will give you the chance to uRPF known bad sources (static but better than nothing at all) and have working RTBH on the router.

And that is where the effort is - what are the known bad sources (from
your point of view, nevermind your customers' point of view).

But yes, it's a compromise, and like I said before, one can enable
temporary or manual measures accordingly.

Having spent too much time troubleshooting uRPF issues on a router that
doesn't carry a full table, it's compromises all around. If only peers
didn't leak stuff, but well...


More information about the cisco-nsp mailing list