16 Jun
2015
16 Jun
'15
7:51 p.m.
I am in the same boat as Bob. Home connection with limited inbound
speed. So the DNS filtering is nice. It also lets my wireless LAN
end users easily decide if they want inbound internet connectivity or
not (when that portion of the portal gets done) without having to get
a hold of me to set a firewall rule for them.
I also like the idea of other VPN technologies being an option. One
being stateful for those in uncool firewall situations .
Sometime back I though maybe one day there would be multiple regional
portals (connected with BGP and all running the open portal code/web
interface) where end gateways could connect using a couple different
vpn technologies.
I understand the problem at hand with the fragmentation between the
BGP vs IPIP segments. Or I think I do, from my end I know hamwan is
BGP connected and have problems reaching it:
I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if
the 44 address you are trying to reach isn't in the RIP list, like
hamwan is, it defaults to route it to UCSD. That doesn't work for me,
as you will see below. But when I override that, and tell it to go
out eth0 like all non 44net traffic it then works.
Or is there something special I can do in my configs to fix this?
root@44.92.21.1:~# ip route show table 44 | grep 44.24
44.24.0.0/20 via 66.114.139.158 dev tunl0 proto 44 onlink window 840
44.24.10.0/24 via 192.231.186.20 dev tunl0 proto 44 onlink window 840
44.24.192.0/24 via 38.104.126.22 dev tunl0 proto 44 onlink window 840
44.24.194.0/24 via 216.161.250.189 dev tunl0 proto 44 onlink window 840
44.24.196.0/24 via 24.113.42.14 dev tunl0 proto 44 onlink window 840
root@44.92.21.35:~# ping hamwan.org
PING hamwan.org (44.24.241.98) 56(84) bytes of data.
From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu
(137.110.222.1)
icmp_seq=2 Time to live exceeded
From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu
(137.110.222.1)
icmp_seq=3 Time to live exceeded
^C
--- hamwan.org ping statistics ---
6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5002ms
root@44.92.21.35:~# ping hambook.de.ampr.org
PING hambook.de.ampr.org (44.225.56.138) 56(84) bytes of data.
64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138):
icmp_req=1 ttl=55 time=189 ms
64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138):
icmp_req=2 ttl=55 time=175 ms
^C
--- hambook.de.ampr.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 175.383/182.595/189.808/7.225 ms
---- Quote ----
I appreciate especially the filtering out of 44 addresses who are
not in the dns by ucsd. I hate to loose that when it goes to another ISP.
I remember well the days when that extra garbage was not filtered out
and I will hate it when that is lost.
My gateway is presently just at a home connection with a static ip.
I object when that stuff is moved and no filtering will be in place
whatsoever. With other words: UCSD is working fine.
So why is it that those BGP subnets have no mandatory IPIP entries
in the list also? They don't have to route back over IPIP, only need
to receive IPIP.
Easy solution, nothing drastic, KISS, and done in no time..
Bob VE3TOK
16 Jun
16 Jun
9:55 p.m.
New subject: AMPRNet Interoperability with BGP
On Tue, Jun 16, 2015 at 4:51 PM, Steve L <kb9mwr(a)gmail.com> wrote:
I understand the problem at hand with the
fragmentation between the
BGP vs IPIP segments. Or I think I do, from my end I know hamwan is
BGP connected and have problems reaching it:
I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if
the 44 address you are trying to reach isn't in the RIP list, like
hamwan is, it defaults to route it to UCSD. That doesn't work for me,
as you will see below. But when I override that, and tell it to go
out eth0 like all non 44net traffic it then works.
BTW, HamWAN used to be "in the RIP list". The entry was deleted by an
AMPR administrator because he thought it wasn't working. We were using
44.24.221.1 as the gateway address. This address was advertised via
BGP, accessible from the internet at large, and intentionally NOT
advertised via RIP so that other gateways would not try to contact it
inside an IPIP packet. This setup was spot-checked from a number of
other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a
static 44/8 route to their gateway. Note that there is no 44/8 route
in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a
bit and utilize another IP address from our ISP to get it running on a
non-44 gateway IP. The simpler solution (and one that serves all BGP
networks) is to work towards solving the underlying BGP/IPIP
interoperability problem that started this thread.
Tom KD7LXL
10:37 p.m.
New subject: AMPRNet Interoperability with BGP
We were using 44.24.221.1 as the gateway address.
[...]
We'd have to reconfigure things a bit and utilize
another IP
address from our ISP to get it running on a non-44 gateway IP.
HamWAN had to switch to using a 44 ip on the IPIP endpoint when it became
an independent autonomous system on the internet. In order to maintain
shortest path and high availability, the IP needs to be on one of the
prefixes that HamWAN announces directly (which is only 44-based prefixes).
If another ISP's address was used instead, the traffic would be forced to
travel though (and have a dependency on) that specific ISP's network.
The ideal workaround would be to get a /24 outside of 44/8 that HamWAN
could announce from its ASN. That's not only prohibitively expensive, but
a waste of resources and a silly thing to do just to route around the
misconfigurations of others.
As a result, it was decided that it was better to maintain high
availability for those who wanted to actively use the HamWAN network
instead of making it less available, but generally reachable to all 44net
users.
17 Jun
17 Jun
12:09 a.m.
New subject: AMPRNet Interoperability with BGP
I can confirm this.
HamWAN's setup, advertizing 44.24.241.0/24 via 44.24.221.1 worked flawless
under the condition to drop that nonfunctional default 44/8 to ampr-gw route
and NAT that traffic as any other internet traffic to the public IP.
But since nobody wants to drop that route... Whatever.
Btw, not a single setup tutorial talks about setting that 44/8 via ampr-gw.
Marius
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom
Hayward
Sent: Wednesday, June 17, 2015 04:56
To: AMPRNet working group
Subject: Re: [44net] AMPRNet Interoperability with BGP
BTW, HamWAN used to be "in the RIP list". The entry was deleted by an
AMPR administrator because he thought it wasn't working. We were using
44.24.221.1 as the gateway address. This address was advertised via
BGP, accessible from the internet at large, and intentionally NOT
advertised via RIP so that other gateways would not try to contact it
inside an IPIP packet. This setup was spot-checked from a number of
other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a
static 44/8 route to their gateway. Note that there is no 44/8 route
in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a
bit and utilize another IP address from our ISP to get it running on a
non-44 gateway IP. The simpler solution (and one that serves all BGP
networks) is to work towards solving the underlying BGP/IPIP
interoperability problem that started this thread.
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:42 a.m.
New subject: AMPRNet Interoperability with BGP
Can't you put that entry back if that worked Tom?
Bob VE3TOK
On 15-06-16 09:55 PM, Tom Hayward wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Tue, Jun 16, 2015 at 4:51 PM, Steve L <kb9mwr(a)gmail.com> wrote:
I understand the problem at hand with the
fragmentation between the
BGP vs IPIP segments. Or I think I do, from my end I know hamwan is
BGP connected and have problems reaching it:
I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if
the 44 address you are trying to reach isn't in the RIP list, like
hamwan is, it defaults to route it to UCSD. That doesn't work for me,
as you will see below. But when I override that, and tell it to go
out eth0 like all non 44net traffic it then works.
BTW, HamWAN used to be "in
the RIP list". The entry was deleted by an
AMPR administrator because he thought it wasn't working. We were using
44.24.221.1 as the gateway address. This address was advertised via
BGP, accessible from the internet at large, and intentionally NOT
advertised via RIP so that other gateways would not try to contact it
inside an IPIP packet. This setup was spot-checked from a number of
other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a
static 44/8 route to their gateway. Note that there is no 44/8 route
in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a
bit and utilize another IP address from our ISP to get it running on a
non-44 gateway IP. The simpler solution (and one that serves all BGP
networks) is to work towards solving the underlying BGP/IPIP
interoperability problem that started this thread.
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:47 a.m.
New subject: AMPRNet Interoperability with BGP
On Tue, Jun 16, 2015 at 10:42 PM, Boudewijn (Bob) Tenty
<bobtenty(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Can't you put that entry back if that worked Tom?
Good question! No, a change to the portal around the same time
prohibits adding 44.xx.xx.xx addresses as gateways. I believe there
was some noise on this list about it at the time.
Tom KD7LXL
2:01 a.m.
New subject: AMPRNet Interoperability with BGP
On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote:
Good question! No, a change to the portal around the
same time
prohibits adding 44.xx.xx.xx addresses as gateways. I believe there
was some noise on this list about it at the time.
That change was made because
1) it was reported that 44.x gateway addresses didn't work
2) it was reported that 44.x gateway addresses caused problems
3) people were entering 44.x gateway addresses for their IPIP tunnels
instead of the proper commercial IP address of the endpoint.
There were, in fact, several of case (3) which of course did NOT work.
If in fact the HAMWAN entry is needed, I can ask Chris to undo the
restriction and then we'll just have to be extra vigilent about checking
new gateway entries. Mistakes will happen and have to be corrected.
- Brian
2:45 a.m.
New subject: AMPRNet Interoperability with BGP
On Tue, Jun 16, 2015 at 11:01 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
If in fact the HAMWAN entry is needed, I can ask Chris
to undo the
restriction and then we'll just have to be extra vigilent about checking
new gateway entries. Mistakes will happen and have to be corrected.
A more robust check would be to ping whatever gateway IP is entered.
If a reply is received, allow it, if not, report the error to the user
("no route to host", etc.). Also check that the IP is not within its
own subnet. I'd be impressed if someone succeeded in passing the first
test and not the second, but not surprised.
(If you're one of those who blocks ICMP, you're intentionally breaking
things and you can deal with your own mess.)
Tom KD7LXL
11:06 a.m.
New subject: AMPRNet Interoperability with BGP
For those using ampr-ripd, the latest version (1.13) does NOT set a route if
the gateway falls inside its own 44net subnet, actually preventing those
situations.
The condition for it to work is, of course, NOT to have a default 44/8 route
via ampr-gw, so that unknown 44net destination are NAT-ed to the gateway's
public IP.
Marius, YO2LOJ
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom
Hayward
Sent: Wednesday, June 17, 2015 09:46
To: AMPRNet working group
Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages)
_______________________________________________
On Tue, Jun 16, 2015 at 11:01 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
If in fact the HAMWAN entry is needed, I can ask Chris
to undo the
restriction and then we'll just have to be extra vigilent about checking
new gateway entries. Mistakes will happen and have to be corrected.
A more robust check would be to ping whatever gateway IP is entered.
If a reply is received, allow it, if not, report the error to the user
("no route to host", etc.). Also check that the IP is not within its
own subnet. I'd be impressed if someone succeeded in passing the first
test and not the second, but not surprised.
(If you're one of those who blocks ICMP, you're intentionally breaking
things and you can deal with your own mess.)
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
11:36 a.m.
New subject: AMPRNet Interoperability with BGP
Since this is a recurring question, what NAT has to do with this...
Scenario: unknown 44net destination address, possible BGP announced:
- To operate a tunnel, one needs a public IP as an endpoint (if not BGP
routed).
- All outgoing 44net traffic will usually originate from the local 44.x.x.x
address and go via IPIP tunnels to their partners
- Replies will return via the same tunnel
- If the destination 44net IP has no known route, it will go the default
route, still being originated from a 44.x.x.x address.
- If the ISP has source filtering it will end here
- If the ISP accepts source 44.x.x.x it will reach the endpoind (let's say a
BGP routed IP) via regular internet
- The reply will be routed back to ampr-gw (since that is the route for all
44/8 traffic if not specified by a tighter BGP route).
- Since ampr-gw does not route data from 44net addresses from the internet
to 44net addresses on tunnels, it will die here.
So, in these conditions, communications are not possible.
And here comes NAT into play:
- unknown 44net destinations will be src-nated from the originating 44.x.x.x
to the GW's public IP
- it will be routed from this public IP to the destination 44net system
- replies will be routed back to the originating system
- replies will be dst-nated utomatically and forwarded back to the
originator.
And voila, it works flawless.
Marius, YO2LOJ
2:20 p.m.
New subject: AMPRNet Interoperability with BGP
On 17.06.2015 17:06, Marius Petrescu wrote:
For those using ampr-ripd, the latest version (1.13)
does NOT set a route if
the gateway falls inside its own 44net subnet, actually preventing those
situations.
The condition for it to work is, of course, NOT to have a default 44/8 route
via ampr-gw, so that unknown 44net destination are NAT-ed to the gateway's
public IP.
it would be nice if you can add the following feature (optional) to the
ampr-ripd:
* Parse the received routing information by RIP for IPIP-Gateways hosted
on an IP-address within 44/8 (e.g. 44.24.221.1 for HamWAN).
* Load the Defaultgateway of the local system from IP-Table "Main" into
Memory (e.g. 141.75.244.1 at my DB0FHN box)
* Set a hostroute to each individual parsed IPIP-Gateway using the
Defaultgateway in a routing table chosen by the user (e.g. 44.24.221.1
via 141.75.244.1 in table "Main" at DB0FHN)
I did this manually to test the interconnection with the
HamWAN-Community. Worked like a charm :)
73,
Jann
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
2:32 p.m.
New subject: AMPRNet Interoperability with BGP
Hi Jann,
This is a good idea.
It will go in the next version, together with default raw sockets (I
understood that multicast doesn't work as it should on new kernels) and
tweaks to support a pid file.
Marius, YO2LOJ
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Jann
Traschewski
Sent: Wednesday, June 17, 2015 21:20
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages)
_______________________________________________
On 17.06.2015 17:06, Marius Petrescu wrote:
For those using ampr-ripd, the latest version (1.13)
does NOT set a route
if
the gateway falls inside its own 44net subnet,
actually preventing those
situations.
The condition for it to work is, of course, NOT to have a default 44/8
route
via ampr-gw, so that unknown 44net destination are
NAT-ed to the gateway's
public IP.
it would be nice if you can add the following feature (optional) to the
ampr-ripd:
* Parse the received routing information by RIP for IPIP-Gateways hosted
on an IP-address within 44/8 (e.g. 44.24.221.1 for HamWAN).
* Load the Defaultgateway of the local system from IP-Table "Main" into
Memory (e.g. 141.75.244.1 at my DB0FHN box)
* Set a hostroute to each individual parsed IPIP-Gateway using the
Defaultgateway in a routing table chosen by the user (e.g. 44.24.221.1
via 141.75.244.1 in table "Main" at DB0FHN)
I did this manually to test the interconnection with the
HamWAN-Community. Worked like a charm :)
73,
Jann
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2:45 a.m.
New subject: AMPRNet Interoperability with BGP
On 17 Jun 2015, at 07:01, Brian Kantor
<Brian(a)ucsd.edu> wrote:
If in fact the HAMWAN entry is needed, I can ask Chris to undo the
restriction and then we'll just have to be extra vigilent about checking
new gateway entries.
I could always put a warning up but still allow the configuration, rather than simply not
allowing it at all?
Chris
2:46 p.m.
New subject: AMPRNet Interoperability with BGP
On Tue, Jun 16, 2015 at 11:01 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
There were, in fact, several of case (3) which of course did NOT work.
If in fact the HAMWAN entry is needed, I can ask Chris to undo the
restriction and then we'll just have to be extra vigilent about checking
new gateway entries. Mistakes will happen and have to be corrected.
The difference is that 44 addresses can be valid gateway destinations as
long as that IP doesn't exist in any of the subnets that have IPIP tunnels
configured.
There's a good chance that the mistakes others made were specifying a
44-based gateway address that existed within the same subnet they're trying
to tunnel. Assuming Chris already has an easy way to do IP math in the
portal, then he should still be able to restrict that mistake. If you
wanted to be thorough, you could also reject any gateway IP that happens to
match the subnet of any tunnel.
18 Jun
18 Jun
5:31 p.m.
New subject: AMPRNet Interoperability with BGP
Has anyone had any luck with finding an ISP that will host our tunnels?
- Brian
5:45 p.m.
New subject: amprnet portal
Hi,
I have got a message that my account has been de-activated because haven't used for
six months. Surprised this happens, once you setup your subnets/gateways don't really
need to login that often?
Was just wondering how I re-activate my account now, do I re-register to see my subnet
allocation etc?
Regards,
Bob, m1duo
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and
may also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England
& Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2548782
19 Jun
19 Jun
1:53 a.m.
New subject: AMPRNet Interoperability with BGP
On 6/18/15 5:31 PM, Brian Kantor wrote:
Has anyone had any luck with finding an ISP that will
host our tunnels?
Brian,
I've asked for traffic details amongst others info on the amprgw and to date
not seen anything. All I'm looking for is the 95th percentile of traffic into
and out of amprgw to the internet. If this is indeed on a 10g connection like
it was stated, this may be larger than I though it was.
I'm sure I one company that will do it for us, but I'm not going to formally
approach my contacts until I have details. Basically we're just looking for
transit for a non-profit org at this point.
This would be for the anycast solution, so we'd need to have a common AS as if
not the BGP protocol would use the lower AS in all cases of it being equal.
Are we planing to have the prefixes we announce based on our IGP
(ampr-ripd/encap), or will they be static with new prefixes manually
configured when an IP is assigned out of that block?
From an operational standpoint I can see us needing to
use radb/prefix
validation to update our upstream filters unless we LOA the entire
/8.\
Will we have this router running on Linux, and if so what sort of
box/cpu/memory/IO do we need? Would a VM work? I have rack space for at
least a few RU.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
17 Jun
17 Jun
1:48 a.m.
New subject: AMPRNet Interoperability with BGP
It was I who deleted it because I was told it was causing problems.
If that was wrong and it was working and not causing problems
then I can put it back or Tom can.
- Brian
On Wed, Jun 17, 2015 at 01:42:00AM -0400, Boudewijn (Bob) Tenty wrote:
Can't you put that entry back if that worked Tom?
Bob VE3TOK
On 15-06-16 09:55 PM, Tom Hayward wrote:
>BTW, HamWAN used to be "in the RIP list". The entry was deleted by an
>AMPR administrator because he thought it wasn't working. We were using
>44.24.221.1 as the gateway address. This address was advertised via
>BGP, accessible from the internet at large, and intentionally NOT
>advertised via RIP so that other gateways would not try to contact it
>inside an IPIP packet. This setup was spot-checked from a number of
>other AMPR systems and proven to work.
>
>The only case where it didn't work is when administrators added a
>static 44/8 route to their gateway. Note that there is no 44/8 route
>in the RIP/encap list.
>
>We're at a bit of a stalemate now. We'd have to reconfigure things a
>bit and utilize another IP address from our ISP to get it running on a
>non-44 gateway IP. The simpler solution (and one that serves all BGP
>networks) is to work towards solving the underlying BGP/IPIP
>interoperability problem that started this thread.
16 Jun
16 Jun
11:59 p.m.
New subject: AMPRNet Interoperability with BGP
Steve,
Defaulting unknown 44net traffic to UCSD does not work since ampr-gw does
not forward traffic betweem 44 endpoints.
That default route to UCSD is an ancient "fossil" from the munge script and
is wrong.
Just drop that route, treat BGP announced networks as an regular internet
connection via your public IP and it should work.
Marius, YO2LOJ
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Steve
L
Sent: Wednesday, June 17, 2015 02:51
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] AMPRNet Interoperability with BGP
I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if
the 44 address you are trying to reach isn't in the RIP list, like
hamwan is, it defaults to route it to UCSD. That doesn't work for me,
as you will see below. But when I override that, and tell it to go
out eth0 like all non 44net traffic it then works.
Or is there something special I can do in my configs to fix this?
3443
days inactive
3446
days old
18 comments
10 participants
participants (10)
-
Bob Easthope -
Boudewijn (Bob) Tenty -
Brian Kantor -
Bryan Fields -
Chris -
Cory (NQ1E) -
Jann Traschewski -
Marius Petrescu -
Steve L -
Tom Hayward