- Test - lists.nanog.org

Results of query on auth usage
by Barbara Fraser 06 Jun '02

06 Jun '02

I received 20 responses which isn't exactly overwhelming :-). All of the responses included usage information for eBGP-MD5 and a few provided information on MD5 for interior protocols. In addition to these 20 I also received a few more with commentary. Conclusion from these messages? + only 2 required their peers to use eBGP-MD5 + many wanted to use it but peers either refused or didn't know how + some issues concerning whether this protects you from any "real" threat So, there you have it. Below are the breakouts and miscellaneous remarks that were included in the email I received. Thanks to all of you who took the time to send me something. Barb ================================== eBGP-MD5 use 2 responded that they used it and required it of all peers 12 others replied they used BGP-MD5 whenever their peers supported it 1 replied they use it only when required by a peer 5 said they do not use it Specific usage comments: Out of 100+ peers, only 1 requires it I use MD5 with BGP where I can, but <ISP> told me they don't support it so I'm limited in where I can deploy. 1 out of 25+ peers supports it 1 or 2 out of the 80+ eBGP sessions support it 2 out of 200 eBGP sessions support it iBGP/OSPF/ISIS with MD5 2 reported using this but were in the 5 above that don't use eBGP-MD5 4 others reported using this as well as eBGP-MD5 no reports of using ISIS w MD5 1 said they do not use it Miscellaneous comments: + For the most part, the greater vulnerability (still not well-understood by the script-kiddie community, thankfully) is probably a simple DoS of the appropriate listening port for the routing protocol. + It is our belief that it is highly unlikely that someone would have into your network to inject erroneous route advertisements. + The most difficult challenge I face there is convincing people of the "need" with the lack of a published exploit that the MD5 authentication would prevent. + Despite all the whining about the potential for an attack, I'm not aware of anyone having actually done so. Routers are notoriously under-CPU'd, and I think most engineers would rather have routes converge 30% faster than protect against an attack noone has ever done. + no hacker could figure out how to get into the infrastructure far enough to attack that so it's not worth attacking +.It is very hard for a big provider to change their procedure for setting up MD5 authentication + Some ISPs are practically religious about using them, usually the result of a single person at the ISP pushing it. + On a case by case basis you can get most ISPs to setup MD5 on your particular BGP session, once you found the right engineer. + The person at the other end didn't know how to enable it so you couldn't do it + As far as internal IGP (OSPF) MD5 authentication, I was always a little leary of using it because I wasn't comfortable with key rollover when you approached the maximum number of key-id's, (I believe it was 255). At that point, you're forced to take a hit when you have to remove the key entirely and start from a low integer value key-id. Had that limitation not been there, I would've deployed IGP MD5 authentication.

2 2

Re: Diagnostic Tools
by Pawlukiewicz Jane 06 Jun '02

06 Jun '02

