Discussion:
BGP Private ASes
(too old to reply)
Arron Scott
2002-09-11 06:24:09 UTC
Permalink
Hi all,

I expect this is probably flame bait, but I keep hitting the same question
in customer-land almost every week, and wondered if there were at least a
different (if not necessarily smarter) way of dealing with the problem.
Maybe this is already been done to some extent, and maybe we just need to
formalise some of this.

Anyway ...

I get endless number of customers who want to peer with more than one ISP at
a time, usually with the intention of resiliency at both the institutional
and upstream provider levels. So what they usually want is a Public AS
number and a class C which is advertised as a long prefix to the Internet
via two upstreams such as Telecom GGI and TelstraClear, often with an
intermediary ISP as their direct peer.

Now ... what I was thinking is ... can we do this without the rare (and
increasingly difficult to obtain) Public AS numbers. Could we have a
publically agreed on pool of Private AS numbers that enterprises can use to
peer with service providers. The pool would administered by a "impartial"
group (maybe WIX/APE). The AS number would then be stripped by both
higher-order ISPs and and the IP address potentially unsuppressed by the ISP
who owns the IP address aggregate.

One possible hiccup I see is between NZ peers, and whether there would be a
problem when for instance the TelstraClear network sees the network as one
AS hop direct to the customer, and one AS hop via Telecom (and vice-versa).

However, on the otherside I also wondered whether this could be used on the
APE and WIX for customer to customer peering, providing more rapid peering
relationship growth in NZ.

Any thoughts ... or have I, in my two years of vendor-land, turned into a
BGP zombie who can no longer fathom the depths of BGPs arcane and sometimes
infuriating nuances ?

Arron Scott
***********************************************************************
Arron Scott (CCIE #4099) Phone: +64-9-3551951
Systems Engineer Mobile: +64-27-4883163
Cisco New Zealand mailto:***@cisco.com
http://www.cisco.com
***********************************************************************


-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Ewen McNeill
2002-09-11 06:59:38 UTC
Permalink
Post by Arron Scott
I get endless number of customers who want to peer with more than one ISP at
a time, usually with the intention of resiliency at both the institutional
and upstream provider levels. [... Want Class C, public AS, advertised
prefix... ]
Now ... what I was thinking is ... can we do this without the rare (and
increasingly difficult to obtain) Public AS numbers.
I'm also in touch with clients that would like to do this -- they don't
especially care about the Class C, or Public AS, etc, but they would like
some resiliency for any disconnections from their provider or routing
issues for their provider, often because they have clients that have
that as a tick-box feature.
Post by Arron Scott
Could we have a publically agreed on pool of Private AS numbers that
enterprises can use to peer with service providers. The pool would
administered by a "impartial" group (maybe WIX/APE). The AS number
would then be stripped by both higher-order ISPs and and the IP
address potentially unsuppressed by the ISP who owns the IP address aggregate.
If I'm not mistaken about what you mean, this is what WIX (the route
reflectors) are trying to do.

Enterprises on Citylink with an appropriate connection, but without
public ASes are assigned a private AS, advertise their routes to the
WIX route reflectors with that private AS, and the WIX route reflectors
then advertises those to all other peers. APE may also have a similar
setup, but my impression is that APE is mostly bilaterial peering,
and it's mostly treated as a peering point, rather than a multilateral
route exchange.

The WIX approach seems to work, but:
- it appears some providers do not peer with the WIX route reflectors,
or do so only to advertise their routes, not to allow in extra routes

- most providers filter "long" prefixes (and most enterprises without
public ASes tend to have only long prefixes). Certainly it's my
impression that pretty much all providers filter anything longer than
/24, and some appear to even filter /24, /23, /22, etc, meaning the
prefixes advertised by enterprises are likely to be filtered.

So from an enterprise point of view WIX (the route reflectors) are useful
for picking up direct routes to providers POPs, but this tends to lead to
asymetric routes to/from the providers (and hence no real resiliency).

And it's useful for enterprise to enterprise peering (indeed one of my
clients connected to the WIX route reflectors soley for the enterprise
to enterprise peering; at the request of the other enterprise).

The WIX route reflectors (according to the route table on a router
peering with them) appears to have about 50 systems peering with it
at present.

But without providers willing to (a) peer with the route reflectors, and
(b) accept long prefixes (at least locally), it's probably not going to
be of general use for resiliency.

To be of much general use providers would have to be willing to at least
accept /24 prefixes locally, even if they're part of a larger supernet
advertised by another provider. Longer prefixes would be desirable,
because otherwise anyone wanting resilency with CIDR space would need
to beg for a class-C sized CIDR chunk.

Simon Blake (Citylink) could probably speak more about what WIX's route
reflectors do, and how well it's worked (or not worked) in practice.

Ewen
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Simon Blake
2002-09-11 23:02:45 UTC
Permalink
Crikey, a bunch of on topic posts in a row. I didn't realise it was
possible...
Post by Ewen McNeill
Post by Arron Scott
I get endless number of customers who want to peer with more than one ISP at
a time, usually with the intention of resiliency at both the institutional
and upstream provider levels. [... Want Class C, public AS, advertised
prefix... ]
Now ... what I was thinking is ... can we do this without the rare (and
increasingly difficult to obtain) Public AS numbers.
Yes. There are several WIX customers doing this - it's a common(ish)
thing to do on Citylink, since generally the second (third, nth) ISP can
be reached without an increase in line costs. It's particularly common
to a single provider (ie, a customer has multiple routers peering with
(possibly) multiple routers within an upstream ISP) to provide
redundancy over Citylink, but it presumably would work ok with multiple
ISP's.
Post by Ewen McNeill
I'm also in touch with clients that would like to do this -- they don't
especially care about the Class C, or Public AS, etc, but they would like
some resiliency for any disconnections from their provider or routing
issues for their provider, often because they have clients that have
that as a tick-box feature.
Presumably, without a /24 you're not going to get international
redundancy, regardless of what agreements you get betwixt ISP's in NZ.
OTOH, we're increasingly seeing customers more interested in improving
their NZ connectivity, and this would help them, even with smaller
prefixes.
Post by Ewen McNeill
Post by Arron Scott
Could we have a publically agreed on pool of Private AS numbers that
enterprises can use to peer with service providers. The pool would
administered by a "impartial" group (maybe WIX/APE).
We already run private ASN's with about 50 peers, and have gentle
arrangements with some of the other ISP's about allocating out of the
private ASN space. We'd be happy to help out with ASN allocation if
there was interest.
Post by Ewen McNeill
Post by Arron Scott
The AS number
would then be stripped by both higher-order ISPs and and the IP
address potentially unsuppressed by the ISP who owns the IP address aggregate.
If I'm not mistaken about what you mean, this is what WIX (the route
reflectors) are trying to do.
Enterprises on Citylink with an appropriate connection, but without
public ASes are assigned a private AS, advertise their routes to the
WIX route reflectors with that private AS, and the WIX route reflectors
then advertises those to all other peers.
More or less - WIX/APE route servers filter default routes, so generally
if route server peers are after redundancy between ISP's, they still
need to peer directly with the ISP's in question. The Citylink route
servers are about optimising traffic across APE and WIX, and reducing
the load on ISP's who can't be arsed maintaining n peering seesions
(where n is now over 20). They're not the tool of choice for
redundancy off APE/WIX - that really should be organised with direct
peering sessions between providers and their customers.

We're happy to help grease that relationship though.
Post by Ewen McNeill
APE may also have a similar
setup, but my impression is that APE is mostly bilaterial peering,
and it's mostly treated as a peering point, rather than a multilateral
route exchange.
Joe Abley
2002-09-11 15:42:41 UTC
Permalink
Post by Arron Scott
I get endless number of customers who want to peer with more than one ISP at
a time, usually with the intention of resiliency at both the institutional
and upstream provider levels. So what they usually want is a Public AS
number and a class C which is advertised as a long prefix to the Internet
via two upstreams such as Telecom GGI and TelstraClear, often with an
intermediary ISP as their direct peer.
APNIC have a policy for allocating long-prefix netblocks for the
purposes of multi-homing:

http://www.apnic.net/docs/policy/add-manage-policy.html#11.1

Alternatively, it's common practice to accept a provider-aggregatable
delegation from one provider, and arrange for that long-prefix route
to be advertised in addition to its covering supernet (so that it can
also be advertised through a different transit provider).

So the address space part is a non-issue.
Post by Arron Scott
Now ... what I was thinking is ... can we do this without the rare (and
increasingly difficult to obtain) Public AS numbers.
APNIC members can obtain ASNs for their customers at no cost beyond
the membership fees they already pay. It takes about four days.
They are not at all difficult to obtain. I happen to know that at
least one of the providers you mentioned is extremely familiar and
well-practiced at this process :)
Post by Arron Scott
Could we have a
publically agreed on pool of Private AS numbers that enterprises can use to
peer with service providers. The pool would administered by a "impartial"
group (maybe WIX/APE). The AS number would then be stripped by both
higher-order ISPs and and the IP address potentially unsuppressed by the ISP
who owns the IP address aggregate.
There is no need for it (and there is no "impartial group" called
WIX/APE, unless you are talking about Citylink).


Joe
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Gordon Smith
2002-09-11 19:52:41 UTC
Permalink
Hi Aaron,

I see that Joe has already mentioned that getting an AS for a customer
isn't a big deal.
The customer can have address space supplied by either provider, or get
their own.

Issuing private AS's then stripping them on our side would be adding
another layer of complexity that isn't really necessary. The customer
doesn't even need to talk BGP, unless they're providing services to the
outside e.g. web or mail server.

Vincent Jones has written a very good book that addresses this issue
well - "High Availability Networking with Cisco". He's also a regular in
the newsgroup comp.dcom.sys.cisco and seems to be more than happy to
answer questions.

Cheers,
Gordon


-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Ewen McNeill
2002-09-11 20:19:30 UTC
Permalink
Andy Linton sent me this response, which he tells me he intended for
nznog as well. Below is Andy's response, and then my reply to Andy's
response. Both are at least as relevant to the list as discussing Klez
all day :-)
Post by Ewen McNeill
Post by Arron Scott
I get endless number of customers who want to peer with more than one ISP at
a time, usually with the intention of resiliency at both the institutional
and upstream provider levels. [... Want Class C, public AS, advertised
prefix... ]
Now ... what I was thinking is ... can we do this without the rare (and
increasingly difficult to obtain) Public AS numbers.
There are proposals to increase the size of the AS numbers from 16 to 32
bits but that soesn't solve the immediate difficulties in getting an AS
number.
Post by Ewen McNeill
I'm also in touch with clients that would like to do this -- they don't
especially care about the Class C, or Public AS, etc, but they would like
some resiliency for any disconnections from their provider or routing
issues for their provider, often because they have clients that have
that as a tick-box feature.
I've heard some very interesting discussions about flap damping at the
RIPE meeting this week. See http://psg.com/~randy/020910.zmao-flap.pdf.
The important thing to note is that the thing that is damped is prefixes
so dual homing may not give you all you hope for if flap damping is in
use.
Post by Ewen McNeill
Post by Arron Scott
Could we have a publically agreed on pool of Private AS numbers that
enterprises can use to peer with service providers. The pool would
administered by a "impartial" group (maybe WIX/APE). The AS number
would then be stripped by both higher-order ISPs and and the IP
address potentially unsuppressed by the ISP who owns the IP address aggregate.
If I'm not mistaken about what you mean, this is what WIX (the route
reflectors) are trying to do.
Dean Pemberton and I have been talking with Simon about trying to get WIX
and APE whois servers running so that people could start registering
routes and AS policy for RPSL use in NZ. Using these to allocate locally
scoped private ASes for use on the WIX and APE would be a doddle.
Post by Ewen McNeill
- it appears some providers do not peer with the WIX route reflectors,
or do so only to advertise their routes, not to allow in extra routes
- most providers filter "long" prefixes (and most enterprises without
public ASes tend to have only long prefixes). Certainly it's my
impression that pretty much all providers filter anything longer than
/24, and some appear to even filter /24, /23, /22, etc, meaning the
prefixes advertised by enterprises are likely to be filtered.
It seems difficult to believe that the relatively small additional number
of prefixes being announced by the enterprises on the WIX is significant.
The total number of prefixes is around the 250 mark and many of those come
from the "providers" anyway. Filtering out the few dozen prefixes that are
/25 or greater would seem to have little impact on table size and the
kosher ones could easily handled in a prefix-list.
Post by Ewen McNeill
So from an enterprise point of view WIX (the route reflectors) are useful
for picking up direct routes to providers POPs, but this tends to lead to
asymetric routes to/from the providers (and hence no real resiliency).
So it would be nice to get the providers to use them. Some of them resist
but surely this is an issue that could be driven by their respective
customers. E.g. "As my provider I need you to provide a resilient
efficient local mesh at WIX and APE. Perhaps I should consider moving to a
provider who...."
Post by Ewen McNeill
And it's useful for enterprise to enterprise peering (indeed one of my
clients connected to the WIX route reflectors soley for the enterprise
to enterprise peering; at the request of the other enterprise).
The WIX route reflectors (according to the route table on a router
peering with them) appears to have about 50 systems peering with it
at present.
But without providers willing to (a) peer with the route reflectors, and
(b) accept long prefixes (at least locally), it's probably not going to
be of general use for resiliency.
To be of much general use providers would have to be willing to at least
accept /24 prefixes locally, even if they're part of a larger supernet
advertised by another provider. Longer prefixes would be desirable,
because otherwise anyone wanting resilency with CIDR space would need
to beg for a class-C sized CIDR chunk.
See above

