Re: Wee query about clear :) (fwd)
Hi all (bringing a conversation between Jamie Clark and yours truly out into the light) On Tue, 9 Nov 1999, Jamie Clark wrote:
Simon,
On Tue, 9 Nov 1999, Simon Blake wrote:
Any change in your policy of not publishing a route policy? :)
"policy" is a bit strong :-). It has always been my intent to publish a
No offence intended.
and absolutely none taken.
route policy, but time is pressing, and Clear are the only ISP on Citylink that consistantly ask for same. Everytime I sit down to learn what's involved and get a policy loaded, something else crops up that appears more urgent. :-( I'm happy to try and bump it up the priority list, if it will encourage more ISP's to peer.
WIX has obviously worked well without filters so far.
It comes and goes. Generally, it works fine, and that's probably a reflection on the stability of the NZ net, or at least, the bit that peers in wellington. In general, it's changes (additions of new peers) that can cause temporary hiccups (Actrix advertising 4000 prefixes yesterday being a good example).
It is certainly tempting to forgo the safety measures and peer anyway - however I suspect that some day it will become necessary to have the WIX route policy in some form of database. (?) maybe, perhaps.
Absolutely, especially as WIX rises in importance as a major peering point in NZ, rather than as a "backup" peering point, which has been it's role until now.
IMHO it is a potential security risk if you cannot control which routes you choose to learn from your neighbours. It would be possible for a WIX customer with evil intentions to advertise a longer prefix into our network and steal our customer's traffic (or any other WIX ISP's traffic for that matter). Hmmm (evil ideas spring to mind)
It may seem a bit odd, but this has been one of my pet *aims* for WIX! Contrary to popular belief, Citylink doesn't have infinite network capacity :-). Therefore, providing a mechanism where customers of ISP's can transit data directly to other customers of ISP's, without having that data split horizon through one or two ISP routers is increasingly desirable. That's why we have a setup where a little Citylink customer with a /28 from their ISP and no ASN can still peer with the route server and exchange data directly with other Citylink users.
It would not be sufficient for us to deny these advertisements either - as they may very well be legitimate (multihoming).
Having said that (that I think allowing small Citylink customers to advertise long prefix routes directly is desirable), I'm all for restricting what the route server will accept from each client. My policy at the moment tends to vary, depending on the customer. If the peer is an ISP (ie, if they have their own ASN), then I assume they know what they're doing, and I don't filter incoming or outgoing updates, unless requested by the peer. If the peer has no ASN, then I assume that they're less clueful, and also that they're likely to have a small number of routes that change infrequently. Because those non ASN peers are much more likely to foul things up, I filter the updates I receive from them to only the routes they've told me they'll send.
Admittedly a policy database with automatic updates will not necessarily prevent this - but at least there would be an audit trail pointing to the offender.
And that has to be a good thing.
With the current operational changes to RADB it looks like we will set up our own database and have this mirrored by RADB. This won't happen until next year though. The goal would be to automatically generate router BGP configs from this database.
If you're interested (and provided you don't do it first ;) I'm sure we would be keen to pass on anything that might be useful.
When I last looked at the RADb a few months ago, I mused that having route arbiters on WIX and/or APE might not be a bad thing, and would be a useful service for Citylink to provide in it's capacity as "neutral peering provider to the stars" :-). Seeing that Merit are planning to charge US$200 per year leads me to believe that it's an idea who's time may have come. Comments? Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
I would fully support a peering database, as the size grows it will become even more important. It is relitivly easy to make mistakes and advertise tings incorrectly for those of us who work on this gear for a living, let alone small connections that are set up by people of unknown experience levels. I would be fully prepared to put some resource ( what type ? ) towards this. This is too important a thing to take lightly. I would much rather spend some time and/or money towards getting this right than run the risk of random routeing problems. -----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of Simon Blake Sent: Wednesday, 10 November 1999 10:31 To: nznog(a)list.waikato.ac.nz Cc: richard(a)citylink.co.nz Subject: Re: Wee query about clear :) (fwd) Hi all (bringing a conversation between Jamie Clark and yours truly out into the light) On Tue, 9 Nov 1999, Jamie Clark wrote:
Simon,
On Tue, 9 Nov 1999, Simon Blake wrote:
Any change in your policy of not publishing a route policy? :)
"policy" is a bit strong :-). It has always been my intent to publish a
No offence intended.
and absolutely none taken.
route policy, but time is pressing, and Clear are the only ISP on Citylink that consistantly ask for same. Everytime I sit down to learn what's involved and get a policy loaded, something else crops up that appears more urgent. :-( I'm happy to try and bump it up the priority list, if it will encourage more ISP's to peer.
WIX has obviously worked well without filters so far.
It comes and goes. Generally, it works fine, and that's probably a reflection on the stability of the NZ net, or at least, the bit that peers in wellington. In general, it's changes (additions of new peers) that can cause temporary hiccups (Actrix advertising 4000 prefixes yesterday being a good example).
It is certainly tempting to forgo the safety measures and peer anyway - however I suspect that some day it will become necessary to have the WIX route policy in some form of database. (?) maybe, perhaps.
Absolutely, especially as WIX rises in importance as a major peering point in NZ, rather than as a "backup" peering point, which has been it's role until now.
IMHO it is a potential security risk if you cannot control which routes you choose to learn from your neighbours. It would be possible for a WIX customer with evil intentions to advertise a longer prefix into our network and steal our customer's traffic (or any other WIX ISP's traffic for that matter). Hmmm (evil ideas spring to mind)
It may seem a bit odd, but this has been one of my pet *aims* for WIX! Contrary to popular belief, Citylink doesn't have infinite network capacity :-). Therefore, providing a mechanism where customers of ISP's can transit data directly to other customers of ISP's, without having that data split horizon through one or two ISP routers is increasingly desirable. That's why we have a setup where a little Citylink customer with a /28 from their ISP and no ASN can still peer with the route server and exchange data directly with other Citylink users.
It would not be sufficient for us to deny these advertisements either - as they may very well be legitimate (multihoming).
Having said that (that I think allowing small Citylink customers to advertise long prefix routes directly is desirable), I'm all for restricting what the route server will accept from each client. My policy at the moment tends to vary, depending on the customer. If the peer is an ISP (ie, if they have their own ASN), then I assume they know what they're doing, and I don't filter incoming or outgoing updates, unless requested by the peer. If the peer has no ASN, then I assume that they're less clueful, and also that they're likely to have a small number of routes that change infrequently. Because those non ASN peers are much more likely to foul things up, I filter the updates I receive from them to only the routes they've told me they'll send.
Admittedly a policy database with automatic updates will not necessarily prevent this - but at least there would be an audit trail pointing to the offender.
And that has to be a good thing.
With the current operational changes to RADB it looks like we will set up our own database and have this mirrored by RADB. This won't happen until next year though. The goal would be to automatically generate router BGP configs from this database.
If you're interested (and provided you don't do it first ;) I'm sure we would be keen to pass on anything that might be useful.
When I last looked at the RADb a few months ago, I mused that having route arbiters on WIX and/or APE might not be a bad thing, and would be a useful service for Citylink to provide in it's capacity as "neutral peering provider to the stars" :-). Seeing that Merit are planning to charge US$200 per year leads me to believe that it's an idea who's time may have come. Comments? Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Tony Wicks wrote:
I would fully support a peering database, as the size grows it will become even more important. It is relitivly easy to make mistakes and advertise tings incorrectly for those of us who work on this gear for a living, let alone small connections that are set up by people of unknown experience levels. I would be fully prepared to put some resource ( what type ? ) towards this. This is too important a thing to take lightly. I would much rather spend some time and/or money towards getting this right than run the risk of random routeing problems.
Agreed, and surely we've all done it and we're supposed to know what we are doing ;) <stir> Oh, and Si what's happening with the WIX mailing list </stir> Cheers, Sid -- Sid Jones Loquacious, dissemblers, immoral liars, stunted, sjones(a)netlink.co.nz bigoted, dark, ugly, pugnacious little trolls. 0800 655 465 -British Food Critic AA Gill on the Welsh --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, 9 Nov 1999, Sid Jones wrote:
Tony Wicks wrote:
I would fully support a peering database, as the size grows it will become even more important. It is relitivly easy to make mistakes and advertise tings incorrectly for those of us who work on this gear for a living, let alone small connections that are set up by people of unknown experience levels. I would be fully prepared to put some resource ( what type ? ) towards this. This is too important a thing to take lightly. I would much rather spend some time and/or money towards getting this right than run the risk of random routeing problems.
Agreed, and surely we've all done it and we're supposed to know what we are doing ;)
<stir> Oh, and Si what's happening with the WIX mailing list </stir>
I thought I'd just take over nznog for my own nefarious purposes :-) It's still on the list of things to get done... :-) Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Wed, Nov 10, 1999 at 11:23:27AM +1300, Simon Blake wrote:
It's still on the list of things to get done... :-)
Looks like you might need a database for that soon too =) Dean -- ----------------------------------------------------------------------- Dean Pemberton - dp(a)lucent.com Escalation Engineer with the Company Formally Known As Ascend Lucent Technologies - Lvl 38, 55 Collins St, Melbourne 3000, Australia ----------------------------------------------------------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Wed, Nov 10, 1999 at 10:30:59AM +1300, Simon Blake wrote:
On Tue, 9 Nov 1999, Jamie Clark wrote:
WIX has obviously worked well without filters so far.
It comes and goes. Generally, it works fine, and that's probably a reflection on the stability of the NZ net, or at least, the bit that peers in wellington. In general, it's changes (additions of new peers) that can cause temporary hiccups (Actrix advertising 4000 prefixes yesterday being a good example).
Originally, there was only one peering point, in Hamilton. It used OSPF, which you couldn't filter, but that was generally ok because it was more important to connect people to the exchange quickly and easily than it was to worry about filtering problems. When your only route out is through the exchange, you don't necessarily need to worry much about filtering. Now there are three exchanges as well as private peering links in the network, some operators have a choice of as many as six routes for their domestic traffic to take as it leaves their network. This requires some traffic engineering that previously was not particularly necessary. The proliferation of domestic peering also means that finger trouble at one particular operator now has (in some cases) six times as many ways to cause problems for other operators, in a manner that is quite possibly six times harder to debug. All this adds up to the fact that when Angry Customer calls up to find out why his Angry Customer can't talk to someone else's Angry Customer, you need some idea of how things _ought_ to look before you can figure out what has broken. Publishing route policy makes that easier. It also makes it easier to filter with some confidence, which is also a good thing. If Atrix release 4000 prefixes into the network, and you pick them up and trust them, then it's your fault for not filtering. Don't yell at Actrix :) The tools required to set up and run an RPSL registry are all freely available, but it _is_ something that needs to be set up professionally and run as such, in my opinion. A flaky database which contains out-of- date information because people can't update it is probably worse than no database at all. Merit now charge US$200/year to keep records in their database. In the absense of a similar facility elsewhere (e.g. in NZ) that is as stable as Merit's, I would say that was good value for money.
My policy at the moment tends to vary, depending on the customer. If the peer is an ISP (ie, if they have their own ASN), then I assume they know what they're doing,
You missed out the ":)"
and I don't filter incoming or outgoing updates, unless requested by the peer.
Warning! Warning! Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Joe's point about Merit is where this get's interesting to me. Obviously, WIX and APE should move to a Arbitrated network in my opinion, if you are providing the route server, then you provide the only rational filtering point. On the issue of running the database though, this data may well reach beyond the realm of WIX and APE and their customers, for instance NetGate could use it to Clear directly etc. Wouldn't it be nice if we could trust that ISOCNZ and DomaiNZ could provide a useful cost-effective and more regionally acurate alternative to Merit !!! Well, I'm allowed to dream aren't I !!! Arron Scott Telecom NZ On Wed, 10 Nov 1999, Joe Abley wrote:
On Wed, Nov 10, 1999 at 10:30:59AM +1300, Simon Blake wrote:
On Tue, 9 Nov 1999, Jamie Clark wrote:
WIX has obviously worked well without filters so far.
It comes and goes. Generally, it works fine, and that's probably a reflection on the stability of the NZ net, or at least, the bit that peers in wellington. In general, it's changes (additions of new peers) that can cause temporary hiccups (Actrix advertising 4000 prefixes yesterday being a good example).
Originally, there was only one peering point, in Hamilton. It used OSPF, which you couldn't filter, but that was generally ok because it was more important to connect people to the exchange quickly and easily than it was to worry about filtering problems. When your only route out is through the exchange, you don't necessarily need to worry much about filtering.
Now there are three exchanges as well as private peering links in the network, some operators have a choice of as many as six routes for their domestic traffic to take as it leaves their network. This requires some traffic engineering that previously was not particularly necessary.
The proliferation of domestic peering also means that finger trouble at one particular operator now has (in some cases) six times as many ways to cause problems for other operators, in a manner that is quite possibly six times harder to debug.
All this adds up to the fact that when Angry Customer calls up to find out why his Angry Customer can't talk to someone else's Angry Customer, you need some idea of how things _ought_ to look before you can figure out what has broken.
Publishing route policy makes that easier. It also makes it easier to filter with some confidence, which is also a good thing. If Atrix release 4000 prefixes into the network, and you pick them up and trust them, then it's your fault for not filtering. Don't yell at Actrix :)
The tools required to set up and run an RPSL registry are all freely available, but it _is_ something that needs to be set up professionally and run as such, in my opinion. A flaky database which contains out-of- date information because people can't update it is probably worse than no database at all.
Merit now charge US$200/year to keep records in their database. In the absense of a similar facility elsewhere (e.g. in NZ) that is as stable as Merit's, I would say that was good value for money.
My policy at the moment tends to vary, depending on the customer. If the peer is an ISP (ie, if they have their own ASN), then I assume they know what they're doing,
You missed out the ":)"
and I don't filter incoming or outgoing updates, unless requested by the peer.
Warning! Warning!
Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (6)
-
Arron Scott -
Dean Pemberton -
Joe Abley -
Sid Jones -
Simon Blake -
Tony Wicks