AASTRA SIP-DECT (Release 3.0)- OM System Manual - Installation, Administration and Maintenance EN - Manual (Page 186)

SIP–DECT OM System Manual Release 3.0 9 Configuration und Administration Aspects
Aastra depl-1624/1.0 Page: 186 (241)
9.10 802.1Q Support
The IP RFPs support VLANs according to IEEE 802.1Q. VLAN can be administered
•
on a per port basis of the LAN switch assuming that the IP RFPs are connected to a
single port of a switched Ethernet environment, or
•
by advising a VLAN ID to the IP RFP matching the VLAN they should operate in.
VLAN tagging has only to be set to IP RFPs’ in the last case. The whole section refers to that
case. With this, also 802.1p priority within Ethernet frames is enabled.
The scope of the following description is only the VLAN tagging and obtaining the VLAN ID.
Quality of Service mechanisms like 802.1p priority and DiffServ are not in the scope of this
section.
VLAN implementation notes referring to IP RFPs:
•
IP RFPs are not able to support VLAN ID 0 as described later in this section. Any other
valid VLAN ID can be configured.
•
If a VLAN ID is configured all traffic from an IP RFP will be tagged with this VLAN ID.
•
The VLAN ID configured for a IP RFP is also used for the OMM running on this IP RFP.
•
Once a VLAN ID is set to the IP RFP, incoming frames are only accepted if they are
tagged as well. Therefore the switch port has to be configured as a tagged trunk for this
VLAN.
•
The VLAN configurations can be done using DHCP or the interface for the local static
configuration, the OM Configurator.
•
The usage of VLAN does influence the boot up process of the IP RFP because the VLAN
configuration takes place during the boot up phase.
•
The default setting is not to tag the traffic. 802.1Q tagging is enabled if the VLAN ID is set.
If no VLAN ID is set 802.1Q is disabled.
Why not VLAN ID 0 ?
VLAN ID 0 means that the IP RFP’s traffic belongs to the port/native VLAN. The Ethernet
switch port to which the IP RFP is connected must be configured to accept 802.1Q tagging
for this to work and the switch must interpret VLAN ID 0 as the port/native VLAN ID per the
IEEE 802.1Q standard.
The packets from the IP RFP are tagged with VLAN ID 0 and the packets send to the IP RFP
are tagged with the port/native VLAN ID. This scenario does not work, because the IP RFP
supports only one VLAN ID in both directions. That means the VLAN ID in receive direction
has to be the same as in send direction.
9.10.1 Boot Phase of IP RFPs (DHCP)
Because the IP RFP does not know about VLAN during the beginning of the start up, two
DHCP scopes are required. This applies regardless of the Ethernet switch being used. The
following scenario with arbitrary VLAN Ids’ details the steps an IP RFP would go through in a
typical dual-VLAN implementation.