Stop Googling and Start Testing

Here’s a question I got on one of my ancient blog posts:

How many OSPF process ID can be used in a single VRF instance?

Seriously? You have to ask that? OK, maybe the question isn’t as simple as it looks. It could be understood as:

  • Can I have more than one OSPF process in a single VRF instance?
  • Can I have many OSPF processes in a single VRF instance?
  • What is the maximum number of OSPF processes one could have in a VRF instance?
  • What is the maximum number of processes in an instance, and is it a fixed number, or does it depend on the platform?

Before even trying to answer the question, you should ask yourself “what am I doing, and how did I get painted into this particularly scary corner” – most questions like this are a result of a broken design. Even if you get the answer you like, you might be one of the very few people worldwide deploying this particularly crazy idea, so you might hit bugs that nobody ever encountered before. Good luck getting them fixed unless you’re buying millions worth of equipment per quarter ;) Or as Andrius Adamavicius wrote in the comments:

If you tested and it worked this is no way an indication that it is supported.

Read documentation, especially Restrictions and Limitations sections, before putting anything in production deployment. Google is very efficient way to navigate vendors documentation that spans multiple unconnected or unlinked documents. If can't find an answer - open a ticket with your vendor to clarify specify SW/HW combo features/limitations.

The prime abusement is 'ip nat enable' where folks use it as a replacement for 'ip nat inside/outside'. If both are working in the global routing table does not mean that both are supported. So, when something fails in production, after 'about 15 seconds' of testing in the lab, then network redesign might be the only option.

Sometimes when you start considering unusual ideas it’s worth stepping back and figuring out what the original problem was and whether you can solve it in some other way. You can always use ExpertExpress if you need a fresh set of eyes.

Now back to the question itself.

It’s obviously very easy to answer the first question yourself – you spin up a virtual router. If you work with Cisco IOS, and don’t have one on your laptop yet, it’s time to fix that anyway. It took me about 15 seconds to get the answer from my decade-old Cisco 1812: yes, you can have more than one OSPF process per VRF (however, that does NOT mean that it's a good idea and/or supported, see also above).

The second question is also pretty easy to answer – create a very large configuration, download it to the router, and see what happens. You could use something as simple as Notepad, or stop wasting your time with cut-and-paste and use Excel, Perl, Python, Ansible, whatever… Oh, you don’t know how to do it in Ansible? This might help.

The answer to the third question might be ~30 (see this article I wrote in 2009) due to internal IOS architecture, or more. Yet again, it’s easy to test.

If the answer to the third question is way above 30, I don’t think many people know what it depends on, but if you desperately want to know the answer, you should ask your Cisco SE and not a random blogger anyway.

Anyway, what really disappointed me was that whoever asked that question obviously knew what Cisco IOS is, what OSPF is, and what VRF is… and yet he found it more appealing to waste time googling around and asking random people than to check things out (or asking the people who should know – the vendor – if he wanted a definitive answer), and maybe even sharing the results after figuring out what the answer is.

5 comments:

  1. If you tested and it worked this is no way an indication that it is supported.

    Read documentation, especially Restrictions and Limitations sections, before putting anything in production deployment. Google is very efficient way to navigate vendors documentation that spans multiple unconnected or unlinked documents. If can't find an answer - open a ticket with your vendor to clarify specify SW/HW combo features/limitations.

    The prime abusement is 'ip nat enable"; were folks use it as a replacement for 'ip nat inside/outside'. If both are working in the global routing table does not mean that both are supported. So, when something fails in production, after 'about 15 seconds' of testing in the lab, then network redesign might be the only option.
    Replies
    1. Loved your reply so much that I copied it in to the body of the blog post. Hope you don't mind.
    2. A decade ago, I challenged my coworkers to come up with an IOS config for transparent interception, so that HTTP from any source to any destination is "proxied" to one specific host. With IOS, this means applying both client source PAT and server destination NAT (rotary pool) to the same flow, a tricky feat since those functions have inverted ideas about NAT "inside" and "outside". I was expecting a solution that did each NAT function in its own VRF, with inter-VRF traffic being manhandled over a crossover cable.

      But one clever fellow combined "ip nat enable" for the client source PAT and "ip nat inside|outside" for the server destination NAT on the same pair of interfaces. It was an elegant, single hop, single VRF solution that was completely consistent with the NAT order-of-operation and, as far as I'm concerned, is fully supported by TAC!
    3. problem is those vender document, sometime it is just not possible to see the full picture.

      ip nat inside/outside is *THE dumbest idea ios ever had, no matter how many times I read their config guide, I still don't get it, snat/dnat is much easy to understand.
  2. "How many OSPF process ID can be used in a single VRF instance?"
    Sounds like a poorly chosen vendor certification test question...
Add comment
Sidebar