bryan at bryanfields.net wrote:
I'd ask, why only one gateway to 44/8? Why not setup some tunnel/peering points globally?
That is a plan. There just needs to be some folks to step forward to make it happen.
Until recently, there wasn't a formal way to seek permission from ARDC to have the high level BGP routing changed to support this.
I have been curious since ARDC announced that option, how many/which local subnets are not being announced locally.
Maybe Brian Kantor can chime in on that.
Steve
With regard to using Cisco routers for integration into the AMPRNET, if you are going to load full tunnels be ready to throw some descent hardware at the task. The first issue is the config length, you need config compression on and no less than a 2600 due to nvram size. The other issue is number of interfaces, you also need at least a 2600 to configure the number of tunnels needed to be fully meshed. I am currently running a 2651xm and it does an ok job. Let me know if you are interested in a script to convert the encap.txt into a loadable config. 73, Jason KY9J
On Mon, 2013-06-17 at 13:54 -0400, Jason R Begley wrote:
Let me know if you are interested in a script to convert the encap.txt into a loadable config.
Oh, yes, please!
http://phx0.colliertech.org/~cjac/tmp/IMG_20130617_112301.jpg
I think we need to provide this information in a normalized manner, and have scripts for various router implementations:
Common -> JNOS Common -> Cisco Common -> MikroTik Common -> IPTables
Etc.
The current parsing is a pain.
Something in JSON on XML would be nice, or at least fixed length records, using CIDR and gating hosts.
e.g.
{ gateway: 192.231.186.124, transport : {method: BGP}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
BGP routes shouldn't need any special rules
{ gateway: 192.231.186.124, transport : {method: tunnel, protocols: [ipip,l2tp]}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
On an IPIP tunnel:
[admin@MikroTik] interface ipip> add local-address: x.x.x.x remote-address: 192.231.186.124 [admin@MikroTik] interface ipip> print Flags: X - disabled, R - running # NAME MTU LOCAL-ADDRESS REMOTE-ADDRESS 0 X ipip1 1480 x.x.x.x 192.231.186.124
[admin@MikroTik] interface ipip> en 0 [admin@MikroTik] interface ipip> /ip address add address=44.24.10.0/24 interface=ipip1 [admin@MikroTik] interface ipip> /ip address add address=44.24.100.12/32 interface=ipip1
Given the above JSON object [pseudo-Javascript Code to generate MikroTik].
document.write('/interface ipip add local-address: x.x.x.x remote-address: ' . gateway); document.write('/interface ipip en 0'); document.write('/interface ipip address add address=' . subnets[0].net . '/' . subnets[0].mask . ' interface=ipip1'); document.write('/interface ipip address add address=' . subnets[1].net . '/' . subnets[1].mask . ' interface=ipip1');
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Mon, Jun 17, 2013 at 11:26 AM, C.J. Adams-Collier
KF7BMP cjac@colliertech.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, 2013-06-17 at 13:54 -0400, Jason R Begley wrote:
Let me know if you are interested in a script to convert the encap.txt into a loadable config.
Oh, yes, please!
http://phx0.colliertech.org/~cjac/tmp/IMG_20130617_112301.jpg
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
AFAIK some Cisco devices support NOS tunnels wich allow multiple endpoints. But for IPIP on Mikrotik this approach means at the moment 366 individual tunnel interfaces since it accepts only PtP tunnels.
For IPIP, maybe some cheap standardized tunneling device, e.g. a Raspberry Pi with a specific AMPR image would be helpful, to accept IPIP encap traffic and ensure proper routing like below
| Pi tunnel endpoints | <---IPIP/RIP----> | Router | <---------> <Internet>
Hopefully we'll see fewer tunnels and more BGP :)
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Mon, Jun 17, 2013 at 12:11 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ AFAIK some Cisco devices support NOS tunnels wich allow multiple endpoints. But for IPIP on Mikrotik this approach means at the moment 366 individual tunnel interfaces since it accepts only PtP tunnels.
For IPIP, maybe some cheap standardized tunneling device, e.g. a Raspberry Pi with a specific AMPR image would be helpful, to accept IPIP encap traffic and ensure proper routing like below
| Pi tunnel endpoints | <---IPIP/RIP----> | Router | <---------> <Internet>
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hey there John,
I vote JSON rather than XML. The XML marshaling pipeline makes me cry every time I think about it.
I'll expand on your target platforms for config formats:
Common -> JNOS Common -> JunOS Common -> Cisco Common -> MikroTik Common -> shorewall / IPTables Common -> quagga
Rick (CC'd), can you help me and John here out with exercising some code to configure mikrotik routers? John is the administrator for the Western Washington /44 block and is issuing San Juan County a subnet. Traffic on this network can make use of the amateur band to transmit tcp/ip (as well as Ethernet over 802.11) on non-encrypted channels as per 47 CFR Part 97. This seems like it would be very useful for your ISP, since many of your long-range APs run without WPA or WEP. You can run on channel 7 with a narrow beam at higher gain than unlicensed users. When transmitting SSL or other application-layer encryption, the radio must operate at unlicensed power limits. Credentials negotiation using HMAC algorithms such as SHA-1 (and *mumble* md5 *mumble*) seem to have been approved. But I would avoid using anything the NIST no longer considers secure.
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
On Mon, 2013-06-17 at 12:00 -0700, K7VE - John wrote:
(Please trim inclusions from previous messages) _______________________________________________ I think we need to provide this information in a normalized manner, and have scripts for various router implementations:
Common -> JNOS Common -> Cisco Common -> MikroTik Common -> IPTables
Etc.
The current parsing is a pain.
Something in JSON on XML would be nice, or at least fixed length records, using CIDR and gating hosts.
e.g.
{ gateway: 192.231.186.124, transport : {method: BGP}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
BGP routes shouldn't need any special rules
{ gateway: 192.231.186.124, transport : {method: tunnel, protocols: [ipip,l2tp]}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
John, I had to quote your json key and value strings in order for JSON.pm to accept them. Is there any way you can get your JSON generator to wrap string literals in double quotes?
cjac@foxtrot:~/src/perl$ cat import-export-json.pl ; perl import-export-json.pl #!/usr/bin/perl -w use strict; use JSON;
use Data::Dumper;
my @json = ( q{ { "gateway": "192.231.186.124", "transport" : { "method": "BGP" }, "subnets" : [ { "net": "44.24.10.0", "mask": "24" }, { "net": "44.24.100.12", "mask": "32" } ] } }, q{ { "gateway": "192.231.186.124", "transport": { "method": "tunnel", "protocols": ["ipip","l2tp"] }, "subnets": [ { "net": "44.24.10.0", "mask": "24" }, { "net": "44.24.100.12", "mask": "32" } ] } } );
my @perl = map { decode_json $_ } @json;
print Data::Dumper::Dumper( @perl ), "\n"; __END__ $VAR1 = { 'transport' => { 'method' => 'BGP' }, 'gateway' => '192.231.186.124', 'subnets' => [ { 'net' => '44.24.10.0', 'mask' => '24' }, { 'net' => '44.24.100.12', 'mask' => '32' } ] }; $VAR2 = { 'transport' => { 'protocols' => [ 'ipip', 'l2tp' ], 'method' => 'tunnel' }, 'gateway' => '192.231.186.124', 'subnets' => [ { 'net' => '44.24.10.0', 'mask' => '24' }, { 'net' => '44.24.100.12', 'mask' => '32' } ] };
On an IPIP tunnel:
[admin@MikroTik] interface ipip> add local-address: x.x.x.x remote-address: 192.231.186.124 [admin@MikroTik] interface ipip> print Flags: X - disabled, R - running # NAME MTU LOCAL-ADDRESS REMOTE-ADDRESS 0 X ipip1 1480 x.x.x.x 192.231.186.124 [admin@MikroTik] interface ipip> en 0 [admin@MikroTik] interface ipip> /ip address add address=44.24.10.0/24 interface=ipip1 [admin@MikroTik] interface ipip> /ip address add address=44.24.100.12/32 interface=ipip1
Correct me if I'm wrong here, John and Rick, but you should be able to get to an admin@MikroTik shell using Net::SSH, right? If this is the case, it should be trivial to automate the above given the JSON description of the tunnel endpoints above.
Given the above JSON object [pseudo-Javascript Code to generate MikroTik].
It's fully javascript. no pseudo about it. values can be the results of evaluations of javascript code, but I try to avoid that sort of thing and stick with string literals.
document.write('/interface ipip add local-address: x.x.x.x remote-address: ' . gateway); document.write('/interface ipip en 0'); document.write('/interface ipip address add address=' . subnets[0].net . '/' . subnets[0].mask . ' interface=ipip1'); document.write('/interface ipip address add address=' . subnets[1].net . '/' . subnets[1].mask . ' interface=ipip1');
73,
C.J.
John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Mon, Jun 17, 2013 at 11:26 AM, C.J. Adams-Collier
KF7BMP cjac@colliertech.org wrote: (Please trim inclusions from previous messages) _______________________________________________ On Mon, 2013-06-17 at 13:54 -0400, Jason R Begley wrote: > Let me know if you are > interested in a script to convert the encap.txt into a loadable > config.
Oh, yes, please! http://phx0.colliertech.org/~cjac/tmp/IMG_20130617_112301.jpg _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
It was hand generated :) hence, pseudo :)
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Mon, Jun 17, 2013 at 6:16 PM, C.J. Adams-Collier KF7BMP < cjac@colliertech.org> wrote:
(Please trim inclusions from previous messages) _______________________________________________
Hey there John,
I vote JSON rather than XML. The XML marshaling pipeline makes me cry every time I think about it.
I'll expand on your target platforms for config formats:
Common -> JNOS Common -> JunOS Common -> Cisco Common -> MikroTik Common -> shorewall / IPTables Common -> quagga
Rick (CC'd), can you help me and John here out with exercising some code to configure mikrotik routers? John is the administrator for the Western Washington /44 block and is issuing San Juan County a subnet. Traffic on this network can make use of the amateur band to transmit tcp/ip (as well as Ethernet over 802.11) on non-encrypted channels as per 47 CFR Part 97. This seems like it would be very useful for your ISP, since many of your long-range APs run without WPA or WEP. You can run on channel 7 with a narrow beam at higher gain than unlicensed users. When transmitting SSL or other application-layer encryption, the radio must operate at unlicensed power limits. Credentials negotiation using HMAC algorithms such as SHA-1 (and *mumble* md5 *mumble*) seem to have been approved. But I would avoid using anything the NIST no longer considers secure.
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
On Mon, 2013-06-17 at 12:00 -0700, K7VE - John wrote:
(Please trim inclusions from previous messages) _______________________________________________ I think we need to provide this information in a normalized manner, and have scripts for various router implementations:
Common -> JNOS Common -> Cisco Common -> MikroTik Common -> IPTables
Etc.
The current parsing is a pain.
Something in JSON on XML would be nice, or at least fixed length records, using CIDR and gating hosts.
e.g.
{ gateway: 192.231.186.124, transport : {method: BGP}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
BGP routes shouldn't need any special rules
{ gateway: 192.231.186.124, transport : {method: tunnel, protocols: [ipip,l2tp]}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
John, I had to quote your json key and value strings in order for JSON.pm to accept them. Is there any way you can get your JSON generator to wrap string literals in double quotes?
cjac@foxtrot:~/src/perl$ cat import-export-json.pl ; perlimport-export-json.pl #!/usr/bin/perl -w use strict; use JSON;
use Data::Dumper; my @json = ( q{ { "gateway": "192.231.186.124", "transport" : { "method": "BGP"}, "subnets" : [ { "net": "44.24.10.0", "mask": "24" }, { "net": "44.24.100.12", "mask": "32" } ] } }, q{ { "gateway": "192.231.186.124", "transport": { "method": "tunnel", "protocols": ["ipip","l2tp"] }, "subnets": [ { "net": "44.24.10.0", "mask": "24" }, { "net": "44.24.100.12", "mask": "32" } ] } } );
my @perl = map { decode_json $_ } @json; print Data::Dumper::Dumper( @perl ), "\n"; __END__ $VAR1 = { 'transport' => { 'method' => 'BGP' }, 'gateway' => '192.231.186.124', 'subnets' => [ { 'net' => '44.24.10.0', 'mask' => '24' }, { 'net' => '44.24.100.12', 'mask' => '32' } ] }; $VAR2 = { 'transport' => { 'protocols' => [ 'ipip', 'l2tp' ], 'method' => 'tunnel' }, 'gateway' => '192.231.186.124', 'subnets' => [ { 'net' => '44.24.10.0', 'mask' => '24' }, { 'net' => '44.24.100.12', 'mask' => '32' } ] };On an IPIP tunnel:
[admin@MikroTik] interface ipip> add local-address: x.x.x.x
remote-address: 192.231.186.124
[admin@MikroTik] interface ipip> print Flags: X - disabled, R -
running # NAME MTU LOCAL-ADDRESS REMOTE-ADDRESS 0 X ipip1 1480 x.x.x.x 192.231.186.124
[admin@MikroTik] interface ipip> en 0 [admin@MikroTik] interface ipip> /ip address add address=44.24.10.0/24interface=ipip1 [admin@MikroTik] interface ipip> /ip address add address=
44.24.100.12/32 interface=ipip1
Correct me if I'm wrong here, John and Rick, but you should be able to get to an admin@MikroTik shell using Net::SSH, right? If this is the case, it should be trivial to automate the above given the JSON description of the tunnel endpoints above.
Given the above JSON object [pseudo-Javascript Code to generate MikroTik].
It's fully javascript. no pseudo about it. values can be the results of evaluations of javascript code, but I try to avoid that sort of thing and stick with string literals.
document.write('/interface ipip add local-address: x.x.x.x remote-address: ' . gateway); document.write('/interface ipip en 0'); document.write('/interface ipip address add address=' . subnets[0].net . '/' . subnets[0].mask . ' interface=ipip1'); document.write('/interface ipip address add address=' . subnets[1].net . '/' . subnets[1].mask . ' interface=ipip1');
73,
C.J.
John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Mon, Jun 17, 2013 at 11:26 AM, C.J. Adams-Collier
KF7BMP cjac@colliertech.org wrote: (Please trim inclusions from previous messages) _______________________________________________ On Mon, 2013-06-17 at 13:54 -0400, Jason R Begley wrote: > Let me know if you are > interested in a script to convert the encap.txt into a loadable > config.
Oh, yes, please! http://phx0.colliertech.org/~cjac/tmp/IMG_20130617_112301.jpg _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html_________________________________________ 44Net mailing list
44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
The HamWAN.org project I've been working with lately uses Mikrotik on their BGP edge routers and also configures them with all the IPIP tunnels. One of the contributors (Tom Hayward KD7LXL) created a cron'able python script that compares the Mikrotik configuration with the current list of tunnels and submits only the necessary changes to the device to keep it up to date.
You can find it here: https://github.com/kd7lxl/hamwan_scripts/tree/master/amprupdate
-Cory NQ1E
On Mon, Jun 17, 2013 at 6:16 PM, C.J. Adams-Collier KF7BMP < cjac@colliertech.org> wrote:
(Please trim inclusions from previous messages) _______________________________________________
Hey there John,
I vote JSON rather than XML. The XML marshaling pipeline makes me cry every time I think about it.
I'll expand on your target platforms for config formats:
Common -> JNOS Common -> JunOS Common -> Cisco Common -> MikroTik Common -> shorewall / IPTables Common -> quagga
Rick (CC'd), can you help me and John here out with exercising some code to configure mikrotik routers? John is the administrator for the Western Washington /44 block and is issuing San Juan County a subnet. Traffic on this network can make use of the amateur band to transmit tcp/ip (as well as Ethernet over 802.11) on non-encrypted channels as per 47 CFR Part 97. This seems like it would be very useful for your ISP, since many of your long-range APs run without WPA or WEP. You can run on channel 7 with a narrow beam at higher gain than unlicensed users. When transmitting SSL or other application-layer encryption, the radio must operate at unlicensed power limits. Credentials negotiation using HMAC algorithms such as SHA-1 (and *mumble* md5 *mumble*) seem to have been approved. But I would avoid using anything the NIST no longer considers secure.
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
On Mon, 2013-06-17 at 12:00 -0700, K7VE - John wrote:
(Please trim inclusions from previous messages) _______________________________________________ I think we need to provide this information in a normalized manner, and have scripts for various router implementations:
Common -> JNOS Common -> Cisco Common -> MikroTik Common -> IPTables
Etc.
The current parsing is a pain.
Something in JSON on XML would be nice, or at least fixed length records, using CIDR and gating hosts.
e.g.
{ gateway: 192.231.186.124, transport : {method: BGP}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
BGP routes shouldn't need any special rules
{ gateway: 192.231.186.124, transport : {method: tunnel, protocols: [ipip,l2tp]}, subnets : [{net:44.24.10.0,mask:24},{net:44.24.100.12,mask:32}]}
John, I had to quote your json key and value strings in order for JSON.pm to accept them. Is there any way you can get your JSON generator to wrap string literals in double quotes?
cjac@foxtrot:~/src/perl$ cat import-export-json.pl ; perlimport-export-json.pl #!/usr/bin/perl -w use strict; use JSON;
use Data::Dumper; my @json = ( q{ { "gateway": "192.231.186.124", "transport" : { "method": "BGP"}, "subnets" : [ { "net": "44.24.10.0", "mask": "24" }, { "net": "44.24.100.12", "mask": "32" } ] } }, q{ { "gateway": "192.231.186.124", "transport": { "method": "tunnel", "protocols": ["ipip","l2tp"] }, "subnets": [ { "net": "44.24.10.0", "mask": "24" }, { "net": "44.24.100.12", "mask": "32" } ] } } );
my @perl = map { decode_json $_ } @json; print Data::Dumper::Dumper( @perl ), "\n"; __END__ $VAR1 = { 'transport' => { 'method' => 'BGP' }, 'gateway' => '192.231.186.124', 'subnets' => [ { 'net' => '44.24.10.0', 'mask' => '24' }, { 'net' => '44.24.100.12', 'mask' => '32' } ] }; $VAR2 = { 'transport' => { 'protocols' => [ 'ipip', 'l2tp' ], 'method' => 'tunnel' }, 'gateway' => '192.231.186.124', 'subnets' => [ { 'net' => '44.24.10.0', 'mask' => '24' }, { 'net' => '44.24.100.12', 'mask' => '32' } ] };On an IPIP tunnel:
[admin@MikroTik] interface ipip> add local-address: x.x.x.x
remote-address: 192.231.186.124
[admin@MikroTik] interface ipip> print Flags: X - disabled, R -
running # NAME MTU LOCAL-ADDRESS REMOTE-ADDRESS 0 X ipip1 1480 x.x.x.x 192.231.186.124
[admin@MikroTik] interface ipip> en 0 [admin@MikroTik] interface ipip> /ip address add address=44.24.10.0/24interface=ipip1 [admin@MikroTik] interface ipip> /ip address add address=
44.24.100.12/32 interface=ipip1
Correct me if I'm wrong here, John and Rick, but you should be able to get to an admin@MikroTik shell using Net::SSH, right? If this is the case, it should be trivial to automate the above given the JSON description of the tunnel endpoints above.
Given the above JSON object [pseudo-Javascript Code to generate MikroTik].
It's fully javascript. no pseudo about it. values can be the results of evaluations of javascript code, but I try to avoid that sort of thing and stick with string literals.
document.write('/interface ipip add local-address: x.x.x.x remote-address: ' . gateway); document.write('/interface ipip en 0'); document.write('/interface ipip address add address=' . subnets[0].net . '/' . subnets[0].mask . ' interface=ipip1'); document.write('/interface ipip address add address=' . subnets[1].net . '/' . subnets[1].mask . ' interface=ipip1');
73,
C.J.
John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Mon, Jun 17, 2013 at 11:26 AM, C.J. Adams-Collier
KF7BMP cjac@colliertech.org wrote: (Please trim inclusions from previous messages) _______________________________________________ On Mon, 2013-06-17 at 13:54 -0400, Jason R Begley wrote: > Let me know if you are > interested in a script to convert the encap.txt into a loadable > config.
Oh, yes, please! http://phx0.colliertech.org/~cjac/tmp/IMG_20130617_112301.jpg _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html_________________________________________ 44Net mailing list
44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, Jun 17, 2013 at 12:45:10PM -0500, kb9mwr@gmail.com wrote:
I have been curious since ARDC announced that option, how many/which local subnets are not being announced locally.
There are at this moment 10 subnets which are authorized to announce their connectivity via their own BGP announcements.
We don't have an accurate count of tunnel-routed gateways. This is because the gateways list has not yet been audited to include only those gateways that are still operational. We had originally planned to get this done by the first of July but life got in the way and we'll have to set a later date. In the meantime, it's important for all gateway operators to make sure their gateway is registered with the portal as eventually those that aren't registered will be dropped from the gateways list. - Brian
10 with permission and 10 announcements seen on the net (in addition to the /8). It's good that nobody is trying to do it without permission ;)
$ curl -s http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44." 7377 44.0.0.0/8 226 44.16.15.0/24 32915 44.24.240.0/20 12637 44.68.52.0/24 61337 44.127.128.0/24 28748 44.130.99.0/24 56129 44.136.150.0/24 56129 44.136.151.0/24 8973 44.140.0.0/16 1653 44.140.47.0/24 39120 44.208.0.0/16
On Mon, Jun 17, 2013 at 10:59 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jun 17, 2013 at 12:45:10PM -0500, kb9mwr@gmail.com wrote:
I have been curious since ARDC announced that option, how many/which local subnets are not being announced locally.
There are at this moment 10 subnets which are authorized to announce their connectivity via their own BGP announcements.
We don't have an accurate count of tunnel-routed gateways. This is because the gateways list has not yet been audited to include only those gateways that are still operational. We had originally planned to get this done by the first of July but life got in the way and we'll have to set a later date. In the meantime, it's important for all gateway operators to make sure their gateway is registered with the portal as eventually those that aren't registered will be dropped from the gateways list. - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html