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