Overview

General information

An IES is a routed connectivity service in which the customer traffic passes through an L3 IP router interface to the Internet.

IES allows customer-facing IP interfaces in the same routing instance to be used for service network core-routing connectivity. IES requires that the IP addressing scheme that is used by the customer be unique among other provider addressing schemes and potentially the entire Internet.

Packets that arrive at the edge device are associated with an IES based on the access interface on which they arrive. An access interface is uniquely identified using:

• port

• service ID

• IP address

IES configuration overview

The NFM-P supports end-to-end IES configuration using tabbed configuration forms with an embedded navigation tree.

The NFM-P supports the configuration in IES of an L3 aggregation mechanism called routed CO. Routed CO uses DHCP relay to manage dynamic subscriber hosts; the network resources for static subscriber hosts are explicitly provisioned. Routed CO supports all residential subscriber management functions of the NFM-P. See Chapter 74, Residential subscriber management for more information about residential subscriber management and routed CO.

Routed CO uses a subscriber interface that defines up to 256 subnets. A subscriber interface has child objects called group interfaces. A group interface supports the configuration of multiple SAPs as child objects. A SAP in a group interface supports all residential subscriber management functions. A group interface does not allow the specification of IP subnets or addresses, but inherits the addressing scheme of the parent subscriber interface. The NFM-P service topology map displays IES subscriber interfaces, group interfaces, and the associated SAPs.

You can configure NAT for dynamic subscriber hosts in a routed CO deployment. NAT implementation in an IES requires a NAT configuration on the NE base routing instance and a NAT policy that is associated with a subscriber profile. See Chapter 27, NE routing and forwarding for information about configuring and deploying NAT on a base routing instance. See Chapter 66, NAT policies for information about configuring a NAT policy. See Chapter 74, Residential subscriber management for information about associating a NAT policy with a subscriber profile.

When you use the NFM-P to create or discover a service, the NFM-P assigns a default Service Tier value to the service. The Service Tier parameter value is relevant only in the context of composite service topology views. See Chapter 85, Composite service management for more information about the hierarchical organization of composite services.

Common to all device services, such as IES, are policies that are assigned to the service. Policies are defined at a global level and can then be applied to components of the service, such as interfaces or circuits, when the service is configured or modified. The following policies are common to all device services:

• QoS policies define ingress classification, policing, shaping, and marking on the ingress side of the interface. QoS policies are configured using the SAP Access Ingress Policy form, the SAP Access Egress Policy form, and the ATM QoS Policy form.

• Policer control policies to control access ingress policers and access egress policers under a common hierarchy. Policer control policies are configured using the Policer Control Policy Manager.

• Scheduling policies define hierarchical rate limiting and scheduling to govern the scheduling of queues. Scheduler policies are configured using the Scheduler Policy form.

• Port scheduler policies define hierarchical bandwidth allocation and scheduling at the egress port level. Port scheduler policies are configured using the Port Scheduler Policy form.

• Filter policies control network traffic into or out of an interface or circuit based on DHCP, IP, or MAC matching criteria. Filter policies are configured using the ACL IP Filter form, the ACL MAC Filter form, and the DHCP Filter form.

• Accounting policies measure the traffic on a service to ensure proper billing and enforcement of SLAs. Accounting policies are configured using the Accounting Policy form.

• ANCP policies provide status and control information based on port-up and port-down messages and current line rate changes between the edge device and the access NE. ANCP policies are configured using the Manage Subscriber Policies form.

• Routing policies control the size and content of the routing tables, the routes that are advertised, and the best route to take to reach a destination. Routing policies are configured using the Routing Policy Manager.

• Time of day suites specify time and day restriction policies that are assigned to QoS policies and schedulers, ACL filters, and aggregation schedulers. Time of day suites and time range policies are configured using the Time of Day Suite form and Time Range form, respectively.

See Chapter 49, Policies overview for more information about policies.

Although IES is part of the routing domain, the usable IP address space may be limited. IES allows a portion of the service provider address space to be reserved for service IP provisioning and to be administered by a separate, but subordinate, address authority.

Multiple IESs can be created to separate customer-owned IP interfaces. More than one IES can be created for one customer. More than one IP interface can be created in one IES. All IP interfaces created in an IES belong to the same customer.

The IES IP interfaces are restricted to the routing protocols that can be defined on the interface based on the fact that the customer has a different routing domain for this service. The IP interfaces support the following routing protocols:

• RIP

• OSPF

• BGP

• IS-IS

• PIM

• IGMP

Customer routes can be advertised to the network core using static routes, RIP, or BGP. BGP and static routes are the most commonly used routing methods.

An IES can be connected to a VLL service or to a VPLS by an internal cross-connect through a CCAG adapter. This configuration eliminates the need for the physical port, cable, and other MDA-specific components and results in a less costly and more reliable interconnection. See Chapter 85, Composite service management for information about joining services to form composite services.

