| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the VPN and network connectivity services supported by Oracle Communications IP Service Activator.
IP Service Activator supports the established IETF standard (RFC 4364bis) for Layer 3 VPNs on Cisco and Juniper M-series. MPLS is used to forward packets over the backbone while BGP is used to distribute routes, offering a scalable alternative to fully meshed circuit or tunnel-based IP VPNs. Security and privacy within an MPLS VPN is achieved by limiting the distribution of routing information to members of the VPN.
Using IP Service Activator allows you to set up VPNs quickly and easily by defining the appropriate customer sites and specifying how they are linked together into VPNs. The relevant routers throughout the network are then configured automatically.
For complete details on MPLS VPN support for specific vendor devices, please refer to the appropriate cartridge guide.
This section describes some of the key MPLS VPN concepts, as implemented in IP Service Activator.
MPLS uses a technique called label switching to forward data throughout the network. The routers within an MPLS network that are responsible for label processing are known as Label Switched Routers (LSRs), and the path followed by data is known as a Label Switched Path (LSP).
On entry to an MPLS network, one or more fixed-format labels are inserted at the front of each packet. This label tells switching nodes throughout the network how to process and forward the data. The packet's path through the network is defined by its initial labeling – subsequent mapping of labels is defined by the initial label allocation.
Each LSR in the MPLS network normally runs a Label Distribution Protocol (LDP) that distributes the labels that are to be used to forward packets across the MPLS network using peer-to-peer negotiation from network edge to network edge. These labels are associated with Forwarding Equivalence Classes (FECs) that define an IP address prefix for an egress point from the network. The MPLS labels only have significance between these LSR-peers.
In an MPLS VPN, routers are classified according to the roles they perform.
Provider Edge (PE) routers are those routers within a Service Provider core network that connect directly to a router at the customer's site.
Provider (P) routers are all those routers within the VPN core network that are not edge routers.
Customer Edge (CE) routers are those routers at the customer premises that have a direct interface to the PE router. These are sometimes known as CPE (Customer Premises Equipment) devices.
These roles are shown in Figure 4-1.
The Service Provider is responsible for managing the backbone, comprising the PE and the P routers. From an MPLS point of view, all routers in the core are LSRs. The PE devices are edge LSRs, responsible for attaching label headers at ingress and stripping labels at egress.
As far as MPLS VPNs are concerned, the CE devices are the responsibility of the customer, and they do not need to run MPLS. However, in cases where they are managed by the Service Provider, IP Service Activator can configure policy-based services on them.
The various routers within the VPN communicate using BGP, an IP routing protocol that defines how routes can be distributed. BGP transports information about CE routers only to members of the same VPN, ensuring security.
A BGP Autonomous System (AS) is a collection of networks under a common administration that share a common routing strategy. BGP communication that takes place within an autonomous system (for example, between PE routers within a Service Provider network) is known as Internal BGP (iBGP). BGP communication between different autonomous systems, for example, between a PE and a connected CE, is known as External BGP (eBGP).
Each AS is identified by an Autonomous System Number (ASN), which is required when running BGP. Service Provider networks normally use BGP, so they will already have an assigned ASN. However if eBGP is used as the routing protocol between PEs and CEs, a unique ASN must be assigned to each separate customer site network.
A VPN comprises a number of customer sites communicating over a shared network infrastructure.
A CE device is always in a single site, but a site may belong to multiple VPNs. A PE router can be connected to CE devices in a number of different sites, in the same or different VPNs.
Each customer site can be identified by its CE router, but from the Service Provider's point of view (who may not have visibility of customer equipment), each site is defined by interfaces on the PE router connected to the CE router, as in Figure 4-2.
MPLS VPNs enable customer site networks to use overlapping address space, rather than globally registered IP addresses. This is achieved by ensuring unique addresses for use within the VPN, by means of Route Distinguishers (RDs), also known as Route Descriptors.
The PE adds the site RD to the IP address of each node within the customer site to create an extended address, known as a VPN-IPv4 address and VPN-IPv6 address. This is used to identify the node throughout the VPN. The VPN-IPv4 address and VPN-IPv6 address uniquely identifies each endpoint in the network, even if the customer site is using unregistered private IP addresses.
Each PE router maintains a number of separate forwarding tables known as VRF (VPN Routing and Forwarding instance) tables, and each site (that is, each PE interface or sub-interface connected to a CE device) must be mapped to one of those VRF tables.
A VRF table does not necessarily correspond to a particular VPN. Its purpose is to hold the routes that are available to a particular site connected to a PE device. If a site is in multiple VPNs, the VRF table associated with that site contains routes for all the VPNs of which it is a member.
Routes defined within a PE's VRF tables are propagated to other PE devices within the same VPN. But since a VRF table is not mapped directly on to a VPN, it is necessary to identify the VPN to which each route applies.
This is achieved by means of route targets. Every route that is distributed from a VRF table is tagged with an export route target attribute identifying its VPN. Each VRF is tagged with one or more import route target attributes, indicating the VPNs for which it wants to import routes.
When routes are distributed, any route marked with a particular export route target attribute will be installed in VRF tables marked with the same import route target attribute.
The various routers within the VPN need to communicate using a routing information distribution protocol that defines who can talk to whom. Figure 4-3 illustrates the routing protocols required in an MPLS VPN.
PE routers that are connected to other PE routers within the same VPN communicate using iBGP. iBGP is used to transport VPN-IPv4 and VPN-IPv6 network addresses across the core network to other VRF tables.
Each PE router also needs to communicate with its external neighbors (the CE routers to which it is connected) in order to transport these private routes between the CE routing table and the PE VRF table. IP Service Activator supports eBGP, OSPF and RIP routing protocols as well as static routing.
In addition to BGP, an Interior Gateway Protocol (IGP), such as OSPF or IS-IS is required within the core network, to enable normal connectivity throughout the core, so that LSPs can be established.
The IP Service Activator Device Drivers (and Network Processor and cartridges) configure the appropriate VRF (VPN Routing/Forwarding Instance) tables and associated route targets on the PE devices. Each customer site connects to a PE interface or sub-interface. This interface is assigned to a VRF table, which defines the VPN membership of a customer site. VRF tables hold routing information that defines how packets from a given site are routed across one or more VPNs to other sites. They are private routing tables containing IPv4 and IPv6 routes that have been learned from CE routers using eBGP, RIP or OSPF and any explicitly defined static routes. They do not form part of the PE router's own routing tables.
VRF tables are generally given default names by IP Service Activator. However, you can define specific names for VRF tables on selected interfaces if you wish.
A VRF table is set up on the device for each PE interface that is a member of a VPN. However, if multiple VRF tables contain exactly the same routes IP Service Activator will normally reduce them to just one, in order to minimize resource usage. This is known as VRF re-use or VRF reduction.
In some cases automatic VRF re-use may not be required. For example, you may want to provision dual links to customer sites in order to implement load balancing, requiring a separate VRF table for each connecting interface, or to reduce the impact of future re-configuration. In this case you can override VRF re-use by specifying that particular interfaces are always to have their own VRF table.
The RD number can be in either of the following formats:
32-bit IP address:16-bit number
16-bit ASN number:32-bit number
IP Service Activator normally generates RD numbers automatically, using the second of these formats. However you can override the default and specify your own RD numbers if you wish.
A route target (RT) identifies a set of sites within a VPN to which a PE device distributes routes. Route targets are used to create the VPN topology. Each VPN must have a unique route target number.
The RT number can be in either of the following formats:
32-bit IP address:16-bit number
16-bit ASN number:32-bit number
IP Service Activator normally generates RT numbers automatically, using the second of these formats. However, you can override the default and specify your own RT numbers.
The connectivity of the VPN can be one of the following:
Mesh: all sites have connectivity to all other sites
Hub and Spoke: one or more hub sites has access to all other sites; spoke sites can access the hub only
Management: works in the same way as hub and spoke, but is used when setting up QoS to ensure connectivity to CE devices
In a hub and spoke VPN topology, IP Service Activator generates two RT numbers – one for the hub site(s), generated as indicated above, and one for all spoke sites, generated by incrementing the hub low order number by 1.
You can specify your own RT numbers for hub, spoke or fully-meshed sites within a VPN if you do not want to use the default values. You can easily reassign RT numbers to sites within a VPN, if for example, it has been imported or exported by a different application.
You can specify any number of RT values per VPN and specify whether a value is used for VRF import, VRF export, or neither for hub, spoke, and fully-meshed behaviors.
By default, IP Service Activator automatically generates a site-specific VRF table name and RD number for each site that participates in a VPN.
However, you can override the IP Service Activator default by specifying at the VPN level that the same VRF table name and RD number is applied to all sites that participate in the VPN. You can choose whether to use IP Service Activator-generated values or specify your own VRF table name and/or RD number.
The route-limit features enable you to specify the maximum number of routes that can be imported into the VRF table. Two alternative actions can be defined:
A warning message can be generated if the number of imported routes reaches the maximum, but with routes continuing to be accepted.
A warning message can be generated when the number of routes reaches a specified percentage of the maximum, with no further routes accepted when the maximum is reached.
If an MPLS VPN has already been manually configured on a network, IP Service Activator is able to work with the pre-configured VRF tables that exist on devices. You can choose whether IP Service Activator ignores existing VRF tables or assumes control of them, and if existing content is preserved or removed.
You can apply a user-defined export map to the export policy configured by IP Service Activator. The export map exports only the VRF table routes whose prefixes match those specified in the export map to other PE devices. The export map tags these routes with only the RT numbers of sites that need to receive those routes.
iBGP is the protocol used for communication of VPN routes between PE devices in an MPLS VPN. In order for devices to exchange routing information, an iBGP session must be configured between the PE devices that comprise the VPN.
If iBGP peering is already installed on PE routers, for example if Route Reflectors are used, the existing configuration can be preserved.
You can enable load-balancing between iBGP peers by specifying the number of alternative routes to a given prefix that are maintained in a device's routing table. By default, this option is disabled and all identical routes learned from peer devices are dropped. To enable load-balancing, you can specify the number of routes that are maintained.
You can specify that routes advertised to the neighbor CE router contain the standard community attribute as well as the extended community attribute which is configured by default.
The identity of iBGP peers and the integrity of data exchanged during iBGP sessions can be verified using MD5 authentication. This option uses the MD5 digital signature algorithm and a specified key of up to 255 characters to generate a checksum of the iBGP data that is to be sent from a PE device to its peer. The iBGP data and its checksum are then sent to the peer device using TCP. The recipient device uses MD5 and the same key to generate a checksum of the received iBGP data. If both checksums match, the identity of the sender and the integrity of the received iBGP data is verified.
In order to exchange information to and from customer sites in the VPN, each PE router also needs to communicate with each of its external neighbors – the CE routers to which it is connected.
The effect is to advertise network reachability information between the CE and the PE, which in turn converts IPv4 and IPv6 addresses to VPN-IPv4 and VPN-IPv6 addresses respectively, for traffic passing from the CE to the PE and from the PE to the CE.
IP Service Activator supports eBGP, RIP and OSPF. Static routes can also be configured in conjunction with eBGP, RIP and OSPF routing or used alone to define routing between the PE and CE.
IP Service Activator offers a high level of control over the redistribution of routes between protocols, enabling you to specify the metric to associate with routes distributed from the selected PE-CE routing protocol into other Internal Gateway Protocols (IGPs) and BGP, and vice versa.
Redistributing routes between protocols brings with it the risk of introducing routing loops and convergence problems. However, you can filter and refine the redistribution of routes by associating a manually pre-configured route map/policy statement with redistributed routes.
You can make the following configurations to eBGP:
AS Override: you can specify that the ASN of a provider is used to override the ASN of a site. In this case, a PE device that receives route prefixes whose AS_PATH attributes have one or more ASNs matching the ASN of its neighboring CE devices, substitutes those ASN instances with the ASN of the Service Provider network. Prefixes with the substituted ASNs are then re-advertised to neighboring CE devices. The PE device also adds its ASN to routes before exporting them to the CE device.
This allows CE devices to accept routes that have been re-advertised by devices having the same ASN, and which would otherwise be rejected. Normally, a CE device rejects routes whose AS_PATH attribute contains ASNs matching its own ASN, to prevent routing loops.
Allow AS in: you can specify the maximum number of times the same ASN is allowed to occur in the AS_PATH attribute of a route prefix advertised to the PE device for the prefix to be permitted and then re-advertised to neighboring CEs by the PE device.
Extended and Standard community attributes: you can specify that routes advertised to the neighbor CE router contain the standard or extended community attribute or both.
Local preference: where multiple PE interfaces are associated with a site, the local preference for an interface can be set.
PE-CE authentication: the identity of eBGP peers and the integrity of data exchanged during eBGP sessions can be verified using Authentication.
Prefix filters: you can set up a prefix list file to specify that routes whose prefixes match those in the prefix list are either allowed or rejected by the PE router depending on their designation in the prefix list.
Prefix limit: you can specify a maximum number of eBGP IP route prefixes that can be received by the PE router from its CE neighbor.
Site of Origin: Site of Origin (SOO) is configured automatically for sites that have more than one CE to PE connection. It identifies the site from which the PE router learned the route and prevents routing loops from occurring when a site is multi-homed.
Multiple-path load sharing: you can enable load-balancing between eBGP peers by specifying the number of alternative routes that are maintained in a device's routing table. By default, this option is disabled and all identical routes learned from peer devices are dropped.
Route dampening: route dampening is a mechanism that attempts to minimize network instability by suppressing the advertisement of poorly-behaved routes. Penalties are applied when a route is withdrawn, readvertised, or changed. When a predefined penalty limit is reached, further advertisement of the route is suppressed. The penalty is reduced according to a defined ”half-life” setting, and once the penalty decreases below a limit, the route can be readvertised.
IP Service Activator allows you to configure VRF-Aware IPsec tunnels using configuration policies, which support Customer IPsec Access and Public IPsec configuration.
The VRF-Aware IPsec feature allows you to map IPsec tunnels that terminate on a shared public interface to specific Virtual Routing and Forwarding (VRF) instances. This allows you to map IPsec tunnels to MPLS VPNs extending customer VPN access to users that are not directly reachable via dedicated WAN links.
A Layer 2 Martini point-to-point connection is a Pseudo-Wire (PW) or tunnel configured between two endpoints across an IP network, as shown in Figure 4-4.
The connection uses MPLS labels to encapsulate and transport various Layer 2 data formats, including VLAN to VLAN, Ethernet, Frame Relay, ATM Cell and ATM AAL5, across an IP network. The tunnel provides a transparent connection, so users see no change in their Layer 2 data. The tunnel does not aim to meet QoS aspects of the connection, particularly in the ATM case.
The Martini endpoints can be interfaces, sub-interfaces, or other endpoint identifiers (VCI/VPI on ATM, DLCI on Frame Relay, or VLAN ID on Ethernet.
A Layer 2 Martini VPN is an association of Layer 2 Martini point-to-point connections.
A Layer 2 Martini MPLS VPN enables the encapsulation and transport of legacy data types over IP networks. As Service Providers upgrade their network core, connections between legacy networks can be maintained. Customers needing traditional connectivity over a third-party network can be served using the same IP core network, regardless of the packet types they need to transport. Additionally, the tunnel saves the complexity of carrying the customers routes across the network.
Support of Ethernet technologies also permits Service Providers to use inexpensive Metro-Ethernet solutions in the Local Area Network (LAN), reducing the rollout cost of new networks.
Similarly, Martini solutions can reduce the rollout costs associated with mobile networks in transition from 2G to 3G. Using Martini tunnels, legacy 2G connection-oriented networks can traverse the new 3G IP core network. This saves the operational costs of supporting two different networks.
IP Service Activator supports the configuration of Layer 2 Martini VPNs on MPLS-enabled switching devices, which encapsulate and transmit a number of different types of data.
These devices can be roughly categorized as either MPLS-enabled switching devices or routers.
MPLS-enabled switching devices support Layer 2 and Layer 3 switching features, MAC learning, and VLAN bridging. Table 4-1 lists the data types that can be encapsulated on switching devices.
Table 4-1 Layer 2 Martini VPNs on MPLS-enabled Switching Devices
| Encapsulated Data | Endpoint | Comments |
|---|---|---|
|
Ethernet (Port) |
Ethernet port |
Martini VLAN ID header is stripped on the pseudo-wire and re-applied (if required) on the exit interface. |
|
Ethernet (VLAN) |
VLAN endpoints configured under Ethernet interfaces (not sub-interfaces) |
N/A |
Routers support none of the switching features described above but support standard IP routing between interfaces. Table 4-2 lists the data types can be encapsulated on router equipment.
Table 4-2 Layer 2 Martini VPNs on Routers
| Encapsulated Data | Endpoints | Comments |
|---|---|---|
|
Ethernet (Port) |
Ethernet interfaces |
All VLAN tags are preserved across the connection. Frames that enter the tunnel labeled VLAN n leave the tunnel labeled VLAN n. |
|
Ethernet (VLAN) |
VC identifiers |
The VC identifier value represents the VLAN ID. The same VLAN ID must be used at both ends of the connection. |
|
ATM Cell |
Sub-interface with VC identifier |
N/A |
|
ATM AAL5 |
Sub-interface with VC identifier |
N/A |
|
Frame Relay |
Main interface with VC identifier |
The VC identifier value attached to the main interface must be created manually. |
The high-level steps to create a Layer 2 Martini VPN in Service Activator are:
Add the Layer 2 Martini connections.
Set the options in the L2 Martini Pt-Pt property page.
Assign the endpoints to the new Layer 2 Martini tunnel.
Complete details, including concepts, prerequisites, and procedures, are provided in IP Service Activator VPN User's Guide.
Layer 2 MPLS Label Switched Path (LSP) Activation enables the provisioning of engineered LSP tunnels. An LSP tunnel is an entity that exists on a specific network device and identifies a hop-by-hop path through the network to another specific device. Once an engineered tunnel is in place between device A and device B, traffic flowing from A to B should travel through the network more efficiently.
A primary LSP on the Service Provider network is configured to be the preferred path. An optional secondary path provides path protection, as shown in Figure 4-5.
In addition to the IP addresses of all the hops (between 0 and 30) in both the primary and backup (secondary) path between the 2 devices, the user can provision a number of attributes which affect the operation of the tunnel.
IP Service Activator implements only Virtual Private LAN Services (VPLS), a service type of Transparent LAN Service (TLS).
A VPLS connects separate customer Ethernet LAN segments through an MPLS network. The connection across the network appears to the customer as a single LAN segment.
On Brocade devices, IP Service Activator supports the encapsulation and transport of layer 2 frames across the VPLS as described in the Lasserre TLS Draft available at the following web site:
http://tools.ietf.org/html/draft-lasserre-tls-mpls-00
The VPLS is configured on the PE devices within an MPLS network only. Ethernet frames are mapped to a particular service instance based on a combination of the port on which they arrive at the PE device and, optionally, the 802.1Q tag that has been applied to them. As with other VPN solutions, inner and outer tunnels are used. The outer tunnels provide a transport mechanism between the PE routers in the VPLS. The inner tunnels, referred to as VC-LSPs, form a full-mesh between the PEs in each VPLS instance and are particular to that VPLS. Multiple VC-LSPs may be carried by a single transport 'outer' LSP.
The Lasserre VPLS solution uses VC-LSPs, which are defined in the Layer 2 Martini over MPLS Internet drafts. A targeted LDP peering association between two PEs creates the VC-LSP. The PEs exchange information about the Layer 2 protocol that will be carried. In the TLS case, this is either untagged or 802.1Q tagged frames. This exchange also includes information about the VPLS instance of which the VC-LSP forms a part. The Forwarding Equivalence Class (FEC) thus describes Layer 2 information, rather than the more usual IP prefix.
Each PE sends back a VC-LSP label, which is mapped to the FEC. When a frame is received at the PE, it examines its forwarding table and applies the correct VC-LSP label. Then the correct transport label is added and the frame is forwarded to the correct destination. At the egress PE router, the VC-LSP label is used to identify the correct Ethernet port over which to forward the enclosed frame.
In Figure 4-6, VC-LSPs are configured for the Customer A TLS instance between San Francisco, Denver and New York. The VC-LSPs are contained within the transport LSPs that connect these destinations.
Transport LSPs are responsible for linking PE routers together. Each VC-LSP must be forwarded to the correct PE by the transport LSP.
The IEEE standard 802.1Q describes a VLAN tag that can be applied to an Ethernet frame. The tag value is the VLAN ID, a number assigned to switches in an Ethernet network. Tagged frames can only be forwarded to switches that are configured with the same VLAN ID as the tag. Switches may be in more than one VLAN at a time, connected by trunk ports over which tagged frames are sent. Access ports to the Ethernet network may only be assigned a single VLAN ID. The frames arriving at an access port are untagged.
To complete the VPLS service, a mapping must be established between incoming Ethernet frames to the PE and the VC-LSPs that are configured over the MPLS core. This mapping can be:
Port based: all frames from a particular port are mapped to the service.
VLAN based: all frames with an 802.1Q tag of a given value are mapped to the service.
Port-and-VLAN based: all frames from a particular port with a given 802.1Q tag are mapped to the service.
IP Service Activator supports port-based and port-and-VLAN based TLSs. The mapping to the VPLS instance is configured on the PE device.
Ethernet is a broadcast service and this must be replicated in the VPLS. Therefore, when a frame is received at the PE for an unknown destination, it is forwarded over all the VC-LSPs in the VPLS. When a response to this frame is received at the PE, the device first learns which VC-LSP the frames were returned over before forwarding the frame over the correct Ethernet port. Future frames to that destination are then only sent over the learned VC-LSP. This mechanism is called 'flood and prune'.
A port that handles incoming traffic to the VPLS may therefore receive tagged or untagged frames and tagged frames may belong to one or more VLANs. The ingress ports to the TLS may be configured as one of the following, depending on whether tagged or untagged frames are handled:
A trunk port: receives and transmits tagged frames belonging to one or more VLANs; a trunk port may also be configured to transmit untagged frames by making it part of the native VLAN (typically VLAN 1), but this is not supported by IP Service Activator.
An access port: receives and transmits untagged frames and frames belonging to a maximum of one VLAN. By default, access ports are considered to be part of the native VLAN unless they are explicitly assigned to another VLAN.
A TLS is represented by a TLS object in the client, and the edge points of the TLS are represented by layer 2 site objects. Each layer 2 site is linked to one or more ports that indicate where IP Service Activator will apply TLS configuration, as shown in Figure 4-7.
IP Service Activator represents a layer 2 port as an interface object in the client. In the descriptions that follow, the term ”interface” is used when referring to TLS setup through the client.
IP Service Activator applies the concept of port and port-and-VLAN-based entry criteria both to the TLS object and the layer 2 sites that are linked to it:
A port-based TLS consists of a number of port-based layer 2 sites
A port-and-VLAN-based TLS consists of a number of port-and-VLAN-based layer 2 sites
In a port-based TLS, forwarding of frames across the TLS is based on incoming port number.
Incoming frames may be tagged frames or untagged frames.
Any VLAN configuration and management is performed by the service provider and/or its customer. IP Service Activator simply configures the specified ports at the edge of the TLS to be either Ethernet access ports or 802.1Q trunk ports, depending on whether untagged or tagged frames are transmitted across the TLS.
You cannot perform tagging of incoming frames at a port-based site.
The edge points for the TLS are defined by port-based layer 2 sites. Each site may contain a single port. A port-based site may be linked to one port-based TLS.
You specify on which ports incoming frames for the TLS will be received by linking the Access interface on the appropriate Gateway (PE) device to a layer 2 site. An interface can be linked to one port-based layer 2 site.
Ethernet has become the technology of choice for Metro networks, and is gradually taking over Frame Relay and ATM for access into the IP core network. IP Service Activator supports the ability to deploy and manage Metro Ethernet Virtual LAN (VLAN) Services in a multi-vendor environment, based on the 802.1Q standard. For example, IP Service Activator supports VLAN services on Cisco Catalyst IOS devices and Extreme Networks' Alpine, Summit and Black Diamond 6800 equipment.
Ethernet services are provisioned differently than IP services. Ethernet network services are configured at the edge and the core on a per customer basis. IP services are typically configured only at the edge of the Service Provider IP network. For this reason, Oracle Communications is delivering two levels of VLAN application, targeting the core network and edge access into the Ethernet network.
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.
IP Service Activator supports multiple VLAN options:
Untagged: Customer traffic comes into the Service Provider as plain, untagged Ethernet traffic. The edge switch and access port then tag the frames with the appropriate VLAN configured against that site. This allows the frames to be transported across the Ethernet core where the VLAN is enabled.
Tagged: Customer traffic comes into the Service Provider with its own set of VLAN tags. In other words, the customer network is already segregated into VLANs which must be transported across the Service Provider network. IP Service Activator supports the configuration on that site of the specific set of VLANs to match the specified incoming traffic.
Stacked VLANs (or Q-in-Q): A Service Provider can carry up to 4096 VLANs within a single Metro Ethernet network. If each customer were to connect with tagged traffic for multiple VLANs, the Service Provider could run out of VLAN IDs for all of its customers. The Stacked VLAN solution can prevent this from happening. Using Stacked VLANs, the Service Provider can encapsulate incoming customer-tagged traffic into a single VLAN, and remove the encapsulation at the destination site. This approach can transport a whole set of customer VLANs through a single Service Provider VLAN. Stacked VLANs can support over 16 million VLANs in a single Metro Ethernet network.
IP Service Activator supports Dedicated Internet Access (DIA) Services through a combination of capabilities built into the IP Service Activator service model and the application of interface and routing configuration policies. This is done through the configuration of Layer 3 interfaces on the PE and the configuration of basic routing (typically static routes) to provide reachability to Internet gateways.
Figure 4-8 illustrates a typical scenario in which it is required that each customer site be able to access the Internet. This is accomplished through the use of DIA sites on the connected PEs.
A Layer 3 interface is configured or created and placed in a DIA site. In a managed CE service, the CE device is also placed in the DIA site. IP routing is configured on the PE to route Internet traffic across the provider core to the Internet gateway and on to the Internet. Additionally, prefix lists may be configured to filter routing updates.
Each DIA site represents a physical location and includes an access interface on a PE device, and a CE device. It is used to link the CE device to the PE interface so that routing to the Internet gateway can be provided.
For each of these DIA sites, you need to create a logical Layer 3 interface on the PE dedicated to that site. Each Layer 3 interface will have a different IP address (because they are public IP addresses), and will connect to the service provider public network routing.
Multicast provides an efficient means of transmitting the same data to multiple receivers in a multicast group. A multicast group is an arbitrary number of receivers that join a group in order to receive a particular traffic. This multicast group has no physical or geographical boundaries—the hosts (sources or receivers) can be located anywhere on the Internet or on any private internetwork. A group of receivers can listen to a single address, or a group of addresses.
A multicast address identifies multiple interfaces, and is used for one-to-many communication. With the accurate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces that are identified by the address. A packet sent to a multicast address is delivered to all interfaces identified by the multicast address, whether it is IPv4 or IPv6.
Multicast uses the class D address range running from 224.0.0.0 through 239.255.255.255 for IPv4 multicast addresses. The addresses do not have a subnet mask length associated with them for forwarding purposes. Each address is treated independently so the subnet mask used for forwarding is always assumed to be /32.
IPv6 multicast addresses have the Format Prefix of 1111 1111. An IPv6 address is simple to classify as multicast because it always begins with FF. Multicast addresses cannot be used as source addresses.
You can use a subnet mask only for discovery using IPv4, not for discovery using IPv6.
Applications that take advantage of multicast include video conferencing, corporate communications, distance learning, and software distribution.
IP Service Activator supports two Layer 3 multicast services:
IP multicast
VPN multicast
IP Service Activator configures multicast using configuration policies.
IP Service Activator supports configuration policy-based activation of IP multicast on Customer Edge (CE) routers. This includes the configuration of multicast RPs using static configuration, Auto-RP, or Bootstrap Router (BSR). Configuration of both Protocol Independent Multicast Sparse Mode (PIM-SM) and Protocol Independent Multicast Source Specific Multicast (PIM-SSM) are supported as well as activation of IGMP, Cisco Group Management Protocol (CGMP), and Router-Port Group Management Protocol (RGMP) on LAN interfaces.
IP multicast is configured on CE interfaces and is supported on specific Cisco IOS devices. Support can be extended to other devices using IP Service Activator Software Development Kit (SDK).
VPN multicast provides the ability to support multicast over a Layer 3 Virtual Private Network (VPN). As Layer 3 VPNs support only unicast traffic connectivity, deploying this service in conjunction with a Layer 3 VPN allows service providers to offer both unicast and multicast connectivity to Layer 3 VPN customers.
VPN multicast allows an enterprise to transparently interconnect its private network across the network backbone of a service provider. The use of a VPN multicast to interconnect an enterprise network in this way does not change the way the enterprise network is administered, nor does it change general enterprise connectivity.
IP Service Activator supports:
A set of policies that enable the creation of VPN multicast sites.
Creating Access Lists when configuring VPN multicast. The access lists include:
PE-CE Access List and PIM
Mrinfo-filter
Static RP-to-Group mapping
PIM-SSM Range
SPT Threshold
Enabling VPN multicast on a device
Setting Rate-Limit on PIM-SM register messages
Configuring the address of a PIM rendezvous point for a particular group
Defining PIM-SSM range
Specifying the threshold that must be reached before moving to the SPT
VPN multicast is configured on Provider Edge (PE) interfaces and is supported on compatible Cisco IOS devices. The support can be extended to other devices using IP Service Activator SDK.
The Alcatel cartridge supports Configuration Policies that require custom generated .xml files that are derived from the Alcatel SAM. Since the HTML used for the Configuration Policy is no longer installed on each client, a tool is required to combine the XML data file with the HTML so it can be imported into the configuration policy.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
