VN macro segmentation for regulated industry

[techno.it]

Hey everyone,

We’re setting up Cisco SD-Access for a regulated HIPAA compliant environment and need some advice on VRF segmentation and security setup.

We're using a firewall as the fusion device. Same firewall controls access to data center servers (east-west in DC and north-south) and shared services and internet edge.

We plan to create separate VRFs in the SD-Access fabric to keep various segments isolated and compliant (macrosegmentation). Here’s what we’re considering.

• Corporate Users ( 1 VRF include all IDFs - e.g. IDF VRF)
• Critical Users ( e.g. Finance VRF, IT VRF)
• Guest
• CCTV
• Door Access Control
• Building Management System
• HVAC
• IoT VRF ( seperate VRF each IoT systems
• Vendor Medical Devices VRF ( seperate VRF for each vendor)

Any device in VRF needing to communicate with data center servers or access internet will pass through the firewall, ensuring policy enforcement. We’ll also control any inter-VN communication through the firewall.

Thanks in advance. Any advice would be appreciated!

Is it okay to create this many VRFs ( approx 20+) in SD-Access for macro segmentation?

We do also have Cisco ISE in this deployment. We know SGT is meant to be used for lateral control within same VRF not in North-South communication, therefore in our case Firewall is best use case.

[jedolphi · Accepted solution]

Hi! Sounds like a good project. A few dot points for your consideration.

• The largest SDA Fabric Site I've seen has around 90 Layer 3 Virtual Networks (L3VN). You need to make sure the Edge Nodes can accomodate this scale, check the Catalyast Center Data sheet, for example 9200L support only one L3VN.
• Running a large number of L3VNs does increase the administrative burden of the network admin e.g. more BGP peerings between BNs and fusion, more fusion routing configuration, more L3VNs in CatC, etc. This is not wrong, it's just something to be aware of. If the customer truely needs about 20x L3VN then that's fine, but if can be reduced into say 10 (or whatever) then that usually works out a bit easier in the long run. TLDR, keep it to a sensible minimum.
• SGTs can be used for inter-VRF policy if you need. You need to switch on SGT propagation on the BNs towards fusion, and the fusion needs to send SGT back (some non-Cisco fusion devices might drop SGT). But, FW has substantially more policy capabilities compared to SGACL on a switch e.g. FW has application inpsection, stateful awareness, IPS/IDS, guaranteed packet logging, etc.

Best regards, Jerome

[Andrii Oliinyk]

well... as u already got yourself into SDA be highly encouraged to contract PSO to design & implement your deployment.
~20 VRF is not an issue for SDA. rather if will take significant efforts with design in general & manual configuration on the FW side. 
 

[techno.it]

Thank you @jedolphi  @Andrii Oliinyk for insights

Would like to know if it’s possible to control traffic between two VLANs within the same VRF using  SGTs

 If SGT can indeed handle this requirement 

reduce the number of VRFs in our network as much as possible. 

[Andrii Oliinyk]

"if it’s possible to control traffic between two VLANs within the same VRF using  SGTs"
it's active by design within same VRF until packet leaves Fabric. It's also available with Extranet afaik.

[techno.it]

Just for more understanding, Can SGT block the communication between two IP address pools within same VRF?

[Andrii Oliinyk · Accepted solution]

it's one of their use-cases. but if target scenario  is to block access between subnets implementation wont be straightforward bc for the intra-VRF traffic u'll need the scalable & supported way to map IP-subnet to SGT. If subnets are mapped 1-to-1 to VLANs u could configure mapping VLAN-to-SGT on edge nodes but i dont remember if there is an option to automate it with DNAC.
alternatively if u relax requirement from "between IP-pools", u just assign SGTs per port or per AAA session (MAC-granularity) & this is recommended & easy approach.

[jedolphi · Accepted solution]

---

@techno.it wrote:

Just for more understanding, Can SGT block the communication between two IP address pools within same VRF?

---

Yes. Can block between devices in same VLAN, or between two devices in different subnets of same VRF, or between devices in different VRFs. For devices in different VRFs you'll need to design and configure for data plane SGT propagation from BN to fusion. I cover all these use cases in BRKENS-2819 if you would like to review it. Best regards, Jerome

[techno.it]

So just for more clarification, for instance, I can tag the devices on VLAN 10  “SGT 10” and VLAN 20 devices as “SGT 20 within same VN and apply deny.

But lets say I want to give exception to group of hosts in VLAN 10 and VLAN 20 to allow to communicate.

How would that be achieved?

[Andrii Oliinyk]

then your SGT development approach must be more sophisticated & potentially u'd mark hosts of interest with new SGTs to define for them different policies of communication.

[Andrii Oliinyk]

with Extranet fabric traffic may not leave BNs, doesnt it? i'd expect SGT to be propagated in VXLAN would be enough, wouldnt it?