not rewriting next-hop, pointing default, ...

a senior engineer at a well-known provider just pointed out to us that
a weenie provider at mae-east was
  o not rewriting next-hop
  o sending our routes to others
  o sending others' routes to us
  o likely pointing default at us

their noc phone was answered by a modem. we suspended peering with them and
wrote to their noc. we got back a snotty message. we have ceased peering
with them.

we installed packet filters. our traffic on the east fddi dropped
noticeably.

when the larger providers decline to peer with the smaller, there is a sad
reason. traceroute -g is your friend.

randy

And calling (or treating) all smaller providers (as) scumbags because a few
do things which should be actionable if they're not (ie: pointing default)
is worse than the disease.

You don't fix a broken finger by cutting off the entire arm!

Yes, this situation sucks. Yes, its made worse by "smaller" providers.
But the fact remains that some of the biggest problems are caused by the
larger providers and the silly things *they* occasionally do, usually for
"cost control" reasons.

The only non-standard thing we do on occasion is prepend an extra copy of
our ASN on announcements which go out to peers or transit links which we
deem "non-optimal". I don't see that as being particularly onerous,
especially given some of those provider's abysmal track record in actually
*delivering* the packets you send their way.

In a true peer relationship situation this is a no-op unless the place
you're trying to reach is multi-homed (if there's only one path, it matters
not if there's one or three "3365"s in the path -- there's only one path to
select from, and that's it).

In a mixed peer/transit relationship situation this kind of load balancing
is extremely valuable if used with *discretion*.