Tales from the Machine Room
Long time ago, so fucking long that my head spins if I try to think about it, networking didn't existed.
Yes, I know, it sounds kinda impossible nowaday, when even your TOASTER is network-connected and spit out the weather forecast or something on each piece of bread you put in it. But yeah.
Then, the great revolution started! Tcp/Ip was at the door. And at the windows. And it came out of the fucking walls too.
So I did what every sensible persons that aspired to be a "professional" should do: I bought a trackload of books from O'Reilly and the like and studied like a frenzied squirrel. The result of so much brain activity was that the fog that was occluding my mind cleared and I began to be a bit more familiar with waaaay too many things that went into something apparently so simple.
Now, that was, as I said, long ago.
Today we have networking coming out of our ears. And "the 'net" is integral part of almost everybody life.
You can't swing a dead cat without hitting some "app developer" that live and breath 'net and
However, I'm regularly presented with members of the "net" generation that don't know even the basic information about networking and how things works in reality. Stuff that anyone that is supposed to work as a "pro" in the field should know even before turning on his first mobile phone.
And now a bit of background information so you can understand what am I going to talk about.
One of our customers, let's call him $BigAndFamous, wanted to host some application on Azure cloud. Why Azure? Fuck if I know. Why we (that have our OWN cloud and were very good at managing it) are supposed to manage their Azure bits? Again, fuck if I know. One theory is that 'everything that looks like money is good for us'. The other theory is that it was all an elaborate tactic to push as many people as possible out of the door.
Anyhow, the problem was that they wanted to have the bits hosted in Azure to talk to some bits hosted somewhere else. Not in their internal (corporate) network, a colo somewhere.
Well, is a matter of establishing a VPN between the 2 environments (note: establishing a vpn in Azure require a simple "gateway" if you want IPSec, if you want PPTP you need a specific "pptp server" that you have to pay separately) and then establishing routing and firewalling between the two ends once the vpn is up & running. Not really rocket science.
So we configure the vpn gateway in Azure and then send the details to $BigAndFamous.
After a few days we receive a message that says, more or less, this doesn't comply with our internal policy so we cannot accept it. Well, tough luck jackass, 'cause that are the specific of Azure, that were clearly stated when you started talking about Azure. At least, *I* put these into my e-mail, after that, I've no idea what our Marketing Man discussed with you.
Anyhow, after a number of mails, counter-mails, conference calls etc., all of them could be summarized as "these are the specific of Azure - but they are against our policy - tell that to Azure - can you change them? - Nopes", they apparently got the message, and a rainy morning we got the VPN enabled.
Problem was that the vpn was active, but no traffic was going around because the firewall on their side was still closed.
Now, I must stress this point: Azure was THEIR stuff, we "managed" it, but it was entirely paid by them. The CoLo where the other bits were hosted was ALSO THEIR STUFF. We didn't even managed it because was fully managed by the colo partner. Basically what we had ZERO control or connection with that stuff, the only thing we could do was to tell THEM to request to the colo people to do stuff. And that was it.
Ok, is a matter of telling them to allow traffic from Network-Segment-Of-Azure to Netork-Segment-Of-OtherPlace.
So I prepare anothe mail that basically sais "allow traffic from 192.168.168.0/24 to 192.168.99.0/24 for ports..." and fire it off.
It turns out that, while we were waiting for them to grudgingly accept Azure's "unreasonable" requests, they changed their policy (again), so now we need to create a 'ticket' in their ticketing system. Ticketing system that was probably designed by a schizofrenic paranoid locked into a toilet, that then tossed the design in the nearby stall and it was picked up by a logorroic web developer during a particularly productive... hemmm... session...
The result is a nightmare of "entry form" that needs to be filled up, and then re-filled once half of the controls gets auto-updated by the information that you entered LATER... Yes, it is as bad as it sounds.
Anyhow, after puzzling a while with the form, I send out the request.
Note: most of the time I work on the assumption (very naive from my part, I admit) that the first-line-supporter that receive a "firewall change" request, should either be competent enough to understand the request or escalate it to the 2nd or 3rd tier.
For this reason I don't overexplain things and 'allow traffic from network X to network Y' was basically the whole content of the ticket.
As you can imagine, we didn't heard anything about it for a few weeks, when we received a call from $BigAndFamous with a request of 'what the fuck' about their request. The reply that "it's on YOUR side" wasn't appreciated.
It turned out that the ticket was looked up by a couple of guys that were really confused by it and decided that "somebody else" should look at it.
Now, that is basically the same identical strategy that several of my collegues were using when dealing with any kind of ticket when they were on the rooster, so I shouldn't be too surprised but... After a couple of request to know what exactly was confusing about it, we got the following responses:
No it is not, you jackass, the connection goes from Azure to a different colo and it goes through you only because it's YOUR fucking co-lo, not ours. It doesn't even touches your internal network
No is not, you imbecil. One network is in Azure, the other one is in your CoLo and the vpn is doing all the connections on its own.
It's not your fucking internal network, you pinhead, it's YOUR application in Azure talking to some other stuff made by your monkeys and hosted somewhere else.
Wake up moron! It's TWO different network in TWO different places talking through a vpn you already activated.
....ARE YOU FUCKING KIDDING ME??
After several days of discussions, finally dawned on them that they were talking generally bullshit, and all they had to do was to take may mail, and forward it to their colo support person. And when that was done, the whole "issue" simply disappeared.
I'm not sure if this is a case of way too many layer of management, or way too many dumbasses in the pool.
Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
Non sono sicuro se tutto questo casino sia stato a causa di troppi "livelli" di management o di un eccesso di dementi nella mischia. O forse entrambi.
By Guido - posted 11/07/2017 09:59
Questa e' una delle storie piu' belle degli ultimi tempi.
who uses Debian learns Debian but who uses Slackware learns Linux
By Cobra78 - posted 11/07/2017 10:00
Questo mi ricorda quando invia ad un cliente l'ip esterno da aprire per far parlare la nostra applicazione con la loro, e visto che era un xxx.xxx.xxx.255 lui mi rispose tutto fiero "Ma non può essere, questo è un indirizzo di Broadcast", e divenne molto meno fiero quando gli risposi "Si, se si parlasse di una /24, ma noi abbiamo una /21", e no, non era il broadcast della /21
Prendi la vita al minuto, non all'ingrosso.
Sogna come se dovessi vivere per sempre; vivi come se dovessi morire
By YAST (Yet Another Anonimous Coward) - posted 11/07/2017 17:35
Assolutamente entrambe le cose.
E aggiungiamoci anche una sprizzata di "ma che roba l'è il tcp/ip ?" per buon peso ...
YAST (Yet Another Anonimous Coward)
By Boso - posted 13/07/2017 15:14
"Eccesso di dementi nella mischia" e' diventata la causa problema numero 1 nella chiusura dei miei interventi!
E questi quanto vi pagano per fare, di fatto, i passacarte? O Passamail se vogliamo...
By L'ennesimo codardo anonimo - posted 17/07/2017 10:04
Troppi livelli di mannaggiament dementi.
L'ennesimo codardo anonimo
This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.
This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.
This site isn't optimized for vision with any specific browser, nor
it requires special fonts or resolution.
You're free to see it as you wish.