ATM SAP terminations for IES

CE routers that have access to an ATM network can connect with an IES service using ATM SAP terminations on a 7750 SR. The interconnection between ATM point-to-point and L3 services uses RFC 2684-encapsulated IPv4 traffic over an ATM PVC that terminates on a specially configured SAP. All RFC 2684-encapsulated traffic can be routed over ATM networks, frame relay, and directly through ATM connections.

The figure below shows how CPE router A in an existing ATM network can access L3 IP services, such as an IES, using a statically configured ATM PVC on a 7750 SR (SR #1). CPE router B is connected to a frame relay, which connects to ATM switch 2 through IWF (service interworking). The RFC 2684-encapsulated traffic moves from both CPE routers through the ATM access network to a SAP configured on a 7750 SR #1 to serve a specific IES. At the same time, SDPs on the router are configured to a service to forward traffic over the IP/MPLS core. Destination CPE router C can receive RFC 2684-encapsulated traffic over an IP network over an ATM switch connected directly using 7750 SR #2.

Figure 78-1: ATM SAP network connection to an IES

The two connection methods used between an ATM network and the IES router: LLC/SNAP encapsulation and VC multiplexing.

A VLL Epipe service can terminate directly on an IES service using an SDP spoke on the 7750 SR, 7450 ESS, or 7950 XRS. Traffic that terminates on an IES service is identified by the interface ID of the SDP on the L2 access router and the VC ID label in the service packet. All routing protocols supported by IES are also supported for spoke SDP termination.

The figure below shows a spoke SDP terminating directly on an IES. The spoke SDP could be tied to VLL Epipe or VPLS. No configuration is required for the CE-to-PE connection on the SAP.

Figure 78-2: SDP spoke termination on an L2 service

Routed CO dual homing using SRRP

Subscriber Router Redundancy Protocol (SRRP) allows two separate connections to an access NE such as DSLAM to operate in an active/standby configuration similar to the way in which VRRP interfaces operate. SRRP is a collection of functions and messaging protocols that allows a system to create a set of redundant gateway IP addresses that are shared by a local and remote NE.

Each SRRP instance is created within the context of a subscriber group IP interface and is identified by a unique SRRP instance ID, which must be unique within the NE. This SRRP instance controls the redundant routing for all subscriber subnets configured or associated with the group interface. One SRRP instance is supported for each group interface and the SRRP ID must be the same as the SRRP instance ID on the group IP interface on the redundant NE.

A subscriber subnet redundant gateway IP host address is assigned at the subscriber IP interface level and is used for each SRRP instance associated with the subscriber subnet. The redundant IP host address must be configured for a subscriber subnet before it can be associated with an SRRP instance.

When SRRP is active on a group interface, the SRRP instance advertises to a remote NE using in-band messaging on the group-interface SAPs and out-of-band messaging on the group-interface redundant interface. If the remote NE uses the same SRRP instance ID, one NE enters a master state, while the other NE enters a backup state. Since the NEs share a common SRRP gateway MAC address (used for the SRRP gateway IP address and for proxy ARP functions), either NE can act as the default gateway for the attached subscriber hosts. This functionality helps to preserve subscriber QoS enforcement. The master state allows routing to and from the subscriber hosts associated with the group IP interface. The backup state stops ingress forwarding for packets destined to the SRRP gateway MAC and causes all packets destined to subscriber hosts on the group IP interface to be forwarded to a redundant IP interface associated with the group IP interface.

Normally, when anti-spoofing is enabled on a group-interface SAP, the SAP drops SRRP packets because they do not contain a subscriber MAC or IP address. However, you can use a configuration option to enable anti-spoofing for subscriber hosts on a group-interface SAP that participates in SRRP advertisements.

The underlying mechanism that controls state transitions is based on a dynamic priority level that an SRRP instance maintains. The SRRP instance with the highest priority level assumes the master operating state. An SRRP instance with a higher current priority level always preempts an SRRP instance with a lower priority level. If the priority levels are equal, the SRRP instance with the lowest source SRRP host IP address assumes the master state. The local SRRP instance priority may also be controlled by associating the instance with an existing VRRP policy.

To prevent a flood of AccessInterfaceDown alarms that an SRRP fault or link failure may generate for LAG-based MSAPs, the NFM-P performs alarm suppression. See Chapter 74, Residential subscriber management for more information.

The redundant IP interface is a special interface that connects two systems with one or more common SRRP instances. The interface is configured with a /31 address and a spoke SDP binding, creating an Ethernet pseudowire shortcut between the redundant NEs. When the SRRP instance is in backup state, the group interface associated with this instance is not allowed to forward or route traffic downstream towards the subscriber. As a result of this, the packets are shunted across the redundant interface so that the active group interface does the forwarding or routing.

If the redundant IP interface goes down, the system allows the group IP interfaces associated with the down interface to forward locally downstream, when they are in the backup SRRP state. While forwarding downstream in the backup state, the system uses the MAC address associated with the group IP interface, not the SRRP redundant gateway MAC address.

SRRP is supported on the 7450 ESS in mixed mode and 7750 SR.

DoS protection

To protect an IES from a high incoming packet rate that characterizes a DoS attack, you can use the NFM-P to create DoS protection policies for the IES L3 access interfaces. A DoS protection policy limits the number of control-plane packets that an interface receives each second, and optionally logs a violation notification if a policy limit is exceeded. You can use the NE System Security form to view the violations for a specific NE.

You can configure a DoS protection policy to control the following on an IES L3 access interface:

• the control-plane packet arrival rate per subscriber host on the interface

• the overall control-plane packet arrival rate for the interface

• whether an NE sends a notification trap if a policy limit is exceeded

Each IES L3 access interface on an NE that supports DoS protection is automatically assigned a default DoS protection policy. This default policy limits only the overall packet arrival rate for the interface, and cannot be deleted or modified. See the procedure to configure an NE DoS protection policy in the NSP System Administrator Guide for information about creating a DoS protection policy.

DDoS protection

To protect an IES from a high incoming packet rate that characterizes a DDoS attack, you can use the NFM-P to configure TMS interfaces to route malicious traffic through the ISA-TMS MDA where the malicious traffic is cleaned before being released to the network.

The TMS interface on an IES consists of one IES and two VPRNs as follows:

• The management VPRN communicates with the TMS server to determine whether incoming packets are malicious. Configuration of this VPRN is optional.

• The Off-Ramp VPRN receives the malicious traffic and routes it through the ISA-TMS MDA where the traffic is scrubbed. Configuration of this VPRN is mandatory.

• The On-Ramp IES returns the cleaned traffic to the network. Configuration of this IES is mandatory.

See To add a TMS interface to an IES for information about creating a TMS interface on an IES.

You can configure a DDoS protection policy on an IES group interface SAP or L3 access interface. See the procedure to configure an NE DDoS protection policy in the NSP System Administrator Guide for information about configuring a DDoS protection policy.

Local DHCP servers

A local DHCP server can be associated with a network interface or L3 access interface on an IES. See Residential subscriber components .

Local user database

A local user database can be associated with a local DHCP server and PPPoE configurations on group interfaces. See Residential subscriber components .

PPPoE protocol on IES

An IES can be configured to support PPPoE. PPPoE is used in subscriber networks to encapsulate PPP frames inside Ethernet frames. PPPoE combines the point-to-point protocol used by DSL sessions with Ethernet framing to support multiple subscribers in a LAN. Using the group interface configuration form, you can assign a PPPoE policy and a local user database to authenticate PPPoE subscribers.

L2TP configuration for IES

An IES group interface can be configured to terminate LNS PPP sessions. L2TP is a session-layer protocol that extends the PPP model by allowing L2 and PPP endpoints to reside on different devices that are interconnected by a PSN. L2TP extends the PPP sessions between the CPE and PPP/L2TP termination points on the L2TP network server (LNS), via an intermediate L2TP access concentrator (LAC). The LAC is the initiator of session-generated L2TP tunnels; the LNS is the server that waits for new tunnels. Manually configured and initiated L2TP tunnels can be initiated or stopped from either the LNS or LAC.

After a tunnel is established, the network traffic between the peers is bidirectional. If a tunnel carrying a session fails, another tunnel from the same tunnel group re-establishes the session. Within each L2TP tunnel, one or more L2TP sessions can exist. Each L2TP session transports PPP packets.

At least one ISA-LNS group must be configured for the LNS NE.

On an LNS NE, L2TP destinations configured for L2TP tunnel profiles can include the following:

• loopback L3 access interfaces for a VPRN or IES service

• loopback interfaces configured for a base routing instance

See Chapter 13, Logical group object configuration for more information about ISA-LNS groups. See To configure an ISA-LNS group for information about creating and configuring an ISA-LNS group. See Chapter 28, Routing protocol configuration for more information about L2TP. See To configure a group interface on an IES for information about configuring an IES group interface to terminate LNS PPP sessions.

PIM on IES group interfaces

You can configure Protocol-Independent Multicast (PIM) functionality on an IES group interface. PIM on a subscriber group interface allows SAP-level replication over ESM group interfaces by establishing PIM adjacency to a downstream L3 router. On each group interface, a single Ethernet SAP is configured (LAG or physical port). Multiple default hosts can be configured, and a static host is configured for connectivity to a downstream L3 aggregation device. When PIM is enabled on the static host interface, a SAP configured under the group interface is added to the OIF list for SAP-level replication towards a downstream L3 router.

To configure PIM on an IES group interface, see To configure a PIM interface on an IES group interface .