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.
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.
Assuming you're getting full routes from this provider, I wouldn't be surprised if the multihop is required because their router you're connected to doesn't have or can't handle full BGP routes. I've done this with customers in the past when they were connected to routers that didn't have the RAM for full routes.
As for the "you're not allowed to prepend" thing, have you experimented to see what happens if you try? Unless they're giving you special pricing based on the idea that they're providing you with strictly backup transit, they shouldn't be doing the prepending (unless you've asked them to or used communities to tell them to).
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
Only a week? I've seen BGP turnups take much longer...not that they should.
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.
Hmmm, this is distinctly unusual.
I'd suspect that the person that you are talking to is a: very new to BGP and is just applying the wrong canned route-map or b: the person is a little less new to BGP and has reached the "Oooh, now I know that I'm doing and can twiddle the knobs with the best of them" stage. I'd suggest trying to find someone else there to talk to....
Unless you have specifically bought the service as a "backup" service (and they are clumsily (and poorly) trying to make sure that you don't use it as your primary path) I cannot think of why your ISP would do this. This also seems a bit worrying -- either they have enough capacity to carry your traffic when you need them to (and so should be happy to let you use them and bill you for the bits) or they don't and you will be unhappy when your primary goes away.
Are they really really cheap? If you need a "backup" ISP for regulatory reasons and don't really care, thats fine. If however you want good performance when your primary goes away, I'd suggest looking into this more...
This smells of bad engineering. I have looked up the bgp report for my provider and they have 0 downstream AS's,
Yeah, that is worrying....
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?
While multihop is not in itself an issue, it does give one pause and it is worth finding out the reason. But, yes, you should expect to be able to prepend at will...
See, this is why I like NANOG. Many eyes see things one pair does not.
Hadn't even occurred to me that they were giving you special "backup transit only" pricing. In that case, makes perfect sense to force multiple prepends on their side.
As for the "you're not allowed to prepend" thing, have you
experimented to see what happens if you try? Unless they're giving
you special pricing based on the idea that they're providing you
with strictly backup transit, they shouldn't be doing the prepending
(unless you've asked them to or used communities to tell them to).
See, this is why I like NANOG. Many eyes see things one pair does not.
Hadn't even occurred to me that they were giving you special "backup
transit only" pricing. In that case, makes perfect sense to force
multiple prepends on their side.
Good insight, Patrick. If I might suggest a point or two, it's that
there's more than one "expectation" here, or perhaps should be:
1. Expectation on protocol/policy behavior
2. Expectation on service delivery and economics
If breaking #1 doesn't break the basic functionality, but does achieve
something under #2, it's worth clarifying. If #1 doesn't improve #2,
there's a legitimate gripe.
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.