- myasntesting - mailman.ripe.net

NOTIFICATION: myASn inaccessable from 4pm, CET, today (09.07.2004) , until 10am, CET, on Monday (12.07.2004)
by Matthew Williams 09 Jul '04

09 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, Due to a code update of the myASn beta, users will not be able to access the system over the weekend. We also expect that notifications during the maintenance window may be unreliable, and probably better ignored. The update and the following testing will commence at 4pm, CET, today (09.07.2004) and be completed by 10am, CET, on Monday (12.07.2004). Apologies for the short notice. Kind regards, Matthew Williams --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/ -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQO6Z5sHkFbJe+GdoEQKomgCgtuNeg3IHx3TEyIUilZgq0qMQc7wAn0Ex eFOtVISez4CTTvb2zuPhNvQW =1COI -----END PGP SIGNATURE-----

1 0

RE: myASn Account Created
by Matthew Williams 07 Jul '04

07 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, myASn has to detect an update from a RIS peer somewhere that 'conflicts' with your configuration. Check one of the 'bogus' prefixes in BGPlay for the time period that that alarm was configured. If you see activity there that you feel should have triggered an event, which you didn't see in 'pending events' on the 'Manage Alarms' page or 'view details' on the 'View Alarms' page, then we would have to dig deeper to see whether it's a bug. You can use one of the RIS routing beacon as a reference (originated from AS12654), just to make sure that the myASn system is actually doing something. The list of prefixes is available here: http://www.ripe.net/ris/beaconlist.html Please note that syslog will report conflicting 'events' rather than 'alarms', and that the feature is very experimental at this stage. Thanks for testing myASn! Kind regards, Matthew Williams > -----Original Message----- > From: Hroi Sigurdsson [mailto:hroi@ngdc.net] > Sent: 06 July 2004 19:51 > To: risops(a)ripe.net > Subject: Re: myASn Account Created > > > Thanks. > > I created two bogus alarms just for testing, but I don't get > alerts? Alarm 741 and 742 are bogus. > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQOwS5cHkFbJe+GdoEQL6HACfQzS9znECa/P6rhU9KNQBVQynU/gAn2fJ CS2EKxjdAdQ+aa3LDJKyB0sx =yAQY -----END PGP SIGNATURE-----

1 0

NOTIFICATION: Old myASn Prototype Deprecated
by Matthew Williams 05 Jul '04

05 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, We will be turning off the old prototype at URL: http://www.ris.ripe.net/cgi-bin/myas/index.cgi on Friday, the 9th of July, 2004. The current beta is available here: http://www.ris.ripe.net/myasn.html. Just type in your old account information from the previous myASn prototype in the following format (without apostrophes): U: 'user@asn' PW: 'old password' There is a tool in this newer version of myASn, which allows you to import origin alarms into the configuration. Alas, the other alarm types could not be included due to design changes. Thanks for testing myASn. Your comments are more than welcome. Kind regards, The RIS Team --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/ -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQOkedcHkFbJe+GdoEQK79gCeOxN/AbisyC88LpUD+FisVcwkRrUAoOqZ jNHaLfm32jpAyrUDc75ZkCyG =aJvw -----END PGP SIGNATURE-----

1 0

FW: [myasntesting] New alarm types (proposal)
by Matthew Williams 30 Jun '04

30 Jun '04

Hi there, This is the kind of feedback that we need :) > Expected Transit Alarm > > A Transit Alarm currently goes off when a prefix/AS appears to receive > transit from an unspecified provider. Our peering relationships are > complex, with multiple upstreams and presence at multiple At some point, the intention is to provide tighter integration with the RIPE db and IRR; eg enable the user to pull/import AS_sets and Route_sets into the myASn system. In the longer term, we'd also like to add myASn to the LIR portal. Other ideas are welcome. > exchanges. It would be complex to list and maintain our entire peering > structure in myasn. > > An Expected Transit Alarm would sound when a prefix/AS _doesn't_ > recieve transit from a _specified_ provider. It seems to me that you'd like a visibility type alarm with the option to match/don't match the regular expression and AS_path. We will definitely incorporate a visibility alarms in the near future. We have had many folk requesting this functionality (see 'requested features' after logging in). Exactly how has yet to be dwelled upon. I think we should look into your proposed alarm type. > > (The difficulty with this alarm is, of course, that perhaps your > routing beacons do not ever see the expected AS path.) > > > Comparision Alarms > > This would allow you to specify groups of prefixs that ought to have > idenitical AS paths, past a specified (common) point. > > For example: AS1 is providing identical global transit to AS's 2, 3 > and 4, and identical partial transit to AS's 5, 6, 7. For the global > transit after ^2_1_ , ^3_1_ and ^4_1 the paths seen should be > idenitcal. Likewise for ^5_1_ , ^6_1_ and ^7_1_ . I am a little confused about the paths above. If AS1 is providing transit to 2,3,4 etc then the RIS would expect to see AS1 upstream from 2,3,4 etc, or did I miss something? Anyway, I think I understand your point: tell me if the paths for this collection of prefixes are dissimilar beyond an AS. The question is what the advanced reg exp option could do for you when creating alarms. Kind regards, Matthew > > A comparison alarm would go off when differing AS paths are seen > within the given groups. > > With some extra thought on how to specify the common points in the AS > path, AS 1 could also compare it's global annoucements to those it > annouces for ASs 2, 3 and 4 etc. > > When setting up new transit and peering arrangements we would use this > to check the propogation of prefixes against known working > annoucements. It would also guard against indiviudal prefixes suddenly > being filtered at some future point. > > The nice thing about this is that it only compares, so you don't > actually have to maintain the AS paths you expect to see. > > > Just some suggestions - I'd be interested in what the implementors > think about the feasibilty of these. > > Sam > >

1 0

New alarm types (proposal)
by Sam Stickland 28 Jun '04

28 Jun '04

Hi, I've been playing about with the myasn system, and it's impressive, but it doesn't quite work the way we'd like to it. While the objective of the project is described as "an alarm notification system that monitors the propagation of eBGP routes" the biggest problem we face is the _non-propagation_ of eBGP routes. I've seen countless cases where our peers (or our peers peer) prefix filters were blocking routes we were attempting to annouce to them, but few incidents of route leaks or actual hi-jacking in comparision. With this in mind, I'd like to suggest two new types of alarm: Expected Transit Alarm A Transit Alarm currently goes off when a prefix/AS appears to receive transit from an unspecified provider. Our peering relationships are complex, with multiple upstreams and presence at multiple exchanges. It would be complex to list and maintain our entire peering structure in myasn. An Expected Transit Alarm would sound when a prefix/AS _doesn't_ recieve transit from a _specified_ provider. (The difficulty with this alarm is, of course, that perhaps your routing beacons do not ever see the expected AS path.) Comparision Alarms This would allow you to specify groups of prefixs that ought to have idenitical AS paths, past a specified (common) point. For example: AS1 is providing identical global transit to AS's 2, 3 and 4, and identical partial transit to AS's 5, 6, 7. For the global transit after ^2_1_ , ^3_1_ and ^4_1 the paths seen should be idenitcal. Likewise for ^5_1_ , ^6_1_ and ^7_1_ . A comparison alarm would go off when differing AS paths are seen within the given groups. With some extra thought on how to specify the common points in the AS path, AS 1 could also compare it's global annoucements to those it annouces for ASs 2, 3 and 4 etc. When setting up new transit and peering arrangements we would use this to check the propogation of prefixes against known working annoucements. It would also guard against indiviudal prefixes suddenly being filtered at some future point. The nice thing about this is that it only compares, so you don't actually have to maintain the AS paths you expect to see. Just some suggestions - I'd be interested in what the implementors think about the feasibilty of these. Sam

1 0

RE: transit alarms with a single-element AS-PATH
by Matthew Williams 23 Jun '04

23 Jun '04

Hi there, > the RRC box we peer with is receiving the prefix directly > from us without our transit provider ASN prepended, so myasn > is flagging it as a leak. Hmm, if so, then that's not really what we want. I'll add this to the bug list after reproducing it. > BTW, I think that it would be useful to sort by default on > last seen date in show_alarmevents.html. We'll look into this one. Cannot promise anything though. Many thanks for the feedback. Kind regards, Matthew > -----Original Message----- > From: Marco d'Itri [mailto:md@Linux.IT] > Sent: 23 June 2004 18:38 > To: ris(a)ripe.net > Subject: transit alarms with a single-element AS-PATH > > > I'm receiving some events (for alarm 545) with only my own > ASN in the path. If I understand correctly what is happening, > the RRC box we peer with is receiving the prefix directly > from us without our transit provider ASN prepended, so myasn > is flagging it as a leak. > > BTW, I think that it would be useful to sort by default on > last seen date in show_alarmevents.html. > > -- > ciao, | > Marco | [6886 cov/HgvPKMXiU] >

1 0

myASn User Feedback
by Nipper, Arnold 20 Jun '04

20 Jun '04

Howdy, how do I change notification for Origin alarm? Do I have to add a new user? Arnold -- Arnold Nipper / DE-CIX Management GmbH, the German Internet Exchange e-mail: arnold.nipper(a)de-cix.net phone/mob: +49 172 265 0958 fax: +49 6224 9259 333 http://www.de-cix.net pgp-fingerprint: e533 5cc5 be27 27ae 04b7 0adc 2603 f8a9 1b59 3bd4

2 1

ANNOUNCEMENT: myASn beta ready for testing
by Matthew Williams 14 Jun '04

14 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, The myASn beta is now ready for testing! Just type in your old account information from the previous myASn prototype in the following format (without apostrophes): U: 'user@asn' PW: 'old password' URL: http://www.ris.ripe.net/myasn.html Thanks for testing myASn. Your comments are more than welcome. Kind regards, The RIS Team --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/ -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQM2LncHkFbJe+GdoEQJOoACgh5dn6bqr9urGBv482JbjSVd777cAniVc lqM8z90QcFWdiLBE9ZS01U5r =u0On -----END PGP SIGNATURE-----

1 0

RE: [myasntesting] origin alarms / PI
by Henry Dziewa 19 May '04

19 May '04

Is it me or there is not much work being done with this project ? I have the same issues as described below and even when signing up the AS it takes a long time for someone to respond. -----Original Message----- From: Joerg Schumacher [mailto:schuma@gaertner.de] Sent: Friday, May 14, 2004 10:16 AM To: myasntesting(a)ripe.net Subject: [myasntesting] origin alarms / PI Hi, we just signed up and got our first origin alarm. Configured prefix: 194.120.234.0/24 prefix causing the alarm: 194.120.0.0/14 194.120.234.0/24 has status: ASSIGNED PI. Origin alarms for PI networks due to a less specific prefix aren't really useful. Regards, Joerg -- Gaertner Datensysteme 38114 Braunschweig Joerg Schumacher Hamburger Str. 273a Tel: 0531-2335555 Fax: 0531-2335556

4 3

origin alarms / PI
by Joerg Schumacher 14 May '04

14 May '04

Hi, we just signed up and got our first origin alarm. Configured prefix: 194.120.234.0/24 prefix causing the alarm: 194.120.0.0/14 194.120.234.0/24 has status: ASSIGNED PI. Origin alarms for PI networks due to a less specific prefix aren't really useful. Regards, Joerg -- Gaertner Datensysteme 38114 Braunschweig Joerg Schumacher Hamburger Str. 273a Tel: 0531-2335555 Fax: 0531-2335556

1 0

recover password for myAS
by Maxim Tuliuk 11 May '04

11 May '04

Hello I'm sorry, I forget login and password from myAS. How I can recover it? (AS: 21011) -- Maxim Tuliuk, Network Engineer ISP "TopNet": http://top.net.ua/ (+380-44) 239-2899/246-3669/248-8206

2 1

Re: Welcome to the "Myasntesting" mailing list
by Hilario Martin G. 04 May '04

04 May '04

Hi, would you please tell me my login name & password? thanks in advance, Hilario On Tue, 04 May 2004 15:19:38 +0200 myasntesting-request(a)ripe.net wrote: > Welcome to the Myasntesting(a)ripe.net mailing list! Your myASn account > has been created! > > In order to start using it type you AS number into the 'AS number:' > text box and click on 'SUBMIT'. The next page shows two links, > 'Current Alarms' and 'Alarm Configuration'. From this point your Login > Name and Password will be required.

1 0

(no subject)
by admin-dima 08 Jan '04

08 Jan '04

requested features

1 0

FW: MyASN - no alarms
by Matthew Williams 17 Dec '03

17 Dec '03

Forwarded to myasntesting... > -----Original Message----- > From: Arife Vural [mailto:arife@ripe.net] > Sent: 17 December 2003 12:00 > To: Andreas Laudwein > Cc: ris(a)ripe.net > Subject: Re: MyASN - no alarms > > > > Hi Andreas, > > > I wrote a question to Maximo, he responded but that was on his last > > working day for RIPE, so I'm now getting back to you with further > > questions ;-) > > I try to answer your question as much I can :-) > > > >>We just had a look at MyASN, configured it and waited for alarms, > > >>but we > > >>did not receive any ... our AS number is 8560. > > >> > > >>We put in 5 prefixes in, but no more-specifics (we have one > > >>more-specific announced). We put in two upstream > providers and 'forgot' > > >>one upstream to provoke upstream alarms. > > >> > > >>For some weird reason, we don't get any alarms. I > crosschecked with > > >>the > > >>RIS query and when I compare it with our config, I should > get a bunch of > > >>alarms. > > > > > >The myASn send alarm notification in case something unexpected > > >happen. In > > >your case you have configured: > > >the origin alarms: > > >@ ORIGIN 217.160/16 300 3 14400 > > >@ ORIGIN 195.20.224/19 300 3 14400 > > >@ ORIGIN 212.227/16 300 3 14400 > > >@ ORIGIN 82.165/16 300 3 14400 > > > > > >and the providers: > > >@ PROVIDERS 3356 300 3 14400 > > >@ PROVIDERS 1239 300 3 14400 > > > > > >you will only get alarm messages in case something unexpected > > >happens. For > > >example > > >if AS2323 announces prefix 217.160/16 you will then get > alarm messages. Or > > >if someone announces any prefix and the ASPATH is NOT "x x > x 3356 8569 x x > > >x" OR > > >"x x x 1239 8569 x x xÂ¨ then you will get alarm messages. > > > > so with this setting we should get alarms: as I wrote I left out a > > more > > specific in the configuration and I left out another > upstream, which is > > AS12312. > > If I query RIS directly, I e.g. see the announcement from > AS12132 as > > well as various announcements from other RIS peers who give > you a full > > feed and announce our route as their peer route. > > > > myASN is using only data from RRC03. That's kind of > misleading. You can > get all BGP announcement from RIS queries but you can not see > those in > myASN. New version will run over all RRC data. > > It looks there is a bug in ASPATH matching. This would be > fixed in the new version of myASN. > > > Can you please have a look at this issue ? > > > > We would be happy to integrate MyASN into our monitoring since it > > gives > > us a smart view on how the world's routers is see us. > > It's great to hear that! I suggest you to wait the new > version will be > online. We are planning to announce the new version late Jan. > > Kind regards, > > Arife > > > Thanks ! > > > > Regards, > > Andreas > > -- > > Andreas Laudwein p: +49 721 91374 391 > > Network Operations f: +49 721 91374 212 > > Schlund+Partner AG http://www.schlund.net > > -- > > "The shortest distance between two points is usually under repair" > > -Anonymous > >

1 0

RE: myASn Super User Account Created
by Matthew Williams 30 Oct '03

30 Oct '03

