17 Mar
2016
17 Mar
'16
8:25 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net