6connect / irrpt Goto Github PK

Can you support having the IPv4 and IPv6 have different prefix names. We prepend all IPv4 Prefixes list names with IPV4 and for IPV6 Prefixes list we do the same.

Example
in the file conf/irrpt.conf
$cfg['pfxgen']['default_pfxstr_v4'] = "IPV4-AS%d-IN";
$cfg['pfxgen']['default_pfxstr_v6'] = "IPV6-AS%d-IN";

[user@server irrpt]$ bin/irrpt_pfxgen -f cisco 42
conf t
no ip prefix-list IPV4-AS42-IN
ip prefix-list IPV4-AS42-IN permit 216.21.2.0/23 le 24
no ip prefix-list IPV6-AS42-IN
ipv6 prefix-list IPV6-AS42-IN permit 2a01:8840:00a1:0000:0000:0000:0000:0000/48

Thanks!

to work on more platforms, consider changing the shebang insted to be "/usr/bin/env php"

also, the v6 pfxlist generator hard codes ":V6" at the end which is inflexible and unnecssary as you can just repliate this in the config. inc/pfxlist.inc.

http://falz.net/static/irrpt-paths-v6.diff

Given the following in irrdb.conf:

# Example:
# ASN           IRR Object (AS-SET/AUT-NUM)           Update Email

#42              AS-PCH                                [email protected]
#6939            AS-HURRICANE                          none
#11670           AS-TORIX                              [email protected]
#393424          AS393424                              [email protected]

16970           AS16970:AS-MIDNET-ALL                   [email protected]

irrpt_fetch returns a warning, ostensibly because it expects a "top level" as-set (AS-HURRICANE) versus one nested into an aut-num, like AS16970:AS-MIDNET

[eng@westie irrpt]$ bin/irrpt_fetch -v
Reading irrdbConf array list for ASNs, Objects, Email
Processing AS16970 [AS16970:AS-MIDNET-ALL] (Record 1)
   - Parsed IRR Object AS16970:AS-MIDNET-ALL
   - Fetching v4 routes.
   * WARNING: Query (!gAS16970:AS-MIDNET-ALL) failed: Invalid AS number AS16970:AS-MIDNET-ALL: number part is not numeric

But it does appear to work:

   - Filtering against excluded routes.
   - Writing routes to local database.
   - Aggregating v4 routes.
   - Aggregating routes - sorting...
   - Aggregating routes - eliminating overlapping prefixes...
   - Removing 23.169.240.0/24, fits into: 23.169.240.0/22
   - Removing 23.169.241.0/24, fits into: 23.169.240.0/22
   - Removing 23.169.242.0/24, fits into: 23.169.240.0/22
   - Removing 23.169.243.0/24, fits into: 23.169.240.0/22
   - Aggregating routes - aggregating neighboring prefixes...
   * WARNING: Aggregating 23.169.244.0/24 and 23.169.245.0/24 into 23.169.244.0/23
   - Fetching v6 routes.
   * WARNING: Query (!6AS16970:AS-MIDNET-ALL) failed: Invalid AS number AS16970:AS-MIDNET-ALL: number part is not numeric
   - Filtering against excluded routes.
   - Writing routes to local database.
   - Aggregating v6 routes.
   - Aggregating routes - sorting...
   - Aggregating routes - eliminating overlapping prefixes...
   - Removing 2602:0800:1005:0000:0000:0000:0000:0000/48, fits into: 2602:0800:1000:0000:0000:0000:0000:0000/44
   - Aggregating routes - aggregating neighboring prefixes...
   - Writing ASN list to local database.
Completed processing of 1 IRR object(s).

Thanks!

Hi,

Found a two part problem:

1. Issue where the CLI was not honouring the prefix length passed via -l and -l6.
2. inc/pfxlist.inc was not checking the prefix length to filter out the variables passes for prefix length.

patch attached.
irrpt-20170318-patch.txt

Found a minor issue around removing older ipv6 prefix-lists on Cisco devices:

portal@base:/usr/local/irrpt/bin% ./irrpt_pfxgen -p6 PEER:%d -p PEER:%d -l6 48 -f cisco 1234
conf t
no ip prefix-list PEER:1234
no ip prefix-list PEER:1234 <-----
ip prefix-list PEER:1234 permit xxx.yyy.zzz.0/21 le 24
ipv6 prefix-list PEER:1234 permit 2600:abcd::/32 le 48
end
write mem
portal@base:/usr/local/irrpt/bin%

root@base:/usr/local/irrpt# grep -r 'no ip prefix-list' *
inc/pfxlist.inc: printf("no ip prefix-list %s\n", $pfxname);
inc/pfxlist.inc: printf("no ip prefix-list %s\n", $pfxname_v6);
inc/pfxlist.inc: printf("no ip prefix-list %s\n", $pfxname);
inc/pfxlist.inc: printf("no ip prefix-list %s\n", $pfxname_v6);
inc/pfxlist.inc: printf("no ip prefix-list %s\n", $policy_name);
root@base:/usr/local/irrpt#

Looks like a few lines just need to be changed to 'no ipv6 prefix-list'.

Thnx!

There seems to be a bug in IPv6 aggregation.

For example for Cloudflare's AS13335, I get:

