Strange practices?

Mon Jun 7 21:16:26 UTC 2010

Let me recant on what I said.  I re-read and had myself confused (apologies).  I see that the providers are using their own AS's.  I still would not do this if it could be avoided, but the traffic won't be dropped like I had said, in the way I was thinking.

What I was thinking was a case where the same AS is announcing from two sites, which are not connected via iBGP. In that case default behavior is that the AS drops traffic from its own AS as this is how eBGP accomplishes loop prevention.

In the case that is being described this won't happen since each provider is using its own AS to announce from.  

Brian

On Jun 7, 2010, at 5:05 PM, Brian Feeny wrote:

> 
> I would say partitioning into two AS's like this is not a good thing.  I wouldn't consider it a valid design myself, and would avoid it if possible.
> 
> If one of the AS's that is announcing the block, originates any traffic into the other AS for that block, the traffic will drop.  I realize this ideally should not happen, but BGP uses arbitrary metrics, and people turn alot of knobs, which makes wierd things happen.
> 
> If someone were doing this themselves, I would say at least use a GRE tunnel with an iBGP link between the sites, but your not going to get that out of these providers, so its going to remain partitioned which should be thought through well as there may be issues with this.
> 
> Brian
> 
> On Jun 7, 2010, at 4:59 PM, Florian Weimer wrote:
> 
>> * Dale Cornman:
>> 
>>> I had personally never heard of this and am curious if this is a
>>> common practice as well as if this would potentially create any
>>> problems by 2 Autonomous Systems both originating the same prefix.
>> 
>> The 6to4 anycast gateway RFC practically mandates this, and it does
>> work when you're doing anycast.  But with static routes, you cannot
>> handle some failure scenarious, and that usually a good reason to stay
>> away from such setups.  Of course, in the world of real routers, there
>> might be constraints such lack of memory or processing power to handle
>> BGP. 8-/
>> 
> 
> 