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.
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
These are just my thoughts :-)
73 de Marc
On 17 mars 2016, at 21:28, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net