- Ris-int - mailman.ripe.net

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