September 2004 - Ris-int - mailman.ripe.net

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