Hi Randy, On 10/04, Randy Bush wrote:
so i have an AS (3130) which peers at the SIX (RSs and some direct).
in the hope that leak detectors such as artemis would stop false positives when they see my prefixes announced customer cones of SIX peers, i want to add the SIX peers to my aut-num: policy.
I would be astonished if artemis was parsing your import/export expressions, but as an academic exercise...
export: to AS-SEATTLEIX-RS-CLIENTS announce AS-RG-SEA
seems clear and obvious. but
import: from AS-SEATTLEIX-RS-CLIENTS accept AS-SEATTLEIX-RS-CLIENTS
would seem to allow bill's bait and sushi to announce microsoft to me. and i am not sure that expansive `from` clause is actually allowed.
The having an as-set in the peering-expr part is fine, but that particular set appears to contain all of the peers' customer cones, which is not what you want there. Additionally it evaluates down to "any route originated by any customer of any peer, from any customer of any (other) peer". That's not a good filter, as you pointed out ;-) In order to express what you want, the SIX needs to create: - an as-set containing the ASNs of the RS peers (not their customers), e.g. AS33108:AS-PEERS; and - for each peer, a set containing that peer's customer cone, each with name that contains the peer's ASN, e.g. AS33108:AS-PEERS:AS65000. Then you can say something like: import: from AS33108:AS-PEERS accept AS33108:AS-PEERS:PeerAS The fact that the IX operator needs to maintain these sets is a symptom of the same issue that makes it near impossible to construct sane filters for route-server sessions: you have no idea when someone joins, or what they *should* be announcing. One of the many reasons you don't see us on route-servers.
what are others in this space doing?
Mostly, asking people fill-in peeringdb records, and ignoring import/export attributes entirely. However we use roughly the above scheme, just in case someone is reading. Cheers, Ben