No. But I was thinking of something more robust. And I think it depends on what level you want your diagnostics to go to. Then there's metrics, analysis, detection processes. Ping and traceroute give me a ton of data. I was thinking of something that takes that data and turns it into the bottom line. Where is the problem, when did it start, all the good stuff. I still can't believe someone hasn't cashed in on this. Or is it something you wouldn't need or use? Jane Marc Pierrat wrote: > > Is there a problem with good ol' fashioned ping and traceroute? They're on every platform, even windows. > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > Pawlukiewicz Jane > > Sent: Thursday, June 06, 2002 12:39 PM > > To: Nicolas Maton; nanog(a)merit.edu > > Subject: Re: Diagnostic Tools > > > > > > Sorry it took so long to reply. Work gets in the way... > > > > Nicolas Maton wrote: > > > > > > hmmm, > > > > > > I still don't get the global picture?? > > > You want to poll routers andso outside of your network ? > > > > That's the idea I had, yeah. The traffic on my network is not hard to > > pull. We can analyze that data forever. What I'm curious about is the > > performance, or detection of problems in the routers that serve other > > networks, the gateways. Not like I'm curious about your internal network > > or anything, just there should be some way to determine the what, where, > > when of a boggle on the internet. > > > > I thought by now there'd be a nice package we could buy from somebody > > that would pinpoint the problem(s). I was told they haven't developed > > that yet and couldn't believe it. > > > > > > > > If you have access to them you can use some monitoring software like > > > > > > Big Brother > > > HP openvieuw > > > Aprisma Spectrum > > > CiscoWorks > > > and so on..... > > > > > > If you mean something else please let me know so i can search > > an solution with you. > > > > I'm not sure yet. Access is the rub, I think. Everyone is so proprietary > > these days. I suppose it doesn't matter. > > > > > > > > <<< Cogito ergo sum >>> > > > > ?? (as in, what does that mean?) > > > > > > Nicolas Maton > > > Network Engineer > > > s.a. Tiscali Belgium n.v. > > > Rue de Stassart 43 de Stassartstraat > > > 1050 Brussel -Bruxelles > > > Belgie-Belgique > > > NEW Direct number:+32 (0)2 4003663 > > > NEW Cell Phone:+32 (0)498 889363 > > > E-mail: nmaton(a)be.tiscali.com > > > http://www.tiscali.be > > > > > > This email and any attachments may be confidential and the > > subject of legal > > > professional privilege. Any disclosure, use, storage or copying of this > > > email without the consent of the sender is strictly prohibited. Please > > > notify the sender immediately if you are not the intended > > recipient and then > > > delete the email from your inbox and do not disclose the > > contents to another > > > person, use, copy or store the information in any medium. > > > ********************************************************************** > > > > > > -----Original Message----- > > > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > > > Sent: donderdag 6 juni 2002 16:01 > > > To: Nicolas Maton > > > Subject: Re: Diagnostic Tools > > > > > > Thanks for responding so quickly. > > > > > > I think I need to rephrase the question. I'm not thinking of diagnostics > > > on a specific network, as in my company's intranetwork. I'm thinking > > > there must be a set of diagnostic tools to determine where the problem > > > is outside of my network. If its platform specific it wouldn't work very > > > well, would it? > > > > > > I was just thinking again. A dangerous hobby. > > > > > > Thanks, > > > > > > Jane > > > > > > Nicolas Maton wrote: > > > > > > > > For what platform? > > > > > > > > -----Original Message----- > > > > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > > > > Sent: donderdag 6 juni 2002 15:51 > > > > To: nanog(a)merit.edu > > > > Subject: Diagnostic Tools > > > > > > > > Hi, > > > > > > > > I'm new here but I already have a quick question. > > > > > > > > What are the best diagnostic tools available to network > > operators today? > > > > > > > > Thanks for any info, > > > > > > > > Jane

4 3

Re: Diagnostic Tools
by Pawlukiewicz Jane 06 Jun '02

06 Jun '02

Sorry it took so long to reply. Work gets in the way... Nicolas Maton wrote: > > hmmm, > > I still don't get the global picture?? > You want to poll routers andso outside of your network ? That's the idea I had, yeah. The traffic on my network is not hard to pull. We can analyze that data forever. What I'm curious about is the performance, or detection of problems in the routers that serve other networks, the gateways. Not like I'm curious about your internal network or anything, just there should be some way to determine the what, where, when of a boggle on the internet. I thought by now there'd be a nice package we could buy from somebody that would pinpoint the problem(s). I was told they haven't developed that yet and couldn't believe it. > > If you have access to them you can use some monitoring software like > > Big Brother > HP openvieuw > Aprisma Spectrum > CiscoWorks > and so on..... > > If you mean something else please let me know so i can search an solution with you. I'm not sure yet. Access is the rub, I think. Everyone is so proprietary these days. I suppose it doesn't matter. > > <<< Cogito ergo sum >>> ?? (as in, what does that mean?) > > Nicolas Maton > Network Engineer > s.a. Tiscali Belgium n.v. > Rue de Stassart 43 de Stassartstraat > 1050 Brussel -Bruxelles > Belgie-Belgique > NEW Direct number:+32 (0)2 4003663 > NEW Cell Phone:+32 (0)498 889363 > E-mail: nmaton(a)be.tiscali.com > http://www.tiscali.be > > This email and any attachments may be confidential and the subject of legal > professional privilege. Any disclosure, use, storage or copying of this > email without the consent of the sender is strictly prohibited. Please > notify the sender immediately if you are not the intended recipient and then > delete the email from your inbox and do not disclose the contents to another > person, use, copy or store the information in any medium. > ********************************************************************** > > -----Original Message----- > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > Sent: donderdag 6 juni 2002 16:01 > To: Nicolas Maton > Subject: Re: Diagnostic Tools > > Thanks for responding so quickly. > > I think I need to rephrase the question. I'm not thinking of diagnostics > on a specific network, as in my company's intranetwork. I'm thinking > there must be a set of diagnostic tools to determine where the problem > is outside of my network. If its platform specific it wouldn't work very > well, would it? > > I was just thinking again. A dangerous hobby. > > Thanks, > > Jane > > Nicolas Maton wrote: > > > > For what platform? > > > > -----Original Message----- > > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > > Sent: donderdag 6 juni 2002 15:51 > > To: nanog(a)merit.edu > > Subject: Diagnostic Tools > > > > Hi, > > > > I'm new here but I already have a quick question. > > > > What are the best diagnostic tools available to network operators today? > > > > Thanks for any info, > > > > Jane

