Month: February 2012

Zero Trust Network Architecture – ZTNA

I recently attended a one-day data center summit.  Interesting items and topics discussed throughout by everyone.  The opening speaker was John Kindervag of Forrester.  He advocated the concept of Zero Trust Network Architecture (ZTNA).

I walked away from the summit thinking about the concept of Zero Trust Network Architecture (ZTNA).  I find it to be a complete shift from the traditional perimeter security approach – which John Kindervar characterized as “trust” and “untrust”.

One of the first concepts I was exposed to in network security upon entering the networking field was that of “trust” and “untrust”.   ZTNA does away with this traditional thinking.  Given the presentation in the conference from John Kindervag and the security events that are publicly known from 2011, it stands strong reason for ZTNA to become discussed and considered.

According to John Kindervar there are already organizations adopting ZTNA.

Based on what I heard in the conference ZTNA will impact the way network architects/engineers and security engineers go about building and securing networks.  John Kindervar advocated that ZTNA architecture is comprised of what is termed a Micro Core and Perimeter (MCAP).  I like to think of it as a zone or container.

From what I heard an MCAP is scalable, centrally managed, share similar functionality global policy with other MCAPs, all traffic to/from an MCAP is inspected and logged and secures VMs by default.

For me moving forward there is much more to learn and understand overall about ZTNA conceptually and practically.

Palo Alto Networks and Brocade sponsored the one-day data center summit.

Is it RIB or FIB capacity?

When reading or hearing about IP route capacity of routing gear it is often stated that a piece of equipment will support x-number of routes.  This number is a large number typically – and can sound impressive.

So if you hear or read of one capacity number mentioned keep in mind there is more than one capacity number to know.  RIB (or routing table) and FIB (or forwarding table) are two different tables within an IP networking platform.  They share common information, like routes, but perform two distinctly different purposes.  They also each have a different degree of resource capacity to perform their respective roles.

Technically RIB is an acronym for Routing Information Base and FIB is an acronym for Forwarding Information Base.  A RIB is the same thing as a routing-table.  A FIB is the same thing as a forwarding-table.

The RIB stores all routing input collected from routing protocols and holds that information for processing by the routing protocol(s).  Once a routing protocol has preformed it’s analysis on the RIB it determines what within the RIB should belong in the FIB.  If it sounds like I’m over simplifying the process, I am.  There are many different routing protocols (distance vector, link state).  Each of the routing protocols will employ an algorithm(s) to invoke functions and achieve its purpose.

The details of the routing protocols and methods they use are unimportant for making this simple point of awareness – there is more than one performance number to know when it comes to the number of routes a router can process.

Beyond the how many routes question it’s worth mentioning that performance is a broad discussion that includes several topics.  Vendors implement different hardware architectures to achieve several objectives like, performance, redundancy, capacity, services, green/environmental-initiative etc..  For example on higher-end gear it is standard to find a distributed hardware architecture whereby the FIB is located on the physical line cards.  So if you have a chassis with eight slots, there would be 8 FIBs, one FIB per slot.  Keep in mind I’m over simplifying it and skipping a lot of detail – some of which I probably can’t explain anyway.

Other performance metrics include knowing how well a vendor’s operating system and hardware ASICs perform at processing IP flows.  The overall point of awareness here is that simply reading a vendor’s datasheet should be a starting point for conversation(s) and not considered the end-all-be-all to make purchase recommendations and/or decisions.

If you’ve heard the terminology, “marketing math” then you know that datasheets can mislead.