- myasntesting - mailman.ripe.net

RE: [myasntesting] false reports?
by Rob Wise 15 Nov '05

15 Nov '05

myasntesting-admin(a)ripe.net wrote: > Hello all, > > We have seen many alarms at this moment. I checked the alarms by > comparison with several route-server's records, and it seems the > alarms are false reports. > > How is your situations, all? We're seeing the same issue with reports for AS9942. Cheers, Rob

1 0

(no subject)
by rajtanu＠alliancekolkata.com 28 Oct '05

28 Oct '05

Dear sir Recently we got our IP fom Apnic.We want to setup our DNS server and make the reverse dns entry for those ips. Do we have to make any DNS entry to RIPE or APNIC servers? It willbe helpful for us we got any help regarding DNS setup. NOC

1 0

Fw: Welcome to the "Myasntesting" mailing list
by Brijesh Patel 26 Oct '05

26 Oct '05

----- Original Message ----- From: <myasntesting-request(a)ripe.net> To: <brijesh(a)gipl.net> Sent: Wednesday, October 26, 2005 5:39 PM Subject: Welcome to the "Myasntesting" mailing list > Welcome to the Myasntesting(a)ripe.net mailing list! > > To post to this list, send your email to: > > myasntesting(a)ripe.net > > General information about the mailing list is at: > > http://www.ripe.net/mailman/listinfo/myasntesting > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > http://www.ripe.net/mailman/options/myasntesting/brijesh%40gipl.net > > You can also make such adjustments via email by sending a message to: > > Myasntesting-request(a)ripe.net > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > woxese > > If you forget your password, don't worry. There is a button on your > options page that will email your current password to you. > > Kind Regards, > > RIPE NCC Mailing list moderation team > >

1 0

MyASn will be offline today between 14.00 and 18.00 (CET).
by Arife Vural 25 Nov '04

25 Nov '04

Dear All, Because of urgent maintenance on our main RIS server, MyASn service would not be available today between 14.00 and 18.00 (CET). Other RIS services would not be affected from this maintenance window. Sorry for the inconvenience we caused. Kind regards. Arife

1 0

Re: myASn Account Created
by Hroi Sigurdsson 12 Jul '04

12 Jul '04

Matthew Williams wrote: > Hi there, > > >>morning from the one bogus entry and from the transit alarms, >>triggered >>by peer propagation. > > > Great :) > > I really appreciate that you're investing the time to investigate our system. Please feel free to suggest some features that you > think are missing in the current implementation. You're welcome. It is a useful tool. A cool feature would be auto-configuration (even auto-updating?) of alerts from info in aut-num objects. Another nice feature would be detection of leaks, ie. "only this set of prefixes may have my AS in the path". Comparative checks: "These prefixes must have identical paths" etc. (might be too noisy). Bug? Customer alerts contain empty AS fields: Customer alarm 742 (Default), 217.145.48.0/20 (exceptions not shown), MyASn: , Their ASn: , HDT: 60, HDE: 1, TTL: 3600 .=------+-----------------+--------------+--------------------------+-------------------------=. | RRC | Prefix | Peer | First Seen | Last Seen | |=------+-----------------+--------------+--------------------------+-------------------------=| | rrc10 | 217.145.48.0/20 | 217.29.66.65 | Wed Jul 7 02:02:01 2004 | Wed Jul 7 02:02:01 2004 | '=------+-----------------+--------------+--------------------------+-------------------------=' -- Hroi Sigurdsson · NetGroup DataCenter A/S St. Kongensgade 40H · DK-1264 Copenhagen K, Denmark Phone: +45 3370 1544 · Fax: +45 7025 2687

2 1

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