Recently I was contacted by an Internap sales person.
The third line of the email read:
"As you know well, BGP makes all routing decisions simply based on HOP COUNT"
I blinked my eyes a couple of times.. Yes it really said hop count.
Then I replied to the guy that if he tries to sell a technical product
to technical people he should get his info straight.
On that page there is also this gem:
"BGP relies on the premise that hops are responsible for packet loss
and congestion, and therefore a route with fewer hops is inherently
better. "
I can imagine blatant misinformation like this from a shady startup
trying to trick some sales with smoke and mirrors, but from Internap?
Looking at the link referenced below, the route optimization method mentioned appears to be very similar to the old Routescience or Sockeye BGP optimization products.
That's a shame - I had a sales-oriented conversation with a few people from Internap (we are already a customer but this was about other services) and they were very clueful. This was a few months ago (including some discussions about BGP and their optimization products where their technical sales lead was clueful about how it worked and what it did).
Though, Internap had the NOC who replied to a problem report of mine (where even-numbered addresses weren't pingable in our block via Internap; I used <our prefix>.0, a router loopback, as an indication of something unpingable which normally is) with "You should expect <our prefix>.1 to respond to ping and such, but not 2<our prefix>.0 as that is only capable of representing a subnet and not a network interface of any kind, or any machine, at all"
Honestly, though. Can you blame them in this case? Given the lack of insight into your network, I also might question your numbering system (given the number of people who use .0 and .255 in /24 Ethernet segments). Although, there are still perfectly good reasons never to use .0 or .255 in production networks, even if it does work most of the time.
I just finished griping at some vendors for using .0/31 on the first ptp link. Sure, it works, it might always work, but I'll be mighty pissed when I have to renumber core interfaces because some stupid software program freaks about it. I can live with 126 ptp links per /24 in 1918 space of all things.
Yes, it's possibly foolish to allocate x.y.z.0 or .255.
But saying that that x.y.z.0 is *not* *capable* of representing an interface is
demonstrating a dangerous lack of knowledge. There's several totally legal .0
and .255 addresses in each /22 subnet, and yes people *do* use /22 subnets.
Unfortunately, we're still stuck with "Don't use .0 or .255, because there are
*still* people out there who don't understand CIDR and will hassle you about it"...
What really sucks is when the CIDR-challenged people are hassling you indirectly
via the code they write...
Yes, it's possibly foolish to allocate x.y.z.0 or .255. But saying that that x.y.z.0 is *not* *capable* of representing an interface is demonstrating a dangerous lack of knowledge. There's several totally legal .0 and .255 addresses in each /22 subnet, and yes people *do* use /22 subnets. Unfortunately, we're still stuck with "Don't use .0 or .255,
Yeah, I quit using them in '98ish and never bothered trying again. Was annoying the first time I realized the dialup user wasn't working because they had a .0 or .255 address from the pool.
Of course, I've had more calls from people asking why they don't work when they aren't supposed to work.
because there are *still* people out there who don't understand CIDR and will hassle you about it"... What really sucks is when the CIDR-challenged people are hassling you indirectly via the code they write...
Yeah, but at 2-4 addresses per /24, I really can't be bothered to yell at the coders. Easier to just not use them.
Looking at the link referenced below, the route optimization method
mentioned appears to be very similar to the old Routescience or Sockeye
BGP optimization products.
That might have something to do with the fact InterNAP bought both of
them (and the third company in that space).
Errr, I think they mean AS hops, which is actually mostly correct. After
you eliminate things that don't actually convey any information (like
localpref, which you have to configure yourself), and things that don't
provide any meaningful data in a multi-network path selection role (like
MEDs), AS-PATH length is pretty much the only useful basis you have for
picking a best path from your BGP peers. All other marketing crap
asside, they aren't incorrect in pointing out that BGP really sucks as a
way to pick a best path.
That might have something to do with the fact InterNAP bought both of
them (and the third company in that space).
I believe RouteScience was acquired by Avaya in 2004. Did Internap acquire the IP after the fact?
Correct on RouteScience going to Lucent/Avaya. InterNAP bought NetVMG and
Sockeye in 2003. Proficient Networks merged with IP Deliver forming
Infiniroute in 2004.
A decade ago, I recall allocating a /23 to a dialup pool and getting calls
from customers who landed on .0 and .255 because they were unable to reach
random sites. It should be legal, but doesn't always work. I assumed this
was still the case.
Several months ago, I fired up a permanent aws ec2 instance with a static
IP. To my surprise, they allocated me a .0 address. I haven't noticed any
issues with it at all. But I figure if Amazon is using .0 as a normal part
of their deployments, their scale is so high that if it didn't work reliably
you'd think they would have noticed by now. I don't know if they also use
.255.
