- Ris-int - mailman.ripe.net

Re: AMBtcEN news
by Ondrej Hamel 02 May '06

02 May '06

Hi, C V P X A L V I I r a m e A A A o n b v L L G z a i i I I R a x e t U S A c n ra M http://www.kvoratizalopan.com mutton again tomorrow, said one of the trolls. Never a blinking bit of manflesh have we had for long enough, said a second. What the ell William was a-thinkin of to bring us into these parts at all, beats me and the drink runnin short, whats more, he said jogging the elbow of William, who was taking a pull at his jug. William choked. Shut yer mouth! he said as soon as he could.

1 0

Fixed config file
by Lorenzo Colitti 02 May '06

02 May '06

Hi James, here is the fixed bgpd config with the route-map. This one should have the proper community values... Cheers, Lorenzo -- Lorenzo Colitti lorenzo(a)ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net ! hostname bgpd password zebra enable password zebra ! router bgp 12654 neighbor 194.146.105.1 remote-as 12654 neighbor 194.146.105.1 next-hop-self neighbor 194.146.105.1 allowas-in ! neighbor 194.68.123.143 remote-as 16150 neighbor 194.68.123.143 description Router as16150 neighbor 194.68.123.143 send-community neighbor 194.68.123.143 route-map as11-out out ! neighbor 194.68.123.109 remote-as 5400 neighbor 194.68.123.109 description Router as5400 neighbor 194.68.123.109 send-community neighbor 194.68.123.109 route-map as21-out out ! neighbor 194.68.123.141 remote-as 13237 neighbor 194.68.123.141 description Router as13237 neighbor 194.68.123.141 send-community neighbor 194.68.123.141 route-map as31-out out ! ip community-list 10 permit 12654:100 ip community-list 11 permit 12654:101 ip community-list 12 permit 12654:102 ip community-list 13 permit 12654:103 ip community-list 14 permit 12654:104 ip community-list 15 permit 12654:105 ip community-list 16 permit 12654:106 ip community-list 17 permit 12654:107 ip community-list 18 permit 12654:108 ip community-list 19 permit 12654:109 ip community-list 41 deny 12654:199 ip community-list 41 permit ! route-map as11-out permit 10 match community 11 set as-path prepend 12654 ! route-map as11-out permit 15 match community 12 set as-path prepend 12654 12654 ! route-map as11-out permit 20 match community 13 set as-path prepend 12654 12654 12654 ! route-map as11-out permit 25 match community 14 set as-path prepend 12654 12654 12654 12654 ! route-map as11-out permit 30 match community 15 set as-path prepend 12654 12654 12654 12654 12654 ! route-map as11-out permit 35 match community 16 set as-path prepend 12654 12654 12654 12654 12654 12654 ! route-map as11-out permit 40 match community 17 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 ! route-map as11-out permit 45 match community 18 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as11-out permit 50 match community 19 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as11-out permit 55 match community 10 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as11-out permit 90 match community 41 ! ip community-list 20 permit 12654:200 ip community-list 21 permit 12654:201 ip community-list 22 permit 12654:202 ip community-list 23 permit 12654:203 ip community-list 24 permit 12654:204 ip community-list 25 permit 12654:205 ip community-list 26 permit 12654:206 ip community-list 27 permit 12654:207 ip community-list 28 permit 12654:208 ip community-list 29 permit 12654:209 ip community-list 42 deny 12654:299 ip community-list 42 permit ! route-map as21-out permit 10 match community 21 set as-path prepend 12654 ! route-map as21-out permit 15 match community 22 set as-path prepend 12654 12654 ! route-map as21-out permit 20 match community 23 set as-path prepend 12654 12654 12654 ! route-map as21-out permit 25 match community 24 set as-path prepend 12654 12654 12654 12654 ! route-map as21-out permit 30 match community 25 set as-path prepend 12654 12654 12654 12654 12654 ! route-map as21-out permit 35 match community 26 set as-path prepend 12654 12654 12654 12654 12654 12654 ! route-map as21-out permit 40 match community 27 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 ! route-map as21-out permit 45 match community 28 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as21-out permit 50 match community 29 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as21-out permit 55 match community 20 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as21-out permit 90 match community 42 ! ! ip community-list 30 permit 12654:300 ip community-list 31 permit 12654:301 ip community-list 32 permit 12654:302 ip community-list 33 permit 12654:303 ip community-list 34 permit 12654:304 ip community-list 35 permit 12654:305 ip community-list 36 permit 12654:306 ip community-list 37 permit 12654:307 ip community-list 38 permit 12654:308 ip community-list 39 permit 12654:309 ip community-list 43 deny 12654:399 ip community-list 43 permit ! route-map as31-out permit 10 match community 31 set as-path prepend 12654 ! route-map as31-out permit 15 match community 32 set as-path prepend 12654 12654 ! route-map as31-out permit 20 match community 33 set as-path prepend 12654 12654 12654 ! route-map as31-out permit 25 match community 34 set as-path prepend 12654 12654 12654 12654 ! route-map as31-out permit 30 match community 35 set as-path prepend 12654 12654 12654 12654 12654 ! route-map as31-out permit 35 match community 36 set as-path prepend 12654 12654 12654 12654 12654 12654 ! route-map as31-out permit 40 match community 37 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 ! route-map as31-out permit 45 match community 38 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as31-out permit 50 match community 39 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as31-out permit 55 match community 30 set as-path prepend 12654 12654 12654 12654 12654 12654 12654 12654 12654 12654 ! route-map as31-out permit 90 match community 43 ! ! log file /var/log/zebra/bgpd.log ! debug bgp debug bgp events debug bgp filters debug bgp fsm debug bgp keepalives debug bgp updates !

1 0

Prepending experiment: meaning of communities
by Lorenzo Colitti 02 May '06

02 May '06

Hi James, here is a hopefully less confusing meaning of the communities we're planning to use: > 12654:10x : Prepend AS12654 x times to AS16150 (RRC07), AS1299 (RRC10), AS6762 (RRC14) > 12654:20x : Prepend AS12654 x times to AS5400 (RRC07), AS9026 (RRC10), and AS6939 (RRC14) > 12654:30x : Prepend AS12654 x times to AS13237 (RRC07), AS12779 (RRC10), and AS2914 (RRC14) > > 12654:199 : Don't announce to AS16150 (RRC07), AS1299 (RRC10), or AS6762 (RRC14) > 12654:299 : Don't announce to AS5400 (RRC07), AS9026 (RRC10), or AS6939 (RRC14) > 12654:399 : Don't announce to AS13237 (RRC07), AS12779 (RRC10), or AS2914 (RRC14) The route-map I gave you is out of date and uses 12654:40x instead of 12654:x99, but the principle is the same. So for example, announcing 84.205.73.0/24 to RRC07 with a community value of "12654:199 12654:202 12654:301" should result in RRC07 announcing nothing at all to AS16150, "12654 12654" to AS5400, and "12654 12654 12654" to AS13237. Since cow announces three different prefixes RRC07, RRC10, and RRC14, this should give us complete control over who we announce to and how much we prepend to each upstream. As far as we can see, these RRCs only have three peers giving transit for the beacon prefixes, but perhaps we need an explicit rule that denies the routes to anyone else... Do you think all this makes sense and could actually work? Cheers, Lorenzo P.S. I attach the setup diagram in powerpoint format for the benefit of others on the list. -- Lorenzo Colitti lorenzo(a)ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net

1 0

prowl assist
by Silas Mckinney 24 Apr '06

24 Apr '06

1 0

peers in Brazil (Re: [ris-int] RIS meeting minutes )
by Rene Wilhelm 21 Apr '06

21 Apr '06

Hi Henk, Arife, > >>help how do it. There is not much point for RIS to have 7 RRCs in > >>LACNIC area. Henk will contact with Milton. > > > >Done, suggested to set up a copy of the RIS in Brazil with our help. > > I got a reply from Milton. > > We agree that for this case, it is best to replicate our RIS and > do the data collection/serving in their area. As you are in touch with the Brazilians, would it be an idea to ask them to do some more, active promotion for the RIS collector we have in Sao Paulo? http://www.ris.ripe.net/peerlist/rrc15.html suggests there are only 3 peers on this collector, a rather disappointing number. -- Rene

2 1

BGP prepending beacon request
by Lorenzo Colitti 21 Apr '06

21 Apr '06

Ok, so here's what we would need to do: 0. Verify that the beacon prefixes 73.0/24 and 89.0/24 are free 1. Send email to them telling them that we will: - Use one RRC (RRC07) - Setup an IBGP peering for them on RRC07 - Relay their announcements - Point them to the software to announce their routes. 2. We ask them to write a short email describing the experiment and their announcement schedule. We tell them that if we don't like it, or if our peers complain, we have to shut the peering down. 3. If they agree, we send out the email to ris-users and our peers on RRC07. If nobody screams, we: - Open firewall for RRC07 if necessary - Configure IBGP peering on RRC07 using the config we already had for my experiments - Set up more detailed filters if necessary - Agree on dates for their experiments 4. On the agreed dates, activate peering 5. When experiment is over, shut down peering Did I miss anything? Cheers, Lorenzo -- Lorenzo Colitti lorenzo(a)ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net

2 2

Conf call with HK polytechnic people on prepending
by Lorenzo Colitti 21 Apr '06

21 Apr '06

