Adam,
Well aware that ibgp is a solution, but these are pretty much completely
different sites with no interconnection whatsoever between them. Forming
a full mesh in this scenario is a bit ...
Setting up a session over GRE works as does setting up a reflector
client/server combo; but the easier solution at least for this was to
set a defroute to one of the carriers.
I understand why allow-as in <n> was skipped, but having it sure would
be handy.
On 9/13/2014 午前 04:38, Adam Thompson wrote:
On 2014-09-12 13:28, Gregory Edigarov wrote:
On 09/12/14 19:07, Henning Brauer wrote:
* Paul S. <[email protected]> [2014-08-28 11:19]:
Earlier today, however, I discovered that routes that I'm announcing
under
the same ASN (in another location) are being received and put into
the RIB
-- but never into the kernel's FIB.
that's correct behaviour, routes from the same AS aren't supposed to be
distributed via BGP but your IGP.
IGP is correct solution in most cases, but it doesn't cover the
situation when you need to accept a route originated from your remote
location or a customer connected to your remote location.
and your remote location is a few AS hops away from you.
that's where 'allow-as in' come into play.
although i would agree that it is a hack.
BGP dictates that all eBGP border routers shall form an iBGP mesh; the
assumption in the protocol is that the iBGP routers shall participate
in some sort of IGP mesh.
In other words, you're trying to make BGP do something it's designed
NOT to do.
It sounds like you need either BGP confederations or a Router Reflector.
Have a look at
http://www.enterprisenetworkingplanet.com/netsp/article.php/3617346/Networking-101--Understanding-iBGP.htm
(not necessarily the best article, just the first one I found
describing the iBGP/same-AS stuff you're talking about).