---------------------------------------------------------------------------
Post by Ewen McNeill
Post by Arron Scott
I'm also in touch with clients that would like to do this [advertise
their blocks to multiple providers for resiliency]
I've heard some very interesting discussions about flap damping at the
RIPE meeting this week. [...] The important thing to note is that the
thing that is damped is prefixes so dual homing may not give you all
you hope for if flap damping is in use.
For both the clients I have in mind most of their benefits would be
gained in about the first 5 hops or so (ie, within New Zealand), as that
is the main market they're serving. So how important flap damping was
to that would largely depend on how soon it was applied.
Post by Ewen McNeill
Dean Pemberton and I have been talking with Simon about trying to get WIX
and APE whois servers running so that people could start registering
routes and AS policy for RPSL use in NZ. Using these to allocate locally
scoped private ASes for use on the WIX and APE would be a doddle.
This would definitely be a good thing. RPSL (from your talk at the
Uniforum conference) looks like a Good Thing (tm), and a whole lot more
sensible than the alternatives (yet more prefix listson nznog!).

Scoped private ASes would also solve the immediate problem -- probably
for Aaron too (hence my suggestion you mention this on nznog, and/or
directly to Aaron).
Post by Ewen McNeill
It seems difficult to believe that the relatively small additional number
of prefixes being announced by the enterprises on the WIX is significant.
WIX is worth about 300 prefixes or so on an average day, and "generally"
includes the POPs of most NZ providers. For an organisation hosting
a lot of content, there's definitely a win for them in sending traffic
"directly" to the POPs (and bypassing the ticket counter at their ISP
:-) ).

If those routes were symmetric, then there'd also be a resiliency win.
Post by Ewen McNeill
The total number of prefixes is around the 250 mark and many of those come
from the "providers" anyway. Filtering out the few dozen prefixes that are
/25 or greater would seem to have little impact on table size and the
kosher ones could easily handled in a prefix-list.
Last I spoke to Simon about it, he was starting to put filters in on the
expected prefixes from each peer with the WIX route reflectors -- which
would make it possible to have a pretty "exact" set of expected
prefixes.

There are 27 prefixes in WIX (right now) longer than /24. Some of them
are as long as /30s, and there's a bunch of /29s.

One of the clients I have in mind has a /27 CIDR block. They're
starting to run out of public address space (despite using RFC1918
everywhere it can be used, and lots of NAT), and will probably try
asking for more space. But even that more space is likely to be only
another /28, another /27, or maybe if they're very lucky one /26.

My point here is that while there might not be very many prefixes longer
than /25 in WIX now, that's sort of a self-fulfilling prohpehcy, because
prefixes longer than /24 (or /23, /22, /21, etc -- I haven't managed to
find out what's considered "best practice" by NZ providers) are being
filtered out already by lots of people. So "what's the point?".

If the answer is "everyone use RPSL, and persuade people to accept all
properly described RPSL lists" then I'm all for it. If the answer is
"only providers get to do peering", then that's tantamount to "only
people with public ASes get to do peering". And may well lead to a
bunch of people chasing public ASes (and provider independant space for
that matter) when they don't otherwise need them.

Ewen
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Joe Abley
2002-09-11 21:10:39 UTC
Permalink
Post by Ewen McNeill
[...]
Dean Pemberton and I have been talking with Simon about trying to get
WIX
and APE whois servers running so that people could start registering
routes and AS policy for RPSL use in NZ.
Just out of interest, what's the benefit in running yet another RPSL
database?
Post by Ewen McNeill
Using these to allocate locally
scoped private ASes for use on the WIX and APE would be a doddle.
Run and hide! There's no reason to break RFC1930. That makes things
difficult and confusing, whereas obtaining a globally-unique ASN is
simple and easy.
Post by Ewen McNeill
[...]
So it would be nice to get the providers to use them. Some of them
resist
but surely this is an issue that could be driven by their respective
customers. E.g. "As my provider I need you to provide a resilient
efficient local mesh at WIX and APE. Perhaps I should consider moving
to a
provider who...."
... is willing to surrender control of her routing policy to a
best-effort coordination service with no responsibility for the quality
of the routing data sent to or from her network?
Post by Ewen McNeill
One of the clients I have in mind has a /27 CIDR block. They're
starting to run out of public address space (despite using RFC1918
everywhere it can be used, and lots of NAT), and will probably try
asking for more space. But even that more space is likely to be only
another /28, another /27, or maybe if they're very lucky one /26.
Tell your client that a requirement to multi-home (whether to multiple
transit providers, or to a single transit providers and multiple peers)
is adequate justification for being allocated a /24 netblock from their
transit provider. Ask, and it will be given.
Post by Ewen McNeill
If the answer is "everyone use RPSL, and persuade people to accept all
properly described RPSL lists" then I'm all for it. If the answer is
"only providers get to do peering", then that's tantamount to "only
people with public ASes get to do peering". And may well lead to a
bunch of people chasing public ASes (and provider independant space for
that matter) when they don't otherwise need them.
If you want to multi-home using BGP, and you don't want to violate
RFC1930, you need a globally-unique ASN. ASNs are not just allocated to
providers. So, only people with public ASNs get to do peering, but that
doesn't mean that only providers get to do peering.

None of this is new. In fact, there was enough of this going on when I
was still involved in AS4768 that I *documented* it:

http://www.clear.net.nz/documentation/dedicated/multi.html

Some of those documents are old enough that they have NZIX in their
diagrams :)


Joe

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
James Tyson
2002-09-11 21:37:56 UTC
Permalink
Post by Joe Abley
Post by Ewen McNeill
Dean Pemberton and I have been talking with Simon about trying to get
WIX
and APE whois servers running so that people could start registering
routes and AS policy for RPSL use in NZ.
Just out of interest, what's the benefit in running yet another RPSL
database?
Infact, it might be a very good idea to host an RPSL database in New
Zealand, and ask the nice folks at Merit to mirror it.

If only for such reasons as having nice fast access to the DB, and
having it run by someone you trust.

Moebius Systems is more than happy to run said irrd server in NZ on one
of our servers if that's what needs to happen to organise the routing in
NZ a little more.

WRT private AS', I am not sure if this is a good idea, however I am also
not sure that asking enterprises to get their own globally unique AS
number is a good (or responsible) thing to do either. Perhaps we can
form a "working group" (not the InternetNZ sense, the NZNOG sense, where
we all go out for curry and beer) to discuss a standard for this sort of
thing within NZ. I know this sounds yuck, but what about carefully
controlled IGP's or maybe funky use of confederations?

There is also one more way of acquiring /24 address space that hasn't
been mentioned. We acquired the remnants of a company with one :)
--
Cheers.