Hi, I just had a conference call with Samantha Lo (student) and Rocky Chang (associate professor) from Hong Kong Polytechnic on the prepending research. This email is a status update on what we are doing and what we want to do. Comments/suggestions welcome. Current status -------------- There seems to be good communication and agreement on where to go. Today we discussed which RRCs to announce the test prefixes from. We decided that RRC07 (Stockholm), RRC10 (Milan), and RRC14 (Palo Alto) are the best candidates because they have a realistic number of upstreams and a more balanced AS graph (shown in attached PDF file). We obtain BGP data from the RIS (using my scripts) and from ORV and looking glasses (using scripts by Samantha). In total we have about 150 views of the Internet. This might further be enriched by TTM, but I don't know if I'll have time to implement that. Goals ----- - Submit a paper to IMC 2006 conference (deadline end of May). Author list might be something like Lo, Chang, and Colitti - They also want to present this at nanog in June Proposed setup -------------- Everything will be in the NCC network and under our control: - We have a machine here that peers with the 2 or 3 RRCs involved - The machine runs the Python BGP announcer I wrote and announces communities to the RRCs - The RRCs announce varying degrees of prepending to our transit peers based on the communities they receive. A route-map will be used for this purpose. Next steps ---------- - Samantha will set up a test-lab, write the route-maps and test the setup (this week) - Once we know how long that is going to take, we inform our peers that we will be doing the experiments. - Target: begin experiments soon after RIPE meeting Cheers, Lorenzo -- Lorenzo Colitti lorenzo(a)ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net

1 0

RIS meeting minutes
by arife＠ripe.net 21 Apr '06

21 Apr '06

Attendees: James, Arife, Henk, Lorenzo, Francesco 1. Everyone agrees it's a good idea to have RIS data distributed over the Internet. This needs to be discuss with Andrei and get back to Simon Leinen. (AV) 2. Runing some scripts/tools Geoff has that uses RIS data. Arife will contact with Geoff to run them here. 3. RRC boxes in LACNIC region, we are happy to offer LACNIC people help how do it. There is not much point for RIS to have 7 RRCs in LACNIC area. Henk will contact with Milton. 4. RIS statistics, SED and Comms should look at how much of the statistics we produce are used. If there is no interest, we should stop spending CPU cycles. 5. Beacon request from The Hong Kong Polytechnic University, Lorenzo is in touch with them. He will let us know when do the configuration changes. 6. Having new RRC in NAP of Amreica is a good idea, as long as we get interested parities to peer with us. Josh Snowhorn, Terramark seems to be voluntered to do this. 7. Henk is voluntered to do RIS/TTM presentation in DE-CIX technical meeting. 8. Load on AMS-IX RRC is getting quite high with the number of peers. We should check our budget and get a new box, and share the load between two boxes. Any comments are welcome. -- Arife Vural SED, RIPE NCC

2 2

Fwd: RIS things, was Re: [np] Conf report: Peering Forum
by Henk Uijterwaal 20 Apr '06

20 Apr '06

>Date: Fri, 31 Mar 2006 14:38:49 +0200 >To: Arife Vural <arife(a)ripe.net> >From: Henk Uijterwaal <henk(a)ripe.net> >Subject: RIS things, was Re: [np] Conf report: Peering Forum >Cc: ris > >Hi Arife, > >(Distribution list reduced) > >Thanks, interesting. In case you ever want to do a ris-overview >talk, I do have a presentation on the shelf. (And I also have >generic NCC services talk). Something else: > >2 RIS related things I heard at the IETF: > > 1. Geoff Huston complained that it was hard to download the full > data sets. Simon Leinen suggested in the IEPG to put the data > on bittorrent and even offered 2 machines with diskspace as > servers. I promised to take this up here. > > 2. Geoff showed all kinds of activity plots. Some of them are related > to the hotspots and BGP update plots that we have. I tried to find > them in the meeting but failed. Slightly related: a few weeks ago, > Rene reported that some of the standard plots had not been updated > since December. That means that nobody looked at them for two > months. Which means that they are probably not too useful and we > should consider using the CPU cycles for something else. > > Perhaps we should review the standard set of RIS plots that we > produce, remove what is never used, add new plots and make it a > bit easier to find. > >And at APNIC: > > 3. Milton (RRC15 host) asked about installing 7 or so RRC's in the LACNIC > region. His idea was to have RRC's at all IX's there, so people could > really debug problems in the LACNIC area. > > This is probably a good idea FOR THEM, I just wonder if we should be > operating this. If it is LACNIC specific, then it might be better to > tell then HOW the RIS works and have them copy the system. They > can then operate it themselves. > > I also promised to bring this up internally. > >Perhaps we can meet and discuss all this sometime soon? > >Henk > > > > >At 21:16 27/03/2006, Arife Vural wrote: > >>Conference report: >> >>Conference: Peering Forum >>Date: 18.03.2006 - 23.03.2006 >>Venue: Miami, US >>URL: http://www.peeringforum.com >>Attendee(s): Arife Vural >>Department(s): SED >> >>* Scope of conference: >> >>Everything that's related with Peering >> >> >>* Reason for attendance: >> >>Related with my job >> >> >>* Summary (main aspects & outcome of the conference, personal evaluation >> thereof, impressions, interesting floor talks etc.): >> >>o Met a lot of people peering people. >> >>o Had chat with De-CIX guys. They offered us to have a RIS presentation in >>one of their technical meetings. One is in April and the other one is in >>October. Bernhard KrÃ¶nung is the contact person to discuss the detail more >>He wil be attending RIPE52. >> >>Bernhard also mentioned about OpneBGPD software. They are planing to use on >>their route server. He said it's more stable than Quagga. It does not crash >>so often. It has a mode to configure as route server. That mode allows BGP >>speaker to announce all routes it gets from the peers rather than only the >>best ones. >> >>It might worth to spend some cycles on it to find out pros & cons. >> >>o I got some free transit donation for >>K-anycast server. Thanks Josh Snowhorn, >>Terramark for his help. Some of them already contacted with OPS. With some I >>will contact during the week. Some of those >>guys are also willing to peer with >>RIS. >> >>TeleGlobe, Delhi is offered free transit. I >>think it would be nice to have with >>eBGP on RRC00. We do not have any peers in that part of the world. >> >>o prolexic.com >> >>Those guys are protecting companies from DDos >>attacks. They are doing quite a >>good job chasing the hackers. They work with >>FBI and other organization to track >>them down. It's a small company. When they find >>a site is under DDos attack, by >>using BGP and DNS, they directed to the routes >>on their servers and work on to stop >>the attack, while the original site is up and running. They have quite a few >>customers. >> >>o QoS >> >>There was a panel about QoS effort at IX >>points. Most of IXs do not do anything >>other than watching their bandwith usage statistics. Henk Steenman mentioned >>about TTM box they have at AMS-IX to measure >>the gitter. He said those graphs are >>publicly available. Data&Switch and TeleGlobe >>might consider go such a solution. >> >>I have to contact with them about RIS peering, >>during that time I will send link >>about TTM. >> >>o Next PeeringForum >> >>If there will be Peering Forum next year, it >>would be worth to put a presentation >>about what RIPE NCC does and mention the projects like RIS, TTM and Routing >>Registry Courses and roughly what we do at the RIPE NCC. >> >>Some people have no idea what we do. Some knows >>quite well and ask question like >>what RIPE NCC does with all the money they get. >>I think such 30 mins presentation >>would help to clear those questions. >> >>o ENUM >> >>It looks quite trendy when IXs mention they do >>support ENUM. I do not know exactly >>what kind of works involve from IXs, but it would be worth to coordinate the >>ENUM work (which Katie is doing) with those guys. >> >>o IRR Power Toolset >> >>This is a similar tool like IRR toolset. >>Richard Steenbergen gave a presentation >>about it. The reason he implemented this tool >>is the available one is not compiled >>any of OS(?). >> >>He said quite positive things about the job >>RIPE NCC is doing maintaining the >>Routing Registry and hoped some point in US >>they will have such a well maintained >>DB. >> >>Daved Reader (Zen) mentioned RIPE NCC is doing >>a good job giving Routing Registry >>courses that help people to understand why and >>how they maintain Routing Registry DB. >> >>o IP TV panel >> >>There were panelists from IX points to discuss >>the future of IP TV situations. >>With the available bandwith and architecture >>IXs are not ready to handle such a >>big traffic. Some English attendees brought about BBC and it's IP TV effort. >> >>o BGPlay >> >>It's the most popular RIS tool. I do not think >>it's new. I heard postive feedbacks >>about it again. >> >>o RIS services >> >>Some ideas and suggestions about RIS services: >> >>- A suggestion came to add a telnet interface on RRC boxes >>- RIS does not give the view in US, we should find a way to improve it. >>- Configure a peering session from RouteView (not a bad idea) >>- Companies are looking for some criteria like >>ASpath length to adjust their filters >>at IX points. Especially, US ones since they do >>not have RR DB in ARIN area. I do >>not know how RIS can be useful in such effort. >> >>AOB >> >>o KIX (Korean Internet Exchange point) is biggest IX point, traffic vice. >>o AMS-IX is the biggest IX point, number of members, heading ahead LINX >>o LINX or LINX members are not so keen on PeeringForum, they did not >>sponsor it this year. There was not any LINX >>employee tt Peering Forum this year. >>o Jay Adelson (founder) left Equnix. He is a >>spokesman for Equnix for a while. >>He has his own compnay, digg.com. >>o There is a new content provider in the market >>like Akamai, Limelight. They are >>growing quite fast. They are happy to donate free transit to K-anycast. >>o AMS-IX and France Telecom are the only one >>who provides 10G ports. The other >>IXs are putting some effort to provide 10G ports, as well. >> >>Regards, >>Arife Vural > >------------------------------------------------------------------------------ >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 >------------------------------------------------------------------------------ > >1160438400. Watch this space... ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400. Watch this space...

3 3

RIS Analaysis page
by Rene Wilhelm 13 Apr '06

13 Apr '06

Hi, The web page which lists external analysis done with RIS, http://www.ripe.net/ris/docs/analysis.html is very hard to locate when navigating through the RIS part of the ripe.net website. As far as I can see, the only place it is mentioned is at the bottom of the (quite lengthy) "RIS Raw data" page Can we not add a label/link to the RIS menu in the left pane? The analysis page is part of RIS PR, showing people the project also has value to the research community. It should be easy to find. As for the page itself, I'd think this line If you are using our data and have published a paper, please send us an email and you will be added to this list. better moves to the beginning of the page. It makes it more obvious to readers how to contact us for having their paper listed. Cheers, -- Rene

2 1

Fwd: Christmas report
by Henk Uijterwaal 12 Apr '06

12 Apr '06

FYI, Henk >X-Original-To: henk(a)ripe.net >Delivered-To: henk(a)ripe.net >Date: Wed, 12 Apr 2006 14:19:18 +0200 >From: Attila Miklos <Attila.miklos(a)ripe.net> >User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) >X-Accept-Language: en-us, en >To: henk(a)ripe.net >Subject: Christmas report > >hello Henk, > >Here is the final version of my christmas report. > >Attila > ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400. Watch this space...

1 0

Question from eBay Member -- Respond Now
by aw-confirm＠eBay.com 03 Apr '06

03 Apr '06

1 0

Re: maLoy50 news
by Comfort Weyer 25 Mar '06

25 Mar '06

Hi Do you want to OVER P A Y for your MEDs ? Nothing like you need it, S A V E yourself 50 % with http://www.ellorthecin.com \/ \/ C A I l L A A l G L U R I M A S $ $ $ 8 6 6 5 9 7 , , , 4 9 5 5 5 0

1 0

Re: NCC#2006021124 [RIS Lease-A-Beacon Request]
by Lorenzo Colitti 23 Mar '06

23 Mar '06

RIS Beacon Request User wrote: > We are studying properties of AS Path Prepending which is > a popular inbound traffic engineering method. We propose an active > measurement method to measure the impact of ASPP method under > different prepending lengths and strategies. > [...] > pattern : We would like prefix to have the following A/W pattern: > Set1 (prepending on the link to AS20483) > Day1 > A: 00:00 : prepending length =0 > W: 02:00 > A: 04:00 : prepending length=1 > W: 06:00 > A: 08:00 : prepending length=2 > W: 10:00 > [...] Dear Samantha, apologies for the delay in replying, we have been busy with other cases. We are discussing this internally and should be able to give you an answer early next week. Regards, Lorenzo -- Lorenzo Colitti lorenzo(a)ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net

3 9

You've received a greeting from a family member!
by postcards1001 15 Mar '06

15 Mar '06

1 0

You've received a greeting from a family member!
by postcards1001 15 Mar '06

15 Mar '06

1 0

�T�C�g�ʂɃf�[�^�ƍU��@��L��
by isnmvajka＠kobej.zzn.com 14 Mar '06

14 Mar '06

�� @�@��@Deai��̂��m�点�@�� @�@�@�@�@�@�@�@�@�V��ɕK�v�Ȃ��̂�GET��悤�I�I �@�@�@�@�@�@�@�@�@�@�@�@http://www.ai-love-you.net/tv/ �� ==INDEX======================================================== �y_1_�z��ɂ��A��̏o��T�C�g�̂�50�T�C�g�ȏ�Љ� �y_2_�z��̓��W�@�w�{�C�ŏo��Ȃ�x �y_3_�z��Ȕގ��ق��@�X��C��^�r��[ �y_4_�z�l�C�}�㏸��@��Έ��E�E�E�B �y_5_�z�h��ق��āE�E�E�s�ϊ�]�I�I �y_6_�z�V��o��l�̏o��n�@�@http://www.ai-love-you.net/tv/ =============================================================== �@��s�ρE�n�k�E�Ō�w�E�w��E��E�l�ȁE��F�� e�W��Ƃɕ��ނ��M��D�݂̏��T��o��I�I 24��ԑΉ��Ȃ̂ł��D��ȂƂ��ɂf�n�I�I ��l�b�g�i��p�n�L��y�[��{�\�� @http://www.ai-love-you.net/tv/ ---------------------------------------------------------------------- �o�^��]�̕��́A��萔�ł��L��肢��܂�m(_ _)m ��@Unsubscribe mail service�@�� (http://www.ai-love-you.net/tv/release.php) ----------------------------------------------------------------------

1 0

Introduction of 4-byte ASN: RIS & TTM view
by Rene Wilhelm 14 Mar '06

14 Mar '06

Leo, Attached is the XLS sheet with, as far as I can see, the list of things that needs to be done in RIS and TTM to be able to handle 4-byte long AS numbers in the routing system. -- Rene

1 0

quagga & 4-byte ASN support
by Rene Wilhelm 13 Mar '06

13 Mar '06

Searching for the status of 4-byte ASN support in quagga I couldn't see a word on this in the official mailing lists at http://lists.quagga.net/ But after a little googling I found Paul Jamka's weblog http://blogs.sun.com/roller/page/paulj?catname=%2FNetworking which (in the March 10 entry) says: The short answer is that Quagga is part-way towards 4-byte ASN support [...] That leaves the following (generally) as still to be implemented: 1. The 4-byte-supported BGP capability 2. Extending the unit tests with equivalent 4-byte forms and verifying the AS_PATH parser and transformational functions. 3. Using the appropriate encoding for AS_PATH according to the remote peer 4. Adding support for the 2<->4 byte transition mechanisms (unit tests implied) 1, 2 and 3 should be quite easy, 2 weeks about, including testing, and would get bgpd to the stage which the draft RFC calls a "NEW" speaker and interoperate fully with other "NEW" speakers. It would also be able to speak to "OLD" peers, provided no 4-byte wide ASNs are involved. Support for these items I hope to see in Quagga before the end of the year. That leaves 4, which isn't as easy, further I am not very optimistic on its chances of working. I suspect the internet would be in trouble if we end up relying on the 4-byte transition mechanism to work. I really hope all deployed speakers of significance end up being upgraded to "NEW" (ie corresponding to at least 1,2 and 3 above) well before the first 4-byte ASNs are issued, so that we never have to find out how well the transition mechanisms might work.. His hopes may prove faint, especially when (according to the proposed policy) RIRs start allocating/assigning 4-byte ASNs by default come 1/1/2009; it'll be interesting times. However, it is clear the issue has the quagga author(s) attention; there's no need for RIPE NCC to step in. -- Rene P.S. Interesting side fact: the last real Quagga died in Artis, Amsterdam's zoo, some 123 years ago. :)

2 2

[paul@clubi.ie: Re: RIPE RIS / Quagga]
by arife＠ripe.net 13 Mar '06

13 Mar '06

----- Forwarded message from Paul Jakma <paul(a)clubi.ie> ----- From: Paul Jakma <paul(a)clubi.ie> To: Arife Vural <arife(a)ripe.net> Subject: Re: RIPE RIS / Quagga Date: Wed, 8 Mar 2006 13:53:18 +0000 (GMT) Mail-Followup-To: paul(a)hibernia.jakma.org On Wed, 8 Mar 2006, Arife Vural wrote: >We run Quagga 0.96.5. I think we have that version more than a >year. Wow. :) I think it has an IPv6 attribute related DoS btw. At least, the SIXXS ghosthunter had to upgrade to 0.98 because someone was injecting something into global IPv6 that took down old 0.96ish bgpd's. >Until now, we did not have any big performance problem related with >Quagga. We have to run mySQL and DBinsert on route collectors in >addition to Quagga to insert data into DB. We had a memory leak in >DBinsert process, it was eating up the all memory and was killing >the deamons including bgpd. We kind of get round that problem. Now, >bgpd seems to be quite OK. :) >We have problem only on RRC03 (AMS-IX). It's the biggest route >collector. It has peering session about 130. Only thing, I observe >is the bgpd response time. It is bit slow. It takes a while (less >than a minute) to configure a session. Interesting. >But be honest, I do not know how bgp traffic is effected with this >slowness. We do not have tool to check the consistency of BGP >updates. Until now, I have not heard any comment from our users >about complaining the consistency of the data. Consistency is probably good. What you may notice is that sometimes sessions drop for no apparent reason (typically co-inciding with the telnet interface being unresponsive). This we have, I think, fixed. >We have looking glass here, please have a look at and decide which >RRC will be a good example for you, than I will try to provide you >the performance graph of that RRC. The ones I'm interested in are: RRC01 (Linx) RRC03 (AMS-IX) I'm particularly interested in the following outputs: >From bgpd's telnet interface: - 'show memory bgp' - 'show memory lib' - 'show ip bgp sum' (at the time above are taken) >From your operating system (in whatever way): - the total memory usage of bgpd That would be *very* informative. We intend to try bgpd on a diet - there's some low-hanging fruit and I think we can easily reduce usage by 10% or so. Output from RRC01 and RRC03 would be very useful in determining where else "dieting" would have biggest effect on bgpd (both RRC's if possible -> so we can see how objects scale with number of sessions / prefixes / paths). That would be *great* if you could provide that. :) >I just checked the performance graphs some of them are missing, but >I'm sure we can find one that will be useful for you. We use Orca >tool to get performance graphs I hope it would be useful for you. Very neat. >This is the "show thread cpu" from RRC03. > >rrc03> show thread cpu >Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread >2165490.000 7184 301432 36150000 T bgp_dump_interval_func >1537621.376 35511 43299 4710000 T bgp_scan >3676941.376 60175283 61 4570000 E bgp_event > 229430.000 384 597473 3850000 T bgp_holdtime_timer >1900803.568 142918849 13 36150000 RWTEX TOTAL Interesting, bgp_dump_interval_func() took the longest. We should probably run it as a child process, if possible. >If you like to see the output of the other RRCs, please let me know. >BTW, we do not run zebra daemon. I would have thought so. Avoids bulk of the performance problems too. >About using the new version, I think we are bit conservative. >Until, we have problem or a security issue, we are happy to using >old version. Ok. >BTW 2, I have a question for you. Is there any plan about implementing >32bit AS number in Quagga? Yes, the internal AS_PATH parsing code was partially rewritten late last year to make the internal representation of AS_PATHs indepedent of the wire format, specifically in order to make it ready (internally) for 4-byte ASNs. Ie the internal format is now just a change of a typedef away from 4-byte ASNs. (We also have, with that rewrite, an extensive set of AS_PATH code exercising unit tests to verify nothing breaks). Didn't yet get as far as adding support for the 4-byte capability or its required attributes, or the transition mechanism of NEW_AS_PATH (and unit tests to verify them). Later this year hopefully. regards, -- Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A Fortune: You will be dead within a year. ----- End forwarded message ----- -- Arife Vural SED, RIPE NCC

1 0

RIS Report and Host Spots stats no longer updated ...
by Rene Wilhelm 10 Mar '06

10 Mar '06

Hi, It looks like the RIS Reports (IP v4 & v6) pages on http://www.ripe.net/projects/ris/stats/index.html are no longer updated automagically. random picks show *all* graphs on pages like http://www.ris.ripe.net/risreport/rrc03/193.148.15.204/bgpcount.html have a label "(2005-12-04)" which suggests they haven't seen an update since Sinterklaas left the country. Most of these gifs seem to be empty too (any rrc, any peer). Similarly, the last entries on the BGP Hotspots page http://www.ris.ripe.net/topten/ are from Nov 2005. No hyperlinks for Dec 2005, nothing listed for 2006. Can you have a look what's happening? Maybe related to moving the website from Halfweg to the new lama? Cheers, -- Rene

1 0

Fw: NCC#2006021124 [RIS Lease-A-Beacon Request]
by RIPE NCC RIS 09 Mar '06

09 Mar '06

Hi, I'd like to ask your view on this request. At the moment there are no available beacon prefixes that can be used for this experiment. So, we need to decide if we wish to support this user in his research and if so, we need to submit a request to RS for a new RIS beacon IP range. What do you think? I informed the user that we are discussing this case internally and will let them know when we have a solution (or not). Thanks, Vasco Asturiano -------------------------- Software Engineering Dept. RIPE-NCC ----- Begin forwarded message ----- Date: Thu, 9 Feb 2006 15:20:21 +0000 (UTC) From: RIS Beacon Request User <risops(a)ripe.net> To: ris(a)ripe.net Subject: NCC#2006021124 RIS Lease-A-Beacon Request Message-Id: <20060209152021.D7D724B959(a)lama.ripe.net> name : Samantha Sau Man Lo contact : cssmlo(a)comp.polyu.edu.hk org : The Hong Kong Polytechnic University comments : We are studying properties of AS Path Prepending which is a popular inbound traffic engineering method. We propose an active measurement method to measure the impact of ASPP method under different prepending lengths and strategies. We applied it on a dual-homed, stub AS. We announce a prefix(/21) to both upstream ASes. But the announcement to one of the upstream AS, we applied different prepending length. After prepended once, we observe the route changes from different looking glasses (we have the script to collect the route changes from different looking glasses). However, we would like to perform the active measurement from other sites to see the effect. Here is the extended abstract appeared in ICNP2005: http://csr.bu.edu/icnp2005/Posters/Lo.pdf beacons : 2 RRC : RRC00 RRC : RRC01 RRC : RRC02 RRC : RRC03 RRC : RRC04 RRC : RRC05 RRC : RRC06 RRC : RRC07 RRC : RRC08 RRC : RRC10 RRC : RRC11 pattern : We would like prefix to have the following A/W pattern: Set1 (prepending on the link to AS20483) Day1 A: 00:00 : prepending length =0 W: 02:00 A: 04:00 : prepending length=1 W: 06:00 A: 08:00 : prepending length=2 W: 10:00 A: 12:00 : prepending length=3 W: 14:00 A: 16:00 : prepending length=4 W: 18:00 A: 20:00 : prepending length=5 W: 22:00 Day2 A: 00:00 : prepending length=6 W: 02:00 A: 04:00 : prepending length=7 W: 06:00 A: 08:00 : prepending length=8 W: 10:00 A: 12:00 : prepending length=9 W: 14:00 A: 16:00 : prepending length=10 W: 18:00 A: 20:00 : prepending length=11 W: 22:00 Day3 A: 00:00 : prepending length=10 W: 02:00 A: 04:00 : prepending length=9 W: 06:00 A: 08:00 : prepending length=8 W: 10:00 A: 12:00 : prepending length=7 W: 14:00 A: 16:00 : prepending length=6 W: 18:00 A: 20:00 : prepending length=5 W: 22:00 Day4 A: 00:00 : prepending length=4 W: 02:00 A: 04:00 : prepending length=3 W: 06:00 A: 08:00 : prepending length=2 W: 10:00 A: 12:00 : prepending length=1 W: 14:00 A: 16:00 : prepending length=0 W: 18:00 ------ Set2 (prepending on the link to AS3277) Day1 A: 00:00 : prepending length =0 W: 02:00 A: 04:00 : prepending length=1 W: 06:00 A: 08:00 : prepending length=2 W: 10:00 A: 12:00 : prepending length=3 W: 14:00 A: 16:00 : prepending length=4 W: 18:00 A: 20:00 : prepending length=5 W: 22:00 Day2 A: 00:00 : prepending length=6 W: 02:00 A: 04:00 : prepending length=7 W: 06:00 A: 08:00 : prepending length=8 W: 10:00 A: 12:00 : prepending length=9 W: 14:00 A: 16:00 : prepending length=10 W: 18:00 A: 20:00 : prepending length=11 W: 22:00 Day3 A: 00:00 : prepending length=10 W: 02:00 A: 04:00 : prepending length=9 W: 06:00 A: 08:00 : prepending length=8 W: 10:00 A: 12:00 : prepending length=7 W: 14:00 A: 16:00 : prepending length=6 W: 18:00 A: 20:00 : prepending length=5 W: 22:00 Day4 A: 00:00 : prepending length=4 W: 02:00 A: 04:00 : prepending length=3 W: 06:00 A: 08:00 : prepending length=2 W: 10:00 A: 12:00 : prepending length=1 W: 14:00 A: 16:00 : prepending length=0 W: 18:00 They are subjected to change. Sending host [158.132.12.81]. Agent Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 1.0.3705). ------ End forwarded message ------ --

4 8

Chase Card Services Online Services Team
by Chase 27 Feb '06

27 Feb '06

1 0

��ɂȂ�܂�
by risorrio＠walla.com 23 Feb '06

23 Feb '06

��Ȃ��݁w�o��U��S�x�ł��I �߂��ኮ��ȁy��S�D�ǃT�C�g�z��ł�v(^^)v��ł��m�点��܂��m(_ _)m http://speedofsound.weedns.com/ ��o�^�s�v�I��[��M�\�I ��S��؂Ȃ��̊��S�� r��(��Ȃ̂œ��R�ł��) ��Ȃ̂ɏ��̃��X�� Ȃ�d�v ��y�X�ڍ׌��ȂǕ֗��@�\�� http://speedofsound.weedns.com/ �� w�ǉ�� w�ǉ��]�̕��́A��萔�ł��L��w�ǉ��o�^��B I don't veceive your mail http://speedofsound.weedns.com/1/rejectb1.php ��[��s�v http://speedofsound.weedns.com/1/rejectb1.php ��

1 0

RFC4384 community strings for RIS
by Henk Uijterwaal 23 Feb '06

23 Feb '06

Arife, Shane, In case you didn't notice: the RFC on BGP communities for data collection was published last week (RFC4384). The idea is to tag routes collected by routeviews, RIS and others with specific values in order to specify what they are. This should make life easier for people doing research. I think it'd be good if we encourage the RIS peers to use those values. Steps that I see: 1. Summarize RFC, so people know what to put in without having to read the whole document. (Ask comms for help?) 2. Put this information on the web. 3. Email information to peers. 4. Ask people to use those values. 1 day of work, not very urgent, but useful. Is this something you can pick up? 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 ------------------------------------------------------------------------------ 1160438400. Watch this space...

2 1