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.
CWB
Carrier saves costs by not having a clue, and has no idea which router
will have an open port until they try to plug you in.
Hope its not a long contract, because customer service never gets better ... only worse.
"This carrier said that they don't provide this until the night of the
cut." / "Is this a common SOP nowadays?" - Not in our experience.
I’d be concerned. IMHO, it’s not normal to withhold such information. Doing so suggests that they are disorganized at best.
When we sign a BGP customer, we collect their ASN and the networks they want to advertise up front. With that information, we complete a network setup document that is forwarded to the customer. The document contains all of the information they provided, the transit network(s) we’ve assigned, and port info. This is done weeks/months before turn-up.
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.
That's the first mistake. Internet w/ BGP is not a mass-market
service. Accounting people have no business searching out highly
technical custom products and services. Custom services are highly
variable in terms of what the service actually delivers. Accounting
people are not at all equipped to evaluate them.
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.
It's not unusual for smaller providers who do less BGP to have the
engineer work with the customer on the phone to turn up the session
without collecting or preparing a bunch of documentation ahead of
time. This can be a good thing or a bad thing. They'll have more
outages but if they're willing to reprogram routers on the fly they
may also be more responsive when you have a problem. And they mayy be
more willing to customize your configuration.
Regards,
Bill Herrin
* William Herrin:
I know of 2 larger providers that have strange provisioning processes.
Both of them do layer 0/line testing and then their bgp group gets the
order to finish the routing. It's not that they are withholding the
info, they haven't done the bgp policy yet and it happens during turnup
testing.
But the data is fairly standard, what were you missing that wasn't on the
tech/bgp form you fill out at the start of setup?
Bryan Socha
Network Engineer
DigitalOcean
Sounds like you need a little posturing with your sales team and account manager on the phone. Threaten to cancel the contract and site their lack of support and willingness to help you be successful. Say they're interfering with your company's ability to do business. If their sales team is worth anything they'll jump all over trying to fix the problem. If not, cancel the contract and move on. Do you and your company's mgmt want to deal with someone that unhelpful? Imagine what happens when you have a problem..
Ian Mock
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.
CWB
My question to the OP would be why didn’t you schedule the turndown of the old circuit to overlap with the turnup of the new circuit? That way you could perform your cut independently of turn-up testing with your new provider. Why is it that you MUST perform both activities on the same night? You can always turn up a circuit, make sure it works and then turn it back down on your end until you’re actually ready to use it.
I agree with Sean. Poor planning always leads to poor service.
It sure makes for a fast clumsy cut over. But, you now know that you the
customer are not a priority or better planning steps would have been taken
for your consideration in advance.
Thank You
Bob Evans
CTO
I was wondering the same. Most likely because it's accounting that's making the decision and they don't want to spend a penny more than they have to$
Regards,
Dovid
Sender: "NANOG" <nanog-bounces@nanog.org>Date: Thu, 21 Jan 2016 18:35:05
I have not been following this thread closely, but I'll bet I klnow why the new vendor is cheaper.
I have this theory that says accounting may not be the best place for technical OR engineering decision making (it destroyed the company I worked for for many years).
My theory (see the scientific usage of the word) is that "cheapest" is rarely "best" in any dimension INCLUDING "total cost".
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
1.2.3.4 might be worth the X dollars you're saving.
They probably make it up as they go along during the turn-up.
Owen
Oh, we don't. Typically when we turn up a new circuit, the old is left in place for 2 weeks in case we need to roll back. This is simply a matter of them giving us their peering info ahead of time so that we can prestage the configs. Someone else responded that there are probably two teams involved on the carrier's side (and I'm guessing some automated systems?) which may explain some of this, but I can't understand why they couldn't just punch in the info earlier than the night of the change. These guys are not a small carrier.
Anyways, it's just an inconvenience and it struck me as odd, so I thought I'd ask if this is normal or not. Thanks for the feedback everyone.