IRR-clueful person at 3356?
Hi folks, Sorry for the extremely broad email but I'm trying to sort out an IRR issue regarding automatic filter generation at Level(3) on behalf of a friend. The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. If true this would be a rather startling shortcoming of their filter generation software and at odds with the whole point of having multiple components to the IRR system. Anyone got any pointers or help? Email to r...@level3.net has not gotten us anywhere, but I was not the one who sent it and can't guarantee that the right questions were asked. Thanks, -r
Re: IRR-clueful person at 3356?
On Fri, 17 Aug 2012, Robert E. Seastrom wrote: The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. Can't say for sure if it's true, but I've been told the same thing by Level3 support. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IRR-clueful person at 3356?
L3 can be tricky with IRR especially if you have objects split across multiple IRR databases. This should help with what filters you want them to put on: http://www.clarksys.com/blog/2009/09/02/using-irr-with-level3/ You can test before using: whois -h filtergen.level3.net RIPE::YOUR-AS-SET -searchpath=RIPE;ARIN;RADB -recurseok -warnonly Regards Patrick On 17/08/2012 16:16, Robert E. Seastrom wrote: Hi folks, Sorry for the extremely broad email but I'm trying to sort out an IRR issue regarding automatic filter generation at Level(3) on behalf of a friend. The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. If true this would be a rather startling shortcoming of their filter generation software and at odds with the whole point of having multiple components to the IRR system. Anyone got any pointers or help? Email to r...@level3.net has not gotten us anywhere, but I was not the one who sent it and can't guarantee that the right questions were asked. Thanks, -r
Re: IRR-clueful person at 3356?
That's the sort of thing we have in Europe, downstream customer need to be in your AS-SET for filtering purposes - Original Message - From: Jon Lewis [mailto:jle...@lewis.org] Sent: Friday, August 17, 2012 11:29 AM To: Robert E. Seastrom r...@seastrom.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: IRR-clueful person at 3356? On Fri, 17 Aug 2012, Robert E. Seastrom wrote: The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. Can't say for sure if it's true, but I've been told the same thing by Level3 support. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: IRR-clueful person at 3356?
Yes, usually something like accept r/n iff there is a route object 'covering' r/n and the 'origin AS' of r/n is in the AS-set of the neighbor AS. mh -Message d'origine- De:Mike Simkins Envoyé: 17/08/2012, 18:04 A: jle...@lewis.org; r...@seastrom.com Cc: nanog@nanog.org Objet:Re: IRR-clueful person at 3356? That's the sort of thing we have in Europe, downstream customer need to be in your AS-SET for filtering purposes - Original Message - From: Jon Lewis [mailto:jle...@lewis.org] Sent: Friday, August 17, 2012 11:29 AM To: Robert E. Seastrom r...@seastrom.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: IRR-clueful person at 3356? On Fri, 17 Aug 2012, Robert E. Seastrom wrote: The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. Can't say for sure if it's true, but I've been told the same thing by Level3 support. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IRR-clueful person at 3356?
Thanks to all who reached out to me in private email and on IRC. Here's the thumbnail explanation of how to do it (so some future searcher doesn't curse me for not summarizing to the list). By default Level(3) only searches one IRR component for you. I can understand why one would want to scope things this way but it sure was confusing. It's possible to have one's searchpath set to look in multiple IRR components explicitly (or * if you want more standard behavior) - these parameters are hinted at in the output from whois -h filtergen.level3.net help but you need someone in tech support to set this up for you in 3Scape; don't expect the first line guys to be able to help you beyond telling you that your update failed. There's another way though - Level(3) uses an extension to RPSL that allows one to explicitly state sources in the as-set like so: remarks: is normally just a remark and not evaluated, BUT... remarks: Level3 members: is a magic construct that will cause the rest of the line to be evaluated by Level(3) as one or more IRRCOMPONENT::AS-OR-AS-SET pairs. Apparently unqualified AS-OR-AS-SET values are allowed too, presumably to default to either whatever your normal pull-from IRR component is or from LEVEL3, but it looks as if one can't go wrong by explicitly stating each pair. Comcast and Yipes both have very nice as-sets that can be used as cheat sheets for how the grammar works: whois -h rr.level3.net as-cbc whois -h rr.level3.net as-yipes (careful with as-yipes - you get two objects back, one with a source of LEVEL3 and one with a source of RADB - it's the LEVEL3 one that you are interested in). Disclaimer: I haven't tested this all the way yet. The origin AS expands right and the friend's upstream has been updated and we're just waiting for mirroring to happen. If there's nothing further from me in this thread in a couple of days then it worked. :-) -r
