[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is it normal for your provider to withhold BGP peering info until the night of the cut?

My first question is, is this the first request for the information which
resulted in this information?  Almost wonder if you're currently dealing
with someone that does only a certain part of the setup and instead of
saying " I don't know " attempted to give an answer that he really has no
idea about.  While they may not be able to provide it today, I can't
believe they can't provide it in advance of the activation.

That being said, we tend to cut the IP allocation anywhere from a day to a
week before the scheduled activation.

You mentioned they were a major player, shouldn't be to difficult to
identify their ASN and then all you need is a placeholder for your peering
IP once they get those allocated to you.  Certainly not as clean as I can
understand mgmt wanting it, but few seconds of replacing x.x.x.x with might be worth the X dollars you're saving.

On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01 at hotmail.com> wrote:

> We have 4 full-peering providers between two data centers. Our accounting
> people did some shopping and found that there was a competitor who came in
> substantially lower this year and leadership decided to swap our most
> expensive circuit to the new carrier.
> (I don't know what etiquette is, so I won't name the carrier... but it's a
> well-known name)
> Anyways, we were preparing for the circuit cutover and asked for the BGP
> peering info up front like we normally do. This carrier said that they
> don't provide this until the night of the cut. Now, we've done this 5 or 6
> times over the years with all of our other carriers and this is the first
> one to ever do this. We even escalated to our account manager and they
> still won't provide it.
> I know it's not a huge deal, but life is so much easier when you can
> prestage your cut and rollback commands. In fact, our internal Change
> Management process mandates peer review all proposed config changes and now
> we have to explain why some lines say TBD!
> Is this a common SOP nowadays? Anyone care to explain why they wouldn't
> just provide it ahead of time?
> Thanks in advance.