What are most large NSP's doing in the way of routing registries? Is most everyone using the RADB or a local database? I'm working on some guide-lines here. To me, using the RADB seems the best idea, but others have mentioned a requirement that it be kept in-house and just exported on a regular basis. Any thoughts? I'll summarize private responses, --Ben Kirkpatrick, ELI DPG
We are using local data base, but it can contain the references to the RIPE data base (i.e. if we believe to some peer or customer, we can trust to his information in the RIPE DBA; usially we don't trust anyone except ourself). Exactly there is 3 types of the neighbours: - trusted (for example, I hope MCI should be trusted for everyone; you can't build access filter for it); - we get info from RIPE or some other DBA (usially it's some peers); - we maintain routing info ourself (customers and some small ISP here). ===================================== On Mon, 9 Feb 1998, Ben Kirkpatrick, ELI wrote:
Date: Mon, 9 Feb 1998 09:32:28 -0800 (PST) From: Ben Kirkpatrick, ELI <blkirk@float.eli.net> To: north american NOG <nanog@merit.edu> Subject: Routing Registries...
What are most large NSP's doing in the way of routing registries? Is most everyone using the RADB or a local database? I'm working on some guide-lines here. To me, using the RADB seems the best idea, but others have mentioned a requirement that it be kept in-house and just exported on a regular basis. Any thoughts?
I'll summarize private responses, --Ben Kirkpatrick, ELI DPG
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Exactly there is 3 types of the neighbours: - trusted (for example, I hope MCI should be trusted for everyone; you can't build access filter for it);
Not according to two of the presentations at nanog. Of course, being too lazy to ask the question, I remained in my seat :). Anyways, both the IOPS proposal and origin authentication assume that you are going to be looking up a hefty amount of routes against either an RR database or some dns tree to validate that the information that you are receiving is correct. Caching or not, this is not a good way to go about solving the problem (if it even exists on a large scale... Paul may have some information about spammers doing this?)
- we get info from RIPE or some other DBA (usially it's some peers); - we maintain routing info ourself (customers and some small ISP here).
Generally, our response is to use the routing registries to build policy from the customer end (i.e. ensuring that our customers are doing the right thing). That way, we will not be responsible for any prefixes injected into the global routing table. Our upstreams as well make some attempt to verify that our information is correct (though it may be only through as path access lists. I think that this is the best solution to the problems talked about today. Ensure that you are not the problem and eventually the clue factor will propogate around the network (though it seems to have a really slow convergence time :). If everyone ensured that neither they nor their customers are responsible for the problems, the world would be that much a better place. I'll stop the idealistic crusade now, but it would be nice.. BR brad reynolds brad@iagnet.net IAGnet/CICnet
Sorry, I forget to add:
Exactly there is 3 types of the neighbours: - trusted (for example, I hope MCI should be trusted for everyone; you can't build access filter for it); - we get info from RIPE or some other DBA (usially it's some peers); - we maintain routing info ourself (customers and some small ISP here). And this case we should check this information by RIPE or RADB, and then by our local registry, and then add it to the local data base...
Generally, our response is to use the routing registries to You can't do it for your own customers - this registries does not contain enougph information for your local routing filters... This is why I mentioned not 2 but 3 different schemas.
For now, the problem is not in choosing one of this schemas, the problem is in a lot of small and badly-qualified ISP who do not control their routes, and are not controlled by their ISP (due to some unknown reasons) and so on. Anyway this do not protect your from mistakes (we had some funy experience when some authoritive person lost 1 digit and add wrong network (95.x.x.x instead of 195.x.x.x) into RIPE DB; then we have checked this and add this to our data base, and it took about 2 weeks to found this mistake. This is why the idea of using some authentication or sighning (as is to be proposed now, as I know) is important. On the other hand, I don't think it's good idea for some small ISP to check all routes he receive from the big one (for example, some _VILLAGE_DUBY_ISP get conenctivity from some GLOBAL_AFRICA_AND_AZIA) in case if they are sure this big one make all such checks itself. But it's another issue. All I'd like to note here is _it's important to make any kind of control now instead of total absence of such control_ - this cause a lot of headache over the whole internet. And (in real life) we saw this 3 schemas _where routing information can be found_.
participants (3)
-
Alex P. Rudnev -
Ben Kirkpatrick, ELI -
Bradley Reynolds