Hey Guys; Email from the land with no gas =)
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.
I'm with Joe on this one. I think that while there is no problem with using rfc1918 or rfc 1930 numbers internal to an AS that globally unique addressing should be used at the interfaces to other AS's. If we all had to keep a track of which rfc1918 or rfc1930 addresses each other were using it would just be a big pain in the butt.
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.
dean nods Good call Batman
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 :-).
Ack - I get out more to *avoid* reading rfc's =)
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.
No problem. You can bundle them all into one AS and as long as none of them are doing BGP to their upstream provider then all is well and good. Even if they are, it only takes a little more clue to return everything to the aforementioned `well and good' state.
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.
Yeah - quite a large part of this project was to design a setup that would require minimun configuration at the client end. Alot of clients are just having boxes dropped at their site and have no idea of how to configure them to run something like BGP. And those are the ones with routers =). It would be preferable for everyone on WIX to get an AS number and run BGP, but for some this is just not an option. Atleast this way, the people who are running BGP (primarily the ISP's and organisations with clue) do not have to maintain static routes to the organisations who are not. Not having to maintain static routes on these routers is a Good Thing (tm). So for an end user who is not running BGP, the other BGP speakers on WIX will route traffic to them directly and not congest the router of the users ISP. And for end users who are running BGP with rfc1930 ASN's everything should happen just fine (because they will be hidden behind the ASN that WIX will buy, hint hint).
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.
We should look at some sort of route database with email support for users to email in requests in a format that the administrator can find usefull. See point below about policy registries.
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.
Cool - they should definatly do this (see rant in section 1)
(b) everybody commits to filtering the advertisements they receive,
That's critical.
And should be happening anyway. Filtering should be happening at the ingress and egress points of everyones networks.
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 can. Being able to generate your route maps and filters from a policy registry makes things a lot easier and less prone to error. The main hurdle is getting people to understand what is required and getting them to input the correct information into the registry. It would be a good idea for the WIX route admin to update a policy registry with all the static route information that they are populating into MRT. That way filter generation by the other parties is a simple process.
I might also add (d) as long as there are at least two route servers, preferably located in different buildings in Wellington :)
Yeah we wouldn't want a POWER CRISIS to take out most of the city and get both boxes would we =). I spose I should add that making them gas powered is also a bad move.
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.
I'm sure you'll work something out. Dean --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog