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.
Erm ...
Link not working Brian. Sorry
Mark
On Thu, Sep 5, 2013 at 8:52 PM, Brian Rogers n1uro@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@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.
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@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@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.
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.
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@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@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.
On Fri, 2013-09-06 at 16:11 -0700, K7VE - John spake:
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?
-
Brian Rogers -
K7VE - John -
Mark Phillips