On Jan 21, 2009, at 12:25 AM, mike wrote:
So I am just wondering what my expecations should be in a bgp
peering scenario where I am multihomed with my own ASN and arin
assigned ip space. At issue is the fact that my backup isp forced me
to use ebgp multihop to peer with a router internal to their network
and not the border router I am directly attached to, and secondly,
that they say I am not allowed to prepend at all - they will do it
for me, and from the looks of things they have established a route-
map that just prepends their AS 6 times to my announcement.
This smells of bad engineering. I have looked up the bgp report
for my provider and they have 0 downstream AS's, and the week that
this project has taken (and it's still not up and working) has left
me with less than absolute confidence in the provider. I want to
know if anyone has an opinion on ebgp multihop for external
customers, and wether I should really have an expectation to be able
to assign my prepends as suits my needs? Are there any conditions
that could make this fail that I should be aware of?
First, Rule Number One: Your network, your decision. (Okay, rule
number one not about spam. :) Your transit provider owns your transit
provider's network, he can run it as he pleases. There is nothing
"wrong" with multi-hop or not allowing you to prepend. Bits are
flowing, and you are connected.
Now that we know he _can_ run his network like that, I would never buy
transit from someone who _does_ run a network like that. I've seen
multi-hop before, but it is usually when something unusual is
happening. For instance, if you are in a strange location and the
edge router near you does not speak BGP. It is not horrible, but
certainly not something I personally would prefer. Multi-hop can
present more or at least different failure modes than direct BGP, but
those can be managed with clue and effort.
The non-prepending thing though, that's Just Plain Silly. And hints
at a general lack of clue. Which means that multi-hop is dangerous as
it requires more clue, not less, to manage properly.
--
TTFN,
patrick