[ris-int] Fw: NCC#2004081420 [RE: RIPE beacon request!]
Arife Vural arife at ripe.net
Mon Apr 4 10:35:52 CEST 2005
> > > >What do you think about this request? > > I would be against this. The RRC's are set up as route collectors, > not as machines to run named or whatever for 3rd parties. We have > our agreements with hosts, let's not do things we have not agreed > just because a student somewhere asks. Agree with that. I will let him know. Arife > > Henk > > > > > >James, what does OPS think to run named on RRCs? > > > >Arife > > > > > >----- Begin forwarded message ----- > > > >Date: Thu, 10 Mar 2005 03:56:08 -0500 > >From: "Hitesh Ballani" <hitesh at cs.cornell.edu> > >To: "RIPE NCC RIS" <ris-request at ripe.net> > >Subject: RE: NCC#2004081420 RIPE beacon request! > >Message-Id: <2EE48095D8C21643B0B70EC95F9BFBAF0A3174 at EXCHVS1.cs.cornell.edu> > > > > > >Hello Arife, > > > >Thanks for your help with my last experiment - but I need an even bigger > >favor now. I am going to describe my requirements below - if you do not > >find > >them feasible, please feel free to tell me so. Also, if you have stopped > >leasing out beacons to external researchers, I totally understand. > > > >I need a prefix to be advertised to many RRCs (as many as possible) for the > >duration of a week or so. However, this time I also need the RRCs to run a > >nameserver and answer queries for a particular domain. My friend here at > >Cornell owns a domain name (guha.cc) and hence, I can point anycast.guha.cc > >to the anycast address you assign to me. So for example, assume you assign > >a > >prefix a.b.c.0/24 to my experiment and it is advertised by 8 RRCs. I want > >all > >the 8 RRCs to run a nameserver and answer DNS queries (type A) for > >anycast.guha.cc - each RRC will answer with a different address. Hence, the > >first RRC will answer with a.b.c.1, the second with a.b.c.2 and so on. The > >purpose of this is that such an arrangement allows me to use thousands of > >DNS > >servers which have recursion enabled to perform my measurements and hence, > >adds a lot of value to my anycast study. The above mentioned approach for > >measurement is known as KING and was developed at U.Wash (described here > >http://www.cs.toronto.edu/~stefan/publications/imw/2002/imw.html). > > > >In case this sounds vaguely feasible, I would be more than happy to give > >you > >more details or clarify any doubts you may have. We have used the King > >approach for anycast measurements against the anycasted root-servers - and > >so, have some sense of what is required. You might have security concerns > >regarding running a name-server on your RRCs. I think there are standard > >techniques (eg. running BIND in a chroot JAIL) by which we can ensure that > >this experiment does not add any vulnerabilities to the RRCs - again, I can > >provide with more information/help in case you are interested. > > > >Thanks for your time, > >Hitesh > > > >> -----Original Message----- > >> From: RIPE NCC RIS [mailto:ris-request at ripe.net] > >> Sent: Monday, September 20, 2004 8:13 AM > >> To: Hitesh Ballani > >> Subject: Re: NCC#2004081420 RIPE beacon request! > >> > >> Hi Hitesh, > >> > >> > Lets start off with a prefix (I presume 195.80.238.0/24) being > >> advertised as > >> > normal (i.e. no periodic withdrawals) from 6 locations : RRC01 > >(Lon,UK), > >> > RRC02 (Paris,UK), RRC05 (Vienna,AT), RRC06 (Otemcahi, JP), RRC08 (San > >> > Jose,US), RRC11(NY,USA). As I mentioned earlier, the purpose is to get > >> > baseline measurements for an anycasted prefix when there are no flaps > >> (at > >> > least, no intentional flaps). Then, later we can introduce flaps for > >> other > >> > experiments. > >> > >> I configured on rrc01, rrc02, rrc05, rrc06, and rrc11. rrc08 is offline > >> by now. It's replacement would be rrc14 at PAIX, but it's not online > >> yet. > >> > >> > Actually, what I would like to do is to have the prefix advertised in a > >> > stable fashion (i.e. no intentional withdrawals) from 7 RRC locations > >> with > >> > the locations changing every couple of days .... i.e. of the 13 RRCs, 7 > >> are > >> > always advertising the prefix but the set of seven changes every couple > >> of > >> > days ...since, I would like the non-european sites (3 of them) to > >always > >> be > >> > part of the advertising set, so we are left with choose(13 - 3, 7 -3) = > >> > choose(10,4) = 1260 combinations ... while this is not certainly not > >> > possible, I was wondering if we could try out 5-7 odd combinations so > >> that > >> > the entire experiment finishes in a couple of weeks and then, we can > >> move > >> > onto the experiments with periodic withdrawals ... however, I am not > >> sure if > >> > this can be automated (I would be happy to write any scripts needed for > >> this) > >> > because it would be a pain for you to do this manually .. if this is > >> > possible, then I would be more than happy to send you a chart of the > >5-7 > >> sets > >> > of 7 RRCs, each set advertising the prefix for 2 (or whatever u are > >> > comfortable with) days .. However, if this is not feasible, then we > >> could > >> > start with the pattern mentioned in the previous paragraph and make 1 > >or > >> 2 > >> > changes (2 weeks, one change a week gives us 2 combinations to try > >out). > >> > Comments?? > >> > >> I do not have any comments by now. Should think about it. > >> > >> Thanks for offer. We will see how much of time is required from our side. > >> Then, we can do something about it. We have already some scripts that > >> do the config changes on zebra/bgd. We can modify that one. > >> > >> > > >> > By the way, are you going to set up interfaces on these machines so > >that > >> I > >> > can also do end-to-end experiments? > >> > >> I've configured an interface on those RRCs, IP address, 195.80.238.1. You > >> can try to ping that address. In a few minutes, I will send an e-mail to > >> those IXs mailinglists also to allow transit that prefix. > >> > >> Regards. > >> Arife > >------ End forwarded message ------ > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > Look here junior, don't you be so happy. > And for Heaven's sake, don't you be so sad. (Tom Verlaine)
[ Ris-int Archives ]