> AFAICT making a difference between routes learned via radio, tunnel or the AMPR IPIP mesh
> has most importance within your local AS. You may forward those annoucements by any mean to another AS.
> For example, you may learn a route via tunnel bit forward it via radio to another AS. This other AS may
> learn that same route via tunnel and your radio link. So the question may come up if that other AS should
> prefer a direct route via tunnel ot a route learned via radio whcih ultimately still goes via a tunnel.
> From a HAM perspective you might want to prefer the longer route via radio but then you will eventually
> have to pay for the bandwidth used by that other AS, but this might not be relevant in your case.
I have been varying what is an AS, but at the moment I am using the simple "one site is one AS".
This means everything is eBGP and there is no interior routing protocol.
Of course one could define larger areas and use iBGP within them, but it will be very difficult to set
up a reasonable system because geographical boundaries and management group boundaries are very different
here, and also difficult to predict. Some people may want to do everything themselves, others will leave
the management to me. And of course we like "simple" deployment without the headaches of setting up
peering with an increasing number of routers within the AS. With eBGP you only need to peer with the
routers you link to.
I have read that in other countries OSPF is used as IGP and eBGP on top of that as an inter-AS protocol.
That is most likely too difficult to deploy here, except when we exclusively use OSPF inside the country
and BGP at the links to our neighbors.
The way I see it now is that we use eBGP to exchange the routes between our nodes inside the country and
our gateway, where we distribute 3 routes (0.0.0.0/0, 44.0.0.0/8 and 44.137.0.0/16) that can be used as
"default" easily selectable with a filter, and the /22 or lower subnets are exchanged as defined in our
IP plan.
When we make links to our neighboring countries Germany and Belgium, we will only send them the aggregated
route to 44.137.0.0/16 and not the route to 44.0.0.0/8 or 0.0.0.0/0. When we receive /15 or smaller
routes from them we announce them inside our network and also to the other neighboring country, so we
can also carry transit traffic from Belgium to Germany and v.v.
We are not going to route traffic towards internet for them, neither direct nor tunneled.
> What may be of interest in a more universal way, might be the available bandwidth on the route.
> A route which goes over multiple links (whatever kind) of which one has one link limited to 50kbps
> might be worth to be used as a secondary route over a route which has the slowest link at 1 Mbps, regardless of the technology.
> So may we should define "well known communities" which define the link speed over which they are learned.
> Those pseudo well known communities could start by X: followed by the bandwidth class. For example:
> 0:1 = 10kbps
> 0:2 = 100 kbps
> 0:3 = 1 Mbps
> 0:4 = 10 Mbps
> Etc
The problem with eBGP is that there is no other metric than hop count to select preference of a route,
all other selections have to be made by local static configuration or derived from community values.
In the automatic routing protocols we used before, like NET/ROM, the metric of a path is calculated
from the metrics of the individual links, and assigning a metric corresponding the the quality of each
link would influence the selection of that link as part of a long path. 3 fast link hops could be
preferred over one slow one.
Not so in eBGP. You can influence the path by introducing "artificial" extra hops on slow or bad
links, so that for example a 10kbps link counts as 3 hops, and is not used when two other faster hops
can reach the same destination, but of course this works very coarsely.
A system as depicted above could only be used at the next hop, but it would not be easy to assign
such values to every link and then calculate an aggregate metric of all the hops to the destination.
Routers can match community values using a direct compare and often a simple pattern match on the
decimal representation of the numbers (e.g. when the value is 1234 you can match on 1??? to select
the values that start with a 1 when written in decimal), but operations like multiplying community
values to achieve a new value to be used as a preference are not available.
That means you would need long and complicated matching tables to do anything with information like
you propose.
Rob
What is the status of the "to-be-deleted.txt" cleanup?
There are 14946 entries that were announced to be deleted early march, but looking at
the current zonefile it appears that only about 1524 have been deleted at this time...
(I have deleted about 1000 entries, that were not on that list, in 44.137 myself)
Rob
With the kind cooperation of Neil Johnson, I've identified nearly 15000
entries in the AMPR.ORG DNS that I feel can go away.
What was done was to create a list of valid subnets of network 44
by combining the encap list, the list of BGP-advertised subnets, and
extracting all the connected or end-user subnets listed in the portal.
We then made a list of all the DNS entries that no longer fall into any
of those subnets. This is nearly half the "A" records in the DNS.
That list is available for review by anonymous FTP from hamradio.ucsd.edu.
The file is called "to-be-deleted.txt". I encourage everyone who has
a DNS entry to fetch a copy of the file and make sure that we haven't
accidently included any entries that need to remain in the DNS. Please
let me know of any such entries and I can remove them from the list.
Assuming our scheme worked, around the beginning of next month, March,
I will process the list and remove those entries from the DNS. We still
have a long ways to go but this will help.
Thank you.
- Brian
> It's essentially at a standstill; it depends on people making sure
> that their allocations are registered in the portal and that just
> hasn't been happening. It's very disappointing.
Ah, ok... This time I just announced the deletion, gave people a month to reply, then
deleted everything that was not reconfirmed. I received some confirmations, in addition
to those received and processed in 2014. After the deletion, only two suddenly woke
up and wanted their registration back.
But most of these are still not registered in the portal, I would need some kind of
batch import method for that.
Rob
Cory is correct. I just followed his steps and the openvpn server
started up fine. When I went to connect using my windows Securepoint
client I got a TLS error till I went in and unchecked the server
certificate box.
I am using the concatenated certs\root (didn't break them apart) as ca.crt
I got an IP and everything worked just fine after that. I'll try what
Hessu is talking about setting up a private ca and having it issue a
server certificate about later today after running some errands.
Still a little confused on that. But I think it equates to:
./build-ca
./build-key-server server
Do I just discard the ca.crt that the first step produces and continue
to use the certs\root file?
Thanks Corey that is the info I was seeking.
For anyone else with further clarification:
Server Side:
- ca.crt = The latest LotW Root CA cert
certs\root*, you need to break them apart an select the latest one
- server.crt* = Your personal LotW cert concatenated with the
intermediate that signed it.
certs\user* + certs\authorities*
- server.key = The private key associated with your personal cert
keys\YOURCALL*
*References are to the Windows TQSL program:
C:\Documents and Settings\your-username\Application Data\TrustedQSL\
Is there any registry or documented method for allocation values for "BGP communities"
to be used inside the AMPRnet as helpers for the BGP routing?
Note I am not referring to internet BGP, but to the BGP protocol used on isolated radio
networks operated using private AS numbers.
Some time ago we have discussed the allocation of AS numbers in the 32-bit AS space,
and I would like to know if people feel a necessity for allocating (reserving) community
values as well.
These are 32-bit values, commonly written as two decimal 16-bit values separated by a colon,
used to communicate attributes of a route. I now use one value to tell the other routers
that a route is not over radio (but over internet tunnel, in this case) so inside the network
it can be used as a backup route when the radio route fails.
In practice there is little chance of collision of these community values, and they can
easily be filtered or translated at boundaries between areas where different values are
used.
Originally a common practice was to use the own AS number as the first value in the
2x16bit pair, but of course that no longer works now the AS number can be 32 bits.
Rob
> RFC4360 defines extended communities, but I don't know much more about them.
> So far not I haven't seen much usage of communities within AMPR BGP networks.
Of course the used routers must support it as well...
> Which usages would you like to coordinate?
My question is if I need to coordinate... I think probably not.
The usage is to mark routes with an origin, just like Jann mentioned in his
reply: we have a central gateway with VPN support and we can setup a VPN from
routers in the country that are interlinked by radio links, where of course we
would like the traffic to flow over the radio links unless they have failed, in
which case the routing via VPN would be an alternative. For BGP to know which
routes are radio routes and which are VPN routes, a "community" is the BGP name
for an attribute that you can add to each separate route, at its origin.
Then every router can examine this attribute and assign a lower preference value
to the route. Routes with a lower preference are not used when a route to the
same destination with default or higher preference is available.
> Since these are arbitrary numbers, I use the first decimal part of the 32bit
> address as the high word (so that the 42 + country is conserved).
> Just an idea, and it works...
> e.g. 42226:0
Yes, that would be a possibility. Right now I have used 44137 (our net is 44.137)
but a numbering like that would be possible too.
Of course this conflicts with the common practice to use the 16-bit AS as the first
16 bits, because we don't own any of those two AS numbers. Jann's proposal of using
a 16-bit private AS avoids this conflict, but it is incompatible with 32-bit AS.
However, in practice there is no problem because we will never see community
values from an AS like 42226 or 44137 on our isolated network.
(where we are using private AS numbers only)
Again, for clarity, our network is BGP routed on internet, but this is a completely
separate thing. BGP at the internet side is run by our ISP who advertises our
44.137.0.0/16 network on internet (under agreement with ARDC) using their own
AS number, receive the data and send it over an ethernet link to our gateway,
where we relay it to our radio network which also uses BGP, using private AS numbers
and those community values we are discussing, but there is no BGP traffic
"across" the gateway, only IP traffic to/from internet.
So my guess is that any community value set up using a convenient numbering scheme
to reduce the conflicts with cross-border schemes is sufficient, a more elaborate
scheme like the IP address or AS number coordination is not required.
(note that HamnetDB has a registration for AS numbers, but not for community values)
Rob
While I appreciate the responses from everyone, no one is really
explaining this in a nice step by step manner that I need. I suspect
its because everyone is trying to help me learn it rather than give me
the answer. The problem is the terminology compounded by extraneous
info.
________________________________
>If you want to use LotW keys, you CAN NOT generaty any keys.
>
>Let me motivate:
Well its not working. I am real close to throwing in the towel and
moving on to a different project.
>
>- LotW has a CA certificate, and its private key.
>- using those, it generates some intermediate certificates, public and
>private keys.
>- using those intermediate certificates, it generates the public and
>private keys for the user which are sent to him.
I understand all this.
>To generate user keys, you NEED the private keys of the intermediate
>certificates, which you do not have. These are needed to sign the newly
>generated keys.
I think of this as two parts, client and server. Maybe thats the
wrong way to look at it, but either way user keys equates to me as
client keys, which has already been documented in a simple manner.
I don't need the private keys because A.) I am not asking about the
user/client end of this.
These are the related files in my server,conf file. I am asking
where/how do I get these so that my openvpn server can be accessed by
clients using the method documented in the wiki:
http://wiki.ampr.org/wiki/AMPRNet_VPN
ca.crt server + all clients Root CA certificate
ca.key key signing machine only Root CA key
dh{n}.pem server only Diffie Hellman parameters
server.crt server only Server Certificate
server.key server only Server Key
> Here you can find the proposed allocation method:
> http://laru.lu/on-the-air/hamnet-44net.html <http://laru.lu/on-the-air/hamnet-44net.html>
> It uses 32 bit ASNs, which are represented as a single number, the old
> 16bit:16bit scheme being obsolete, but backwards compatible.
I know about AS numbers but I am asking about community values, not AS numbers.
Rob
