On 6/17/13 8:46 PM, Cory (NQ1E) wrote:
> 10 with permission and 10 announcements seen on the net (in addition to the
> /8). It's good that nobody is trying to do it without permission ;)
This actually brings up a good question, as some point this weekend I'll have
44.98.254.0/24 announced via BGP out of 12083.
The Florida coordinator said I should be good to go with this once I got the
assignment completed, is this not the case?
I'd be willing to put some hardware/bandwidth/colo towards an east coast
gateway for the 44net if we have an architecture that would work for
distributing our interconnection points.
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
bryan at bryanfields.net wrote:
>I'd ask, why only one gateway to 44/8? Why not setup some tunnel/peering
>points globally?
That is a plan. There just needs to be some folks to step forward to
make it happen.
Until recently, there wasn't a formal way to seek permission from ARDC
to have the high level BGP routing changed to support this.
I have been curious since ARDC announced that option, how many/which
local subnets are not being announced locally.
Maybe Brian Kantor can chime in on that.
Steve
Awesome, please send me the script. Ill have time tear into it this weekend.
As for hardware, I'll bet testing on a 2800 series with 1gb of ram.
Jason R Begley <jayray(a)digitalgoat.com> wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>With regard to using Cisco routers for integration into the AMPRNET, if
>
>you are going to load full tunnels be ready to throw some descent
>hardware at the task. The first issue is the config length, you need
>config compression on and no less than a 2600 due to nvram size. The
>other issue is number of interfaces, you also need at least a 2600 to
>configure the number of tunnels needed to be fully meshed. I am
>currently running a 2651xm and it does an ok job. Let me know if you
>are
>interested in a script to convert the encap.txt into a loadable config.
>73,
>Jason KY9J
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
>http://www.ampr.org/donate.html
--
Bryan Fields
727-409-1194
http://bryanfields.net
On 6/17/13 2:04 AM, kb9mwr(a)gmail.com wrote:
>
> Many gateway opperators only allow inbound 44-net IP addresses.
>
> Maintain a local route table alleviates bandwith issues at ucsd, and
> the single point of failure.
Thanks, this is good info. I think I can change the "munge" script to
generate a working 44/net config. Cisco/etc is going to need a tunnel
interface for each destination, but I think it will work.
Perhaps a template interface might be the best way.
I'll post my results back here.
I'd ask, why only one gateway to 44/8? Why not setup some tunnel/peering
points globally?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Bryan,
I have some archived resources here:
http://www.qsl.net/kb9mwr//wapr/tcpip/index.html
---
But if I can reach all of 44/8 via ucsd via the internet, why bother with
tunnels in the first place?
--
Many gateway opperators only allow inbound 44-net IP addresses.
Maintain a local route table alleviates bandwith issues at ucsd, and
the single point of failure.
On 6/17/13 1:53 AM, C.J. Adams-Collier KF7BMP wrote:
> If you decided to go this way, you could use a perl script with Net::SSH
> to update the router's config. At least with IOS. I'm not familiar
> with JunOS.
Yea, I was thinking this. I have RANCID running on all the routers now, so
it's trivial to get it to push configs out once a day or so.
But if I can reach all of 44/8 via ucsd via the internet, why bother with
tunnels in the first place?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 6/17/13 1:25 AM, Heikki Hannikainen wrote:
> It's intended to be totally separate, but there's a single gateway in
> the US announcing all of 44/8 and relaying packets from the Internet
> to amprnet hosts which have an ampr.org DNS entry in place. Also, a
> few local subnets are announced locally by the gateways using BGP,
> after signing the TOS (http://www.ampr.org/tos.txt) and obtaining
> permission documents from ARDC.
>
> Upstream amprnet->internet packets should be routed, if possible, from
> the local gateway directly to the Internet, but ISP anti-spoofing
> filters / uRPF typically prohibit it these days (which is a very good
> thing in the botnet/DDOS respect). Unless, of course, you've arranged
> a BGP peering and announcing the subnet yourself, in which case you
> can send packets out from that subnet.
My intention was just to use a VRF on my main colo router for the 44net space,
and keep it separate from everything else. I'm routing this over a tunnel
back to my home and from there out to my wireless links. Right now I have 5
links all running with 172.17/16 space and thought it would be cool to link it
all with "real" IP's.
So for the exception of the 44/net space directly announced, can everything be
reached via the gateway at ucsd? Does this gateway have tunnels to the rest
of the network behind it?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
POL: Potrzebuje pomocy.
Jak modem podłączę pod ttyS0 (iobase 3f8 irq 4) na płycie głównej modem
działa idealnie nadaje
i odbiera. A jak podłączę go do ttyS1 (iobase 2400 irq 177) na karcie I/O
to tylko odbiera nie
chce nadawać
ENG: I need help.
How do I plug the modem into ttyS0 (iobase 3f8 irq 4) on the main board
modem works perfectly
transmits and receives. And when I connect it to ttyS1 (iobase 2400 irq
177) on the I/O just
does not want to give answers
------
POL: Mam komputer z 2 modemami Baycom
Linux CentOS 5, Kernel 2.6.18-274.18.1.el5ax25.2,
używam sterownik: baycom_ser_fdx
ENG: I have a computer with two modems Baycom
Linux CentOS 5 Kernel 2.6.18-274.18.1.el5ax25.2,
I use the driver: baycom_ser_fdx
------
POL: Używam modemów Baycom, podłączone do karty I/O PCI
Modemy tylko odbierają (Rx) ale nie nadają (not Tx)
ENG: I use Baycom modems, connected to the I/O PCI
Modems only receive (Rx), but does not transmit (Tx not)
------
POL: A to konfiguracja karty I/O z komendy: lspci -vvv
ENG: And this is the configuration I/O card with the command: lspci-vvv
Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:3253
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 177
Region 0: I/O ports at 2400 [size=8]
Region 1: I/O ports at 2000 [size=8]
Kernel driver in use: serial
------
ttyS0, iobase: 0x03f8, irq: 4 (mainboard)
ttyS1, iobase: 0x2400, irq: 177 (Card I/O)
ttyS2, iobase: 0x2000, irq: 177 (Card I/O)
------
baycom_ser_fdx: version 0.10 compiled
hdlcdrv: version 0.8 compiled
POL: Może ktoś mi powie dlaczego na ttyS0 działa idealnie a na karcie I/O tylko
odbiera ....
Gdzie mam błąd. Może w baycom_ser_fdx.c ???
ENG: Can someone tell me why the ttyS0 works perfectly and on the I/O only ....
Where do I receive an error. Maybe baycom_ser_fdx.c???
--
73 de Janusz / SP1LOP
===== Janusz J. Przybylski, SP1LOP ==================
Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003
=====================================================
Hi,
The AMPRNet might be more useful if it had:
(1) more services which would be interesting to hams
(2) more access to the AMPRNet
Tonight I tried to attack (2) a bit. Access to the AMPRNet over the
Internet could maybe be made easier to hams by allowing them to connect
over VPNs instead of setting up their own IPIP tunnels at home, or trying
to find a working radio gateway. After getting a VPN running it might be
easier for them to set up a radio gateway, or some services. As discussed
on the other mailing list, VPNs are easier to get up on NATed residential
networks than IPIP tunnels.
Setting up VPN user accounts and maintaining them can be a pain. It
doesn't take a lot of weekly or monthly maintenance work to run a VPN
service, but it can be a major pain to manage an user account database for
thousands of hams and check if your users around the Internet are, in
fact, licensed.
It turns out that ARRL's Logbook of the World has already given out
cryptographic X.509 certificates to 57334 amateur users, after verifying
their license status against the FCC database (they send a postcard with a
random token code to the FCC-listed snail-mail address to make sure they
give the certificate to the right guy) or after looking at a paper
photocopy of a license + a photo ID. I had to physically mail in a photo
of my ham license and my driver's license and wait a couple weeks to get
the cert. If they can get 50k contesters and DXers to work with
certificates, maybe certs can work for the AMPRnet, too.
Technically, we can validate if a VPN user is in possession of one of
those certificates and the respective private key. Politically, K4JH asked
the ARRL guys, and they said that they don't mind if we use them for other
ham authentication needs. We can start accepting other CAs too once they
come around. I plan to help SRAL, the Finnish amateur radio union, to set
up a CA within their web site (they already have user accounts for
members). I know ARRL isn't for everyone, but smaller clubs could set up
CAs too, or even commercial entities - as long as we trust them to do the
license validation in a proper manner.
Tonight I hacked up an OpenVPN setup which authenticates users with LoTW
certs, and wrote a little documentation:
http://wiki.ampr.org/index.php/AMPRNet_VPN
What do you think? Technically, it seems to work - try it out if you like.
It's not very straightforward to set up, but the license validation is
pretty strong, and running the service shouldn't be a lot of work. There
can be many VPN servers around the world, serving the whole customer base
(VPN servers do not need access to any central user database, they just
need the certificates of the trusted CAs). With a little Dynamic DNS
magic, you could get a oh7lzb.vpn.ampr.org hostname on DNS within a few
seconds after connecting (I've got code for that in another project).
(Yes, eventually certificates need to be revoked after they accidentally
get into wrong hands, or ham licenses are revoked. Technically that can be
done using CRLs and/or OCSP, but ARRL apparently does not do those yet.
Maybe they will, if the need arises. We can also set up a blocked
certificates list of our own.)
- Hessu, OH7LZB
It's been a while since I encountered this problem I have forgotten the
fix. My JNOS has stopped populating routes broadcast by the rip server.
I've verified that I am receiving the broadcasts through tun0 and there
have been no changes to my autoexec.nos file in a long time. I think
routing via rip stopped sometime within the past few days. Any ideas ?
tx ~Ken
