Design Approach
|
Pros
|
Cons
|
Firewall-based segmentation
|
This is common in data centers, not so much in campuses.
|
Firewall routing is limited in capability.
Firewalls can become traffic bottlenecks.
Generally ends up being somewhat clumsy, not agile.
|
Central interconnect or core with firewall pairs guarding compartments or zones
|
|
For zone A to talk to B, two pairs of firewalls need to be configured. This scales very poorly.
|
Firewall pair with compartments as zones off the firewalls
|
All the rules are in one firewall pair.
|
You still have to write two sets of ingress rules for A to B.
All the rules are in one firewall pair.
Doesn’t scale (scale up not out).
|
Multiple firewall pairs randomly interconnecting security zones
|
|
Routing could get really messy.
Avoiding asymmetric flows?
Operations, troubleshooting ugly.
Hierarchical designs are generally highly advisable — random meshes not.
|
Network virtualization and segmentation
|
|
Complexity
|
VLANs as segmentation
|
Simple
|
Large scale VLANs not a good idea.
|
VLANs + VRFs and VRF Lite/EVN as segmentation
|
This can work; I have done it at 100+ building hospital and medium-sized government agency scale.
Simple, low-tech for operations
|
Not elegant.
Adding a segment/zone is painful.
|
That plus central MPLS
|
Makes the core more scalable, which in turn simplifies overall scaling
|
Cost for MPLS capability (devices supporting it, licensing).
Increased tech complexity (MPLS VPNs).
|
MPLS-centric campus (e.g. down to access layer using 3850 switches)
|
Scalable, elegant.
|
Cost for MPLS capability.
Increased tech complexity (MPLS VPNs).
|
Campus Fabric: ISE + VLAN/VRF/VXLAN, omitting LISP
|
If you have a need to extend L2, VXLAN is the way to go. We’re doing it in some datacenters, with BPG (EVPN). It is, in effect, the new FabricPath.
|
Why would one want to extend L2? VoIP mobility without central CAPWAP and avoiding re-DHCP comes to mind.
The DNA Campus Fabric (SD-Access) solution requires LISP.
|
(New) Cisco DNA Campus Fabric: ISE + VLAN/VRF/VXLAN + LISP
|
(See above)
|
(See above)
Increased complexity due to LISP. (I’m not a fan!)
LISP is apparently in there for mobility support; I’m not convinced it is needed unless you’re talking mobility across normal L3 routing boundaries — use cases?
|
ISE-centric segmentation
|
Provides useful security insights into devices, locations, contexts.
Doesn’t create “hard boundaries” between user or server groups.
Does allow control via PEPs.
|
Device support in general (SGTs, PEPs).
Doesn’t create “hard boundaries” between user or server groups — that’s not helpful if you need to keep different types of users segmented from each other.
Some requirements might need overly many PEPs.
SXP scaling limitations.
|