I'm going to take advantage of the collective wisdom and experience of the Community:
I like to consolidate interfaces into as few policy-classes as possible, to keep configs simple and have policy-classes neatly represent actual trust zones. I know that you can use a separate policy-class for each interface, and many config examples from ADTRAN engineers and in technical documents seem to show a separate policy-class for each interface.
Are examples given with separate "trusted" policy-classes merely because it's arguably simpler to understand what's going on in those examples? Post your thoughts--Do you see some other benefit from maintaining a security zone separation between trusted interfaces?
I'm taking for granted here that all of the private networks and interfaces are truly trusted in the wide-open sense. Obviously, situations where some granularity is needed between departments, tenants or whatever would require the use of multiple policy-classes. I'm thinking about typical small or medium companies where you might have some VLANs or a remote office connected with a T1.
@cj - I would agree that sometimes it is just easier to have multiple interfaces share security zones/policy-classes. Although there are several applications that *require* that different policy-classes/security zones be defined, for generic applications it is acceptable to have them shared between interfaces.
For me, I would prefer to have separate policy-classes defined if I am dealing with several interfaces simply because if I need to troubleshoot, it is easier for me to go through the policy-sessions to find the entry that I am looking for and to verify that traffic is being routed correctly.
Thanks, Noor. Other than applications where there's just more than one trust zone (departments, VLANs, companies, etc.), what would be some common applications requiring separate policy-classes?
We're trying to standardize on our config approaches in my company. Your input is helpful for us to plan ahead and anticipate scenarios that we will encounter.
@cj - I would say most of these applications involve multiple WAN interfaces. Failover configurations, load balancing, and route-maps usually require that separate policy-classes/security zones be used since traffic will need to be NATted to different WAN IPs depending on which connection will be used. The separate policy-class/security zones allows the router to NAT traffic based on which interface will be sending the traffic out. Also, these WAN security zones/policy-sessions could very well need a different set of access rules and port forwards configured on each interface.
I see. If I understand you, these would be good examples of the need for outside/untrusted interfaces to use discreet policy-classes. Do you think the need to separate is diminished for inside/private interfaces?
Thanks again for helping me think this through.
@cj - Its really a matter of personal preference and how you would like to set up your rules. However, besides the examples you gave and perhaps configuring a DMZ with a private IP and a private interface, I haven't ran into many applications where a separate trusted policy-session/security zones were necessarily needed.