On Thu, 8 Oct 1998, Joe Abley wrote:
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 22.214.171.124/23?
Yes, on both counts.
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
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 126.96.36.199/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
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
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
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.
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
and (c) those filters are built from consistent,
(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
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
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads: