- Ris-int - mailman.ripe.net

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