44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)
by Bryan Fields 30 Jan '14

30 Jan '14

On 1/30/14 12:47 AM, Heikki Hannikainen wrote: > As I understand it, currently all BGP sites must have an IPIP gateway too > to enable connectivity with all the rest of the non-BGP sites. This, i've got it going, but requiring a mesh of tunnels is nasty and it's hard to maintain (absent custom protocols) As it stands now, my BGP space can talk to the rest of the internet, but no other 44/8 (excluding the 9 BGP subnets). I'd love to write up an draft proposal for AMPRnet on how to fix this, but I just don't have the time right now. I'd want it as a standard that works on all routers at least for the "core". Perhaps even a route reflector software would work (ALU/CSCO/JNPR have this now). Even foundcade would work, the MLX's don't shit the bed anymore :) Mikrotik is not something you can put in a CO/datacenter for obvious reasons. I'd love to say we need a custom protocol, but the chances of getting that supported on anything production grade is slim to none. Argh, I'll have to make time to do this. I travel about 75% of the time for work, it sucks. I'm a bit hungover in an airport now even :) 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 20
by Steve Wright 29 Jan '14

29 Jan '14

With the BPG routed system, the > gateway is another weak link in the routing chain. What happens if > the BPG gateway goes down - every station down stream is isolated. > Yes thats correct. Why do you think an unreliable gateway is the proper way to build a network? If that subnet needs failover, then add failover. This is a volunteer effort, with > distributed network design and management. > No, it's a volunteer effort that's broken, because everyone wants to over-engineer some new unduly-complicated idea into a very uncomplicated system that actually works REALLY WELL EVERYWHERE else.. > What we have now, with IPIP Encap (protocol 4) is a FULLY MESHED > network. How much better can you get than a network that speaks DIRECTLY > gateway to gateway with NO intermediate hops??? Isn't this one of the > benefits of HSMM-Mesh in that any node that has a path to another node can > continue to pass traffic when other nodes have failed? > > This mesh crap really needs to be binned, or at the very least not try and do anything important over it, such as route an entire /16. If you want to connect a /24 with it to make a neat local play toy then go for it, but using it as an enterprise routing tool is absurd at the very least, and at it's WORST, it's very likely to just completely stop anyone from trying to build anything new over it because it's connectivity and throughput sucks. It's just a subnet for gods sake - stop playing with it and route the shit already, then we might actually get to DO SOMETHING over it. Puhleeease.. >

1 0

amprnet portal
by Eric Fort 28 Jan '14

28 Jan '14

is there a written spec for exactly what the amprnet portal needs to do and keep track of? Might it be available for review and reading? Thanks, Eric Fort AF6EP

3 2

Newmembers
by Jerry 27 Jan '14

27 Jan '14

I forget how does someone join NET 44 working group.. Sorry.. Thanks 73 jerry

1 1

Re: [44net] amprnet portal
by kb9mwr＠gmail.com 27 Jan '14

27 Jan '14

Brian, Interesting, thanks for sharing. Amplifiers are something I really think the ham community needs to think about. They exist, but like you say, but at outrageous prices. i.e.: http://www.shireeninc.com/300-500mhz-20-watts-outdoor-amplifier/ I have been reading Dubus magazine (focused on microwave), hoping to read more data oriented construction articles. I am much in the same line of thinking. 1200 and 9600 is really not worth re-deploying in 2014. The regulatory landscape needs some major changes so that manufactures can put something different in the hands of many. Steve

1 0

Re: [44net] amprnet portal
by Bryan Fields 26 Jan '14

26 Jan '14

On 1/26/14 2:20 PM, kb9mwr(a)gmail.com wrote: > It would be interesting to hear more about how those other BGP > announced chunks of 44net are using the space. My segment 44.98.254.0/24 is being used for one PtP data link now, and some asterisk based repeater controllers. I have email for kb9mci.net on it (but need to get SWIP/PTR going Brian ;). My intent is to fire up some of the doodle labs 23cm link cards as we get another repeater site and link it over on that space. As this grows over the next couple years it will be quite a high speed data network with VoIP as the primary purpose. Doing all the RF links in the ham bands is part of the fun. (anyone have a OFDM rated 20-30 watt amp for 23cm that's not $2k?) One of the pet peeves I've have is not being able to access the other AMPR net space with out tunnels. I think tunnels are just an ugly hack IMO. I'd like to see us transition into more of a regionally routed network, rather than the few BGP nets and UCSD gateway. Well aware of how much time this would take I'm not ready to write up a proposal just yet (ampRFC?). If anyone wants a subnet I'd be happy to route it to you, as I'm not using the whole /24 and won't be for some time. Global routing policies being what they are, a /24 is the smallest subnet you can announce. My interest lies in high speed networks, and see little to no value in 9600 baud IP networks in 2014 :) 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] amprnet portal
by kb9mwr＠gmail.com 26 Jan '14

26 Jan '14

Along the same lines, I have been wondering: Will the portal design/code be available for other regional BGP enabled 44net gateways to implement? It would be interesting to hear more about how those other BGP announced chunks of 44net are using the space.

1 0

Are there (still) issues with SMP and/or x86_64 and AX25 on linux?
by Robert Brose 25 Jan '14

25 Jan '14

For a quite a while I've been getting "bugs in scheduling while atomic" kernel messages. I seem to recall there were some issues with SMP and mkiss at some point in the past. This isn't a hardware problem since the issue remains after putting together a completely new system. This is currently a machine running debian wheezy i386 userland with a x86_64 kernel. ax25_rebuild_header is in all of these dumps. Seems suspicious. The hardware is a i7-4770K CPU @ 3.50GHz with 16 gigs of ram, dual ethernet ports (acting as a router), a serial kiss port to a TNC and an AXIP port. ham related modules in use: ipip 12941 0 tunnel4 12629 1 ipip ip_tunnel 21436 1 ipip netrom 36534 4 mkiss 17161 2 ax25 54676 60 mkiss,netrom dmesg [10433.518914] Hardware name: MSI MS-7850/Z87-G41 PC Mate(MS-7850), BIOS V1.2 06/07/2013 [10433.518915] 0000000000000000 ffff88002e21e7c0 ffffffff814b98af ffff8803f603e000 [10433.518917] ffffffff814b6f16 ffff88040eb93800 ffffffff814bd1ad 0000000000000000 [10433.518918] ffff88041fac3bd8 ffff8803f603ffd8 ffff8803f603ffd8 ffff8803f603ffd8 [10433.518919] Call Trace: [10433.518920] <IRQ> [<ffffffff814b98af>] ? dump_stack+0x41/0x51 [10433.518927] [<ffffffff814b6f16>] ? __schedule_bug+0x46/0x55 [10433.518928] [<ffffffff814bd1ad>] ? __schedule+0x5cd/0x780 [10433.518931] [<ffffffff8108d3dd>] ? __cond_resched+0x1d/0x30 [10433.518932] [<ffffffff814bd3d7>] ? _cond_resched+0x27/0x30 [10433.518934] [<ffffffff814bc209>] ? mutex_lock_interruptible+0x9/0x40 [10433.518942] [<ffffffffa0309c08>] ? rp_write+0x68/0x340 [rocket] [10433.518943] [<ffffffffa08adf0d>] ? ax_xmit+0x1ad/0x440 [mkiss] [10433.518946] [<ffffffff813d2669>] ? dev_hard_start_xmit+0x319/0x500 [10433.518948] [<ffffffff8106ac18>] ? internal_add_timer+0x18/0x50 [10433.518950] [<ffffffff813f010d>] ? sch_direct_xmit+0xfd/0x1d0 [10433.518951] [<ffffffff813d2a40>] ? dev_queue_xmit+0x1f0/0x490 [10433.518954] [<ffffffffa08988f8>] ? ax25_rebuild_header+0x108/0x2b0 [ax25] [10433.518956] [<ffffffff813d9e3d>] ? neigh_compat_output+0x8d/0xa0 [10433.518957] [<ffffffff8140a4d1>] ? ip_finish_output+0x1b1/0x3a0 [10433.518959] [<ffffffff8143ec85>] ? igmp_ifc_timer_expire+0x175/0x280 [10433.518960] [<ffffffff8143eb10>] ? igmp_group_added+0x170/0x170 [10433.518962] [<ffffffff8106ab1c>] ? call_timer_fn+0x2c/0x100 [10433.518963] [<ffffffff8143eb10>] ? igmp_group_added+0x170/0x170 [10433.518964] [<ffffffff8106c0d5>] ? run_timer_softirq+0x1f5/0x2a0 [10433.518967] [<ffffffff812860f1>] ? timerqueue_add+0x61/0xb0 [10433.518969] [<ffffffff81063bbe>] ? __do_softirq+0xde/0x220 [10433.518970] [<ffffffff814c875c>] ? call_softirq+0x1c/0x30 [10433.518973] [<ffffffff810155b5>] ? do_softirq+0x75/0xb0 [10433.518974] [<ffffffff81063e65>] ? irq_exit+0xa5/0xb0 [10433.518977] [<ffffffff810407cb>] ? smp_apic_timer_interrupt+0x3b/0x50 [10433.518979] [<ffffffff814c7a9d>] ? apic_timer_interrupt+0x6d/0x80 [10433.518979] <EOI> [<ffffffff814c8a2c>] ? sysenter_dispatch+0x7/0x21 Thanks for any ideas. Bob Brose / N0QBJ

3 2

DNS records 44.131.56.0/24
by Nick G4IRX 20 Jan '14

20 Jan '14

Hi, I've checked DNS A records for various hosts in the net that I'm co-ordinator for and they resolve but to to obsolete records. I've entered some new records via portal.ampr.org, expecting them to come to me for approval but as yet, no email! The correct entries should be - gw.g4irx.ampr.org IN A 44.131.56.9 g4irx.ampr.org IN A 44.131.56.10 Ideally the entire 44.131.56.0/24 block could be deleted as we've started afresh re-allocating addresses. Any suggestions to get this fixed? Thanks, Nick G4IRX.

3 5

Re: [44net] DNS records 44.131.56.0/24
by Rob Janssen 20 Jan '14

20 Jan '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] DNS records 44.131.56.0/24 > From: > Nick G4IRX <g4irx.44net(a)nowindows.net> > Date: > 01/20/2014 08:34 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Hi, > > I've checked DNS A records for various hosts in the net that I'm co-ordinator for and they resolve but to to obsolete records. I've entered some new records via portal.ampr.org, expecting them to come to me for approval but as yet, no email! > > The correct entries should be - > gw.g4irx.ampr.org IN A 44.131.56.9 > g4irx.ampr.org IN A 44.131.56.10 > > Ideally the entire 44.131.56.0/24 block could be deleted as we've started afresh re-allocating addresses. > > Any suggestions to get this fixed? > > Thanks, > Nick G4IRX. Nick, I think this part of the portal does not work. It would be better if it were disabled until time can be spent on it. You need to send the updates of your address space to the ampraddr robot as before. To delete a block, first download the existing allocations from ftp://hamradio.ucsd.edu/pub/ampr.tar.gz, isolate what you want to delete, edit the "IN" to "DEL" and submit it to the robot. Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net