On 4/11/14, 12:26 PM, lleachii(a)aol.com wrote:
> TOS section 7c requires him to provide an AMPRNet connection for AMPR
> devices local to him; but not necessarily via rip44. Since its not valid at
> this time to tunnel to a 44subnet via a 44 address, I don't see how he's in
> compliance (save via RF, which is their local AMPRNet anyway).
Where would hamradio be with out armchair lawyers? I love this hobby.
If he's using 44net space and announcing it to the internet via BGP he is
providing access to the users behind his BGP router that have AMPRnet
addresses. Sure they may not have access to the rest of AMPRnet via the IPIP
routes, but that's optional. I'd even venture to guess most hams on his
system won't care/know that it's missing the IPIP tunnels.
People using AMPRnet space in BGP are most likely concerned with providing
access to the internet via ham radio, not accessing slow 9600 baud links from
the internet.
> Bart also mentioned:
>
>>>>> It allows our microwave network to remain connected to the rest of
>>>>> AMPRnet as long as we have at least 1 ISP that isn't dead.
> **The problem would also solved if he announces 209.189.196.68/32 on both
> ISP connections.**
A /32 is going to be route filtered, and it's not his IP space, it's a /30 or
/31 from his upstream BGP peer. So no, this is not possible.
The entire *IDEA* of BGP is to allow you to control your own redundancy and
peering to the routing table.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Alright how many people are still running some sort of NOS on DOS?
Time to move forward folks and use the excellent routing capabilities of Linux.
Every time I look at the encap.txt and see stuff like:
route addprivate 44.129/16 encap 118.22.1.194
I ask myself why do we still export is this way. I say export it as:
ip route add 44.129.0.0/16 via 118.22.1.194 dev tunl0 onlink
And let those who still need it the old way learn the pain of
conversion. Give them a reason to upgrade/ move forward.
</Off my soap box>
---- Quote---
Bart,
Don brought up some good points. In addition:
- non Linux-kernel routers (e.g. JNOS and TNOS) would not be able to
route to you as they would need to be reprogrammed and recompiled (FYI,
JNOS and TNOS is the most commonly used AMPR Network OS)
https://www.nanog.org/meetings/nanog61/home
I'll be here, and Tim Osbourn W7RSZ as well. Is there anyone else going?
I'd enjoy having a dinner or lunch breakout to meet with some of the AMPRnet
users at NANOG.
Post if you're going and we'll arrange something if we have some interest.
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 4/11/14, 11:37 AM, lleachii(a)aol.com wrote:
> It's much easier, and doesn't require a total reconfiguration of AMPR to
> simply have Bart run a 44GW speaking rip 44 using his Public IP address as
> the GWip - be advised that he is required to do so under the Terms of
> Service:
That's a heck of a jump in logic.
I see nothing in there requiring anyone to run rip44d. All it means is you
need have the ability of supplying connectivity to other hams in your area out
of your subnet. I'm doing this via GRE and VPN dialers.
I have little interest in connecting to the rest of AMPRnet hosts who are not
rotatable in the global table. My interest is supplying access over RF using
the AMPR space and setting up routed redundant multi-megabit links.
What AMPRnet has running now is akin to the GRX network IMO. It's private
with one interconnection to the internet.
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 4/11/14, 11:32 AM, Bart Kus wrote:
> It allows our microwave network to remain connected to the rest of
> AMPRnet as long as we have at least 1 ISP that isn't dead. The
> microwave network peers with the Internet at 2 different points at
> present, but more points will come in the future. It's a robustness
> improvement in the face of partial failures, like in a natural disaster
> when an ISP's fiber gets torn or their building collapses.
So this is a hack to correct for the hack of AMPRnet IPIP tunnels. Argh, it
makes my head hurt.
If AMPRnet was treated like any other network on the internet, this problem
would go away. At worst anyone not redundantly connected to the global
internet would lose connectivity if their small gateway went down.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
As far as I know, because of routing restrictions on the amprgw network
connectivity, hosts on BGP-announced subnets of 44/8 will be unable
to communicate with hosts on tunnel-routed subnets of 44/8 unless the
BGP-announced subnet also runs a listed tunnel router gateway with a
non-44/8 gateway address.
This is because the building-level router one hop upstream from amprgw has
a fixed route directing all 44/8 traffic to amprgw. This building-level
router does not speak BGP and so cannot learn about BGP-announced subnets
of 44/8. This is a historical artifact; it predates the availability
of BGP-announced 44/8 subnets by many years.
We hope to change this topology in the future to connectivity with the
border router that DOES speak BGP, but indications are that that change
will not be able to be done soon.
In the meantime, gateway tunnel routers with a non-44 gateway address
(that's all of them, except HamWan's proposed gateway) are the workaround
to this restriction.
I'm sorry for this difficulty but it's what we're stuck with for now.
- Brian
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
I'm trying to decide how to write a "How To" guide for setting up a
Linux Gateway for the Wiki.
I'm planning on basing it on the excellent guide found here (with Credit):
http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/
But I'm wondering what level of Linux Administration and IP Networking
Expertise I should assume.
If I assume zero, it's going to be a looong guide, probably too long.
Below is a link to the diagram I was planning to base the guide off of.
AMPRNet Gateway Diagram -
https://docs.google.com/drawings/d/1xAcMbROBpbuRFY0tVf1VdBrAP0ZQwTsE6Eqokn2…
Comments welcome.
Thanks
-Neil
All,
I finished by volunteer stint at a youth robotics competition, so I
have been poking around the Wiki making some changes. Mainly I have
been adding some small pieces of content to eliminate the Wiki links
that go to empty pages, but I have also rearranged some of the content
on the main page.
If you run across any issues, please let me know.
I hope that is okay with everyone.
-Neil
--
Neil Johnson, N0SFH
http://erudicon.com