James Tyson ---
Samizdat New Media Solutions
Simon Blake
2002-09-11 22:02:10 UTC
Permalink
Post by Joe Abley
Just out of interest, what's the benefit in running yet another RPSL
database?
WIX has 50+ private ASN peers, AFAIK you can't put info about private
ASN into the public RPSL services, so if you want the value RPSL
provides for private ASN (and I ohh so do), you run your own database.
Post by Joe Abley
Post by Ewen McNeill
efficient local mesh at WIX and APE. Perhaps I should consider moving to a
provider who...."
... is willing to surrender control of her routing policy to a
best-effort coordination service with no responsibility for the quality
of the routing data sent to or from her network?
Oh for crying out loud.

Four years ago, we started agressively filtering incoming advertisments
on WIX from new peers. Three years ago, we had filter lists in place
for *every* *single* *peer*. New peers are independantly vetted (I
check with their upstreams that what they want to advertise is
plausible). We are no longer just "best efforts", and have not been for
many years, conversely, we haven't had a routing catastrophe for years
either. I've pointed this out several times on NZNOG, and yet you
continue to assert that it's not the case.

<sigh>

Cheers
Si
Post by Joe Abley
Post by Ewen McNeill
One of the clients I have in mind has a /27 CIDR block. They're
starting to run out of public address space (despite using RFC1918
everywhere it can be used, and lots of NAT), and will probably try
asking for more space. But even that more space is likely to be only
another /28, another /27, or maybe if they're very lucky one /26.
Tell your client that a requirement to multi-home (whether to multiple
transit providers, or to a single transit providers and multiple peers)
is adequate justification for being allocated a /24 netblock from their
transit provider. Ask, and it will be given.
Post by Ewen McNeill
If the answer is "everyone use RPSL, and persuade people to accept all
properly described RPSL lists" then I'm all for it. If the answer is
"only providers get to do peering", then that's tantamount to "only
people with public ASes get to do peering". And may well lead to a
bunch of people chasing public ASes (and provider independant space for
that matter) when they don't otherwise need them.
If you want to multi-home using BGP, and you don't want to violate
RFC1930, you need a globally-unique ASN. ASNs are not just allocated to
providers. So, only people with public ASNs get to do peering, but that
doesn't mean that only providers get to do peering.
None of this is new. In fact, there was enough of this going on when I
http://www.clear.net.nz/documentation/dedicated/multi.html
Some of those documents are old enough that they have NZIX in their
diagrams :)
Joe
-
unsubscribe nznog
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Joe Abley
2002-09-11 22:48:08 UTC
Permalink
Post by Simon Blake
Post by Joe Abley
Just out of interest, what's the benefit in running yet another RPSL
database?
WIX has 50+ private ASN peers, AFAIK you can't put info about private
ASN into the public RPSL services, so if you want the value RPSL
provides for private ASN (and I ohh so do), you run your own database.
... or you use globally-unique ASNs. Using private ASNs for non-private
applications is surely broken, especially when it's so trivial to
obtain a globally-unique one.

You might argue that it's inefficient use of a finite resource for
enterprises (in the AS1918 sense) that are not transit providers
to be allocated globally-unique ASNs, and I might agree with you.
That's not a problem that's going to be solved in New Zealand,
though; that's a problem that will be managed by IANA and the RIRs
with allocation policies until someone comes up with a multi-homing
and routing system that scales better than the one we have.
Post by Simon Blake
Post by Joe Abley
Post by Ewen McNeill
efficient local mesh at WIX and APE. Perhaps I should consider moving to a
provider who...."
... is willing to surrender control of her routing policy to a
best-effort coordination service with no responsibility for the quality
of the routing data sent to or from her network?
Oh for crying out loud.
I'm not talking about ingress filtering done by the WIX route servers.
By "responsibility for the quality", I mean:

+ having a route propagation path which is different to the packet
forwarding path, which is a general problem of route servers on
non-trivial layer-2 exchange fabrics;

+ having no contract/support relationship/whatever between operators
connected to the route server, which is a general problem of
multi-lateral peering.

As to the "best-effort" bit, I thought you were; sorry if that's not
the case.
Post by Simon Blake
I've pointed this out several times on NZNOG, and yet you
continue to assert that it's not the case.
Nope. I don't remember making any comments ever about what ingress
policy you were using for the route servers. I do remember making
comments about it being generally hard for *other* people to come
up with a sensible ingress policy for their session to the route
server, though, which is quite different.

Lots of people find your route servers useful, and that's great.
They *are* useful.

I was objecting to the idea that operators who don't use the route
servers must be bad or stupid, or be otherwise unworthy of attracting
customers, because I don't think that's reasonable; there are
arguments for not using them, just as there are arguments *for*
using them.


Joe
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Simon Blake
2002-09-11 23:39:07 UTC
Permalink
Post by Joe Abley
Post by Simon Blake
Post by Joe Abley
Just out of interest, what's the benefit in running yet another RPSL
database?
WIX has 50+ private ASN peers, AFAIK you can't put info about private
ASN into the public RPSL services, so if you want the value RPSL
provides for private ASN (and I ohh so do), you run your own database.
... or you use globally-unique ASNs. Using private ASNs for non-private
applications is surely broken, especially when it's so trivial to
obtain a globally-unique one.
Philip Smith
2002-09-12 13:07:29 UTC
Permalink
Post by Arron Scott
The reason I mentioned this ... non-RFC compliant idea in the first place,
was the number of comments I get from customers who state that the cost and
ease of obtaining the AS number is not as Joe says "trivial". It costs a
fair bit of money and takes a fair bit of time.
Hmmm, throughout Asia, any organisation who has complained about it being
difficult to get any resources from APNIC usually has not tried. Just want
to reiterate Joe's experience - it really isn't that hard, and that's the
feedback I get when people who said it was hard actually tried.

There are two ways of getting an ASN from APNIC: from my multihoming
tutorial at the last APNIC conference
(www.apnic.net/meetings/14/programme/docs/bgp-tut-slides-pfs.pdf) these are:

- existing APNIC member - fill up
http://ftp.apnic.net/apnic/docs/asn-request - costs nothing more than you
already pay
- become an APNIC member (takes some time, and money), then do the above
- apply as a non-member -
http://www.apnic.net/member/non-member-application.html - cost US$500,
annual US$50.

Using a private ASN for multihoming of a customer between two ISPs works
just fine so long as the two ISPs actually agree that the ASN can be used
for that. In my past life I've done that, it's worked. But it definitely
falls into the category of "unnecessary" - that's what public ASNs are for.
Post by Arron Scott
I also wanted to say that even though NZ isn't going to fix the global AS
number crisis, NZ is not excused from thinking about opportunities to help,
if some minor bending of 1930 allows us to do that, then we can at least
consider it.
What global ASN crisis?
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-05.txt fixes
that one, hopefully. :-)
Post by Arron Scott
Thanks for everyone's input, the question I am left with is ... if customer
X designing their network with our Routers asks me how to multihome to 2
ISPs, do I say go and talk to APNIC first or forget it, or do I say, the
ISPs have jointly agreed on a method of using Private AS numbers, go and
talk to them about how it's done ? If we just want to make it happen I would
be happy to offer a suitable forum to thrash it out (the three critical
components being Beer/Pizza/Chairs). If not I rest my case ... thanks again
Go to upstreams - if either is an APNIC member, they get the ASN for them.
As per Joe's example, it takes little time, costs nothing, or close to
nothing (if the upstream chooses to charge).

