cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8837
Views
5
Helpful
9
Replies

With SDA, relationship between VN and subnet?

m1xed0s
Spotlight
Spotlight

I am learning SDA currently but I am a little bit confused for the relationship with VN and Subnet...

 

For example, I am going to do four VNs: Corp, Contractor, WiFi and Guest-WiFi. The ISE integrated with AD will group user devices into either VN based on the user login. So when I create the VNs in DNAC, I will select the ISE group tags accordingly. However the confusion comes when I associate the IP Pool or subnet with each VN.

 

Should I create four pools 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 and 192.168.40.0/24 for VNs respectively OR should I do two big pools 192.168.0.0/17 and 192.168.128.0/17 for the Corp/Contractor/WiFi and Guest-WiFi VNs respectively?

 

The other thing is if it is recommended to do one big subnet/pool for multiple VNs, then how will the IP address be associated with VRF? Each VN is essentially a VRF in SDA, right? So will multiple VRFs share one subnet/pool? If true, then I am lost on how to configure the fusion router...Or I completely misunderstood some concept here...

 

Please help!

 

4 Accepted Solutions

Accepted Solutions

jedolphi
Cisco Employee
Cisco Employee

Hello,

At an Cisco SD-Access fabric site an IP pool can exist in only one VN. If you need 4x VNs then you need 4x IP Pools at the fabric site. This can be accomplished a few different ways. Typically:

1-In DNA Centre > DESIGN > Network Settings > IP Address pools, at global level, you can create large pools e.g. /16s

2-In DNA Centre > DESIGN > Network Settings > IP Address pools, at fabric site level, you reserve portions of the large pools for use in VNs

Here's a screen grab from the lab,

Global level (/16s):

image.png

Site level (sub-pools of the global /16s):

image.png

These fabric site level sub-pools can then be selected in host onboarding screen for use in a VN. So in this example I would put 10.4.3.0/24 in the 'CORP' VN and 10.3.3.0/24 in the 'IOT' VN.

At global level in the screen grab I have two /16s, one for CORP and a second for IOT. It would also be fine to have a /16 at global level and break it down into mulitple sub-pools at fabric site level. Eg, global pool 10.0.0.0/16. Site level 10.0.0.0/21 for CORP and 10.0.8.0/21 for IOT.

Please review the latest version of the Software-Defined Access Deployment Guide which explains IP pools further:

https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-campus/design-guide-listing.html?dtid=osscdc000283

Cheers, Jerome

View solution in original post

Mike.Cifelli
VIP Alumni
VIP Alumni
Here are my opinions on your questions:

Should I create four pools 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 and 192.168.40.0/24 for VNs respectively OR should I do two big pools 192.168.0.0/17 and 192.168.128.0/17 for the Corp/Contractor/WiFi and Guest-WiFi VNs respectively?
@jedolphi hit on the VN & IP pool creation/assignment.

The other thing is if it is recommended to do one big subnet/pool for multiple VNs, then how will the IP address be associated with VRF? Each VN is essentially a VRF in SDA, right? So will multiple VRFs share one subnet/pool? If true, then I am lost on how to configure the fusion router...Or I completely misunderstood some concept here...
A virtual network is essentially the same thing as a VRF. A logically separated routing instance that, as of now, can only get to another VN via the fusion router. I believe that it has been road mapped to allow your EBN to act as a fusion eventually down the road, which basically eliminates the need for a fusion device in your SDA fabric. Multiple VNs will not share one ip pool. Keep this in mind, for a VN, you can have one to many ip pools inside of it, and each ip pool can be assigned an SGT to control east-west traffic between the pools. What you should consider is whether or not your ip pools will ever need to talk to each other. If they do and you do not want to leak between the VNs at the fusion you could always put 2,3, or all 4 into one VN and control via SGTs and SGACLs. Then on the flip side if the requirement is to keep them separated then maybe separate VNs is what you need. The way I look at it is, do you want most of your stuff to have to hit the fusion to leak over, which means more admin work there, or do you want to rely on trustsec with SGTs and policy assignment via ISE and manage restrictions that way. I think the design depends on what exactly the requirements are.

HTH!

View solution in original post

When considering Guest Design for wireless , the integration with Fabric offers two different solutions:

  1. Enterprise and Guest traffic sharing the same Border and Control Plane nodes
  2. Guest Traffic terminated on a Dedicated Guest Border and prefixes registered on a dedicated Control Plane Node.

For your scenario, Option1 is preferable for simplicity and using exiting devices Fabric devices.

Your Guest will be a dedicated VN. For the rest you can have phone and Corp SSID in single VN.

 

View solution in original post

Mike has put a correct perspective on design choice ,depending on the requirement.

If you want to communicate any time between two Groups, then better to put them in single VN and segment them by using SGT/SGACL.

That way you do not need to do any leaking at fusion and you can avoid the extra manual config at fusion.