Hi there, > Thanks for creating my account. You are most welcome. > I had one question about the customer alarms. The tutorial > says the Customer Alarms are to check: > "Are my single-homed customers routes being announced with > myself as the expected transit provider?" > Does the system also check for more-specific announcements > from the customer prefix blocks that might show up with a > different source ASN? We do monitor more specifics. However, this particular alarm type focuses on matching the upstream of the origin, i.e. YYYY in AS sequence {XXXX, YYYY, ZZZZ}. This means that the highjacked more specific route would only be detected if announced over someone else than YYYY. The type of alarm you are implying will become available in the version of myASn that integrates into the RIPE NCC LIR Portal, for it'll allow the user to monitor IP space originating from any ASN. One of the remaining issues is how to facilitate users, whom are non-LIRs, with access to the system. We are currently looking into several feasible workarounds. Our aim is to provide this service to the entire community. Both related and non-related ideas are always welcome ;) LIR Portal: https://lirportal.ripe.net/lirportal/index.html I hope above answers your question. There should be a beta of the next version ready for demonstration by the next RIPE meeting in January. Watch this space for more information. Best regards, Matthew Williams Ps. I have cc'd Maximo Alves, the developer working on myASn, in case he has something to add. > -----Original Message----- > From: metzger(a)ripe.net [mailto:metzger@ripe.net] On Behalf Of > Joe Metzger > Sent: 28 October 2003 18:25 > To: matthew(a)ripe.net > Subject: Re: myASn Super User Account Created > > > Matthew, > Thanks for creating my account. > > This looks like a very interesting project! I was looking at > putting together something similar to help monitor and track > problems with Spammers hijacking address space for short > intervals and using them to inject spam. > > > I had one question about the customer alarms. The tutorial > says the Customer Alarms are to check: > "Are my single-homed customers routes being announced with > myself as the expected transit provider?" > > Does the system also check for more-specific announcements > from the customer prefix blocks that might show up with a > different source ASN? > > > Is the myastesting(a)ripe.net mailing list the appropriate > place to ask this kind of question? > > > --Thanks! > Joe Metzger > > Matthew Williams wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Dear myASn Test User, > > > > We have created a super user account for you with the requested > > password. You have also been added to our mailing list > > "myasntesting(a)ripe.net". Please help us to improve the > current alpha > > version by sending your comments to > mailto:myasntesting@ripe.net. The > > latest "bug" and > "requested features" lists are accessible from the > > help page after login. > > > > Some useful links: > > - - - ------------------- > > * myASn Login: http://www.ris.ripe.net/cgi-bin/myas/index.cgi > > > > * myASn Help: http://www.ripe.net/ris/myasnhelp.html > > > > * myASn FAQ: http://www.ripe.net/ris/myasnfaq.html > > > > * myASn Glossary: http://www.ripe.net/ris/myasngls.html > > > > * myASn Tutorial: > > http://www.ripe.net/ris/Talks/myAS_TUTORIAL_MEGABIT.pdf > > > > Thank you for signing up as a myASn test user! > > > > Kind regards, > > The RIS Team > > > > Ps. We are in the process of changing the project name from > "myAS" to > > "myASn". > > > > --- > > > Matthew Williams (MW243-RIPE) > > > Customer Liaison Engineer > > > RIPE NCC - http://www.ripe.net/np/ > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 7.0.4 > > > > iQA/AwUBP56aIcHkFbJe+GdoEQJ5MQCg0R+egHb4GgAmJsp5xBzZYtMq4fkAoNmh > > GhPIefYXOy+oQ/8OosNrBzrM > > =7WnO > > -----END PGP SIGNATURE----- > > -- > Joe Metzger > metzger(a)es.net > Network Engineering, ESnet > Lawrence Berkeley National Laboratory >

2 2

AS378
by Hank Nussbacher 01 Sep '03

01 Sep '03

Comments: 1) I manage 2 ASNs 378 and 3339. Most ISPs manage quite a few. The model of having myASN based per ASN number is wrong. It should be based on a person or mntner who has authority for multiple ASNs. Otherwise, the tool becomes cumbersome. 2) When I login to myASN, I would like to see that the system has auto-learnt all my announced prefixes and presents a menu of prefixes - 1 per line - with boxes to be checked or modified - such as "remove" or "holdtime", "ttl", etc. 3) From http://www.ris.ripe.net/myas/accounts/378/myashelp.html (individual help page) you should have links to the FAQ as well. -Hank

3 2

[NOTIFICATION: myASn backend working again]
by Maximo Alves 15 Aug '03

15 Aug '03

Dear All, The myASn prototype's backend is working fine now. Best regards, The RIS Team

1 0

NOTIFICATION: myASn backend problems
by Matthew Williams 14 Aug '03

14 Aug '03

Dear All, The myASn prototype's backend is experiencing some problems with scanning the RIS raw data files. We are currently working on a fix and should have it ready by tomorrow afternoon. Best regards, The RIS Team Ps. The project name is changing from "myAS" to "myASn", hence the mailing list's new epithet: "myasntesting(a)ripe.net". - - --- > Matthew Williams-Bywater (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC (http://www.ripe.net/np/)

1 0