> Subject:
> Re: [44net] AMPRNet Interoperability with BGP
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 06/17/2015 08:01 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote:
>> >Good question! No, a change to the portal around the same time
>> >prohibits adding 44.xx.xx.xx addresses as gateways. I believe there
>> >was some noise on this list about it at the time.
> That change was made because
> 1) it was reported that 44.x gateway addresses didn't work
> 2) it was reported that 44.x gateway addresses caused problems
> 3) people were entering 44.x gateway addresses for their IPIP tunnels
> instead of the proper commercial IP address of the endpoint.
The reason (1 and 2) is that for a typical system that has both a public IP and an AMPRnet
IP and is to function on the IPIP mesh, you need policy routing when you want the AMPRnet
IP to be reachable from public IP addresses on internet.
Normal internet traffic is to go out using the public IP, possibly using NAT, and AMPRnet
traffic is to go out via the IPIP tunnels.
When such a system is on a source-address filtered internet connection, the default route
for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh system
that has unfiltered internet access. Typically the system at UCSD.
It is preferred that the varying gateway systems are configured only via RIP (usually in a
separate route table), and that it is not required to make specific policy routing configuration for
gateways. So the policy routing is static for 44.0.0.0/8.
This conflicts with the 44.x gateway addresses, because the traffic got incorrectly routed by
the routing policy (which is used both for the actual traffic and the encapsulated packets).
When people see a way around that (I don't completely oversee if Jann's suggestion will
achieve that), it would be no problem when tunnel endpoints exist within 44.x. Please see
the example configuration for Linux systems in the wiki and suggest a way how that could
be made working without manual "ip rule" entries dedicated to specific gateways. Or else,
those "ip rule" entries maybe could be managed by ampr-ripd, that would be fine as well.
Aside from that, of course it should still be validated that tunnel endpoints are not within
the subnet being tunneled (3). That is simply an error condition. There were some networks
that were claimed to be reachable via a tunnel at their first address (Sweden, for example)
and there were some entries with tunnel endpoint == tunneled address. The portal should
refuse that so that applicants are made aware of their error before such entries are broadcast
via RIP and result in encapsulation loops.
Rob
So to solve the issue of Existing AMPRnet tunnel users not being able to
reach BGP announced 44-net IP Space I've drawing the below drawing that shows
how this can be done without having Brian Kantor ask UCSD to make any
network/routing changes. This only requires at least 1 (or more) ISP (or
companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server
to make this work. There are currently two ISP I know of willing to do this if
Brian is willing to do this on the AMPRnet Server shown in the drawing. This
only requires setting up BGP with a route-map for changing the next hop IP's and
running GRE tunnels on his server. The bonus is he can set this up with multiple
ISP so that there is redundancy. Since the ISP is only sending BGP routes of the
44 IP Space of size /16-/24, this will not consume very much routing table space
on his box (currently 53 prefixes). I also have to imagine the bandwidth going
over this GRE tunnels not going to be a huge amount.
So to summarize how this work. AMPRnet tunnel users can send traffic to
a BGP announced 44 ip space which would travel over their IPIP tunnels (perhaps
a low pref 44.0.0.0/8 route to UCSD in rip? or inject the BGP routes into RIP)
back to UCSD and then over the GRE tunnel to a ISP and then ride the internet to
get to that BGP announced block. Return traffic would just follow the existing
internet routing table and come back via the UCSD network.
AMPRNet Interoperability with BGP Drawing:
https://www.osburn.com/amprnet-150614-1.0.0-bgptunnels.jpg
Tim Osburn
www.osburn.com
W7RSZ
Greetings Peter (et al),
> Sorry for being a bit off topic, could someone please help me with a
> current JNOS 2.0j.7 autoexec.nos file, I only have old 1.11 configs on
> floppies somewhere but will need to find a working floppy drive first,
> Hi.
>
> Thanks ....... Peter ZL2BAU
Here is the 'autoexec.nos' I run here on Hamgate.Washtenaw.AMPR.org.
At the bottom, I have included the 'access.rc' TCP and IP access firewall
rules.
This 'autoexec.nos' is used on a DOS machine. It will require a few
tweeks to have it run on a Linux box.
Enjoy!
--- Jay WB8TKL
# autoexec.nos
#
# 040821 tkl - first cut
# 040822 tkl - Adding ETH0
# 040825 tkl - Added AX1
# tkl - Configured to work with NOS110 version as well as 111
# 041206 tkl - Also works with JNOS2.0a (for DOS)
# 051104 tkl - Including a better access.rc firewall
# 060305 tkl - Configured as new YPSI Hamgate (access3.rc local.rte)
# 080604 tkl - HG.LIV now CONV links to us (rather than us to him)
# Also changed 'smtp timer 900' (was 300)
# 'smtp maxclients 4' (was default of 10)
# And changed 145.76 interface to 144.93
# 080911 tkl - Changed TCP SYNDATA to off (cheap routes won't pass SYNDATA)
# Moved ann SMTP and BBS Mail settings into /nos/etc/mail.cfg
# 090320 tkl - Removed conv link to Monroe (they link to us now)
# 100309 tkl - Added link to MICONV
# 100315 tkl - Using experimental nos2a-nr.exe
# Modified autoexec.nos to support NetROM (MIYPSI WB8TKL-7)
# 120418 tkl - Changed eth0 from 216.144.208.44 to 216.86.85.144
# = Chamged nameserver from 216.144.208.67 to 216.86.85.167
#
#
########################################
### Memory and System Configs ###
########################################
isat yes
watchdog yes
mem minalloc 32
mem ibufsize 2048
mem nibufs 7
mem debug on
echo "***** Memory configured *****"
pause 2
########################################
### Station Indentity ###
########################################
ax25 mycall wb8tkl-4
ax25 ttycall wb8tkl-5
ax25 bbscall wb8tkl-3
ax25 alias YPSI
hostname HamGate.Washtenaw.AMPR.org
ip address 44.102.1.1
ax25 bctext "WB8TKL-3 (YPSI) Washtenaw County AX25 & TCP/IP HamGate [www.MI-DRG.org]"
#
########################################
### Global AX.25 Parameters ###
########################################
ax25 version 2
ax25 maxframe 1
ax25 retries 10
ax25 pacl 200
ax25 window 1024
ax25 irtt 4000
ax25 timer linear
ax25 t3 0
ax25 t4 1200
ax25 maxwait 9000
#
########################################
### Global TCP/IP Parameters ###
########################################
tcp timertype linear
tcp maxwait 9000
tcp retries 32
tcp window 864
tcp blimit 20
tcp irtt 4000
tcp mss 512
tcp syndata off
#
ip ttl 225
ip rt 4
#
########################################
### Port Attaches ###
########################################
attach packet 60 eth0 11 1500
attach asy 0x3f8 4 ax25 144.93 576 256 9600 f1
##attach asy 0x2f8 3 ax25 223.40 576 256 4800 f1
#
attach netrom
#
echo "***** Attaches completed *****"
pause 2
#
########################################
### Configure the Interfaces ###
########################################
#
# ETHERNET
ifconfig eth0 ipaddress 216.86.85.144
ifconfig eth0 netmask 255.255.255.0
ifconfig eth0 broadcast 216.86.85.255
ifconfig eth0 descript "Ethernet to the Internet"
#
ifconfig eth0 tcp win 1024
ifconfig eth0 tcp irtt 50
ifconfig eth0 tcp maxw 150
ifconfig eth0 tcp mss 512
echo "***** Ethernet configured *****"
pause 2
#
# ENCAP
ifconfig encap ipaddress 44.102.1.1
ifconfig encap netmask 255.255.255.255
ifconfig encap broadcast 255.255.255.255
ifconfig encap description "IPIP Encapsulation interface"
echo "***** ENCAP configured *****"
pause 2
#
# COM1 [144.93]
ifconfig 144.93 descript "144.93 MHz AX.25/IP Local Access port"
ifconfig 144.93 netmask 0xffffff00
param 144.93 up #130 (129 = down)
param 144.93 1 100 #1 Transmit delay
param 144.93 2 128 #2 Persistance
param 144.93 3 10 #3 Slot time
param 144.93 4 10 #4
param 144.93 5 0 #5 0=half 1=full duplex
param 144.93 8 1 #8 dtr
param 144.93 9 1 #9 rts
#
# COM2 [223.40]
##ifconfig 223.40 descript "223.40 MHz 1200 baud District-2south Backbone Network"
##ifconfig 223.40 netmask 0xffffff00
##param 223.40 up
##param 223.40 1 30
##param 223.40 2 128
##param 223.40 3 10
##param 223.40 4 10
##param 223.40 5 0
##param 223.40 8 1
##param 223.40 9 1
#
# COM3 [phone]
##attach asy 0x3e8 5 slip phone 2048 576 19200 v
##param phone up
#
echo "***** IFconfig & Param completed *****"
pause 2
#
###################
### NetROM ##
###################
start netrom
pause 2
#
netrom alias MIYPSI
netrom call wb8tkl-7
#
mode netrom vc
netrom minquality 10
#
netrom interface 144.93 192
netrom bcnodes 144.93
netrom bcpoll 144.93
pause 2
#
netrom acktime 3000
netrom choketime 180000
#
netrom derate on
netrom hidden off
netrom promiscuous off
#
netrom retries 10
##netrom tdisc 0
netrom ttl 10
netrom window 4
#
netrom timertype linear
netrom irtt 15000
netrom nodetimer 1800
netrom obsotimer 2100
netrom qlimit 2048
#
###netrom verbose on
##netrom kick
#
echo "***** NetROM configured *****"
#
########################################
### Services ###
########################################
start ax25
start telnet
start smtp
start ttylink
start convers
start ftp
start forward
start finger
start pop3
start remote
##start http 80
##start http 8080
echo "***** Services Started *****"
pause 2
#
########################################
### Digipeating, JHeard, Beacons ##
########################################
ax25 bcinterval 1900
ax25 hsize 30
#
ax25 bcport 144.93 on
ax25 digi 144.93 on
ax25 hport 144.93 on
#
##ax25 bcport 223.40 on
##ax25 digi 223.40 on
##ax25 hport 223.40 on
#
ip hsize 30
ip hport 144.93 on
##ip hport 223.40 on
##pause 2
#
###########################
### ARP Settings ###
###########################
##arp eaves eth0 on
arp eaves 144.93 on
##arp eaves 223.40 on
#
arp poll eth0 on
arp poll 144.93 on
##arp poll 223.40 on
arp maxq 10
#
##arp publish 44.102.1.72 ax25 ka8pog-4 145.76
##arp publish 44.102.1.42 ax25 ka8pog-4 145.76
#
#########################################
### Domain Name Service (DNS) ###
#########################################
domain dns on
domain suffix ampr.org.
domain add 216.86.85.167
domain ret 2
domain maxw 60
domain translate off
#
domain verbose yes
domain cache clean off
domain cache wait 330
domain cache size 15
# cache for 5.7 days
domain ttl 500000
#
echo "***** Resolver configured *****"
pause 2
########################################
### CONVerse Bridge ###
########################################
conv hostname WASHTENAW
conv channel 81
conv mycall wb8tkl-6
conv interface 144.93 on
#
##conv filter mode accept
##conv filter 44.102.24.1
##conv filter 44.102.56.1
#
###conv link 44.102.24.1 3600 LIVINGSTON
###conv link 44.102.238.1 3600 ALCONA
###conv link 44.102.56.1 3600 MONROE
conv link 44.102.135.1 3600 MICONV
#
conv maxwait 600
#
########################################
### SMTP & BBS Mail ###
########################################
source /nos/etc/mail.cfg
echo "***** /nos/etc/mail.cfg sourced *****"
pause 2
#
########################################
### Routing Tables ###
########################################
source /nos/encap.txt
echo "***** /nos/encap.txt sourced *****"
#
source /nos/etc/local.rte
echo "***** /nos/etc/local.rte sourced *****"
#
# Gateway through a neighboring station
##route add 44.102.1.220 145.76 44.102.48.88
##route add 44.102.1.50 145.76 44.102.1.32
#
# AX25 ROUTES
##ax25 route perm wa8efk 145.76 wpxd
##ax25 route perm n8kuf 145.76 wpxd
#
pause 2
########################################
### Firewall Rules ###
########################################
source /nos/access3.rc
echo "***** /nos/access3.rc sourced *****"
##echo "#### no access.rc ###"
pause 2
#
########################################
### Passwords ###
########################################
mbox password "12345"
remote -s PURPLE
#
########################################
### Miscellanious ###
########################################
source /nos/scripts/fkeys.scr
echo "***** /nos/scripts/fkeys.scr sourced *****"
##pause 5
#
trace 144.93 111
trace netrom 0211
strace on
#
history 15
watchdog on
log on
#
# ---end---
#
# Gateways-Access-FAQ
#
# /nos/access3.rc
#
# 20080604 tkl - Change interface to 144.93
#
#
# Start of ACCESS.RC file
# ***********************
# NB: The IP ACCESS and TCP ACCESS frame work is based on IP ACCESS and TCP
# ACCESS control files shown below written by VE3RKS at VE3UOW and by
# VE3PNX at VE3RPI.
#
# - This file should be sourced into your autoexec.nos file after all ports
# have been attached and defined.
# - This file also contains a handy summary of what TCP/UDP ports are
# commonly used.
# - This file contains information on the use of TCP ACCESS and IP ACCESS
# - All lines begin with # symbols. This is to allow this file to be
# sourced into your autoexec.nos after being edited for you specific setup.
# Lines that do not begin with # symbols are valid NOS IP and TCP ACCESS
# commands.
#
# Ports of interest for both UDP and TCP
# **************************************
# 1 - 3599 - SERVER PORTS limit access based on local rules UDP and TCP
#
#***************************************************************************
# 7 - ECHO
# 9 - DISCARD
# 20 - FTP-DATA
# 21 - FTP-CONTROL
# 23 - TELNET
# 25 - SMTP
# 57 - SECONDARY TELNET
# 67 - BOOTP
# 79 - FINGER
# 87 - TTYLINK [Operator chat]
# 97 - AXIP/IPIP/IPTUNNEL
# 109 - POP2
# 110 - POP3
# 119 - NNTP
# 513 - RLOGIN/RWHO
# 525 - TIME DAEMON
# 1234 - REMOTE
# 1235 - CALLSIGN DB
# 3600 - CONVERS [Only AMPR.ORG domain should have access]
# 3601 - LZW CONVERS [Only AMPR.ORG domain should have access]
#
#***************************************************************************
# 1050 - 32768 - REPLY PORTS should be accessable to all <= very important
#
#***************************************************************************
#
# TCP ACCESS
# **********
# TCP ACCESS is used to limit access to certain servers accessable by
# TCP/TELNET to specific ports. For example you may want to allow
# access to the SMTP server in your machine from all machines AMATEUR
# and NON-AMATEUR.
#
# TCP access stops a connection to a server from being built at only
# the machine at which it is installed. If you want to stop a gateway
# from routing TCP/IP packets from specific addresses to specific
# addresses you need to use the IP ACCESS code!
#
# TCP ACCESS WHAT FROM LOW HIGH
# ### ###### ###### ############### ##### #####
#
# Permit all AMPR.ORG and LOCAL domains to ports 1 - 3601
tcp access permit 44/8 1 3601
tcp access permit 127.0.0.1 1 3601
#
# Do NOT allow inbound SMTP connectins from the Internet
tcp access deny all 25 25
#
# Permit all to ports 1 - 3599
tcp access permit all 1 3599
#
# Permit all access to ports 3602 - 32768
tcp access permit all 3602 32768
#
# Deny all access to CONVERS ports 3600 and 3601
tcp access deny all 3600 3601
#
#
# NOTES: The preceding TCP ACCESS code is read in order. TOP down!
# Order is important. In reading from top down the first rule that
# satisfies the origination address and port requirments is the one
# used. So you should place excludes before includes for specific
# originating addresses then followed by global [all] includes or
# excludes.
#
# Example:
# tcp access permit all 1 32768
# tcp access deny 167.23.43.1 3600 3601 <= should be first line
#
# This would not deny 167.23.43.1 access to convers server as the first
# rule would satisfy the test to allow, but reversing the order would!
#
#
# IP ACCESS
# *********
# IP ACCESS is an important bit of code for a INTERNET/AMPRnet Gateway
# as it can be used to selectively allow or disallow the routing of
# TCP/IP packets based on source ip address, destination ip address,
# packet type [udp/tcp/..], UDP or TCP port number and interface port.
#
# For most gateways you would like to only pass AMPR.ORG originated
# ip address to other AMPR.ORG ip address (like UK and AUSTRALIAN LAW).
# Exceptions might be where local law allows Amateurs to originate to
# anywhere (including non-amateur destinations) as the replys are
# technically under the control of the originator (like USA and CANADIAN
# law).
#
# The idea behind IP ACCESS is to set up rules that will allow or deny
# routing of packets. Unlike the TCP ACCESS command, IP ACCESS does not
# restrict access to servers at the machine that is running this code. It
# does however restrict the gatewaying of IP packets accross interface
# ports.
#
# Valid PROTOCOLS are ICMP, UDP, TCP, and ANY (every thing else). Both
# ICMP and ANY do not allow specific port restrictions as port numbers
# are not really used for the other TCP/IP protocols.
#
# WHAT = <permit | deny | delete>
# PROT = <tcp | icmp | udp | any>
# PORT = ATTACHED INTERFACE/PORT
# LOW = TCP or UDP low port number
# HIGH = TCP or UDP high port number
#
# Below I use the following pseudo PORT names:
# AX0 = ax25 rf port
# AX1 = ax25 rf port
# AX3 = AXIP psuedo ax25 port
# BBS = SLIP port to an attached bbs
# MODEM = SLIP port to a telphone modem
# ETH0 = PACKET interface to ethernet card
# ENCAP = ENCAP routing interface
#
#
# IP ACCESS WHAT PROT SOURCE DESTINATION PORT low high
# ## ###### ###### #### ############# ############### ##### ###### ######
ip access permit icmp 44/8 all 144.93 1 32768
### ip access permit icmp 44/8 all 147.58 1 32768
# ip access permit icmp all all ax3 1 32768
# ip access permit icmp all all bbs 1 32768
ip access permit icmp all all eth0 1 32768
ip access permit icmp all all encap 1 32768
# ip access permit icmp all all modem 1 32768
#
ip access permit udp 44/8 all 144.93 1 32768
### ip access permit udp 44/8 all 147.58 1 32768
#
# ip access permit udp all 44.bbb.ccc.ddd ax2 1 32768
# The above line allow a machine 44.bbb.ccc.ddd to receive UDP datagrams
# from any source over a channel that would normally only allow 44/8 sources
#
# ip access permit udp all all ax3 1 32768
# ip access permit udp all all bbs 1 32768
ip access permit udp all all eth0 1 32768
ip access permit udp all all encap 1 32768
# ip access permit udp all all modem 1 32768
#
# TCP will allow TCP client-server packets to be passed
#
ip access permit tcp 44/8 all 144.93 1 32768
ip access permit tcp all 44/8 144.93 1000 3599
ip access permit tcp all 44/8 144.93 3602 32768
### ip access permit tcp 44/8 all 147.58 1 32768
#
# ip access permit tcp all 44.bbb.ccc.ddd ax1 25 25
# The above line allow a machine 44.bbb.ccc.ddd to receive incoming SMTP
# from any source over a channel that would normally only allow 44/8 sources
#
# ip access permit tcp all all ax3 1 32768
# ip access permit tcp all all bbs 1 32768
ip access permit tcp all all eth0 1 32768
ip access permit tcp all all encap 1 32768
# ip access permit tcp all all modem 1 32768
#
# ANY will allow AXIP, IPIP etc!
#
# ip access permit any 44/8 44.bbb.ccc.ddd ax1 1 32768
# The above line allow a machine 44.bbb.ccc.ddd to receive incoming axip
# from 44/8 sources over a channel that would normally not allow axip
#
# ip access permit any all all ax3 1 32768
# ip access permit any all all bbs 1 32768
ip access permit any all all eth0 1 32768
ip access permit any all all encap 1 32768
# ip access permit any all all modem 1 32768
#
# IP ACCESS WHAT PROT SOURCE DESTINATION PORT low high
#
# Allow FINGER (port 79) from monitor.nuge.com to any
ip access permit any 216.86.85.228 all 144.93 79
#
# Block anything from AMPRGW/Mirrorshades (such as RIP2 updates)
ip access deny any 169.228.66.251 all eth0 1 32768
#
# The default rule is to deny all that are not allowed above.
#
#
# ---end of file access.rc---
#
Hi All,
Sorry for being a bit off topic, could someone please help me
with a current JNOS 2.0j.7 autoexec.nos
file, I only have old 1.11 configs on floppies somewhere but will need
to find a working floppy drive first, Hi.
Thanks ....... Peter ZL2BAU
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Don Fanning <don(a)00100100.net>
> Date:
> 06/15/2015 12:35 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
>> >When you want to do something about a SPOF it is only required to do the
>> >RIP transmission
>> >from another system in parallel. E.g. from the system running the portal.
>> >
>> >
> RIP still doesn't solve routing loops that occur. RIP doesn't converge
> quickly (currently 44ripd takes 5+ minutes to send any new*static* change
> - if your firewall is configured to receive said packets from said
> source).
I fail to see why that is a problem. Few gateway stations appear a day, and having to wait
5 minutes before they are routed is really no big deal. Before, many gateway stations loaded
a routing table maybe once a day, or even less frequently.
Again, we are a radio hobbyist network, not some financial trade network.
> RIP has no concept of bandwidth limitations or multiple paths for
> the same route (ie: load balanced connections with different ISP).
Again, let's first set up something that is popular and has many users, and then we can always
consider doing things like that. For now we, and many others, find ourselves fortunate to have
found a SINGLE ISP that wants to sponsor us. When we setup radio connections to our neighboring
countries we may achieve some redundancy. And I prefer that way over settting up a tunneling
system over the internet. Or even over routing over the internet. Remember we are an amateur
radio network, not some multinational company trying to setup a rendundant data network with
zero failures.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Bryan Fields <Bryan(a)bryanfields.net>
> Date:
> 06/14/2015 09:48 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On 6/14/15 3:35 PM, Rob Janssen wrote:
>> >Your problem is that you want to try to talk us into believing that we have a problem with
>> >reliability, while for most of us it is clear that we first and foremost have a problem with
>> >existance. The amateur digital network is nearly dead, we are trying to revive it and make
>> >it thrive like it did in the early days, a network built and operated by hobbyists, and you
>> >are continuously trying to impress us with your knowledge about professional networks and
>> >your concerns about failure modes.
> Rob, take a chill pill.
>
> Take a look at the HamWAN, HAMNET, and what I'm doing here in the bay area.
> It's very much alive, and we're educating people about high-speed ham packet
> networks everyday. I had over 200 people at the TAPR forum at Dayton this
> year for my talk.
>
I am not talking about the work you do locally but about the way you approach "us" after you have found some
problem with your gateway implementation.
Not even mainly about the discussion that just has started, but about a similar discussion that was started
about the same topic some time ago. You continuously refer to Brian's system at UCSD as "broken", and
I don't like that attitude.
Especially not because it really is possible to fit in your system to co-exist in the network as it is now, as is
demonstrated by our gateway.
Rob
> Subject:
> Re: [44net] Two questions
> From:
> Bryan Fields <Bryan(a)bryanfields.net>
> Date:
> 06/14/2015 09:10 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
> No, the issue is the_broken_ routing at UCSD.
>
> ARDC does not announce the 44/8, UCSD does it for them and has a static route
> for 44/8 pointing at the gateway box. This is broken routing since the
> gateway is unaware of the more specific networks.
>
> What needs to be done is the UCSD gateway needs to be made aware of the
> subnets in the global table and only announce the subnets it knows about.
> There are routing protocols that would make this easy.
But that is already in place!! It is the IPIP tunnel mesh.
As long as you provide an IPIP tunnel for the subnet you advertise yourself on BGP, with
a tunnel endpoint on an internet address OUTSIDE 44.0.0.0/8, there is no problem at all!
We do have the same situation as UCSD at our gateway. Our ISP does the BGP advertising
of 44.137.0.0/16 and routes the traffic to the gateway. We have registered the same space
on the portal, and we have an external address for that (213.222.29.194). All the routing is fine,
also for people who send the traffic to UCSD. Because UCSD sees the more specific route 44.137.0.0/16
first and sends the traffic via IPIP to us, instead of sending it out to the default gw that would
bounce it back.
When you would set up the same configuration, you would be out of trouble.
When you don't want a single system to be responsible for the IPIP tunnel you can setup some
redundancy, as long as you don't "conveniently" take a subnet out of 44.0.0.0/8 for that, because
that does not work. It is known it does not work.
>
> <tangent>
> I'd argue the BGP networks would be better if 44/8 was split up in such a way
> set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users.
> This makes the routing much easier to configure on a IPIP encap gateway. The
> present geographic area way of doing it leads to routing table bloat.
> </tangent>
I don't agree with that. It will just make a new configuration necessary for something that now
works OK just by the mechanisms we already have.
Rob
Hi!
I have two questions:
1. Around 99% of all webcams on the HAMNET are *only* reachable if you
establish the connection using a *source-44* ip address. Do you think
this restriction is enough if you don't want to expose the webcam to the
internet but want to share with other AMPRNet users?
2. We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless
router to HAMNET access point> into their DSL/cable routers. Some
well-known internet services for radio amateurs are nowadays hosted on
the internet using network44 addresses. Who needs to be blamed if the
connection from the HAMNET user to the well-known internet service is
not as stable as expected by the user?
73,
Jann
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
On Sun, 14 Jun 2015, Brian Kantor wrote:
> Date: Sun, 14 Jun 2015 18:20:22 -0700
> From: Brian Kantor <Brian(a)ucsd.edu>
> Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] AMPRNet Interoperability with BGP
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote:
>> This only requires at
>> least 1 (or more) ISP (or companies running BGP) willing to setup a
>> BGP over GRE tunnel to Brian's server to make this work. There are
>> currently two ISP I know of willing to do this if Brian is willing to
>> do this on the AMPRnet Server shown in the drawing.
>
> I'm willing but not able. The server 'amprgw' is an old FreeBSD system
> that doesn't understand GRE. We have been discussing updating it to
> a more modern system (both hardware and software) but at this point
> it doesn't seem like that's going to happen. We've not been able to
> identify ANY router product that can do what the gateway needs to do
> in order to replace 'amprgw'.
>
> I have an alternative suggestion, which would be to find an ISP or two
> that are willing to take over the IPIP tunnel routing.
>
> They would BGP advertise /24 summary routes for the smaller tunnels, as well
> as appropriate routes for the wider tunneled subnets. That way there is
> no fixed route that blinds the tunnels to the BGP subnets. UCSD could
> still advertise the 44/8 overarching route (which I strongly believe is
> essential to preventing prefix hijacks), but since there would be more
> specific routes for the BGP and tunnel subnets, that wouldn't matter.
> It would only be necessary for the tunneled gateways to change their
> tunnel endpoint address -- there is no need for tunneled gateways to
> suddenly have to change software or overall configuration.
>
> Flaws?
> - Brian
>
If we did BGP over IPIP would that work? Are you able to run Quagga or
something that can do BGP/Routemaps on your FreeBSD box? What version of
FreeBSD is it?
Is the CAIDA telescope a external system? Perhaps a SHIM box with
quagga & GRE Tunnels between CAIDA & amprgw?
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Don Fanning <don(a)00100100.net>
> Date:
> 06/13/2015 10:05 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Alright, let's take this a different route.
>
> What would it take to make IPIP mesh more robust?
>
> If BGP capable nodes were to announce and route for IPIP endpoints within
> it's endpoint, that would remove the SPOF at UCSD.
No, it will just make the system more complicated. Especially when you introduce yet another
routing protocol, even worse, a manufacturer proprietary protocol.
When you want to do something about a SPOF it is only required to do the RIP transmission
from another system in parallel. E.g. from the system running the portal.
Rob
