Hi Joe,et al Apologies, another long rant. On Fri, 19 Jun 1998, Joe Abley wrote:
On Fri, 19 Jun 1998, Simon Blake wrote:
1. Establish a second emulated LAN on CityLink for BGP peering between cooperating network operators. This will consist of a series of bilateral agreements between individual network operators. No customers should connect to ISPs over this network - this will be a "clean" IP-only network.
While I appreciate that the ISP's primary desire is an interconnect to exchange data with their "peers" (in the loosest sense of the word) on a national basis, I would really like to see an exchange set up in Wellington that also allowed any local organisation to peer on the WIX for *local* traffic.
I think that makes a lot of sense as well, although I am slightly disturbed by reports of broadcast IPX, Appletalk and NetBEUI traffic flowing helter-skelter over the current emulated LAN :)
It's not an emulated LAN, it *is* a LAN - native ethernet over fibre with stock Cisco LAN switches, presumably with an ATM interconnect in the future when someone asks for it. Like most switches, Cisco 2900XL's don't do protocol filtering/firewalling, so we haven't got any direct mechanism to prevent somebody hurling IPX,Appletalk, whatever, over the network. Over time, as more users are added and the cost for advanced features like protocol/port filtering becomes cheaper and more commonplace in switches, we'll almost certainly move to backbone switches that do support at least some protocol filtering. As the network has increased in size and bandwidth, we've moved from hubs to dumb switches to 100Mb/s manageable switches, and we're investigating gigabit ethernet - each time with a commensurate improvement in performance/diagnosability. So now, at least, we can restrict each connection to a given number/range of MAC addresses, and we have the mechanism's to hunt down and harass the users broadcasting IPX et al, even if we can't directly stop them (without disconnecting them). Having said that, non-IP broadcasts are not a huge problem on Citylink - lots of users say "look, there is IPX on the wire", but I've never heard "and it's causing us problems". It's just a couple of poorly configured Instant Internet boxes - it's not a case of somebody backhauling us onto their internal Novell net...
There is a technical problem surrounding the use of the current eLAN for BGP peering. ISPs who exchange routes using BGP over WIX will have route objects tagged within their interior BGP process with a next-hop address from network 10.0.0.0/8, since that is the addressing scheme used across the customer-access eLAN.
No, it is not. Clear use 10.96.8.0/22 for a few connections, we use 192.168.100.0/24 for in-network device management, as far as I know everybody else (the other ISP's) use some chunk of their own range on CNHL. This is an undesirable state of affairs (IMHO), but it's a fairly natural product of "line of least resistance" network construction. :-)
This presents potential problems (ppp :) since it presupposes that the 10.0.0.0/8 network is carried by each ISP's interior routing protocol which CLEAR for one is not able to do cleanly (10 is used for private CLEAR networks).
The more fundamental problem is that we need to get all the routers that need to chat together on to the same address space, be that private, public, or whatever. Currently Netlink are donating a small bit of their IP address space for the purpose, but I think it would be better if we used a range that was a) not routed internationally b) big enough that anbody can get on it, which assumes at lease a /25
We could continue to use the existing eLAN with a globally-unique address range, but that would involve multiple ARPs per router interface across the network. In my experience networks which layer multiple subnet addressing schemes across the same broadcast network are almost always messy and fraught with problems. YMMV :)
Indeed, but the alternative has always been difficult to administer - it needs a central registry to feed and water IP numbers and DNS, and up until now, there hasn't really been a will to organise a pan Citylink numbering scheme. However, with Citylink looking to take a more active role in the management of it's network and in it's involvement in WIX, hopefully a more unified approach to numbering will come.
I think this is an admirable goal, but bear in mind that customers' packets travel through a customers' router before they hit WIX anyway - is an ISPs router likely to be a bigger bottleneck than that?
Hell yes. Up until now, ISP's have connected to Citylink with routers sufficient to drive their upstream links, so there is no real need to provide much more than a 2514 when you're bottlenecked by an upstream slow pipe, so that's (more or less) what everybody uses. Customers, on the other hand, connect with all manner of exotic and mundane hardware, much of it capable of sustaining 100Mb/s. Multiple source/sink pairs @ 100Mb/s passing through a single 10Mb/s router is pretty scary, and there really shouldn't be a need for ISP's to provide such high end hardware - better that the ISP's customers communicate directly amongst themselves.
So, while the ISP's do need a bilateral peering point where individual operators can choose whether to (in effect) carry other ISP's data on their national network, I would like to see a tandem system implemented where local Citylink users can share routes for locally attached networks amongst themselves.
Sorry if I was unclear in my previous post; I was putting forward the idea that each peering ISP would maintain two connections to Citylink eLANs - one for customer access, one for peering. And by ISP I mean "anybody who is keen to persue BGP peering with other network operators in NZ". I just assume that most of these are likely to be ISPs.
Sure, I was observing that even if the ISP's did implement a seperate VLAN for national route peering, I'd like to see a similar exchange running on the current network for ordinary Citylink users (ISP's included, obviously) to share their local routes, to enhance performance over Citylink. I don't know whether it's feasible or even possible, but it certainly won't happen without the support and cooperation of the contributing ISP's.
As far as customers are concerned everything would work as it does now, since I am not proposing any changes to the way that the CityLink managed IP service works.
Managed IP being something of a misnomer, in reality each ISP asserts their own IP network over the underlying ethernet.
Citylink are/can provide hardware to make a local RA registry a reality, which is presumably necessary if non AS numbered entities want to join the IX?
The consensus seems to be that an additional route arbiter database doesn't really add any value - it makes more sense for WIX-peering ISPs to use the Merit RADB in Michigan. This avoids repeated records in national and global route registries which, in practice, will always differ to some degree.
All peering partners will need AS numbers in order to peer using BGP. AS numbers cost US$500 setup and then US$50/year from APNIC (for non-members - they are available free to members). I would have thought this was within the financial scope of all NZ ISPs who are not APNIC members.
Customers who use an ISP via CityLink do not need to peer, as their provider is effectively doing it for them. However, a customer who wanted service from more than one ISP for backup purposes could BGP-peer with the ISPs concerned exactly as it is proposed ISPs do between each other.
A locally-run route server (which draws its policy from the Merit RADB) might make sense if we find a large number of ISPs wanting to peer; however, if the number of peering ISPs/customers is low (say, below 10) then I think it's not really worth the trouble.
How about if we had, say 8 national ISP's sharing national routes, and 80 (10 from each ISP) single homed ISP customers who just want to share local route information with each other - what would that do with the equation? Would a local RADB be worthwhile if it allowed us to implement private AS numbers for these ISP's customers?
With a bit of arm twisting, I could probably squeeze a couple of unused pre-CIDR Class C's out of WCC - would that be a useful/cheaper alternative? Citylink would (I imagine) also be happy to act as a neutral party for DNS maintenance or ISI billing.
Bear in mind that any ISP may source packets from an address on this subnet - so if the Cs you are thinking of are advertised as part of a supernet (at WCC's expense) you will potentially be carrying ISPs traffic globally.
Sure.
If the Cs are not part of larger supernet routes, then you should be fine.
Could you give a firm indication on whether a non-globally-advertised WCC class C could be made available, or whether WCC is keen to administer the payment for an ISI-supplied class C network?
Sorry, I should have provided a little more background. WCC, while being instrumental in getting Citylink off the ground, is but one of some ~22 equal shareholders in Citylink - they are seperate legal entities, and once Citylink takes premises elsewhere in town (sometime soon), there will be no ties at all, other than that WCC is a customer of Citylink. In various capacities I contract to both organisations, so I happen to know that there are some pre CIDR class C's currently routed by Netlink to WCC that aren't used, and with a bit of gentle pleading I believe I could persuade WCC to sign them over to Citylink. I haven't yet checked if they're part of a superblock, nor have I actually talked to the holder of the keys (sic), but if the consensus was that it was worthwhile I'll investigate further. FWIW, it wouldn't suprise me if there were other pre CIDR class C's kicking around unused in these days of heavy NAT use - the ISP's doing traffic charging should know where they are. Failing that, I'm pretty confident that *Citylink* would be happy to oversee the payment and distribution of an ISI-supplied class C - it makes sense, given that Citylink already bill the involved organisations for other services. Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog