aggregation & table entries
randy at psg.com
Wed Oct 13 21:53:13 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.
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
More information about the NANOG