North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: aggregation & table entries
>>> 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
|