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
- 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
On Thu, Apr 10, 2014 at 3:52 AM, lx1duc@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
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.
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.
BTW, it is *NOT* "a good thing" to route 44net addresses via BGP but not via IPIP mesh.
The ONLY solution for this is to use a non 44net address as the anycast destination for the IPIP tunnel for network 44.24.240.0/20.
73 de Marc
On Thu, Apr 10, 2014 at 8:45 AM, Marc, LX1DUC lx1duc@laru.lu wrote:
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.
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
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
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@hes.iki.fi wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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
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
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
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
On Thu, Apr 10, 2014 at 12:17 PM, Marius Petrescu marius@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
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@laru.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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 _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
Bart Kus -
Heikki Hannikainen -
lx1duc＠laru.lu -
Marc, LX1DUC
-
Marius Petrescu -
Neil Johnson -
Tom Hayward