If upstreams refuse, or are not APNIC/ARIN/RIPE NCC members, the org has
the two choices I highlighted above.

If they still find they are having problems, let me know, and I will be
more than happy to follow up.

hth,

philip
--

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Arron Scott
2002-09-12 01:04:40 UTC
Permalink
The reason I mentioned this ... non-RFC compliant idea in the first place,
was the number of comments I get from customers who state that the cost and
ease of obtaining the AS number is not as Joe says "trivial". It costs a
fair bit of money and takes a fair bit of time.

I also wanted to say that even though NZ isn't going to fix the global AS
number crisis, NZ is not excused from thinking about opportunities to help,
if some minor bending of 1930 allows us to do that, then we can at least
consider it.

The hippocritical part of my proposal is actually the address space
requirements, in which I see no easy option other than the allocation of
/24's as suggested by Joe. These are easier to come by, and justify as it is
often done through the ISP, removing that complexity from the end-user.

Thanks for everyone's input, the question I am left with is ... if customer
X designing their network with our Routers asks me how to multihome to 2
ISPs, do I say go and talk to APNIC first or forget it, or do I say, the
ISPs have jointly agreed on a method of using Private AS numbers, go and
talk to them about how it's done ? If we just want to make it happen I would
be happy to offer a suitable forum to thrash it out (the three critical
components being Beer/Pizza/Chairs). If not I rest my case ... thanks again

Arron

