Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not being used. If you have or no of a range of IP's that are being used downunder, could you please let me know by emailing samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf)
Why not use portal.ampr.org
Sent from my iPhoney
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" vk4fq@smellyblackdog.com.au wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not being used. If you have or no of a range of IP's that are being used downunder, could you please let me know by emailing samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the portal's existence or purpose. So, the idea would be to contact those who are still actively using addresses, and get them to register their address blocks in the portal.
73, Matt VK2RQ
On 13/07/2013, at 1:06 AM, John Hays john@hays.org wrote:
Why not use portal.ampr.org
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" vk4fq@smellyblackdog.com.au wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not being used. If you have or no of a range of IP's that are being used downunder, could you please let me know by emailing samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 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
We are probably going to flush all old 44.24.x.x soon -- portal.ampr.orgwill be our authoritative source. Australia could consider doing the same. If they aren't connected to the rest of the network it really doesn't matter.
------------------------------ 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 Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ matt.vk2rq@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the portal's existence or purpose. So, the idea would be to contact those who are still actively using addresses, and get them to register their address blocks in the portal.
73, Matt VK2RQ
On 13/07/2013, at 1:06 AM, John Hays john@hays.org wrote:
Why not use portal.ampr.org
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" <
vk4fq@smellyblackdog.com.au> wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not
being
used. If you have or no of a range of IP's that are being used
downunder,
could you please let me know by emailing
samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 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
I suspect this is the direction the new VK coordinator is headed as well. If there are isolated islands out there, then of course they can use any IP addresses they want, but if at some point they decide they want to connect to the wider network, then it is easier if they are sitting on a unique allocation.
73, Matt VK2RQ
On 13/07/2013, at 7:18 AM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ We are probably going to flush all old 44.24.x.x soon -- portal.ampr.orgwill be our authoritative source. Australia could consider doing the same. If they aren't connected to the rest of the network it really doesn't matter.
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 Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ matt.vk2rq@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the portal's existence or purpose. So, the idea would be to contact those who are still actively using addresses, and get them to register their address blocks in the portal.
73, Matt VK2RQ
On 13/07/2013, at 1:06 AM, John Hays john@hays.org wrote:
Why not use portal.ampr.org
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" <
vk4fq@smellyblackdog.com.au> wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not
being
used. If you have or no of a range of IP's that are being used
downunder,
could you please let me know by emailing
samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 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
Or request a new one :)
------------------------------ 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 Fri, Jul 12, 2013 at 3:37 PM, Matt VK2RQ matt.vk2rq@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ I suspect this is the direction the new VK coordinator is headed as well. If there are isolated islands out there, then of course they can use any IP addresses they want, but if at some point they decide they want to connect to the wider network, then it is easier if they are sitting on a unique allocation.
73, Matt VK2RQ
On 13/07/2013, at 7:18 AM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ We are probably going to flush all old 44.24.x.x soon -- portal.ampr.orgwill be our authoritative source. Australia could consider doing the same. If they aren't connected to the rest of the network it really doesn't matter.
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 Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ matt.vk2rq@gmail.com
wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the
portal's
existence or purpose. So, the idea would be to contact those who are
still
actively using addresses, and get them to register their address blocks
in
the portal.
73, Matt VK2RQ
On 13/07/2013, at 1:06 AM, John Hays john@hays.org wrote:
Why not use portal.ampr.org
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" <
vk4fq@smellyblackdog.com.au> wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not
being
used. If you have or no of a range of IP's that are being used
downunder,
could you please let me know by emailing
samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 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
Hi John
Before we took such a drastic move, I was asking to see who actually still used the 44net range in the land downunder. Even the encap.txt file is not a reliable source of information
Thanks to the VK's who are active and contacted me
Sam VK4FQ|VK4AA|VK4TTT
----- Original Message ----- From: "K7VE - John" k7ve@k7ve.org To: "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Saturday, July 13, 2013 9:19 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________ Or request a new one :)
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 Fri, Jul 12, 2013 at 3:37 PM, Matt VK2RQ matt.vk2rq@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ I suspect this is the direction the new VK coordinator is headed as well. If there are isolated islands out there, then of course they can use any IP addresses they want, but if at some point they decide they want to connect to the wider network, then it is easier if they are sitting on a unique allocation.
73, Matt VK2RQ
On 13/07/2013, at 7:18 AM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ We are probably going to flush all old 44.24.x.x soon -- portal.ampr.orgwill be our authoritative source. Australia could consider doing the same. If they aren't connected to the rest of the network it really doesn't matter.
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 Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ matt.vk2rq@gmail.com
wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the
portal's
existence or purpose. So, the idea would be to contact those who are
still
actively using addresses, and get them to register their address blocks
in
the portal.
73, Matt VK2RQ
On 13/07/2013, at 1:06 AM, John Hays john@hays.org wrote:
Why not use portal.ampr.org
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" <
vk4fq@smellyblackdog.com.au> wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not
being
used. If you have or no of a range of IP's that are being used
downunder,
could you please let me know by emailing
samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 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
Hi John
Before we took such a drastic move, I was asking to see who actually still used the 44net range in the land downunder. Even the encap.txt file is not a reliable source of information
Thanks to the VK's who are active and contacted me
Sam VK4FQ|VK4AA|VK4TTT
----- Original Message ----- From: "K7VE - John" k7ve@k7ve.org To: "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Saturday, July 13, 2013 9:19 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________ Or request a new one :)
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 Fri, Jul 12, 2013 at 3:37 PM, Matt VK2RQ matt.vk2rq@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ I suspect this is the direction the new VK coordinator is headed as well. If there are isolated islands out there, then of course they can use any IP addresses they want, but if at some point they decide they want to connect to the wider network, then it is easier if they are sitting on a unique allocation.
73, Matt VK2RQ
On 13/07/2013, at 7:18 AM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ We are probably going to flush all old 44.24.x.x soon -- portal.ampr.orgwill be our authoritative source. Australia could consider doing the same. If they aren't connected to the rest of the network it really doesn't matter.
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 Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ matt.vk2rq@gmail.com
wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the
portal's
existence or purpose. So, the idea would be to contact those who are
still
actively using addresses, and get them to register their address blocks
in
the portal.
73, Matt VK2RQ
On 13/07/2013, at 1:06 AM, John Hays john@hays.org wrote:
Why not use portal.ampr.org
On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" <
vk4fq@smellyblackdog.com.au> wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not
being
used. If you have or no of a range of IP's that are being used
downunder,
could you please let me know by emailing
samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) _________________________________________ 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
Matt the problem will also be some of 44 will be directly connected to the Internet(not thur UCSD) if they have any route to the net the local DNS could cause conflict or just a miss configured router. Just like a few companies have had when using 1.X.x.x as a private LAN. It was Allocated to the US DoD I think, but it looks to have been released now. A mis configured router drew quite a bit of attention from them as you can imagine. I still see 1.1.1.1 used a lot as an interrupt login page at hotels, ect for free or pay Internet.
My understanding is that there may be some rouge direct connected 44 address ranges out there too. This is from a friend at a national CATV/ISP provider. I don't remember the specifics but prior to the policy Change by AMPR regarding this allocation we found some of these in their AS. If memory serves some were in VK. This is some thing we really need to run down.... With 16million addresses this is a hard task to police. I am guessing that ISPs have whole groups that just deal with rouge networks in their IP space. Just running a scan is not going to work as most ISPs will shut ya down if you tried to scan a whole class A. It really needs to be looked at in a AS. Not Brian's at UCSD as his will be correct.
Lin N4YCI
there may be some rouge direct connected 44 address ranges out there too.
All of the BGP announcements on the internet that include 44 space are listed below. Brian says they are all accounted for. I assume that means each of those subnets are registered in the portal.
# 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 8121 44.74.128.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 07/13/2013 07:23 PM, Cory (NQ1E) wrote:
(Please trim inclusions from previous messages) _______________________________________________
there may be some rouge direct connected 44 address ranges out there too.
All of the BGP announcements on the internet that include 44 space are listed below. Brian says they are all accounted for. I assume that means each of those subnets are registered in the portal. --snip--- 8973 44.140.0.0/16 1653 44.140.47.0/24
Hi,
I am the current maintainer of the Swedish subnet 44.140.0.0/16 (se.ampr.org). The Swedish University Network (SUNET, AS 1653) agreed (with Brian's permission) to provide Internet transit for the entire network, which is initially announced out of a research network at KTH (AS8973), one of the universities connected to SUNET. We are slowly but surely distributing gateways to the 256 /24-networks over the country, located at an institution connected to SUNET and maintained by a licensed radio amateur associated with a local club, so that as many radio amateurs as possible can reach at least one of them via radio without tunneling. The basic agreements were arranged a few months ago. Things take time and we so far have only obe gateway up and running, at KTH in Stockholm (SK0WE). Another one (44.140.47.0/24) is coming up in August at the Technical Museum of Stockholm (SK0TM) and we have preparations in progress in almost all of the eight radio amateur districts of Sweden. If an opportunity opens to have an intradomain link to another AMPR subnet, we will take it, but all addresses in use can be reached via Internet transit. At an earlier stage of the restart of AMPRnet, I advocated going for an own AS number for AMPRnet, but I guess the way things have worked out for us is perfectly OK. I am working with a few amatuer colleagues and academic institutions in some African countries to replicate this model to be used for specific applications. One of them is to make environment data publicly available on the web.
Bjorn/SA0BXI
There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
On 13-07-13 02:44 PM, Bjorn Pehrson wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 07/13/2013 07:23 PM, Cory (NQ1E) wrote:
(Please trim inclusions from previous messages) _______________________________________________
there may be some rouge direct connected 44 address ranges out there too.
All of the BGP announcements on the internet that include 44 space are listed below. Brian says they are all accounted for. I assume that means each of those subnets are registered in the portal. --snip--- 8973 44.140.0.0/16 1653 44.140.47.0/24
Hi,
I am the current maintainer of the Swedish subnet 44.140.0.0/16 (se.ampr.org). The Swedish University Network (SUNET, AS 1653) agreed (with Brian's permission) to provide Internet transit for the entire network, which is initially announced out of a research network at KTH (AS8973), one of the universities connected to SUNET. We are slowly but surely distributing gateways to the 256 /24-networks over the country, located at an institution connected to SUNET and maintained by a licensed radio amateur associated with a local club, so that as many radio amateurs as possible can reach at least one of them via radio without tunneling. The basic agreements were arranged a few months ago. Things take time and we so far have only obe gateway up and running, at KTH in Stockholm (SK0WE). Another one (44.140.47.0/24) is coming up in August at the Technical Museum of Stockholm (SK0TM) and we have preparations in progress in almost all of the eight radio amateur districts of Sweden. If an opportunity opens to have an intradomain link to another AMPR subnet, we will take it, but all addresses in use can be reached via Internet transit. At an earlier stage of the restart of AMPRnet, I advocated going for an own AS number for AMPRnet, but I guess the way things have worked out for us is perfectly OK. I am working with a few amatuer colleagues and academic institutions in some African countries to replicate this model to be used for specific applications. One of them is to make environment data publicly available on the web.
Bjorn/SA0BXI _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Well, that is history and should eventually be cleaned up and archived, I guess. As far as I am aware, this does currently not create a problem. When I pointed it out to Brian, he seemed to have the same opinion. Pontus was the previous maintainer and handed it over to me. If you look into the new data base at https://portal.ampr.org/networks.php you will find me there. Bjorn
On 07/13/2013 10:29 PM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
Bob/Boudewijn VE3TOK
On 13-07-13 04:59 PM, Bjorn Pehrson wrote:
Well, that is history and should eventually be cleaned up and archived, I guess. As far as I am aware, this does currently not create a problem. When I pointed it out to Brian, he seemed to have the same opinion. Pontus was the previous maintainer and handed it over to me. If you look into the new data base at https://portal.ampr.org/networks.php you will find me there. Bjorn
On 07/13/2013 10:29 PM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
Oh, sorry that I missed this. Thanks for spotting it. Since Pontus is no longer active and hard to get hold of, it would be great if Chris could remove it. Can you do that Chris? Thanks Bjorn
On 07/14/2013 12:30 AM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
Bob/Boudewijn VE3TOK
Done
On 14 Jul 2013, at 09:58, Bjorn Pehrson bpehrson@kth.se wrote:
(Please trim inclusions from previous messages) _______________________________________________ Oh, sorry that I missed this. Thanks for spotting it. Since Pontus is no longer active and hard to get hold of, it would be great if Chris could remove it. Can you do that Chris? Thanks Bjorn
On 07/14/2013 12:30 AM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
Bob/Boudewijn VE3TOK
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
route addprivate 44.24.240/20 encap 198.178.136.80 route addprivate 44.130.99/24 encap 193.22.2.254 route addprivate 44.136.150/24 encap 203.55.214.21 route addprivate 44.136.151/24 encap 203.55.214.21 route addprivate 44.208/16 encap 94.101.48.134
This will give a problem if your commercial gateway address has changed as in that case we can't reach your subnet. (If I don't remove them manually)
$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 8121 44.74.128.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
Bob/Boudewijn VE3TOK
It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
<Bob/Boudewijn VE3TOK
On 13-07-13 04:59 PM, Bjorn Pehrson wrote:
Well, that is history and should eventually be cleaned up and archived, I guess. As far as I am aware, this does currently not create a problem. When I pointed it out to Brian, he seemed to have the same opinion. Pontus was the previous maintainer and handed it over to me. If you look into the new data base at https://portal.ampr.org/networks.php you will find me there. Bjorn
On 07/13/2013 10:29 PM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
In the case of 44.24.240/20, we were seeing issues where traffic from some networks (including google) wasn't making it back to our ASN for some reason. I was theorizing that perhaps our more specific BGP announcement wasn't being seen/honored in some circumstances in favor of the more generic 44/8 one.
We intentionally setup the IPIP tunnels as an experiment and haven't had that trouble since. I suppose I need to shut that down and see if the problem returns to know for sure. Either way, we're in the encap file intentionally and you don't need to remove it.
On Sat, Jul 13, 2013 at 4:04 PM, Bob Tenty bobtenty@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
route addprivate 44.24.240/20 encap 198.178.136.80 route addprivate 44.130.99/24 encap 193.22.2.254 route addprivate 44.136.150/24 encap 203.55.214.21 route addprivate 44.136.151/24 encap 203.55.214.21 route addprivate 44.208/16 encap 94.101.48.134
This will give a problem if your commercial gateway address has changed as in that case we can't reach your subnet. (If I don't remove them manually)
$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 8121 44.74.128.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
Bob/Boudewijn VE3TOK
It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
<Bob/Boudewijn VE3TOK
On 13-07-13 04:59 PM, Bjorn Pehrson wrote:
Well, that is history and should eventually be cleaned up and archived, I guess. As far as I am aware, this does currently not create a problem. When I pointed it out to Brian, he seemed to have the same opinion. Pontus was the previous maintainer and handed it over to me. If you look into the new data base at https://portal.ampr.org/networks.php you will find me there. Bjorn
On 07/13/2013 10:29 PM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
I wonder if you are creating split horizon problems, which some ISPs won't permit.
------------------------------ 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 Sat, Jul 13, 2013 at 8:44 PM, Cory (NQ1E) cory@nq1e.hm wrote:
(Please trim inclusions from previous messages) _______________________________________________ In the case of 44.24.240/20, we were seeing issues where traffic from some networks (including google) wasn't making it back to our ASN for some reason. I was theorizing that perhaps our more specific BGP announcement wasn't being seen/honored in some circumstances in favor of the more generic 44/8 one.
We intentionally setup the IPIP tunnels as an experiment and haven't had that trouble since. I suppose I need to shut that down and see if the problem returns to know for sure. Either way, we're in the encap file intentionally and you don't need to remove it.
On Sat, Jul 13, 2013 at 4:04 PM, Bob Tenty bobtenty@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ There are more subnets who are announcing themselfs over Internet with
BGP
and who are still in the encap.txt
route addprivate 44.24.240/20 encap 198.178.136.80 route addprivate 44.130.99/24 encap 193.22.2.254 route addprivate 44.136.150/24 encap 203.55.214.21 route addprivate 44.136.151/24 encap 203.55.214.21 route addprivate 44.208/16 encap 94.101.48.134
This will give a problem if your commercial gateway address has changed as in that case we can't reach your subnet. (If I don't remove them manually)
$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 8121 44.74.128.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
Bob/Boudewijn VE3TOK
It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
<Bob/Boudewijn VE3TOK
On 13-07-13 04:59 PM, Bjorn Pehrson wrote:
Well, that is history and should eventually be cleaned up and archived, I guess. As far as I am aware, this does currently not create a problem. When I pointed it out to Brian, he seemed to have the same opinion. Pontus was the previous maintainer and handed it over to me. If you look into the new data base at https://portal.ampr.org/networks.php you will find me there. Bjorn
On 07/13/2013 10:29 PM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
In the case of 44.136.150/23 this was supposed to be deleted from the gateway file ages ago when I removed it as a gateway in the portal - obvious there is a bug in the code LOL
Sam
----- Original Message ----- From: "Bob Tenty" bobtenty@gmail.com To: "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Sunday, July 14, 2013 9:04 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________ There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
route addprivate 44.24.240/20 encap 198.178.136.80 route addprivate 44.130.99/24 encap 193.22.2.254 route addprivate 44.136.150/24 encap 203.55.214.21 route addprivate 44.136.151/24 encap 203.55.214.21 route addprivate 44.208/16 encap 94.101.48.134
This will give a problem if your commercial gateway address has changed as in that case we can't reach your subnet. (If I don't remove them manually)
$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 8121 44.74.128.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
Bob/Boudewijn VE3TOK
It is a really a problem because that entry overrides the default. Maybe Chris can remove it.
73,
<Bob/Boudewijn VE3TOK
On 13-07-13 04:59 PM, Bjorn Pehrson wrote:
Well, that is history and should eventually be cleaned up and archived, I guess. As far as I am aware, this does currently not create a problem. When I pointed it out to Brian, he seemed to have the same opinion. Pontus was the previous maintainer and handed it over to me. If you look into the new data base at https://portal.ampr.org/networks.php you will find me there. Bjorn
On 07/13/2013 10:29 PM, Bob Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case.
route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
73,
Bob/Boudewijn VE3TOK
On 14 Jul 2013, at 09:46, VK4FQ/VK4TTT Sam vk4fq@smellyblackdog.com.au wrote:
(Please trim inclusions from previous messages) _______________________________________________ In the case of 44.136.150/23 this was supposed to be deleted from the gateway file ages ago when I removed it as a gateway in the portal - obvious there is a bug in the code LOL
Not a bug - there were two entries imported from the original encap file:
4.136.150.0 / 24 44.136.151.0 / 24
These have never been claimed so remain in the db under a holding account.
I will delete them now.
Regards, Chris
On Sun, Jul 14, 2013 at 2:04 AM, Bob Tenty bobtenty@gmail.com wrote:
There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.
- Hessu
Not necessarily so.. The 44 addresses not in the encap.txt should be routed to ucsd and they will hopefully tunnel them to that specific gateway. There is normally a line for that in a munge script.
Bob
On 13-07-15 02:54 AM, Heikki Hannikainen wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jul 14, 2013 at 2:04 AM, Bob Tenty bobtenty@gmail.com wrote:
There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.
- Hessu
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, Jul 15, 2013 at 11:21 AM, Bob Tenty bobtenty@gmail.com wrote:
The 44 addresses not in the encap.txt should be routed to ucsd and they will hopefully tunnel them to that specific gateway. There is normally a line for that in a munge script.
I'm sorry, but I don't quite understand. If a subnet is not in encap.txt, the tunnel router in UCSD will not tunnel packets to that specific gateway - it's not much different than any other gateway in that respect, it gets its encap routing table from the very same gateways database. It doesn't have any magic deeper knowledge outside encap.txt.
Maybe, if you updated your own encap routing table very rarely, you could send unknown traffic to UCSD and hope that it updates more often, but even then:
I don't see any reason to remove BGP-announced subnets from encap.txt *except* at gateways which are doing BGP themselves or are otherwise certain that they can send out unencapsulated packets with their own net-44 source addresses. Most sites, these days, won't be able to do that, and they'll need to learn the net-44 tunnel routes somehow even for the BGP announced sites.
On 13-07-15 02:54 AM, Heikki Hannikainen wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jul 14, 2013 at 2:04 AM, Bob Tenty bobtenty@gmail.com wrote:
There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.
The 44 addresses not in the encap.txt should be routed to ucsd and they will hopefully tunnel them to that specific gateway.
Isn't it a good idea to keep ucsd out of the path? If all the (BGP) gateways have to route through UCSD then there's a new 'link' (that can break), an extra hop and much more (we can hope) traffic going through UCSD. One of the benefits of the encap.txt routing table scheme is that it provided independent routes between gateways.
Bill, WA7NWP
Heikki,
But I could (IPIP) tunnel my 44 address back to UCSD and UCSD would route that in a normal way like every other Internet address back to those who make the announcements
My mistake, UCSD would not tunnel but route in a normal way back over Internet to those gateways.
So no entry in the encap.txt is needed for Gateways making BGP announcements.
Bob VE3TOK
On 13-07-16 09:22 AM, Heikki Hannikainen wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jul 15, 2013 at 11:21 AM, Bob Tenty bobtenty@gmail.com wrote:
The 44 addresses not in the encap.txt should be routed to ucsd and they will hopefully tunnel them to that specific gateway. There is normally a line for that in a munge script.
I'm sorry, but I don't quite understand. If a subnet is not in encap.txt, the tunnel router in UCSD will not tunnel packets to that specific gateway - it's not much different than any other gateway in that respect, it gets its encap routing table from the very same gateways database. It doesn't have any magic deeper knowledge outside encap.txt.
Maybe, if you updated your own encap routing table very rarely, you could send unknown traffic to UCSD and hope that it updates more often, but even then:
I don't see any reason to remove BGP-announced subnets from encap.txt *except* at gateways which are doing BGP themselves or are otherwise certain that they can send out unencapsulated packets with their own net-44 source addresses. Most sites, these days, won't be able to do that, and they'll need to learn the net-44 tunnel routes somehow even for the BGP announced sites.
On 13-07-15 02:54 AM, Heikki Hannikainen wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jul 14, 2013 at 2:04 AM, Bob Tenty bobtenty@gmail.com wrote:
There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Tue, Jul 16, 2013 at 04:48:57PM +0300, Heikki Hannikainen wrote:
Also, doesn't amprgw at UCSD drop net-44 packets on the floor unless they're in encap.txt? Or is there an exception for BGP announced networks?
We would drop them since they're not in the encap database, but they don't show up here from the Internet in the first place since the narrower BGP subnets override the larger /8 network and the packets aren't routed here.
It'd be really unfortunate if the BGP sites would be only accessible from the Internet and not from the rest of the amprnet.
That's a choice the BGP-announced subnets have to make. In order to avoid the amprgw connection point as a single point of failure they have chosen to make themselves individual connection points, with all that entails.
44net-only tunnel-connected hosts HAVE to route back to the Internet through amprgw because of the anti-spoofing filters in place on most of their providers' networks, and once the packets are here and decapsulated they're treated as any other packets, which means that if the destination is one of the BGP-routed ("directly-connected") 44net subnets that isn't also participating in the tunnel mesh, the traffic has to flow over the commercial Internet to get there.
I've long thought that tunnels were about the only way to go for internal connectivity in the AMPRNet, but as it's an experimental network and people were getting rather shrill about allowing directly-connected subnets, I figured we might as well try it.
The question reduces to one of internal versus external connectivity.
A solution would be to have the border router at each of the directly-connected subnets also have a full set of tunnel routes and interfaces installed, as it could then participate in the tunnel mesh and should then be in the encap file. I don't see commercial internet providers doing that.
So this means that in order for the the directly-connected subnets to also participate in the tunnel mesh, there has to be a tunnel-enabled router downstream of the connection to the commercial Internet. Thus the only advantage of being directly-connected is simply an independent (quite possibly higher-bandwidth) connection to the commercial Internet backbone. It doesn't improve internal connectivity in the AMPRNet at all. We still need the tunnels for that. - Brian
To me, the reason for having more than one peering point is not only to avoid a singular point of failure, but also all sorts of performance and security issues. Besides robustness, it is about keeping local traffic local. There should be a route between all amprnet addresses in different non-directly connected subnet islands, either via Internet, if the spaces of the different islands are only announced via eBGP, or via intranet links on a per network level, tunnels or direct links whatever, in which case border routers should inform each other via iBGP and all be encap/decap-capable to satisfy anti-spoofing filters. As long as this is properly managed to avoid routing loops, asymmetric routing, etc, we should be able to mix them if there is a reason to do so. I would be prepared to participate in tests of schemes for this if anyone is interested. I am also keeping my eyes open for opportunities of having direct intranet links to other ampr islands.
On 07/16/2013 05:00 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jul 16, 2013 at 04:48:57PM +0300, Heikki Hannikainen wrote:
Also, doesn't amprgw at UCSD drop net-44 packets on the floor unless they're in encap.txt? Or is there an exception for BGP announced networks?
We would drop them since they're not in the encap database, but they don't show up here from the Internet in the first place since the narrower BGP subnets override the larger /8 network and the packets aren't routed here.
It'd be really unfortunate if the BGP sites would be only accessible from the Internet and not from the rest of the amprnet.
That's a choice the BGP-announced subnets have to make. In order to avoid the amprgw connection point as a single point of failure they have chosen to make themselves individual connection points, with all that entails.
44net-only tunnel-connected hosts HAVE to route back to the Internet through amprgw because of the anti-spoofing filters in place on most of their providers' networks, and once the packets are here and decapsulated they're treated as any other packets, which means that if the destination is one of the BGP-routed ("directly-connected") 44net subnets that isn't also participating in the tunnel mesh, the traffic has to flow over the commercial Internet to get there.
I've long thought that tunnels were about the only way to go for internal connectivity in the AMPRNet, but as it's an experimental network and people were getting rather shrill about allowing directly-connected subnets, I figured we might as well try it.
The question reduces to one of internal versus external connectivity.
A solution would be to have the border router at each of the directly-connected subnets also have a full set of tunnel routes and interfaces installed, as it could then participate in the tunnel mesh and should then be in the encap file. I don't see commercial internet providers doing that.
So this means that in order for the the directly-connected subnets to also participate in the tunnel mesh, there has to be a tunnel-enabled router downstream of the connection to the commercial Internet. Thus the only advantage of being directly-connected is simply an independent (quite possibly higher-bandwidth) connection to the commercial Internet backbone. It doesn't improve internal connectivity in the AMPRNet at all. We still need the tunnels for that.
- Brian
On Tue, Jul 16, 2013 at 6:00 PM, Brian Kantor Brian@ucsd.edu wrote:
On Tue, Jul 16, 2013 at 04:48:57PM +0300, Heikki Hannikainen wrote:
Also, doesn't amprgw at UCSD drop net-44 packets on the floor unless they're in encap.txt? Or is there an exception for BGP announced networks?
We would drop them since they're not in the encap database, but they don't show up here from the Internet in the first place since the narrower BGP subnets override the larger /8 network and the packets aren't routed here.
Yes, exactly. How about if someone sends an encapsulated 44-to-44 packet to amprgw, and the packet has a destination address in one of the BGP subnets, and the subnet is not in encap database? Would that get routed out from amprgw (unencapsulated), or would it be dropped?
And wouldn't it be preferred to have that go directly encapsulated to an encap gateway box at the BGP-enabled site?
If I understood him right, Bob Tenty is suggesting that BGP-enabled sites should be removed from the encap database altogether, and says that packets from tunnel-only gateways to those networks should always be sent via amprgw. My opinion is in the opposite end of the spectrum.
A solution would be to have the border router at each of the directly-connected subnets also have a full set of tunnel routes and interfaces installed, as it could then participate in the tunnel mesh and should then be in the encap file. I don't see commercial internet providers doing that.
The border router does not necessarily need a tunnel route + interface set. All that is needed is the traditional linux box sitting near it, that act as the encap gateway with rip44d or whatever. The border router can have a 44/8 route towards the local encap box for outgoing packets, so that packets going to the rest of the old 44/8 does not need to go back to amprgw.ucsd.edu.
If I were to create some fancy new bandwidth-heavy service, and host it on a BGP-enabled net-44 address here, I think my main motive would be to (1) make it available to all net-44 users in addition to the Internet, and (2) make it run fast and not go via amprgw all the time. If I only had BGP but no encap mesh routes, I suspect both (1) and (2) would not happen - I'd just be using a net-44 address on the Internet with quite broken net-44 routing.
So this means that in order for the the directly-connected subnets to also participate in the tunnel mesh, there has to be a tunnel-enabled router downstream of the connection to the commercial Internet.
Yup, my thoughts exactly. Downstream, or on its side.
My point is that the BGP sites *should* have a tunnel-enabled gateway router in their setup, and they should be in the encap routing table to keep them well-connected.
- Hessu
I just think the deal is we really should not be required to do something that we dont have as a project goal. If a BGP site wants to play in the amprgw world great if not then then no. That is like saying your FM radio must also be able to receive SSB to opperate on the 440mhz band. Maybe we dont want to do SSB or incur the extra complexity and cost. I think the idea is these are not the same projects they just use the same "band" IP space there is a plan to divide the sub nets up so that it is easy to see that whole class Bs or what ever is allocated is not necessarily going to be accessible unless you specifically make changes to the apmprgw system. It is not necessary for the packets to route back and forth. It just adds an extra level of complexity that is not needed for our project goals of hosting radio projects that are fully rotatable to the internet.
Lin
On Tue, Jul 16, 2013 at 2:35 PM, Heikki Hannikainen hessu@hes.iki.fi wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jul 16, 2013 at 6:00 PM, Brian Kantor Brian@ucsd.edu wrote:
On Tue, Jul 16, 2013 at 04:48:57PM +0300, Heikki Hannikainen wrote:
Also, doesn't amprgw at UCSD drop net-44 packets on the floor unless they're in encap.txt? Or is there an exception for BGP announced networks?
We would drop them since they're not in the encap database, but they don't show up here from the Internet in the first place since the narrower BGP subnets override the larger /8 network and the packets aren't routed here.
Yes, exactly. How about if someone sends an encapsulated 44-to-44 packet to amprgw, and the packet has a destination address in one of the BGP subnets, and the subnet is not in encap database? Would that get routed out from amprgw (unencapsulated), or would it be dropped?
And wouldn't it be preferred to have that go directly encapsulated to an encap gateway box at the BGP-enabled site?
If I understood him right, Bob Tenty is suggesting that BGP-enabled sites should be removed from the encap database altogether, and says that packets from tunnel-only gateways to those networks should always be sent via amprgw. My opinion is in the opposite end of the spectrum.
A solution would be to have the border router at each of the directly-connected subnets also have a full set of tunnel routes and interfaces installed, as it could then participate in the tunnel mesh and should then be in the encap file. I don't see commercial internet providers doing that.
The border router does not necessarily need a tunnel route + interface set. All that is needed is the traditional linux box sitting near it, that act as the encap gateway with rip44d or whatever. The border router can have a 44/8 route towards the local encap box for outgoing packets, so that packets going to the rest of the old 44/8 does not need to go back to amprgw.ucsd.edu.
If I were to create some fancy new bandwidth-heavy service, and host it on a BGP-enabled net-44 address here, I think my main motive would be to (1) make it available to all net-44 users in addition to the Internet, and (2) make it run fast and not go via amprgw all the time. If I only had BGP but no encap mesh routes, I suspect both (1) and (2) would not happen - I'd just be using a net-44 address on the Internet with quite broken net-44 routing.
So this means that in order for the the directly-connected subnets to also participate in the tunnel mesh, there has to be a tunnel-enabled router downstream of the connection to the commercial Internet.
Yup, my thoughts exactly. Downstream, or on its side.
My point is that the BGP sites *should* have a tunnel-enabled gateway router in their setup, and they should be in the encap routing table to keep them well-connected.
- Hessu
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Tue, Jul 16, 2013 at 9:45 PM, Lin Holcomb LHolcomb@clearqualitygroup.com wrote:
I just think the deal is we really should not be required to do something that we dont have as a project goal. If a BGP site wants to play in the amprgw world great if not then then no.
It is not necessary for the packets to route back and forth. It just adds an extra level of complexity that is not needed for our project goals of hosting radio projects that are fully rotatable to the internet.
Hmm, just checking, if I understand right:
Your project is about hosting radio projects that are fully routable to the Internet. You do not wish to be accessible from the rest of Amprnet, over amateur radio for example.
Why do you need to use 44/8 addresses then, if not for being available on the Amprnet?
I always thought that the cool thing about using 44/8 with BGP announcements would be that they'd be accessible over both the normal Internet routing infrastructure *and* over radio from various Amprnet gateway sites. And that whenever a 44/8 source address would be seen at my service, I could tell that it would be originated by an amateur radio operator.
- Hessu
On Tue, Jul 16, 2013 at 09:35:03PM +0300, Heikki Hannikainen wrote:
How about if someone sends an encapsulated 44-to-44 packet to amprgw, and the packet has a destination address in one of the BGP subnets, and the subnet is not in encap database? Would that get routed out from amprgw (unencapsulated), or would it be dropped?
It's supposed to get routed out unencapsulated. I haven't tested that to make sure it works.
And wouldn't it be preferred to have that go directly encapsulated to an encap gateway box at the BGP-enabled site?
I think it should, for network efficiency and robustness. Perhaps we should make that a required part of the network architecture? - Brian
On Tue, Jul 16, 2013 at 10:20 PM, Brian Kantor Brian@ucsd.edu wrote:
On Tue, Jul 16, 2013 at 09:35:03PM +0300, Heikki Hannikainen wrote:
How about if someone sends an encapsulated 44-to-44 packet to amprgw, and the packet has a destination address in one of the BGP subnets, and the subnet is not in encap database? Would that get routed out from amprgw (unencapsulated), or would it be dropped?
It's supposed to get routed out unencapsulated. I haven't tested that to make sure it works.
Tested, does not work:
44.74.128.0/24 is announced using BGP, but it's not in the encap routing table yet. There is an APRS-IS server in that block now (44.74.128.25, fifth.aprs.net, one of rotate.aprs.net core servers - cool, an APRS-IS core server on AMPRNet *and* the Internet at the same time with a single address!).
I manually added an encap route on my amprnet encap gateway, pointed it to amprgw.ucsd.edu. Packets go out towards amprgw, but replies don't come back. Here's the tcpdump -vv output for packet to amprgw and the reply from there:
22:46:44.558642 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPIP (4), length 80) 85.188.1.118 > 169.228.66.251: IP (tos 0x0, ttl 64, id 64699, offset 0, flags [DF], proto TCP (6), length 60) 44.139.39.8.33351 > 44.74.128.25.14501: Flags [S], cksum 0x254d (correct), seq 802450829, win 14400, options [mss 1440,sackOK,TS val 1479217 ecr 0,nop,wscale 2], length 0
22:46:44.757626 IP (tos 0x0, ttl 42, id 49221, offset 0, flags [none], proto IPIP (4), length 76) 169.228.66.251 > 85.188.1.118: IP (tos 0xc0, ttl 254, id 37842, offset 0, flags [none], proto ICMP (1), length 56) 137.110.222.1 > 44.139.39.8: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 64699, offset 0, flags [DF], proto TCP (6), length 60) 44.139.39.8.33351 > 44.74.128.25.14501: tcp 40
Seems to be a routing loop somewhere over there, 137.110.222.1 probably routes all of 44/8 to amprgw (maybe it has a static route for 44/8 and does not have the full BGP routing table with more specific routes announced elsewhere) and amprgw then gives packet destined to 44.74.128.25 back to 137.110.222.1 since it's not in the encap routing table. Or something along those lines.
And wouldn't it be preferred to have that go directly encapsulated to an encap gateway box at the BGP-enabled site?
I think it should, for network efficiency and robustness. Perhaps we should make that a required part of the network architecture?
That's what I would propose, just to keep the amprnet interconnected.
It'd be counterintuitive if some of the really advanced cool sites, which set up BGP for performance and robustness, would resort back to relying on amprgw for their amprnet traffic.
- Hessu
On Tue, Jul 16, 2013 at 10:59:10PM +0300, Heikki Hannikainen wrote:
Tested, does not work:
Seems to be a routing loop somewhere over there, 137.110.222.1 probably routes all of 44/8 to amprgw (maybe it has a static route for 44/8 and does not have the full BGP routing table with more specific routes announced elsewhere) and amprgw then gives packet destined to 44.74.128.25 back to 137.110.222.1 since it's not in the encap routing table.
That is precisely what's happening. 137.110.222.1 is an internal router with no BGP so it'll never learn about those directly-connected subnets. - Brian
I think the other thing to keep in mind is that the more that is shown to be routable on the network the more chances we can keep the IP poachers out and stave off any questions from ARIN on why the allocation exists and what it is being used for that a 10/8 space would not be substituent.
Lin
On Tue, Jul 16, 2013 at 4:08 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jul 16, 2013 at 10:59:10PM +0300, Heikki Hannikainen wrote:
Tested, does not work:
Seems to be a routing loop somewhere over there, 137.110.222.1 probably routes all of 44/8 to amprgw (maybe it has a static route for 44/8 and does not have the full BGP routing table with more specific routes announced elsewhere) and amprgw then gives packet destined to 44.74.128.25 back to 137.110.222.1 since it's not in the encap routing table.
That is precisely what's happening. 137.110.222.1 is an internal router with no BGP so it'll never learn about those directly-connected subnets. - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, 15 Jul 2013, Heikki Hannikainen wrote:
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.
Existance of a route in the encap file implies there is a tunnel established at the other end willing to accept the encapsulated traffic. The sites doing BGP may or may not be doing that. If the latter, then you're just sending traffic to a black hole.
Most gateways don't have visibility into the core routing tables. As you already mentioned, due to upstream service providers doing uRPF filtering, 44-to-any traffic must be tunneled through a gateway. For the non-encap net-44 destinations that means tunnelling through the UCSD gateway. You will need to setup a default (not just net-44) encap route pointing to UCSD but apply it only to traffic sourced from net-44 hosts - ie. policy routing for net-44.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
We are not really planing on doing both inside the same IP ranges in Georgia(US) the north Atlanta LAN will still be on 44.36 and the BGP space will be on 44.37 per Brian. (As soon as our ISP completes its upstream provider switch.) mooching hobby type stuff comes last on The list of things to do for them. We can add the functionality I guess, but wouldn't it just be better for the routing directly to these addresses instead of going in and out and sideway. Lin
On Monday, July 15, 2013, Antonio Querubin wrote:
(Please trim inclusions from previous messages) ______________________________**_________________ On Mon, 15 Jul 2013, Heikki Hannikainen wrote:
But but... I think they absolutely must stay in encap.txt even if a
BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.
Existance of a route in the encap file implies there is a tunnel established at the other end willing to accept the encapsulated traffic. The sites doing BGP may or may not be doing that. If the latter, then you're just sending traffic to a black hole.
Most gateways don't have visibility into the core routing tables. As you already mentioned, due to upstream service providers doing uRPF filtering, 44-to-any traffic must be tunneled through a gateway. For the non-encap net-44 destinations that means tunnelling through the UCSD gateway. You will need to setup a default (not just net-44) encap route pointing to UCSD but apply it only to traffic sourced from net-44 hosts - ie. policy routing for net-44.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com ______________________________**___________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/**mailman/listinfo/44nethttp://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.**html http://www.ampr.org/donate.html
On Mon, 15 Jul 2013, Lin Holcomb wrote:
We are not really planing on doing both inside the same IP ranges in Georgia(US) the north Atlanta LAN will still be on 44.36 and the BGP space will be on 44.37 per Brian. (As soon as our ISP completes its upstream provider switch.) mooching hobby type stuff comes last on The list of things to do for them. We can add the functionality I guess, but wouldn't it just be better for the routing directly to these addresses instead of going in and out and sideway.
Of course it is but not everyone can convince their upstream to route their net-44 prefixes in their route tables and announce them via BGP. If that were easy, we wouldn't have the encap table we have today.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
Makes it a lot easier when you and your upstream are both Amateurs.. We get our biggest drama from the USA carriers, as they demand written approval We have been luck so far with the response from Brian - but have been warned they should be signed and on a letter head... ----- Original Message ----- From: "Antonio Querubin" tony@lavanauts.org To: lholcomb@clearqualitygroup.com; "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Tuesday, July 16, 2013 8:21 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________ On Mon, 15 Jul 2013, Lin Holcomb wrote:
We are not really planing on doing both inside the same IP ranges in Georgia(US) the north Atlanta LAN will still be on 44.36 and the BGP space will be on 44.37 per Brian. (As soon as our ISP completes its upstream provider switch.) mooching hobby type stuff comes last on The list of things to do for them. We can add the functionality I guess, but wouldn't it just be better for the routing directly to these addresses instead of going in and out and sideway.
Of course it is but not everyone can convince their upstream to route their net-44 prefixes in their route tables and announce them via BGP. If that were easy, we wouldn't have the encap table we have today.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, Jul 15, 2013 at 11:27 PM, Antonio Querubin tony@lavanauts.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, 15 Jul 2013, Heikki Hannikainen wrote:
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
Existance of a route in the encap file implies there is a tunnel established at the other end willing to accept the encapsulated traffic. The sites doing BGP may or may not be doing that. If the latter, then you're just sending traffic to a black hole.
I would suggest that all of the BGP-enabled sites should have tunnel endpoints like before, so that all the old non-BGP net-44 sites can talk directly to the BGP sites, even when they old sites are behind uRPF/spoofing filters and cannot transmit unencapsulated net-44 traffic.
If one of the major reasons to do BGP announcements in the first place is to reduce traffic going via UCSD, then it makes a lot of sense to keep the old tunnel endpoints in place, and not have all traffic from non-BGP sites to BGP sites go via UCSD. It's good for latency and resiliency.
- Hessu
On Sat, Jul 13, 2013 at 04:29:43PM -0400, Bob Tenty wrote:
There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case. route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX
That was supposed to have been deleted long ago. - Brian
Cory There are a few others that use 55707 and a few more for 56129 waiting for upstream to allow them
Sam ----- Original Message ----- From: "Cory (NQ1E)" cory@nq1e.hm To: lholcomb@clearqualitygroup.com; "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Sunday, July 14, 2013 3:23 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________
there may be some rouge direct connected 44 address ranges out there too.
All of the BGP announcements on the internet that include 44 space are listed below. Brian says they are all accounted for. I assume that means each of those subnets are registered in the portal.
# 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 8121 44.74.128.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
There are a few others that use 55707
Sam,
If 55707 is announcing 44 blocks, they don't appear to be globally visible. Here's what's visable from that AS right now:
# curl -s http://thyme.rand.apnic.net/current/data-ASnet-detail | sed -n '/^55707/,/^\w/ p' 55707 101.2.168.0/22 103.1.108.0/22 103.5.88.0/24 223.25.112.0/23 223.25.112.0/22 223.25.118.0/23
I think they are waiting for upstream to do there filtering
----- Original Message ----- From: "Cory (NQ1E)" cory@nq1e.hm To: "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Monday, July 15, 2013 8:46 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________
There are a few others that use 55707
Sam,
If 55707 is announcing 44 blocks, they don't appear to be globally visible. Here's what's visable from that AS right now:
# curl -s http://thyme.rand.apnic.net/current/data-ASnet-detail | sed -n '/^55707/,/^\w/ p' 55707 101.2.168.0/22 103.1.108.0/22 103.5.88.0/24 223.25.112.0/23 223.25.112.0/22 223.25.118.0/23
In Australia as far as I know the only ones who are directly connected are those entries in the bgp table Which only numbers a couple ----- Original Message ----- From: "Lin Holcomb" LHolcomb@clearqualitygroup.com To: "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Sunday, July 14, 2013 2:31 AM Subject: Re: [44net] Re Networks in OZ
(Please trim inclusions from previous messages) _______________________________________________ Matt the problem will also be some of 44 will be directly connected to the Internet(not thur UCSD) if they have any route to the net the local DNS could cause conflict or just a miss configured router. Just like a few companies have had when using 1.X.x.x as a private LAN. It was Allocated to the US DoD I think, but it looks to have been released now. A mis configured router drew quite a bit of attention from them as you can imagine. I still see 1.1.1.1 used a lot as an interrupt login page at hotels, ect for free or pay Internet.
My understanding is that there may be some rouge direct connected 44 address ranges out there too. This is from a friend at a national CATV/ISP provider. I don't remember the specifics but prior to the policy Change by AMPR regarding this allocation we found some of these in their AS. If memory serves some were in VK. This is some thing we really need to run down.... With 16million addresses this is a hard task to police. I am guessing that ISPs have whole groups that just deal with rouge networks in their IP space. Just running a scan is not going to work as most ISPs will shut ya down if you tried to scan a whole class A. It really needs to be looked at in a AS. Not Brian's at UCSD as his will be correct.
Lin N4YCI
-- Lin Holcomb
Office: +1 404 806 5412 Mobile: +1 404 933 1595 Fax: +1 404 348 4250
On Fri, 2013-07-12 at 14:18 -0700, K7VE - John wrote:
We are probably going to flush all old 44.24.x.x soon -- portal.ampr.org will be our authoritative source.
That's what I've been trying to do in the various subnets within 1-land. So far those I knew who had addresses have given up on 44-net because while they point fingers at us that 44-net doesn't work, when infact -they- don't know how to configure an ipip tunnel.
Hey Chris,
Do you want to get involved in this? Do you know any amateurs in WA.au who do or could make use of addresses in the 44/8 ?
Cheers,
C.J.
On Fri, 2013-07-12 at 12:15 +1000, VK4FQ/VK4TTT Sam wrote:
(Please trim inclusions from previous messages) _______________________________________________ Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not being used. If you have or no of a range of IP's that are being used downunder, could you please let me know by emailing samantha@smellyblackdog.com.au
Regards
Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf)
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
-
Antonio Querubin -
Bill Vodall -
Bjorn Pehrson -
Bob Tenty -
Brian Kantor -
Brian Rogers -
C.J. Adams-Collier KF7BMP -
Chris -
Cory (NQ1E) -
Heikki Hannikainen -
John D. Hays -
John Hays
-
K7VE - John -
Lin Holcomb -
Matt VK2RQ -
VK4FQ/VK4TTT Sam