Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NANOG: users

BGP Peer Selection Considerations

 

 

NANOG users RSS feed   Index | Next | Previous | View Threaded


adel at baklawasecrets

Nov 9, 2009, 9:40 AM

Post #1 of 9 (670 views)
Permalink
BGP Peer Selection Considerations

Hi,

Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows:

BGP Peer with Provider A who is multihomed to other providers.
BGP Peer with Provider B who is not peered with provider A

I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse "fibre backhaul network"). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to.

Am I missing things that I need to consider?


sethm at rollernet

Nov 9, 2009, 11:04 AM

Post #2 of 9 (645 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

adel [at] baklawasecrets wrote:
> Hi,
>
> Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows:
>
> BGP Peer with Provider A who is multihomed to other providers.
> BGP Peer with Provider B who is not peered with provider A
>
> I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse "fibre backhaul network"). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to.
>
> Am I missing things that I need to consider?
>

Don't let them cross connect over their network. Bring it in to your
site separate from A, otherwise there's no point in the multihoming
exercise.

~Seth


herrin-nanog at dirtside

Nov 9, 2009, 11:10 AM

Post #3 of 9 (644 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

On Mon, Nov 9, 2009 at 12:40 PM, <adel [at] baklawasecrets> wrote:
> I have an existing relationship with provider A, colo, cross connects
> etc.  Provider A has offered to get the PI space, ASN number,
> purchase the transit for us with provider B and manage cross
> connects to provider B (they say they have a diverse "fibre
> backhaul network").  This is quite attractive from a support
> and billing perspective.  Also suspect that provider A will be
> able to get more attractive pricing from Provider B than I
> would be able to.
>
> Am I missing things that I need to consider?

What happens when provider A is bought by provider C and you want to
dump provider C but keep provider B? You'll have created a conflict of
interest for provider B in any negotiation you have with them.

Be aware that provider A's diverse network for provider A's service is
the same diverse network they'll use to connect you to provider B. As
a result, many or most of the outages which impact provider A will
also impact your connectivity to provider B, defeating the central
purpose of having a provider B.

Regards,
Bill Herrin


--
William D. Herrin ................ herrin [at] dirtside bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


jgreco at ns

Nov 9, 2009, 11:20 AM

Post #4 of 9 (648 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

> Don't let them cross connect over their network. Bring it in to your
> site separate from A, otherwise there's no point in the multihoming
> exercise.

s/no point/less benefit/

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


sethm at rollernet

Nov 9, 2009, 11:57 AM

Post #5 of 9 (646 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

William Herrin wrote:
>
> Be aware that provider A's diverse network for provider A's service is
> the same diverse network they'll use to connect you to provider B. As
> a result, many or most of the outages which impact provider A will
> also impact your connectivity to provider B, defeating the central
> purpose of having a provider B.
>


I'll just add to the OP: you want them independent *to you* not
internally diverse between themselves. How would that help your site be
independent? I'm sure the billing/support sounds attractive (and they
get to upsell you), but you won't gain provider independence, only a
larger bill.

~Seth


steve at ibctech

Nov 9, 2009, 6:43 PM

Post #6 of 9 (642 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

adel [at] baklawasecrets wrote:
> Hi,
>
> Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows:
>
> BGP Peer with Provider A who is multihomed to other providers.
> BGP Peer with Provider B who is not peered with provider A
>
> I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B

...I've likely missed something, but get the IP/ASN for yourself.

*ensure* that A & B will peer and provide transit for you.

> (they say they have a diverse "fibre backhaul network"). This is quite attractive from a support and billing perspective.

...until you find out that the backhaul network is owned by Provider B,
or virtualized within an existing circuit to someplace else.

> Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to.

But at what cost?

> Am I missing things that I need to consider?

I think so. Long-term survival for one.

If you are budgeted for a diverse and redundant network, then I
recommend that you ensure one. My current understanding is that you can
negotiate terms with potential providers where there is competition.

Don't allow any of your ISPs to manage/dictate the use of your address
space. It will bite you, and cause undue frustration.

Steve


adel at baklawasecrets

Nov 10, 2009, 1:52 AM

Post #7 of 9 (624 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

If nothing else by the time this deployment is finished I will surely have become extremely cynical. Now reading through peoples answers, I think the general consensus is that
I would be giving too much control to provider A in the scenario I suggested below. So as someone mentioned they have the ability to foul up my connections all by themselves.
>From all of this I gather that the most resilience would be provided by:

1) Go to two tier 1 carriers myself - say Global Crossing and Level 3. Arrange to get two 100meg BGP feeds, burstable. Pick them up at different datacentres as well I suppose to provide
datacentre redundancy? Negotiate pricing, any tips on negotiating appreciated.

2) Arrange cross connects to these providers i.e. get to the datacentres the Tier1 providers are in. They are not on net at the colo we are in. With regards to arranging the cross connects
am I able to ask the cross connect providers for fibre maps? Is this a done thing or will they brush me off with "you don't need this our network is diverse?"

