How are operators using IRR?
How are operators using the data available in the various IRRs? Using an example: AS1 is your customer AS1 has AS2, AS3 and AS4 described as customers in an IRR Also assume AS2 has IRR data describing AS1000 and AS2000 as it's customers. Are operators building AS path regexes such as the following automatically from IRR and applying that to your BGP sessions? ---- AS1{1,} AS1{1,} AS2{1,} AS1{1,} AS3{1,} AS1{1,} AS2{1,} AS1000{1,} AS1{1,} AS2{1,} AS2000{1,} ---- I would imagine most operators that are building policy from IRR are building prefix lists to limit what they are accepting. Is this being paired with some AS path filtering? Are operators just traversing an AS-SET as far as it will go and building prefix lists to represent all intended prefixes to be heard on a session regardless of who originates them? Is the possibility of AS1000 hijacking AS2000 prefixes towards AS2 a problem you as the upstream to AS1 need to consider? (Last question assumes AS2 made a mistake and wasn't filtering properly on it's own customers and AS1 is just accepting all prefixes under the cone of AS2) Thanks
Hi, On Wed, 16 Jan 2013 19:55:44 -0500 ML <ml@kenweb.org> wrote:
Is this being paired with some AS path filtering?
I am a huge fan of path filtering, but I have so very little paths to maintain that I can say so. I guess most operators to not filter paths, and building prefix lists is more or less current practice. Just from what I have seen so far. I asked about best practice about building filteers from IRR data a while ago on NANOG, but there were not really an answer. Cheers Dan
2013/1/17 ML <ml@kenweb.org>
How are operators using the data available in the various IRRs?
Using an example:
AS1 is your customer AS1 has AS2, AS3 and AS4 described as customers in an IRR Also assume AS2 has IRR data describing AS1000 and AS2000 as it's customers.
Are operators building AS path regexes such as the following automatically from IRR and applying that to your BGP sessions?
---- AS1{1,} AS1{1,} AS2{1,} AS1{1,} AS3{1,} AS1{1,} AS2{1,} AS1000{1,} AS1{1,} AS2{1,} AS2000{1,} ----
I would imagine most operators that are building policy from IRR are building prefix lists to limit what they are accepting. Is this being paired with some AS path filtering?
Are operators just traversing an AS-SET as far as it will go and building prefix lists to represent all intended prefixes to be heard on a session regardless of who originates them? Is the possibility of AS1000 hijacking AS2000 prefixes towards AS2 a problem you as the upstream to AS1 need to consider? (Last question assumes AS2 made a mistake and wasn't filtering properly on it's own customers and AS1 is just accepting all prefixes under the cone of AS2)
Thanks
Hi, I usually build a prefix-list gathering route objects having an origin AS from the customer AS-SET. I know some operators doing AS-PATH filtering and other who don't have anything else than a max-prefix limit on the session. In my previous job, one of my transit provider just had a max-prefix limit of 4k and I was announcing 2K routes. Hopefully we were good enough to not leak any unlegitimate routes on the sessions by misconfiguration. -- Pierre-Yves
participants (3)
-
Dan Luedtke
-
ML
-
Pierre-Yves Maunier