Is it normal for your provider to withhold BGP peering info until the night of the cut?
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
On Thu, 21 Jan 2016, c b wrote:
Is this a common SOP nowadays? Anyone care to explain why they wouldn't just provide it ahead of time?
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.
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
On Thu, 21 Jan 2016, c b wrote:
Is this a common SOP nowadays? Anyone care to explain why they wouldn't just provide it ahead of time?
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. On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01@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. CWB
On 1/21/2016 15:33, Kraig Beahn wrote:
"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.
On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01@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. CWB
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". -- sed quis custodiet ipsos custodes? (Juvenal)
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. On 1/21/16, 2:26 PM, "NANOG on behalf of c b" <nanog-bounces@nanog.org on behalf of bz_siege_01@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. CWB
On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01@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.
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 ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
* William Herrin:
On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01@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.
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.
I guess that's why so many customers keep paying for circuits that have long been shut down. :)
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 On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01@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. CWB
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 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of c b Sent: Thursday, January 21, 2016 3:27 PM To: nanog@nanog.org Subject: Is it normal for your provider to withhold BGP peering info until the night of the cut? 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
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 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 -----Original Message----- From: Daniel Corbe <dcorbe@hammerfiber.com> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Thu, 21 Jan 2016 18:35:05 To: Ian Mock<ianm@fairwaymc.com> Cc: nanog@nanog.org<nanog@nanog.org> Subject: Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?
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.
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.
Subject: Re: Is it normal for your provider to withhold BGP peering info until the night of the cut? From: dcorbe@hammerfiber.com Date: Thu, 21 Jan 2016 18:35:05 -0500 CC: bz_siege_01@hotmail.com; nanog@nanog.org To: ianm@fairwaymc.com
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.
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. On Thu, Jan 21, 2016 at 4:26 PM, c b <bz_siege_01@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. CWB
On Jan 21, 2016, at 1:26 PM, c b <bz_siege_01@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. CWB
They probably make it up as they go along during the turn-up. Owen
participants (14)
-
Bob Evans -
Bryan Socha -
c b -
Daniel Corbe -
Dovid Bender -
Eric Sieg -
Florian Weimer -
Ian Mock -
Kraig Beahn -
Larry Sheldon -
Owen DeLong -
Sean -
Sean Donelan -
William Herrin