***********************************************************************
Arron Scott (CCIE #4099) Phone: +64-9-3551951
Systems Engineer Mobile: +64-27-4883163
Cisco New Zealand mailto:***@cisco.com
http://www.cisco.com
***********************************************************************


-----Original Message-----
From: owner-***@list.waikato.ac.nz
[mailto:owner-***@list.waikato.ac.nz]On Behalf Of Joe Abley
Sent: Thursday, 12 September 2002 10:48 a.m.
To: Simon Blake
Cc: ***@list.waikato.ac.nz
Subject: Re: BGP Private ASes
Post by Simon Blake
Post by Joe Abley
Just out of interest, what's the benefit in running yet another RPSL
database?
WIX has 50+ private ASN peers, AFAIK you can't put info about private
ASN into the public RPSL services, so if you want the value RPSL
provides for private ASN (and I ohh so do), you run your own database.
... or you use globally-unique ASNs. Using private ASNs for non-private
applications is surely broken, especially when it's so trivial to
obtain a globally-unique one.

You might argue that it's inefficient use of a finite resource for
enterprises (in the AS1918 sense) that are not transit providers
to be allocated globally-unique ASNs, and I might agree with you.
That's not a problem that's going to be solved in New Zealand,
though; that's a problem that will be managed by IANA and the RIRs
with allocation policies until someone comes up with a multi-homing
and routing system that scales better than the one we have.
Post by Simon Blake
Post by Joe Abley
Post by Ewen McNeill
efficient local mesh at WIX and APE. Perhaps I should consider moving
to a
provider who...."
... is willing to surrender control of her routing policy to a
best-effort coordination service with no responsibility for the quality
of the routing data sent to or from her network?
Oh for crying out loud.
I'm not talking about ingress filtering done by the WIX route servers.
By "responsibility for the quality", I mean:

+ having a route propagation path which is different to the packet
forwarding path, which is a general problem of route servers on
non-trivial layer-2 exchange fabrics;

+ having no contract/support relationship/whatever between operators
connected to the route server, which is a general problem of
multi-lateral peering.

As to the "best-effort" bit, I thought you were; sorry if that's not
the case.
Post by Simon Blake
I've pointed this out several times on NZNOG, and yet you
continue to assert that it's not the case.
Nope. I don't remember making any comments ever about what ingress
policy you were using for the route servers. I do remember making
comments about it being generally hard for *other* people to come
up with a sensible ingress policy for their session to the route
server, though, which is quite different.

Lots of people find your route servers useful, and that's great.
They *are* useful.

I was objecting to the idea that operators who don't use the route
servers must be bad or stupid, or be otherwise unworthy of attracting
customers, because I don't think that's reasonable; there are
arguments for not using them, just as there are arguments *for*
using them.


Joe
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Joe Abley
2002-09-12 01:16:38 UTC
Permalink
Post by Joe Abley
+ having a route propagation path which is different to the packet
forwarding path, which is a general problem of route servers on
non-trivial layer-2 exchange fabrics;
Sure, but that's an equally good arguement for fixing the exchange
fabric, since if you're under some kind of partial reachability cloud,
then you're not getting full value for your connection anyway.
Right.

The issue arises when there is a functional layer-2 path from the
route-server to your router, but no functional layer-2 path from your
router to the next-hop address for particular routes you learn from the
route server.

In those circumstances you will black-hole traffic across the exchange
instead of losing the route and sending the traffic by some other path
(which is what would happen if you only learnt routes directly from the
other operator's router, with no route server involved).

It's a failure mode thing, not a value for money thing.
Post by Joe Abley
+ having no contract/support relationship/whatever between operators
connected to the route server, which is a general problem of
multi-lateral peering.
Sure. We have various contracts available if people want to look at
them, but generally, people don't. Funny, that :-).
There is no contract between ISP A and ISP B who receive each others'
routes from the route server, though. That's what I was getting at.
That's important to some people, and not just for
lawyers-run-the-company, my-hair-is-pointy reasons.
Post by Joe Abley
I was objecting to the idea that operators who don't use the route
servers must be bad or stupid, or be otherwise unworthy of attracting
customers, because I don't think that's reasonable; there are
arguments for not using them, just as there are arguments *for*
using them.
Undoubtedly. I just think the arguements for peering with the route
servers are significantly stronger than the arguements for not peering
with the route servers, but then I'm biased :-).
I am not anti-route-server, on APE or WIX or elsewhere; I just don't
think they have universal application. I have set up networks that use
the APE route server, and I have also helped set policy in other
networks which involved deliberately not connecting to the route server.

I ordered the ASNs for the APE and WIX route servers, back in the day.
I wouldn't have necessarily bothered if I thought they were a bad idea
:)


Joe

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Simon Blake
2002-09-12 01:59:46 UTC
Permalink
Post by Joe Abley
Post by Joe Abley
+ having a route propagation path which is different to the packet
forwarding path, which is a general problem of route servers on
non-trivial layer-2 exchange fabrics;
Sure, but that's an equally good arguement for fixing the exchange
fabric, since if you're under some kind of partial reachability cloud,
then you're not getting full value for your connection anyway.
Right.
The issue arises when there is a functional layer-2 path from the
route-server to your router, but no functional layer-2 path from your
router to the next-hop address for particular routes you learn from the
route server.
In those circumstances you will black-hole traffic across the exchange
instead of losing the route and sending the traffic by some other path
(which is what would happen if you only learnt routes directly from the
other operator's router, with no route server involved).
It's a failure mode thing, not a value for money thing.
Well, that's debatable - it's still broken, you're not getting value for
money, and if the L2 connection over the exchange between the two ISP's
is the only path between them, then you're still screwed. I think my
observation still stands - if your L2 infrastructure is broken such that
you don't have reachability between points A and B on that
infrastructure, then that is the real problem, and that's what has to be
fixed.

What we're really discussing is whether the advantages the route
servers bring in normal operation is outweighed by the disadvantages
when the L2 exchange goes pear shaped. I think the advantages are
greater (because experience tells me that the NZ L2 exchanges are
reliable), you think the disadvantages are greater (presumably
coz you've seen exchanges elsewhere go mental). I don't think you can
broad brush the arguement either way.
Post by Joe Abley
There is no contract between ISP A and ISP B who receive each others'
routes from the route server, though. That's what I was getting at.
That's important to some people, and not just for lawyers-run-the-company,
my-hair-is-pointy reasons.
Again, I'm interested in the local, specific cases, rather than in
general contract theory :-). I fully agree that some peers may want to
have contracts between each other, and the associated bilateral
peering, and I've no problem with that whatsoever. That doesn't mean,
however, that route servers are immediately removed from the
discussion, it just means ISP's have different policies for routes
learnt from the route server vs from bilateral peers.

It is, as always, a value thing - you're getting a bunch of routes with
little effort from the route servers - how much value do you get from
that, vs the effort involved with initiating bilateral contractural
arrangements with specific providers. How much do you trust the routes
from each source? How important do you rank the need for legal comeback
if stuff goes wonky?

Each provider gets to make their own judgements on these things.
Post by Joe Abley
I ordered the ASNs for the APE and WIX route servers, back in the day.
Not strictly - I obtained the WIX ASN by mine own fair hand, it was the
APE one you obtained (and for which we are eternally grateful, since it
doesn't cost us anything :-).
Post by Joe Abley
I wouldn't have necessarily bothered if I thought they were a bad idea
Nor I :-).

Cheers
Si
-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Joe Abley
2002-09-12 01:21:35 UTC
Permalink
Post by Arron Scott
The reason I mentioned this ... non-RFC compliant idea in the first
place,
was the number of comments I get from customers who state that the
cost and
ease of obtaining the AS number is not as Joe says "trivial". It costs
a
fair bit of money and takes a fair bit of time.
I ordered an ASN for a project I'm working on, just the other day. I
asked my transit provider in NZ, who is an APNIC member, to put the
application in to APNIC. It took two e-mails, four working days, and
zero dollars.
Post by Arron Scott
Thanks for everyone's input, the question I am left with is ... if
customer
X designing their network with our Routers asks me how to multihome to
2
ISPs, do I say go and talk to APNIC first or forget it, or do I say,
the
ISPs have jointly agreed on a method of using Private AS numbers, go
and
talk to them about how it's done ?
The "RFC1930-bending" is a solution looking for a problem.


Joe

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Joe Abley
2002-09-12 02:08:58 UTC
Permalink
Post by Simon Blake
Post by Joe Abley
I ordered the ASNs for the APE and WIX route servers, back in the day.
Not strictly - I obtained the WIX ASN by mine own fair hand, it was the
APE one you obtained (and for which we are eternally grateful, since it
doesn't cost us anything :-).
Ah, you're right. Sorry :)

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Lin Nah
2002-09-12 05:51:11 UTC
Permalink
Post by James Tyson
form a "working group" (not the InternetNZ sense, the NZNOG sense, where
we all go out for curry and beer) to discuss a standard for this sort of
thing within NZ. I know this sounds yuck, but what about carefully
So how many are showing up for Curry and beer tonight?

Tonight in Auckland: http://auckland.thursdaynightcurry.com/
And other cities info can be found at Wellington, Melbourne, Sydney,
and San Francisco . Thought not quite sure if convo at other cities
apart from auck and wgtn would be fruitful.

grin
Lin

-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Andy Linton
2002-09-12 07:12:12 UTC
Permalink
I meant to post to all concerned. Do you want to forward my mail and your
response to get this rolling again?
Done. Joe Abley seems to be suggesting that public ASes can be obtained
(at least by providers for their customers) for the purposes that Aaron
is talking about, perhaps along with provider independent space with a
long prefix. But something tells me that won't scale to everyone on
Citylink getting provider independent space and their own AS...
I agree with Joe that it is possible to get a public AS and some address
space for mulithoming but we'd be talking about a 50% increase in NZ's AS
number assignment. (APNIC have currently allocated 89 AS numbers to NZ +
some earlier allocations from the US registries and we'd need 42+ private
AS replacements for Citylink alone).

The policy for AS numbers is effectively described at
http://www.apnic.net/docs/drafts/apnic-draft-asn-v002.txt

The problem I see with say Citylink customers applying under this schema
is that assigning them an AS number does nothing to reduce the size of
global address tables and the number will not be used to describe diverse
routes in the global routing fabric. So private AS numbers seem like the
'right thing'. Where people really do want to multihome for global
connectivity there is a mechanism - see the above and for multihoming IPv4
address space see http://www.apnic.net/info/faq/multihoming_faq.html

But people should note - there is a cost in dollars and renumbering
effort.


-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Andy Linton
2002-09-12 07:12:21 UTC
Permalink
Post by James Tyson
Post by Joe Abley
Post by Ewen McNeill
Dean Pemberton and I have been talking with Simon about trying to get
WIX
and APE whois servers running so that people could start registering
routes and AS policy for RPSL use in NZ.
Just out of interest, what's the benefit in running yet another RPSL
database?
Infact, it might be a very good idea to host an RPSL database in New
Zealand, and ask the nice folks at Merit to mirror it.
Let me nail my colours to the mast. My preference is not to run a local
database. APNIC has recently made the transition to RIPE V3 code and have
highly available and fast servers in Brisbane. This data is mirrored at
RIPE. The servers in Brisbane are around 90ms away. They will have full
support for the relevant RPSL objects in the next few months - the
database already supports these - hostmaster training is currently in
progress.

Dean and I have only discussed running a local service because we were
concerned that local resistance to using a remote service might slow
progress. IFF we run a database it would be with the goal of using it as a
transition step.
Post by James Tyson
If only for such reasons as having nice fast access to the DB, and
having it run by someone you trust.
See above - I think this access is fast enough and I think APNIC can be
trusted. They're also roughly in the same time zone and people are in
general customers who have paid for this service.
Post by James Tyson
Moebius Systems is more than happy to run said irrd server in NZ on one
of our servers if that's what needs to happen to organise the routing in
NZ a little more.
I'd recommend using the RIPE code as the authentication and
database consistency mechanisms and search capabilites are much better.
Post by James Tyson
WRT private AS', I am not sure if this is a good idea, however I am also
not sure that asking enterprises to get their own globally unique AS
number is a good (or responsible) thing to do either. Perhaps we can
form a "working group" (not the InternetNZ sense, the NZNOG sense, where
we all go out for curry and beer) to discuss a standard for this sort of
thing within NZ. I know this sounds yuck, but what about carefully
controlled IGP's or maybe funky use of confederations?
And here's the only time I'd advocate running a private database. If
people want to allocate private ASes for use on a "private network" like
Citylink (remember the 202.7.0.0/23 is not routed globally). In that case
it wouldn't be appropriate to have Merit/APNIC etc mirror this although
duplicate local servers could be run using NRTM.
Post by James Tyson
There is also one more way of acquiring /24 address space that hasn't
been mentioned. We acquired the remnants of a company with one :)
Mmm.


-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Andy Linton
2002-09-13 07:30:59 UTC
Permalink
I'm pleased to see this thread generate lots of discussion and I've
thought some more about my position on this. I think the community should
look at a number of things:

1) I think from postings from Philip Smith, Joe Abley, myself (and others)
it's clear there is a mechanism for applying for globally unique ASNs and
it is possible to get them assigned where need can be demonstrated. There
may be an additional cost associated with this.

Clearly such an ASN can be used anywhere on the net including Citylink or
the APE. This should be the preferred option for anyone who wants to peer
in whatever form with more than one other entity. Private ASNs should be
reserved for use between two entities. This may well cover Simon's WIX
route reflectors.

Perhaps ISPs, telcos, and other organisations like Citylink should create
mechanisms (if they don't already have them) to enable their customers to
obtain ASN numbers from APNIC where those customers need an ASN. (My
cynical mind makes me suspect that there may be some resistance to this as
it may be perceived that customers are using this to avoid charging,
connect to another provider etc. Please prove me wrong! Public
declarations on this list might help.)

2) Additionally there is a mechanisms also identified in previous postings
for obtaining IPv4 address space for multihoming. Explore those mechanisms
if you *need* address space.

3) It would be good if we could work together to make the WIX model work
efficiently. Some larger providers might wish that there were only larger
providers peering at the WIX. That clearly isn't the case so it would be
good to see them sit down with Simon Blake and work out how to get
efficient and redundant peering working.

