19 Mar
2016
19 Mar
'16
8:33 p.m.
Just a thought, if the lowest link on the route to a destination has 1 single link at
10kbps this will also be the maximum speed you can achieve over that path towards this
specifc destinatio , so there is no need to multiply the different communities.
So you can setup filter which set the localpref based on the lowest communit as proposed
previously.
If you receive the same route via a longer route but with the lowest link at 10Mbps, you
may want to prefer this route. Of course this could lead to certain links becoming
overloaded if they accumulate alot of traffic due to this traffic engineering.
But this is only an idea, I haven't tuned it in any way and I haven't field tested
it completely.
BTW we use eBGP between sites but we combine this with BGP confederation. This brings the
benefit of eBGP (only BGP sessions with link peers) and keeps AS PATHs short towards our
external peers. We also opted for a single routing protocol versus OSPF within the
internal network with iBGP overlay and eBGP on the edge.
73 de Marc
On 18 mars 2016, at 10:58, Rob Janssen
<pe1chl(a)amsat.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net