From matthew at ripe.net Mon Jun 14 13:27:26 2004 From: matthew at ripe.net (Matthew Williams) Date: Mon, 14 Jun 2004 13:27:26 +0200 Subject: [myasntesting] ANNOUNCEMENT: myASn beta ready for testing Message-ID: <003501c45202$927fd580$2d0200c1@rockstar> -----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 at 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----- From arnold.nipper at de-cix.net Sat Jun 19 21:30:44 2004 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Sat, 19 Jun 2004 21:30:44 +0200 Subject: [myasntesting] myASn User Feedback Message-ID: <40D49464.80209@de-cix.net> 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 at 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 From matthew at ripe.net Sun Jun 20 21:04:55 2004 From: matthew at ripe.net (Matthew Williams) Date: Sun, 20 Jun 2004 21:04:55 +0200 Subject: [myasntesting] myASn User Feedback In-Reply-To: <40D49464.80209@de-cix.net> Message-ID: <003701c456f9$799c0510$aba8a8c0@rockstar> Hi there, > how do I change notification for Origin alarm? Do I have to > add a new user? The 'Manage alarm groups' link allows you to set up email destinations per alarm group. You can send notifications to several email addresses by separating them with a comma. On the 'Manage alarms' page you can tag each alarm with its alarm group. Cheers, Matthew > -----Original Message----- > From: myasntesting-admin at ripe.net > [mailto:myasntesting-admin at ripe.net] On Behalf Of Nipper, Arnold > Sent: 19 June 2004 21:31 > To: myastesting at ripe.net > Cc: Nipper, Arnold > Subject: [myasntesting] myASn User Feedback > > > 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 at 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 From matthew at ripe.net Wed Jun 23 18:52:40 2004 From: matthew at ripe.net (Matthew Williams) Date: Wed, 23 Jun 2004 18:52:40 +0200 Subject: [myasntesting] RE: transit alarms with a single-element AS-PATH In-Reply-To: <20040623163819.GA16220@wonderland.linux.it> Message-ID: <001801c45942$7ef97dd0$2d0200c1@rockstar> 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 at Linux.IT] > Sent: 23 June 2004 18:38 > To: ris at 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] > From sam at c4l.co.uk Mon Jun 28 13:20:30 2004 From: sam at c4l.co.uk (Sam Stickland) Date: Mon, 28 Jun 2004 12:20:30 +0100 (BST) Subject: [myasntesting] New alarm types (proposal) Message-ID: 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 From matthew at ripe.net Wed Jun 30 13:33:22 2004 From: matthew at ripe.net (Matthew Williams) Date: Wed, 30 Jun 2004 13:33:22 +0200 Subject: FW: [myasntesting] New alarm types (proposal) Message-ID: <000801c45e96$0d1c4b80$2d0200c1@rockstar> 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 > >