RE: Clue's for Clue-less

["Martin, Christian" <CMartin () mercury balink com>]

> 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?