3) Arrange for PI space and ASN myself, so become an LIR through RIPE.

Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN for me? I think the failure mode cited by someone was if the PI and ASN provider goes out of business. I would prefer
not to go through becoming an LIR and maintaining the membership, as they are not an ISP and so it is more attractive to do that through one of the Tier 1 providers.

I'm not sure what my options are in terms of getting to the datacentres to pick up the Tier1 providers. The "provider A" below has said they run a diverse fibre backhaul network etc etc.
and I should go with them for connectivity to other datacentres. Now it would be easier to go with them just because they are running colo for us and they run the datacentre we are in.
However I assume that I should not be scared of arranging a second cross connect with someone else altogether.

In all of the above, I'm most worried about administrative overhead. Managing two cross connect providers, managing ongoing relationship with two Tier1 providers and so on. However
resilience comes at a cost I suppose is the answer.

Comments appreciated.

Adel

On Mon 7:10 PM , "William Herrin" herrin-nanog [at] dirtside sent:
> On Mon, Nov 9, 2009 at 12:40 PM, <adel@
> baklawasecrets.com> wrote:> I have an existing relationship with provider A,
> colo, cross connects> etc.  Provider A has offered to get the PI
> space, ASN number,> purchase the transit for us with provider B and
> manage cross> connects to provider B (they say they have a
> diverse "fibre> backhaul network").  This is quite
> attractive from a support> and billing perspective.  Also suspect that
> provider A will be> able to get more attractive pricing from
> Provider B than I> would be able to.
> >
> > Am I missing things that I need to
> consider?
> What happens when provider A is bought by provider C and you want to
> dump provider C but keep provider B? You'll have created a conflict of
> interest for provider B in any negotiation you have with them.
>
> Be aware that provider A's diverse network for provider A's service is
> the same diverse network they'll use to connect you to provider B. As
> a result, many or most of the outages which impact provider A will
> also impact your connectivity to provider B, defeating the central
> purpose of having a provider B.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin ................ herrin [at] d
> rtside.com bill [at] herrin
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>Falls Church, VA 22042-3004
>
>
>


nick at foobar

Nov 10, 2009, 2:02 AM

Post #8 of 9 (622 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

On 10/11/2009 09:52, adel [at] baklawasecrets wrote:
> 3) Arrange for PI space and ASN myself, so become an LIR through RIPE.

You don't need to become a LIR to get PI space and an ASN.

> Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN
> for me?

You lose relatively little. If you wish to move your provider independent
resources to another LIR at a later stage, RIPE are very happy to assist.

> I think the failure mode cited by someone was if the PI and ASN
> provider goes out of business.

If they go out of business, there's a small amount of overhead - you find
yourself a new LIR and life will continue on. I wouldn't worry about it
too much.

> I would prefer not to go through becoming an LIR and maintaining the
> membership

Probably sensible.

Nick


adel at baklawasecrets

Nov 10, 2009, 3:00 PM

Post #9 of 9 (612 views)
Permalink
Re: BGP Peer Selection Considerations [In reply to]

I've decided to get transit from provider B independently of A, so I don't create a conflict of interest as mentioned below. However I think that I will have to use provider A's dark fibre network to connect to both peerings. Provider A tells me that they will use different routes and different entry points to get to their peering and separate routes, entries to get to B's peering. As they own the datacentre and can probably provide the bests costs for getting into the datacentres where the second transit provider is, I think I will have to use

I should mention there are no transit providers on net at the datacentre facility which has been acquired by the business. I suspect it will be cheaper to get the cross connects to where the transit provider is from provider A, (did I mention provider A owns the datacentre?). I know I'll be sacrificing some resilience by using A's network to get to both Internet services, however I think I will just have to outline the risks to the business and go with it. Moving datacentres isn't an option and as long as I understand exactly what resilience I sacrifice by getting A to provide all the cross connects, I can explain that to the business.

Adel





On Mon 7:10 PM , William Herrin <herrin-nanog [at] dirtside> wrote:

> On Mon, Nov 9, 2009 at 12:40 PM, wrote:
> > I have an existing relationship with provider A, colo, cross connects
> > etc.  Provider A has offered to get the PI space, ASN number,
> > purchase the transit for us with provider B and manage cross
> > connects to provider B (they say they have a diverse "fibre
> > backhaul network").  This is quite attractive from a support
> > and billing perspective.  Also suspect that provider A will be
> > able to get more attractive pricing from Provider B than I
> > would be able to.
> >
> > Am I missing things that I need to consider?
>
> What happens when provider A is bought by provider C and you want to
> dump provider C but keep provider B? You'll have created a conflict of
> interest for provider B in any negotiation you have with them.
>
> Be aware that provider A's diverse network for provider A's service is
> the same diverse network they'll use to connect you to provider B. As
> a result, many or most of the outages which impact provider A will
> also impact your connectivity to provider B, defeating the central
> purpose of having a provider B.
>
> Regards,
> Bill Herrin
>
> --
> William D. Herrin ................ herrin [at] dirtside bill [at] herrin
> 3005 Crane Dr. ...................... Web:
>

NANOG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.