Subnets at Edge or Core when utilising NAC

  • 0
  • 2
  • Question
  • Updated 7 months ago
  • Answered
Hi,

Have a network design question.... I’m often being directed to follow traditional networking design approaches, one of which is always creating VLANs on the core rather that steering more to moving them to the edge and using a layer 3 approach, especially when wanting to use NAC in a particular way. There are going to be reasons for either or, but my focus is on using layer 3 at the edge for the use of NAC for a specific end goal.

My view is that in the past switches where less capable, but now this really isn’t so much of a concern, so possibly pushing layer 3 to edge for the specific use of NAC makes better sense, perhaps even to do as the norm?

Often one of the end sight goals is to have NAC dynamically assign a user to their respective VLAN wherever they may connect on the network. 

Using the approach of creating all the subnets on the core means you equally have a different VLAN ID’s for each of the /24 subnets that might exist at the edge. This means to reach that final goal the rule engine in NAC could end up getting pretty big and arguably messy i.e. the rules might be for a data subnet, to assign the HR department profile based on where they connect in the network as such:

• If connecting from location A then contain to VLAN 10, HR AD User, assign profile HR
• If connecting from location B then contain to VLAN 22, HR AD User, assign profile HR
• If connecting from location C then contain to VLAN 33, HR AD User, assign profile HR

Now if you push layer 3 out to the edge then the data VLAN, a self-contained /24 subnet, each could then have the same VLAN ID, say 100 for all Data subnets throughout the network. Now the three rules could be replaced with one:

• If HR AD User, contain to VLAN 100, HR AD User, assign profile HR

So progressively, especially with a lot of switches this becomes very much simpler.

My question is, would in this example moving layer 3 to the edge make most sense or is there a better way to simplify the rules in the previous approach?

Many thanks in advance.
Photo of Martin Flammia

Martin Flammia

  • 6,210 Points 5k badge 2x thumb

Posted 7 months ago

  • 0
  • 2
Photo of Volker Kull

Volker Kull

  • 1,830 Points 1k badge 2x thumb
Hi !

You can do both !
If you have geographic based vlans (cabinet, floor, building - or regional sites !) you can use "policy VLAN islands" to handle this in a single NAC rule.

We do that for years and it works fine if you are taking care about some requirements and limits ...

br
Volker
Photo of Volker Kull

Volker Kull

  • 1,830 Points 1k badge 2x thumb
Additionally:
You can handle different VLANs on different switches for the same function (guest, internal, HR, ...) with policy VLAN islands.
The nac rule is VLAN=HR and not VLAN=100. So the VLAN islands list handle the matching about function (HR) to VLAN-ID.

Volker
Photo of Martin Flammia

Martin Flammia

  • 6,210 Points 5k badge 2x thumb
Hi Volker,

Thanks for posting.

OK, that's interesting. So I have configured VLAN islands, to say group all 'Data', or 'Voice' VLANs and was aware that I could apply a common policy for the common entity but not that it would automatically assign the correct VLAN.

If it can then that's assume!

Will give that a go, thanks for the information.

Cheers,

Martin
Photo of Yacobucci, Ryan

Yacobucci, Ryan, Multi-Tier Technical Support Engineer

  • 5,354 Points 5k badge 2x thumb
Hello Martin,

I think that policy VLAN islands is the way to go here. I just wanted to add that NAC also the ability to configure location based policy mappings, so you would only have to create 1 rule, and you could have 10 underlying policy mappings with different location criteria so that you could send a different policy mapping for each location while only using 1 rule. 

This would probably be the way to go if you were in an RFC 3580 environment where VLANs aren't controlled by policy.

Thanks
Ryan
Photo of Martin Flammia

Martin Flammia

  • 6,210 Points 5k badge 2x thumb
Thanks Ryan