March 2006 - Ris-int - mailman.ripe.net

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

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

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