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

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

http://www4.ripe.net/ris/
by Matthew Williams 02 Sep '04

02 Sep '04

Hi there, Did a little more work there. Pls check it out. We should probably plan one more meeting (dedicated afternoon?) for going through the final stuff. Cheers, Matthew

2 4

R: Kernel on RRC06
by Arife Vural 31 Aug '04

31 Aug '04

Hereby I wish to request a service from Operations. Detailed description: --------------------- MD5 support on RRC06 does not work and I'm just wondering whether we still use the kernel that Japan guy compiled. If this is the case, then MD5 might not be enabled on RRC06 properly. Few other things which are related with rrc rsync schema, I got this warning when I run ps command on RRCs, arife@rrc06:~$ ps aux |grep bgpd {sys_alarm} {register_sysctl_table} Warning: /System.map does not match kernel data. quagga 253 0.3 3.9 39948 36072 ? S Jun23 326:06 /usr/lib/quagga/bgpd --daemon arife 14412 0.0 0.0 1516 480 ttyp1 S 16:15 0:00 grep bgpd Anything to be worried or not? Also could you please change the owner of /etc/quagga dirs to quagga user and group? It's owned by root and when you make bgp config changes, it's not allowed to save the config. Regards, Arife Vural

1 0

bgpd dies
by James Aldridge 31 Aug '04

31 Aug '04

http://bugzilla.quagga.net/show_bug.cgi?id=103 We seem to be seeing this bug too. Don't know whether it's a Linux thing or a Quagga version 0.96.5 thing... worth keeping an eye on the quagga-users and quagga-dev lists. James

2 2

IPv6 updates plots
by James Aldridge 31 Aug '04

31 Aug '04

Take a look at http://www.ris.ripe.net/ipv6-updates/all/ (or any of the individual RRC's plots) and you'll see a certain periodicity about the graph. It seems that the RRD is only getting about half the data: 5 minutes and 35 minutes past each hour: weesp runs the "collect" script and pushes the raw files to halfweg. 0 minutes past each hour: halfweg runs the "ipv6-updates/update.sh" script looking for files from the "previous hour" (date -d "1 hour ago" +"%Y%m%d.%H"). However, at this time, only files up to the last run of "collect" (25 minutes earlier) are present - YYYYMMDD.HH00 to YYYYMMDD.HH35. Next time "update.sh" runs, an hour later, it again only looks at files from the previous hour (and not the missing files from the hour before that). Data from the last 25 minutes of each hour are never inserted into the RRD. A solution to this would be for risops@halfweg's crontab to run the "ipv6-updates/update.sh" sufficiently long after 5 minutes past the hour for the "collect" run on weesp to have pushed all the previous hour's files to halfweg. Thoughts? James

2 1

Tool to check RIS peering status
by James Aldridge 30 Aug '04

30 Aug '04

~risops/bin/peerstat is a simple script to report BGP peering status Examples: "peerstat all -lt 300" will show all peers which have changed state within 5 minutes (300 seconds) - typically peers which are flapping. risops@halfweg:~$ peerstat all -lt 300 AS20940 [ 195.66.224.168 ] on rrc01 DOWN for 0w 0d 0h 0m 4s (4 seconds) AS12222 [ 198.32.160.47 ] on rrc11 UP for 0w 0d 0h 0m 10s (10 seconds) "peerstat rrc00,rrc01 -gt 86400" will show all peers on rrc00 and rrc01 which have been down for more than 86400 seconds (1 day): risops@halfweg:~$ peerstat rrc00,rrc01 -gt 86400 AS3257 [ 195.69.144.85 ] on rrc00 down "for ever" AS15861 [ 195.66.224.40 ] on rrc01 down "for ever" AS5604 [ 195.66.224.41 ] on rrc01 down "for ever" AS1299 [ 195.66.224.48 ] on rrc01 down "for ever" AS12513 [ 195.66.224.117 ] on rrc01 down "for ever" AS15861 [ 195.66.226.40 ] on rrc01 down "for ever" AS8272 [ 195.66.226.47 ] on rrc01 down "for ever" AS2818 [ 195.66.226.103 ] on rrc01 DOWN for 5w 6d 19h 0m 0s (3610800 seconds) AS8210 [ 195.66.226.107 ] on rrc01 DOWN for 2w 3d 6h 0m 0s (1490400 seconds) AS12390 [ 195.66.226.119 ] on rrc01 down "for ever" AS13127 [ 195.66.226.142 ] on rrc01 DOWN for 2w 6d 11h 0m 0s (1767600 seconds) "peerstat rrc08 -gt 2419200" will show all peers on rrc08 which have been down for more than 2419200 seconds (4 weeks): risops@halfweg:~$ peerstat rrc08 -gt 2419200 AS2551 [ 198.32.200.14 ] on rrc08 down "for ever" James

1 0

Fw: NCC#2004081420 [RIPE beacon request!]
by RIS 30 Aug '04

30 Aug '04

Hi guys, What do you think about the following request? It looks he is asking to extend our anycast failover scenario to more RRCs. After discussing with him what kind of patterns he needs, we can use same prefix or we can use one of the free Beacon Prefixes. Arife ----- Begin forwarded message ----- Date: Fri, 13 Aug 2004 20:39:14 -0400 From: "Hitesh Ballani" <hitesh(a)cs.cornell.edu> To: <ris(a)ripe.net> Subject: NCC#2004081420 RIPE beacon request! Message-Id: <81224EA6DDA07C43BC7555E32401029E054219(a)EXCHVS2.cs.cornell.edu> Hello, I was wondering if you could spare a beacon for the following experiment: At the moment, one of your beacons (195.80.233.0/24) at advertised from 2 locations - LINX and AMS-IX. An interesting question is to study anycast fail-over time from an end user perspective - i.e given that the advertisement is withdrawn from AMS-IX at a particular instant, how long is it before convergence is reached and packets from a node, which were earlier being routed to AMS-IX, are routed to LINX. I tried running this experiment from a bunch of nodes on Planetlab but I have not been able to locate any node whose packets are routed to AMS-IX and so, I am never able to analyze the convergence time (for that matter, even nodes in Netherlands have their packets routed to LINX). Here, "packets being routed to LINX" implies that periodic traceroutes from my Planetlab sites show so. This is important to me as I am currently working an a proxy based deployment model for IP anycast and so anycast failover time through BGP is critical for me (see http://www.cs.cornell.edu/People/francis/pias.pdf and http://www.cs.cornell.edu/People/francis/pias/pias-worlds.pdf for details!). As a matter of fact we are in the process of obtaining 3 /22 blocks from ARIN for this very purpose - however, given the long drawn nature of that process, I thought it would be nice if I could use your advertisement infrastructure to answer some niggling questions which are critical for the success of our proposal. I was wondering if it would be possible for me to get a beacon to be advertised from more locations (ideally, from America(RRC08), Europe(a number of locations), and Asia(RRC06)). While a beacon being advertised from 2 locations would suffice for the above experiment, but advertisements from more than 2 locations would allow me to look at other stuff such as - How good is IP anycast at selecting nearby locations? Ideally, when a node sends out a packet to a anycast location, it should be routed to the destination which is closest - but with the policy based nature of BGP, it is not clear if it does. Such an experiment would make more sense with greater number of advertising locations. I tried determining answers to these questions using the anycasted root servers and the servers belonging to the AS-112 project but the hierarchical nature of their deployment prevents me from coming to any conclusions. While the above description may sound as if I am looking for just an end-user analysis, but I will also be looking at BGP updates for the anycast prefix to determine if advertising a prefix from many locations has an adverse impact on the visibility of the prefix due to reasons such as route flap dampening. If the above description sounds terribly confusing, I will be glad to provide additional details about the experiments I plan to run. Also, if such an arrangement is possible, I will plan out the detailed A/W pattern and the sites involved. Thanks, Hitesh ------ End forwarded message ------

4 4

RRC06
by Henk Uijterwaal (RIPE NCC) 27 Aug '04

27 Aug '04

Hi, Mainly FYI. I had an action on myself to contact Akiro Kato re: more peerings at the Japan RRC. He suggested a couple of mailing lists to write to. I did that yesterday, if you see a flurry of peering requests from there, blame me. If you don't, blame me as well ;-) 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent).

1 0

Fw: NCC#2004081626 [Re: Test allocations]
by RIPE NCC RIS 26 Aug '04

26 Aug '04

