| Oracle® Communications IP Service Activator VPN User's Guide Release 7.2 E47719-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator VPN User's Guide Release 7.2 E47719-01 |
|
|
PDF · Mobi · ePub |
This chapter explains how to configure VLANs using Oracle Communications IP Service Activator.
This chapter describes VLANs in terms of a typical large service provider scenario. The service provider has a large IP/MPLS core network with a wide geographic reach. This core network can be nationwide or even global in scope. In various cities, the evolution is to use Metro Ethernets to connect many customers to the local, large Provider Edge (PE) device. Sometimes when a customer is close enough to the core network, a Customer Edge (CE) device can connect directly to the PE without the use of a Metro Ethernet.
Figure 5-1 illustrates the configuration of VLAN in a Metro Ethernet network.
Figure 5-1 VLAN Configuration in Metro Ethernet Network
Depending on physical distance, a Metro Ethernet network may be small or large. A small Metro Ethernet network can be a single switch (or two for redundancy if placed in parallel), each connected to their own PE interface on a PE router.
Metro Ethernet network can have 30, 40, 50, or more switches in it depending on the number of customers. Where multiple customers connected to the same Metro Ethernet network, need to configure separate VLANs on the Metro Ethernet network to provide transport from the Metro Ethernet network to the IP/MPLS core.
Metro Ethernet can be organized in four types of topologies:
An example of a line topology is two switches in a sequence:
CE—Switch—Switch—PE
This topology is not redundant. If either of the switches goes out, the connection to the PE is broken.
An example of a full mesh topology is six switches physically connected to each other. The advantage is if one link goes down the traffic can take another path.
This is the most common topology. Few switches feature multiple connections to other switches, but not all switches are fully interconnected as in full mesh topology.
Figure 5-1, "VLAN Configuration in Metro Ethernet Network" illustrates ring topology. This topology is more efficient for provisioning and maintaining because of fewer connections than a mesh topology. The advantage is if one device fails, traffic can go through the other side of the ring.
In a large service provider scenario, a Metro Ethernet ring can connect to one or more smaller, secondary Metro Ethernet rings to further extend the geographic stretch (or reachability) to remote customers.
This topology can have a single link to a single switch for the secondary ring to reach smaller customers.
In a large service provider scenario, VLAN provisioning occurs in the Metro Ethernet network and at access points from the PE to the Metro Ethernet network. If you want to connect the CE on the second ring at the upper-left to a Layer 3 VPN on the PE, there are a number of connections involved, especially between the twelve switches. The PE is attached to the Metro Ethernet ring through two Ethernet switches, one on each side of the ring.
The PE requires a Layer 3 VPN site which includes two different access interfaces. These interfaces are Ethernet VLAN sub-interfaces. They are Layer 3 sub-interfaces created on the PE device using the interface policy registration in IP Service Activator. The VLAN sub-interfaces are associated with a particular VLAN ID (for example, VLAN ID 5) using the following command:
encapsulation dot1q
For information on the configuration policy used to create sub-interfaces, see the IP Service Activator Online help.
For information on interface policy registration, see "Registering Interface Policies and Creating Interfaces".
A Metro Ethernet network can support multiple VLANs and multiple customers. At the PE, all VLAN traffic from the Metro Ethernet network can arrive at the same PE port. However, the PE port is configured with separate VLAN sub-interfaces, one to match each VLAN configured on the Metro Ethernet network. The traffic tagged with a particular VLAN ID is routed to the PE through the matching VLAN sub-interface.
Continuing the example from above, the Metro Ethernet network is configured to support VLAN ID 5, so as to know where to send traffic tagged with that VLAN ID.
All devices in the primary and secondary ring must be configured to support VLAN ID 5. All interconnections between the Ethernet switches (that is, trunk ports), as well as, the switch to PE router connections have to be enabled for VLAN ID 5. This allows traffic tagged with VLAN ID 5 to be sent across the trunk ports. Each of these configurations requires a separate manual step.
In order to perform the needed configurations, you must log in to all the twelve switches on the left ring, create VLAN ID 5 on all 12, and configure 26 trunk ports (two per device including one device with four trunk ports).
To perform this configuration manually is very demanding and error prone. If any one of the trunk ports on the two Metro Ethernet rings is not enabled or misconfigured, the ring is broken and there will be only one path remaining to go through. If a second trunk port is misconfigured, connectivity between the CE and PE (and IP/MPLS core) is broken.
The CE is connected to a switch on the Metro Ethernet ring through a port which also needs to be configured as either an access or trunk port. The VLAN configuration is applied so that all Ethernet frames are tagged with VLAN ID 5. Then the frames are broadcast across the Metro Ethernet network.
At this stage, everything is configured so that frames can travel from the CE, across the Metro Ethernet networks, to the PE, onto the VPN, across IP/MPLS core, to the destination Metro Ethernet network, onto the access device (CE) and finally to the receiver.
VLAN ID is local to the Metro Ethernet rings and is dropped when the traffic passes onto the IP/MPLS core. The Metro Ethernet network that the destination CE is connected to could use a different VLAN ID.
The Metro Ethernet network can support many different customers each with their own VLAN ID, so that there is no visibility of traffic between customers. For example, a Metro Ethernet ring could be provisioned with 200 different VLAN IDs.
At the PE, multiple VLAN IDs can arrive into the same port, but with different VLAN sub-interfaces, each associated with their respective Layer 3 VPN.
This configuration exercise can be extremely time consuming and error prone involving thousands of decision points.
This section explains how IP Service Activator implements VLANs.
VLANs are configured on Metro Ethernet networks in IP Service Activator using a policy-based approach. A network object is created in IP Service Activator to represent the Metro Ethernet network. All devices in the Metro Ethernet network would be included under the network object. An appropriate custom role is applied to these devices and to the interfaces which are trunk port connections within the VLAN.
One configuration policy is used to define the VLAN IDs on the Metro Ethernet network and a second is used to apply trunk port configuration to the appropriate interfaces. The configuration policies are applied at the network level and role-based inheritance ensures that the configuration is distributed to the appropriate devices and interfaces, and applied as device configuration commands by IP Service Activator.
This powerful policy-based approach greatly reduces potential configuration errors and makes maintenance of the VLAN configuration easy.
Another advantage is that as additional devices are added to the Metro Ethernet network, you need to only discover them and apply appropriate device and interface roles, and all the required VLAN configuration is automatically applied. In case, you need to remove or add support for a single VLAN ID, the change is made in one place (on the vlanDefinitions configuration policy) and is automatically updated throughout your network.
Table 5-1 shows the topology points that must be configured between the CE and PE, and the Metro Ethernet between them to support a VLAN.
Table 5-1 Topology Points Required to Support a VLAN
| Topology Points | Required Configuration |
|---|---|
|
On the PE |
PE interface and access port |
|
On the access switch connected to the PE |
Trunk port |
|
On the Metro Ethernet switches |
Trunk port |
|
On the access switch connected to the CE |
Access port and trunk port |
The vlanDefinitions configuration policy can be used to define VLANs at the network level. The vlanDefinitions configuration policy is applied on the PE interface. By setting roles on target devices and interfaces, inheritance is used to apply the VLAN configuration to the appropriate devices and interfaces. The vlanDefinitions configuration policy can be used to define up to 200 VLAN IDs.
The vlanInterface configuration policy is applied to the switch ports and access ports connecting to the PE and CE.
The device level configuration policy should be applied to a Loopback interface. For more information, see IP Service Activator QoS User's Guide.
The vlanInterface configuration policy can be applied at the network level. By setting roles on target devices and interfaces, inheritance is used to apply the configuration policy to the appropriate devices and interfaces.
Separate instances of the vlanInterface configuration policy are used to configure access ports and trunk ports. It is important to ensure that separate roles are used to distinguish the two types of policy targets. One instance of vlanInterface configuration policy is applied to each customer site access port. Only one VLAN ID is allowed to be specified on this port.
When you discover the devices and switches that will be configured to support VLAN, ensure you create a structure within the IP Service Activator object model hierarchy that will reflect your strategy for grouping targets so that policy inheritance will flow correctly.
Within a Metro Ethernet network, consider creating a custom role that applies to the network and the devices under that network that make up the Metro Ethernet network. Using this role, the vlanDefinitions configuration policy can be automatically applied to all devices in the Metro Ethernet network that require VLAN configuration, because it will be inherited by all devices with custom role.
Where there are primary and secondary Metro Ethernet rings, you may require different custom roles so that you can address each Metro Ethernet network separately, for management purposes.
As additional devices are added to a Metro Ethernet ring, they can be discovered into the appropriate IP Service Activator network and given required roles.
Consider a single Metro Ethernet ring.
Figure 5-2 illustrates the application of VLAN role and configuration policies.
To assign VLAN roles and configuration policies as in Figure 5-2:
In the IP Service Activator client, take the devices that are in the Metro Ethernet network and group them into the same network (for example, MetroEth).
Create a custom role called MetroEthCoreDev to identify devices that are included in the MetroEth network.
For information on creating a role, see IP Service Activator User's Guide.
Apply the MetroEthCoreDev role to all devices in the MetroEth network.
Create another custom role called MetroEthCorePort to identify trunk ports.
Apply the MetroEthCorePort role to each trunk port.
Apply the vlanDefinitions configuration policy to the MetroEth network and apply the role MetroEthCoreDev.
All devices in the network will receive the VLAN configuration specified by the vlanDefinitions configuration policy.
Apply the vlanInterface configuration policy to the MetroEth network and apply the role MetroEthCorePort.
All trunk ports in the network will receive the VLAN interface configuration specified by the vlanInterface configuration policy.
The CE access port must be configured either as a trunk port or an access port as follows:
If configured as a trunk port, the MetroEthCorePort role is applied to the interface, which will cause the vlanInterface configuration policy to be applied. In this case, traffic travelling out of this port onto the Metro Ethernet network is tagged with a VLAN ID.
If configured as an access port, the port can handle traffic destined for multiple VLAN IDs. The traffic traveling out of this port onto the Metro Ethernet network is not tagged with a VLAN ID—this happens on the device in the Metro Ethernet network to which it is connected.
Configure the port on the PE which connects to the Metro Ethernet network as either an access or trunk port similar to CE access port configuration.
The following two configuration policies are provided with IP Service Activator for configuration of VLAN.
vlanDefinitions: Allows you to create VLAN definitions on devices. Various parameters including the VLAN ID and name can be specified. Up to 200 VLAN IDs can be specified in a single instance of this policy. Multiple instances of the vlanDefinitions configuration policy can be applied on the device to configure more VLANs.
vlanInterface: Allows you to configure a VLAN on an interface. Multiple VLAN IDs can be specified in a single instance of this policy. Alternatively, multiple instances of the vlanInterface configuration policy can be applied to an interface to configure more VLANs.
For details about the fields provided in these configuration policies, see IP Service Activator online Help.
In some cases there may be a requirement to trade-off between redundancy and resiliency, and speed within a Metro Ethernet network.
For example, a partial mesh Metro Ethernet network with fewer VLAN IDs configured on it may switch faster due to less broadcasting of VLAN tagged packets across the network, but provide less redundancy. A full mesh Metro Ethernet network with a lot of VLAN IDs managed by a configuration policy applied across the network is easier to maintain in terms of operator actions, and provides high resiliency, but might switch packets slowly across the network due to a higher hop count.
Consider an efficient VLAN configuration set up with individual configuration policies applied to all involved target objects (interfaces and devices) on the Metro Ethernet network. This VLAN configuration will be very labor-intensive, slow to provision and maintain, and error-prone.
Instead, if you choose to accept more Ethernet broadcasting, you can have a VLAN configuration in which you can provision services very quickly using a full or partial policy-based approach.
Oracle can provide consulting to help you achieve an optimal solution to match your requirements.
Table 5-2 illustrates various trade-offs that can be considered for your VLAN configuration.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
