somewhat unilaterally denying prefixes without verification of the

...

validity of their origin...Hmm, lets see...AS 1 sending the 4.0.0.0 netblock across a direct peering point, but it get's nicked because of max-prefix, so it comes across through a multihomed downstream and all of a sudden, sorry little multihomed downstream is carrying 200 Megs of BBN transit. Oops!

So, why would a multi-homed *downstream* be sending you *upstream* routes .... Hrrrmmmmm ?

;)

Poor filtering practices. As filter-lists grow in size and complexity, and the AS lists grow, there is the potential for leaks. All it takes is for and inexperienced/tired/clueless operator to turn up a T1 session with a multihomed downstream peer, and neglect the filter-list on their inbound updates. Then, considering that any other peer that advertises an AS that is two hops away has the same preference configured all the way through, we're talking router ID here. The OC3 session that is prefered doesn't see the routes, but they are coming in from other places, including the T1. bgp always-compare-med can help, but not everyone uses it. This can be bad. What I would like to see, though, is where the cutoff point takes place. Is it on updates, or insertions into the table? If it were updates, this would be horrible. So if the table is being pruned, where is it starting?