Hello RIS-all, As a request from RS, we stopped announcing the following prefixes through the RIS AS number on 18/08/2004: 85.192.0.0/16 85.255.248.0/21 But it appears that yesterday we restarted to announce the same prefixes. Can it be that some old configuration showed up again? What should be done to cancel these announcements? Vasco Asturiano ----- Begin forwarded message ----- Date: Thu, 26 Aug 2004 12:55:56 +0200 From: Mike Petuschak <mike(a)ripe.net> To: RIS <ris-request(a)ripe.net> Subject: Re: NCC#2004081626 Test allocations Cc: Pierre Baume <pierre(a)ripe.net>, Timothy Lowe <timothy(a)ripe.net> Message-Id: <20040826105556.GA30815(a)ripe.net> Hi, It looks like you started announcing the ranges from 85/8 once again, could you please remove them? > whois -h riswhois.ripe.net -M 85.192/10 % This is RIPE NCC's Routing Information Service % whois gateway to collected BGP Routing Tables % IPv4 or IPv6 address to origin prefix match % % For more information visit http://www.ripe.net/ris/riswhois.html route: 85.192.0.0/16 origin: AS12654 descr: RIPE-NCC-RIS-AS RIPE NCC RIS Project. lastupd-frst: 2004-08-17 09:00Z 195.69.144.234@rrc03 lastupd-last: 2004-08-24 21:37Z 80.81.192.126@rrc12 seen-at: rrc03,rrc04,rrc07,rrc12 num-rispeers: 7 source: RISWHOIS route: 85.255.248.0/21 origin: AS12654 descr: RIPE-NCC-RIS-AS RIPE NCC RIS Project. lastupd-frst: 2004-08-17 09:00Z 195.69.144.234@rrc03 lastupd-last: 2004-08-24 21:37Z 80.81.192.126@rrc12 seen-at: rrc03,rrc04,rrc07,rrc12 num-rispeers: 7 source: RISWHOIS -- Sincerely, Mike Petuschak RIPE NCC > Dear Arife, > > Please only remove the ranges from 85/8, i.e. > network 85.192.0.0/16 > network 85.255.248.0/21 > > the following route objects needs to be removed too: > > route: 85.192.0.0/16 > descr: RIPE-NCC-RIS New Allocation Filter Checking > origin: AS12654 > mnt-by: RIPE-NCC-RIS-MNT > changed: risops(a)ripe.net 20040402 > source: RIPE > > route: 85.255.248.0/21 > descr: RIPE-NCC-RIS New Allocation Filter Checking > origin: AS12654 > mnt-by: RIPE-NCC-RIS-MNT > changed: risops(a)ripe.net 20040402 > source: RIPE > > > > > >> It looks we are announcing the following networks, do you want >> me to remove all? >> >> network 85.192.0.0/16 >> network 85.255.248.0/21 >> network 86.192.0.0/16 >> network 86.255.248.0/21 >> network 87.192.0.0/16 >> network 87.255.248.0/21 >> network 88.192.0.0/16 >> network 88.255.248.0/21 >> >> Arife >> >> On Tue, 17 Aug 2004 09:41:13 +0200, Mike Petuschak wrote: >>> Dear RIS, >>> >>> As both James & Daniel are on holidays, >>> can somebody else please stop announcing the >>> ranges from 85/8 and remove the route objects? >>> >>> Thanks a lot. >>> >>> -- >>> Mike >>> >>> ----- Forwarded message from Mike Petuschak <mike(a)ripe.net> ----- >>> >>> Date: Tue, 10 Aug 2004 16:38:15 +0200 >>> From: Mike Petuschak <mike(a)ripe.net> >>> To: James Aldridge <james(a)ripe.net> >>> Cc: Daniel Karrenberg <dfk(a)ripe.net>, lsd(a)ripe.net, >>> Pierre Baume <pierre(a)ripe.net> >>> Subject: Re: Test allocations >>> >>> Dear James, >>> >>> Could you please stop announcing the ranges from 85/8 and remove the route >>> objects? We allocated first /12 from 85/8. ------ End forwarded message ------ --

1 0

RE: myASn in training
by Matthew Williams 25 Aug '04

25 Aug '04

> yes, i can! Excellent :) Cheers, Matthew > -----Original Message----- > From: Vesna Manojlovic [mailto:BECHA@ripe.net] > Sent: 25 August 2004 09:20 > To: Matthew Williams > Subject: Re: myASn in training > > > hi matthew, > > > On Tue, 24 Aug 2004 19:39:44 +0200 > "Matthew Williams" <matthew(a)ripe.net> wrote: > > > Hi Vesna, > > > > Do you now know whether you can join the meeting (see ctime)? > > > > yes, i can! > > > > I would like to know this before I go to Can next week. > > > > have a good time :) > > > Cheers, > > Matthew > > > thanks, > b >

1 0