5 Sep
2013
5 Sep
'13
8:52 p.m.
http://n1uro.ampr.org/cgi-bin/safe-config.cgi will set up a *very* basic
system for amprnet ipencap routing pending you have a tunnel interface
already configured.
Field 1: 169.228.66.251 <- ucsd
Field 2: 44.0.0.1 <- ucsd
Field 3: 44.x.x.x <- your amprnet gw IP
Field 4: eth0/wlan0/wifi0/etc
The rest gives you basic IPTable rules to allow IPEncap and ax25 frames
through your firewall, route rules, and a basic route table. Load your
favorite ripv2-daemon and configure it to populate "table 1" and you'll
be off and running within the first rip broadcast (faster if you run the
munge script - no need to wait for a broadcast).
Mine looks exactly as the cgi prints:
Add this to your rc.local, or whatever init script you wish to make:
# allow IPEncapsulation and ax25 frames to gate through...
iptables -I INPUT 1 -j ACCEPT --proto 4
iptables -I INPUT 1 -j ACCEPT --proto 93
iptables -I OUTPUT 1 -j ACCEPT --proto 4
iptables -I OUTPUT 1 -j ACCEPT --proto 93
iptables -I FORWARD 1 -j ACCEPT --proto 4
iptables -I FORWARD 1 -j ACCEPT --proto 93
# Create a policy to encap forward to your host...
ip rule add from 44/8 pref 1 table 1
ip rule add to 44/8 pref 1 table 1
# Now let's set the routing accordingly...
ip route add 44/8 via 169.228.66.251 dev tunl0 onlink src 44.88.0.9
table 1
ip route add default via 169.228.66.251 dev tunl0 onlink table 1
*Whether or not you're SAFed (source address filtered) this should work
for you.
--
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Massachusetts, New Hampshire,
Pennsylvania, Rhode Island,
and Vermont.
6 Sep
6 Sep
12:16 p.m.
Erm ...
Link not working Brian. Sorry
Mark
On Thu, Sep 5, 2013 at 8:52 PM, Brian Rogers <n1uro(a)n1uro.ampr.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> http://n1uro.ampr.org/cgi-bin/safe-config.cgi will set up a *very* basic
> system for amprnet ipencap routing pending you have a tunnel interface
> already configured.
>
> Field 1: 169.228.66.251 <- ucsd
> Field 2: 44.0.0.1 <- ucsd
> Field 3: 44.x.x.x <- your amprnet gw IP
> Field 4: eth0/wlan0/wifi0/etc
>
> The rest gives you basic IPTable rules to allow IPEncap and ax25 frames
> through your firewall, route rules, and a basic route table. Load your
> favorite ripv2-daemon and configure it to populate "table 1" and
you'll
> be off and running within the first rip broadcast (faster if you run the
> munge script - no need to wait for a broadcast).
>
> Mine looks exactly as the cgi prints:
>
> Add this to your rc.local, or whatever init script you wish to make:
>
> # allow IPEncapsulation and ax25 frames to gate through...
> iptables -I INPUT 1 -j ACCEPT --proto 4
> iptables -I INPUT 1 -j ACCEPT --proto 93
> iptables -I OUTPUT 1 -j ACCEPT --proto 4
> iptables -I OUTPUT 1 -j ACCEPT --proto 93
> iptables -I FORWARD 1 -j ACCEPT --proto 4
> iptables -I FORWARD 1 -j ACCEPT --proto 93
> # Create a policy to encap forward to your host...
> ip rule add from 44/8 pref 1 table 1
> ip rule add to 44/8 pref 1 table 1
> # Now let's set the routing accordingly...
> ip route add 44/8 via 169.228.66.251 dev tunl0 onlink src 44.88.0.9
> table 1
> ip route add default via 169.228.66.251 dev tunl0 onlink table 1
>
> *Whether or not you're SAFed (source address filtered) this should work
> for you.
> --
> 73 de Brian Rogers - N1URO
> email: <n1uro(a)n1uro.ampr.org>
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> AmprNet coordinator for:
> Connecticut, Delaware, Maine,
> Massachusetts, New Hampshire,
> Pennsylvania, Rhode Island,
> and Vermont.
>
12:58 p.m.
This may be a stop gap for low traffic sites, but I think the goal is to
avoid sending everything through 44.0.0.1.
We should be working toward deprecating hacked solutions, like the IPIP
tunnel set. Our model should be
Internet -> Router (BGP) -> subnet (i.e. 44.24.0.0/16) -> VPN/Tunnel/RF
Link -> Local Subnet 44.24.10.0/24 -> LAN (wired or RF) -> Station (
44.24.10.2/32)
Any incoming traffic to the router based on BGP would be routed to the
subnet and filtered at the local Subnet or where the traffic hits Part 97
(or equivalent) RF.
Any outgoing (from individual /32 net) traffic is passed up the chain LAN /
Local Sub-net / Subnet / Internet.
If the src address is 44.x.x.x/32 it should be routed through the BGP
enabled router to the Internet. If the src address is no 44.x.x.x/32 it
goes over the local ISP router.
------------------------------
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 Thu, Sep 5, 2013 at 5:52 PM, Brian Rogers <n1uro(a)n1uro.ampr.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> http://n1uro.ampr.org/cgi-bin/safe-config.cgi will set up a *very* basic
> system for amprnet ipencap routing pending you have a tunnel interface
> already configured.
>
> Field 1: 169.228.66.251 <- ucsd
> Field 2: 44.0.0.1 <- ucsd
> Field 3: 44.x.x.x <- your amprnet gw IP
> Field 4: eth0/wlan0/wifi0/etc
>
> The rest gives you basic IPTable rules to allow IPEncap and ax25 frames
> through your firewall, route rules, and a basic route table. Load your
> favorite ripv2-daemon and configure it to populate "table 1" and
you'll
> be off and running within the first rip broadcast (faster if you run the
> munge script - no need to wait for a broadcast).
>
> Mine looks exactly as the cgi prints:
>
> Add this to your rc.local, or whatever init script you wish to make:
>
> # allow IPEncapsulation and ax25 frames to gate through...
> iptables -I INPUT 1 -j ACCEPT --proto 4
> iptables -I INPUT 1 -j ACCEPT --proto 93
> iptables -I OUTPUT 1 -j ACCEPT --proto 4
> iptables -I OUTPUT 1 -j ACCEPT --proto 93
> iptables -I FORWARD 1 -j ACCEPT --proto 4
> iptables -I FORWARD 1 -j ACCEPT --proto 93
> # Create a policy to encap forward to your host...
> ip rule add from 44/8 pref 1 table 1
> ip rule add to 44/8 pref 1 table 1
> # Now let's set the routing accordingly...
> ip route add 44/8 via 169.228.66.251 dev tunl0 onlink src 44.88.0.9
> table 1
> ip route add default via 169.228.66.251 dev tunl0 onlink table 1
>
> *Whether or not you're SAFed (source address filtered) this should work
> for you.
> --
> 73 de Brian Rogers - N1URO
> email: <n1uro(a)n1uro.ampr.org>
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> AmprNet coordinator for:
> Connecticut, Delaware, Maine,
> Massachusetts, New Hampshire,
> Pennsylvania, Rhode Island,
> and Vermont.
>
6:04 p.m.
Hello John et al;
On Fri, 2013-09-06 at 09:58 -0700, K7VE - John spake:
This may be a stop gap for low traffic sites, but I
think the goal is
to avoid sending everything through 44.0.0.1.
If tunnelled routing via RIP/munge is configured properly, not
everything gets routed via 44.0.0.1. That's the idea behind such a route
schema. Routes between 44-net gateways are then point-to-point bypassing
the need to route traffic between them through 44.0.0.1.
Internet -> Router (BGP) -> subnet (i.e.
44.24.0.0/16) ->
VPN/Tunnel/RF Link -> Local Subnet 44.24.10.0/24 -> LAN (wired or RF)
-> Station (44.24.10.2/32)
In a perfect world perhaps, however we are NOT in a perfect world and
with corporate policies at almost every ISP, I can't see this working.
100% of the ISPs I've worked for refused to allow my personal connect to
be an exception of Source Address Filtering. The corporates don't want
to be held liable for traffic that flows through their network on a
direct tiedown to an edge point to/from a network that's not theirs. I
can more than understand this.
Also, there's the human factor involved here; what happens when the
engineer is layed off/quits/ISP goes dark? Then what happens to that
larger subnet when the human no longer is there to maintain it or the
ISP goes under and the route is removed? Then it fails to work. All
those gateways which were formerly supported via their local BGP table
now have 0 connectivity to 44/8.
Any incoming traffic to the router based on BGP would
be routed to the
subnet and filtered at the local Subnet or where the traffic hits Part
97 (or equivalent) RF.
See above.
Any outgoing (from individual /32 net) traffic is passed up the chain
LAN / Local Sub-net / Subnet / Internet.
Not necessarily true; explained below.
If the src address is 44.x.x.x/32 it should be routed
through the BGP
enabled router to the Internet. If the src address is no 44.x.x.x/32
it goes over the local ISP router.
This may be the case where you are at, but in the northeast U.S. we
route subnets based on RF connectivity first. It's always been our
policy for years. We also use FlexNet, which is like BGP to ax25 - uses
RF - and is very efficient. Because our regions are smaller in
geographic size, from 44.88/16 I would route to 44.44/16, 44.64/16,
44.68/16, etc., all via RF (FlexNet), and I wouldn't even consider using
a wired IP solution such as an ISP's link or ipip tunnel through my ISP.
This too also helps keep <all> traffic from going through 44.0.0.1 while
doing our part to keep 44-net an experimental RF network, not a
glorified ISP.
For more info on this;
http://wetnet.net/pipermail/seatcp/2003-December/003602.html
If engineers at ISPs never retire, are immortal, and their respective
ISPs don't go dark and allow broadcasting pseudo ownership of a
subnet(s) not registered to them while opening holes from their source
address filtering, then I'd be in full favor of your proposed BGP
solution. I'm also not saying the same argument can't be made for when
BK retires from UCSD either... it could very well happen.
--
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Massachusetts, New Hampshire,
Pennsylvania, Rhode Island,
and Vermont.
7:11 p.m.
Brian,
I see a lot more use for 44-Net then routing to 1200 baud AX.25 endpoints.
Puget Sound (area around Seattle) is building a 150 mbit WiFi network for
amateur radio called Hamwan (Hamwan.Org) they will be managing a /22 or
better LAN with direct BGP.
Repeater linking of digital voice (D-STAR, EchoLink, IRLP, AllStar) --
these need minimized jitter (easier on minimized hops and encapsulation).
How about MPEG encoded amateur digital TV? Or file servers / Websites that
can deliver content for Amateur Radio.
Cross linking HSMM-Mesh via net-44?
Real time monitoring and control systems... and so on.
I think we need to think of all of the various IP based amateur radio
related services that can be delivered and encapsulation besides AX.25,
like D-STAR Digital Data, and one that mimics Ethernet on RF Lans.
I have been coordinator for Utah (now for Western Washington), there are 3
main population centers with significant miles in between and large (1000s
of square miles) areas to be covered. RF linking isn't always possible.
Also, I want it to be trivial for a new station/LAN to configure and join.
Using my model, end routers have two entries to support net-44.
LAN 44.24.10.x/24
Wide area 44.x.x.x/8
We could have pretty simple Linux or Router (like Mikrotik) setup scripts.
The BGP requirements for Net-44 require a formal agreement with an
ISP/Datacenter not just some engineer slipping the BGP in on the side.
If successful in building the net, we could end up with 10s of thousands of
entries in the munge text files.
I just think we can do better using modern methods.
I have an experimental dns running which can return services using SRV
records (right now digital voice linking).
host -t SRV _dextra._udp.arlink.net
host -t SRV _dplus._udp.arlink.net
host -t SRV _dcs._udp.arlink.net
I think the BGP router would largely reach out to LANs via easy to
establish and secure VPN protocols.
------------------------------
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, Sep 6, 2013 at 3:04 PM, Brian Rogers <n1uro(a)n1uro.ampr.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Hello John et al;
>
> On Fri, 2013-09-06 at 09:58 -0700, K7VE - John spake:
> > This may be a stop gap for low traffic sites, but I think the goal is
> > to avoid sending everything through 44.0.0.1.
> >
> If tunnelled routing via RIP/munge is configured properly, not
> everything gets routed via 44.0.0.1. That's the idea behind such a route
> schema. Routes between 44-net gateways are then point-to-point bypassing
> the need to route traffic between them through 44.0.0.1.
>
> > Internet -> Router (BGP) -> subnet (i.e. 44.24.0.0/16) ->
> > VPN/Tunnel/RF Link -> Local Subnet 44.24.10.0/24 -> LAN (wired or RF)
> > -> Station (44.24.10.2/32)
> >
> In a perfect world perhaps, however we are NOT in a perfect world and
> with corporate policies at almost every ISP, I can't see this working.
> 100% of the ISPs I've worked for refused to allow my personal connect to
> be an exception of Source Address Filtering. The corporates don't want
> to be held liable for traffic that flows through their network on a
> direct tiedown to an edge point to/from a network that's not theirs. I
> can more than understand this.
>
> Also, there's the human factor involved here; what happens when the
> engineer is layed off/quits/ISP goes dark? Then what happens to that
> larger subnet when the human no longer is there to maintain it or the
> ISP goes under and the route is removed? Then it fails to work. All
> those gateways which were formerly supported via their local BGP table
> now have 0 connectivity to 44/8.
>
> > Any incoming traffic to the router based on BGP would be routed to the
> > subnet and filtered at the local Subnet or where the traffic hits Part
> > 97 (or equivalent) RF.
> >
> See above.
> >
> > Any outgoing (from individual /32 net) traffic is passed up the chain
> > LAN / Local Sub-net / Subnet / Internet.
> >
> Not necessarily true; explained below.
>
> > If the src address is 44.x.x.x/32 it should be routed through the BGP
> > enabled router to the Internet. If the src address is no 44.x.x.x/32
> > it goes over the local ISP router.
> >
> This may be the case where you are at, but in the northeast U.S. we
> route subnets based on RF connectivity first. It's always been our
> policy for years. We also use FlexNet, which is like BGP to ax25 - uses
> RF - and is very efficient. Because our regions are smaller in
> geographic size, from 44.88/16 I would route to 44.44/16, 44.64/16,
> 44.68/16, etc., all via RF (FlexNet), and I wouldn't even consider using
> a wired IP solution such as an ISP's link or ipip tunnel through my ISP.
> This too also helps keep <all> traffic from going through 44.0.0.1 while
> doing our part to keep 44-net an experimental RF network, not a
> glorified ISP.
>
> For more info on this;
> http://wetnet.net/pipermail/seatcp/2003-December/003602.html
>
>
> If engineers at ISPs never retire, are immortal, and their respective
> ISPs don't go dark and allow broadcasting pseudo ownership of a
> subnet(s) not registered to them while opening holes from their source
> address filtering, then I'd be in full favor of your proposed BGP
> solution. I'm also not saying the same argument can't be made for when
> BK retires from UCSD either... it could very well happen.
>
> --
> 73 de Brian Rogers - N1URO
> email: <n1uro(a)n1uro.ampr.org>
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> AmprNet coordinator for:
> Connecticut, Delaware, Maine,
> Massachusetts, New Hampshire,
> Pennsylvania, Rhode Island,
> and Vermont.
>
8:11 p.m.
On Fri, 2013-09-06 at 16:11 -0700, K7VE - John spake:
--
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Massachusetts, New Hampshire,
Pennsylvania, Rhode Island,
and Vermont.
I see a lot more use for 44-Net then routing to 1200 baud AX.25
endpoints.
I agree, and I also wasn't using 1200 baud either. AX.25, like with IP
is a protocol... and like water, protocols will travel at any path you
wish to provide them. If not we wouldn't have AXIP.
Puget Sound (area around Seattle) is building a 150 mbit WiFi network
for amateur radio called Hamwan (Hamwan.Org) they will be managing
a /22 or better LAN with direct BGP.
While that may work for your region, it isn't practical here. Too many
hilltops blocking line-of-sight.
Repeater linking of digital voice (D-STAR, EchoLink, IRLP, AllStar) --
these need minimized jitter (easier on minimized hops and
encapsulation).
correct.
How about MPEG encoded amateur digital TV? Or file servers / Websites
that can deliver content for Amateur Radio.
That's all well and good.
Cross linking HSMM-Mesh via net-44?
Real time monitoring and control systems... and so on.
This I do with the FlexNet network as well.
I think we need to think of all of the various IP
based amateur radio
related services that can be delivered and encapsulation besides
AX.25, like D-STAR Digital Data, and one that mimics Ethernet on RF
Lans.
... AND needs to be -cost effective- for the average ham. This too has
been a battle for years; convincing the average joe-ham to invest a few
hundred dollars for packet.
I have been coordinator for Utah (now for Western Washington), there
are 3 main population centers with significant miles in between and
large (1000s of square miles) areas to be covered. RF linking isn't
always possible.
That's why someone in one geographical location can't speak for those in
other geographical locations, so a generic solution isn't always
possible.
Also, I want it to be trivial for a new station/LAN to
configure and
join. Using my model, end routers have two entries to support net-44.
We could have pretty simple Linux or Router (like Mikrotik) setup
scripts.
Again, what may be practical in your region isn't necessarily the proper
solution for another.
The BGP requirements for Net-44 require a formal agreement with an
ISP/Datacenter not just some engineer slipping the BGP in on the side.
Again, this requires the "human element", and convincing a data center
owner/operator that you wish to broadcast a network via BGP tied down
directly to them that they don't own. The key words here are: legal
liability.
If successful in building the net, we could end up with 10s of
thousands of entries in the munge text files.
Actually no. Perhaps in the dns files but not a munge text. In a large
high-speed "hamwan", just the gateway entry point needs to be in the
encap.txt - reference your earlier design draft. Ex: if I needed to
route to your /22, then there should be *1* point of entry in your area
I should need to pass my encapsulated traffic to. I see no need for such
a high speed wan to require individual encap.txt entries.
I just think we can do better using modern methods.
I totally agree with you on this one.
I think the BGP router would largely reach out to LANs
via easy to
establish and secure VPN protocols.
In a perfect world - yes. This is not a perfect world. Even datacenters
go bankrupt; ex: us datacenters in boston. Large datacenter, went dark
overnight. Then what's the solution when BGP for that region no longer
exists?
4093
days inactive
4094
days old
5 comments
3 participants
participants (3)
-
Brian Rogers -
K7VE - John -
Mark Phillips