Re: aggregation & table entries

[Randy Bush <randy () psg com>]

> > > The second is a harder problem, because of the business
> > > decisions of some providers to source packets from prefixes
> > > that they do not announce.
> > i presume you are not intending to recommend that i drop packets
> > that multi-homed customers hand me when they have also asked me
> > to de-pref the prefix from which they come?  i might be their
> > backup for inbound, but they need to balance their outbound.
> No, I'm not recommending that.

so i suspected <g>

> In the example that you give, the prefix from which the packets
> in question will be sourced *is* offered as a destination?

not by me.  but by one or more of the originator's other upstreams.
i suspect this is not uncommon.

> The problem is differentiating these two cases:
> 1. the offer of a route to a prefix is not made but packets
>    sourced in that prefix are legitimate and are expected to be
>    forwarded; the reverse path is only available through a
>    different AS
>
> 2. the source address is spoofed; packets are not legitimate and
>    should be dropped
>
> Once upon a time, I tried to enable loose-mode uRPF on a peering
> interface, effectively treating #1 as #2. The complaints were
> relatively instantaneous (at 2am local for me, a traffic-low time),
> and not localized to a specific source prefix (the majority were
> residential broadband users); I wound up turning the loose-mode uRPF
> check off in fairly short order.
>
> Attempts to discover why #1 was happening ended with technical
> people shrugging their shoulders and saying that the money people
> made them do it.

yep.  some times it is even less intentional and less understood;
see tim's paper on bgp wedgies.  and the "management made me do
it," is a bit disingenuous.  it's part of what it means to have
customers.

randy