Hey Joe On Thu, 8 Oct 1998, Joe Abley wrote:
Hi Simon,
On Thu, Oct 08, 1998 at 12:14:43AM +1300, Simon Blake wrote:
The main aim of the experiment was to consider ways that Citylink connected organisations with BGP capable routers but without AS numbers might exchange routing data, so that they can send data directly between each other, without having to go through one (or several) ISP routers.
Is it reasonable to assume that all networks reachable in this manner (a) will be numbered on globally-unique addresses, and (b) will have a WIX next hop within 202.7.0.0/23?
Yes, on both counts.
As a rudimentary route server, MRT seems to work really well (it lacks some of the RIPE tools of the Merit RA, but on the other hand, it compiles under Linux :-). We ended up setting up MRT to peer with the organisations who had AS numbers, and then setup all the other routers in AS number 65502 (chosen at random) as static routes within MRT, and redistributed them into BGP. Turn off synchronisation on the routers in AS65502, and everything seemed to work as advertised (this is speaking from memory, I haven't looked at it for about 6 weeks).
This is a cool idea, but I have a minor reservation based on the setup you described.
I have a problem with the use of a "private use" ASN (rfc1930) for essentially the same reason that I object to the use of rfc1918 addresses on WIX - this is shared infrastructure, and we should use globally-unique numbering (for IP addresses and for ASNs). To not do so may/will cause problems - we should not have to worry about _our_ use of any private-use ASNs or IP addresses within _our_ network conflicting with anybody else's.
I don't have any real problem with using either private or public AS numbers - we used the private number because Citylink doesn't have it's own AS number, not because we're anti the idea of getting a public ASN. I'm not convinced it's such an issue, though. Every organisation is going to want to filter, prioritise and avoid rebroadcasting networks with the CL ASN, regardless of whether it's public or private, otherwise you'll end up carting national traffic for organisations that aren't your clients.
The way to fix this is for the Citylink route servers to operate under a globally-unique ASN, and to essentially hide all the private-use ASNs to other networks when advertising the routes on to ISPs. Ciscos will do this automagically for private-use ASNs (64512 to 65535), and I assume mrt can do something similar?
Possibly, MRT is something of a work in progress, and it's a while since I've read the docs. I would suspect however, that if Citylink got a global ASN, we wouldn't have much need for private-use ASNs anyway, we could just put all the non ASN'd orgnisations into the Citylink ASN.
Since all the BGP speakers (with global or private-use ASNs) will learn routes with next hop addresses on the 202.7.0.0/23 network, they will route traffic to them directly (since this is a connected route).
That's how it works.
This scheme very closely follows that suggested in rfc2270, with Citylink taking the role of the "local provider", talking BGP to their local customers and providing transit to other "global providers".
Does it? I should get out more :-).
I'm pretty sure this is also how most other big exchanges function with route servers.
The only difference being that most exchanges are between organisations with unique ASN's - that's why they're on the exchange. Citylink has this wrinkle that most of the organisations on the network have no AS number, and no hope (or need) of getting one.
I'm not sure how your redistributed static advertisements fit into the picture - surely only traffic in one direction would escape the ISP's router in this case? Or was that just part of the mrt testing?
I (or, I should say, we - much thanks goes to Dean Pemberton for spending his last hours in NZ working with me on this) was examining ways of improving reliability, and reducing reliance on each organisations router being correctly setup. I liked the idea of all the non AS numbered Citylink customers sharing the same ASN, which immediately implied an interior BGP network. The problem I had was that (theoritically) all routers in an IBGP net should be peers, which seemed to me to defeat the purpose of having a route server in first place. So rather then setup each client router to redistribute from their internal routing protocol into the iBGP net on Citylink, we just bunged static routes for those networks straight into the route servers, and redistributed the static routes into BGP on the route servers. This has several advantages - it's stable, possibly clueless customers have to email or ring up to get changes made, rather than accidentally readvertising a pile of routes they shouldn't, and it makes configuration of the client routers simpler. On the down side, it's more admin work for the route server administrator, but these small networks aren't likely to change the networks they want to advertise much, so I don't see that moves/adds/changes are going to be a big issue. Obviously, for the big (in a network sense) organisations that do have their own AS numbers, we do bog standard eBGP peering.
Citylink is now at the stage where we've got customers pestering us to incorporate them into the system, and a management itchy keen to take some money off of these people. So I guess what I'm after from the list is some opinions on whether this is a good idea, and I'm on the right track. Obviously, for this to be more than a toy I need the ISP's on Citylink to participate in such an exchange, so recommendations on making it easier for them to be involved are welcome.
I think this is definitely a good idea, and will help everybody out tremendously, as long as
(a) the route servers operate under a globally- unique ASN [as above],
I'm sure citylink can spring for an AS number.
(b) everybody commits to filtering the advertisements they receive,
That's critical.
and (c) those filters are built from consistent, published policy (e.g. in the IRR).
I don't have a good feeling for how the policy in the IRR works, so I can't comment here.
I might also add (d) as long as there are at least two route servers, preferably located in different buildings in Wellington :)
We have two identical machines, and the intention is to stash them in different buildings, near the main switches. I haven't yet worked out an elegant way of keeping them updated and consistent, but it shouldn't be a problem. Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog