- Ris-int - mailman.ripe.net

Installation CD for RRC13
by Matthew Williams 28 Oct '04

28 Oct '04

Hi there, Thanks for getting the RRC in place. BTW, did receive the installation cd that Bruce Campbell sent you a while ago? Kind regards, Matthew

2 5

RE: [ripe.net #105795] R: rrc13 installation CD briefly publicly available as ISO image via ftp
by Matthew Williams 22 Oct '04

22 Oct '04

Hi there, > Unfortunately, James is out of the country. Yes, I know. He is at FICIX, but won't he be back on Monday? > Could you give me some more details? This bootable cd will install a plain vanilla Debian distribution + a software router (Quagga) + looking glass + mysql and some in-house code needed for data insertion on a remote route collector (to be). The server in Moscow will become rrc13. > What files, who might know more about this and so on? I am not sure how good the relationship between BC and the higher echelons of ops is nowadays, but he does definitely know more about the CD than I. Bruce, could you help us out? Otherwise, I'm fine with waiting until Monday. Have a good weekend. Cheers, Matthew > -----Original Message----- > From: Miriam Schoon via RT [mailto:ops@ripe.net] > Sent: 22 October 2004 14:59 > To: matthew(a)ripe.net > Subject: Re: [ripe.net #105795] R: rrc13 installation CD > briefly publicly available as ISO image via ftp > > > On Thu, Oct 21, 2004 at 05:50:56PM +0200, Matthew Williams wrote: > > > > At ops everyone presumed these were shipped together with the > > > machines. > > > > No, this request concerns a customised installation CD for a Remote > > Route Collector that's already in Moscow. James, who has > been working > > on this deployment, should know the details. > > Hi Matthew, > > Unfortunately, James is out of the country. > > Could you give me some more details? > What files, who might know more about this and so on? > > Thanks, > > -- > Miriam Schoon | miriam(a)ripe.net > RIPE NCC | Support Technician >

2 1

RRC00 down
by Vasco Asturiano 22 Oct '04

22 Oct '04

Hello all, I just noticed that RRC00 is currently down, apparently since yesterday at around 08:00. The host is reachable but Quagga doesn't seem to respond. In the case that the downtime wasn't planned, BGPd probably needs to be restarted. Is there a procedure for this operation? Thanks, Vasco

1 0

new url for ris pages?
by Engin Gunduz 22 Oct '04

22 Oct '04

Hi Webmaster, What is the new URL for, for example http://www.ripe.net/ripencc/pub-services/np/ris/rrc01.html ? There are broken links from http://www.ris.ripe.net/cgi-bin/rrcstatus.cgi Thanks, -engin

2 1

RE: [ripe.net #105795] R: rrc13 installation CD briefly publicly available as ISO image via ftp
by Matthew Williams 21 Oct '04

21 Oct '04

Hi there, > At ops everyone presumed these were shipped together with the > machines. No, this request concerns a customised installation CD for a Remote Route Collector that's already in Moscow. James, who has been working on this deployment, should know the details. Cheers, Matthew > -----Original Message----- > From: Miriam Schoon via RT [mailto:ops@ripe.net] > Sent: 21 October 2004 16:54 > To: matthew(a)ripe.net > Subject: Re: [ripe.net #105795] R: rrc13 installation CD > briefly publicly available as ISO image via ftp > > > On Thu, Oct 21, 2004 at 02:47:55PM +0200, Matthew Williams wrote: > > > installation CD lost in mail. can we provide ISO via ftp? > > Hi Matthew, > > Are these cd's shipped seperately? > At ops everyone presumed these were shipped together with the > machines. > > Thanks, > > -- > Miriam Schoon | miriam(a)ripe.net > RIPE NCC | Support Technician >

1 0

R: rrc13 installation CD briefly publicly available as ISO image via ftp
by Matthew Williams 21 Oct '04

21 Oct '04

Hereby I wish to request a service from Operations. Detailed description: --------------------- [ Please provide us with all relevant information ] installation CD lost in mail. can we provide ISO via ftp? Cheers, Matthew Regards, Matthew Williams

1 0

Re: suggestions for beacons
by Henk Uijterwaal (RIPE NCC) 19 Oct '04

19 Oct '04

Hi Morley, > Paul Francis, Ramesh Govindan, and I wrote this draft for setting up a > BGP Lab combining the RIPE beacons with other beacons. Please see the > attachment for more details. Basically, we would like to allow > programmable access to the beacons for researchers, so that it is easier > to perform experiments. We plan to provide the software to enable such > access. 1) How many users do you expect for this facility: 1, 10, 100, 1000? O(1) is fine, O(10) doable, O(100) will require a major administrative effort from somebody. 2) Our route collectors are there to collect routes, in order to get the data for the tools that our users use (myASn, BGPlay, all the queries). That's the number 1 priority for them, everything else (including the beacons) is a by-product. The problem with giving out accounts and have people configure their own prefix, is that people can misconfigure things. If this results in a lot of BGP activity, then this will cause people to loose confidence in the RIS project and perhaps even dropping peering sessions. That is a bad thing. So-far, we have never given any account to anybody, except for own operations, so we can control what is running on the box. This proposal would change that completely. 3) We have quagga running on the box to collect and announce routes, you have your own software. I'm not sure if they can coexist (but we can find out). 4) Address blocks: the RIR's all have a policy for temporary address assignments. I'm not sure, but I don't think that they allow us to have a large number of used /24's on the shelf. As far as I can see, these policies do not allow for temporary AS# assignments, this might be an oversight, but fixing it will take time. Bottom line: I like the concept but it will need a lot of thought regarding the practical implications. (Cc'ing some of my colleagues, who may want to add something). Henk ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis)

2 3

Request: keep ris-int in Cc [was Re: [ris-int] NCC#2004093307 [195.80.224.0/24 not flapping?]
by Rene Wilhelm 19 Oct '04

19 Oct '04

Hi, Just a request: when a thread is started on ris-int could all who reply please keep ris-int in Cc: ? Cleaning up my inbox, I was wondering myself what the status was, not having seen any reply to Vasco's request for advice. Now going through the xrtt ticketing system, I see messages with headers like To: RIPE NCC RIS <ris-request(a)ripe.net> Cc: james(a)ripe.net, matthew(a)ripe.net, arife(a)ripe.net shouldn't that have been "Cc:ris-int" instead of personal e-mails? wasn't the ris-int list created for exactly that purpose? Cheers, -- Rene

2 1

Meeting?
by Henk Uijterwaal (RIPE NCC) 18 Oct '04

18 Oct '04

Do we have/need a meeting this morning? Henk ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis)

3 3

Web Access Report for the Routing Information Service - September, 2004
by Matthew Williams 15 Oct '04

15 Oct '04

Hi All, We have another monthly RIS Web Access Report available at the following URL: http://iii.ripe.net/np/WWW092004_RIS.pdf Please comment on oddities. Cheers, Matthew Ps. Future location: http://iii.ripe.net/sed/ris/reports/www/ --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/

1 0

Web Access Report for the Routing Information Service - August, 2004
by Matthew Williams 12 Oct '04

12 Oct '04

Hi All, The monthly RIS Web Access Report is available at the following URL: http://iii.ripe.net/np/WWW082004_RIS.pdf Please comment on oddities. Cheers, Matthew Ps. The report will later be moved to: http://iii.ripe.net/sed/ris/reports/www/ --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/

1 0

Attn: Factory Manager
by Minola Smoked Products 11 Oct '04

11 Oct '04

1 0

NCC#2004093307 [195.80.224.0/24 not flapping?]
by RIPE NCC RIS 08 Oct '04

08 Oct '04

Hi all, I'd like to ask an advice on this case. This is about a peering session at RRC0 with AS7018 (12.0.1.63). They're saying that they recently do not receive the announcements/withdrawals of the beacon prefix 195.80.224.0/24. Apparently, the last time they noticed the flapping of this prefix was in the beginning of June 2004. In fact, looking at the RIS database, we can see the daily updates of the other RRC0 peers for 195.80.224.0/24, but none from AS7018. The peering session with them has been up for about 3 weeks. How can we check whether the BGP updates are being sent to them or not? Thanks, Vasco ----- Begin forwarded message ----- Date: Wed, 29 Sep 2004 18:18:40 -0400 From: Jay Borkenhagen <jayb(a)att.com> To: rispeering(a)ripe.net Subject: NCC#2004093307 195.80.224.0/24 not flapping? Cc: Aman Shaikh <ashaikh(a)research.att.com> Message-Id: <16731.13504.826194.244753(a)oz.mt.att.com> Hi, We've got a BGP session from our 12.0.1.63 to your 193.0.4.28. I thought that 195.80.224.0/24 was supposed to oscillate based on the schedule at http://www.ripe.net/ris/beaconlist.html, but I haven't seen that prefix flap since sometime in early June 2004. Below I'll include what I've got now. Jay B. route-spews#show ip bgp sum [...] 193.0.4.28 4 12654 16 2163875 45600521 0 0 1w6d 2 [...] route-spews#show ip bgp nei 193.0.4.28 routes BGP table version is 45601230, local router ID is 12.0.1.63 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 195.80.224.0 193.0.4.28 0 100 0 12654 i *> 195.80.239.0 193.0.4.28 0 100 0 12654 i Total number of prefixes 2 route-spews#show ip bgp 195.80.224.0/24 BGP routing table entry for 195.80.224.0/24, version 32179320 Paths: (2 available, best #1) Advertised to update-groups: 1 3 4 12654, (aggregated by 64536 10.34.183.128) 193.0.4.28 from 193.0.4.28 (193.0.4.28) Origin IGP, metric 0, localpref 100, valid, external, best Community: 7018:2000 12654, (aggregated by 64536 10.34.183.128), (received-only) 193.0.4.28 from 193.0.4.28 (193.0.4.28) Origin IGP, metric 0, localpref 100, valid, external route-spews#show ip bgp 195.80.239.0/24 BGP routing table entry for 195.80.239.0/24, version 32179323 Paths: (2 available, best #1) Advertised to update-groups: 1 3 4 12654, (aggregated by 64512 10.255.255.255) 193.0.4.28 from 193.0.4.28 (193.0.4.28) Origin IGP, metric 0, localpref 100, valid, external, best Community: 7018:2000 12654, (aggregated by 64512 10.255.255.255), (received-only) 193.0.4.28 from 193.0.4.28 (193.0.4.28) Origin IGP, metric 0, localpref 100, valid, external route-spews# -- Jay Borkenhagen jayb(a)att.com AT&T Internet Services ------ End forwarded message ------ --

1 0

suggestions for beacons (fwd)
by Henk Uijterwaal (RIPE NCC) 07 Oct '04

07 Oct '04

Hi, Mainly FYI. I like the idea but I'm not sure about all the consequences. Will talk to Morley, Henk ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) ---------- Forwarded message ---------- Date: Mon, 4 Oct 2004 14:36:52 -0400 (EDT) From: Z. Morley Mao <zmao(a)eecs.umich.edu> To: "Henk Uijterwaal (RIPE NCC)" <henk(a)ripe.net> Subject: suggestions for beacons Hi Henk, Paul Francis, Ramesh Govindan, and I wrote this draft for setting up a BGP Lab combining the RIPE beacons with other beacons. Please see the attachment for more details. Basically, we would like to allow programmable access to the beacons for researchers, so that it is easier to perform experiments. We plan to provide the software to enable such access. We would love to hear any comments you may have. Thank you very much! --Morley

1 0

FW: myASN code walk-through
by Matthew Williams 05 Oct '04

05 Oct '04

Hi Ziya, Olaf Maennel at the Technical University of Munich is helping us out with ideas for future myASn alarms. I know this is short notice, but when would you have time for a conf call with Olaf and a student of his? Olaf Maennel wrote: > do you have some time for a conf call on Tuesday, Oct 05 at 3pm or > 3:30pm? > I'm meeting Florian Hauer, the student working on myASN. If > time permits > on your side for a quick(*) walk through the latest version of the > myASN code that would be very helpful, because Florian could > participate. What do you think? Cheers, Matthew

3 6

some notes regarding myasn...
by Alexis Yushin 01 Oct '04

01 Oct '04

Hi, Yesterday, in the brewery, I understood from Henk that you guys are going to have a myasn meeting somewhere in the near future. I thought it might be usefull if I send in some ideas of what needs to be done/implemented. I'm also looking for a new contract right now and I would be quite willing to work on myasn again :) Either way I hope that my input helps. Cheers, Alexis Prio 1. - bugfixes/feature implementation (obvious) - proper authentication module (with logout option) - optimization/clean-up myasn-scan/myasn-send/myasn-admin move the functionality of these programs into respective RIPE::NCC::myASn::Scan RIPE::NCC::myASn::Send (this will untie lots of knots and make myasn much more extendable) - reimplement XML import with XML::DOM and use <registry name=".."> as DTD - enable retromatch (will be trivial after myasn-scan reimplemented as perl interface; retromatch is already in there but requires a rather resource inefficient invokation of myasn-scan) - handle notification mail bounces/errors with some inteligence - graphical (.png) summary on the start page Prio 2. - prefix independent alarms with complex (multi-part) regular expressions (this is one most important and powerfull feature that will make myasn usefull for much larger range of applications) - site global alarm groups with possibility to subscribe to them (martians system/default route) - visibility alarms - churn based alarms - snmp alarm notifications - pgp signing of notification messages (usefull?) Prio 3. - auto sync with IRR and LIR portal (for prefixes and as numbers) - self tuning alarms

2 2

FW: [ris-int] RIS Beacons
by Matthew Williams 30 Sep '04

30 Sep '04

Sorry, forgot to include ris-int. /Matthew > -----Original Message----- > From: Matthew Williams [mailto:matthew@ripe.net] > Sent: 29 September 2004 16:05 > To: zmao(a)eecs.umich.edu > Cc: beacons(a)ripe.net > Subject: RE: [ris-int] RIS Beacons > > > Hi again, > > The old beacons list has been revitalised with the additions > of Shane, Paul and Ramesh. The more, the merrier ;) > > > Bush), we are performing this experiment (shown > > http://www.psg.com/~zmao/beacon5.jpg) to understand the > > effect of fail over behavior. Perhaps something similar to > > this can be set up in the RIS beacon project. This would be > > very interesting to study. > > Wow, quite an intricate little beacon. In principle, once we > have the appropriate set up with transit providers (and they > understand what we're doing), then we should be able to > oblige. The question, however, is how to prioritise among > many experiments and find the RIPE NCC resources to support > them. The RIS team will probably have to discuss this > internally before providing answers. > > > Perhaps a similar scheme to the PSG beacons can be adopted. > > Right now, for PSG beacons we are overloading the Aggregator > > Sorry, I forgot that James had actually implemented above. > > +++ > > Since 12th September 2003 > > All beacon prefixes are now announced with additional > attributes. We now overload the BGP AGGREGATOR attribute to > tag each announcement with a timestamp, a sequence number and > the identifier of the RRC making the announcement. These are > encoded as follows.... > > http://www.ripe.net/ris/beaconlist.html > > +++ > > This seems similar to PSG's schema, no? > > I believe that you use your own beacon code, while we still > use Quagga. Where there any special reasons for this or was > Quagga just to heavy-weight for beacon purposes? Moreover, > some concerns were raised about 'lag' between execution of > the cron job that modifies the [no] network statement and > when the a's or w's actually hit the wire. Is this still an > issue or will timestamping be sufficient to deal with it? > > Cheers, > Matthew > > > -----Original Message----- > > From: Z. Morley Mao [mailto:zmao@eecs.umich.edu] > > Sent: 29 September 2004 06:57 > > To: Matthew Williams > > Cc: 'Henk Uijterwaal (RIPE NCC)'; ris-int(a)ripe.net; 'Shane > > Kerr'; Ramesh Govindan; Paul Francis > > Subject: RE: [ris-int] RIS Beacons > > > > > > Hi Henk and Matthew, > > > > Thanks very much for including me on these emails. I have > > also CC'd Ramesh Govindan and Paul Francis who are also > > interested in using the Beacons. > > > > > > > a) They have more peers giving transit than any other > AS on the > > > > > Internet. > > > > > > This was discussed internally right from day one of RIS beacon > > > project. Good that the research community have confirmed concerns > > > raised back then. > > > > Would it be possible to set up the experiment such that the > > beacon alternates across the different upstream providers, > > i.e., at one point announced by two providers, then withdraw > > from one, re-announce to another one, etc? And iterate using > > another two different providers. > > > > For one of the multi-homed PSG beacons (hosted by Randy > > Bush), we are performing this experiment (shown > > http://www.psg.com/~zmao/beacon5.jpg) to understand the > > effect of fail over behavior. Perhaps something similar to > > this can be set up in the RIS beacon project. This would be > > very interesting to study. > > > > > > > > > > > > b) When a prefix is invisible, it is not clear if this > > is caused by > > > > > an experimental problem or by the prefix being > > filtered. The > > > > > anchor prefix does not solve this problem, there should > > > > be one anchor > > > > > per beacon. > > > > > > Yup, our beacons were deemed practically useless in the > > paper by Mao, > > > Bush et al, so it's good that we're finally fixing above. > > > > > > What about timestamping and sequence numbers in the BGP > > messages? Was > > > this also something that needed to be addressed? > > > > Perhaps a similar scheme to the PSG beacons can be adopted. > > Right now, for PSG beacons we are overloading the Aggregator > > AS field to denote the sequence number (each new announcement > > has a seq number incremented from the old one), and > > aggregator IP field to denote the time at which the message > > is sent out. To prevent people from misinterpreting these > > two fields, we make sure that the Aggregator AS is in the > > private AS range (64512-65535), and the Aggregator IP is also > > in the private address range (e.g., 10/8). > > > > Thanks! > > > > --Morley > > > > > Cheers, > > > Matthew > > > > > > > -----Original Message----- > > > > From: ris-int-admin(a)ripe.net [mailto:ris-int-admin@ripe.net] On > > > > Behalf Of Shane Kerr > > > > Sent: 28 September 2004 12:25 > > > > To: Henk Uijterwaal (RIPE NCC) > > > > Cc: zmao(a)eecs.umich.edu; ris-int(a)ripe.net > > > > Subject: Re: [ris-int] RIS Beacons > > > > > > > > > > > > Henk Uijterwaal (RIPE NCC) wrote: > > > > > All, > > > > > > > > > > At SIGCOMM 2004, it became clear that the current > > beacon prefixes > > > > > suffer from 2 problems: > > > > > > > > > > a) They have more peers giving transit than any other > > AS on the > > > > > Internet. > > > > > > > > > > b) When a prefix is invisible, it is not clear if this > > is caused by > > > > > an experimental problem or by the prefix being > > filtered. The > > > > > anchor prefix does not solve this problem, there should > > > > be one anchor > > > > > per beacon. > > > > > > > > > > So, people suggested that for the next period > > > > (1/10/2004-30/9/2005), > > > > > we make the following changes: > > > > > > > > > > 1. A new /19 is requested from the RIPE NCC. This /19 > > is split into > > > > > /24's. > > > > > > > > > > 2. Each RRC annouces 2 /24's. Assuming A.B.Z is the > > base address > > > > > > > > > > A.B.(Z+2*Y).0/24 > > > > > A.B.(Z+2*Y+1).0/24 > > > > > > > > > > For Y=0 to 13 for the (up to 16) RRC's. > > > > > > > > > > The first prefix is announced permanently. The second > > > > one is a flapping > > > > > prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. > > > > The pattern may > > > > > be changed at a later stage. > > > > > > > > > > 3. Inside each /24, a pingable address will be established. > > > > > > > > > > 4. We ask only 2 or 3 peers at each IX to provide > > transit for these > > > > > prefixes. (In other words, we do not ask everybody). > > > > > > > > > > 5. Other experiments that we do are: > > > > > > > > > > - An overflow prefix (prefix announced at 1 RRC, > > > > flapping at the next). > > > > > - Hitesh's experiment. > > > > > > > > > > 6. The current 195.80.224.0/20 is returned to the RIPE NCC > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > This looks good to me. > > > > > > > > -- > > > > Shane Kerr > > > > RIPE NCC > > > > > > > > > > >

1 0

RIS Beacons
by Henk Uijterwaal (RIPE NCC) 29 Sep '04

29 Sep '04

All, At SIGCOMM 2004, it became clear that the current beacon prefixes suffer from 2 problems: a) They have more peers giving transit than any other AS on the Internet. b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should be one anchor per beacon. So, people suggested that for the next period (1/10/2004-30/9/2005), we make the following changes: 1. A new /19 is requested from the RIPE NCC. This /19 is split into /24's. 2. Each RRC annouces 2 /24's. Assuming A.B.Z is the base address A.B.(Z+2*Y).0/24 A.B.(Z+2*Y+1).0/24 For Y=0 to 13 for the (up to 16) RRC's. The first prefix is announced permanently. The second one is a flapping prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. The pattern may be changed at a later stage. 3. Inside each /24, a pingable address will be established. 4. We ask only 2 or 3 peers at each IX to provide transit for these prefixes. (In other words, we do not ask everybody). 5. Other experiments that we do are: - An overflow prefix (prefix announced at 1 RRC, flapping at the next). - Hitesh's experiment. 6. The current 195.80.224.0/20 is returned to the RIPE NCC Comments? Henk ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis)

4 3

Arife is offline from now on.
by Arife Vural 28 Sep '04

28 Sep '04

Hi all, I'll be away for a month. During that time if you need anything from me, you can reach by phone. My mobile number is, Mobile: +31 61 471 8561 I do not know yet, I might check my e-mails occasionally. But do not expect me to get back to you until I come back. Arife

1 0

RRC13 (Moscow) & RRC14 (PAIX)
by Arife Vural 28 Sep '04

28 Sep '04

Hi guys, If any of those RRCs would be online when I'm away, you can find the details of how to configure mySQL server and update CGIs in the following doc, http://iii/sed/twiki/bin/view/SED/HowToAddNewRRC I have already done mySQL config for RRC14. RRC13 needs to be done. Arife

1 0

Re: RIS box @ MAE-West
by Paul Vixie 28 Sep '04

28 Sep '04

i'm making good progress with paix-s&d on getting you your own peering port.

2 1

RIS box @ MAE-West
by Arife Vural 28 Sep '04

28 Sep '04

Hi Thomas, Joe, On RRC08, we could not get enough peers and that makes the route collector less functional. Because of that, we are thinking to relocate RRC08 at PAIX. We hope that would give us a chance to get more peers and better view there. Peter Losher will help us to move the box from MAE-West to PAIX. We are hoping to do those changes early September. I would like to thank you all your help for hosting RRC08 at MAE-West. Kind regards. Arife

4 28

Switching to new layout and RIS WEB pages
by Arife Vural 27 Sep '04

27 Sep '04

Hi all, I'll be off for vacation from this Wed. Please, coordinate RIS part of switching to new layout with Ziya. Documentation how to do the switch on RIS site is available at http://iii/sed/twiki/bin/view/SED/MigrateRISWEBPagesToNewRIPENCCLayout Good luck. Arife

1 0

Fw: NCC#2004081420 [RE: RIPE beacon request!]
by RIPE NCC RIS 27 Sep '04

27 Sep '04

Hi James, Hitesh could ask some changes about announcing Beacon Prefix. Vasco might need help to do those changes. Could you please give him a hand to do those changes? BTW, I updated the following page. http://www.ripe.net/ripencc/pub-services/np/ris/beaconlist.html You can find the latest changes there. Thanks. Arife ----- Begin forwarded message ----- Date: Fri, 17 Sep 2004 02:11:17 -0400 From: "Hitesh Ballani" <hitesh(a)cs.cornell.edu> To: "RIPE NCC RIS" <ris-request(a)ripe.net> Subject: RE: NCC#2004081420 RIPE beacon request! Message-Id: <81224EA6DDA07C43BC7555E32401029E054260(a)EXCHVS2.cs.cornell.edu> Hi Arife, > Sorry getting back to you late. That is all-right ... I can imagine you being very busy! > Please let me know which RRCs you > like to announce Beacon prefix and which pattern we will start-up. 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. 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?? By the way, are you going to set up interfaces on these machines so that I can also do end-to-end experiments? Thanks, Hitesh ------ End forwarded message ------

1 0

[ugin@ripn.net: Re: RIS & MCK-IX]
by Arife Vural 27 Sep '04

27 Sep '04

Hi Bruce, James, I do not know where we are at RRC13. Installation CD or image should send to people in Moscow. Could you keep in touch with MCK-IX people about installation of RRC13? Arife ----- Forwarded message from Evgueni Kouskevitch <ugin(a)ripn.net> ----- From: Evgueni Kouskevitch <ugin(a)ripn.net> To: Bruce Campbell <bruce.campbell(a)ripe.net> Subject: Re: RIS & MCK-IX Date: Tue, 7 Sep 2004 17:40:28 +0400 Cc: arife(a)ripe.net, NOC RELARN <noc(a)relarn.ru> Hello! Now you can hand your installation CD to Andrei Robatchevski for Alexey Platonov who will be present at Amsterdam until Thursday, September 9. -- Evgueni G. Kouskevitch <ugin(a)ripn.net> Russian Institute for RIPN NOC:+7(095)192-9179 Public Networks ----- End forwarded message -----

1 0