1 0

Re: Bogon list
by smd＠clock.org 06 Jun '02

06 Jun '02

| Why treat exchange subnets differently to any other bit of backbone | infrastructure? Oh, I wholeheartedly agree. I would love them all to use RFC 1918 addresses, because it is VERY VERY VERY rare that anything outside the scope in which the 1918 local use addresses are unique actually has to communicate with backbone infrastructure of any type. What communication can your workstation have with an XYZNET router? Can you log into it? Can you talk SMTP to it? How about SNMP? Oh, I know - you can start up a BGP session with it from your desk, right? In short, ping & traceroute are about the only interaction anyone will ever have with a router that is not under their control, excepting error messages (which is the usual way at least traceroute works), and it is NOT WORTH THE ADDRESS CONSUMPTION just to facilitate this. Regrettably, IP sux in the confusing of "where" and "what", so the only way to know who sent you the error ICMP datagram except by the source address. ICMP types that let one encode a handy URL or maybe some text explaining the error and its source would be cool, and if this is regularized, then there's no point in having global address space consumed by things which are only ever going to have interactive sessions with local hosts, and you get to keep your end-to-end diagnostic regime of incredibly useful, reliable and intuitive tools like traceroute and ping. In the absence of new ICMP messages (which really have to be rolled out "everywhere"), redirecting the attention spent on inducing and interpreting them to an in-the-network tool for diagnosing the condition of a LOCAL set of infrastructure is something I think is quite practical. Perhaps a tiny chunk of address space with useful IN-ADDR.ARPA messages would be a good start. : unix ; traceroute abc.defxyz.net symbolic-name (217.31.0.1) 1 ms 1 ms 1 ms symbolic-name.your.provider.net (217.31.10.2) 5 ms 5 ms 5 ms please-see.http.www.smartprovider.net (223.255.255.1) 50 ms 50 ms 50 ms please-see.http.www.smartprovider.net (223.255.255.1) 60 ms 60 ms 60 ms please-see.http.www.smartprovider.net (223.255.255.1) 65 ms 65 ms 65 ms please-see.http.www.smartprovider.net (223.255.255.1) 70 ms 70 ms 70 ms please-see.http.www.smartprovider.net (223.255.255.1) 75 ms 75 ms 75 ms please-see.http.www.otherprovider.net (223.255.255.2) 79 ms 80 ms 79 ms please-see.http.www.otherprovider.net (223.255.255.2) 85 ms 82 ms 98 ms ... (I was kinda thinking it might be fun for someone with some spare address space to offer up a mapping of A.B.HI.LO with HI.LO being the higher and lower order bytes of an AS number, although obviously that's not necessary, and is going to be wasteful, since people like Joe will think this is so abominable, that they won't have their ASes do it :-) ) | Why number point-to-point links with even locally-unique addresses? iBGP hack requires intra-domain connectivity to work, and may sometimes require distinguished interface addresses; eBGP insists on connectivity between peers in same logical subnet except when you break that with intentional use of knobs. SNMP hack requires interactive intra-domain connectivity to work. SSH (and telnet disaster) requires interactive intra-domain connectivity to work. Ping/traceroute/etc originating from route-server host(s) require interactive intra-domain connectivity to work. All these and more may benefit from discretely numbered interfaces. These numbers may be 1918 addresses, or they be kept discreet. You might think this is rather backwards and Victorian, like hiding the legs of tables from prying eyes through the use of extremely long tablecloths. However, there are people who have had funny carpentry done, who might see this as a feature. | Slashdot readers wielding traceroute can make an annoying pain in the | side of your head, but traceroute and ping are not without their uses. No functionality is broken - it's just you get ICMP messages from things you probably cannot connect to in any meaningful way. Big deal, that's what you have now, pace ping. | Ask people who are cursed with running poorly-documented X.25 networks | (surely there must be some left) how nice it would be to be able to map | the network in-band. Ask them why they don't have any hair left, while | you're at it. MPLS cannot cause baldness. That lot all have thick and fuzzy hair, I think. I'll stick with conventional theory and suggest it might be genes or razors. (Are you gonna call NATs&6to4/faith X.75 gateways? Cool!) | You don't need to deal with the messy traceroute problem if your | consistent and clean architecture doesn't happen to make traceroute | mess :) Right, stop replying to things which are obviously or even probably traceroutes. No more traceroute mess. No more idiotic firewall operators complaining about these damn unreachable and exceeded messages. I think I'm in favour, although I have to admit traceroute can be fun. Did you ever see Louis Mamakos's toy? Sean.

