dsl providers that will route /24

David Schwartz davids at webmaster.com
Thu Mar 29 00:57:07 UTC 2001



	I think we're in 99.9% percent agreement, which is probably about the best
you can expect between two human beings. Let me respond to one thing:

> I do have ingress/egress filtering.  I used to log all the RFC1918 crap
> coming into my network.  Unfortunately, when talking with upstream
> providers who are "leaking" these, I would always get: "not from us", or
> "can't track it, sorry", or "you are filtering it, why do you care?".
> So,
> I gave up logging and tracking it down.
>
> I also have ingress filtering to block my own addresses from coming into
> my network.  I rarely see these type of packets coming into my network,
> but when I do, I try to track them down.  Unfortunately, I usually get
> the
> same type responses as above.  No one seems to care.
>
> Because of my experience in trying to track down problems, I have come to
> be militant about egress filtering.

	I do agree with you that most large ISPs don't seem to care about what
comes out of their pipes and will just tell you that if you don't like what
you're getting from them, you should filter it. However, that doesn't mean
that you should take that same attitude with your customers.

	I do have ingress filtering to block packets with origin IP addresses
assigned to my own machines and LANs. I don't have ingress filtering on
transit or peer connections for IPs subassigned to my customers.

	Some customers might see such filtering as a service, some might see it as
a detriment that limits their own topological flexibility.

	What happens if one of your customers is multihomed, loses his link to you,
and tries to reach another one of your customers through his other ISP? Or
do you make exceptions to this filter for multihomed customers? (The problem
is, with VPNs and mobile IP schemes, every customer is potentially
multihomed.)

	IMO, this is something best done on the customer's routers. Obviously, for
your own 'local' IPs, you are the customer.

	DS





More information about the NANOG mailing list