Mitel Deutschland GmbH 68635RFP36U-01 ユーザーズマニュアル
SIP-DECT OM System Manual
258
The scope of the following description is restricted to VLAN tagging and obtaining the VLAN ID. Quality
of Service mechanisms like 802.1p priority and DiffServ are not described in this section.
of Service mechanisms like 802.1p priority and DiffServ are not described in 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 an 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 must 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 use 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.
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 sent 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 the receive direction must be the same as the send
direction.
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 the receive direction must be the same as the send
direction.
7.12.1 BOOT PHASE OF IP RFPS (DHCP)
Because the IP RFP does not know about VLAN at 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.
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.
Step A. DHCP scope within the native VLAN:
1 IP RFP boots up and obtains an address on the native VLAN.
2 The data VLAN DHCP option 132 directs the IP RFP to go to voice VLAN.
1 IP RFP boots up and obtains an address on the native VLAN.
2 The data VLAN DHCP option 132 directs the IP RFP to go to voice VLAN.
Step B. DHCP scope within the voice VLAN:
1 IP RFP releases the data VLAN address and obtains an address on the voice VLAN and all other
1 IP RFP releases the data VLAN address and obtains an address on the voice VLAN and all other
parameters.
The voice VLAN does not have the DHCP option 132, because an IP RFP already on the voice VLAN
does not need to be directed to go there.
does not need to be directed to go there.
2 IP RFP is operational on the voice VLAN.
If a reboot or power cycle occurs, the IP RFP returns to step A.
If an IP RFP cannot obtain an address on the voice VLAN, due to network or DHCP problems then the
IP RFP falls back automatically to untagged frames (native VLAN).
IP RFP falls back automatically to untagged frames (native VLAN).