44net June 2015

44net@mailman.ampr.org

41 participants
47 discussions

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 17 Jun '15

17 Jun '15

> 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

4 3

AMPRNet Interoperability with BGP
by Tim Osburn 16 Jun '15

16 Jun '15

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

12 26

Re: [44net] JNOS 2.0j.7 autoexec.nos ?
by Jay Nugent 16 Jun '15

16 Jun '15

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--- #

1 0

JNOS 2.0j.7 autoexec.nos ?
by Peter Mallett 16 Jun '15

16 Jun '15

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

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 15 Jun '15

15 Jun '15

> 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

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 15 Jun '15

15 Jun '15

> 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

2 1

Re: [44net] Two questions
by Rob Janssen 15 Jun '15

15 Jun '15

> 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

1 0

Two questions
by Jann Traschewski 15 Jun '15

15 Jun '15

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

6 12

Re: [44net] AMPRNet Interoperability with BGP (fwd)
by Tim Osburn 14 Jun '15

14 Jun '15

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

2 2

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> 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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net June 2015