anurag@tools:~/irrpt$ php bin/irrpt_fetch 13335
Processing AS13335 (Record 1)
Completed processing of 1 IRR object(s).
anurag@tools:~/irrpt$

and now if I look at the v6 aggregate, I get:

anurag@tools:~/irrpt$ cat db/13335.6.agg
2a06:98c0::/29
2400:cb00::/32
2405:8100::/32
2405:b500::/32
2606:4700:f00::/40
2606:4700::/32
2803:f800::/32
anurag@tools:~/irrpt$

2606:4700:f00::/40 is part of 2606:4700::/32 and hence should not be there in the list.

I have noticed that certain as-set objects that include many ASNs and as-sets are quite slow to process or even yield memory error.

While running couple of simple tests with bgpq3, its performance is magnitudes faster.

What about providing a patch that detects if bgpq3 is present and using it instead of the built-in fetcher?

Take AS15412 - AS-FLAGP as an example. Their raw v4 prefix list has 572686 entries. The aggregated one drops down to 75906, but still contains a bunch of entries that could be aggregated further.

For example, this is part of the 15412.4.agg file:

2.99.146.0/24
2.99.147.0/24
2.99.148.0/24
2.99.149.0/24
2.99.150.0/24
2.99.151.0/24
2.99.152.0/24
2.99.153.0/24
2.99.154.0/24
2.99.155.0/24
2.99.156.0/24
2.99.157.0/24
2.99.158.0/24
2.99.159.0/24
2.99.160.0/24
2.99.161.0/24
2.99.162.0/24
2.99.163.0/24
2.99.164.0/24
2.99.165.0/24
2.99.166.0/24
2.99.167.0/24
2.99.168.0/24
2.99.169.0/24
2.99.170.0/24
2.99.171.0/24
2.99.172.0/24
2.99.173.0/24
2.99.174.0/24

Shouldn't this be aggregated down a lot further?

Not so much an issue as a question (and possibly a feature request)....

Are there any plans to offer support for generating a prefix list off of an AS-SET? (or is there an example available on how to do it?)

or... is it assumed you're supposed to use 'irrpt_list_prefixes' to build your our ACL based upon the AS-SET provided?

I think for peering with ISPs, building an AS-SET based prefix list as part of the script would be good.

are there any plans to move to git? (with remote repos) or should I go ahead with this idea? :)

Will it be possible to allow for the use of more than 1 AS-SET per AS listed in the irrdb.conf file?

Eg. AS23456 AS23456:AS-SET|AS23456:AS-SETV6 [email protected] (Used | as the separator in this example)

Nb: I am asking this. because I have run into several Networks would operate with no. 1 AS-SET only for v4 and no. 2 AS-SET only for v6.

Attached patch for Cisco IOS XR prefix-sets. This SHOULD be used with the -p6 flag on the CLI as the names by default are the same, PEER:%d.

irrpt-XR.patch.txt

When no prefix is found in the AS, a filter like this is generated:

[email protected]> show configuration policy-options policy-statement CUSTOMER-v6-xxxxx
term prefixes {
then next policy;
}
then reject;

Since the "from" statement is missing, every prefix will be accepted. This is a security issue, please suggest a solution :-)

Hi team,

Thinking the issue may be around the rewrite of the CLI parsing and parsing of irrdb.conf around here:
+// check AS parameter if provided
+if (isset($_SERVER['argv'][$offset+0]))
+{

• if (preg_match("/^AS./i", $_SERVER['argv'][$offset+0])) {

•   $asString = strtoupper($_SERVER['argv'][$offset+0]);
  

•   $rev = track($routefile);
  

  ..... etcetc

It seems that if you run ./irrpt_fetch -v <AS#> from the CLI it runs a fetch against just that AS number itself. In version 1.27 it would check it against the irrdb.conf entry and if an AS-SET was specified it would use that AS-SET information instead of just the AS#.

Version 1.27:
nistor@base:/usr/local/irrpt.orig/bin# ./irrpt_fetch -v 30176
Processing AS30176 (Record 1)
- Querying IRR Object AS30176:AS-CUSTOMERS

• WARNING: IRR Query - key not found - Query: !gAS30176:AS-CUSTOMERS
• Writing ASN list to local database.
• Filtering against excluded routes.
• Writing routes to local database.
• Aggregating routes.
• Tracking data in CVS.

Version 2.0:
nistor@base:/usr/local/irrpt/bin# ./irrpt_fetch -v 30176
Processing AS30176 (Record 1)
- Querying IRR Object AS30176

• Fetching v4 routes.
• Filtering against excluded routes.
• Writing routes to local database.
• Aggregating v4 routes.
• Aggregating routes - sorting...
• Aggregating routes - eliminating overlapping prefixes...
• Aggregating routes - aggregating neighboring prefixes...
• Fetching v6 routes.
• Filtering against excluded routes.
• Writing routes to local database.
• Aggregating v6 routes.
  ......

please fix :)

Hi,

Looks like one small change required:

if( $o_quiet == 1 )
{
status(STATUS_INFO, "Completed processing of {$count} IRR object(s).");
}

that should read o_quiet == 0

QA:
portal@base:% /usr/local/irrpt/bin/irrpt_fetch -q --nocvs
portal@base:%

works when the value is 0.

Cheers,
-nistor

the V4/V6 prefix-list is compiled incorrectly, submitted pull req.