In the referenced message, Iljitsch van Beijnum said:
On Fri, 3 May 2002, Stephen Griffin wrote:
for single-homed customers, simple uRPF for multihomed customers, acl exceptions based upon their registered IRR-policy, since the customer should already be registering in the IRR you have a list of all networks reachable via the customer, regardless of the actual real-time announcements or policy applications (prepending, localpref tweaks, etc)
This doesn't make any sense. If you use uRPF on a customer interface, it will check the packets coming in from the customer to see if they match the prefixes you route to that customer. So as long as what you route to them and what they use as source addresses are identical, you don't have a problem.
think MEDs and localpref twiddles., identical prefixes do not necessarily relate to best paths.
For multihomed customers, these sets of prefixes should be identical, just like with single homed customers. The only time when those sets of prefixes is NOT the same is for a backup connection. But if a connection is a pure backup for incoming traffic, it's reasonable to assume it's a pure backup for outgoing traffic as well, so as long as the backup is dormant, you don't see any traffic so no uRPF problems.
Not always the case, customer behaviour can not be accurately modeled.
Using an exception access list is pretty silly: if you're going through the trouble of listing all a cutomer's prefixes in a list, you might as well just apply this acl to the interface rather than uRPF with the acl as exceptions.
the acl will only be used on packets failing the rpf check. interface acls get applied to all traffic.
There is another way to handle backups: you can also set the weight to a higher value for customer routes. This way, the router connecting to the customer will always use the routes announced by the customer, even if the rest of the network deems them inferior to another route to this customer because of a lower local pref, a higher MED or a longer AS path.
This mechanism is also useful for peering: because of the higher weight, the border router will always prefer the exchange (or private peering link) for all traffic to the customer, so uRPF works. The rest of the network can still decide to send the traffic to another exchange point.
I'm quite leery of having islands of widely divergent policy, and I wouldn't think it would help if you have multiple non-equal-cost-paths on the same router with which to accept traffic on.
for non-clued peers, accept based upon any available forwarding path [hopefully, by the 100th time you beat on the peer about spoofed crud coming from them, they'll get religion and register, since you'll have less overall spoofing to track down, you can devote it to slapping them around more]
If people stop peering with those network polluters they'll clean up their act soon enough.
This is unlikely to occur, unfortunately, so merely making it as annoying as possible for polluters and less annoying as possible for non-polluters, is probably the way to go.
you should also in/egress filter known bogons at all borders, like src/dst in rfc1918 src/dst in class e
Why? That doesn't buy you much except job security because someone spending so much time on those impressive filters can't be missed of course.
Because it is polite to not send crap to your neighbors, and advantageous to not have crap coming into your network.
src in class d (not dest, however)
Some multicast apps set the source to the group address as well.
How... odd...
Iljitsch van Beijnum