9 11

Re: KPNQwest ns.eu.net server.
by Joao Luis Silva Damas 06 Jun '02

06 Jun '02

At 16:35 +0200 6/6/02, Gert Doering wrote: > >Hmmm? As far as I can see, RIPE has enough providers. The problem is >that the ccTLD secondary server hosted at KQ broke - ns.eu.net has not "broke". At least not yet. KPNQwest still has very competent people (and I would like to specifically thank Berislav Todorovic for embracing the idea of placing ns.eu.net outside KPNQwest to ensure stability and for all the support in actually doing it) The RIPE NCC doesn't currently need further support to operate the service, which is why we volunteered to do it, to provide a stable service until further steps are undertaken without the concern for the time period KPNQwest will be able to continue to operate. With time, since EUNet will not exist, ns.eu.net should also disappear (I am not quite sure the RIPE NCC would want to "own" the eu.net domain), but it should be after everyone has got time to think properly about a solution that suits them in the long term. Cheers, Joao

1 0

RE: KPNQwest ns.eu.net server.
by Neil J. McRae 06 Jun '02

06 Jun '02

Gert, > On Thu, Jun 06, 2002 at 02:59:22PM +0100, Neil J. McRae wrote: > > I suggest that if the RIPE need another provider that they > > take time and issue a proper RFI/P/Q through the European > > Journal. It does ask an interesting question over disaster > > recovery in situations like this. > > Hmmm? As far as I can see, RIPE has enough providers. The problem is > that the ccTLD secondary server hosted at KQ broke - which isn't RIPEs > fault, and doesn't even host anything RIPE is master for (like ripe.net > or the *.in-addr.arpa zones). > Hence why I said "if the RIPE need another provider". Note the part that has "if" in it. Regards, Neil.

1 0

RE: Re: KPNQwest ns.eu.net server.
by Daniska Tomas 06 Jun '02

06 Jun '02

ok, let's suppose that usually provides the most appropriate environment for placing the dns servers and their co-infrastructure. taking it only technically, providing the connectivity for the ixp is a detail (to announce or not to announce). maybe the ixp could allocate a 'stub' subnet - separate from the transit subnet - and provide a voluntary mlpa to all the hosted isps. this would not break the isp policies on announcing the transit ixp subnet. all these are details. i see a space for another topic in this thread - updating the dns infrastrucure a bit. to be more specific: - would the ixp-located tld dns servers server only a small set of tld's each? if so, would it be region-based or agreement-based? - would it be worth the effort starting a project similar to irr that would serve as a common source for dns configurations? it'd be nice to hear your oppinions -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: Arnold Nipper [mailto:arnold@nipper.de] > Sent: 6. júna 2002 16:29 > To: Daniska Tomas > Cc: Nipper, Arnold; nanog(a)merit.edu > Subject: Re: Re: KPNQwest ns.eu.net server. > > > On Thu, Jun 06, 2002 at 04:13:08PM +0200, Daniska Tomas wrote: > > how would you guarantee connectivity? > > > > as you have a lot of ISPs around you it should be really easy > to get some > connectivity. Very easy: tell some friendly ISP to announce > your prefix/AS > to outside. > > > should each isp present should provide bandwidth as part of > collocation expenses? > > What do you mean by this? If some ISP want to donate bw, > nice. If not also Ok. > > > should the opexes be included in the colo bill? > > Which colo bill? > > > > > and then - this would probably make the colo becoming a > connectivity provider, wouldn't it? > > > > Not necessarily. This much depends on your IXP model. Let's > take DE-CIX. > There is an association running DE-CIX, but InterXion as colo > partner takes > cae for a lot of things. If DE-CIX would offer > infrastructural services, > InterXion still would remain a simple colo provider. > > > Arnold > -- > Arnold Nipper Email: > arnold.nipper(a)de-cix.net > DE-CIX, The German Internet Exchange Mobile: +49 172 2650958 >

