Network : Network > Interfaces

Physical and Virtual Interfaces
Interfaces in SonicOS can be:
Physical interfaces – Physical interfaces are bound to a single port
Virtual interfaces – Virtual interfaces are assigned as subinterfaces to a physical interface and allow the physical interface to carry traffic assigned to multiple interfaces.
Physical Interfaces
Physical interfaces must be assigned to a zone to allow for configuration of Access Rules to govern inbound and outbound traffic. Security zones are bound to each physical interface where it acts as a conduit for inbound and outbound traffic. If there is no interface, traffic cannot access the zone or exit the zone.
For more information on zones, see Network > Zones .
10 Gigabit Ethernet SFP+ Ports on NSA 6600 and SuperMassive 9000 Series
On NSA 6600 and the SuperMassive 9000 series appliances, the enhanced small form-factor pluggable (SFP+) ports, X16, X18, and X19 are designated with a dot to signify that they have a direct maximum throughput to the CPU. These dotted ports have a dedicated (non-shared) uplink to the CPU.
This is beneficial, for example, if you have a 10Gb corporate network backbone and you are using a SuperMassive 9200 as the gateway device for your department. You should connect one of the dotted ports (X16, X18, or X19) directly to the backbone. This will provide the fastest access because these ports are direct connections from the CPU to anything connected to them. You do not want the connection to the backbone sharing bandwidth with users or any other devices on your network. For maximum speed and efficiency a dotted port should be connected directly to the backbone.
As another example, business-critical and heavily multiplexed links should also typically be connected to a dotted interface. An example of a business-critical use case might involve an administrative unit connecting to a 10Gb backbone network. For maximum performance, the upstream backbone connection should connect via a dotted interface. This ensures that important backbone traffic will never be lost due to transient high load conditions on the other non-dotted interfaces that share a CPU uplink.
An example of a heavily multiplexed use case might involve a number of downstream enterprise switches that each have 10Gb uplinks. For maximum performance, each should be connected via a dotted interface. This ensures that differing high-level switching domains cannot starve each other of CPU resources.
Figure 4. 10 Gigabit Ethernet hot-pluggable ports
The X17 interface is marked with an asterisk in the SonicOS management interface to indicate that it is connected to the common switching domain shared with ports X0 - X15, thereby allowing X17 to participate in SonicOS advanced switching features.
Virtual Interfaces (VLAN)
Supported on SonicWALL security appliances, virtual Interfaces are subinterfaces assigned to a physical interface. Virtual interfaces allow you to have more than one interface on one physical connection.
Virtual interfaces provide many of the same features as physical interfaces, including zone assignment, DHCP Server, and NAT and Access Rule controls.
Virtual Local Area Networks (VLANs) can be described as a “tag-based LAN multiplexing technology” because through the use of IP header tagging, VLANs can simulate multiple LAN’s within a single physical LAN. Just as two physically distinct, disconnected LAN’s are wholly separate from one another, so too are two different VLANs; however, the two VLANs can exist on the very same wire. VLANs require VLAN aware networking devices to offer this kind of virtualization — switches, routers and firewalls that have the ability to recognize, process, remove and insert VLAN tags (IDs) in accordance with the network’s design and security policies.
VLANs are useful for a number of different reasons, most of which are predicated on the VLANs ability to provide logical rather than physical broadcast domain, or LAN boundaries. This works both to segment larger physical LAN’s into smaller virtual LAN’s, as well as to bring physically disparate LAN’s together into a logically contiguous virtual LAN. The benefits of this include:
Increased performance – Creating smaller, logically partitioned broadcast domains decreases overall network utilization, sending broadcasts only where they need to be sent, thus leaving more available bandwidth for application traffic.
Decreased costs – Historically, broadcast segmentation was performed with routers, requiring additional hardware and configuration. With VLANs, the functional role of the router is reversed – rather than being used for the purposes of inhibiting communications, it is used to facilitate communications between separate VLANs as needed.
Virtual workgroups – Workgroups are logical units that commonly share information, such as a Marketing department or an Engineering department. For reasons of efficiency, broadcast domain boundaries should be created such that they align with these functional workgroups, but that is not always possible: Engineering and Marketing users might be commingled, sharing the same floor (and the same workgroup switch) in a building, or just the opposite – the Engineering team might be spread across an entire campus. Attempting to solve this with complex feats of wiring can be expensive and impossible to maintain with constant adds and moves. VLANs allow for switches to be quickly reconfigured so that logical network alignment can remain consistent with workgroup requirements.
Security – Hosts on one VLAN cannot communicate with hosts on another VLAN unless some networking device facilitates communication between them.
Subinterfaces
VLAN support on SonicOS is achieved by means of subinterfaces, which are logical interfaces nested beneath a physical interface. Every unique VLAN ID (tag) requires its own subinterface. For reasons of security and control, SonicOS does not participate in any VLAN trunking protocols, but instead requires that each VLAN that is to be supported be configured and assigned appropriate security characteristics.
Trunk links from VLAN capable switches are supported by declaring the relevant VLAN ID’s as a subinterface on the firewall, and configuring them in much the same way that a physical interface would be configured. In other words, only those VLANs which are defined as subinterfaces will be handled by the firewall, the rest will be discarded as uninteresting. This method also allows the parent physical interface on the firewall to which a trunk link is connected to operate as a conventional interface, providing support for any native (untagged) VLAN traffic that might also exist on the same link. Alternatively, the parent interface may remain in an ‘unassigned’ state.
VLAN subinterfaces have most of the capabilities and characteristics of a physical interface, including zone assignability, security services, GroupVPN, DHCP server, IP Helper, routing, and full NAT policy and Access Rule controls. Multicast support is excluded from VLAN subinterfaces at this time.