4) Ditto the APE.

5) If people want address the related but separate problem of using RPSL
and the routing registry mechanism to express their public policy (and
automatic generation of filter lists etc) then start trying to understand
policy in terms of the provisions of RFC2622 and RFC2650. I'm happy to
work on this with people when I get back to NZ in November. Others have
said the same but I'll let them put their hands up.

If you intend to do this please strongly consider using the APNIC service
coming shortly. I posted yesterday that the service was hosted in Brisbane
and mirrored at RIPE. They are also investigating the deployment of
redundant services using anycast on four separate continents. How
redundant do you need the service to be?

andy


-
To unsubscribe from nznog, send email to ***@list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Mark Davies
2003-07-07 11:57:56 UTC
Permalink
From: Ewen McNeill <***@naos.co.nz>
Date: Mon, 07 Jul 2003 22:30:05 +1200
I wasn't aware that they were (still) conducting a review (again), and
Mark's "changes" list seems (at first glance) to be consistent with the
existing zone transfer policies.
I got asked on 1 July by Nick Griffin to not publish the changes list until
some review I wasn't aware of that is apparently currently happening was completed.
I know that Mark updated those scripts recently ('cause I prompted him
to do so, since some links were out of date including the ones for
whois)
Actually it was just the whois links.
I guess lots of people doing the same thing would be bad, but this page has
been around for yonks.
As I understand it, that was the main reason (in an earlier interation
of setting zone transfer restrictions) for allowing Mark's scripts to
keep going -- it was one point where people could look for changes,
rather than everyone doing their own zone transfers.
Well the growth stats are the primary reason I'm still doing it. The other
pages merely fall out from doing that.

cheers
mark
Lin Nah
2003-07-08 00:56:45 UTC
Permalink
Post by Mark Davies
I wasn't aware that they were (still) conducting a review (again), and
Mark's "changes" list seems (at first glance) to be consistent with the
existing zone transfer policies.
I got asked on 1 July by Nick Griffin to not publish the changes list until
some review I wasn't aware of that is apparently currently happening was completed.
Perhaps the DNC should explain to us why there is a problem with
Mark's excellent netsites page. I have found it a very valuable resource
(thanks Mark) for many years now. Just because we have the new system
doesn't mean we have to throw out the old stuff with it.

Is it doing any harm or is it because it isn't published by DNC and so
not sanctioned?

The thing is there's stuff I was able to do there that domainz (when it was
a monopoly) and probably now SRS probably don't have the ability to do.
I say probably because I haven't had the need to visit Mark's site apart
from looking up the stats since the SRS has gone through.


Please may we have Mark's netsites pages back!

Thanks
lin
Lin Nah
2003-08-26 22:31:54 UTC
Permalink
The email below tells us that Mark's domain stats site is no longer
updated due to the DNC office.

Have the DNC office done their review and justified their reason
for shutting down Mark's site? It is now nearly 2 months and
we haven't seen any positive developments on this.

Bear in mind that Mark does this useful service at no cost to them
(Or that's the impression I get) and this service existed way way way
before DNS or even Internet NZ /ISOCNZ ever existed.

Unless they intend to take over the job themselves and do an equal task
(without turning things into pdf documents or couched in legalese/spin),
I would like to see Mark's site resume (if mark is willing to continue).
If he isn't, I am sure there'll be someone who will be more tham happy
to raise their hand to offer to take over the task

lin
Post by Mark Davies
I wasn't aware that they were (still) conducting a review (again), and
Mark's "changes" list seems (at first glance) to be consistent with the
existing zone transfer policies.
I got asked on 1 July by Nick Griffin to not publish the changes list until
some review I wasn't aware of that is apparently currently happening was completed.
I know that Mark updated those scripts recently ('cause I prompted him
to do so, since some links were out of date including the ones for
whois)
Actually it was just the whois links.
I guess lots of people doing the same thing would be bad, but this page has
been around for yonks.
As I understand it, that was the main reason (in an earlier interation
of setting zone transfer restrictions) for allowing Mark's scripts to
keep going -- it was one point where people could look for changes,
rather than everyone doing their own zone transfers.
Well the growth stats are the primary reason I'm still doing it. The other
pages merely fall out from doing that.
cheers
mark
_______________________________________________
Nznog mailing list
http://list.waikato.ac.nz/mailman/listinfo/nznog
Bruce Fitzsimons
2003-08-27 02:42:28 UTC
Permalink
Post by Lin Nah
The email below tells us that Mark's domain stats site is no longer
updated due to the DNC office.
<snipped>
Post by Lin Nah
lin
Thanks for writing the email I should have Lin :-)

