> Subject:
> Re: [44net] Using Cisco Router as a gateway ?
> From:
> Drorap <drorap(a)netvision.net.il>
> Date:
> 12/27/2015 10:09 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Dear Rob
> I used to do it 15 years ago and it worked
> I even publishe the config file to the Gateways users group that time
> I did a bi directional tunneling to UCSD (that time it was called mirrorshades) and let him deal with all the neccessary routes
That is considered unacceptable behaviour....
To be a good gateway in the IPIP tunnel system you need to setup tunnels to all the other systems in the network.
I think it currently does not even work anymore as the UCSD system now blocks such wrongly routed traffic.
In a Linux system as a router, you need only one tunnel interface and the tunnel endpoints are defined in the route table
(can be put in a separate route table when you want to use the same system both for internet and 44-net)
That route table is automatically kept uptodate using a RIP daemon like ampr-ripd. Simple one-time setup and no more need to look
after it and run regular scripts that fetch files and send commands. When someone changes their external address
or subnets they route, your system will know about it after 5 minutes.
But when you want to do it the difficult way, please go ahead!
After all, learning and experimenting is what it is all about.
Ready and working setups are not as interesting as finding out yourself how it all works and what are advantages and
disadvantages of each method.
Rob
Use use protocol 4.
Beyond that I am not going to be able to help you, as I don't have any
Cisco stuff.
I snagged this from the list some time back that might be of help.
And you might want to reach out to Jason KY9J.
http://www.qsl.net/kb9mwr/wapr/tcpip/cisco.txt
Hello all,
This is a little off the topic of 44 network, but I am curios. The
44 network is split into many regions for Amateur Radio to use.
But does anyone know on how the10.x.x.x network is assign to Amateur
Radio Ham Mesh network?
Is there someone or a group that have the responsibility on dishing ip
addresses? Sorry for the band width, but
just curios.
K6DLC
--
Daniel Curry
IPV6 Sage Certified
PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92
San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]
FYI: This is how a DNS attack reply profile looks like...
(Seen via AMPR gateway, as someone uses YO addresses as the reply address)
The reply amplification can be nicely seen for each attack sequence – targets are some hosts in China.
http://www.yo2loj.ro/files/dns_attack_replies.png
73s de Marius, YO2LOJ
> Subject:
> Re: [44net] Portal API: networks and allocations
> From:
> Tom Hayward <esarfl(a)gmail.com>
> Date:
> 12/21/2015 09:20 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Mon, Dec 21, 2015 at 12:02 PM, Rob Janssen<pe1chl(a)amsat.org> wrote:
>> >You can do that by simply watching the RIP broadcast and filter your own
>> >external address.
>> >This is what ampr-ripd also does.
> Wouldn't this only work for networks in the encap with assigned
> gateways? I was planning to use it with direct/BGP allocations, not
> tunneled, so there would be no entry in the encap.
>
> Tom KD7LXL
>
I think there is no entry in the portal either... at least there need not be one.
Anyway, I never do really basic config using a method this complicated. Risk is to high that
it fails, e.g. when the portal is offline. I keep a file with important config items as a shell script
and source it wherever it is required.
Rob
I'm getting bombed with these frames:
-- IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 1 DF prot UDP
UDP: len 142 40445->6771 Data 134
0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In
0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721
0080 ......
ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162
IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 1 DF prot UDP
UDP: len 142 40445->6771 Data 134
0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In
0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721
0080 ......
ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162
IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 255 DF prot UDP
UDP: len 142 6771->6771 Data 134
0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In
0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721
0080 ......
ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162
IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 255 DF prot UDP
UDP: len 142 6771->6771 Data 134
0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In
0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721
0080 ......
Someone have a misconfigured router?
The only thing worse than an extreme left-wing state is an extreme
left-wing commonwealth protected by the sovereign doctrine.
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
> Subject:
> [44net] Portal API: networks and allocations
> From:
> Tom Hayward <esarfl(a)gmail.com>
> Date:
> 12/21/2015 08:53 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> I just looked through the portal API document
> (https://portal.ampr.org/api.php) and don't see an endpoint for the
> network list and the user's own allocation list. Is this currently
> available? Can it be added?
>
> This would be useful for automation software. For example, you could
> plug your AMPR portal username into the software and it would fetch
> your list of allocations and automatically program your router to use
> those allocations.
>
> Tom KD7LXL
>
You can do that by simply watching the RIP broadcast and filter your own external address.
This is what ampr-ripd also does.
Rob
I just looked through the portal API document
(https://portal.ampr.org/api.php) and don't see an endpoint for the
network list and the user's own allocation list. Is this currently
available? Can it be added?
This would be useful for automation software. For example, you could
plug your AMPR portal username into the software and it would fetch
your list of allocations and automatically program your router to use
those allocations.
Tom KD7LXL
Marius:
> Coming back to the IP range/AS assignment:
>
> IMHO there must and shall not be such a correspondence. An AS is used to
> group one or more subnets into an well, Autonomous System (AS), and it
> should support, based on network architecture and layout, a possible
> migration of subnets from/to a specific AS, without any changes in the
> peering structure.
> e.g. If there is a subnet with access via AS 1 it should be there. But if
> later this subnet will be reorganized, and lets say will be accessed via AS
> 2, it should be possible to move it to AS 2 without any change in the BGP
> peering. This is not possible using AS numbers generated from IPs.
The idea behind using the IP address to calculate the AS is to make sure
that AS numbers are always unique, without having to use a registry and without
having to coordinate. When there is more than one subnet, it does not matter
which one is used to calculate the AS number. When the one that was used to
calculate the AS is being moved, some care will be required so it is not used
again for this purpose at the new site.
Up to now we only route to the "regional subnet" level and each region has only
a single subnet, so there are no problems. If an additional subnet is added
and then the original one is moved there could be problems, but this is not
likely.
This whole thing can depend on local issues and policies, but it does not
really matter how you do things locally as long as everyone uses the same
method to generate the prefix of the number. I will stick to that E.212
thing as it uses only 3 digits and because others are already doing this.
(if not, I would probably have removed the "44" digits and added 2 available
digits at the end, as proposed by Robbie)
Rob
> Subject:
> Re: [44net] Proposal for allocation of AS numbers
> From:
> Egbert - DD9QP <dd9qp(a)db0res-svr.ampr.org>
> Date:
> 12/11/2015 06:13 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
>
>
> EU HAMNET has started thinking about using private 32bit-ASN quite some time ago. Diskussions in our regular meetings pulsed up since 32bit-ASN where available.
>
> But what we always were missing up to now was an international proposal for all countries using the 44-Net and, of course, a common agreement for using that. It makes no sense when everyone is rolling out a different System without talking to
> others. Chances of crashing are high and planing isn't even worth the time.
>
> Regardless wether there is a registry, policy, human- or computerbased IP-Net-to-ASN-Generator out there, we all have to respect one minimal policy to keep everything running in the future:
>
> Don't use concurrent private-ASN-proposals in parallel!
> Everything else is left to the countries themselves.
>
> For example:
> Using the 42<mcc>xxxxxx in all countries is fine. But if some country starts using eg 42<IP-OctetofCountryDeployment>xxxxx there is high risk to crash with:
>
> Greece, Netherlands, Belgium, France, Monaco, Andorra, Spain, Hungary, Bosnia, Croatia, Serbia, Montenegro, Italy, Vatican, Romania, Switzerland, Czech Rep., Slovak Rep., Austria, United Kingdom, Denmark, Sweden, Finland, Lithuania, Latvia,
> Estonia, Russia, Ukraine
>
> All of them have mcc-codes between 0 and 255.
That is correct, that is why I decided to drop that proposal, although I still think it was better because:
- it did not rely on another number list that has questionable status w.r.t. availability
(my first attempts to download a complete list ended at some ITU site that requires a subscriber login,
but later I found places where the full list is available in the open)
- it handles the issue that the USA has much more network space relative to the number of E.212 entries
- it left a lot of space in the private ASN range unused for future ideas (4225600000 - 4294967294)
However, these issues are not that relevant in practice, and I am willing to go with the E.212 based system
because it is already there.
It gives all countries at least 100000 AS numbers to work with without any risk of duplicates, and some
countries have more than one mcc number. That should be plenty, especially when they are not based on
another number like a network address, but generated at some central site.
Finally, when space ever runs out we can always assign "reserved" E.212 numbers as an overflow.
100000 numbers is a lot, and allows for regional subdivision where appropriate.
Rob