1 0

Are you seeing ATM framing errors at Chicago AADS?
by John Kristoff 06 Jun '02

06 Jun '02

The Chicago SBC (formerly AADS) NAP upgraded their Lucent switch code this past Sunday and we suspect we may be having some problems due to that upgrade. If anyone else is there and has been seeing framing errors since then, I'd appreciate a private reply back saying so (or not even). It would be particularly valuable to know what vendor's equipment you have on your side of that link as well. Thanks, John

1 0

RE: Re: KPNQwest ns.eu.net server.
by Daniska Tomas 06 Jun '02

06 Jun '02

how would you guarantee connectivity? should each isp present should provide bandwidth as part of collocation expenses? should the opexes be included in the colo bill? and then - this would probably make the colo becoming a connectivity provider, wouldn't it? -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: Nipper, Arnold [mailto:arnold.nipper@de-cix.net] > Sent: 6. júna 2002 16:07 > To: Jan-Ahrent Czmok; Sabine Dolderer/Denic > Cc: apnic-talk(a)lists.apnic.net; apops(a)lists.apnic.net; > ddiaz(a)ripe.net; joao(a)ripe.net; lir-wg(a)ripe.net; > nanog(a)merit.edu; randy(a)psg.com; routing-wg(a)ripe.net; tech-l(a)ams-ix.net > Subject: Re: Re: KPNQwest ns.eu.net server. > > > > As a lot of people are offering secondary services: may be > it's a good idea > to place infrastructural services at IXP. IXP seem to be more > stable than > any ISPs and often more neutral than ISPs. > > Comments? > > > Arnold > -- > Arnold Nipper, DE-CIX, the German Internet Exchange > email: arnold.nipper(a)de-cix.net > mobile: +49 172 2650958 > handle: an6695-ripe > > > ----- Original Message ----- > From: "Sabine Dolderer/Denic" <dolderer(a)denic.de> > To: "Jan-Ahrent Czmok" <czmok(a)gatel.net> > Cc: <apnic-talk(a)lists.apnic.net>; <apops(a)lists.apnic.net>; > <ddiaz(a)ripe.net>; > <joao(a)ripe.net>; <lir-wg(a)ripe.net>; <nanog(a)merit.edu>; > <randy(a)psg.com>; > <routing-wg(a)ripe.net>; <tech-l(a)ams-ix.net> > Sent: Thursday, June 06, 2002 9:43 AM > Subject: Re: Re: KPNQwest ns.eu.net server. > > > > Hello, > > DENIC runs currently several secondarys (not only DE but also for some > other TLDs) in different places worldwide. We are willing to offer > secondary service for other ccTLDs. But there will be because of > security/stability reasons a limit on the number of ccTLDs we > want to run > on a single machine. > > Sabine > > -- > Sabine Dolderer > DENIC eG > Wiesenhüttenplatz 26 > D-60329 Frankfurt > > eMail: Sabine.Dolderer(a)denic.de > Fon: +49 69 27235 0 > Fax: +49 69 27235 235 > > > > Jan-Ahrent > Czmok An: Joao Luis Silva Damas > <joao(a)ripe.net> > <czmok@gatel. Kopie: randy(a)psg.com, > ddiaz(a)ripe.net, routing-wg(a)ripe.net, > net> lir-wg(a)ripe.net, > tech-l(a)ams-ix.net, > apops(a)lists.apnic.net, > Gesendet von: nanog(a)merit.edu, > apnic-talk(a)lists.apnic.net > owner-lir-wg@ Thema: Re: KPNQwest > ns.eu.net > server. > ripe.net > > > 06.06.2002 > 01:29 > > > > > > > PostedDate: 06.06.2002 01:29:37 > $MessageID: <20020606012937.2c476312.czmok(a)gatel.net> > From: owner-lir-wg(a)ripe.net > SendTo: Joao Luis Silva Damas <joao(a)ripe.net> > CopyTo: > randy@psg.com;ddiaz@ripe.net;routing-wg@ripe.net;lir-wg@ripe.n > et;tech-l@ams- > ix.net;apops@lists.apnic.net;nanog@merit.edu;apnic-talk@lists. > apnic.net > > Subject: Re: KPNQwest ns.eu.net server. > Received: from smtp.denic.de ([194.246.96.22]) by > notes.denic.de > (Lotus Domino Release 5.0.8) with ESMTP id > 2002060601283597:15602 > ; Thu, 6 Jun 2002 01:28:35 +0200 > Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by > smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 > +0200 > Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 > Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 > Delivered_To: lists-lir-wg-out(a)lists.ripe.net > PRINCIPAL: Jan-Ahrent Czmok <czmok(a)gatel.net> > In_Reply_To: <p05111700b92449b9ddee(a)[193.0.1.81]> > References: <200206051725.g55HPlA05396(a)birch.ripe.net> > <E17Ff8f-0003So-00(a)roam.psg.com> > <p05111700b92449b9ddee(a)[193.0.1.81]> > Organization: Global Access Telecommunications Inc. > $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; > i386-debian-linux-gnu) > X_Ncc_RegID: de.gatel > MIME_Version: 1.0 > Precedence: bulk > X_Loop_Detect: RIPE NCC > SMTPOriginator: owner-lir-wg(a)ripe.net > RouteServers: CN=notes/O=Denic > RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 > DeliveredDate: 06.06.2002 01:28:38 > DENICDOCOPENCOUNT: 1 > $MIMETrack: Itemize by SMTP Server on notes/Denic(Release > 5.0.8 |June 18, > 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine > Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 > 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 > BlindCopyTo: > WebSubject: Re: KPNQwest ns.eu.net server. > > > On Thu, 6 Jun 2002 01:08:46 +0200 > Joao Luis Silva Damas <joao(a)ripe.net> wrote: > > > > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > > Given the current situation of KPNQwest and the possibility > > >> of its services going offline sometime soon, the RIPE NCC in > > >> agreement with KPNQwest will be temporally hosting this > > >> server (ns.eu.net) in its premises. > > > > > >nice emergency hack and sorry to whine. but i used them both > > >to get diversity. > > > > Hi Randy, > > > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > > secondary. So we will definitely request those ccTLDs to look for a > > new host as soon as possible. > > Hi Randy, hi Joao, dear routing-wg, > > probably my Company (GATEL, AS13129) is able to host a secondary > server for the ccTLDs. > > The question is rather what are the hardware "requirements" for the > secondary > server. > > We have sufficient bandwidth capacity available and rack > space as well. > > > The rest can take bit more time to think what they want to do since > > ns.eu.net will keep running. > > Well done ! Congrats for the good ideas and coordination work. > > > > > We are offering secondary service on ns.ripe.net for any ccTLD that > > we weren't sencodaring for, as are other people. > > > > The idea is not to have ns.eu.net running for ever, just to enable > > people to have time to take rational decisions, without the fear of > > having the server going away because of some unexpected turn of > > events. > > > > > > > >when in less of a panic, please move it to moscow or something. > > > > Panic? what panic? this is just common sense > > > > right. it's not panic. > > --jan > > -- > Jan Ahrent Czmok - Senior Network Engineer - Access Networks > Global Access Telecommunications, Inc. - Stephanstr. 3 - > 60313 Frankfurt > voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: > czmok(a)gatel.de > > > > >

3 2

Clarification needed on ATM
by Rich Sena 06 Jun '02

06 Jun '02

OK - sorry if this is elementary - however I am dealing with a challenge to the security of some ATM links that we have connecting remote facilities to a main campus. The connections are all PVPs with individual PVCs defined point to point. The concern that is being raised is that although these connections appear point-to-point PVCs to the router interfaces at our sites and our main campus - they are more than likely switched SVCs on the provider backbone... I had thought that a PVC was a nailed up connection between vpi-vci pairs throughout the provider ATM network - is that an incorrect assumption? And if so is the scenario that was raised possible/probable and a concern? Thanks for any info kids... -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

3 2