Crikey, a bunch of on topic posts in a row. I didn't realise it was possible... On Wed, Sep 11, 2002 at 06:59:38PM +1200, Ewen McNeill said:
In message
, "Arron Scott" writes:
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.
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.
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.
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.
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.
From my perspective, they're pretty similar, the difference is that the cost of entry onto APE is such that (currently) there are no "customers" of ISP's on APE, so the issue doesn't really arise. I suspect that this won't be the case into the future though.
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
Unfortunately, perceptions like Joe's hang around for a lot longer than they're valid. Almost all ISP's peer with the route servers in Wellington (current exceptions would be Telstra and AT/T, GG don't have a connection), but there are several who speak but don't listen. My perception is that that is slowly changing - more ISP's are doing both, as the number of ISP's increases and the hassle of maintaining 20+ bilateral sessions starts to bite. RPSL databases for WIX/APE will allow me to easily produce accurate prefix and community lists for advertisements out of the route servers (ie, I can do it now, but it's a tedious manual process). When I have that in place, I'll be tub thumping around the ISP's again to get more listening, and I'm hoping that the last few will listen as well as speak.
- 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.
I'm guessing, but I imagine that most providers will take longer prefixes if one was to suck up to them.
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).
As above, resiliency wasn't (and isn't) a design goal of the route servers - it's something you organise yourself.
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.
They're a reliable, effective aid to peering, for ISP's and non-ISP's alike. As an "accelerator" over Citylink (and the Internet in NZ in general), they work brilliantly. As devices to improve resiliency, they're a waste of time. My perception at the moment is that if you want to do this sort of thing between two different providers, then you engage in some gentle horse trading - provider 1 says "how about ASN 645xx", provider two says "mmm, we're using that, what about 645yy", and so on, till a mutually unused ASN is found. I'm not sure if a central register is going to help that process at all, but if there's interest, I'm happy to run it. Cheers Si - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog