aggregation & table entries

Stephen Stuart stuart at
Wed Oct 13 21:26:32 UTC 2004

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

In the example that you give, the prefix from which the packets in
question will be sourced *is* offered as a destination? Assuming yes,
then regardless of whether that offer is selected as the best to use
to reach the destination or not, the edge router that needs to make
the decision to accept or reject packets sourced in that prefix can
use its knowledge that the offer was made to accept packets.

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.


More information about the NANOG mailing list