Update to weekly routing analysis summary
Philip Smith
pfs at cisco.com
Tue Nov 14 19:59:25 EST 2000
Hi Lee,
At 18:34 14/11/00 -0500, Lee Howard wrote:
>I'll look into it.
Great, thanks for that!
>Since I work in Install, I'll confess that it's never occurred to me that
>someone might try to announce an ASN they didn't own, or propagate an ASN
>that wasn't legitmately their customer. In a current thread on NANOG,
>somebody else pointed out that there's no benefit to it; they real owner
>will catch you and make the upstream stop routing.
Yup, if you are using someone else's. But if you are using an unallocated
ASN below the current range being allocated from by the three registries,
or one which is just below the 64512 boundary, people aren't likely to come
chasing you soon. Note the ASN57158 coming from a customer of Pacific
Internet. This isn't meant to encourage people to do this (because my spare
time hobby is to run this weekly report, and I'm watching now... ;-)
>Still, it's probably fair to say that I'm too trusting. A logical question
>then is, if a customer is propagating a bogus ASN to me, how would I stop
>it?
I agree, this was easier when networks were small, and it was easier to
spot funny goings on. Now it is harder.
>Do other folks commonly use "AS Martian" access lists? I'm not even sure
>how I would begin to compile such a list.
>for ($asn=1; $asn<65535; $asn++) { if (! &whois($asn)) {push(@martians,
>$asn);} } ## bleah
I don't think there is one, but a first cut today would be to block
ASNs >32768, maybe (I know, won't scale beyond another year)?
Also, some routers have an option to block ASNs >64511 which would help
block some of the private ASNs appearing on the Internet...
Operationally, in the past when I brought on a new customer, I'd check
their announcement on connection - if their address space and/or ASN
weren't registered, we'd go "fix" that... Ongoing monitoring - harder,
doesn't earn money, so isn't really done.
philip
--
More information about the Rtma
mailing list