- 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