Jeff, Initially, I thought that you were right, but on second thought I see a problem. If a peer of yours is giving someone third party routes, this filtering will blackhole traffic. While your peer should not be giving these routes with your router as the next hop, it will happen and we need a way to debug it.
Direct peering - use next-hop-self. May be problematic in that it will load your FDDI more (esp problematic if you've got a NetEdged FDDI bridge thing). RA peering - this is a bit more of an issue. Suppose A gives/sells some routes to B through the RA including those of C who B peers with through the RA. A doesn't peer with C. The RA will send C's routes to A with a next hop of C's router and they'll presumably be black holed. Obviously the simple solution in this case is for A and B not to be so ridiculous and direct peer or use a serial lead or something, but I wonder if there are other less obvious problems. One of the nasty things about filtering is that a non-obvious RA misconfiguration might lead to blackholing, possibly hurting other networks than the one responsible for the misconfig. Maybe gated can be hacked to always return the next hop of intermediate peer (B here). Mmmm... Tool for configuring filtering straight from the RA anyone? Alex Bligh Xara Networks
Erik
I din't see an answer on this one....
---------- From: Andrew Partan[SMTP:asp@partan.com] Sent: Saturday, February 01, 1997 10:55 PM To: feldman@mfst.com Cc: nanog@merit.edu Subject: Re: Alpha test of MAE filtering capability
In response to requests from several customers for a filtering solution at MAE EAST and MAE WEST, MFS WorldCom is developing an automated system to enable ISPs to control traffic destined for their own routers and networks.
Are you going to post the list of permitted/denied addresses?
Operationally it would be *very* useful to know what addresses are blocked. --asp@partan.com (Andrew Partan)