10 Apr
2014
10 Apr
'14
8:14 a.m.
Hi,
In trying to migrate HamWAN to IPIP anycast as discussed in a previous
thread. I have run across a problem at the very last step. The
relevant screenshot is at http://imgur.com/X2BfziT . Cannot attach the
PNG due to message size restrictions.
Basically, when I try to change the Gateway IP for our 44.24.240.0/20
subnet to be 44.24.221.1, I get the error message "Invalid gateway IP
address".
I'm sure this was intentionally coded at some point, but I believe this
to be a design error. Here's why:
1) 44.24.221.1 is outside the associated prefix list for this gateway
(44.24.240.0/20 only).
2) 44.24.221.0/24 will not be configured to have an IPIP gateway as it
is being announced directly on the Internet.
Given those two conditions, anyone with traffic for 44.24.240.0/20 can
send it via Internet or IPIP to 44.24.221.1. When sending to
44.24.221.1 (outer IPIP header dst-addr), there should be no conflicting
route and the default route should be taken, resulting in proper packet
delivery to HamWAN.
Can someone add this gateway manually and then fix the portal interface
problem?
Our tunnels are re-configured into the new desired state and awaiting
packets. :) We are presently in AMPR tunnel downtime mode until that
gateway is set + propagated.
Thanks!
--Bart
10 Apr
10 Apr
5:52 p.m.
2) 44.24.221.0/24 will not be configured to have an
IPIP gateway as
it is being announced directly on the Internet.
Networks announced via BGP to the Internet without an IPIP gateway
entry won't be reachable from within 44net including the AMPRGW. This
has been explained and discussed several times over here, BGP
announced network must also have an IPIP gateway entry in to be
reachable from Internet AND 44net. This means that you will have to
provide a non-44net IP address as IPIP endpoint.
73 de Marc
10:34 p.m.
On Thu, Apr 10, 2014 at 3:52 AM, <lx1duc(a)laru.lu> wrote:
Networks announced via BGP to the Internet without an
IPIP gateway entry
won't be reachable from within 44net including the AMPRGW. This has been
explained and discussed several times over here, BGP announced network must
also have an IPIP gateway entry in to be reachable from Internet AND 44net.
This means that you will have to provide a non-44net IP address as IPIP
endpoint.
It's not a problem if 44net addresses cannot route to 44.24.221.0/24.
It is *only* used as an anycast IPIP gateway for 44.24.240.0/20. We
expect to see source addresses from the various ISPs around the world,
not 44net. These ISPs should have no problem sending IPIP packets to
44.24.221.0/24, regardless of any funky 44net issues.
Tom KD7LXL
10:45 p.m.
Networks
announced via BGP to the Internet without an IPIP gateway entry
won't be reachable from within 44net including the AMPRGW. This has been
explained and discussed several times over here, BGP announced network must
also have an IPIP gateway entry in to be reachable from Internet AND 44net.
This means that you will have to provide a non-44net IP address as IPIP
endpoint.
It's not a problem if 44net addresses cannot route to 44.24.221.0/24.
It is *only* used as an anycast IPIP gateway for 44.24.240.0/20. We
expect to see source addresses from the various ISPs around the world,
not 44net. These ISPs should have no problem sending IPIP packets to
44.24.221.0/24, regardless of any funky 44net issues.
10:49 p.m.
On Thu, Apr 10, 2014 at 8:45 AM, Marc, LX1DUC <lx1duc(a)laru.lu> wrote:
Forget AMPRGW. I understand there is a routing issue at UCSD that
breaks 44net routing for AMPRGW. But I'm not asking about AMPRGW! I'm
asking about routing from all the IPIP gateways, none of which have
44net endpoints at the moment.
Since none of the current IPIP gateways have 44net endpoints, you
cannot say with certainty that it won't work until the portal lets us
try it.
Tom KD7LXL
It's not a
problem if 44net addresses cannot route to 44.24.221.0/24.
It is *only* used as an anycast IPIP gateway for 44.24.240.0/20. We
expect to see source addresses from the various ISPs around the world,
not 44net. These ISPs should have no problem sending IPIP packets to
44.24.221.0/24, regardless of any funky 44net issues.
I repeat the AMPR GW is unable to route to 44net addresses announced via BGP. The AMPR GW
can only route to non 44net addresses. So you cannot enter a 44net address as endpoint for
IPIP tunnel. 
11:01 p.m.
On Thu, 10 Apr 2014, Tom Hayward wrote:
Since none of the current IPIP gateways have 44net
endpoints, you
cannot say with certainty that it won't work until the portal lets us
try it.
There's a quite good bunch of slightly silly IPIP configurations which
route all 44/8 over a tunnel to the gateway at UCSD, if they can't find a
more specific route for an address. Some people have been recommending
this setup quite lately on this mailing list, too.
I suppose that you could say, with pretty high certainty, that a tunnel
endpoint address within 44/8 won't work for those sites.
- Hessu
11 Apr
11 Apr
12:24 a.m.
In order allow hosts in the IP-IP tunnel system reach/be reachable
to/from the Internet, I believe the default route has to be to
amprgw.sysnet.ucsd.edu.
-Neil
On Thu, Apr 10, 2014 at 11:01 AM, Heikki Hannikainen <hessu(a)hes.iki.fi> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Thu, 10 Apr 2014, Tom Hayward wrote:
--
Neil Johnson
http://erudicon.com
Since none of the current IPIP gateways have
44net endpoints, you
cannot say with certainty that it won't work until the portal lets us
try it.
There's a quite good bunch of slightly silly IPIP configurations which route
all 44/8 over a tunnel to the gateway at UCSD, if they can't find a more
specific route for an address. Some people have been recommending this setup
quite lately on this mailing list, too.
I suppose that you could say, with pretty high certainty, that a tunnel
endpoint address within 44/8 won't work for those sites.
- Hessu
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:49 a.m.
On 10/04/2014 19:24, Neil Johnson wrote:
In order allow hosts in the IP-IP tunnel system
reach/be reachable
to/from the Internet, I believe the default route has to be to
amprgw.sysnet.ucsd.edu.
true but note that default route is not equal to a 44/8 route. If no
route for 44/8 exists the default route will obviously catch traffic for
undefined 44nets, but that still doesn't make both routes equal or one.
73 de Marc
1:07 a.m.
On Thu, 10 Apr 2014, Neil Johnson wrote:
In order allow hosts in the IP-IP tunnel system
reach/be reachable
to/from the Internet, I believe the default route has to be to
amprgw.sysnet.ucsd.edu.
Actually, no, not the default route. If the default route pointed to
amprgw, you could not send encapsulated packets to any other gateway at
all. The default route is applied to the IPIP packet after encapsulation -
it needs to point to your local upstream Internet router.
Some sites will have to route packets which have both (1) source
address within their 44.x.y/z subnet and (2) destination address outside
44/8, to amprgw, since their local upstream Internet provider drops
outgoing packets which have a source address within 44/8.
That's quite different from both the default route, or routing packets
having destination address within 44/8.
- Hessu
1:40 a.m.
On 10/04/2014 20:07, Heikki Hannikainen wrote:
Actually, no, not the default route. If the default
route pointed to
amprgw, you could not send encapsulated packets to any other gateway at
all. The default route is applied to the IPIP packet after encapsulation
- it needs to point to your local upstream Internet router.
Some sites will have to route packets which have both (1) source address
within their 44.x.y/z subnet and (2) destination address outside 44/8,
to amprgw, since their local upstream Internet provider drops outgoing
packets which have a source address within 44/8.
That's quite different from both the default route, or routing packets
having destination address within 44/8.
All depends on how you've setup your network, it could be plain dumb
default route, or it could be a default route within a VRF, or a default
route combined with source based routing... This thread however is not
about if, when and how much that route is a default route.
I think that in this case not the technical term "default route" was
intended but rather the description the default route for that kind of
traffic passing through that gateway...
73 de Marc
2:17 a.m.
Setting the default route for 44.0.0.0/8 to 44.0.0.1 plain and simple
doesn't work and makes no sense.
The gw sends all traffic from 44 tunnels to internet hosts to the internet
via (a real, public) 44.0.0.1 address and enapsulates internet originating
traffic toward a KNOWN ampr subnet via the proper tunnel.
Again 44.0.0.1 is a real, routed IP address and is the gateway for all
44.0.0.0/8 traffic from the internet's point of view.
No traffic is routed between tunnels at the gateway (ir is assumed that
there's a ful mesh in place), and since unknown destinations have no
associated tunnels, they are not routed either.
So the correct approach is to NAT the unknown 44 destinations (meaning not
in the encap file or in RIP broadcasts) to your public IP and send them over
regular internet. This will allow you to reach directly BGP enabled subnets,
with the draw back that your traffic will seam to originate from your public
IP, not your ampr address.
And there's no workaround for this at the moment, unless you have a BGP
announced subnet.
73s de Marius, YO2LOJ
2:36 a.m.
On Thu, Apr 10, 2014 at 12:17 PM, Marius Petrescu <marius(a)yo2loj.ro> wrote:
So the correct approach is to NAT the unknown 44
destinations (meaning not
in the encap file or in RIP broadcasts) to your public IP and send them over
regular internet. This will allow you to reach directly BGP enabled subnets,
with the draw back that your traffic will seam to originate from your public
IP, not your ampr address.
I think you will confuse people with this detail, because this is a
problem that hasn't yet been mentioned in this thread. You are talking
about networks that to not accept IPIP.
This thread is about a network that accepts IPIP, like any other 44net
gateway. The only problem is it's not listed in the encap at the
moment because the portal won't accept the gateway address as valid.
And there's no workaround for this at the moment,
unless you have a BGP
announced subnet.
Well, there is a workaround: Just run the IPIP stuff on the BGP
announced subnet.
Tom KD7LXL
2:23 a.m.
Here is my 44 routing table base on the wiki instructions I created.
Should I be doing something different ?
njohnsn@srv01:~$ ip route list table 44
default via 169.228.66.251 dev ampr0 onlink
44.2.2.0/24 via 157.130.198.190 dev ampr0 proto 44 onlink window 840
44.2.10.0/29 via 71.130.72.52 dev ampr0 proto 44 onlink window 840
44.2.14.0/29 via 50.79.156.221 dev ampr0 proto 44 onlink window 840
44.2.50.0/29 via 68.189.35.197 dev ampr0 proto 44 onlink window 840
44.4.2.152/29 via 173.167.109.217 dev ampr0 proto 44 onlink window 840
44.4.10.40 via 69.12.138.16 dev ampr0 proto 44 onlink window 840
Thanks.
- Neil
On Thu, Apr 10, 2014 at 1:40 PM, Marc, LX1DUC <lx1duc(a)laru.lu> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 10/04/2014 20:07, Heikki Hannikainen wrote:
--
Neil Johnson
http://erudicon.com
Actually, no, not the default route. If the
default route pointed to
amprgw, you could not send encapsulated packets to any other gateway at
all. The default route is applied to the IPIP packet after encapsulation
- it needs to point to your local upstream Internet router.
Some sites will have to route packets which have both (1) source address
within their 44.x.y/z subnet and (2) destination address outside 44/8,
to amprgw, since their local upstream Internet provider drops outgoing
packets which have a source address within 44/8.
That's quite different from both the default route, or routing packets
having destination address within 44/8.
All depends on how you've setup your network, it could be plain dumb
default route, or it could be a default route within a VRF, or a default
route combined with source based routing... This thread however is not
about if, when and how much that route is a default route.
I think that in this case not the technical term "default route" was
intended but rather the description the default route for that kind of
traffic passing through that gateway...
73 de Marc
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
3910
days inactive
3910
days old
12 comments
7 participants
participants (7)
-
Bart Kus -
Heikki Hannikainen -
lx1duc＠laru.lu -
Marc, LX1DUC
-
Marius Petrescu -
Neil Johnson -
Tom Hayward