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.
Ok... In that case a (small) number of communities could be used and a filter list to
match them from slow
to fast and assign some preference value. However, this will not be enough to make a
consistent and optimal
set of routes I'm afraid. We'll see how it works out once we encounter this
situation in practice and can
check if it leads to unwanted routes and this change would improve it.
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.
I still have to find the limits of the AS PATH length (hard or practical). Looking this
up after a mention
in a direct mail I found that there apparently is or was an implementation limit in Cisco
routers at a path
length of 256 that destabilized the internet 7 years ago. We are not anywhere near such
lengths.
However, I am aware that longer path lengths probably mean more data traffic between peers
and maybe a little
more memory and CPU use, so it could be worthwile to keep these down a bit.
We also opted for a single routing protocol versus
OSPF within the internal network with iBGP overlay and eBGP on the edge.
Ok, that is what I am doing for now as well, it has to be kept a bit simple not only for
me but also for other
people who like to install a node and configure it themselves.
Rob