Two vendors, two OSPFs. Does this come as a surprise to you? No? Welcome to the club.

I was neglecting this blog for a while, more than 2 years actually. Well, things changed in my personal life, but this is out of scope for this whiteboard. Let me stick to networking stuff here.

I worked for an ISP as a network engineer for many years. I thought I knew so much about the protocols
— the networking fundamentals. Now I know I was just a network operator who was told how things should work. I was following the instructions, never doubting they were wrong or, at least, not the only way to go. Workshops, trainings, testing in LABs with a vendor equipment…, these thing make you a perfect engineer but they are not an eye opener. Yes, I now that MTU must match for OSPF, I know that nonzero OSPF area must be connected with a backbone…, I now many these things and for many I also know the reason behind it (yes, I have read the RFCs). But I’ve never questioned that, saying to myself, “it was designed that way.”

Moving to a design verification team of a vendor, where my daily job is to make sure that things work as designed, put me to another stand point. It is not about looking for bugs and bad implementation, it is about looking deeply into networking fundamentals and understanding the solutions. And there are many. People think their own ways and you can’t say they are wrong. Well, some solutions work better than others, some are more robust and less prone to errors and, yes, some are bad. But — there are many ways :-).


I’m currently looking into OSPF implementations from a few vendors and I might report some findings here. You might be surprised that some details in OSPF can be understood in different ways by different vendors. Or not?