I was meaning to follow up my original query with the person mentioned
in the original discussion (Nick Griffin) to get the other side of the
story. (Nick, refer
http://list.waikato.ac.nz/pipermail/nznog/2003-July/006475.html and
prior messages).

Nick, do you care to contribute? Is this going to be sorted out in the
near future?

/Bruce
--
Bruce Fitzsimons <***@fitzsimons.org>
DPF
2003-08-27 06:45:18 UTC
Permalink
On Wed, 27 Aug 2003 10:31:54 +1200 (NZST), Lin Nah
Post by Lin Nah
The email below tells us that Mark's domain stats site is no longer
updated due to the DNC office.
Have the DNC office done their review and justified their reason
for shutting down Mark's site? It is now nearly 2 months and
we haven't seen any positive developments on this.
Bear in mind that Mark does this useful service at no cost to them
(Or that's the impression I get) and this service existed way way way
before DNS or even Internet NZ /ISOCNZ ever existed.
Unless they intend to take over the job themselves and do an equal task
(without turning things into pdf documents or couched in legalese/spin),
I would like to see Mark's site resume (if mark is willing to continue).
If he isn't, I am sure there'll be someone who will be more tham happy
to raise their hand to offer to take over the task
I think the major issue is preventing spam. As I have said previously
I have been a major user of Mark's site and found it really useful.
However the list of new domains registered does make it easier for
scammers/spammers to compile a partial list of the .nz register. With
around 4,000 new domains a month it only takes a year to get over a
third of the total .nz register.

I believe there is an intention to have growth stats published again,
but I'm not aware or involved with any details such as where about.

DPF
--
Blog: http://www.kiwiblog.co.nz
E-mail: ***@farrar.com
ICQ: 29964527
MSN: ***@hotmail.com
Mark Davies
2003-08-27 11:46:26 UTC
Permalink
From: DPF <***@farrar.com>
Date: Wed, 27 Aug 2003 18:45:18 +1200
Post by DPF
I believe there is an intention to have growth stats published again,
but I'm not aware or involved with any details such as where about.
The only thing stopping the growth stats side of my monthly update happening
was me getting around to it - done now.

mark
Mark Davies
2003-09-22 01:24:44 UTC
Permalink
From: Ewen McNeill <***@naos.co.nz>
Date: Mon, 22 Sep 2003 13:14:59 +1200
Some people in ASR were getting many dozens per _hour_ (I think one
person was seeing hundreds per hour), so I'm grateful that this one
doesn't seem to have hit me as hard as SoBig.F was (I was seeing
thousands of copies of SoBig.F per day).
We threw away 4500 over the weekend, mostly to two particular addresses, but a
sprinkling to others. Don't know why those two addresses were so hard done by.

mark
Ewen McNeill
2003-10-13 07:19:06 UTC
Permalink
Is anyone else seeing very high volumes of ICMP echo requests today (ie,
in the order of hundreds/thousands per second)? [....]
What do the ping packets look like?
block in on ste7: [internal ip] > [victim ip]: icmp: echo request
4500 005c 58fa 0000 7f01 4929 0a04 0102
3df3 5085 0800 c9c8 0200 d6e1 aaaa aaaa
aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa
As James pointed out, that's a truncated packet (to tcpdump's default
snaplen). The real packet is 92 octets, with 64 octets of payload (0xaa
octets). Which is what the Welchia/Nachi worm sends out.

Desktop support at the client has found several of the machines generating
these ICMP streams to be infected with the Welchia/Nachi worm, and are
busy checking the rest. They also believe they've identified the source
(a laptop that arrived back today IIRC).

It has, however, highlighted which machines didn't get put into the
default policy for lock downs, updates, etc ....

So nothing new, it seems. Just another infection with another windows
worm. Sorry to trouble you all.

Ewen
Ewen McNeill
2006-12-07 21:41:56 UTC
Permalink
Call for Presentations for
NZNOG 2007: Network Systems Administration Mini-Conference
[....]
- Email servers and spam filtering techniques
[....]
At the risk of distracting everyone from arguing about responsible use of
the list, I'd just like to point out that we still have room for a couple
more talks at the Sysadmin Miniconf (on the first day of NZNOG 2007).

And that we'd particularly welcome a proposal on, eg, best practices in
running a mail server, or coping with the ever increasing volume of spam
without rejecting all the legitimate mail.

Proposals of other relevant talks (see the original CFP) are also
welcomed, but be quick as we'd like to finalise the programme before
Christmas so the speakers know what their summer homework is.

Ewen
Ewen McNeill
2008-07-22 01:50:18 UTC
Permalink
See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some
sane discussion of the issue [...]
It appears that someone guessed close enough to how the attack worked
to cause one of the people "in the know" to post a confirmation, and
then attempt to withdraw it -- but of course people have found traces
of the confirmation description and mirrored it. So the cat seems to
be out of the bag, and presumably the Bad Guys (tm) will now try to do
this for real.

See, eg, http://it.slashdot.org/it/08/07/21/2212227.shtml which has
various cut'n'paste copies of what seems to be the confirmation
description, plus a link to the guess that prompted it.
Amongst other things they suggest patching any recursive/caching DNS
servers with vendor patches at the soonest suitable patch window.
If you haven't already patched your recursive/caching DNS servers used
by customers, today would be a good day to do it. So says Dan Kaminsky
who found the issue in the first place: http://www.doxpara.com/?p=1176

Also beware that the NAT in at least some firewalls has been reported to
undo the port randomisation that the patch introduces, resulting in
predictable port numbers again (and thus no increase in randomness or
protection against this attack). Linux-based firewalls are reported to
be okay (apparently by default they pass through the port number used by
the client on outgoing UDP packets if they can), and presumably OpenBSD
based ones are okay given their choice to randomise everything. But
beware of running recursive DNS servers behind NAT on firewalls without
checking what the outgoing packets look like -- if in doubt perhaps put
your recursive DNS servers into the DMZ outside the NAT.

Ewen
Ewen McNeill
2009-01-12 06:25:59 UTC
Permalink
If you've registered for NZNOG 2009 (http://2009.nznog.org/register)
you will have seen that we are holding another network administrators
miniconf on the Wednesday tutorial day.
One more reminder to send us (a) topics you'd like to see discussed, and
(b) offers to introduce a specific topic. This is your chance to talk
with your peers about layer 7 issues which are of relevance to you.

To date we have had suggested:
- configuration automation (puppet, cfengine, and friends)
- scaling network monitoring (eg, distributed nagios)
- virtualisation (VMWare ESX, etc)

No one showed any interest in talking about ENUM (either having it as a
topic, or giving an intro talk), so perhaps that topic is too last week.
We'd be happy to host it if there is still interest, particularly if
those trying to get the 4.6.e164 delegation are willing to turn up and
talk about it.

Please send additional topics (and ideally offers to present for 5-15
minutes as an intro to the topic) to:

<***@nznog.miniconf.org>

Simon Lyall and Ewen McNeill
Network Administrators Miniconf

Continue reading on narkive:
Loading...