View solution in original post

9 Replies 9

jedolphi
Cisco Employee
Cisco Employee

Hello,

At an Cisco SD-Access fabric site an IP pool can exist in only one VN. If you need 4x VNs then you need 4x IP Pools at the fabric site. This can be accomplished a few different ways. Typically:

1-In DNA Centre > DESIGN > Network Settings > IP Address pools, at global level, you can create large pools e.g. /16s

2-In DNA Centre > DESIGN > Network Settings > IP Address pools, at fabric site level, you reserve portions of the large pools for use in VNs

Here's a screen grab from the lab,

Global level (/16s):

image.png

Site level (sub-pools of the global /16s):

image.png

These fabric site level sub-pools can then be selected in host onboarding screen for use in a VN. So in this example I would put 10.4.3.0/24 in the 'CORP' VN and 10.3.3.0/24 in the 'IOT' VN.

At global level in the screen grab I have two /16s, one for CORP and a second for IOT. It would also be fine to have a /16 at global level and break it down into mulitple sub-pools at fabric site level. Eg, global pool 10.0.0.0/16. Site level 10.0.0.0/21 for CORP and 10.0.8.0/21 for IOT.

Please review the latest version of the Software-Defined Access Deployment Guide which explains IP pools further:

https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-campus/design-guide-listing.html?dtid=osscdc000283

Cheers, Jerome

Thanks for the information.

 

A quick follow-up question, what you described is making sense for wired connection. What about WIFI? Say I have three SSIDs: Corp, Phone and Guest. The Guest will be a dedicated VN and has a dedicate subnet/pool. Should I do one VN for the Corp and Phone SSIDs OR two VNs?

When considering Guest Design for wireless , the integration with Fabric offers two different solutions:

  1. Enterprise and Guest traffic sharing the same Border and Control Plane nodes
  2. Guest Traffic terminated on a Dedicated Guest Border and prefixes registered on a dedicated Control Plane Node.

For your scenario, Option1 is preferable for simplicity and using exiting devices Fabric devices.

Your Guest will be a dedicated VN. For the rest you can have phone and Corp SSID in single VN.

 

Attached diagram to add clarity, you can do coarse level segmentation by statically mapping the IP pool/subnet to SGT using DNAC and ISE or you could do further granular segmentation. Using ISE, you could dynamically assign two hosts on a given IP pool two different SGTs and give differentiated controlled access to network resources.

Mike.Cifelli
VIP Alumni
VIP Alumni
Here are my opinions on your questions:

Should I create four pools 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 and 192.168.40.0/24 for VNs respectively OR should I do two big pools 192.168.0.0/17 and 192.168.128.0/17 for the Corp/Contractor/WiFi and Guest-WiFi VNs respectively?
@jedolphi hit on the VN & IP pool creation/assignment.

The other thing is if it is recommended to do one big subnet/pool for multiple VNs, then how will the IP address be associated with VRF? Each VN is essentially a VRF in SDA, right? So will multiple VRFs share one subnet/pool? If true, then I am lost on how to configure the fusion router...Or I completely misunderstood some concept here...
A virtual network is essentially the same thing as a VRF. A logically separated routing instance that, as of now, can only get to another VN via the fusion router. I believe that it has been road mapped to allow your EBN to act as a fusion eventually down the road, which basically eliminates the need for a fusion device in your SDA fabric. Multiple VNs will not share one ip pool. Keep this in mind, for a VN, you can have one to many ip pools inside of it, and each ip pool can be assigned an SGT to control east-west traffic between the pools. What you should consider is whether or not your ip pools will ever need to talk to each other. If they do and you do not want to leak between the VNs at the fusion you could always put 2,3, or all 4 into one VN and control via SGTs and SGACLs. Then on the flip side if the requirement is to keep them separated then maybe separate VNs is what you need. The way I look at it is, do you want most of your stuff to have to hit the fusion to leak over, which means more admin work there, or do you want to rely on trustsec with SGTs and policy assignment via ISE and manage restrictions that way. I think the design depends on what exactly the requirements are.

HTH!

Mike has put a correct perspective on design choice ,depending on the requirement.

If you want to communicate any time between two Groups, then better to put them in single VN and segment them by using SGT/SGACL.

That way you do not need to do any leaking at fusion and you can avoid the extra manual config at fusion.

Cool, Love this community !!!


@Mike.Cifelli wrote:
....
What you should consider is whether or not your ip pools will ever need to talk to each other. If they do and you do not want to leak between the VNs at the fusion you could always put 2,3, or all 4 into one VN and control via SGTs and SGACLs. Then on the flip side if the requirement is to keep them separated then maybe separate VNs is what you need.
....

Perfect! I think this is what I missed and got myself confused! Thanks!

Thank you for this explanation (in regards to the ability to assign multiple IP pools into a single VRF). This seems like it will make our deployment much simpler.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: